SE-380 Project 2: Applying an Architectural Style: Pipes and Filters

Overview

The purpose of this project is to learn about and apply a particular architectural style, pipes and filters, to a familiar problem, the completely indexed dictionary (CID) problem. The project work is to be accomplished in your existing team environment (4 or 5 members) using a disciplined software process. Note that coordinated team effort and careful planning will be required to accomplish this project in the time allotted.

Project details

Description

Design a set of SISO (single input, single output) filters that can be combined in various combinations to address the following scenarios:

Scenario 1: Generate sorted dictionary and index from data source

Given a list of word/definition pairs and a list of stopwords (as defined in project 1), generate a dictionary file with the words in alphabetical order followed by all definitions and an index file (again, as defined in project 1).

Scenario 2: Generate first instance definitions (excluding stopwords) from a body of text

Given a body of text, generate a list of definitions, with each word from the text (excluding stopwords) being defined once. The words in this list should be ordered by their first appearance in the text.

Scenario 3: Index lookup and definition display

Given a word, use the index generated in scenario 1 to find the words having that word in their definitions. Output these definitions to the console.

Hints

• Scenario 1 might be addressed more efficiently by using multiple output pipes. On Unix-based systems, this can be done with the pipe() and dup2() functions. However, taking the less complicated approach of independently initiated pipelines for generating the organized dictionary and index is sufficient.
• For this project, you are allowed to use standard OS components such as sort and grep (these are standard on Unix-based systems, but are available for other systems as well).
• On both Windows and Unix-based systems, the input redirection character ("<") can be used to make a filter take its input from a file. However, to clarify the pipeline structure, type (on Windows) or cat (on Unix) are often used to use a file's contents as input to the pipeline.
  • sort < file.txt | tail -5
  • cat file.txt | sort | tail -5
• You may specify files to be used as additional inputs by filters. For example, "cat wordlist.txt | searchdef dictionary.txt". The "searchdef" filter takes input on standard input (e.g., via cin) and from a file (dictionary.txt).

Additional Details

The system (particular combinations of filters) must:

• Generate only a single definition entry for words with multiple definitions, with definitions arranged in some reasonable order (such as the order in which they were input).
• Accept a list of "stopwords". These words should not appear in the index (as headwords) even if they appear in one or more definitions.
• Support input data in the format used in the sample files. Data may be saved in any format that is appropriate, however. The sample output files show how information should be displayed to the user.

Optional features

The CID application may also provide additional features, which will be considered for extra credit. Optional features may be proposed to the instructor.

Deliverables

Two reports are required for this project. Each report should be clearly identified with the team members, course number, and project name.

Project progress memo: design

This report should document your team's design work, including:

• Expanded project requirements description, including:
  • operational details: filters to be developed, data interchange formats, diagrams of filter connections that address the above scenarios (see Figure 5.3 on page 97 of the text for an example), etc.;
  • details of optional features that will be considered for inclusion;
  • remaining questions regarding the published (above) project requirements and specifications.
• Description of the software process that the team will use (at least equivalent to PSP2) and examples of the process reports that will be produced
• Description of the overall design and other significant features; incorporate the most relevant Rose diagrams into this section.
• Rational Rose model, including complete documentation of classes, operations, and attributes.
• Process data for project work to date
• A discussion of the benefits and disadvantages that you anticipate from using the pipe and filter style compared with the approach you took to project 1 in light of various quality attributes
• Other comments, questions, and suggestions

This report is due by 4 P.M. on Wednesday of week 5.

Final project report

This report should document your team's work on the entire project, including:

• Final Rational Rose model
• Final program source files (including MSVC project/workspace files or makefile)
• Final description of the overall design and other significant features. This report should be a stand-alone summary of all your work on the project that does not rely on references to the prior report.
• Final process data for all project work
• A discussion of the actual vs. anticipated benefits and disadvantages of the pipe and filter style. Consider various relevant quality attributes, both those that are readily evaluated and those that relate to how the system might be used and reused in the future
• Other comments, questions, and suggestions

This report is due by 4 P.M. on Friday of week 6.

Design Team Peer Evaluation

Upon completion of the project, each team member must complete the Design Team Peer Evaluation Form and turn it in by 4 P.M. on Monday of week 7. Either electronic or paper submission may be used.

Report submission

The contents of the various reports are outlined above. Please submit appropriate items electronically, with all components combined into a single .zip or .tgz file. If possible, use GhostScript (or Acrobat) to produce a combined PDF file containing the entire report, and include it in the submitted file.

When submitting program code, please include:

• Your project source code files (including MSVC project/workspace files or makefile)
• A (separate) single text file containing the source file content in some logical order (e.g., main program, primary objects, secondary objects), with each header (".h") file preceding the corresponding implementation (".cpp") file.

  Within the "concatenated" text file, each segment should be preceded by a separator containing the file name, in the following format ("<blank line>" means a real blank line, of course, and "xyz.h" is a file name):
  

  <blank line> >>>>> >>>>> xyz.h >>>>> <blank line>

  
  There should be a single space character preceding the file name, after the ">>>>>" prefix. Note that sequences of this form should not appear in the body of any of your submitted files.

Email the archive file to the instructor with a subject and message body indicating that this is your SE-380 Project 2 (Design or Final) submission. The email should include all team members' names.

Acknowledgment

The reporting requirements of this project are based on the work of Dr. Mark J. Sebern.

This page was last updated on Saturday, 25-Aug-2007 19:23:40 CDT.