Scribd
Upload
26 views3 pages

Moses 254

Uploaded by

nyamgeromoses
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
26 views3 pages

Moses 254

Uploaded by

nyamgeromoses
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

This is a sample website used by the online shoppers:

Case diagram mostly used are:


View Items use case is mostly extended by several optional use cases - customer
may search for items, browse catalog, view items recommended for him/her, add
items to shopping cart or wish list. All these use cases are extending use cases
because they provide some optional functions allowing customer to find item.
Customer Authentication use case is mostly included in View Recommended
Items and Add to Wish List because both require the customer to be
authenticated. At the same time, item could be added to the shopping cart without
user authentication.

Checkout use case includes several required uses cases. Web customer should be
authenticated. It could be done through user login page, user authentication
cookie ("Remember me") or Single Sign-On (SSO). Web site authentication service
is used in all these use cases, while SSO also requires participation of external
identity provider.
Checkout use case also includes Payment use case which could be done either by
using credit card and external credit payment service or with PayPal.

Use case diagram UML


This UML use case diagram example shows some use cases for a system which
processes credit cards.
Credit Card Processing System (aka Credit Card Payment Gateway) isa subject,
i.e. system under design or consideration. Primary Actor for the system is
a Merchant’s Credit Card Processing System. The merchant submits some
credit card transaction request to the credit card payment gateway on behalf of a
customer. Bank which issued customer's credit card is actor which could approve
or reject the transaction. If transaction is approved, funds will be transferred to
merchant's bank account.
Authorize and Capture use case is the most common type of credit card
transaction. The requested amount of money should be first authorized
by Customer's Credit Card Bank, and if approved, is further submitted for
settlement. During the settlement funds approved for the credit card transaction
are deposited into the Merchant's Bank account.
In some cases, only authorization is requested and the transaction will not be
sent for settlement. In this case, usually if no further action is taken within some
number of days, the authorization expires. Merchants can submit this request if
they want to verify the availability of funds on the customer’s credit card, if item is
not currently in stock, or if merchant wants to review orders before shipping.
Capture use case describes several scenarios when merchant needs to complete
some previously authorized transaction - either submitted through the payment
gateway or requested without using the system, e.g. using voice authorization.

UML use case diagram example for a credit cards processing system.
Credit use case describes situations when customer should receive a refund for a
transaction that was either successfully processed and settled through the system
or for some transaction that was not originally submitted through the payment
gateway.
Void use case describes cases when it is needed to cancel one or several related
transactions that were not yet settled. If possible, the transactions will not be sent
for settlement. If the Void transaction fails, the original transaction is likely already
settled.
Verify use case describes zero or small amount verification transactions which
could also include verification of some client's data such as address.
You can find excellent resources, documentation, white papers, guides, etc. related
to the credit card processing at Authorize.Net - Payment Gateway to Accept
Online Payments.

Website administration
Purpose: Website management or administration UML use case diagrams
example.
Summary: Website Administrator actor could manage user groups, users, user
sessions, and logs. Help Desk staff uses a subset of functions available to the
Website Administrator.

Uml diagram
Here we provide an example of UML class diagram which shows a domain model
for online shopping. The purpose of the diagram is to introduce some common
terms, "dictionary" for online shopping - Customer, Web User, Account, Shopping
Cart, Product, Order, Payment, etc. and relationships between. It could be used as
a common ground between business analysts and software developers.
Each customer has unique id and is linked to exactly one account. Account owns
shopping cart and orders. Customer could register as a web user to be able to buy
items online. Customer is not required to be a web user because purchases could
also be made by phone or by ordering from catalogues. Web user has login name
which also serves as unique id. Web user could be in several states - new, active,
temporary blocked, or banned, and be linked to a shopping cart. Shopping cart
belongs to account.

State uml diagram


Every company having customers maintains customer accounts and supports a
complete life cycle of the account from its creation until it is closed. There are
differences in what are the stages (states) in the account's life cycle, and what are
conditions or events causing account to change its state.
Here we provide an example of user account life cycle in the context of online
shopping, shown as UML protocol state machine diagram.
For the user account to be created, it has to meet some initial requirements. For
example, user id (used as a login name) must be unique, at least for the existing
accounts. After account was created, it might need to be verified. Verification
depends on the company and could include e-mail, phone, and/or address
verification. If account was not verified during some predefined period of time, that
account could be moved to the suspended accounts.

You might also like