Milestone 3 for project for online food ordering system
Milestone 3: Design Modeling – Due 11/11
The Design Modeling part should contain the following components:
a. Final Class Diagram (see page 299, fig 8-15 (5th Ed))
b. Package Diagram (see page 267, fig 7-21 (5th Ed))
c. Database Design (see page 353, fig 9-16 (5th Ed))
d. Data Access and Manipulation Design (see page 358, fig 9-21 (5th Ed))
2
Online Food Ordering
System
System Proposal Report
Grade: 70/100
Group – 5Sija Nepal, 1001732745
Sanju Nepal, 1001731590
Sita Rana Magar, 1001748816
Subhadra Paudel, 1001756766
Sarbani Tuladhar, 1001669
2208-INSY-5341-001-ANALYSIS-AND-DESIGN-FALL-2020
TABLE OF CONTENTS
TOPIC PAGE NO.
1. Activity Diagram ………………………………………………………………………………………………… 3
2. Use Cases Diagram ……………………………………………………………………………………………… 4
3. Use Cases Description …………………………………………………………………………………………. 5-11
A. Create Account ……………………………………………………………………………………………….. 5
B. Login ……………………………………………………………………………………………………………….. 6
C. Create Order …………………………………………………………………………………………………… 7
D. Review Order ………………………………………………………………………………………………….. 8
E. Order Payment ………………………………………………………………………………………………… 9
F. Delivery Information ……………………………………………………………………………………… 10
G. Create and Update Menu………………………………………………………………………………… 11
4. Initial Class Diagrams ………………………………………………………………………………………….. 12
5. Sequence Diagrams …………………………………………………………………………………………… 13-17
A. Login ………………………………………………………………………………………………………….. 13
B. Create Account ……………………………………………………………………………………………. 14
C. Update Account …………………………………………………………………………………………… 14
D. Create Menu ……………………………………………………………………………………………….. 15
E. Update Menu ……………………………………………………………………………………………… 15
F. Add to Cart ………………………………………………………………………………………………… 16
G. Edit Cart …………………………………………………………………………………………………….. 16
H. Place Order ………………………………………………………………………………………………… 17
1. Activity Diagram
When customer visit our site, the new customer can create new account, the old customer can directly sign in, look at the menu, create order, make a payment, and get it delivered.
2. Use Case Diagram
Here, we have designed the function of our system, and tried to show how it works using use case diagram. We have created 7 use cases for the system. They are as follows: Comment by Sikora, Riyaz: You mention 7 use cases but only list 5 below. You also show 8 and not 7 use cases in the use case diagram.
· Login
· Create Order
· Review Order
· Order Payment
· Delivery Information
Comment by Sikora, Riyaz: Activities related to Maintain & Update Menu use case are not shown in the activity diagram.
3. Use Case Description
: Comment by Sikora, Riyaz: Use Case Description for Provide
Customer
Information use case is missing.
A. Create New Account Comment by Sikora, Riyaz: There is no use case called “Create Account” mentioned in the Include relationships. A use case cannot have an include relationship with itself.
Use-Case Name: Create new account ID: 1 Importance level: High
Primary Actor: Customer User Case Type: Detail, Essential
Stakeholders and Interest:
Customer wants to create an account
Brief Description:
This use case describes how customer creates an account with valid contact information
Trigger:
A customer will create an account with username and password.
Type:
External
Relationships:
Association: Customer
Include: Create account, provide customer information Comment by Sikora, Riyaz: A call to Provide Customer Information use case should be included in the Normal Flow of Events.
Generalization:
Normal Flow of Events:
1. Customers create an account with either email or phone no.
2. Customer provides delivery address.
3. Customers can save their card information.
Sub flows:
Alternate / Exceptional flows:
If invalid information is entered, then error will occur.
B. Login
|
Use-Case Name: Login ID: 2 Importance level: High |
|
Primary Actor: Customer Use-Case Type: Detail, Essential |
|
Stakeholders and Interest:
Customer: wants to access menu and make an order |
|
Brief Description:
This use case describes how the user can login as customer and get access to menu |
|
Trigger: The customer clicks on the “login” button Type: |
|
Relationships:
Association: Customer Include Extend: Generalization: |
|
Normal Flow of Events:
1. The customer clicks on the “login” button on the Home page. 2. The customer enters their login username and password. 3. The customer is verified with correct login information. 4. After successful login, the customer arrives at the page of the menu list. 5. The customer can click the logout button to log out from their account. |
|
Sub flows:
S-1: login as customer The customer sees a screen showing the menu of the restaurant . |
|
Alternate / Exceptional flows:
1. Incorrect username and password. 2. Retry username and password option. 3. The customer arrives at the home page to retry. |
C. Create Order
|
Use-Case Name: Create an order ID: 3 Importance level: High |
|
Primary Actor: Customer Use-Case Type: Detail, Essential |
|
Stakeholders and Interest:
Customer: wants to create a new order |
|
Trigger:
The user clicks on the “add item” button Type: |
|
Relationships:
Association: Include Extend: Generalization: |
|
Normal Flow of Events:
1. The customer has access to the menu system. 2. The customer clicks on the add item button beside the food item in the menu list to choose the food they want, and the food item is secured in the shopping cart. 3. The customer can go to the shopping cart page after the order is created. 4. The customer can modify their order like adding and removing food items or any additional changes in the shopping cart. 5. The customer then clicks on “checkout cart”. |
|
Alternate / Exceptional flows:
1. Incomplete information. 2. The Customer will see an error. 3. The Customer will return to shopping cart page and continue completing the information. |
D. Review Order
|
Use-Case Name: Review order ID: 4 Importance level: High |
|
Primary Actor: Customer Use-Case Type: Detail, Essential |
|
Stakeholders and Interest:
Customer: wants to ensure the order is placed correctly with the right address. |
|
Brief Description:
This use case describes how customers can review their order and confirm the delivery address. |
|
Trigger:
Customer clicks on the “checkout cart” button. Type: |
|
Relationships:
Association: Customer Include: Review order Comment by Sikora, Riyaz: A use case cannot have an include relationship with itself. There is an include with Make a Payment use case shown on the use case diagram. Extend: Generalization: |
|
Normal Flow of Events:
1. The customer will review the order they created. 2. The customer can still go back and make changes to their order. 3. The customer provides an address for delivery or can choose the one that exists in file. 4. The customer can add special delivery instructions. 5. The customer clicks on the place order button which takes them to the order payment page. |
|
Alternate / Exceptional flows:
1. If the customer has an incomplete address filled. 2. The customer will see a page showing errors. 3. The customer is required to return to the delivery information section to fill the correct address. |
E. Make Payment
|
Use-Case Name: Make a payment ID: 5 Importance level: High |
|
Primary Actor: Customer Use-Case Type: Detail, Essential |
|
Stakeholders and Interest: Customer |
|
Brief Description:
This use case describes how the customer makes a payment to pay for their order. |
|
Trigger:
The customer presses the “Place Order” button. Type: |
|
Relationships:
Association: Customer Include: Make a payment Comment by Sikora, Riyaz: A use case cannot have an include relationship with itself. There is an include relationship with Order and Delivery Confirmation shown on the use case diagram. Extend: Generalization: |
|
Normal Flow of Events:
1. The customer can use the payment options they saved previously while creating their account. 2. The customer can choose different cards for payment. |
|
Sub flows:
None |
|
Alternate / Exceptional flows:
1. If incorrect or incomplete card information is filled. 2. The customer will see a page showing errors. 3. The customer is required to return to the “order payment” page and fill in correct information. |
F. Delivery Information
|
Use-Case Name: Order and Delivery confirmation ID: 6 Importance level: High |
|
Primary Actor: Customer, Restaurant, Driver User Case Type: Detail, Essential |
|
Stakeholders and Interest:
Customer: to get the confirmation notification of the order Restaurant: to fulfill customer order Driver: to deliver food |
|
Brief Description: This use case describes the order confirmation that the customer gets, how the restaurant receives the food order, and the driver delivers food to the designated address. |
|
Trigger:
The customer clicks the “make the payment” option. The restaurant and the driver get notified. Type: |
|
Relationships:
Association: Customer, Restaurant, Driver Include: Order and Delivery Information Comment by Sikora, Riyaz: A use case cannot have an include relationship with itself. Extend: Generalization: |
|
Normal Flow of Events:
1. After finalizing the order and information and making the payment, the customer will click the “make a payment” button and the person will get the order confirmation email or message. 2. The restaurant will be notified about the order as well as the driver. 3. The customer will receive an email or message regarding any update of the order status and delivery. |
|
Sub flows:
1. Once the order is ready, the driver heads towards the delivery address. 2. The restaurant will provide the estimated time of delivery to the customer. |
|
Alternate / Exceptional flows:
1. If street hazards like traffic is on way than the customer will be notified about delay. 2. The customer will get notified if any order cannot be fulfilled or any special demand cannot be fulfilled. |
G. Create and Update Menu
|
Use-Case Name: Maintain and Update menu ID: 7 Importance level: High |
|
Primary Actor: IT Department /Admin User Case Type: Detail, Essential |
|
Stakeholders and Interest:
IT Department: to access the app system to check if the app functions correctly without any technical error and to create and update menu lists in the app. |
|
Brief Description:
This use case describes how the IT department creates the menu list and how the changes in the menu or the whole system are dealt. |
|
Trigger:
IT people will access the system. Type: |
|
Relationships:
Association: IT Department Include: Create menu and Update menu Comment by Sikora, Riyaz: These include relationships are not shown on the use case diagram. Extend: Generalization: |
|
Normal Flow of Events:
1. The IT Department will access the system in order to check if it functions correctly. 2. The IT Department will update the menu as per the need of the restaurant. 3. The IT Department will provide solutions for any technological difficulties that occur while accessing the application. |
| Alternate / Exceptional flows: |
4. Class Diagram
In our Initial Class Diagram, we have created 5 classes for our system known as Customer Class, Admin Class, Shopping Cart Class, Checkout Class, and Menu List Class. All these classes have their own functions.
5. Sequence Diagram
In the sequence diagram, it shows the interactions of objects arranged in time series and the series of messages exchanged between objects required to carry out the functionality of the scenario.
A. Login:
B. Create Account:
C. Update Account
: Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
D. Create menu
: Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
E. Update menu
: Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
F. Add to Cart
: Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
G. Edit Cart
: Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
H. Place Order Comment by Sikora, Riyaz: There is no such use case in the use case diagram.
INSY3305/5341
Information Systems Analysis & Design
Fall 2020
Project and Presentation
Introduction
Students are required to do a project on system analysis and design for a realistic
problem of their choice. The project should consist of three main components: the system
proposal, analysis modeling, and design modeling.
Formation of Groups
Ideally there should be 5-6 students in each group. The formation of groups will be
finalized on 9/3. Students who have not formed a group would be grouped randomly.
Deliverables
The following milestone reports will be due by email. All milestones and the final
project report should be typed/printed and not handwritten.
Milestone 1: System Proposal – Due 10/1
The System Proposal should contain the following components:
a. Introduction about the problem domain
b. System Request (see Lecture Slides Chapter 3)
c. Feasibility Analysis (see Lecture Slides Chapter 3)
d. Requirements Definition (see Lecture Slides Chapter 3)
Milestone 2: Analysis Modeling – Due 10/22
The Analysis Modeling part should contain the following components:
a. Activity Diagram (see page 133, fig 4-8 (5th Ed))
b. Use Cases Diagram (see page 155, fig 4-21 (5th Ed))
c. Use Cases Descriptions (see page 143, fig 4-13 (5th Ed))
d. Class Diagram (see page 177, fig 5-7 (5th Ed))
e. Sequence Diagrams (see page 205, fig 6-1 (5th Ed))
Milestone 3: Design Modeling – Due 11/12
The Design Modeling part should contain the following components:
a. Final Class Diagram (see page 299, fig 8-15 (5th Ed))
b. Package Diagram (see page 267, fig 7-21 (5th Ed))
c. Database Design (see page 353, fig 9-16 (5th Ed))
d. Data Access and Manipulation Design (see page 358, fig 9-21 (5th Ed))
Final Project Report
The final project report will be due on 12/3 by email. The final report should consist
of the above-mentioned four main parts: Introduction, System Proposal, Analysis
Modeling, and Design Modeling. There should be a logical flow between the sections with
a brief narrative for each section explaining the different components.
Important Dates
9/3 – Group formations
10/1 – Milestone 1 (System Proposal) due by email
10/22 – Milestone 2 (Analysis Modeling) due by email
11/12 – Milestone 3 (Design Modeling) due by email
12/3 – Final project report due by email
Shipment Delivery Status System
Kaixuan Yin, 10011417
Chuqi Wang, 1001141754
Guoxin Gu, 1001145403
Kaixin Tian, 1001141755
2148-INSY-5341-001-ANALYSIS-AND-DESIGN–2014-Fall
Shipment Delivery Status
System
Final report
Team 3
2014/12/11
Shipment Delivery Status System
Introduction
This document is the final report of the team project. The project will be shown in four parts:
planning, analysis, design and implementation.
The Planning part includes the introduction about the problem domain, System Request,
Feasibility analysis and Requirements Definition.
The analysis part includes the activity diagram, use case descriptions, use case diagrams, initial
class diagrams and sequence diagrams.
The design part includes the final class diagram, package diagram, database design and data
access and manipulation design.
The implementation part includes the screen shot of the software.
1
Shipment Delivery Status System
Category
…………………………………………………………………………………………………………………………… 3
1.1 Introduction about the problem domain ………………………………………………………………………….. 3
1.2 System Request …………………………………………………………………………………………………………….. 4
1.3 Feasibility analysis …………………………………………………………………………………………………………. 5
1.4 Requirements Definition ………………………………………………………………………………………………… 6
……………………………………………………………………………………………………………………………. 7
2.1 Activity diagram ……………………………………………………………………………………………………………. 7
2.2 Use Case Diagram …………………………………………………………………………………………………………. 8
2.3 Use Case Description …………………………………………………………………………………………………….. 9
2.4 Initial Class Diagram …………………………………………………………………………………………………….. 15
2.5 Sequence Diagram ………………………………………………………………………………………………………. 16
……………………………………………………………………………………………………………………………. 22
3.1 Final Class Diagram ……………………………………………………………………………………………………… 22
3.2 Package Diagram …………………………………………………………………………………………………………. 23
3.3 Database design ………………………………………………………………………………………………………….. 24
3.4 Data access and manipulation design …………………………………………………………………………….. 25
………………………………………………………………………………………………………………. 26
2
Shipment Delivery Status System
Part 1: Planning
1.1 Introduction about the problem domain
Nowadays, more and more people buy things from the Internet rather than go to malls. This
phenomenon led to the development of the courier industry. Besides, people claims to have
high quality delivery process and wants to get the package information at any time they want.
Some customers may encounter a problem when they are waiting a shipment: don’t know when
their package will arrive. They can only keep checking the mailbox or call the express company.
So the system is developed for an express company and is aimed at serving the customers that
have a shipment.
3
Shipment Delivery Status System
1.2 System Request
System Request: Shipment Delivery Status System
Project Sponsor:
Business Need: The system is developed for an express company and is aimed at serving
the customers that have a shipment.
Business Requirements:
Three kinds of users can access the system. They are: customers, couriers, and administrator.
With providing the package number to the system, customers should be able to access the status of
package they have send or will receive. The status should include: date of being sent out, route of
shipment, shipping method (by air/train/car), current location, and estimated remaining delivery
time of arriving.
The couriers should access to the system and update the location of shipment as soon as they get
to a transit station. At the beginning of delivery, the couriers should also input the information of
the package into the system, which should include: package number, route of shipment, and
shipping method. Couriers need to be verified with their account and password before they update
the
shipment information.
There is only one administrator. He/she has a unique account to access the system. The
administrator will be able to delete, change, and create account information of each courier.
He/she can also inquire the history record of each shipment and make a decision of whether to
delete it or not.
Business Value:
Some customers may encounter a problem when they are waiting a shipment. That is they sometimes
don’t know when their package will arrive if there occurs a delay because of bad weather or other
accident. By applying this system, customers can check the status of their package easily without
continuing inquiring the company by a phone call.
As a result, the system can help increase service quality of an express company, also improve customers’
satisfaction when they will receive or send a package delivered by the express company. This will help
the company in seeking out potential customers, as well as improve competitiveness among various
express companies.
4
Shipment Delivery Status System
1.3
Feasibility analysis
Feasibility analysis
Technical Feasibility
The shipment delivery status management system is feasible technically, although there is some risk.
The project risk regarding familiarity with shipment delivery status management system is medium
• The basic process of the shipment delivery is clear.
• The specific content of the status information database is not clarified.
The project risk regarding familiarity with programming language is medium
• There are four people included in the project, and two of them have confident software engineering
experience before.
• Other two people have the experience to do some small Java programs and know the basic concept
of Java well.
• Development tools for the program are available on the Internet.
The project size is considered medium risk
• The project team will include four people.
• The project will last for about one and a half months. The time will be plenty enough for the project
unless delayed by any personal issues.
• The system only needs one delivery loop.
The compatibility should be good
• The system does not need to integrate with any existing technology.
• The system uses a simple database to store the shipment status data.
Economic Feasibility
Actually there will be no financial cost in this project.
The company is expected to reduce management cost since the shipment information can be easily uploaded
through the system. The company can gain more customers since the customers are expected to appreciate
for the easy way to know the up-to-date delivery information from the system.
Organizational Feasibility
From the organizational view, the project has low risk.
• The system’s size and function suit the champion’s need.
• Every team member knows the concept of the system and how it works.
• The customers are expected to appreciate for the easy way to know the up-to-date delivery
information from the system.
• The couriers are expected to appreciate the new shortcut way to build new shipment and update
shipment information.
5
Shipment Delivery Status System
1.4
Requirements Definition
Requirements Definition
Nonfunctional Requirements
1. Operational Requirements
• The system will calculate the estimated remaining delivery time according to the location and
shipping method.
• The system will be able to show the lists of couriers’ accounts to the administrator.
2. Performance Requirements
None
3. Security Requirements
• There is a unique account for the administrator.
• Each courier’s username and passport is decided by administrator.
• Every user can access the status of package by inputting the package number without logging in.
4. Cultural and Political Requirements
None
Functional Requirements
1. Status inquiry
• By providing package number. Users of this system will be able to inquire the detail status of
package they sent out or will receive.
• The status should include: route of shipment, shipping method, current location, and estimated
remaining delivery time.
2. Input package information
• At the beginning of a shipment, the related courier will input the information of the package
into the system. The information should include: start point, route of shipment, and shipping
method.
• By providing package number, the couriers will be able to access to the system and update the
location of shipment during the shipping.
3. Management
• The administrator has ability to manage (modify, create) the username and password of each
courier.
• The administrator can also access to the list of accounts.
4. Log in
• Couriers and administrator should input their username and password before they operate the
system.
5. Maintain package information
• The system needs a database of information about packages and accounts.
6
Shipment Delivery Status System
Part 2: Analysis
2.1 Activity diagram
The first part of our analysis is activity diagram, which is showed following.
We can see it has two loops. Whenever a user access to our system, they can do two things in the
homepage: to search a package or login. And if he/she login, the system will check their identity and
show them different modules.
7
Shipment Delivery Status System
2.2 Use Case Diagram
We designed 6 use cases for the system, which contains almost all of its functions. They are:
• Login
• Create package
• Update package
• Create account
• Update account
• Get package Detail
Please find their relationships in use case diagram and details in use case descriptions.
8
Shipment Delivery Status System
2.3 Use Case Description
Use-Case Name: Login ID: 1 Importance Level: high
Primary Actor: User Use Case Type: Detail, essential
Stakeholders and Interests:
Courier – wants to access the create package module and update package info module
Administrator – wants to access the create account module and update account info module
Brief Description:
This use case describes how the users log into the system and access to different module
Trigger:
The user clicks on the “login” button
Type:
External
Relationships:
Association: Administrator, Courier
Include: create package, update package info, create account, update account info
Extend:
Generalization:
Normal Flow of Events:
1. The user clicks on the “login” button in home page
2. The user enters their login username and password
3. The username and password is available and the user is verified as courier or administrator
If it is verified as courier, the S-1: login as courier subflow is performed.
If it is verified as administrator, the S-2: login as administrator subflow is performed.
4. The user clicks the logout button
5. The user returns to the home page
Sub flows:
S-1: login as courier
The user sees a page showing “create package”, “update package info” buttons
S-2: login as administrator
The user sees a page showing “create account” button and “update account info” button
Alternate/Exceptional Flows:
3a1: The username or password is not valid
3a2: The system shows an error page
3a3: The user is returned to home page
9
Shipment Delivery Status System
Use-Case Name: Create package ID: 2 Importance Level: high
Primary Actor: Courier Use Case Type: Detail, essential
Stakeholders and Interests:
Courier – wants to create a new package
Brief Description:
Trigger:
The Courier clicks on the” create package” button
Type:
External
Relationships:
Association:
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The courier accesses to the system
2. The courier clicks on “create package” button
3. The courier sees some blanks waiting to be filled in with the package information
4. The courier enters some package information to the tables
5. The courier clicks on the “submit” button
6. The new package is added to database
7. The courier can repeat 3-6, or quit the system
Sub flows:
Alternate/Exceptional Flows:
6a1: Not all blanks are filled
6a2: Courier will see a page showing error
6a3: Courier will return to the create package page and continue filling the infomation
10
Shipment Delivery Status System
Use-Case Name: Update package info ID: 3 Importance Level: high
Primary Actor: Courier Use Case Type: Detail, essential
Stakeholders and Interests:
Courier – wants to ensure the satisfaction of customers
Visitor – wants to see the newest status of package
Brief Description:
This use case describes how courier update the status of a package
Trigger:
Courier clicks on the “update package info” button
Type:
External
Relationships:
Association:
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The courier accesses to the system and clicks on the “update package info” button
2. The courier inputs the ID of package that need be modified
3. System will match the package ID in database
4. The courier inputs the current location of that package
5. The courier clicks on the “submit” button
6. The package’s information is updated
7. The courier can repeat 2-6, or quit the system
Sub flows:
Alternate/Exceptional Flows:
3a1: The inputted number can’t be found in database.
3a2: Courier will see a page showing error
3a3: Courier will return to the package number inputting page
11
Shipment Delivery Status System
Use-Case Name: Create Account ID: 4 Importance Level: high
Primary Actor: Administrator Use Case Type: Detail, essential
Stakeholders and Interests:
Administrator – wants to create new accounts for new couriers
Courier – wants to log in the system
Brief Description:
This use case describes how the administrator create the usernames and passwords for couriers
Trigger:
The administrator clicks on the “create account” button
Type:
External
Relationships:
Association:
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The administrator access to the system
2. The administrator click on “create account” button
3. The system shows a table with blanks for administrator to type in the new account information
4. The administrator types in the new username and password
5. The administrator clicks on “submit”
6. The new account is added to database
7. The administrator can repeat 3-6 or quit the system
Sub flows:
Alternate/Exceptional Flows:
6a1: Not all blanks are filled
6a2: Administrator will see a page showing error
6a3: Administrator is returned and continue to fill in the blanks
12
Shipment Delivery Status System
Use-Case Name: update account info ID: 5 Importance Level: high
Primary Actor: administrator Use Case Type: Detail, essential
Stakeholders and Interests:
Administrator – wants to change the couriers’ account information
Brief Description:
This use case describes how an administrator change the couriers’ account information
Trigger:
Administrator access to the system and press the “update account info” button
Type:
External
Relationships:
Association:
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The administrator accesses to the home page and press the “update account info” button
2. The system shows all accounts as a list, there exist buttons beside each account item called
“update”
3. The administrator choose the account record he wants to update and clicks on the “update”
button next to the record
4. The system will provide a table for administrator to change the information of the account
5. The administrator type the new information into the table
6. The administrator clicks on the “submit” button
7. The administrator can repeat 2-6, or quit the system
Sub flows:
None
Alternate/Exceptional Flows:
6a1: Not all tables have been filled
6a2: Administrator will see a page showing error
6a3: Administrator is returned and continue to fill in the blanks
13
Shipment Delivery Status System
Use-Case Name: get package detail ID: 6 Importance Level: high
Primary Actor: visitor Use Case Type: Detail, essential
Stakeholders and Interests:
Visitor – wants to know current location and estimated remaining time of arriving of a specific
package
Brief Description:
This use case describes how visitor get the package information they want
Trigger:
Visitor access to the system
Type:
External
Relationships:
Association: Visitor
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The visitor accesses to the home page and input an order ID
2. The visitor clicks on the “search” button
3. The system will match the ID number in database
4. An item with same order ID in the database is found
5. The system calculates the remaining time of delivery
6. Detail status of the package and the remaining time are shown to the visitor
7. visitor can choose to return to home page or quit the system
Sub flows:
None
Alternate/Exceptional Flows:
3a1: The inputted number can’t be found in database.
3a2: Visitor will see a page showing error
3a3: Visitor can choose to return to the home page or quit the system
14
Shipment Delivery Status System
2.4 Initial Class Diagram
This is our initial Class Diagram. We’ve produced six classes for our project: User Class, Admin Class,
Courier Class, Package Class and DBConnection Class.
There is a generalization relationship between User class, Admin Class and Courier Class, and the User
class is a generalization of Admin class and Courier Class, the Admin class and Courier Class are two
special cases of User class.
The administrator can manage the accounts of couriers through the method in the Admin class, and the
Couriers can manage the package information through the methods in the Courier Class.
DBConnection class is used to connect the system with the database it needed.
Package class is used to store the package information gathered from the database. Also the method
calculateTime() can be used to calculate the remaining delivery time.
15
Shipment Delivery Status System
2.5 Sequence Diagram
The sequence diagrams describe the objects that participate in the use cases and the messages that pass
between them over time. One sequence is corresponded to one use case.
16
Shipment Delivery Status System
17
Shipment Delivery Status System
18
Shipment Delivery Status System
19
Shipment Delivery Status System
20
Shipment Delivery Status System
21
Shipment Delivery Status System
Part 3: Design
3.1 Final Class Diagram
The final class diagram is slightly different with the initial one. Firstly, the DBConnection class
has been deleted in the diagram because we found that there is no need to put the
DBConnection class in the class diagram. Secondly, two new classes are added in to the diagram:
ShipmentDetail class and BuildRoute diagram.
The ShipmentDetail class is used to contain the calculateTime() method and some of the
shipment information.
The BuildRoute class is used to connect the courier class and package class. It can be used to
show which courier is responsible for a certain package in a certain route.
22
Shipment Delivery Status System
3.2 Package Diagram
The Package Diagram is shown below.
User class with Admin class and Courier class is packaged together to be the User Package.
The Package class, ShipmentDetail class and BuildRoute class is packaged together to be the
Shipment Package since they all contain some information of the package.
23
Shipment Delivery Status System
3.3 Database design
The database design is shown below.
As shown in the diagram, the Route Table is used to be the Association table between Package
Table and Account Table.
The package Table stores the package basic information such as package ID, the start point, the
destination and etc. The Account Table contains the administrator and couriers’ account
information. The Route Table contains the divided route information for every package. The
shipMeSpeed Table defines the speed for each ship methods.
24
Shipment Delivery Status System
3.4 Data access and manipulation design
The Data access and manipulation design shows the relationship between classes and databases.
Classes use DAM class to connect the database. The line pointed from database to class shows
the corresponding relationship between classes and databases.
25
Shipment Delivery Status System
Part 4: Implementation
The implementation contains three parts: the interface (folder: “sdss”), which is coded by javascript and
need a browser to display; the program (folder: “sdss_src”) which is coded by java; and the database
(folder: “database”) which is constructed by SQL. The applications we used in our implementation are
Dreamweaver, Eclipse, Tomcat, and Oracle
The screenshots of the system are showed following:
1. The homepage. Customer can access their package’s information by input the number. And the login
module is on the upper-right.
2. Login as administrator, we can see the modules of modify couriers’ account. Let’s create a new
account for courier “Charlie”
26
Shipment Delivery Status System
3. Now we can login as a courier.
4. We create a package with route 1, 2, 3, which means it will be delivered from 1 to 2, and then from 2
to 3.
27
Shipment Delivery Status System
5. An ID for this package has been created.
6. We now go back to the homepage and search for this package. We can see the details including
remaining time, location, shipment method as well as the routes. (The courier of route 2 states null
because the package has not been delivered to the start point of route 2.)
28
Shipment Delivery Status System
7. Then we login as another courier Kevin and update the location of this package.
8. We can see the updated information.
29
Shipment Delivery Status System
30
- Part 1: Planning
1.1 Introduction about the problem domain
1.2 System Request
1.3 Feasibility analysis
1.4 Requirements Definition
Part 2: Analysis
2.1 Activity diagram
2.2 Use Case Diagram
2.3 Use Case Description
2.4 Initial Class Diagram
2.5 Sequence Diagram
Part 3: Design
3.1 Final Class Diagram
3.2 Package Diagram
3.3 Database design
3.4 Data access and manipulation design
Part 4: Implementation
INSY3305/5341
Information Systems Analysis & Design
Fall 2020
Project and Presentation
Introduction
Students are required to do a project on system analysis and design for a realistic
problem of their choice. The project should consist of three main components: the system
proposal, analysis modeling, and design modeling.
Formation of Groups
Ideally there should be 5-6 students in each group. The formation of groups will be
finalized on 9/3. Students who have not formed a group would be grouped randomly.
Deliverables
The following milestone reports will be due by email. All milestones and the final
project report should be typed/printed and not handwritten.
Milestone 1: System Proposal – Due 10/1
The System Proposal should contain the following components:
a. Introduction about the problem domain
b. System Request (see Lecture Slides Chapter 3)
c. Feasibility Analysis (see Lecture Slides Chapter 3)
d. Requirements Definition (see Lecture Slides Chapter 3)
Milestone 2: Analysis Modeling – Due 10/22
The Analysis Modeling part should contain the following components:
a. Activity Diagram (see page 133, fig 4-8 (5th Ed))
b. Use Cases Diagram (see page 155, fig 4-21 (5th Ed))
c. Use Cases Descriptions (see page 143, fig 4-13 (5th Ed))
d. Class Diagram (see page 177, fig 5-7 (5th Ed))
e. Sequence Diagrams (see page 205, fig 6-1 (5th Ed))
Milestone 3: Design Modeling – Due 11/12
The Design Modeling part should contain the following components:
a. Final Class Diagram (see page 299, fig 8-15 (5th Ed))
b. Package Diagram (see page 267, fig 7-21 (5th Ed))
c. Database Design (see page 353, fig 9-16 (5th Ed))
d. Data Access and Manipulation Design (see page 358, fig 9-21 (5th Ed))
Final Project Report
The final project report will be due on 12/3 by email. The final report should consist
of the above-mentioned four main parts: Introduction, System Proposal, Analysis
Modeling, and Design Modeling. There should be a logical flow between the sections with
a brief narrative for each section explaining the different components.
Important Dates
9/3 – Group formations
10/1 – Milestone 1 (System Proposal) due by email
10/22 – Milestone 2 (Analysis Modeling) due by email
11/12 – Milestone 3 (Design Modeling) due by email
12/3 – Final project report due by email