Usecase Diagram.
0
Usecase Diagram:
Use case diagram is created to visualize the interaction of our system with the outside world.
Use case diagram is created to visualize the interaction of our system with the outside world.
The components of use case diagram are:
Use Case: Scenarios of the system.
Actor: Someone or something who is interacting with the system.
Relationship: Semantic link between use case and actor. The forms of relationship are:
a. Association.
b. Dependency.
c. Generalization.
1) Registration:-
Use Case: Scenarios of the system.
Actor: Someone or something who is interacting with the system.
Relationship: Semantic link between use case and actor. The forms of relationship are:
a. Association.
b. Dependency.
c. Generalization.
1) Registration:-
- A user who is not registered will need to enter their details and get an account with the item shop.
Primary Actor: Customer.
Secondary Actor: Manager.
Flow of Events:
Basic Flow
Post condition: User registered successfuly
2) Login:
The online shopping customers need to be able to log on to the system
Flow of Events:
Basic Flow
Invalid Name / Password.
Secondary Actor: Manager.
Flow of Events:
Basic Flow
- User enters preferred user login name, personal details and password.
- System validates name not in use.
- On success user is registered with item.
- On failure user is prompted to try another name.
Post condition: User registered successfuly
2) Login:
The online shopping customers need to be able to log on to the system
Flow of Events:
Basic Flow
- User accesses the login page
- User enters login name and password
- System validates entered data
- On success user is taken to item store
- On fail user may try again or go to register page
Invalid Name / Password.
- If in the basic flow, the customer enters an invalid name and or password, the system displays an error message.
- The customer can choose to either return to the beginning of the basic flow or cancel the login, at which the use case ends.
Pre-Conditions
The customer logs on to the system. Now he can browse the system.
3)Create Order
The customer logs on to the system. Now he can browse the system.
3)Create Order
- The use case support searching for an item and browsing the resultant record set.
- The customer can enter browse criteria and scroll through the results.
- If they so wish, the user may select an item for addition to their current shopping cart.
Flow of Events
Basic Flow
Basic Flow
- The customer can browse the current item catalogue on-line.
- This should detail both the item details and he stocks details for items.
- The user should be able to filter the item title, author, and item category.
Select an item
a) The user enters some filter criteria such as item title or author. This limits the returned set of books to those that match the supplied filter. Wild cards such as ‘*’ and ‘?’ should be supported.
b) The customer can select items by searching
c) The system requests the customer to enter the search details. This includes
- Name of author
- Title of item
- Item category
And any other related information
d) The system finds the item or the customer based on his request. On selection the system provides a cart to drop items in.
e) The system will return both catalogue and inventory details for the items selected.
Search Unlisted Item.
If the user cannot find an item in the current category, they should be able to place a special request. This should include details such as Author, Publisher, Title, ISBN and other helpful information.
-The customer enters a request for an item not in the catalogue.
-The system finds for this special order places by customer.
Alternate Flow
If the search for unlisted item is not successful because of some wrong information regarding the search is provided, the system displays an error message. The customer can re enter the search details or can cancel the search, at which the use case ends.
If the customer selects an item which is already selected by another customer, the system displays an error message. The customer can list that selection from the inventory and proceed further or can cancel the operation at which the use case ends.
Pre-conditions:
The customer must be logged on to the system before this use case begins.
Post-conditions:
If the use case was successful, the customer has a list of his selections. Otherwise, the system state is unchanged.
4) Catalogue
A customer will use the catalogue use case to browse the items on sale and make selections.
The customer can browse the current item catalogue on-line. This should detail both item details and the stock details for items. The user should be able to filter by item title, item category.
Flow of Events:-
Basic Flow
. Display a filtered set of items
. Scroll through list
. Page to next set of results
. Add item to cart
. Get more information on an item
Alternate flow:
None
Pre-conditions:
The customer has to be logged on to the system before he makes selections by browsing the catalog
Post-conditions:
If the use case was successful, the user makes selection from the listings in the catalog and adds them to cart. Otherwise, the system state is unchanged.
5. Manage Cart & Payments:-
This use case allows a user to add an item's title to their on-line shopping cart.
A user first uses the select item use case to find the required item-then this use case to temporarily store the title for later purchase.
Flow of events:
A customer may add a selected title to their shopping cart
Add title to cart:
1) User has searched for and selected a title
2) User highlights the required item in the selection list
3) User presses an 'Add to Cart' button to add the item to their shopping cart
4) The selected title is added to the cart
Pay for order:
Once a user has created their shopping cart and made their final selection, they may pay for their order and enter shipment details.
1) User selects the 'Pay for Order' menu option.
2) A secure web page allowing the user to enter card details, shipping details and associated information displayed.
3) If the card details are confirmed, the order is completed - an order number and receipt details are displayed to the user.
4) An email confirming their payment details is sent to the user.
5) The payment process is complete.
Remove Item from cart:
Proposed Pre-condition: Cart must have existing items.
. A customer uses this condition to remove a previously added item from his from his shopping cart
. A user removes an item from their shopping cart
. The system asks for confirmation of removal, as once removed an item cannot be retrieved
. The shopping cart will keep track of the current running total and update cart details when an item is removed
5) View cart:
A customer views the contents of their cart.
The customer confirms the items in the cart and heads for payment.
Pre-condition;-
The user has created their shopping cart
Post-condition
If the use case was successful, the system accepts the items placed in the cart and creates an order for purchase.
The customer pays for the order in the cart, this is done in highly secure environment. Otherwise, the system state is unchanged.
6) Order Status:
Brief Description:
The customer is able to view the states of their order on-line. They enter their order id and retrieve an updated report on status.
Flow of Events:
Basic Flow:
The customer logs on to the system and verifies his order. If his order hasn't been shipped yet, he can cancel the order, under some circumstances.
7) Enquire on Order status
The customer logs on to the system, and then goes to the order status screen. From there have a list of their current orders and
the details of each order, including shipping status and back order status.
. A customer enquires on his order status by a posting a query.
. The system gives response regarding the query posted by customer. This includes the shipping details of his order.
8) Cancel Order
The user logs onto the system and locates their orders. An order that has not been shipped and is not yet filled (that is, is on back order) may be cancelled by the user.
. The customer enquires the order status. If the order has not been shipped yet, he cancels his order.
. A system accepts the user request and cancels the order.
Alternate flow: None
Pre-conditions: Order must be shipped
Post-conditions:
If the use case was successful, the customer is able to view his order status and even cancels the order under some circumstances, if not shipped yet. Otherwise, the system state is unchanged.
9) Inventory
Brief description
This use case explains that, online shop staff will be continuously updating the db.
Flow of Events
Basic Flow:
The online shopping staff logs onto the system and updates the db. These include inventory, stock, shipment details.
Alternate Flow: None
Pre-conditions: The bookshop staff must logon to the system
Post-condition: The inventory is updated with the latest details of stock.
a) The user enters some filter criteria such as item title or author. This limits the returned set of books to those that match the supplied filter. Wild cards such as ‘*’ and ‘?’ should be supported.
b) The customer can select items by searching
c) The system requests the customer to enter the search details. This includes
- Name of author
- Title of item
- Item category
And any other related information
d) The system finds the item or the customer based on his request. On selection the system provides a cart to drop items in.
e) The system will return both catalogue and inventory details for the items selected.
Search Unlisted Item.
If the user cannot find an item in the current category, they should be able to place a special request. This should include details such as Author, Publisher, Title, ISBN and other helpful information.
-The customer enters a request for an item not in the catalogue.
-The system finds for this special order places by customer.
Alternate Flow
If the search for unlisted item is not successful because of some wrong information regarding the search is provided, the system displays an error message. The customer can re enter the search details or can cancel the search, at which the use case ends.
If the customer selects an item which is already selected by another customer, the system displays an error message. The customer can list that selection from the inventory and proceed further or can cancel the operation at which the use case ends.
Pre-conditions:
The customer must be logged on to the system before this use case begins.
Post-conditions:
If the use case was successful, the customer has a list of his selections. Otherwise, the system state is unchanged.
4) Catalogue
A customer will use the catalogue use case to browse the items on sale and make selections.
The customer can browse the current item catalogue on-line. This should detail both item details and the stock details for items. The user should be able to filter by item title, item category.
Flow of Events:-
Basic Flow
. Display a filtered set of items
. Scroll through list
. Page to next set of results
. Add item to cart
. Get more information on an item
Alternate flow:
None
Pre-conditions:
The customer has to be logged on to the system before he makes selections by browsing the catalog
Post-conditions:
If the use case was successful, the user makes selection from the listings in the catalog and adds them to cart. Otherwise, the system state is unchanged.
5. Manage Cart & Payments:-
This use case allows a user to add an item's title to their on-line shopping cart.
A user first uses the select item use case to find the required item-then this use case to temporarily store the title for later purchase.
Flow of events:
A customer may add a selected title to their shopping cart
Add title to cart:
1) User has searched for and selected a title
2) User highlights the required item in the selection list
3) User presses an 'Add to Cart' button to add the item to their shopping cart
4) The selected title is added to the cart
Pay for order:
Once a user has created their shopping cart and made their final selection, they may pay for their order and enter shipment details.
1) User selects the 'Pay for Order' menu option.
2) A secure web page allowing the user to enter card details, shipping details and associated information displayed.
3) If the card details are confirmed, the order is completed - an order number and receipt details are displayed to the user.
4) An email confirming their payment details is sent to the user.
5) The payment process is complete.
Remove Item from cart:
Proposed Pre-condition: Cart must have existing items.
. A customer uses this condition to remove a previously added item from his from his shopping cart
. A user removes an item from their shopping cart
. The system asks for confirmation of removal, as once removed an item cannot be retrieved
. The shopping cart will keep track of the current running total and update cart details when an item is removed
5) View cart:
A customer views the contents of their cart.
The customer confirms the items in the cart and heads for payment.
Pre-condition;-
The user has created their shopping cart
Post-condition
If the use case was successful, the system accepts the items placed in the cart and creates an order for purchase.
The customer pays for the order in the cart, this is done in highly secure environment. Otherwise, the system state is unchanged.
6) Order Status:
Brief Description:
The customer is able to view the states of their order on-line. They enter their order id and retrieve an updated report on status.
Flow of Events:
Basic Flow:
The customer logs on to the system and verifies his order. If his order hasn't been shipped yet, he can cancel the order, under some circumstances.
7) Enquire on Order status
The customer logs on to the system, and then goes to the order status screen. From there have a list of their current orders and
the details of each order, including shipping status and back order status.
. A customer enquires on his order status by a posting a query.
. The system gives response regarding the query posted by customer. This includes the shipping details of his order.
8) Cancel Order
The user logs onto the system and locates their orders. An order that has not been shipped and is not yet filled (that is, is on back order) may be cancelled by the user.
. The customer enquires the order status. If the order has not been shipped yet, he cancels his order.
. A system accepts the user request and cancels the order.
Alternate flow: None
Pre-conditions: Order must be shipped
Post-conditions:
If the use case was successful, the customer is able to view his order status and even cancels the order under some circumstances, if not shipped yet. Otherwise, the system state is unchanged.
9) Inventory
Brief description
This use case explains that, online shop staff will be continuously updating the db.
Flow of Events
Basic Flow:
The online shopping staff logs onto the system and updates the db. These include inventory, stock, shipment details.
Alternate Flow: None
Pre-conditions: The bookshop staff must logon to the system
Post-condition: The inventory is updated with the latest details of stock.
0 comments: