1 / 28

Team 1

Team 1. Lisa Anthony Luiza da Silva Erik Hayes Diana Tetelman. Style Overviews. General Issues and Design Diagrams. Object-Oriented (ADT). Classes: Main, Input, Output, Shifter, Sorter SentenceCollection, ObjectCollection, KWICRow, KWIObject KWICException Minimal class coupling

bbonnie
Télécharger la présentation

Team 1

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

  2. Style Overviews General Issues and Design Diagrams

  3. Object-Oriented (ADT) • Classes: • Main, Input, Output, Shifter, Sorter • SentenceCollection, ObjectCollection, KWICRow, KWIObject • KWICException • Minimal class coupling • Each class is a module • Several layers of abstraction to enhance data hiding and reuse possibilities

  4. Object-Oriented Design Diagram

  5. Pipe-and-Filter • Classes: • Main, Input, Output, Shifter, Sorter • SentenceCollection, ObjectCollection, KWICRow, KWIObject • KWICException • Central data object passed along from module to module • Format of data cannot change during journey • No implicit trust in other modules completing their tasks

  6. Pipe-and-Filter Design Diagram

  7. Implicit Invocation • Classes: • Master, Input, Output, Shifter, Sorter • SentenceCollection, ObjectCollection, KWICRow, KWIObject • KWICException • Modules are concurrent threads • Communicate via pipes (not event handling) • Pipes set up by Master • One pipe for each module • Read/Write ends assigned to specific module • Implicit trust in other modules completing their tasks

  8. Implicit Invocation Design Diagram

  9. Analysis of Styles Comparison & Contrast

  10. Modularization • All styles used similar class structure • Modularization not necessarily the same • “Secrets” of each module differ in each implementation • Data hiding • Several extra layers to make data more generic (in case of future changes to input/output)

  11. Object-Oriented (ADT) • Modules don’t know about each other • Input module • more complex to handle possible future changes to data format • choice of interfaces (i.e., multiple infiles or only 1 infile)

  12. Pipe and Filter • Each module has single point of entry • Use of OO language (Java) caused difficulty in adhering to strict pipe-and-filter style – used central data object • Addition of modules that changed data format in the middle of flow would require a translation filter afterwards • Removal of modules does not require a lot of change

  13. Implicit Invocation • 2 centralized data objects • Input (unshifted) data • Shifted data • Concurrency issues • Each module waits for events to occur in others • Modules communicate via pipes • Know your neighbors • But don’t know if others did their jobs – implicit trust • Pipes set up by Main module • New modules would severely affect current system – not easily changed

  14. Data Representation • Level of transparency • Generic interface • Hidden access to data • Generic data collection – doesn’t know it is dealing with Strings • 3rd layer converts to Strings • Can sort, compare, print • Change to a different input type would involve only changes to this layer • Promotes reuse of code

  15. Hierarchical Structures “Uses” Hierarchy Diagram, Other Structures

  16. “Uses” Diagram

  17. Implicit Invocation Sequence Diagram IIMaster : main IIInput : run IIShifter : run IISorter : run IIOutput : run Input : start Shifter : start Sorter : start Output : start Input : readSentence() message : SHIFT Shifter : shiftSentence() * iterations message : DONE message : SORT Sorter : sortCollection() message : OUT Output : printCollection()

  18. Commonalities • “Uses” diagrams are the same – why? • Most “obvious” way to structure functionality to prevent loops • Division of work into modules of this type made co-development easier • Not a lot of communication needed • Except for data representation (interface had to be finished 1st)

  19. Other Points Transparency, Code Reuse, Undesired Events, Etc.

  20. Program Families • Are these three styles members of the same family? • Not really: • Not developed from a base system which is common to all 3

  21. Ease of Extension & Contraction • 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

  22. Transparency Loss of transparency apparent in data structure used in all implementations: • Comprised of 3 layers • Upper levels attempt to hide some lower level concepts; ex. the KWICRow performs operations on words that are not possible through use of higher layers

  23. Undesired Events All implementations handle undesired events via use of a KWICException (Java throw): • All exceptions are created at the lowest level • All exceptions are reflected up the execution hierarchy to ensure recovery

  24. Code Reuse • Data structure and exception class reusable: used in all 3 implementations • Object-Oriented • easily reused due to generic interfaces • Implicit Invocation • not easily reused due to expectance of specific events • Pipe and Filter • easily reused as long as new component uses the same data structure

  25. Abstract Data Type Collection used to store sentences to be operated on: • Assumptions: • Random access • Iterator • Provides interface to data that manages to hide some details (secrets)

  26. Unit Tests • Used to ensure correct functioning of all modules of Pipe and Filter and Object Oriented implementations • Difficult to use on Implicit Invocation implementation due to the amount of dependency between modules

  27. Summary of Results Which style is the best for Parnas’ purposes?

  28. Conclusions • Object-Oriented style is most like Parnas’ ideal • Other styles are weaker with respect to • Reuse • Changeability • Centralized data structure helps all 3 styles become stronger • Loss of transparency (data hiding) • Translation modules needed but other modules preserve interfaces

More Related