Software Architectures and Design

Assignment 2 - Object Design

Holiday Travel Vehicles: Sales Information System

Semester 1, 2017

Group:

Hugh Rutland - 9989951

Raghav Kumar - 100675424

Daniel O’Brien - 9509208

Tutor/Lecturer:

Mandeep Dhindsa

Introduction

Problem Analysis

Assumptions

Simplifications

Candidate Classes

Class List

UML Class Diagram

Justification

CRC Cards

1. Controller

2. Interface

3. Person

3.1. Customer

3.2. Employee

3.3. Manager

4. Vehicle

4.1. NewVehicle

4.2. TradeIn

5. Option

6. Invoice

6.1. SalesInvoice

6.2. TaxInvoice

7. Payment

8. Report

9. Login

Quality of Design Solution

Design Patterns

Heuristics

Boot-strap Process

Verification

Usage Scenarios

1. Add new vehicle to database

2. Customer pays for vehicle

3. Employee logs into system

4. Sales invoice created

Appendix

Removed Candidate Class CRC cards

This project document shows the Object Design for the Sales Information System being created for HTV to replace their current outdated system.

It is a continuation of the previous project document which went into detail about the background of the previous system used by HTV as well as the requirements and possible implementation of the new system we are creating.

The purpose of this document is to use the requirements and tasks we created in the previous document to create a design for an object oriented solution for the new system. This will be done by creating a list of classes and showing their overall relationships to each other with a UML class diagram. Each of the identified classes will be shown using a CRC card that will provide further details such as a brief overview of the class, its responsibilities and collaborators. The quality of the solution will be shown by demonstrating that all responsibilities outlined in the previous project document have been covered, they are distributed mostly evenly throughout the classes and design heuristics and patterns are clearly listed.

There will also be verification of our solution via four usage scenarios using our solution illustrated via UML sequence diagrams.

• Sale price negotiated by salesperson

• Payment handled by external system (3rd-party payment gateway)

• Partial Payments are allowed

• Customer might be an existing customer

• A travel trailer is treated the same as a travel vehicle

• Any hardware requirements will be managed at a later date

• An empty SQL database with appropriate privileges has already been setup for the software to interact with.

• We (Swinsoft) have strict user interface and design guidelines that applied to all clients, Holiday Travel Vehicles being no exception. These guidelines are externally documented.

• Vehicle options are pre-installed in vehicles, customer can select from options that are available and already installed in vehicle.

• Any methods, calls or APIs relating to the user interface will be later implemented and not included in this design although references may be made.

• Payment system is handled externally and only references to the system are made

• Controller

• Interface

• Person

  • Customer

  • Employee

  • Manager

• Vehicle

  • New

  • Trade-in

• Options

• Invoice

  • Sales Invoice

  • Tax Invoice

• Payment

• Reports

• Administration

• Login

(see next page)

UML Diagram here (PDF)

For our design we decided to have our classes as separated as possible to make future expansion of the system as easy as possible as well as implementing separation of concerns which would be advantageous for multiple people working on the project at once. For example if specialised UI designers wanted to work on that while leaving the rest of the base code intact.

Controller is the main logic behind the system. It is the class that directly interfaces with the database system that all information is stored on. Having it as a separate file means it can do all the checking, creating of tables and queries of SQL meaning if it was changed from one database language to another it would be very easy to change over the whole code base without having to dig into each class to search for possible queries or database code.

Interface is the class that takes information from the GUI and also handles values coming in that need to be sent to the GUI. Having the interface handled by one class once again allows the system to be scaled and expanded as necessary while also allows changes to the GUI that don’t affect the rest of the code. It also allows error checking to be handled by each respective class where needed.

Person and its subclasses are quite self explanatory. They model a ‘person’ which means all the data relating to a person that would be needed in the system. Person was created as an abstract class as there are a large amount of variables shared between all the people that would be used in the system. The subclasses contain extra variables used for their respective types such as a login/password for the manager and employee that would not be needed for the customers. They also contain some specific methods that would just be used by that type of person within the system dependant on privileges such as a managers being able to add new employees and employees being able to add new vehicles.

In our initial design we had another class called Administrator that handled the specific admin tasks the manager could do but we decided to merge this task with Manager while creating the UML diagram as there was no need to separate the tasks when Manager was the only one that would access them.

Much like Person, Vehicle models the vehicles within the system and manage all data relating to the vehicles. The sub class TradeIn adds a couple of extra variables only relevant to trade in vehicles and the rest of the variables used in the subclasses are shared with the Person superclass.

The vehicles can also have options installed by HTV. The options are modeled by the Option class and then stored in a list in the Invoice class if they are installed.

The Invoice class is another abstract class like Person and Vehicle as there are two invoices used in our system - SalesInvoice which is what is initially filled out upon a customer deciding to purchase a vehicle and TaxInvoice which acts like a receipt that will be sent upon successful full payment of the vehicle. Both will show all the information from the Invoice super class on their invoices which is why it was much more efficient to make them subclasses.

Payment handles the payment information used on the invoices. It is a separate class as it is used with both types of invoice and it also interfaces with an external payment system. It checks the SalesInvoice is valid and will record all payment information such as payment type, date of payment and amount of payment which is used by TaxInvoice to confirm the payment was made both within 30 days and a full payment has been made so the tax invoice can be sent to the customer.

The Report class handles all data involved with creating reports and then the Controller class will turn the data provided into queries to check the database. This was separated as a way to expand in the future by adding various other types of reports.

Finally, the Login class will validate the login details sent from both the Manager and Employee classes to confirm they are logging in with the correct information. This adds a layer of security and further checks can be added to this class in the future including validation to check if passwords contain any unwanted characters.

1. Controller

This class acts as the back-end logic behind the system. It is where the system starts running and where all the logic behind the system such as checking the connection to the database, checking the tables, and all SQL processing takes place.

Controller collaborates with many of the classes that contain data so that when new data is stored in the system it is saved to the database, this improves the reliability of the system by saving the data to non-volatile memory as soon as possible.

1. Interface

This class acts as an interface between the logic components of the system and the user interface (UI). It is responsible for passing all the user input data from the UI to the relevant classes, as well as presenting any returned data to the UI. The Interface class does not do any input validation, this is the responsibility of both the UI and logic components. This allows the validation to be modular, each individual class can validate its own data and the UI can validate common errors such as formatting and data type.

1. Person

Person is an abstract class. The system currently has three kinds of people: Customer, Employee and Manager. All share a number of common attributes and functions. The Person class is important to abstract the commonalities from these two classes as well as allowing the design to be easily expanded to include other types of people.

1. Customer

Customer overrides the update record responsibility to allow employees to change customer records.

1. Employee

Login details are stored for employees and managers as a security measure. These details are a username and password. Note that passwords will be stored as a one way hash to ensure passwords always remain secret.

1. Manager

1. Vehicle

Vehicle is an abstract class. HTV currently can group their vehicles into two groups new and trade-in vehicles.

1. NewVehicle

NewVehicle does not have any additional responsibilities to Vehicle but is required as its own class since Vehicle is an abstract class and cannot be instantiated.

1. TradeIn

TradeIn will store extra information that is specific to trade in vehicles such as the ID of the customer that owned the vehicle, the date it was traded in and the value of the trade in vehicle.

1. Option

The Option class models an option that can be installed by the dealer (HTV) to a vehicle, it includes all the details about the option; code, description, price. Options can then be listed on a vehicle by making reference to this class, as well as invoices showing the options installed on that particular vehicle.

1. Invoice

The Invoice class is an abstract class. The system uses two different invoices for before payment is received (SalesInvoice) and after payment is received (TaxInvoice). The sales invoice will check if the vehicle selected is available or not because payment can take up to 30 days. The tax invoice is sent after receiving the payment and will rely on the external payment system to inform our system that the payment has been made.

When the invoice is generated a copy of all the information is captured; that is if some details change after generating the invoice the invoice does not change unless a manager updates it or an employee generating a new invoice to replace it. This is important so that the business can keep an accurate record of past transactions.

1. SalesInvoice

SalesInvoice adds the ability to determine if the vehicle is available for sale, that is it is not already on another sales invoice. This is important as sold vehicles may not be fully paid for and still be in the yard. A sold status flag is set in the Vehicle record rather than querying the SalesInvoice database for every new sale to improve efficiency.

1. TaxInvoice

1. Payment

Payment receives and records the payment or partial payments made by the customer, the information is received from the third-party payment gateway. It confirms the payment is for a valid SalesInvoice and then if so returns the data to Controller to be saved in the SQL database and also TaxInvoice. It is then TaxInvoice’s responsibility to decide if full payment has been made and within the required timespan.

1. Report

This class is responsible for the reports that are generated to show how sales have been over a specific period. The report can be selected to show all sales over a certain period or just sales by specific employees to track employee progress. The data is selected here and then turned into an SQL query in Controller to return the appropriate information from the database. The report is then saved to the database via the Controller to ensure accurate historical records.

Further reports could be generated using TaxInvoice and payments but as the requirements only specify basic sales reports this would be an extension that could later be added to this class.

1. Login

Login will handle the backend for the login system. Passwords and usernames will be checked to ensure they are correct and any errors found will be returned to the user via Login. Since not all users (employees and managers) will be loaded into memory at any one time the login class must collaborate with the Controller to query the database.

Factory Method

The factory method design pattern was used throughout the design. That is base classes are used to define common behavior and delegate to subclasses to implement the details. This lets us build in specialisations and leave room for future expansion with little extra complication, The pattern can be seen in use with the Person, Vehicle and Invoice base classes and their subclasses Customer, Employee, Manager, NewVehicle, Tradein, TaxInvoice and SalesInvoice.

Observer + Layer

The observer + layer design pattern is making use of layers to separate concerns and using state based actions to communicate between methods. As discussed in the justification sections the HTV Sales Information System design implements separate classes (layers) to interface with the GUI and database. The methods of those classes only get called on events occurring or states changing.

1. A class should capture one and only one key abstraction

2. Keep related data and behaviour in one place - the data about the piece and movement behaviour is stored in each piece class.

3. Inheritance should be used only to model a specialization hierarchy. This is applied in a number of places, Person, Vehicle and Invoice.

4. All base classes should be abstract classes . Person, Vehicle and Invoice are all abstract, hence the creation of NewVehicle which has no additional functionality

Boot-strap Process

1. Program starts with Controller class

2. Controller logs in to database server and checks presence of database

3. Controller creates tables in database (if no tables)

4. Controller starts Interface class

5. Interface class displays main UI

6. Interface awaits user interaction

1. Add new vehicle to database

2. Receive payment for vehicle

3. Employee logs into system

4. Sales invoice created

Diagram 1 here (PDF)

Diagram 2 here (PDF)

Diagram 3 here (PDF)

Diagram 4 here (PDF)

The following section contains the CRC cards that were developed for candidate classes that have now been removed in the current design. A justification on why they were removed has been provided as well as retaining the original justification for the class.

The administration class was removed as it was determined that it really only represented a screen the user will be presented with on the GUI, it itself is not a role, manager is the role has the responsibility of administrator.

Administration is responsible for creating employees and having overarching control to update or delete other records. It even has the ability to add and delete employee during runtime. When employee details are added and deleted then the appropriate information must be added and deleted from person.