Project 4


The goal of this project is to give you a chance to improve the Bible system, but this time by designing the system additions yourself. The ultimate goal will be to add a word search, much like the Shakespeare example. However, the underlying goal is to do this while following the best practices we have been learning in class.

Functional Specification

You user interface will now have two working options - lookup by reference, and search by word. When a search by word is selected, the user is presented with a field to enter the search word. When the lookup by reference is selected, they will see the current options (book, chapter verse, and number of verses). You should only show the input fields appropriate for the option selected. This is simple to achieve using JavaScript.

When the search by word is selected, the user will be able to enter a single word (can you enforce this?). Once the word is entered, and a search button pressed, the system will find ALL verses that contain this word. The list of matching verses will then be displayed. The user will then be able click on any of the verses to look it up in context, that is see the verse with the 5 preceeding, and 5 following verses (if they exist). In showing context the system will NOT cross book boundries, but will cross chapter boundries.

Project Phases

  1. Design Phase: The first step is to review the needed changes, and your existing code, and to then design exactly how the new functionality will be integrated into the system. The goal here to to produce a clean, reliable, mantainable system. This will include the following sub-steps:
    1. Produce a revised design for ALL the objects in the system. For each object, write up a new interface, including all parameters, and explanations on how each object method call will work.
    2. Produce a system architecture design. This is a drawing, and explanation of all the pieces of the system, and how they interact (what information flows, the format of the information, and where it flows).
    3. Include a writeup of the communication protocol between the client and the server.
      The output of this phase is a design document.
  2. Implementation Phase: In this step you actually make the changes to the system, and get it working. This includes testing. The output of this phase is a working system, and quality source code.
  3. Demonstration: Lastly you will demo the system for the entire class, and explain it's design and functionality

Due Dates

Work Due Date Due Points
Phase 1 - complete design proposal. To be presented in class, and turned into Moodle April 5 100
Phase 2 - Working system. Turn in link, and all source code into Moodle April 12 100
Demonstration - In class, with explanation of lessons learned, obstacles overcome. April 12 20
Topic revision: r2 - 2013-03-28 - JimSkon
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback