Sales Information System

Assignment 2 – Object Design

Holiday Travel Vehicles: Sales Information System

Semester 1, 2017

Group:

Hugh Rutland – 9989951

Raghav Kumar – 100675424

Daniel O’Brien – 9509208

Introduction

Sales Information SystemThis 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.

Problem Analysis 

Assumptions

  • 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.

Simplifications

  • 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

Candidate Classes

Class List

  • Controller
  • Interface
  • Person
    • Customer
    • Employee
    • Manager
  • Vehicle
    • New
    • Trade-in
  • Options
  • Invoice
    • Sales Invoice
    • Tax Invoice
  • Payment
  • Reports
  • Administration
  • Login

UML Class Diagram

(see next page)

UML Diagram here (PDF)

Justification

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 Sales Information Systemlogin/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 sub classes.

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.

CRC Cards

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.

2.    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.

Class: Interface
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Read user data passed in from user interface and call relevant classInterface
CustomerEmployee
OptionsNewVehicleTradeIn
SalesInvoice
TaxInvoice
Administration
Return output data to be displayed on the user interfaceInterface
CustomerEmployee
OptionsNewVehicleTradeIn
SalesInvoice
TaxInvoice
Administration

Payment

3.    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.

Class: Person
Sub Class(es): Customer, Employee, ManagerSuper Class(es): n/a
Responsibilities Collaborators
Store name, ID, address, phone number, emailInterface, Controller
Update recordAdministration, Controller
Check for duplicateController
Sign invoiceSalesInvoice
  • Customer

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

Class: Customer
Sub Class(es): n/aSuper Class(es): Person
Responsibilities Collaborators
Update recordInterface, Controller
Store date of birth, license type/sInterface, Controller
  • 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.

Class: Employee
Sub Class(es): n/aSuper Class(es): Person
Responsibilities Collaborators
Store login detailsController
Check login detailsInterface
Create vehicleInterface, NewVehicle, TradeIn, Controller
Create optionInterface, Option
Edit or delete optionInterface, Option
Create sales invoiceInterface, SalesInvoice
  • Manager
Class: Manager
Sub Class(es): n/aSuper Class(es): Person
Responsibilities Collaborators
Store login detailsController
Check login detailsInterface
Create new employee/managerController

4.    Vehicle

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

Class: Vehicle
Sub Class(es): NewVehicle, TradeInSuper Class(es): n/a
Responsibilities Collaborators
Store Vehicle ID, serial number, model, year, manufacturer, base cost, registration detailsEmployee, Controller
Assign options to vehicleOption
Check for duplicate
Store sold statusSalesInvoice, Controller
Update sold statusSalesInvoice, Controller
  • 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.

Class: NewVehicle
Sub Class(es): n/aSuper Class(es): Vehicle
Responsibilities Collaborators
  • 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.

Class: TradeIn
Sub Class(es): n/aSuper Class(es): Vehicle
Responsibilities Collaborators
Store Trade-in customer ID, trade-in date, trade-in allowanceEmployee, Controller

 

5.    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.

Class: Option
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Store OptionID, option code, description, priceEmployee, Controller
Define dealer-installed-option attributesVehicle

6.    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.

Class: Invoice
Sub Class(es): SalesInvoice, TaxInvoiceSuper Class(es): n/a
Responsibilities Collaborators
Store invoice no, customer ID, salesperson ID, vehicle ID, sale date, options on selected vehicle, options cost, total cost, trade-in infoCustomer, Employee, NewVehicle, TradeIn, Payment, Option
Show (generate) invoiceInterface
  • 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.

Class: SalesInvoice
Sub Class(es): n/aSuper Class(es): Invoice
Responsibilities Collaborators
Check if vehicle is available for saleNewVehicle, TradeIn
Set vehicle sold statusNewVehicle, TradeIn
  • TaxInvoice
Class: TaxInvoice
Sub Class(es): n/aSuper Class(es): Invoice
Responsibilities Collaborators
Create Tax InvoiceSalesInvoice
Check payment after 30 days of sale dataPayment
Listen/wait for paymentsPayment
Check if full payment has been madePayment

7.    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.

Class: Payment
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Poll external payment service for new payments and update recordsController, TaxInvoice
Stores payment type, date of payment, amount and the invoice numberSalesInvoice
Check payment is for a valid SalesInvoiceSalesInvoice

8.    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.

Class: Report
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Store details of the report; report number, report date, startDate, endDate, total sales, vehicles sold, employeesEmployee, Vehicle, SalesInvoice, Controller, Interface
Generate sales statistics reportSalesInvoice, Controller, Interface
Generate employee sales statistics reportEmployee, SalesInvoice, Controller, Interface

9.    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.

Class: Login
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Login using employee idEmployee, Controller

Quality of Design Solution

Design Patterns

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.

Heuristics

  1. A class should capture one and only one key abstraction
  • . 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

Verification

Usage Scenarios (UML Sequence diagrams)

  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)

Appendix

Removed Candidate Class CRC Cards

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.

Administration

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.

Class: Administration
Sub Class(es): n/aSuper Class(es): n/a
Responsibilities Collaborators
Create employees or managersInterface, Employee, Manager
Edit recordsInterface

Customer

Employee
Options

NewVehicle

TradeIn
SalesInvoice
TaxInvoice

Payment

Delete recordsController

Interface

Customer

Employee
Options

NewVehicle

TradeIn
SalesInvoice
TaxInvoice

Payment

Don’t forget to check constancy of classes and since we’ve changed at few

Need to implement at least one heuristic or design pattern MINIMUM

some broad heuristics (from the LE slides)

some broad heuristics (from the LE slides)

some broad heuristics (from the LE slides)

Should be checked and expanded upon completion of UML diagram

Include short description alongside diagram

Being worked on

done

trying this one as it’s got less user input (want to see what both styles of sequence diagram are like)

done

David Marks

Dear sir/Ma'am

Our dedication and hard work towards developing quality content has made us competent to provide excellent services to the clients as per their needs. We ensure plagiarism free writing obeying academic integrity and honesty making us a dedicated team towards developing original content helping students to ensure high grades. Our services are hassle free, timely yet at an affordable rate driving clients to avail it for a longer period of time making them loyal and satisfied towards us.

Services we offer:
Essay writing
Report writing
Assignment writing
Reflective writing
Proposal writing
Dissertation writing
Thesis writing
CDR writing
Annotated bibliography
PowerPoint presentation
Article/book review
Why us?
Plagiarism free original content
On-time services maintaining deadlines
Experienced writers
Plagiarism and Grammarly report
Dedicate Team Leaders and Quality Checkers
Subjects we cover:
Marketing management
Human resource management
Literature
Law
Finance
Accounts
Economics
Nursing
Sociology
Environmental science
Business studies
Political science
History
Journalism and Masscommunication
Geography

Declaration: Working with us will give you the opportunity to avail divergent range of academic services at affordable rates in assistance with the dedicated team having members from different disciplines holding high degrees in their respective domains. We are experienced in developing B-plan, writing dissertations and theses having employed highly qualified and experienced writers.

You can reach us at-
Email:- ozpaperhelp@gmail.com
https://www.ozpaperhelp.com/
https://www.cheapassignmenthelp.co.uk
https://www.freeassignmenthelp.com
https://cheapassignmenthelp.blogspot.com/
Thanks
Oz Paper Help

https://www.ozpaperhelp.com/
1 Step 1
GET INSTANT ASSIGNMENT HELP
keyboard_arrow_leftPrevious
Nextkeyboard_arrow_right