1 / 14

Software Design Project Phase 2

Software Design Project Phase 2. Team 1: Lisa Anthony Luiza da Silva Erik Hayes Diana Tetelman. Outline of Discussion. Overview Review predictions from Phase 1 Data Structure changes Implicit Shift Storage Input Filter (as a VM concept) Style Updates + New Structure Diagrams

torn
Download Presentation

Software Design Project Phase 2

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. Software Design ProjectPhase 2 Team 1: Lisa Anthony Luiza da Silva Erik Hayes Diana Tetelman

  2. Outline of Discussion • Overview • Review predictions from Phase 1 • Data Structure changes • Implicit Shift Storage • Input Filter (as a VM concept) • Style Updates + New Structure Diagrams • Implicit Invocation • Pipe-and-Filter • Object Oriented • Comparison of changeability • Conclusions about our designs, styles in general

  3. Phase 1 Predictions: Extensibility & Contractability • Object-Oriented: easiest to extend/subset • 2nd level of “uses” hierarchy are all independent • Promotes reuse • Pipe-and-Filter: • Contraction easy • Extension not so easy • Implicit Invocation: • Not at all easy • Difficult to coordinate new threads and redefine pipes

  4. Changes Needed ForImplicit Shift Storage • Data structure modifications confined to ObjectCollection • Most changes internal • Two additional methods • Change in interface • Required slight modifications to the Shifter classes in each style • Original design flexible enough to allow this modification with little exterior impact SentenceCollection extends ObjectCollection contains KWICRow

  5. Changes Needed ForNoise Words Filter • Data structure modifications confined to SentenceCollection • Most changes internal • One additional method • Change in interface • External modification only needed to take advantage of filter • Layering of data structure provided easy and transparent modification SentenceCollection extends ObjectCollection contains KWICRow

  6. Main instantiates Shifter Sorter Output Input implements extends creates manipulates iterates SentenceCollection KWICListener KWICBroadcaster extends receives receives/sends ObjectCollection contains KWICRow KWICEvent Implicit Invocation KWIC Uses Diagram

  7. affected by index based storage affected by filter addition II Modules Affected by Data Representation Changes Main instantiates Shifter Shifter Input Sorter Output implements extends creates manipulates iterates SentenceCollection KWICListener KWICBroadcaster extends receives receives/sends ObjectCollection contains KWICEvent KWICRow

  8. Pipe and Filter KWIC Uses Diagram instantiates Main Shifter Sorter Output Input fills instantiates manipulates manipulates iterates SentenceCollection extends ObjectCollection contains KWICRow

  9. affected by index based storage affected by filter addition PNF Modules Affected by Data Representation Changes instantiates Main Shifter Noise Sorter Output Input fills sets noise filter instantiates manipulates manipulates iterates SentenceCollection extends ObjectCollection contains KWICRow

  10. Object Oriented KWIC Uses Diagram instantiates Main Shifter Sorter Output Input manipulates instantiates SentenceCollection extends ObjectCollection contains KWICRow

  11. OO Modules Affected by Data Representation Changes affected by index based storage affected by filter addition instantiates Main Shifter Sorter Output Input manipulates instantiates SentenceCollection extends ObjectCollection contains KWICRow

  12. Which was easiest to change? • OO easiest to change: • Fewer modules affected by each change • Reuse of original Input module for input of noise words to filter • Implicit Storage addition affected each the same due to centralized data structure Number of modules changed in each style

  13. Analysis of Designs & Styles

  14. Conclusions • We like OO. • Robust. • Reusable. • Changeable. • Maintainable. • Genericandflexible. • Specific Phase 2 weren’t seriously considered in our predictions in Phase 1 • May have made some changes easier if we had.

More Related