SFDV2004 - Application Software Development Project Specication

Introduction
The project that you will be working on in this course is an online shopping system. In part 1 you will be creating the administration part of the system that allows the shop staff to add new categories and products to the system. In part 2 you will be creating the web based user interface that the customers will use to purchase products from the shop. You will be working on the project throughout the entire course. Each week there will be a project task that is related to the topic covered in the lab that week. By completing each project task each week you will eventually end up with a complete project. We strongly recommend that you keep on top of the project tasks and dont fall behind. This is not a trivial project, and you will not be able to leave it until the last minute and complete it.

1
1.1

Phase 1
Requirements Analysis

The requirements analysis identied eight use cases that need to be implemented in this phase of the project: Add a new category. Viewing all categories. Deleting an existing category. Editing the details of an existing category. Add a new product and associating it with an existing category. Viewing all products. Deleting an existing product. Editing the details of an existing product. 1

1.2

System Analysis

We have already performed the analysis and design phase of the development. The following is some of the design documentation that describes the system. Prototype of the GUI The following are screenshots of the high delity prototype:

The Main Menu. This could be a button based menu (as shown) or a standard pull down menu with the companys logo in the centre of the frame.

The category editor.

Finding existing categories. This frame is shown when the staff member clicks the Find button in the Category Editor.

Deleting a category. This is shown when a staff member selects a category and clicks the Delete button.

Editing an existing category. This is shown when the staff member selects a category and clicks the Edit button. The selected category will be loaded into the Category Editor frame so that its details can be edited.

The product editor. Categories that are in the system are displayed in a drop down list (JComboBox). The staff member chooses the category that the product they are entering belongs to.

Finding existing products. This frame is shown when the staff member clicks the Find button in the Product Editor.

Deleting a product. This is shown when a staff member selects a product and clicks the Delete button. 4

Editing an existing product. This is shown when the staff member selects a product and clicks the Edit button. The selected category will be loaded into the Product Editor frame so that its details can be edited. NOTE: The nal implementation of this system doesnt have to be identical to these screen shots, but should have similar functionality. System Architecture The system should be separated into four packages: The domain package that contains the classes relating to the object-oriented domain model of the business (see the section 1.2 for details about the domain model). The GUI package that contains the user interface classes for the staff administration GUI. The user interface classes should be created using Swing. The data access package that contains the classes that are responsible for storing and nding and otherwise managing the domain objects (products, categories, etc.) that have been entered into the system. The data persistence will be implemented via a framework called Hibernate (http://hibernate.org) using the EJB (Enterprise Java Beans) standard. The web package that will contain the classes associated with the web based user interface that will be created in the second phase of this project. The architecture for this system is a logical 3-tier system (as opposed to a physical 3-tier system where each tier is separated by a network):

Presentation Tier gui Swing GUI interacts with Presentation Tier web Web GUI

Business Tier domain Domain Objects

Persistence Tier

Business Tier dataaccess interacts with Data Access

Persistence Tier

Database

The 3 tiers. The presentation tier provides the user interfaces, the business tier provides the domain objects and the classes that manage them (the data access objects), and the persistent storage tier which in the case of this project is a database provided by a DBMS called H2 (http://h2database.com/). Using this architecture gives us better control over the dependencies between the different packages:
domain Domain Objects creates / displays gui Swing GUI uses dataaccess Data Access uses creates/displays web manages Web GUI

The dependencies between the packages.

Object-Oriented Domain Model

persistent 1 category 0..* products

persistent

Category
name description

Product
id name description price quantity available 1 product

persistent

Order
date

1 order

persistent 1 customer persistent 0..* items

OrderItem
quantity purchased 0..* items

Customer
name address credit card details username password

ShoppingCart

Class Diagram of Domain Model Product - Contains information about a product that is offered for sale at the shop. Category - Used to group related or similar products to make it easier for customers to nd a particular product. Customer - Contains the account details for a customer of the shop. Order - Contains information about a single transaction made at the shop. OrderItem - Represents how much of a single product was purchased in an order. ShoppingCart - Used to keep track of which products a customer has selected while they are browsing the web site. Once the customer is nished browsing they will check out the shopping cart which will create an order using the contents of the shopping cart. Product, Category, Order, OrderItem, and Customer objects will all be stored in the database. ShoppingCart objects are only temporary, so are not going to be stored. 7

1.3

Unit Testing Plan

Ideally the entire system should be unit tested as it is developed, but due to time constraints we will just write unit tests that ensure the eight use cases are implemented correctly. All testing should be done using JUnit inside of Eclipse. There should be eight individual test methods one for each use case. The add product/category unit tests should: Create an instance of the relevant frame. Simulate the user entering data into the text elds and combo boxes data by using the setText and setSelectedItem methods. Simulate the user clicking the relevant button by calling the buttons event handler method. Check if the object exists in the database (via a query in the relevant data access class). This could be done using a getByProductId or getByCategoryName method in the relevant DA. You may need to make the getter and button handler methods for the GUI components public so that you can access them from your test code. The view products/categories unit tests should: Add some dummy categories/products via the relevant DA class for testing. Create an instance of the relevant frame. Get a reference to the JList on the frame (you will probably need to make the getter for the JList public) and check if your test categories/objects are inside the JList as follows:
DefaultComboBoxModel model = (DefaultComboBoxModel)jList.getModel(); int index = model.getIndexOf(category);

If the returned index is a positive number then the object exists in the JList. The delete product/category unit tests should: Add a dummy category or product for testing. Show the relevant frame that displays the objects to delete. Calls setSelectedValue on the JList to select one of the dummy objects to simulate the user selecting the object. Simulate the user clicking the delete button by calling the handler method for the delete button. Check that the object does NOT exist in the database using the getProductById or getCategoryByName methods in the relevant DA class. If you are using the AbstractDA that we gave you then you will get a DataAccessException if the query didnt nd any results. 8

 The edit product/category unit tests should: Add a dummy category/product to test with. Perform whatever user interface actions that will result on the category/product being displayed in the relevant edit frame. Change the value of some of the text elds to simulate the user editing the object. Simulate the user clicking the save button by calling the relevant handler method. Get the object from the database again via the relevant DA method and check the the values in that object have been updated to the new values. You should make sure that any objects that your tests have added are also deleted again to prevent them from causing constraint violations when other tests run. You can either do this at the end of each test, or use the tearDown method.

1.4

Phase 1 Requirements

For this version of the system you are required to: 1. Create all of the domain classes shown in section 1.2. 2. Create data access classes for the product and category domain objects. 3. Create GUIs that allow the user to perform the eight use cases described in section 1.1. 4. Use Hibernate for storing product and category objects in the database and for performing all persistence related operations. 5. Create unit tests for the eight use cases described in section 1.1.

Phase 2

In this phase you are adding a dynamic web site to the system that will allow your customers to browse and purchase the products that have been entered into the database. You will be using a web framework called Wicket to do this.

2.1

Use cases for the web site:

A new customer should be able to create a new account. The customers details (as shown in the class diagram in section 1.2) should be stored in the database. An existing customer (one who has already created an account) needs to be able to login using the usercode and password that they entered when they created their account. 9

 The customer needs to be able to view all of the categories that have been stored in the database, and select one for viewing. Once the customer has selected a category all products in that category should be displayed, and the customer can select one of them to purchase. Once the customer has selected a product all of its details should be displayed, and the customer should be able to enter the quantity of this product that they want to purchase, and add the product to the shopping cart. The customer needs to be able to view the contents of the shopping cart including the total cost. The customer needs to be able to check out the shopping cart. This will cause an order object to be created and added to the database. The quantity on hand values in the products that were purchased should be decremented by the amount that the user purchased. The shopping cart object should be cleared out once the transaction is complete in case the user wants to carry on shopping. Finally the customer needs to be able to log out. This should clear any session data that was associated with this customer. After logging in the user should always be able to see links that will take them to the categories page, the shopping cart view, or the logout page. All dynamic web pages should be controlled by Wicket. Add database access should be done via Hibernate.

10