megamart managemant final document

CSC 4350 Spring 2015

MegaMart Management

Nick Birger Sam Brice

Hamza Jamil Jinsoo Kim

Chung Peng

1

Table of Contents: Introduction (topic description)

p. 2

Requirements Elicitation p. 2 Requirement Traceability Matrix

p. 9

Use cases p. 16 Sequence Diagrams p. 49 Category Interaction Diagram p. 66 Object Design p. 67 Test cases p. 68 Rationale

Topic Choice p. 70 Use Cases p. 71 Object Design p. 73 Test Cases p. 75

Cost Analysis Function Point Cost Analysis p. 76 COCOMO p. 77 Comparison and Conclusions p. 78

Prototype p. 79 Project Legacy p. 82 Work Schedule Diagram p. 83 Gantt Chart p. 84 Dictionary p. 85 Group Member Resumes

Sam Brice p. 86 Jinsoo Kim p. 87 Hamza Jamil p. 88 Nick Birger p. 89 Chung Peng p. 90

User Guide p. 91 Source Code p. 97

2

MegaMart Management System 1.0) Introduction:

MegaMart Management System(MMMS) is an application that will be used to manage a mega mart retail store. The store’s size will be similar to Wal-Mart’s in that it will have several departments, each with distinct employees, inventories and services to be monitored. Information will be stored on local, location-specific servers. Store’s inventory will be accessible by MMMS of other Mega Mart stores.

2.0) Departments:

The departments are: Grocery, Electronics, Sporting/Recreation, Clothing, Home/Office, and Management.

2.1) General:

There shall be 5 general departments. Each shall have one Manager and some General Employees.

2.2) Management:

There shall be 3 sub-departments.

2.2.1) Accounting:

This department shall manage payroll. It shall aggregate data from the transaction database to form reports for executives responsible for financial decisions. The pay rate shall be stored for all types of employees in a separate table.

3

2.2.2) Human Resources (People Management):

Employees shall be assigned positions based on Human Resources management department. The department shall contain max of 4 HR employees. Each store shall have a store manager, a Store supervisor, and a number of general employees (cashiers, baggers, greeters).The Human Resource department shall deal with management of employees including hiring, firing, and scheduling.

2.2.3) Customer Service:

The Customer Service department shall process returns. It shall open customer service cases. Customer service cases shall be dealt with externally by customer service employees.

3.0) Data:

All data accessed by the software shall be stored in a local, relational, store-specific database.

3.1) Employee:

Shall be a table of EMPLOYEES which contains first and middle initial, last name, age, social security number, address, banking information (billing address, account number, routing number), generated user-id, user-created password, and email. Clock-in, clock-out and total time worked shall be stored with the employee entry in the database as well. Employees will be able to send send messages to other employees.

Employee-ID shall be unique 8 digit decimal number that serves as a franchise wide identifier for the employee.

Username shall be a store-unique identifier, and shall be automatically

generated upon addition of employee to database. It shall be composed of first initial, last name, and the first available integer incrementing from one (all one word, all lower-case).

The total time worked field will be a running total of the total time

worked which is calculated based on their clock-in and clock-out values on a daily basis.

3.2) Inventory:

4

Shall store each item’s UPC, name, department, quantity on hand, target quantity, wholesale price per unit and sale price per unit. Each inventory data request. A barcode can be scanned by a Barcode Scanner, the item’s UPC shall be sent to the system as an alpha-numeric string. The ordering of inventory supply shall not be done though this software, but rather an external system.

3.3) Transaction:

Shall be composed of a unique transaction-id which shall be an 12 digit positive integer made up of 4 digits for year, 2 digits month, 2 digits for day, and a 4 digit number to be incremented with each transaction added to the database (to be reset daily), products’ UPC, quantity(purchase or return). All transactions shall be immediately stored in a queue which shall be processed every five minutes, updating the inventory based on the transaction’s type(purchase or return). Each transaction shall be stored in its respective table (purchase or return). Type shall be 0 for purchase and 1 for return and stored in a queue which is processed every 5 minutes , derived total

4.0) User Interface (UI):

The user interface will be intuitive and easy to navigate, as well as efficiently laid out to accomplish tasks quickly.

4.1) General Layout Description:

The software’s interface shall be organized based on department. There shall be a department selection drop-down menu, in which a user will select the department they wish to access. Each department’s interface shall allow the user to intuitively access all necessary functions applicable to that department. 4.1.1) General Department Interface:

General departments shall share a similar interface. This interface shall allow the user to access and view all of the inventory associated with that department. This view of inventory will be intuitively laid out to show what is in stock, the price of the item, and when any out of stock item is expected to be available. The list of inventory items can be sorted by name, UPC, quantity in stock. The user will be able to search for a specific item by name or UPC. General department interfaces shall also allow users to view the staff of that department and send messages/notifications to the management within that department.

5

4.1.2) Management:

The interface for the management department shall be broken down into 3 sub-pages/interfaces each representing one of the sub-departments described in section 2.2. Accounting:

This page shall allow the user to generate reports based on transactions. Accounting employees shall be able to view the hours worked by each employee, and calculate the amount to pay them. All the payroll information shall be pushed out to a file where the information, including banking information and amounts for each employee, is parsed by an external system to print checks or be sent electronically. Employee total hours worked shall be reset after each paycheck is sent out. Payroll shall be processed and sent out every 2 weeks.

Human Resources:

This page shall allow the user to manage all employee positions. There shall be the option to view all employees in a list and sort them by various attributes. The user shall be able to add or remove an employee from the database through the Human Resources interface as well. When adding an employee a popup window will appear with all the relevant fields. This page will have the option to display the employee work schedule, which will be generated externally by a Human Resources employee. This schedule will be visible to all employees regardless of position within the store. A Human Resources employee shall be able to manually reset and modify the clock-in, clock-out and total hours worked fields in an employee record.

Customer Service:

This page shall allow the user to search for search past transactions over the past 30 days, to create a new customer service case, to access old/open customer service cases. To process returns the user shall select a past transaction to reverse and a new transaction will be created.

4.2) Privileges / Restrictions:

Upon accessing the software the user shall be required to enter their login information, i.e. their username and password. After entering valid login information the user shall be signed in and have access to pages that they

6

have the privilege to view or interact with. The privileges are as follows: Store Manager:

The store manager shall have access to all functionality offered by the software, they can assign employees to all positions within the store.

Store Supervisor: The store supervisor shall have access to all functionality offered by the software, they can assign employees to all positions below their own.

Management: Managers shall have access to all functionality within their assigned department, and have limited access to functionality within the management department. They have no administrative privledges.

General Employee: General employees shall only have basic access to the software. They shall be able to view inventory, send messages/notifications to managers, and modify basic information about themselves. If an employee is assigned to a more specific job, such as customer service, they shall have access to the functionality associated with that job. All general employees shall access their employee page and clock-in when they begin work, and clock out when they leave.

A user shall have the option to sign out when they have completed their use of the software, if they let the system sit idle for 10 minutes they shall automatically be signed out.

4.3) Notifications / Messages:

Every 30 minutes the inventory shall be checked for low levels of stock. If an item’s stock level in inventory is below 30% of the desired stock level (target stock level), a warning message shall be sent to the managers. The listing for a low stock item will appear red in the inventory list. Users will be able to manually flag an item if it has less than 30% stock. Employees shall be able to send messages to managers within their own department, managers shall be able to view these messages. When an employee sends a message it shall also send their name, employee ID, and the date sent, to the manager message inbox. There shall be a popup notification when a user has been inactive for 9 minutes, if the user does not interact with this popup by clicking its button the system shall

7

assume the user is still in active and proceed to log the user out at the 10 minute mark.

4.4) Errors / Exception Handling:

If the user should enter invalid information in the login entry fields, the program shall return “ You have entered an invalid username/password.” When a user clocks-in it the system shall store the time in the clock-in field of their employee record, and when they clock-out the time is stored in the clock-out field. The time worked is calculated and added to total time worked. The values for clock-in and clock-out are cleared after a full cycle of clock-in and clock-out occur. If the user does not clock-out at the end of the day, and tries to clock-in on the next day, an error will be displayed, and they will be prompted to contact a manager/Human Resource employee. If the user enter invalid data entry, such as: invalid SSN, address, and banking information, the program shall return, “Invalid (SSN, Address, and Banking information)”. The program shall display a message, “No data found”, if there are no datas in the table requested.

5.0) Backup:

Every day at 11:59pm the new transactions for that day shall be appended to a log file, which acts as a backup of transactions. At the same time transactions older than 30 days will be removed from the database. Every 7 days, the other data in the database will be backed up to log files, this includes employees, messages, inventory, etc... All views of the database content will have the option to export the visible data to a log file. The software will allow the importing of log files to be parsed and replace or append to the current data in the database.

6.0) Administration:

The store manager shall have the ability to access all of the program. The store managers login shall have root access to the software, thus have the privileges to access the administrative functions of the software. A System Administrator has this access as well. The administrative functions shall include:

8

Manual backup of databases: Databases can be manually backed up, by duplicating the .sqlite file and renaming for backup.

Manual restoration of databases: The database backup file can be restored to act as the current database.

Modify the network paths to database servers: Shall Have the ability to modify the paths to access the local database and any relevant files.

9

Requirement Traceability Matrix:

Entry# Para # System Specification Text Type Build Use Case Name Category

1 2.1 There shall be 5 general departments

SWC

2 2.1 Each department shall have 1 manager and some general

employees

SWC

3 2.2 Management shall have 3 subdepartments

SWC

4 2.2.1 Accounting shall manage payroll SW

5 2.2.1 Accounting shall aggregate data from the transaction database to

form reports

SW 1.0 UC05_Create_Finacial_Report Interface Controller

6 2.2.1 The pay rate shall be stored for all types of employees in a separate

table.

SW

7 2.2.2 Employees shall be assigned positions based on Human

Resources management department

SW 1.0 UC07_Assign_Employee_Position

Interface Controller

8 2.2.2 The HR department shall contain max of 4 HR employees

SWC

9 2.2.2 Each store shall have a store manager, a Store supervisor, and a

number of general employees (cashiers, baggers, greeters)

SWC 1.0 UC09_Add_Employee, UC10_Remove_Employee


10 2.2.2 The Human Resource department shall deal with management of

employees including hiring, firing, and scheduling.

SW

UC09, UC10

11 2.2.3 Customer Service shall open customer service cases.

SW 1.0 UC11_Create_Customer_Service_Case UC12_Load_Customer_Service_Case

Interface Controller Database

12 2.2.3 The Customer Service department shall process returns.

SW UC27

13 2.2.3 Customer service cases shall be dealt with externally by customer

service employees.

1.0

UC13_Remove_Customer_Service_Case Interface Controller

14 3.0 All data shall be stored in a local and storespecific database

SWC, HW

15 3.1 Employee table shall contain first name, middle initial, last name, age, SSN, address, banking

information, generated userid, usercreated password, and email.

SWC

10

16 3.1 Clockin, clockout and total time worked shall be stored with the employee entry in the database

SW,SWC

17 3.1 Employees will be able to send schedule requests to management

SW

18 3.1 The total number of personal days and personal days already taken shall be stored in separate fields in

an employee record.

SW

19 3.1 EmployeeID shall be unique 8 digit decimal number that serves as a franchise wide identifier for the

employee.

SW

20 3.1 Username shall be generated with first initial, last name, and the first

available integer.

SW

21 3.1 The total time will be calculated based on Clockin and Clockout

values on daily basis

SW 1.0 UC21_Clock_In, UC22_Clock_Out Interface

Controller

22 3.2 A barcode can be scanned by a Barcode Scanner, the item’s UPC shall be sent to the system as an

alphanumeric string.

SW, HW

23 3.2 Inventory table shall store item's UPC, name, department, quantity on hand, target quantity, wholesale price per unit, and sale price per

unit.

SW 1.0 UC23_Add_Inventory_Item, UC24_Remove_Inventory_Item, UC25_Modify_Inventory_Item


24 3.2 The ordering of inventory supply shall not be done though this

software

SWC

25 3.3 Transaction table shall store unique transaction ID, product's UPC, product's price and product's

quanitity.

SW

UC27

26 3.3 Transaction ID shall be unique 12 digit ID, which is composed of year, months, days, and 4 digit number

that increments with each transaction.

SWC

27 3.3 All transaction shall be immediately stored in queue to update inventory depending on purchase or return.

SW 1.0 UC27_Create_Transaction Interface Controller

28 3.3 The transaction queue shall be processed every 5 minutes.

SW, SWC

1.0 UC28_Process_Transaction_Queue Object Classes

29 3.3 The purchase and return shall be differentiated by number type. (0

being purchase and 1 being return)

SW, SWC

UC27

30 4.0 The user interface will be intuituve and easy to navigate, as well as

SWC

11

efficiently laid out to accomplish tasks quickly.

31 4.1 The software's interface shall be organized based on department.

SW

32 4.1 There shall be a deparment selection dropdown menu, in which a user will select the department

they wish to access.

SW 1.0 UC32_Select_Department

Page Navigator

33 4.1 Each department's interface shall allow the user to intuitvely access all necessary functions applicable

to that department

SW

UC32

34 4.1.1 General departments shall share a similar interface.

SW

35 4.1.1 This interface shall allow the user to access and view all of the inventory associated with that department.

SW 1.0 UC35_Load_Department_Inventory

Database

36 4.1.1 This view of inventory will be intuitively laid out to show what is in stock, the price of the item, and when any out of stock item is expected to be available.

SW

37 4.1.1 The user will be able to search for a specific item by name or UPC.

SW 1.0 UC37_Search_Inventory Interface Controller

38 4.1.1 General department interfaces shall also allow users to view the staff of

that department and send messages/ notifications to the

management within that department.

SW 1.0 UC38_Load_Employees, UC39_Search_Employees


39 4.1.2 The interface for the management department shall be broken down into 3 subpages/interfaces each

representing one of the subdepartments described in

section 2.2

SW

40 4.1.2 The accounting page shall allow the user to generate reports based

on transactions.

SW

UC05

41 4.1.2 Accounting employees shall be able to view the hours worked by each employee, and calculate the

amount to pay them.

SW 1.0 UC41_Process_Paychecks


42 4.1.2 All the payroll information shall be pushed out to a file where the information, including banking

information and amounts for each employee, is parsed by an external system to print checks or be sent

electronically.

SW

UC41

12

43 4.1.2 Employee total hours worked shall be reset after each paycheck is

sent out.

SW

UC41

44 4.1.2 Payroll shall be processed and sent out every 2 weeks.

SW, SWC

45 4.1.2 The human resources page shall allow the user to manage all

employee positions.

SW

UC07

46 4.1.2 There shall be the option to view all employees in a list and sort them

by various attributes.

SW

UC38

47 4.1.2 When adding an employee a popup window will appear with all the

relevant fields.

SW

UC09

48 4.1.2 This page will have the option to display the employee work

schedule, which will be generated externally by a Human Resources

employee.

SW

49 4.1.2 This schedule will be visible to all employees regardless of position

within the store.

SW

50 4.1.2 A Human Resources employee shall be able to manually reset and modify the clockin, clockout and total hours worked fields in an

employee record.

SW 1.0 UC50_Modify_Employee_Data


51 4.1.2 The customer service page shall allow the user to search for

search past transactions over the past 30 days, to create a new

customer service case, to access old/open customer service cases.

SW 1.0 UC51_Load_Transactions, UC52_Search_Transactions


52 4.1.2 To process returns the user shall select a past transaction to reverse

and a new transaction will be created.

SW

UC27

53 4.2 Upon accessing the software the user shall be required to enter their

login information, i.e. their username and password.

SW 1.0 UC53_Log_In


54 4.2 After entering valid login information the user shall be signed in and have access to pages that they have the privilege to view or

interact with.

SW

UC53

55 4.2 The store manager shall have access to all functionality

offered by the software, they can assign employees to all positions

within the store.

SW

13

56 4.2 The store supervisor shall have access to all functionality

offered by the software, they can assign employees to all positions

below their own.

SW

57 4.2 Managers shall have access to all functionality within their

assigned department, and have limited access to functionality within

the management department.

SW

58 4.2 Management will be able to access notifications sent by employees to

management.

SW

59 4.2 General employees shall be able to view inventory, and send messages/notifications to

managers.

SW

60 4.2 If an employee is assigned to a more specific job, such as customer service, they shall have access to the functionality associated with

that job.

SW

61 4.2 All general employees shall access their employee page and clockin when they begin work, and clock

out when they leave.

SW

UC21, UC22

62 4.2 A user shall have the option to sign out when they have completed their

use of the software.

SW 1.0 UC62_Log_Out Interface Controller

63 4.2 If a user lets the system sit idle for 10 minutes, they shall automatically

be signed out.

SW, SWC

UC62

64 4.3.1 Every 30 minutes the inventory shall be checked for stock levels.

SW, SWC

65 4.3.2 If stock level on an item is below 30% of the desired (target) stock level, it shall produce a notification and update the notifications panel.

SW,SWC

66 4.3.3 Items with low stock level (below 30% of the target) will be colored in

red in inventory list

SW

67 4.3.4 User will be able to flag an item if the item is under 30% threshold

SW

68 4.3.5 Employees shall be able to send messages to managers within their

own department

SW 1.0 UC68_Create_Message Interface Controller

69 4.3.6 Manage shall be able to view the message sent by employees in their respective department.

SW 1.0 UC69_View_Message Interface Controller

14

70 4.3.7 When an employee sends a message it shall also send the

message with their information and date

SW

UC68

71 4.3.8 User shall be warned if they're inactive for 9 minutes. (Inactivity is

determined by clicks)

SW

72 4.3.9 The software will log itself out when the user is inactive for 10 minutes.

SW

UC62

73 4.4 Every day at 11:59pm transactions older than 30 days will be removed

from the database.

SW,SWC

UC80

74 4.4.1 If the user should enter invalid information in the login entry fields,

the program shall return “ You have

entered an invalid username/password.”

SW

UC53

75 4.4.2 When a user clocksin it the system shall store the time in the clockin field of their employee record, and when they clockout the time is stored in the clockout field.

SW

UC21, UC22

76 4.4.3 If the user does not clockout at the end of the day, and tries to clockin on the next day, an error will be

displayed, and they will be prompted to contact a

manager/Human Resource employee.

SW

UC21

77 4.4.4 If the user enter invalid data entry, such as: invalid SSN, address, and banking information, the program shall return, “Invalid (SSN, Address,

and Banking information)”.

SW

UC09, UC11, UC23, UC25, UC27, UC50, UC53, UC68, UC88

78 4.4.5 The program shall display a message, “No data found”, if there are no datas in the table requested.

SW

79 5.0 Every day at 11:59pm the new transactions for that day shall be

appended to a log file

SW 1.0 UC79_Back_Transactions Object Classes

80 5.0 Every day at 11:59pm transactions older than 30 days will be removed

from the database.

SW 1.0 UC80_Remove_Old_Transactions Interface Controller

81 5.0 Every 7 days, the other data in the database will be backed up to log files, this includes employees, messages, inventory, etc...

SW

UC82

82 5.0 The software shall allow the database .SQLite file to be duplicated and backedup

SW 1.0 UC82_Backup_Database_Table Object Classes

15

83 5.0 The software will allow the restoring of a backup database .SQLite file

SW 1.0 UC83_Restore_Database_Table Interface Controller

84 6.0 The store manager shall have the ability to access all of the program

SW

85 6.0 The store managers login shall have root access to the software, thus have the privileges to access the administrative functions of the

software

SW

86 6.0 The administrative functions shall include: Manual backup of

databases

SW

UC82

87 6.0 The administrative functions shall include: Manual restoration of

databases

SW

UC83

88 6.0 The administrative functions shall include: Modify the network/local paths to database servers and log

files

SW 1.0 UC88_Modity_Data_Path


89 3.3 There shall be a cash register view which allows the user to create a transaction to be added to the

transaction queue.

SW

UC27

16

Use Cases: Use Case 5: Create Financial Report Overview: Pull data from database tables and calculates financial values and organizes them in a report which is stored as a separate file. Preconditions: 1. The database is accessible. 2. All database tables must be populated. 3. Accounting page is displayed. 4. User is logged into an account with appropriate authorization. Scenario:

Action Software Reaction

1.User browses for a location to save the report, via system directory chooser.

1. System gets path and checks if it is valid.

2. User clicks Generate Report button on the accounting page

2. Report is generated and saved.Appropriate Label is set to visible to notify the user the generation was successful.

Scenario Notes: None Postconditions: The created report file is saved to the location defined by the user. Exceptions: 1. DB cannot be accessed 2. DB is not populated Required GUI: 1.Accounting View Use Case Utilized: 1.UC35 2.UC51 Timing Constraints: None

17

Use Case 7: Assign Employee Position Overview: Select the employee, select the position from a dropdown menu, click Assign Position button. Preconditions: 1. The database is accessible. 2. The employee table within the database is accessible. 3. There is an employee record to assign the position. 4. The user must be an employee in the Human Resources department or a manager. 5. The user is viewing the employee positions page under Human Resources. Scenario:


1. The user selects an employee from a list.

1. The name of the employee will be highlighted, and a dropdown menu will appear.

2. The user selects a position from a dropdown menu and clicks Assign Position.

2. Employee’s position is updated in the table and saved, the employee’s name will no longer be highlighted.

Scenario Notes: None Postconditions: 1. The cell in the employee table is changed to the designated value. Exceptions: 1. The database is inaccessible and the system alerts the user and does not modify the position. 2. The table is inaccessible and the system alerts the user and does not modify the position. 3. The employee record is inaccessible and the system alerts the user and does not modify the position. Required GUI: 1. Employee Positions page within the human resource tab Use Case Utilized: 1. UC38 2. UC50 Timing Constraints: None

18

Use Case 9: Add Employee Overview: This use case allows the user to add a new employee to the employee database. Preconditions: 1. The database is accessible. 2. The user is viewing the employee page under Human Resources. Scenario:


1. User clicks on the Add Employee button.

1. The Add_Employee_Edit_Page appears.

2. User enters employee information. And clicks Ok button

2. System checks the information to make sure it is acceptable format. If there is an error the field is highlighted red. Else the Add_Employee_Edit_Page closes, and a new employee record is added to the database.

3. User modifies incorrectly formatted information, and clicks Ok button.

3. If information is correctly formatted, Add_Emplpoyee_Edit_Page closes and a new employee record is added to the database.

4. User clicks cancel button. 4. Add_Employee_Edit_Page closes, no changes are made to the employee database

Scenario Notes: Employee information consists of: First Name, Middle Initial, Last Name, Birthday, SSN, Address, Banking Information (Name on Account, Account Number, Routing Number),Username, Password, Email and Position. Username will be generated based on employee name. Employee information can be entered in any order. Actions 2 / 3 and 4 are exclusive. Postconditions: 1. An employee record will be added to the database. Exceptions: 1. Information entered in an incorrect format. System does not complete the use case until the user corrects the error. 2. Database is not accessable. System alerts user and does not add employee. 3. If the employee to be added is a repeat of a preexisting employee, the system will alert the user and not add the employee. Required GUI: 1. Employee management page of Human Resources interface 2. Add_Employee_Edit_Page Use Case Utilized: UC39 Timing Constraints: None

19

Use Case 10: Remove Employee Overview: Allows user to select and remove an employee after displaying Employee_Table. Preconditions: 1.Database is accessible. 2.The employee table must be populated 3.Employee table must be displayed. 4.Employee must be selected. Scenario:


1.User clicks on desired employee.

1.The employee is selected and is highlighted.

2.User clicks Remove_Button 2.The employee is removed from the table, then the table updated to reflect removal.

Scenario Notes: None Postconditions: 1.The employee is removed from the employee table. 2.Employee table must be displayed. Exceptions: 1.DB is not accessible. 2. No employee is selected Required GUI: 1.Employee_Table 2.Rmoved_Employee_Pop_Up Use Case Utilized: 1.UC38

20

Timing Constraints: None Use Case 11: Create Customer Service Case Overview: Creates a customer service case for employees to deal with. Preconditions: 1. The database is accessible. 2. The Customer Service Cases page must be displayed. Scenario:



1. The Create_Case_Interface appears.

2. User enters the case information. And clicks Ok button

2. System checks the information to make sure it is acceptable format. If there is an error the field is highlighted red. Else the Create_Case_Interface closes, and a new customer service case is added to the database.


3. If information is correctly formatted, Create_Case_Interface closes and a new customer service case is added to the database.

4. User clicks cancel button. 4. Create_Case_Interface closes, no changes are made to the employee database

Scenario Notes: Information from customer service cases include: customer name, customer contact information, and a description of the case. Postconditions: 1. Customer service case is created. Exceptions: 1.The database is not accessible and the system alerts the user. 2. The Customer_Service_Case_Table is not accessible and the system alerts the user about this information. 3. Information entered in an incorrect format. System does not complete the use case until the user corrects the error. Required GUI: 1.Customer_Service_Page 2.Customer_Service_Case_Table Use Case Utilized: None Timing Constraints: None

21

Use Case 12: Load Customer Service Case Overview: Pulls Customer_Service_Case_Table from the database and displays it. Preconditions: 1.Database is accessible. 2.Customer_Service_Page must be displayed. 3. User has privilege to access the page. Scenario:


1.User clicks on Display_Customer_Service_Case_Button on Customer_Service_Page

1.Displays Customer_Service_Case_Table

Scenario Notes: None Postconditions: 1.Customer_Service_Case_Table is displayed Exceptions: 1.DB is not accessible. 2.Customer_Service_Case_Table is not accessible Required GUI: 1.Customer_Service_Page 2.Customer_Service_Case_Table Use Case Utilized: None Timing Constraints: None

22

Use Case 13: Remove Customer Service Case Overview: Enables user to remove existing customer service case. Preconditions: 1.Database is accessible. 2.Customer_Service_Case_Table must be displayed. 3.Customer_Service_Case_Table must be populated. 4.Customer service case must be selected. Scenario:


1.User clicks on one of the existing cases.

1.The customer service case is selected and highlighted.

2.User clicks on Remove_Customer_Service_Case.

2.The case is removed, then Removed_Customer_Service_Case_Pop_Up is displayed.

3.User clicks OK 3.Removed_Customer_Service_Case_Pop_Up is closed.

Scenario Notes: None Postconditions: 1.The customer service case is removed. Exceptions: 1.DB is not accessible. 2.No case is selected. Required GUI: 1.Customer_Service_Case_Table 2.Removed_Customer_Service_Case_Pop_Up Use Case Utilized: 1.UC12 Timing Constraints: None

23

Use Case 21: Clock In Overview: This Use Case enables the user to clock in. The clock in time will be used (along with the clock out time) to calculate the number of hours the user has worked. Preconditions: 1. User is logged into the MMMS. 2. User is clocked out. 3.The database is accessible. 4. User profile is displayed. Scenario:


1. User clicks on the Clock_In button on the User Profile page.

1. The Clock_In_Confirmation text is displayed, the DB is updated.

Scenario Notes: Postconditions: 1. The Clock In value is updated in the DB. 2. The user is clocked in. Exceptions: 1. The DB cannot be accessed. Required GUI: 1. Clock_In_Clock_Out_View Use Case Utilized: None Timing Constraints: None

24

Use Case 22: Clock Out Overview: This Use Case enables the user to clock out. The clock out time will be used (along with the clock in time) to calculate the number of hours the user has worked. Preconditions: 1. User is logged into the MMMS. 2. User is clocked in. 3.The database is accessible. 4. Clock_In_Clock_Out_View is displayed. Scenario:


1. User clicks on the Clock_Out button on the User Profile page.

1. The clock in text disappears, Clock_Out_Confirmation text is displayed, the DB is updated. Hours work is updated.

Scenario Notes: none Postconditions: 1. The Clock In value is updated in the DB. 2. The user is clocked in. Exceptions: 1. The DB cannot be accessed. Required GUI: 1. Clock_In_Clock_Out_View Use Case Utilized: None Timing Constraints: None

25

Use Case 23: Add Inventory Item Overview: New inventory item is entered into the department’s Inventory_Table. Preconditions: 1. User must be manager or above. 2. Database is accessible. 3. Inventory_Table is displayed. 4. UPC to be entered must not already exist in Inventory_Table. Scenario:


1. User clicks on the Add Inventory button.

1. The Add_Inventory_Item_view appears.

2. User enters item information and clicks OK.

2. The System checks the information to make sure it is acceptable format. If there is an error the field is highlighted red. Else the Add_Inventory_Item_view closes, and a new inventory record is added to the Inventory_Table.

3. User modifies incorrectly formatted information, and clicks OK button.

3. If information is correctly formatted, Add_Iventory_Item_view closes and a new inventory record is added to the Inventory_Table.

4. User clicks CANCEL button.

4. Add_Inventory_Item_view closes, no changes are made to the Inventory_Table

Scenario Notes: Item information consists of: UPC, Quantity Item information can be entered in any order. Actions 2 / 3 and 4 are exclusive. Postconditions: 1. An inventory record will be added to Inventory_Table. Exceptions: Information entered in an incorrect format. System does not complete the use case until the user corrects the error. Database is not accessable. System alerts user and does not add inventory record. Item UPC to be added already exists in Inventory_Table. System alerts user and does not add inventory record. Required GUI: 1. Department view page of appropriate department 2. Add_Inventory_Item_Pop_Up Use Case Utilized: UC37 Timing Constraints: None

26

Use Case 24: Remove Inventory Item Overview: Pulls Inventory table from the database and enables user to select an item, then remove it. Preconditions: 1.DB is accessible. 2.Inventory_Table is displayed. 3.Inventory_Table is populated. 4.An item must be selected. Scenario:


1.User clicks on an item.

1.Item is selected and highlighted.

2.User clicks Remove_Item

2.Item is removed.

3.User clicks OK 3. Inventory table is updated.

Scenario Notes: None Postconditions: 1.Item is removed from the table 2.Inventory_Table is displayed. Exceptions: 1.DB is not accessible. 2.No item is selected. Required GUI: 1.Inventory_Table 2.Removed_Item_Pop_Up Use Case Utilized: 1.UC35 Timing Constraints: None

27

Use Case 25: Modify Inventory Item Overview: Pulls Inventory_Table from the database. Enables user to modify selected item. View will appear with item information and the user will be able to modify the item information on the view. Preconditions: 1.DB is accessible. 2.Inventory_Table is displayed. 3.Inventory_Table is populated. 4.An item must be selected. Scenario:


1.User clicks on an item. 1.Item is selected and highlighted.

2.User clicks on Modify_Item 2.Modify_Item_view is displayed with all the information about the selected item.

3.User clicks on Save 3.Any information that are edited about the item is modified and Modify_item_view is closed. Item is no longer selected.

4.User clicks Cancel 4.Any information edited will not saved and Modify_item_viewp is closed. Item is no longer selected.

Scenario Notes: Action 3 and 4 cannot happen at the same time. Either the item will be modified or kept the same. Modify_Item_view allows you to modify store item’s UPC, name, department, quantity on hand, target quantity, wholesale price per unit, and sale price per unit. Postconditions: 1.Item is modified or kept the same. 2.Item is no longer selected. 3.Inventory_Table is displayed. Exceptions: 1.DB is not accessible 2.No item is selected. Required GUI: 1.Modify_item_View 2.Inventory_Table Use Case Utilized: 1.UC35 Timing Constraints None Use Case 27: Create Transaction

28

Overview: Enables user to create a transaction on the Transaction_Table. Preconditions: 1. Database is accessible 2.Transaction_Table is displayed 3.Necessary information about the transaction must be filled out on Add_Transaction_View. Scenario:


1.User clicks Add_Transaction_Button

1.Add_Transaction_View is displayed that allows user to input all the necessary information.

2.User clicks Save 2.All the information typed is saved and new data is formed on Transaction_Table. Add_Transaction_View is closed.

3.User clicks Cancel. 3.Add_Transaction_View is closed.

Scenario Notes: Action 2 and 3 cannot happen at once. Add_Transaction_View allows user to enter transaction ID, product’s UPC, and product’s quantity. Postconditions: 1.New data is created or nothing happens 2.Transaction_Table is displayed. Exceptions: 1.DB is not accessible. 2.Necessary informations are not filled. 3.Informations are in incorrect format. Required GUI: 1.Transaction_Table 2.Add_Transaction_View Use Case Utilized: UC51 Timing Constraints: None

29

Use Case 28: Process Transaction Queue Overview: New transaction will enter transaction queue. Automatically pulls data from transaction queue and stores the information in the transaction table every 5 minutes. Preconditions: 1.Transaction_Queue is populated. Scenario:


1.New transaction occurs

1.The new transaction will enter transaction queue.

2.5 minute timer triggers

2.All the transactions in the queue will be transferred to transaction table.

Scenario Notes: Action 2 will not occur when queue is not empty. Postconditions: 1.Transaction queue is emptied. 2.Transaction table is filled with new information from the queue Exceptions: None Required GUI: None Use Case Utilized: None Timing Constraints: Action 2 is done automatically every 5 minutes.

30

Use Case 32: Select Department Overview: Transfers the user to the desired department page. Preconditions: 1. The user must be logged in. Scenario:


1. The user clicks on the department dropdown menu

1. A list of departments that eh user has access to will appear.

2. The user selects the department.

2. The user will be transported to the correct department page. The page will be loaded in the content area of the window.

Scenario Notes: 1. If the user does not have the correct privileges certain options will not appear in the menu. Postconditions: 1. You will be sent to the correct department page. Exceptions: 1. Could not load the information Required GUI: 1. Main page of each department. 2. Main Window GUI and controller Use Case Utilized: 1. UC35 Timing Constraints: None

31

Use Case 35: Load Department Inventory Overview: All records in a department’s Inventory_Table are fetched from the store’s database and displayed. Preconditions: 1. Database is accessible 1. User selects one of the 5 general departments from the Department_Drop_Down_Menu. Scenario:


1. User clicks on Inventory_Tab on selected department’s Department_View screen.

2. All records in the selected department’s Inventory_Table are fetched from the store’s database and displayed on the selected department’s Department_View screen.

Scenario Notes: Postconditions: 1. All records in the selected department’s Inventory_Table are displayed on the selected department’s Department_View screen. Exceptions: Database is not accessable. System alerts user and does not display inventory. Required GUI: Inventory_Tab Use Case Utilized: None Timing Constraints: None

32

Use Case 37: Search Inventory Overview: This use case enables user to search through the inventory using keywords. This allows the user to navigate through the inventory table with ease. Preconditions: 1. DB is accessible. 2.Inventory_Table is displayed Scenario:


1.User clicks on Seach_Inventory_Button

1.The table will display all the item that contains the typed keyword.

Scenario Notes: For action 1, if the text field is empty, then the table will display everything. Postconditions: 1.Table will display items that contains the typed keyword. 2.Inventory_Table is displayed. Exceptions: 1.No items contains the keyword. Required GUI: 1.Inventory_Table Use Case Utilized: UC35 Timing Constraints: None

33

Use Case 38: Load Employees Overview: Pulls Employee_Table from the database and displays it. Preconditions: 1.Database is accessible. 2.Human Resources page in management department must be displayed. Scenario:


1.User clicks on employee page within customer service tab.

1. Table of employees is loaded from database and displayed.

Scenario Notes: None. Postconditions: 1. List of employees appear in employees page. Exceptions: 1.DB is not accessible. 2.Employee_Table is not accessible Required GUI: 1. Employee page within Human Resources tab. Use Case Utilized: None. Timing Constraints: None.

34

Use Case 39: Search Employee Overview: This use case enables user to search through the employee using keywords. This allows the user to navigate through the employee table with ease. Preconditions: 1. DB is accessible. 2.Employee_Table is displayed Scenario:


1.User clicks on Seach_Employee_Button

1.The table will display all the item that contains the typed keyword.

Scenario Notes: For action 1, if the text field is empty, then the table will display everything. Postconditions: 1.Table will display items that contains the typed keyword. 2.Inventory_Table is displayed. Exceptions: 1.No items contains the keyword. Required GUI: 1.Employee_Table Use Case Utilized: UC38 Timing Constraints: None

35

Use Case 41: Process Paychecks Overview: This use case enables user to click a button to calculate amount of money that employee needs to be paid. Preconditions: 1. The database is accessible. 2. All database tables must be populated. 3. Accounting page is displayed. Scenario:


1. User clicks browse button, and selects a directory to save file to using the choose directory prompt.

1. System stores the path and checks if it is valid, it sets the textField to that value.

2.User clicks Process_Paycheck_Button

2.The software will calculate the amount of money with the given information in the database and output it for the user.

Scenario Notes: Output of action 1 will be calculated based on hours worked by employees and hourly wage for the corresponding employee. Postconditions: 1.The software will output amount of money for paycheck. 2.Accounting page is displayed. Exceptions: 1.Database is not accessible. Required GUI: 1.Accounting Page Use Case Utilized: UC38

36

Timing Constraints: None Use Case 50: Modify Employee Data Overview: Pulls Employee_Table from the database. Enables user to modify selected Employee. Popup will appear with employee information and the user will be able to modify the employee information on the popup. Preconditions: 1.DB is accessible. 2.Employee_Table is displayed. 3.Employee_Table is populated. Scenario:


1.User clicks on an employee.

1.Employee is selected and highlighted.

2.User clicks on Modify_Employee

2.Modify_Employee_View is displayed with all the information about the selected employee.

3.User clicks on Save 3.Any information that is edited about the employee is modified and Modify_Employee_View is destroyed. Employee is no longer selected.

4.User clicks Cancel 4.Any information edited will not saved and Modify_Employee_View is closed. Employee is no longer selected.

Scenario Notes: Action 3 and 4 cannot happen at the same time. Either the item will be modified or kept the same. Modify_Employee_View allows you to modify the employee’s First Name, Middle Initial, Last Name, Birthday, SSN, Address, Banking Information (Name on Account, Account Number, Routing Number),Username, Password, Email and Position. Postconditions: 1.Employee is modified or kept the same. 2.Employee is no longer selected. 3.Employee_Table is displayed. Exceptions: Use Case Utilized: 1.DB is not accessible 1.UC38 2.No item is selected. Required GUI: Timing Constraints: 1.Modify_Employee_View None 2.Employee_Table

37

Use Case 51: Load Transactions Overview: Pulls Transaction_Table from the database and displays it. Preconditions: 1.Database is accessible. 2.Transaction page in customer service tab must be displayed. Scenario:


1.User clicks on transactions page within customer service tab.

1. Table of transactions is loaded from database and displayed.

Scenario Notes: None. Postconditions: 1. List of transactions appear in transactions page. Exceptions: 1.DB is not accessible. 2.Transaction_Table is not accessible Required GUI: 1. Transaction page within Customer Service tab. Use Case Utilized: None. Timing Constraints: None.

38

Use Case 52: Search Transactions Overview: Enables user to search through the inventory using a Transaction ID. This allows the user to find the correct transaction. Preconditions: 1. DB is accessible. 2.Transactions_Table is displayed Scenario:


1.User clicks on Seach_Transaction_Button

1.The table will display the transaction relevant to the given ID.

Scenario Notes: For action 1, if the text field is empty, then the table will display everything. Postconditions: 1.Table will display items that contains the typed keyword. 2.Transactions_Table is displayed. Exceptions: 1. The ID cannot be found. Required GUI: 1.Transactions_Table Use Case Utilized: 1. UC51 Timing Constraints: None

39

Use Case 53: Log In Overview: This Use Case enables the User to log into the MMMS. Preconditions: 1. The user is logged out of the MMMS. 2.The database is accessible. 3. Log_In_Log_Out View is displayed. Scenario:


1. The user enters username and password and clicks the log_in button.

1. The DB is accessed to see if a record exists with the provided username and password. MMMS_Desktop_View is displayed if the record is found.

Scenario Notes: Postconditions: 1. The MMMS_Desktop_View is displayed. Exceptions: 1. The DB cannot be accessed. Required GUI: 1. Log_In_Log_Out_View Use Case Utilized: 1. UC39_Search_Employees Timing Constraints: None

40

Use Case 62: Log Out Overview: This Use Case enables the user to log out of the MMMS. Preconditions: 1. The user is logged into the MMMS. 2.The database is accessible. 3. Log_In_Log_Out View is displayed. Scenario:


1. The user clicks on the log_out button on the MMMS_Desktop_View.

1. Log_In_Log_Out_View appears.

Scenario Notes: Postconditions: 1. The user is not logged in. 2. The user does not have access t Exceptions: 1. The user is not logged in. Required GUI: 1. MMMS_Desktop_View. 2. Log_In_Log_View Use Case Utilized: None

41

Timing Constraints: None Use Case 65: Inventory Alert Overview: Every 30 minutes, inventory is checked for low stock levels. If stock level for an item is below the target level, this use case would allow the system to produce an inventory alert and send it to the notification panel for the managers to check. Preconditions: 1. The database is accessible. 2. Stock level of one or more inventory item(s) is below the target level. Scenario:


1. Stock levels are checked.

1. Text of the Notifications button in the MMMS_Desktop_View increments by 1. An alert is produced with names and stock levels of the items with low stock levels. Notification table in the DB is updated with this new alert.

Scenario Notes: Postconditions: 1. Notification_Panel_View is updated. 2. Text of Notification_Button is incremented by 1. 3. The database is updated with the new alert. Exceptions: 1. The database cannot be accessed. Required GUI: 1. MMMS_Desktop_View 2. Notification_Button Use Case Utilized: UC68_Create_Message Timing Constraints:

42

None Use Case 68: Create Message Overview: Allows user to send a message to their corresponding department manager. The message is user typed and user information and date are automatically attached to the message. Preconditions: 1.Send_Message_Page must be displayed. 2.Message text box must be filled. Scenario:


1.User clicks Send_Message_Button

1.The message is saved into Message_Table in the database for the manager to view. Message_Sent_Pop_Up is displayed

2.User clicks OK. 2.Message_Sent_Pop_Up is closed and the user is sent back to the main page.

Scenario Notes: When action 1 occurs, the message is saved into the database along with user information and the date it was written. Postconditions: 1.Message_Table is updated with the new message. 2.Main department page is displayed. Exceptions: 1.Message text field is empty. Required GUI: 1.Send_Message_Page 2.Message_Sent_Pop_Up 3.Main_Page Use Case Utilized:

43

Timing Constraints: None Use Case 69: View Messages Overview: Allows the user(managers) to access the Message_Table and view the message written by other employees. Preconditions: 1.Database is accessible. 2.Message_Table is populated. 3.Message_Table is displayed. Scenario:


1.User clicks on a message

1.Message is selected and highlighted.

2.User clicks on Display_Message

2.Display_Message_Pop_Up will be displayed that contains the employee information and the message.

3.User clicks OK 3.Display_Message_Pop_Up is closed.

Scenario Notes: None Postconditions: 1.Message_Table is displayed. 2.Message in the table will be marked as read. Exceptions: None Required GUI: 1.Message_Table 2.Display_Message_Pop_Up Use Case Utilized: None

44

Timing Constraints:None Use Case 71: Inactivity Alert Overview: After 9 consecutive minutes of inactivity, the loggedin user is warned of an auto logout. If inactivity persists for an additional minute, an auto logout is carried out. Preconditions: 1. User must be logged in Scenario:


1. User remains idle (no mouse clicks) for 9 consecutive minutes

1. The Inactivity_Alert_Pop_Up appears

2. User clicks OK 2. The Inactivity_Alert_Pop_Up is destroyed without logging the user off.

3. User remains idle (no mouse clicks) for an additional minute

3. The user is automatically logged out, the Inactivity_Alert_Pop_Up is destroyed, and Log_In_Log_Out_View is displayed

Scenario Notes: Actions 2 / 3 are exclusive. Postconditions: 1. The user remains logged in (Action 2) 2. The user is logged out (Action 3) Exceptions: None. Required GUI: Inactivity_Alert_Pop_Up Log_In_Log_Out_View Use Case Utilized: UC62_Log_Out

45

Timing Constraints:None Use Case 80: Remove Old Transactions Overview: The software will automatically search through the transaction table daily at a fixed time and search for transactions that are 30 days old or older. The searched transactions will be deleted. Preconditions: 1.Transaction_Table is populated. 2.Transaction is 30 days old. Scenario:


1.The software does a search through the table.

1.The searched transactions will be deleted from the database.

Scenario Notes: Postconditions: 1.Transaction is removed. Exceptions: None Required GUI: None Use Case Utilized: UC51 Timing Constraints: The action 1 occurs daily at a fixed time of 11:59PM.

46

Use Case 82: Backup Database Table Overview: This Use Case allows the user to manually backup all records of a desired table to a log file. Preconditions: 1. A database is selected from the DB_Drop_Down_Menu_Button Scenario:


1. Backup_Database_Button is pressed.

1. A copy of the database is created and is backed up.

Scenario Notes: Postconditions: 1. Selected database is backed up. Exceptions: 1. The database is not selected. Required GUI: 1. Backup_Database_View Use Case Utilized: None Timing Constraints: None

47

Use Case 83: Restore Database Table Overview: This use case allows a user to load information from a log file, and replace existing information or append to the existing information in the database’s corresponding table. Preconditions: 1. User is viewing the administrative backup / restore page. 2. The database is accessible. Scenario:


1. The user clicks browse 1. system file browser pop up appears.

2. The user selects a database backup file

2. System check if file is acceptable.

3. User clicks restore button 3. System replaces the database file with the selected file.

Scenario Notes: None Postconditions: 1. The selected database table will be modified with the log data in the specified manner. Exceptions: 1. The log file is not readable, the system will inform the user with a notification. Required GUI: 1. Backup / Restore tab within the administrative department. Use Case Utilized: None. Timing Constraints: None.

48

Use Case 88: Modify Data Path Overview: Changes the path where database is stored. Preconditions: 1. User must be the administrative. 2. User must be on the Administration page. 3. User must be under the System Setup tab on Administration page. Scenario:


1. User clicks Browse_Button 1. Browse Window appears for user to select the database.

2. User clicks open in browse window

2. Browse Window is closed and database path is set.

3. User clicks cancel in browse window

3. Browse WIndow is closed and database path value is unchanged.

4. User clicks Save_Data_Path_Button

4. System.properties file is updated.

5. User clicks Cancel_Button 3. The data path is not changed and user stays on System Setup tab.

Scenario Notes: Postconditions: 1. System information page displayed 2. Data path is changed, or not. Exceptions: 1. Path is not accessable Required GUI: 1. Administrative Page 2. System Setup

49

Use Case Utilized: None Timing Constraints: None Sequence Diagrams:

50

UC09

56

UC28

57

UC32

UC35

58

UC37

UC38

59

UC39

UC41

60

UC50

UC51

61

UC52

UC53

62

UC62

UC68

63

UC69

UC71

64

UC80

65

UC82

66

UC88

67

Category Interaction Diagram

68

Object Design: Software Architecture: Model View Controller (MVC) Model Much of the functionality in the model portion of the software relate to database access and data manipulation, we have contained this portion in just a few classes. View We are using JavaFX, therefore our view will primarily be defined in .fxml files to properly adhere to a MVC architecture. We have broken down our interface into many small elements and “pages” within the software, and each element/page has its own controller. Controller We have elected to break down our interface controllers into small focused controllers which only operate on a specific page/view of the program. This allows for better overall organization of the program’s structure. The controller for each interface element will handle events that occur in the page/view. Our General Object/Class design contains the following groups:

Object Classes (ex: Employee or Inventory Item)

- Represent records from database tables. - Used to manipulate data in the software after loading from database. - Sent to database class to store values representing table records.

Controller Classes (ex: Employee View or Employee Edit)

- Handle events from the corresponding FXML defined interface. - Event handlers contain the majority of the logic for each event that can occur. - Each controller contains variables and event handlers that directly manipulate

data and the interface that the user sees.

Helper Classes (ex: Database or Page Navigator)

- Program wide accessible methods and variables. - Database Functions provides static functions which allow access to the database. - Page Navigator aids in navigating the user around the interface, by acting as the

hub for page switching across all classes of the program.

69

Test Cases: Test Case: Login

Type: Blackbox, Number of Tests: 6 (5 for Input 1, and 1 for Input 2) Attributes Descriptions

Name Login

Location /<Project Root Folder>/src/MegaMartMS/Controllers/LoginScreenController.java

Input Input 1) A username and password combination that exists in the database is entered, and login clicked. Input 2) A username and password combination that does not exist in the database is entered, and login clicked.

Oracle Oracle 1) The corresponding user should be logged in and the department menu has the user's accessible departments added to it, and the user menu has the users name displayed and drop down is populated. Oracle 2) The program should not log the user in and should print out a message informing the user they entered incorrect information into the username and/or password field.

Log Log 1) The two menus are correctly populated and user has access to rest of program. Log 2) The program tells the user they entered invalid info, and the login screen remains displayed.

Test Case: Page Navigation

Type: Whitebox, Number of Tests: 13 (All pages that are loadable) Attributes Descriptions

Name Page Navigation

Location /<Project Root Folder>/src/MegaMartMS/Objects/PageNavigator.java

Input Input 1) Clicking interface items that will load/navigate to a different page. For example: selecting a department from the drop down menu, selecting a tab within a page, or clicking the add employee button.

Oracle Oracle 1) The destination page should correctly load and be displayed, if any data needs to be passed to the new page it should do so by passing it to the page's correct controller instance.

Log Log 1) The correct page page is loaded and necessary information is passed. For example when modifying an employee the selected employee object from the table view is passed to the employee edit page.

70

Test Case: Search Employee Type: Blackbox, Number of Tests: 9 (One for each type of possible search type)

Attributes Descriptions

Name Search Employee

Location /<Project Root Folder>/src/MegaMartMS/Controllers/EmployeeViewController.java

Input Input 1) User inputs a spaceless string into the search field and clicks search. Input 2) User inputs a number into the search field and clicks search. Input 3) User inputs a string that contains one white space in the middle into the search field and clicks search. Input 4) User inputs a blank string or a string composed of only white space into the search field and clicks search.

Oracle Oracle 1) The table view should be updated to display employee records that have a matching attribute to the search string. Oracle 2) The table view should be updated to display employee records that have a matching employeeID or phone number to the search string. Oracle 3) The table view should be updated to display employee records that have a matching first and last name to the words separated by the white space in the search string. Oracle 4) The table should be updated to display all employee records in the database.

Log Log 1) The table view updates to display employee records in which an attribute entirely matches the search string. Log 2) The table view updates to display employee records in which the number entirely matches either the employeeID or the phone number the search string. Log 3) The table view updates to display employee records in which the first and last name match the two word in the search field in any order. Log 4) The table updates to display all employee records in the database.

Test Case: Logout

Type: Whitebox, Number of Tests: 1 (Only one way to logout, via profile menu) Attributes Descriptions

Name Logout

Location /<Project Root Folder>/src/MegaMartMS/Controllers/MainWindowController.java

Input Input 1) While the user is logged in, they select the "Logout" button from the profile drop down menu.

Oracle Oracle 1) Current user and department should be set to null, login screen should be loaded, and all options should be removed from both the department menu and the profile menu.

Log Log 1) The login screen is displayed, and both the menus are cleared.

71

Topic Choice Rational: Out of two desired topics of: 1. Game of Life and Death 2. Management System for a retail store, we chose the second one because of the following reasons:

1. It is practical and realistic in a sense that it is very close to a real world application. The experience that we will gain through building this application can be easily used to build an application for a company.

2. It is easy to expand this project into even a larger scale project by making it a

franchise, for example.

3. Neither it is trivial nor it is a very large scale project. This project can be finished within the given time frame (about 4 months).

A computer system, on which MMMS will be installed, is required to have:

1. Software a. Java 8 (Our software uses JavaFX 8)

2. Hardware

a. 4 GB (or more) RAM b. Networked to adequately sized database

An interface for cashiers, self checkout systems and customer service systems, which will communicate with the main interface with MMMS, must have:

1. Software a. Java 7 or above

2. Hardware

a. 4 GB (or more) RAM b. A barcode scanner may be used, assuming it simulates keypresses

as its form of input.

72

Use Cases Rationale:

The use of use cases most definitely aided in our development of the software. By using use cases we were able to distil the core requirements that our software had into clear cut functionalities. After constructing a requirement traceability matrix via extracting shall and will statements from our problem statement, we quickly saw common program requirements. Many of the functional requirements were representing the exact same software functionality, thus we were able to define a use case which represented the functionality described by the requirement statements.

We found that through the use of use cases we were able to explicitly define our software’s functional requirements. After having defined all of our use cases we examined each closely and were able to break down all of the possible steps during a user's interaction with the software. A prime example use case of how breaking down all of the possible user/software interactions was helpful is UC09_Add_Employee.

In UC09 we went through every possible state that the user and system might face when interacting, as can be seen below in the scenario.



1. The Add_Employee_Edit_Page appears.

2. User enters employee information. And clicks Ok button

2. System checks the information to make sure it is acceptable format. If there is an error the field is highlighted red. Else the Add_Employee_Edit_Page closes, and a new employee record is added to the database.


3. If information is correctly formatted, Add_Emplpoyee_Edit_Page closes and a new employee record is added to the database.

4. User clicks cancel button.

4. Add_Employee_Edit_Page closes, no changes are made to the employee database

Through this process of walking through the user’s interaction, we were able to

break down all of the possibilities that we as developers needed to account for when actually programming this portion of the software. We referred to this scenario diagram

73

during the process of implementing UC09_Add_Employee to check and make sure we had correctly defined the softwares response to all possible user input.

This example among many others allowed us to seriously examine the details of our software before we were in the process of dealing with code. Resulting in a better understanding of what needed to be done, and how to do it when it actually came time to implement the use cases.

After defining and examining each use case we were able to represent them as

sequence diagrams which ultimately aided in the development of our class and object structure.

So overall the use of use cases allowed for explicitly defined functionalities of our

software which we were able to break down and analyze prior to actually delving into the programming aspects; therefore, allowing us to be better prepared when it came time to actually implement. They were extremely useful to us even when our project scope was small (relatively speaking), so we clearly see how they would play an essential role in the development of a larger scale application.

74

Class and Object Design Rationale:

When designing classes and objects, the goal is that they would “fall out” of the sequence diagrams. we found, however, that this is only somewhat the case. The use of sequence diagrams most definitely gave us a direction to head in when designing our classes and objects but we found as we began actual development of the software that there were many classes that we were unable to foresee needing from the sequence diagrams.

What we did find the sequence diagrams useful for was determining what exactly

our our boundary and control objects would be. Due to our planned use of JavaFX and our intended software architecture, that being ModelViewControl, we already knew that we were going to be defining our boundary objects in FXML files and our control objects as controller objects, one for each FXML defined boundary object. Going into object design with this predetermined structure allowed us to easily extract our exact boundary and control objects that we needed to create in order to comprehensively create our interfaces and controller classes for our application. An example of this can be seen in the sequence diagram below:

As can be seen in the sequence diagram above, when the user encounters the

login use case they must be interacting with a login screen, we determined that the login screen would be the boundary object. We could then easily determine that we needed a

75

controller for the login screen to deal with the logic of logging in. This is what is labeled as “log_in/out_view” above. Despite our lack of quality naming in our sequence diagram we easily extracted the correct object designs from this sequence diagram.

We tended to find that our entity objects were more readily designed based on

the database schema, that we developed from our RTM, than they were from our sequence diagrams. This is most likely a shortcoming on our part in the actual creation of our sequence diagrams than it is in the utility of them if done properly before object design. Each object that we derived from our database schema directly represents a record in a corresponding database table.

Our limited project scope allowed us to proceed with this method of object

design. Were it a real world application or a larger scale project, we are quite aware that this methodology of object design is simply not feasible. Therefore, we see the intrinsic value that sequence diagrams have during object design, and are well aware that our somewhat unorthodox form of object design the incorrect approach. Ultimately we have concluded that sequence diagrams are extremely useful and necessary, especially when done properly. But when dealing with a limited project size, there are other ways to go about designing objects that might work just as well, albeit unorthodox in nature.

76

Test Case Rationale: Login Rationale: To correctly allocate user's access to software functionalities based on position within the store, we needed to test the software to make sure that the appropriate pages are accessible to the employee that logs in. We also needed to test the database access by searching employee based login credentials and return the appropriate employee object based on the database records. Page Navigation Rationale: To access all the functionalities of the software, we needed to test the backend for loading FXML files and correctly storing their controller instance when necessary. This allows for fluid software navigation and allow user to access pages that they need for various software functionalities. Search Employee Rationale: It's important for the user to narrow down the list of employees displayed in the table view. Because we programmatically search only likely matching attributes of the employee record to the search field, we needed to test all the possible search format, that is why we needed to have extensive testing. Logout Rationale: Because we're allowing the user to access only what they're allowed to, we need to be able to revoke all access until another user uses the software. This ensures that user doesn't have unauthorized access to software functionalities when they are not personally logged in. By clearing current user/department and clearing drop down menus, we are able to disable access to any software page other than the log in screen.

77

Function Point Cost Analysis:

Weighting Factor Estimation: Measurement Parameter Count Simple

User Inputs 11 * 3 = 33 User Outputs 7 * 4 = 28 User Inquiries 17 * 3 = 51 Number of Files 2 * 7 = 14

External Interfaces 2 * 5 = 10 Total: 136

For the 14 points, we had plus the complexity adjustment factor we had:

Factor Value Backup and Recovery 5 Data Communications 4 Distributed Processing 0 Performance Critical 3

Existing operating environment 3 Online data entry 0

Online input transactions over multiple screens 0 Master files updated online 0

Inputs, outputs, files, inquiries complex 1 Internal processing complex 0 Code designed for reuse 3

Conversion/installation in design 2 Multiple installations 1

Change and ease of use 5 Complexity adjustment factor 1.17

∑F15: 28.17 FP = x * (0.65 + (0.01 * ΣF15)) FP = 136 * (0.65 + (0.01 * 28.17)) = 126.71 If we have the following assumptions: 1.The organization produces an average of 7 function points per month 2.The labor costs is $8000.00 per month We can estimate that the cost per function point is ($8000/7) or approximately $1140 For 126.71 FP the project will cost $(1140 x 126.71). Which is $144,449.40

78

Constructive Cost Model (COCOMO): The effort multipliers for this project are:

Multiplier Rationale Value

Reliability Small network scope; Backup options implemented; Consistent architecture .88

Database 64 KB .94

Complexity Basic Processing .7

Timing Computations are not processorintensive 1

Storage Does not use much RAM 1

Machine Stable; can be commercially available .87

Turnaround Interactive software: users’ actions will be processed and completed almost instantaneously as they are entered.

.87

Analysts Experienced software analysts 1

Programmers Experienced programmers .86

Experience No experience in management 1.42

Experience No time spent on the micro 1.21

Experience 3 years of experience with the language 1

Practices Almost 3 years of experience in modern practices .82

Tools Very basic micro software 1.24

Schedule Nominal scheduled completion time 1

E = ab * (KLOC)b * b = 2.4 * 6.5^1.05 = 17.13 Programmer Months Effort Adjustment Factor(EAF) = 0.658 When Applied to the nominal estimate the effort adjustment factor produces an estimate of: 11.3 programmer months The estimation of Development time is: D = cb * Ed * b = 2.5*11.3**.38 = 6.3 months Assuming that the programmers and analysts cost $8,000 per person month, the total cost is: Dollars = 11.3 PM * 8000/PM = $90,400.

79

Cost Analysis Comparison and Conclusion:

During development, we found our initial Function Point Analysis to be somewhat imprecise. We believe that this is due to the fact that we ended up making some modifications to sections of the software that are used to calculate the Function Point Cost during the development of the software.

An example of this is the number of User Inquiries, before actually diving into

development of the software we anticipated we would be accessing the database far more often than we actually are. We still access the database quite often due to the nature of our application but initially we did not have an accurate estimate of how often we would. Through the actual development of our application we found that we access the database in approximately 17 different places; this is far lower than our initial estimate which was in the 30’s.

These values that were updated during development brought our Function Point

cost estimate to a more reasonable value. It went from ~$300,000 down to ~$145,000. This was a far more realistic estimate, especially when compared to our Constructive Cost Model estimate, which is ~$90,400.

Given our final software, we feel as if these two cost analysis estimates each

serve their purpose, and would accurately represent the total cost of our software were it to be developed in a real world development scenario. We feel this is the case due to the experience we have had during development including but not limited to: the time requirement to fully develop, final number of inputs and outputs and our experience or lack thereof. Therefore we found it a useful exercise to analyze the potential cost of our software using both the Function Point Analysis and The Constructive Cost Model.

80

Horizontal Prototype:

Login:

Menu Structure:

81

General Department:

Management:

82

Administration:

83

Project Legacy:

Expectations: Going into the project we anticipated our database access class would be the

most difficult portion of our software to develop. We knew our project scope was large, and we anticipated spending quite a bit of

time to get all of our project implemented and working bug free. We thought page navigation would be as simple as replacing the current page

with the new one. And did not think about dealing with persistent menus or UI elements.

We thought that using cloud storage (Google Drive) for project storage will allow

for shared access to updated code. Realizations during development: It turns out that developing our page navigation was more complicated than

expected. This is due to the fact that we embed interfaces within other interfaces, this requires maintaining instances of high level interface controllers, which are accessible program wide.

The project scope is massive and we have found many things that we needed to

add to the software, such as a cash register view for creating transactions, the Page Navigator class for switching between embedded interfaces.

In the end we had to slightly modify some of our initial requirements to be able to

complete the project on time. An example of this is our database backup, initially we planned to create a formatted log files storing each of our tables, but during development we found this to be far more time consuming than anticipated, therefore we went with entire database file backups instead, which results in similar functionality but less required development time.

Multiple members accessing and saving code at the same time has resulted in

many duplicate/conflicting file errors and at times entire project corruption, which required manually transporting our code into a new project file.

84

Work Schedule Diagram:

85

Gantt Chart goes hereee

86

Dictionary: Relational Database – A Database which organizes data into tables. Tables can be related to one another and each table entry can be uniquely identified by a combination of attributes. Customer Service Case - If a customer has a problem, they can see a customer service employee to set up a case, which stored information about their problem.

Database Table – A collection of related attributes in the database are stored in a table to organize the information, and allow easy access and look-up.

Record – A single row in a database table can be uniquely identified by certain attributes. UPC – Universal Product Code, a unique numerical identifier for a product. A barcode is used to encode the numerical identifier for scanning purposes when using a barcode scanner.

Alpha-Numeric – A character set consisting of A-Z, a-z, and 0-9. User Interface (UI) – The visual interface that a user interacts with to accomplish \ various tasks and functionalities within the software.

Log File – Formatted plain-text file that stores database data for backup and reference purposes.

Network Path – A path within a network which directs a software system to the location of certain items, this allows for the software to access the database or log files that are stored on a server separate from the local machine running the software. Transaction Type - Defined by an integer in our transactions table, there are two types.

Type 0: Purchase. Type 1: Return.

87

sam resume

88

jin resume

89

hamza resume

90

nick resume

91

chung resume

92

User Guide:

This is a user guide for the MegaMart Management System developed by Dragon Fruit. The purpose of this guide is to walk the user through the steps necessary to complete tasks within our software. Below you will find a table which directs the user to a specific page on which content pertaining to each of the topics below resides. Logging In p. 92 Menu Structure p. 92 General Departments p. 92 Inventory p. 92 Cash Register p. 93 Creating a Transaction p. 93 Management Department p. 93

Accounting Tab p. 93 Human Resources / Employees p. 94 Customer Service p. 94 Returns p. 94 Customer Service Cases p. 95

Administration p. 95 Backup and Restore p. 95 System Setup p. 95

User Profile p. 96 ClockIn and ClockOut p. 96 Messages p. 96 Sending a Message p. 96 Deleting a Message p. 96 Logging Out p. 96

93

Logging In: Upon running the software you will be presented with a login screen. You

must log into go any further in the software. Enter the provided credentials that you got from your manager. Both the username and password are casesensitive. Once you have entered the information hit the Login button. You will be logged in and redirected to the landing page for your position.

Menu Structure: The overall menu structure of the program is controlled primarily by

dropdown menus and tabbed pages. The program is generally broken down by department. To access another department all that you must do is click the dropdown in the top left of the screen. This menu is persistent and will always be accessible. From here on out this user guide will be generally broken down by department, and each feature that is accessible under a department will be described there. From the top right of the screen you can access your User Profile menu, here you can access your messages and your user profile. The User profile is where you will clockin and clockout for work.

General Departments: There are five general departments, they are: Grocery,

Electronics, Sporting/Recreation, Clothing and Home/Office. Each of these departments shares similar interfaces. Within this interface you can view, add, and modify inventory as well as view all of the employees whom are employed in that department.

Inventory: A view of the inventory is what you will see first when selecting one of the general departments. You are able to search by UPC or name in the search box at the bottom. By selecting an inventory item in the table you are able to click the modify button, which will load a new page with editable text fields containing the information about that inventory item. After modifying the fields you desire, you can click save or cancel in the bottom right corner, this will take you back to the inventory view page. The Add button functions identically to the Modify button except no selected item is required and the text fields will be blank.

94

Cash Register: The Cash Register view which can be selected from the department

drop down menu allows you to create transactions for customers.

Creating Transactions: To create a transaction you must select the item you wish to add to the purchase from the table on the left, you may also search for the item by UPC or use a barcode scanner to enter the UPC in the search field. once you have selected an item, enter the quantity that you wish to purchase in the dty field below the inventory table. Then click Add button. The item will be added to the purchase table on the right side of the screen. Repeat this process for all items that are to be purchased. Once all items have been added, to complete the purchase click the Checkout button in the bottom right corner. This will complete the transaction and store it in the database.

Management Department: Within the management department you are presented

with 3 tabs, each of these represents and houses the content for each of the 3 subdepartments of the management department. These 3 subdepartments and what can be done on their pages is described below.

Accounting Tab: Within the accounting tab, on the left side of the screen is a table containing the rate which each position is paid per hour. These values can be modified by selecting one and clicking the modify button at the bottom of the table. Once you have done this new text fields will appear directly below the table. Enter the updated rate in the field and click either the save or cancel button. On the right side of the screen is the Payroll and Report generation tools. By clicking the browse button next to either text field you are prompted to select a directory via a system dialog box. Once you have selected a directory and clicked ok the text field will be updated to display the selected directory. Clicking the Process Payroll or the Generate Report button will generate an output file containing the relevant information to which ever button was clicked at the destination you selected.

95

Human Resources / Employees: The Human Resources tab is purely for

managing employees. When you first visit the Human Resources tab you will see a table view containing all the employees that are currently employed at the store. You are able to search by typing in a keyword of search string in the search bar at the bottom of the screen. Clearing the search field and clicking the search button again will repopulate the table with all of the store’s employees. In the bottom right corner of the screen there are a few buttons. By selecting an employee in the table and clicking Modify, you will be redirected to another page which has editable text field containing all of the information about the selected employee. Make changes to any field that you need to and click the save or cancel button at the bottom right. This will update the employee record and return you to the employee table view. if you wish to add a new employee the process is the exact same as modifying an employee except you need not select an employee before clicking the add button. You may also delete an employee by selecting them and clicking the remove button.

Customer Service: Within the customer service tab you are presented with another set of tabs. These two tabs are accounting and customer service cases. Each of these is explained below.

Returns: When first visiting the returns page you are presented with a view of all of the transactions currently stored in the database. by selecting one of these transactions and then clicking the button near the bottom right of the table, called View Transaction, you will be presented with a breakdown of the items that were part of that transaction of the right side of the screen. You are then able to select individual items from this list and return a certain quantity of that item by typing the quantity you want to return and hitting the return button just under the table. This will add it to a list just below with all of the items you wish to return from that transactions. to complete a return just hit the Return button in the bottom right of the screen. This will create a return transaction in the database and flagg the original transaction as having returned item.

96

Customer Service Cases: The customer service case tab of the customer service subdepartments tab, allows you to view and add customer service cases. A custerms service case is a record of a complaint of problem that a customer had anc contacted us about. The left side of this screen has a table which lists all of the currently active cases. You can view inactive cases by hitting the button labeled Inactive. You can also flag an Active case to be inactive by selecting it in the table and clicking the Make Inactive button. If you need to create new customer service case, you can very easily do so by clicking the New button in the bottom right corner of the screen.This will make the text fields on the right side of the screen editable, allowing you to fill in the information about the new case. You must include a first and last name separated by a space for the customer. After providing the information, you need to click the save or cancel button in the bottom right corner. This will update the database and table view accordingly.

Administration: From within the administrative department’s page you have access to

2 sub pages which reside on tabs. Each of these are explained below.

Backup and Restore: The Backup and Restore page is where you will backup and restore the database file. To backup the database, you first must click the browse button and select a directory in which you wish to make a backup database file. Once you have selected a directory, the text field will be updated to show which directory you selected. Clicking the backup button will then make a backup database file of the current database. It will be named with the current data and time for easy recognition. To Restore a database file to make it become the current database file, you repeat a similar process, click browse select a directory and click restore. This will replace the current database file with the file selected.

System Setup: Within the System Setup Tab you are able to define what the payroll and report files will be called as well as select a database file via a file browser. once each of these fields has been modified to your liking clicking either save or cancel will make the corresponding changes to the settings file.

97

User Profile: ClockIn and ClockOut: ClockIn and ClockOut system will allow the management to keep track of the hours that employees have worked. Before employees begin work, they would need to clockin in order to get their hours counted. When they are done working, they would need to clockout. After they clockout, their worked hours would be calculated for the day.

ClockIn: Click the Clock In button to clock in if you have not clocked in. ClockOut: Click the Clock Out button if you are still clocked in.

Messages: Messaging will provide a way for employees to communicate with their colleagues.

Sending a Message: On the Messages Page, click New Message button. You will be directed to a page with a list of employees on the left. On the right side, you will be presented with a form. Select the recipient from the list of employees and the To text field will be changed to the user ID of the employee you selected. Fill the Subject and Message text fields. Date text field will be set to the date of sending the message. Click Send Message button to send the message.

Deleting a Message: On the Message Page, select the message you want to delete and click the Delete button.

Logging Out: Logging out would allow the user to exit the application, closing the

database connection and returning the user to the login screen. To logout, click the drop down menu from upper right corner and select Logout option.

megamart managemant final document

Documents