Team 1

Lisa AnthonyLuiza da SilvaErik HayesDiana Tetelman

Style Overviews

General Issues and Design Diagrams

Object-Oriented (ADT)

Classes: Main, Input, Output, Shifter, Sorter SentenceCollection, ObjectCollection,

KWICRow, KWIObject KWICException

Minimal class couplingEach class is a moduleSeveral 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 moduleFormat of data cannot change during journeyNo 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 threadsCommunicate 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 structureModularization 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 otherInput 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 entryUse of OO language (Java) caused difficulty in adhering to strict pipe-and-filter style – used central data objectAddition of modules that changed data format in the middle of flow would require a translation filter afterwardsRemoval 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 moduleNew modules would severely affect current system – not easily changed

Data Representation

Level of transparencyGeneric interfaceHidden access to dataGeneric data collection – doesn’t know it is dealing with Strings3rd layer converts to Strings Can sort, compare, print

Change to a different input type would involve only changes to this layerPromotes reuse of code

Hierarchical Structures

“Uses” Hierarchy Diagram, Other Structures

“Uses” Diagram

IIMaster : main IIInput : run IIShifter : run IISorter : run IIOutput : run

Input : startShifter : start

Sorter : startOutput : start

Input : readSentence()

message : SHIFT

Shifter : shiftSentence()

* iterations

message : DONE

message : SORT

Sorter : sortCollection()

message : OUTOutput : printCollection()

Implicit Invocation Sequence Diagram

Commonalities

“Uses” diagrams are the same – why?Most “obvious” way to structure functionality to prevent loopsDivision 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)

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 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

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 implementationsObject-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 implementationsDifficult 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’ idealOther 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