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 Each class is a module Several layers of abstraction to enhance data hiding and reuse possibilities

Object-Oriented Design Diagram

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

Pipe-and-Filter Design Diagram

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

Implicit Invocation Design Diagram

Analysis of Styles Comparison & Contrast

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)

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)

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

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

Data Representation Level of transparency Generic interface Hidden access to data Generic data collection – doesn’t know it is dealing with Strings 3 rd 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

Hierarchical Structures “Uses” Hierarchy Diagram, Other Structures

“Uses” Diagram

IIMaster : mainIIInput : runIIShifter : runIISorter : runIIOutput : 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() Implicit Invocation Sequence Diagram

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 1 st )

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

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

Ease of Extension & Contraction Object-Oriented: easiest to extend/subset 2 nd 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

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

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

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

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)

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

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

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