Team 1

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