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
Interface
Controller
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,S
WC

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
Interface
Controller
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
Interface
Controller
Database
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
Interface
Controller
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
Interface
Controller
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
Interface
Controller
Database
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
Interface
Controller
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,S
WC

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,S
WC

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
include: Manual restoration of
databases
SW

UC83
include: Modify the network/local
paths to database servers and log
files
SW 1.0 UC88_Modity_Data_Path
Interface
Controller
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:
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:
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
Use Case 11: Create Customer Service Case

Overview:
Creates a customer service case for employees to deal with.

Preconditions:
2. The Customer Service Cases page must be displayed.

Scenario:

Employee button.
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.
clicks Ok button.
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:
2.Customer_Service_Page must be displayed.
3. User has privilege to access the page.

Scenario:

1.User clicks on
Display_Customer_Service_Case_Butt
on on Customer_Service_Page
1.Displays Customer_Service_Case_Table

Scenario Notes:
None

Postconditions:
1.Customer_Service_Case_Table is displayed

Exceptions:
2.Customer_Service_Case_Table is not accessible

Required GUI:
1.Customer_Service_Page

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:
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_Ser
vice_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:
2.No case is selected.

Required GUI:
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.
4. Clock_In_Clock_Out_View is displayed.

Scenario:

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:

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:

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


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

Exceptions:
2.No item is selected.

Required GUI:
1.Inventory_Table
2.Removed_Item_Pop_Up

Use Case Utilized:
1.UC35

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

Exceptions:
1.DB is not accessible

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_Butto
n
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:
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


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.

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:
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:
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:
2.Employee_Table is displayed

Scenario:

1.User clicks on
Seach_Employee_Butto
n
1.The table will display all the item that contains the typed
keyword.

Scenario Notes:

Postconditions:

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

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:
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:
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:
2.Transactions_Table is displayed

Scenario:

1.User clicks on
Seach_Transaction_Butt
on
1.The table will display the transaction relevant to the given
ID.

Scenario Notes:

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

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

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:

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)

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)

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)

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.

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

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:

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.

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.

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

More Related Content

Similar to MegaMart Managemant Final Document

MegaMart Managemant Final Document