System Design

1








Group 6Sunny PangKiana ArashiMariam El BadanGroup 6Sunny PangKiana ArashiMariam El BadanCITM430FALL2012Professor: Junlian XiangCITM430FALL2012Professor: Junlian XiangSportsShoes.comPhase 2SportsShoes.comPhase 2

Group 6

Sunny Pang
Kiana Arashi
Mariam El Badan

Group 6

Sunny Pang
Kiana Arashi
Mariam El Badan

CITM430FALL2012
Professor: Junlian Xiang
CITM430FALL2012
Professor: Junlian Xiang
SportsShoes.com
Phase 2

SportsShoes.com
Phase 2

Introduction 4
Context Diagram 5
Use case diagram: 6
1: Customer Management Module 7
1.1: Use Case 1 – Register Customer 7
1.1.1:Use Case Model – Register Customer 7
1.1.2: Activity Diagram – Register Customer 8
1.1.3 System Sequence Diagram – Register Customer 9
1.1.4 Sequence Diagram – Register Customer 10
1.2: Use Case 2 – Update Account Details 11
1.2.1:Use Case Model – Update Account Details 11
1.2.2: Activity Diagram – Update Account Details 12
1.2.3: System Sequence Diagram – Update Account Details 13
1.2.4: Sequence Diagram – Update Account Details 14
2: Online Ordering Module 15
2.1: Use Case 1 – Search shoes 15
2.1.1: Use Case Model – Search Shoes 15
2.1.2: Activity Diagram – Search shoes 16
2.1.3: System Sequence Diagram – Search shoes 17
2.1.4: Sequence Diagram – Search shoes 18
2.2: Use Case 2 – Browse Shoes 19
2.2.1: Use Case Model – Browse Shoes 19
2.2.2: Activity Diagram – Browse Shoes 20
2.2.3: System Sequence Diagram – Browse Shoes 21
2.2.4: Sequence Diagram – Browse Shoes 22
2.3: Use Case 3 – Add to Cart 23
2.3.1: Use Case Model – Add to Cart 23
2.3.2: Activity Diagram – Add to Cart 24
2.3.3: System Sequence Diagram – Add to Cart 25
2.3.4: Sequence Diagram – Add to Cart 26
2.4: Use Case 4 – View Cart 27
2.4.1: Use Case Model –View Cart 27
2.4.2: Activity Diagram – View Cart 28
2.4.3: System Sequence Diagram – View Cart 29
2.4.4: Sequence Diagram – View Cart 30
2.5: Use Case 5 – Checkout 31
2.5.1: Use Case Model – Checkout 31
2.5.2: Activity Diagram – Checkout 32
2.5.3: System Sequence Diagram – Checkout 33
2.5.4: Sequence Diagram – Checkout 34
2.6: Use Case 6 – Use Points 35
2.6.1: Use Case Model – Use Points 35
2.6.2: Activity Diagram – Use Points 36
2.6.3: System Sequence Diagram – Use Points 37
2.6.4: Sequence Diagram – Use Points 38
2.7: Use Case 7 – Use Credit Card 39
2.7.1: Use Case Model – Use Credit Card 39
2.7.2: Activity Diagram – Use Credit Card 40
2.7.3: System Sequence Diagram – Use Credit Card 41
2.7.4: Sequence Diagram – Use Credit Card 42
2.8: Use Case 8 – View Order History 43
2.8.1: Use Case Model – View Order History 43
2.8.2: Activity Diagram – View Order History 44
2.8.3: System Sequence Diagram – View Order History 45
2.8.4: Sequence Diagram – View Order History 46
2.9: Use Case 9 – Print Order History 47
2.9.1: Use Case Model – Print Order History 47
2.9.2: Activity Diagram – Print Order History 48
2.9.3: System Sequence Diagram – Print Order History 49
2.9.4: Sequence Diagram – Print Order History 50
2.10: Use Case 10 – Create Order 51
2.10.1: Use Case Model – Create Order 51
2.10.2: Activity Diagram – Create Order 52
2.10.3: System Sequence Diagram – Create Order 53
2.10.4: Sequence Diagram – Create Order 54
2.11: Use Case 11 – Cancel Order 55
2.11.1: Use Case Model – Cancel Order 55
2.11.2: Activity Diagram – Cancel Order 56
2.11.3: System Sequence Diagram – Cancel Order 57
2.11.4: Sequence Diagram – Cancel Order 58
3: Points Module 59
3.1:Use Case 1 – Add points 59
3.1.1:Use Case Model – Add Points 59
3.1.2: Activity Diagram – Add Points 60
3.1.3: System Sequence Diagram – Add Points 61
3.1.4: Sequence Diagram – Add Points 62
3.2: Use Case 2 – Refund Credit Card 63
3.2.1: Use Case Model – Refund Credit Card 63
3.2.2: Activity Diagram – Refund Credit Card 64
3.2.3: System Sequence Diagram – Refund Credit Card 65
3.2.4: Sequence Diagram – Refund Credit Card 66
3.3: Use Case 3 – View Point Balance 67
3.3.1: Use Case Model –View Point Balance 67
3.3.2: Activity Diagram – View Point Balance 68
3.3.3: System Sequence Diagram – View Point Balance 69
3.3.4: Sequence Diagram – View Point Balance 70
4: Inventory Management Module 71
4.1: Use Case 1 – Adjust Inventory (sub functional) 71
4.1.1: Use Case Model – Adjust Inventory (sub functional) 71
4.1.2: Activity Diagram – Adjust Inventory (sub functional) 72
4.1.3: System Sequence Diagram – Adjust Inventory (sub functional) 73
4.1.4: Sequence Diagram – Adjust Inventory (sub functional) 74
4.2: Use Case 2 – Adjust Inventory (user goal) 75
4.2.1: Use Case Model – Adjust Inventory (user goal) 75
4.2.2: Activity Diagram – Adjust Inventory (user goal) 76
4.2.3: System Sequence Diagram – Adjust Inventory (user goal) 77
4.2.4: Sequence Diagram – Adjust Inventory (user goal) 78
Domain Model 79
Design Class Diagram 80
Workload Assignment 81


Introduction

The system is defined for SportsShoes.com is to set up an effective and efficient online store in order to open an e-commerce selling channel. SportsShoes.com is a sports shoe agent who is sells all brands of sports shoes.
For this phase, we assumed that customer who can become a registered member is one of two actors that would interact with the system, the other being a SportsShoes.com agent. Through the system customers can search or browse all brands of shoes and access to the catalogue of all shoes information. Shoes can be sorted under brands such as Nike, Adidas, Puma, North Face, etc., and type, such as running, hiking, skating, soccer, etc.
In order to purchase shoes customers must register themselves and must log in to the system. Registered members can gain points for their purchases after the cancellation period has passed (5 days) and use points as currency on future purchases. If customers are not satisfied with their purchases they can cancel the orders within 5 days.
Registered members are also able to update their personal information, view their past orders history and print them. The system is able to keep track of inventory and update it for every shipping in or shipping out by both customers and vendors.



Context Diagram











Use case diagram:



Figure Use Case Diagram

1: Customer Management Module
1.1: Use Case 1 – Register Customer
Register Customer: is the first step a customer needs to take in order to start interacting with the system, with his/her unique identity. The customer first visits the website, ask the system to register him, in order to have a unique profile in the system. The system asks for some information in order to understand its customer's better. Some of the basic information needed is First & Last Name, Email Address, desired password, home address, business address (if available) telephone number. The system then try to verify if the email address is in use and available to be used for order confirmation, or for database use. Then after verifying the email the system can either confirm the email and show a successful message, or if the email isn't right, then the system asks the customer to try again. This process is demonstrated in the three diagrams below: Use Case Model, Activity Diagram, System sequence diagram and system diagram.
1.1.1:Use Case Model – Register Customer

Use Case Name:
Register Customer
Scenario:
Customer registers online
Triggering Event:
Customer wants to create a SportsShoes.com account
Scope:
Customer Management Module
Level:
User-goal
Brief Description:
This use case describes how a customer will create a SportsShoes.com account online. Registered members are able to place orders, and update their personal information. The customer must enter their e-mail address, desired password, first name, last name, home address, business address, and telephone number. The e-mail is checked to determine if it is valid and is unregistered. The remainder of the field are checked for completeness by the system.
Actors:
Customer
Related Use Cases:
None
Stakeholders:
Administrators, a new entry (registered member) is inserted into the system
Special Conditions:
None
Frequency:
Very frequent, all new customers requires a new account
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
Customer should not have an account in the database.
Post-Conditions:
Customer information is inserted into the user database.
Flow of Events:
Actor
System

Customer requests to register
Customer enters personal information







Display registration page

2.1 Validate e-mail to ensure it is unregistered and in proper format
2.2 Check fields to ensure all entries are filled
2.3 Create registered member account for customer
2.4 Display confirmation message for account creation.
2.5 Registered member is logged in to the system and directed to the log in home page
Exceptional Conditions:
If customer entered invalid e-mail, display invalid e-mail error message, go to step 2
If customer left any personal messages blank, display blank information error message, go to step 2
Table Register Customer Use Case Description

1.1.2: Activity Diagram – Register Customer


Figure Register Customer Activity Diagram


1.1.3 System Sequence Diagram – Register Customer



Figure Register Customer System Sequence Diagram


1.1.4 Sequence Diagram – Register Customer


Figure Register Customer Sequence Diagram



1.2: Use Case 2 – Update Account Details
1.2.1:Use Case Model – Update Account Details

This use case is probably used whenever the customer decides to add, edit or update their personal information. After successfully registering and having an account saved in the system, the user can then change, add or modify any of the information. The user can only update it after logging in. After finishing all the changes, the user must save the changes and then the system must verify the information first and if it's valid then the system shall display the success message. If not then the user has the choice of either making other changes or just simply discarding the changes.
Use Case Name:
Update Account Details
Scenario:
Update account details online
Triggering Event:
Registered member wants to update account information
Scope:
Customer Management Module
Level:
User-goal
Brief Description:
This use case describes how a registered member can update their password or other personal information (e-mail cannot be changed). After logging in, registered members may change their password, telephone number, first or last name, and home or business address. The system validates whether the information entered by the registered member is valid, and updates the system accordingly.
Actors:
Registered member
Related Use Cases:
None
Stakeholders:
Administrators, information is being updated in the system
Special Conditions:
None
Frequency:
Frequent, customers may wish to change their information
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
Registered member must be logged in.
Post-Conditions:
Changes are made to the registered member's account information.
Flow of Events:
Actor
System

Registered requests to update information in their SportsShoes.com account
Registered member enters updated information




Repeat steps 1 and 2 until registered member is satisfied with their account information
Display update account information page


2.1 Validate whether entered information is valid
2.2 Update system information with registered member input
2.3 Display update information successful message and updated account information
Exceptional Conditions:
If input data is incorrect format, display error and go to step 1.1

Table Update Account details Use Case Description
1.2.2: Activity Diagram – Update Account Details

Figure Update Account Details Activity Diagram


1.2.3: System Sequence Diagram – Update Account Details


Figure Update Account Details System Sequence Diagram


1.2.4: Sequence Diagram – Update Account Details


Figure Update Account Details Sequence Diagram




2: Online Ordering Module
2.1: Use Case 1 – Search shoes
This use case help the customer search for the shoes they like and wish to purchase. First the customer asks to search for shoes, the system then display the search engine. The customer then enters what they are looking for, from brand to type of shoes. The system then takes the keyword and look in the system for shoes with such name or brand. If the system finds shoes that match the keyword then it displays it or else if don't found then a not found message is displayed. The customer can search for as much shoes as they wish. A business rule that is required to access this use case is the customer/user must be registered.
2.1.1: Use Case Model – Search Shoes

Use Case Name:
Search Shoes
Scenario:
Search for shoes information online
Triggering Event:
Registered member or customer wants to search for shoes
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a customer or registered member will access specific shoes information. The individual can indicate the brand of the shoe and/or the type of the shoe.
Actors:
Customer
Related Use Cases:
None
Stakeholders:
None
Special Conditions:
Registered member or customer should be on any page on SportsShoes.com website
Frequency:
Very frequent, everyone who accesses the site will search for shoes
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member or customer requests to retrieve shoes information
Registered member or customer enters shoes information
Repeat steps 1-2 to search again
Display shoe search page



2.1 Search System for shoes based on input
2.2 Display results

Exceptional Conditions:
If search returns no results, display no results returned error, go to step 1.1

Table Search Shoes Use Case Description



2.1.2: Activity Diagram – Search shoes

Figure Search Shoes Activity Diagram

2.1.3: System Sequence Diagram – Search shoes


Figure Search Shoes System Sequence Diagram


2.1.4: Sequence Diagram – Search shoes


Figure Search Shoes Sequence Diagram




2.2: Use Case 2 – Browse Shoes
In this use case the customer can access the catalogue of shoes information by requesting the system to display shoe catalogue information. The customer first request to browse, the system then displays the brand/type page, the customer then chooses the brand/type. The system must then look into the database and get the approached information for the selected brand/type. If the system finds the requested information then it must display the result, and then the user then select the shoes for more product details. If the system receives no result then it must show a no result found error. In this process the user can browse as much as wanted.
2.2.1: Use Case Model – Browse Shoes

Use Case Name:
Browse Shoes
Scenario:
Browse for shoes online
Triggering Event:
Registered member or customer wants to browse for shoes
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a customer or registered member will access the catalogue of all shoes information.
Actors:
Customer
Related Use Cases:
None
Stakeholders:
None
Special Conditions:
Registered member or customer should be on any page on SportsShoes.com website
Frequency:
Very frequent, everyone who accesses the site will browse for shoes
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member or customer requests to retrieve shoes information
Registered member or customer enters selects brand or type
Repeat steps 1-2 to search for other shoes
Display brand catalogue



2.1 Retrieve available products
2.2 Display product information
Exceptional Conditions:
2.1.1 If no products exist for the brand and/or type, display no products for this brand and/or type error page

Table Browse Shoes Use Case Description


2.2.2: Activity Diagram – Browse Shoes

Figure Browse Shoes Activity Diagram

2.2.3: System Sequence Diagram – Browse Shoes


Figure Browse Shoes System Sequence Diagram



2.2.4: Sequence Diagram – Browse Shoes


Figure Browse Shoes Sequence Diagram


2.3: Use Case 3 – Add to Cart
In this use case the customer add the desired shoe to the shopping card in order to do so, the customer doesn't have to be either registered or logged in. After adding the preferred shoes to the shopping cart, the system then display the message that shows that the items are added successfully in the shopping card, if selected shoes are out of inventory the system prompt user an error message, which says the shoes selected are out of stock.
2.3.1: Use Case Model – Add to Cart

Use Case Name:
Add to Cart
Scenario:
Add to shopping cart online
Triggering Event:
Registered member or customer wants to add shoes to shopping cart
Scope:
Online Ordering Module, Inventory Management Module
Level:
User-goal
Brief Description:
This use case describes how a registered member or customer can add shoes to a virtual shopping cart. The user does not need to be logged in for this process.
Actors:
Customer or Registered Member
Related Use Cases:
Browse shoes, search shoes
Stakeholders:
None, no information is being changed
Special Conditions:
None
Frequency:
Often, anyone can add shoes to the shopping cart
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member or customer requests to add shoes to the cart
Check inventory
Add shoes to virtual shopping cart
Display shoes added success message
Exceptional Conditions:
1.1.1 If shoes are out of inventory, display error message, end use case

Table Add to Cart Use Case Description


2.3.2: Activity Diagram – Add to Cart


Figure Add to Cart Activity Diagram


2.3.3: System Sequence Diagram – Add to Cart


Figure Add to Cart System Sequence Diagram


2.3.4: Sequence Diagram – Add to Cart


Figure Add to Cart Sequence Diagram





2.4: Use Case 4 – View Cart
This use case, is for customer to check their carts whenever they wanted, to see what they have are check their subtotal or for any reason. To view the cart, the customer must send a request to view the cart; the system will check the cart. If the cart has items it will view it, but if the cart is empty then it will just send a error message saying the cart is empty.
2.4.1: Use Case Model –View Cart

Use Case Name:
View Cart
Scenario:
View shopping cart online
Triggering Event:
Registered member or customer wants to view their virtual shopping cart
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member or customer can view their current items in the virtual shopping cart
Actors:
Customer or Registered Member
Related Use Cases:
Add to Cart, Search Shoes, Browse Shoes
Stakeholders:
None, no information is being changed
Special Conditions:
None
Frequency:
Often, anyone can view the shopping cart
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member or customer requests to view cart
Check cart
Display shopping cart

Exceptional Conditions:
1.1.1 If cart is empty, display no items in cart message, end use case

Table View Cart Use Case Description


2.4.2: Activity Diagram – View Cart


Figure View Cart Activity Diagram


2.4.3: System Sequence Diagram – View Cart


Figure View Cart System Sequence Diagram


2.4.4: Sequence Diagram – View Cart


Figure View Cart Sequence Diagram




2.5: Use Case 5 – Checkout
The customer could search, browse, add to cart and so on. But in this use case the most important concern is the checkout. Whenever the customer is satisfied with the items they added in the cart, then will hit the checkout tap. Which will view the subtotal for the items in the cart. That will take him to the page were the customer must enter their payment/ address information, and when the system verifies that all the information are right then the system process the checkout or else it asks the customers to re-enter the information.
2.5.1: Use Case Model – Checkout

Use Case Name:
Checkout
Scenario:
Checkout shoe order online
Triggering Event:
Registered member or customer wants to checkout the contents in their cart
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member or customer can checkout to place the order for their shoes in their shopping cart
Actors:
Registered Member or Customer
Related Use Cases:
View Cart, Use Points, Use Credit Card
Stakeholders:
None, no information is being changed
Special Conditions:
None
Frequency:
Very rarely, registered members do not usually cancel their orders after placing it, limiting the cancel period to within 5 days significantly lowers the frequency of this use case.
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
There is at least one item in the shopping cart, the checkout option is not enabled unless there is at least one item in the cart
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member or customer wants to checkout
Enter shipping details

Confirm checkout order
Display order subtotal and shipping screen

2.1 Display total and confirmation screen
3.1 Invoke Use Points use case
Alternate Flows:
3.1 If customer is the actor, invoke Use Credit Card
Exceptional Conditions:
2.2.1 If user rejects shipping details, go to step 2

Table Checkout Use Case Description


2.5.2: Activity Diagram – Checkout



Figure Checkout Activity Diagram


2.5.3: System Sequence Diagram – Checkout



Figure Checkout System Sequence Diagram


2.5.4: Sequence Diagram – Checkout



Figure Checkout Sequence Diagram



2.6: Use Case 6 – Use Points
In the process of the checkout, the system will ask the user if it wants to pay using credit card or point. If the user chooses points then the system's job is to figure out if the points available in the account are enough to pay for the whole order. The user also has the option to pay fully using point or it can be split between point and credit card. So the system must check if the points are sufficient, if so then the customer can pay either by all the point or as said earlier partly by point and party by credit card. But if not then the system goes back to the customer with the insufficient message.
2.6.1: Use Case Model – Use Points
Use Case Name:
Use Points
Scenario:
Use points for a shoe purchase
Triggering Event:
Registered member wants to use points as part or all of their purchase
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member may use points as part or all of their shoe purchase, or not spend any points at all
Actors:
Registered Member
Related Use Cases:
Checkout, Use Credit Card, Create Order
Stakeholders:
Administrator, a type of currency (points) is being changed
Special Conditions:
Registered member should have invoked Checkout use case.
Frequency:
Often, registered members can use as much or as little points as they like towards a purchase
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
Registered member has points in their account
Post-Conditions:
Point total updated, total remaining on purchase updated
Flow of Events:
Actor
System

None
Enter amount of points to use towards purchase
Display use points window
2.1 Check point balance
2.2 Update points and total
2.3 Invoke Use Credit Card use case
Alternate Flow:
2.2.1 If the amount of points used equals the total order, invoke Create Order use case
Exceptional Conditions:
2.1 Registered member rejects to use points, invoke Use Credit Card use case
2.1.1 Registered member does not have sufficient points, display error message, go to step 2

Table Use Points Use Case Description


2.6.2: Activity Diagram – Use Points


Figure Use Points Activity Diagram


2.6.3: System Sequence Diagram – Use Points


Figure Use Points System Sequence Diagram


2.6.4: Sequence Diagram – Use Points


Figure Use Points Sequence Diagram



2.7: Use Case 7 – Use Credit Card
This use case is about the credit card payment, which is involved in also mentioned in the process of checkout. When the user checkouts then they need to either pay by points or credit card. In this case we assume the customer is going to use their credit card. Therefore the user will enter their credit card information, the system then needs to verify the information to make sure that the credit card is valid and if it is then it continue with the process, update the total and create the order. But if the credit card information is invalid then the system asks the user to enter their credit card information again.
2.7.1: Use Case Model – Use Credit Card

Use Case Name:
Use Credit Card
Scenario:
Use credit card for a shoe purchase
Triggering Event:
Registered member wants to use their credit card for the remainder (or all) of their purchase
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member may use their credit as part or all of their shoe purchase
Actors:
Registered Member
Related Use Cases:
Checkout, Use Points, Create Order
Stakeholders:
Administrator, credit card information is entered
Special Conditions:
Registered member should have invoked Checkout or Use Points use case.
Frequency:
Often, registered members usually use a credit card towards their purchase
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
Total remaining on purchase updated
Flow of Events:
Actor
System

None
Enter credit card information
Display credit card window
2.1 Check credit card information
2.2 Update total
2.3 Invoke Create Order use case
Exceptional Conditions:
2.1.1 Registered member enters invalid credit card information, display error message, go to step 2

Table Use Credit Card Use Case Description


2.7.2: Activity Diagram – Use Credit Card


Figure Use Credit Card Activity Diagram


2.7.3: System Sequence Diagram – Use Credit Card


Figure Use Credit Card System Sequence Diagram


2.7.4: Sequence Diagram – Use Credit Card


Figure Use Credit Card Sequence Diagram




2.8: Use Case 8 – View Order History
In this use case the user can refer back to past orders, for details, for documentation or what ever reason. All they have to do, is ask to view the order history, then the system search past order, if found then the system shows history and if not then the system just displays a no order history message.
2.8.1: Use Case Model – View Order History

Use Case Name:
View Order History
Scenario:
View order history online
Triggering Event:
Registered member wants to see their order history
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member can view their past order history. The registered member is directed to a page that displays all their past orders.
Actors:
Registered Member
Related Use Cases:
None
Stakeholders:
None
Special Conditions:
None
Frequency:
Rarely, registered members would not check what they have ordered in the past often
Technology and Data Variation List:
None
Miscellaneous:
Returned result should be in chronological order – showing most recent purchases first
Pre-Conditions:
Customer has a SportsShoes.com account
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member requests to view order history
Retrieve order history
Display order history

Exceptional Conditions:
1.1 If registered member has never ordered an item, display error message

Table View Order History Use Case Description


2.8.2: Activity Diagram – View Order History

Figure View Order History Activity Diagram


2.8.3: System Sequence Diagram – View Order History


Figure View Order History System Sequence Diagram


2.8.4: Sequence Diagram – View Order History

Figure View Order History Sequence Diagram




2.9: Use Case 9 – Print Order History
As I mention in the last use case the user can view order history, in this use case the user can also print any of the order history he/her wishes to print. It's basically the same steps required as order history. The user asks the system to print the selected history and then the system provides a printer friendly copy for printing.
2.9.1: Use Case Model – Print Order History

Use Case Name:
Print Order History
Scenario:
Print order history online
Triggering Event:
Registered member wants to print their order history
Scope:
Online Ordering Module
Level:
User-goal
Brief Description:
This use case describes how a registered member may access a printer friendly version of their order history.
Actors:
Registered Member
Related Use Cases:
View Order History
Stakeholders:
None
Special Conditions:
Registered member should have invoked View Order History use case.
Frequency:
Very rarely, registered members do not usually need a print out of their order history. View order history is invoked much more often.
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
Registered member has placed an order with SportsShoes.com.
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member requests to print order history
Retrieve order history
Display printer friendly version of order history
Exceptional Conditions:
None

Table View Order History Use Case Description


2.9.2: Activity Diagram – Print Order History


Figure Print Order History Activity Diagram


2.9.3: System Sequence Diagram – Print Order History


Figure Print Order History System Sequence Diagram


2.9.4: Sequence Diagram – Print Order History


Figure Print Order History Sequence Diagram





2.10: Use Case 10 – Create Order
In create order use case; it's all about the system. The system needs to create in the order behind the scenes, in order to have the system up to date and always running. After the second process in checkout which is payment by credit card or point is verified, then system afterwards need to create order information about the purchase and make it available, then the system must email the order information to the customer. The system must update the inventory as well, but that will be covered in a different use case.
2.10.1: Use Case Model – Create Order

Use Case Name:
Create Order
Scenario:
Create order online
Triggering Event:
The shoes in the shopping cart have been paid for
Scope:
Online Ordering Module, Inventory Management Module
Level:
Sub-functional
Brief Description:
This use case describes how an order is created after it has been paid for.
Actors:
System
Related Use Cases:
Use Points, Use Credit Card, Adjust Inventory
Stakeholders:
Registered member or customer, shipping, inventory
Special Conditions:
Registered member or customer should have invoked Use Points or Use Credit Card use case
Frequency:
Very often, this use case is invoked after every successful payment
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
A copy of the order is created in the system, this copy is also emailed to the Registered Member or Customer
Flow of Events:
Actor
System

None
Create order information
Email order information
Invoke Adjust Inventory use case
Exceptional Conditions:
None

Table Create Order Use Case Description


2.10.2: Activity Diagram – Create Order


Figure Create Order Activity Diagram



2.10.3: System Sequence Diagram – Create Order


Figure Create Order System Sequence Diagram


2.10.4: Sequence Diagram – Create Order


Figure Create Order Sequence Diagram




2.11: Use Case 11 – Cancel Order
If a customer made purchase, which he/she isn't satisfied with they can request to cancel the order. The system have to check if the cancelation is within the time period of 5 days, and then display item information and cancelation page. The customer then fills and confirm cancelation on the displayed page, the system then sends a shipping return request and email the receipt of cancellation information to customer and invoke add point use case to update customer point balance.
2.11.1: Use Case Model – Cancel Order

Use Case Name:
Cancel Order
Scenario:
Cancel order online
Triggering Event:
Registered member wants to cancel an order
Scope:
Online Ordering Module, Points Module
Level:
User-goal
Brief Description:
This use case describes how a registered member can cancel an order within 5 days after placing an order.
Actors:
Registered Member
Related Use Cases:
View Order History, Refund Points
Stakeholders:
Administrators, shipping, inventory
Special Conditions:
Registered member should have invoked View Order History use case. This use case may only be invoked if the current time is less than order time plus 5 days.
Frequency:
Very rarely, registered members do not usually cancel their orders after placing it, limiting the cancel period to within 5 days significantly lowers the frequency of this use case.
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
Registered member has placed an order with SportsShoes.com within 5 days.
Post-Conditions:
E-mail cancel notification, log return in system, adjust inventory levels, and send information to stop/return shipping.
Flow of Events:
Actor
System

Registered member requests to cancel the specified order
Registered member confirms cancellation

Display order information and cancellation page

2.1 Update order information
2.2 Send shipping return request
2.3 Email registered customer a receipt for cancellation confirmation
3.4 Invoke Add Points use case
Alternate Flows:
3.4 If purchase was made without points, invoke Refund Credit Card use case
Exceptional Conditions:
2.1 If user rejects cancellation, end use case

Table Cancel Order Use Case Description


2.11.2: Activity Diagram – Cancel Order


Figure Cancel Order Activity Diagram


2.11.3: System Sequence Diagram – Cancel Order


Figure Cancel Order System Sequence Diagram


2.11.4: Sequence Diagram – Cancel Order
c

Figure Cancel Order Sequence Diagram




3: Points Module
3.1:Use Case 1 – Add points
Add point is a process fully done by the system. The system request to add point, then it updates the points and therefore updates the order. For this case a business rule system request to add 5 points per dollar to registered member point balance and update point balance and order.
3.1.1:Use Case Model – Add Points

Use Case Name:
Add Points
Scenario:
Add points to account online
Triggering Event:
After an order has been created
Scope:
Points Module, Online Ordering Module
Level:
Sub-functional
Brief Description:
This use case describes how points are added to a registered member's point balance. This use case can be trigged by either an order is successfully placed, or any order refunded that has used points in its purchase.
Actors:
System
Related Use Cases:
Create Order, Adjust Inventory
Stakeholders:
Administrators, points are updated in the system
Special Conditions:
None
Frequency:
Very often, this use case is triggered for every order successfully created or any order refunded that has used points in its purchase
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
Point totals of Registered Members will be updated.
Flow of Events:
System

Request add points
Update points for Registered Member
Update orders (points have been added)
Exceptional Conditions:
None

Table Add Points Use Case Description



3.1.2: Activity Diagram – Add Points


Figure Add Points Activity Diagram


3.1.3: System Sequence Diagram – Add Points


Figure Add Points System Sequence Diagram


3.1.4: Sequence Diagram – Add Points


Figure Add Points Sequence Diagram




3.2: Use Case 2 – Refund Credit Card
In this case, a customer purchases items and he/she asked to be refunded to the credit card. There they refund the order and the system needs to do the process of returning the money back to the credit card. The system must update fund then update order information and call adjust inventory use case in order to update inventory as well.
3.2.1: Use Case Model – Refund Credit Card

Use Case Name:
Refund Credit Card
Scenario:
Refund to credit card
Triggering Event:
Cancel order, Refund Points
Scope:
Points Module, Online Ordering Module
Level:
Sub-functional
Brief Description:
This use case describes how funds are can be refunded to a registered member's credit card.
Actors:
System
Related Use Cases:
Cancel Order, Refund Points, Adjust Inventory
Stakeholders:
Administrators, funds are being updated
Special Conditions:
Cancel order or Refund Points is case is invoked, the payment type has credit card
Frequency:
Very rarely. This use case is only invoked during a cancel order and when the purchase was made partly or all with credit card
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
Funds will be updated, order information will be updated
Flow of Events:
System

Request to refund credit card
Update funds
Update order information
Invoke Adjust Inventory Use Case
Exceptional Conditions:
None

Figure Refund Credit Card Use Case Description


3.2.2: Activity Diagram – Refund Credit Card


Figure Refund Credit Card Activity Diagram


3.2.3: System Sequence Diagram – Refund Credit Card


Figure Refund Credit Card System Sequence Diagram


3.2.4: Sequence Diagram – Refund Credit Card


Figure Refund Credit Card Sequence Diagram














3.3: Use Case 3 – View Point Balance
This use case is a basic process, were the customer request to see their point balance. In order to do that the customer request to view the points, the system retrieve the points and display the page.
3.3.1: Use Case Model –View Point Balance

Use Case Name:
View Point Balance
Scenario:
View point balance online
Triggering Event:
Registered member wants to see their point balance
Scope:
Point Module
Level:
User-goal
Brief Description:
This use case describes how a registered member can view their point balance. The registered member is directed to a page that displays their point balance.
Actors:
Registered Member
Related Use Cases:
None
Stakeholders:
None
Special Conditions:
None
Frequency:
Sometimes
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
None
Flow of Events:
Actor
System

Registered member requests to view point balance
Retrieve point balance
Display point balance

Exceptional Conditions:
None

Figure View Point Balance Use Case Description



3.3.2: Activity Diagram – View Point Balance



Figure View Point Balance Activity Diagram



3.3.3: System Sequence Diagram – View Point Balance



Figure View Point Balance System Sequence Diagram


3.3.4: Sequence Diagram – View Point Balance


Figure View Point Balance Sequence Diagram







4: Inventory Management Module
4.1: Use Case 1 – Adjust Inventory (sub functional)
This use case is mainly for change in inventory, it can be invoked from add point, refund points or refund credit card use cases. If a customer decides to return an order or purchase items, the system's job is to update inventory. The system starts by requesting to adjust inventory, and then it must choose between the types of transaction, is it for sale or return, and according to the answer the system will either increase or decrease inventory.
4.1.1: Use Case Model – Adjust Inventory (sub functional)

Use Case Name:
Adjust Inventory
Scenario:
Adjust Inventory levels
Triggering Event:
Points have been added or points/credit card has been refunded
Scope:
Inventory Management Module
Level:
Sub-functional, user-goal
Brief Description:
This use case describes how the inventory will be updated after a sale, return or buying inventory. This occurs after the last step in the sale or return process, where points are added for a purchase or points/credit card funds have been refunded in the event of a return.
Actors:
Online Ordering Module
Related Use Cases:
Add Points, Refund Points, Refund Credit Card
Stakeholders:
Administrators, inventory
Special Conditions:
Either Add Points, or Refund Points/Refund Credit Card use case is invoked.
Frequency:
Very often, this use case is invoked every time a sale or return.
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
A shoe order or cancel order is placed.
Post-Conditions:
Inventory will be adjusted.
Flow of Events:
System

Online Ordering Module requests to adjust inventory
If it is a return, increase inventory
Alternative Flows:
If it is a sale, decrease inventory
Exceptional Conditions:
None

Figure Adjust Inventory (sub functional) Use Case Description



4.1.2: Activity Diagram – Adjust Inventory (sub functional)


Figure Adjust Inventory (sub functional) Activity Diagram


4.1.3: System Sequence Diagram – Adjust Inventory (sub functional)


Figure Adjust Inventory (sub functional) System Sequence Diagram


4.1.4: Sequence Diagram – Adjust Inventory (sub functional)


Figure Adjust Inventory (sub functional) Sequence Diagram




4.2: Use Case 2 – Adjust Inventory (user goal)
In the use case the users are the SportsShoe.com agent. SportsShoe.com agent request the system to adjust inventory, the system then display the inventory page. The agent then need to fill up the method, by filling up the amount and the item. The system then need to check the method, figure out if its subtracting or adding and according to the result the system must increase or decrease the inventory, were the system updates inventory and calculate the new inventory level.
4.2.1: Use Case Model – Adjust Inventory (user goal)

Use Case Name:
Adjust Inventory
Scenario:
Adjust Inventory levels
Triggering Event:
New shoes arrived from vendors
Scope:
Inventory Management Module
Level:
User-goal
Brief Description:
SportsShoe.com agent adjusting the inventory for buying new shoes from vendors.
Actors:
SportsShoe.com agent
Related Use Cases:
None
Stakeholders:
Administrators, inventory
Special Conditions:
None
Frequency:
Rare, this use case is only invoked when new products in bought from other vendors
Technology and Data Variation List:
None
Miscellaneous:
None
Pre-Conditions:
None
Post-Conditions:
Inventory will be adjusted.
Flow of Events:
Actor
System

Request to adjust inventory

Select method (add or subtract), and enter amount
1.1 Display inventory adjustment page
Increase inventory (if add)
Alternate Flow:
2.1 Decrease inventory (if subtract)
Exceptional Conditions:
None

Figure Adjust Inventory (user goal) Use Case Description



4.2.2: Activity Diagram – Adjust Inventory (user goal)


Figure Adjust Inventory (user goal) Activity Diagram


4.2.3: System Sequence Diagram – Adjust Inventory (user goal)


Figure Adjust Inventory (sub functional) System Sequence Diagram


4.2.4: Sequence Diagram – Adjust Inventory (user goal)


Figure Adjust Inventory (user goal) Sequence Diagram




Domain Model


Figure Domain Model


Design Class Diagram


Figure Design Class Diagram


Workload Assignment

Sunny – Programming, Use Case Diagram, Activity Diagram (1-2), Domain Model, Domain Class Diagram
Mariam – Activity Diagram (3-4), All Extra text, System Sequence Diagram (All)
Kiana – Use Case Descriptions (1-4), Sequence Diagram (All), Context Diagram