Assignment
You are going to design, build, and test a scaled-down version of "Google Search". Rather than searching the Internet's files, you will only search local files added to your search engine's index. Your search engine will allow an administrator to add, update, and remove files from the index. Users will be able to enter search terms, and select between Boolean AND, OR, or PHRASE search. The matching file names (if any) are then displayed in a list.
You also need to design the system architecture (the high-level design), so you can plan each part.
You must kept your projects as simple as possible, with any "extras" saved for a later version (if any). Keep the user interface plain and simple. Time management will be critical for success: set milestones for your project, with due dates. (For example, milestone 1 might be the basic user interface, milestone 2 might be the administrators interface, and so on.)
Search Engine Project Proposal:
Build a search engine with simple GUI, that can do AND, OR, and PHRASE Boolean searches on a small set of text files. The user should be able to say the type of search to do, and enter some search terms. The results should be a list of file pathnames that match the search. This should be a stand-alone application.
User Interfaces
As long as it supports the requirements of the project, that is good enough. AWT is probably easiest, but feel free to use Swing or Oracle's instead (or a web-based user interface if you choose to try Java EE).
In addition to the main user interface (for doing searching), you will need a separate administrator or maintenance interface to manage your application. It should be easy to add and remove files (from the set of indexed files), and to regenerate the index anytime. When starting, your application should check if any of the files have been changed or deleted since the application last saved the index. If so, the administrator should be able to have the index updated with the modified file(s).
Note that with HTML, Word, or other types of documents, you would need to extract a plain text version before indexing. That isn't hard, but the search engine is complex enough already. For these projects, limit your search engine to only plain text files (including .txt, .html, and other text files).
The index must be stored on disk, so next time your application starts it can reload its data. The index, list of files, and other data, can be stored in one or more file(s) or in a database. The saved data should be read whenever your application starts. The saved data should be updated (or recreated) when you add, update, or remove documents from your set (of indexed documents), or perhaps just when your application exits. If you use files, the file formats are up to you; have a format that is fast and simple to load and store.
To keep things as simple as possible, in this project you can assume that only a small set of documents will be indexed, and thus the whole index can be kept in memory at once. (That's probably not the case for Google's data!) All you need to do is be able to read the index data from disk at startup into memory, and write it back either when updating the index, or when your application shuts down. Note, the names (pathnames) of the added files as well as their last modification time must be stored in addition to the index.
It is your choice to use a single file or multiple files, and to choose a format for those files (plain text, XML, JSON, or anything else). Or don't use files, and instead use a database to hold the persistent data. In any case, your file format(s) (or database schema) must be documented completely, so that someone else without access to your source code could use your file(s)/database.
If using XML file, you can define an XML schema for it and have some tool such as Notepad++ validate your file format for you. XML may have other benefits, but it isn't as simple as using plain text files. JSON might be the easist format for storing and reading the index data. In any case, don't forget to include the list of file pathnames and other data you decide is needed, along with the index itself.
Requirements:
Since everyone may have different IDEs, use a Maven project template for your code.
In this project, we will follow the model-view-controller design pattern for the project organization. This allows one to develop each part mostly independently from the other parts.
How your group is organized is up to the group members. Some suggestions include:
Develop Stub User Interfaces:
In this part of the project, you must implement a non-functional (that means looks good but doesn't do a thing) graphic user interface for the application. (The "view".) The main (default) user interface must support searching and displaying results. It should have various other features, such as an "About..." menu or button, a way to quit the application (if a stand-alone application; if you create a web application, there is no need to quit), and a way to get to the administrator/maintenance view.
The maintenance/administrator view must allow the user to perform various administration operations: view the list of indexed file names, adding files to the index, remove files from the index, and update the index (when files have been modified since they were indexed).
The user interface should be complete, but none of the functionality needs to be implemented at this time. You should implement stub methods for the functionality not yet implemented, and invoke them from your event handlers. The stub methods can either return "canned" (fake but realistic) data, or throw an OperationNotSupported exception. The only button that needs to do anything is the one used to switch to the maintenance view.
Since the user interfaces don't do anything, there is nothing to test yet. However, you must create a test class with at least one test method (it can just return success if you wish). I suggest you use JUnit 4 style tests for now.
In a real-world project, some additional features would be required. You would likely require someone to authenticate before allowing them to use the maintenance view. All such operations (and any errors) should be logged. Commonly used search terms should be remembered to provide business intelligence. The code should be instrumented to allow measurement and reporting of performance. The application might need to support multiple languages. All the code would need auditing for security, license compliance, possibly ISO 9000 compliance, and quality assurance. Finally, a way to deploy the code and to provide updates and other support should be planned and implemented.
Hints:
Keep your code simple. You can always add features later, time permitting. If you start with a complex, hard-to-implement design, you may run out of time.
(The style recommended above is known as decomposition by structure. In many cases, a better approach is to make one package for each major feature of your application, each containing all the classes related to that feature, so each package gets model, view, and controller classes. For our project, making classes by structure might be simpler for you.)
Keep in mind the requirements for the remaining parts of these projects, as that will affect what is needed in your user interface and code skeleton.