Computer Science 3331.03 Object Oriented Programming and Design
Assignment 2 (due November 8)
The purpose of this assignment is to give you some practice with using inheritance
and the base libraries in Eiffel. You will also have the opportunity to use class
STORABLE, which allows easy implementation of loading and saving of data.
This assignment will follow from Assignment 1; if you failed to do Assignment 1,
you will have a lot of work to do in order to do Assignment 2.
In Assignment 1, you implemented a small prototype for an on-line store. You
implemented functionality for customers to search for and buy a single type of product
(like CDs, DVDs, books, or videos). In this assignment, you will extend your
prototype in the following ways.
- The system should allow customers to search for and purchase any type
of product, i.e., CDs, DVDs, books, and videos. Appropriate information should
be maintained for each type of product. Keep the database reasonably small.
- In Assignment 1, you did not worry about quantity issues: you assumed
that a product was available whenever a customer wanted to purchase it. Now, you
should modify your system so that each product has an associated quantity in
stock (e.g., 30 copies of The Terrance and Phillip Movie). Each time a
customer purchases a copy of the product, its quantity is reduced by one. A purchase
cannot be made if sufficient quantity is not available in stock.
- Add a restock facility, which will allow you to add more of a particular product
to stock. You will want to make this consistent with the facilities you implemented
in Assignment 1 to add a product to the database.
- A (simple) WWW interface will be produced by allowing HTML to be generated
from a customer's order. The HTML should contain
Organize the HTML neatly, so that purchased products are in a table.
Here is an example of a table that you might generate for a customer's order..
- the name and customer number
- the products that have been ordered, and their price
|South Park vol 1
|Frank Sinatra Sings
You will have to implement several Eiffel classes in order to produce a complete
system. Each class will possess a number of exported and hidden features. For
each feature, you should provide contracts (i.e., require and ensure
clauses), where relevant.
Make sure that each class is a data abstraction.
Follow good object-oriented design practice.
Keep it simple! Do not add extra functionality.
A simple user interface that meets the
requirements is completely sufficient. We suggest that your user interface consists
of a simple menu with options.
The hand-in is identical to that for Assignment 1.
There are two components to your submission: a paper component that must be handed
in during class on the due date, and an electronic component.
You should hand in, on paper, your Eiffel source as well as the ACE file that you
used to compile and execute your system.
Your paper submission should have a cover page, listing the members of
your group (names and email addresses).
Do not hand in listings of any Eiffel library classes. We are only concerned with
the classes that you wrote yourselves.
Electronically submit (using the
submit command - see the WWW page) your ACE file and your Eiffel program, as well as
all your testing. Don't hand your testing in on paper; only the electronic version of testing will
be marked. The submit directory for this assignment is called
Your Eiffel program should be documented with internal comments and with a simple
user manual (a text file that describes how the software should be used).
Your user manual should make all options of your software clear.
You should test your system. You should do this by first testing each individual
class. This can be done by creating a simple test menu program that uses each class,
and feeds input (e.g., from the keyboard or a script) to the class. Once each class
has been tested, you should ensure that the entire system is tested.
Electronically submit your testing with your program.
A testing submission includes: a test
plan (i.e., the test cases you used to test system, including informal descriptions
of what each case is testing and expected results for each test case),
test output, and comparison
of actual vs. expected test results.
Documentation is worth 20%. Testing is worth 30%. Correctness is worth 30%. Style
is worth 20%.