Case Study

e-Commerce System Design

 OO Software Engineering
Process

OO Analysis
- Requirement Analysis
OO Design
- Architectural Design
- Class/Algorithm Design
OO Programming
Testing and maintainance
 Case Study Example - OPS
OPS Order Processing System for online store

Part of an online store

- - Online catalog of products for user browsing

- - Order processing system(processes order)

- - Financial department (handle credit card payments)

- - Shipping department (handle packaging and

shipping).
 Requirements (1)
(R1) Customer has an online shopping cart,
which allows addition and removal of items.

(R2) Customer is able to check out the shopping

cart using credit card, when approved by financial
department.

(R3) Before the transaction is completed, a

customer should be able to learn about the
estimated arrival date, determined by the order
processing time of the shipping department.
 Requirements(2)
(R4) A customer can choose to cancel the
transaction by clearing all items of the cart.

(R5) Customers can use popular Internet

browsers to interact with OPS.
 Stage 1: OO Analysis (1)
Purpose: Understand the domain,
functional and non functional requirements.

Output: Requirement specification and an

initial analysis of the logical structure.
 Stage 1: OO Analysis (2)
OO analysis relies two UML tools available
- Use case diagram
- Analysis class diagram

Use case diagram: Captures user requirements

Analysis class diagram: Describe the conceptual
design of the system and roughly break down the
system into components so that the complex
design task can be divided and overcome.
 Step 1: Design of Use Case
Diagram
Use Case:
Case a way that a user accesses the
system (function)
User
- can be either real human user, or machine,
software agent
Use Case Diagram
- A use case may composed of other use
cases (include).
- A use case may be used by other use case
(extend).
OPS Use Case Diagram

<<include <<extend
>> >>
<<include <<include
>> >>
<<include
<<include >>
<<include
>>
>>
 Scenarios

Use Case Diagram must be accompanied

by the description of flow of events
(scenarios), that actor has to go through
to get the goal accomplished.
Flow of Events (Scenarios): a sequence
of operations for a use case
Using the list of events a sequence
diagram can be constructed.
 Example 1: Register (Event
List)

(1) user visits registration page

(2) user supplies desired user name and password and

submit

(3) system checks if the user name is available

(4) if user name not exists, insert the user, and display
registration success page; otherwise display failure
page.
 Session use case
1. Customer log in using correct user
name and password, the customer starts a
session.

2. During a session, the system maintains a

shopping cart, which records (maintain)
the list of desired items that the customer
wants to purchase later.

3. The session is terminated either because

the user checks out, logs out.
 Example 3: Operation
Operation use case is an abstract use
case.

It include login, logout, add item,

remove item, clear cart, and check out.
 Example 4: Login
First operation of any session.
1.A login page is provided to enter user name and
password and the customer click the login button .
2.If the user name and password stored in customer
database are correct, the session starts.

3.A maximum number of 3 trials are allowed for each

user. Login failure can happen, here failure page is
displayed.
4. When a user fails more than 3 times, the account is
locked.
 Example 4: Add item
1.A customer search a product using a Browse page.
2.Add the item into the shopping cart.
3. Before the item is added, Product information
database should be checked to see the details of
the item.
4. Also, inventory database should be updated after
adding.
 CRC for CustomerInfoDB
CustomerInfoDB
Responsibility Collaborators
Knows SessionController,
RegistrationController
Create user account (user name, RegistrationController
password)
Check valid user(user name, RegistrationController
password)
Save shopping cart Shoppingcart
Load shopping cart Shoppingcart
 Example 5: Remove item
1. Remove the item from the shopping cart,
given that the item is already in it.

2. The item is put back into the inventory

database.
Example 6: Clear item
1. Remove all items from shopping chart.
2. Update inventory
 Example 7: Log out
1. If the user not checked out all the items in the shopping
cart then shopping cart is saved in customer database

2. User can logout by clicking logout.

3. At the beginning of the next log in, the shopping cart is

loaded with the items of the last session.
 Example 8: Check Out
1. User supplies credit card information and click
check out.

2. System contacts financial department for

charging the card.

3. If financial department approves the

transaction, redirects to success page, at the
same time, send the order to shipping dept;
otherwise, redirects to failure page.
 Step 2: Analysis Class
Diagram (Conceptual Class
Diagram) (1)
Describes systems main functionality
using classes and relations, without
going to details

Abstraction of the system

- Not every class in analysis class
diagram is implemented
- The diagram does not include all
classes in the real implementation
 Step 2: Analysis Class
Diagram(2)
Boundary classes: serve as the interface
between the internal of the system and the
outside world.

Boundary classes are usually in the form of

graphic user interface classes (e.g., Web
forms, windows dialogs, etc.)
 Step 2: Analysis Class
Diagram(3)
Entity classes: Used to represent the
information stored and exchanged among
components of the system.

For example, the product information

exchanged among components of the order
processing system should be modeled as
an entity class.
 Step 2: Analysis Class
Diagram(4)
Controller classes: Classes which control
and coordinate the activities of other
classes.

Usually, a controller class is associated

with one specific use case or a set of
closely related use cases.

A controller class coordinates the

interactions that are required to
accomplish the use case.
 Notations
Three Diagrams
 Noun Extraction
Extracts all nouns in the flow of events
description

Example:

Register: A customer visits the registration page,

and specifies the desired user name and
password. If there is already such a
username/password pair, the system reports error
page; otherwise, it reports success page. When
the registration is completed, the user name,
password, and the real name and the billing
address are stored in a database system.
Results of Analysis (Sample) I
customer:
- Out side the system (need not be
represented.)
registration page:
- modeled as a boundary class.
user name:
- should not be modeled as a class.
- can be modeled as an attribute of another
class, e.g., CustomerIdentity.
 Results of Analysis (Sample)
II
password:
- attribute of CustomerIdentity.
username/password pair:
- attribute of CustomerIdentity

system:
- system reports error in the initial description of
the use case is not accurate enough.
- rephrase it as errors are reported in a
RegistrationErrorPage.
- Thus a RegistrationErrorPage should be created as a
boundary class.
 Results of Analysis (Sample)
III
error:
- should not be modeled as a class.
success:
- RegistrationSuccessPage should be created as a
boundary class.
real name: part of the CustomerInfomation class.
billing address: part of CustomerInfomation class.
database system: A boundary class called
CustomerInfoDB should be created to interact with the
customer database.

28
 Classes from Registration use
case(1)
RegistrationPage a boundary class for
registration.

RegistrationErrorPage a boundary class for

reporting registration error.

RegistrationSuccessPage a boundary class for

concluding the registration process.

CustomerIdentity an entity class which records

the user name and password of a customer.
 Classes form Registration use
case(2)
CustomerInfomation an entity class
which records the information of a
customer, e.g., his/her
CustomerIdentity, real name, and
billing address.

CustomerInfoDB a boundary class

which manipulates the customer
information database.
 Classes from other use
case(2)
SessionController a controller class for
coordinating a session. The class provides various
operations for logging on, logging off, adding items,
deleting items, clearing shopping cart, and
checking out.

BrowserPage a boundary class for browsing

product catalog.

LoginPage a boundary class for logging in.

LogoutPage a boundary class for logging off.

 Classes from other use
case(2)
CheckoutPage a boundary class for
accepting user credit card information and
checking out shopping cart.
CheckoutSuccessPage a boundary class
for presenting success information and
receipt.
CheckoutFailurePage a boundary class for
presenting failure information when financial
information verification fails
ShoppingCartPage a boundary class which
displays the contents of a shopping cart and
allows customer adding/removing items.
 Classes from other use
case(3)
FinancialDeptWrapper a boundary
class for interacting with financial
department.

ShippingDeptWrapper a boundary
class for interacting with shipping
department.

InventoryDB a boundary class for

interacting with inventory database.
 Resulting Diagram

Registration use
case
OO Design
 OO Design (1)

Goal: develop overall structure of

system
OO design can be split into two stages:
- High level design process:
- Detailed level design process:
Tools used:
- CRC cards, class diagram, interaction
diagram, state chart etc.
 OO Design (2)

High level design process:

- All classes needed for building the
system are identified and each class is
assigned a certain responsibility.
- Class diagram is constructed to further
clarify the static or dynamic
relationships among the classes.
- Based on the analysis of use cases,
interaction diagrams are drawn to show
the flow of events of each use case.
 OO Design (3)

Detailed level design process

- Based on the interaction diagrams,

attributes and operations are assigned to
each class.
- State machine diagrams are developed for
each class to describe further design details.
 Step 1: CRC Card Approach
(1)

Class-Responsibility-Collaborator (CRC)
Identify classes to build a system and
assign responsibilities to each class
CRC card modeling is a team work
1 Facilitator
1 Domain User
4-6 System Analyzer and Designer
 Step 1: CRC Card Approach
(2)
1 Facilitator
- Carries the discussion session
1 Domain User
- experts in business model
- Knows the business logic well and should have
good communication skills for explaining the
business needs to OO Design Analysts
System Analyzer and Designer (4-6)
- knows OO modeling well and are responsible for
filling out the contents of the cards.
 Card (1)

Class Name
Responsibility Collaborators
 Card (2)
A responsibility is a task that must be
performed by the class, or the knowledge
that is known by the class.
Example: one responsibility of the
SessionController class might be to
perform the adding item operation.
 Card (3)
A collaborator is a class that is involved in
accomplishing a responsibility.
Example: To add an item in the shopping
cart, the InventoryDB object is contacted to
save the new contents of the shopping cart.

Hence, InventoryDB is a collaborator for the

adding_item responsibility.
 How To Play (1)

Facilitator starts the process

Each player has one or more cards

Initial set of class are created (Analysis

class diagram or obvious classes
determined by the Sys. Arc.)
 How To Play (2)
Team examine each use case one by one
- Simulating the interaction andflow of events
that are used by to accomplish each use case

- Each player records the responsibilities of

classes involved

- If necessary, create new classes (assignment

of new cards done by facilitator)
 How To Play (3)
When a class is involved in the execution of the
interaction

- responsibility is recorded for that class

- class role player has to list the actions performed
by the class and the other classes (collaborators)
that are involved in the action.

The session continues until all details of each use

case are examined and all details of each
responsibility of each class are clear.
 Example: Use Case Register

Register: A customer visits the registration

page, and specifies the desired user name and
password and click submit button. If there is
already such a username/password pair, the
system reports error; otherwise, it reports
success. During a registration an account is
created, user name, password, and the real
name and the billing address are stored in a
database system.
 CRC Card1: RegistrationPage
(1)

RegistrationPage is involved in getting

user name and password.

An object is created when the customer

uses an Internet browser to visit the page.

When user clicks the submit button of

the RegistrationPage, the RegistrationPage
knows the user name and password.
 CRC Card1: RegistrationPage
(2)

Now when the submit button of the

registration page is clicked, a request
should be sent to register the user.

But to whom the request is sent?

The RegistrationController!

Therefore, the RegistrationPage must know

the RegistrationController.
 CRC Card1: RegistrationPage
(3)

By clicking the submit button

registration request can be made.

We add another two responsibilities Knows

RegistrationController and Handle click
event of submit button.

The collaborator of the submit button is

RegistrationController.
 CRC Card1: RegistrationPage
(2)

RegistrationPage
Responsibility Collaborators
Knows user name
Knows password
Knows RegistrationController
Handles click-event of RegistrationController
Submit button
 Handle click Event (1)
We need to add the responsibility of
handling the registration request.

To accomplish this responsibility,

RegistrationController needs to interact
with CustomerInfoDB to verify if a
username/password pair has already
existed or not.
 Handle Submit Event (2)
When CustomerInfoDB verifies the non-
existence of the desired
username/password pair,
RegistrationController needs to issue
request to CustomerInfoDB to create an
account of the desired username/password
pair.

Hence, the collaborator for the 1st

responsibility of RegistrationController is
the wrapper class CustomerInfoDB.
 Handle Submit Event (3)
Now when the registration is successful,
Registration Controller needs to create an
instance of RegistrationSuccessPage;
otherwise an instance of
RegistrationFailurePage is created.
 Handle Submit Event (4)

Request to create a user

account(User name, password)
 Session use case
1. Customer log in using correct user
name and password, the customer starts a
session.

2. During a session, the system maintains a

shopping cart, which records (maintain)
the list of desired items that the customer
wants to purchase later.

3. The session is terminated either because

the user checks out, logs out, or times
out.
CRC for Session Controller
Step 2: Construct Interaction
Diagram
Mostly used: sequence diagram
Process: reconstruct the flow of events
using sequence diagram

58
Example: Registration
object.
starts
with :

59
 Step 3: Build State Chart
When the analysis class diagram, interaction
diagram, and CRC cards are completed during
the high level design, we can proceed to the
detailed level design.

The detailed level design has to identify the

function interfaces and implementation details
of each class.

The outcome of the detailed design process is a

detailed class design diagram, (list of attributes
and operations/functions).
 How to build a state
diagram? (1)
When a class is responsible for a single use case,

- look into the use case description (flow of

events)
and corresponding interaction diagram

- identify the different stages that the control

classs object goes through, and then naturally
define the diagram.

61
 How to build a state
diagram? (2)
When the class is involved in multiple use cases

- we have to combine all the information

consider the environment variables and the change of internal

data values (especially boundary conditions) to identify the
states.

62
Example:
 Step 3: state diagram (1)

1. SessionController is triggered by the log-in event.

2. When the log-in is successful, the session class
enters a READY state that waits for user calls.
3. When a user calls for an operation, the system
enters in a corresponding state to process that call
(e.g., HANDLING_DEL_ITEM,
HANDLING_CHECKOUT, HANDLING_ADD_ITEM, etc).
4. Finally, when the LogoutPage is visited, the session
enters the final state.
 Step 3: state diagram (2)
Many of the states in the diagram are sub-states.
For example, the HANDLING_ADD_ITEM represent a sub-
state that handles add item to shopping cart.

The sub-state itself is essentially one state machine,

which starts from the READY state, invokes a
RemoveFromStock() operation provided by InventoryDB,
then depending on the returned result, updates and
saves the shopping cart, and finally displays the
message to user using the boundary Web forms.
 Draw a state diagram for
RegistrationController class
 Step 4: Class Design (2)
In detailed level design
- public attributes
- operations are identified
Class Name
Private:

Data (attributes)
Operations
Public:
Public interface
Data (attributes)
Operations
 Step 4: Class Design (1)
The designers and programmers of other
components will rely on the public interface
of a class any change of the public interface
will damage the work already done by other
designers.

Generally, we want the design of a public

interface to be complete and stable as
possible.
 Step 4: Class Design (3)
Public interface design starts from CRC cards.

By examining the responsibilities carried out by

the class and the interaction diagram within
which the class is involved, we can list the
attributes and operations that must be declared
in the class.
 Step 4: Class Design (4)
In practice, a class can declare public
attributes (most pre-defined constants.)

The majority of a public class interface

should be the set of operations.

Types of functions: constructor,

destructor, accessor, and mutator.
 Step 4: Class Design (5)
Constructor: Initialize the data members of an object
when it is created.

Destructor: Used to clean-off memory and free system

resources when an object is no longer in use

Accessor: Retrieves the information from the object

Mutator: Changes the state of the object by writing values

 Step 4: Class Design (6)
Once we have identified the public attributes
and public operations, we can go on to define
the implementation details of the class.

Then private attributes and operations that are

used to implement the public operations are
identified.
 Step 4: Identify public
operations

We start from the state chart of the class,

examine each of the public operations and
then nail down what attributes are needed.

Continue this process for all operations.

 Step 4: Identify public
operations
Each responsibility in CRC card with
collaborators we introduce one Or study
public the
operation.
sequence diagram,
each incoming
solid arrow
(message) should be
modeled as a public
Log_in(user_name, password):String
operation of the
class.
Log_out
Add_Item(int prouct_id):String

Del_Item
Clear_cart
Check_out
 Step 4: Identify parameters
and return values
What parameters are needed to invoke the operation.

What should be the return value.

Example: add_item() operation of the

SessionController.
Integer product_id of the product can be
passed to the add_item() operation
 Step 4: Identify parameters
and return values
We can return the execution result of the add item to
the customer and display the corresponding message.

Example: when the requested item is not in

stock, the operation should return an error
message explaining the reason. (return type
String)
 Identify attributes (1)
To identify the attributes we consider the
following factors.

1.Using CRC card: what must be known by the

class?
2.Examine the state chart: what states does
the object go through (they will be defined as
constant attributes)?
 Identify attributes (2)
To identify the attributes we consider the following factors.

3.Model the association (especially the dependency and

navigation association) of the class.
1..1 association: A reference type attribute is needed;
1..* association: A collection (e.g., ArrayList or Vector)
attribute is needed.
4. Other data members needed for the implementation of
public operations.
 Identify attributes (3)
What must be known by the class?

We add a variable for each known fact.

Example: InventoryDB is a known fact in SessionController class.

It is a reference type attribute as the relation to the

sessioncontroller class is 1..1
 Identify attributes (4)
Does the attribute is private or public?

Check all the interaction diagrams that the

SessionController classes are involved is there
any object/class that navigates to SessionController
(or takes SessionController as a parameter of their
operation), and needs to modify/read the variable
we model it has public variable otherwise private?
 Identify attributes (5)
Are there any more attributes to be included?

- Check the state machine diagram of the

SessionController class, we need one integer
attribute for recording state of the object.
- We need several pre-defined constants for
state names (e.g., READY, WAIT_LOG_ON,
HANDLING_ADD_ITEM, etc.). All of them can
be declared as private attributes since they
are for internal use only.
 Identify private operations
Private operation can be identified by breaking
down the implementation of public operations.

Example: To implement the SaveShoppingCart()

operation CustomerInfoDB.

we can introduce additional private operations

required to implement public operations.
CRC card of SessionController (1)

customer
information (an
instance of
CustomerInfomati
on),
CRC card of SessionController (2)

shopping cart (a
list of
ProductInfo).
CRC card of SessionController (3)

SessionController
class can navigate to
CustomerInfoDB,
InventoryDB,
FinancialDeptWrap
per, and
ShippingDeptWrap
per. (include one
reference for each of
these wrapper
classes. )
 Exercises: Detail design
of RegistrationController

RegistrationController
Private:
refCustomerInfoDB:object
refRegistrationPage:object

Public:
Register(username, password): String
Create_Reg_SuccessPage(): RegistrationSuccessPage
Create_Reg_FailurePage(): RegistrationFailurePage
 Design Exercises
1. Use the noun extraction method to extract the
set of classes involved in the check out use case.
2. Develop the CRC card of the Inventory.
3. Design the sequence diagram for the check out
use case.
4. Design the state machine diagram for the
RegistrationController class.
5. Complete the design class diagram of the OPS
system.
 CRC for LoginPage

LoginPage
Responsibility Collaborators
Knows username
Knows password
Knows SessionController
Handles click Login SessionController

88
 CRC for Logout Page

Logout Page
Responsibility Collaborators
Knows SessionController
Handles click Logout SessionController

89
 CRC for Checkout Page

Checkout Page
Responsibility Collaborators
Knows SessionController
Handles click Checkout SessionController

90
 CRC for InventoryDB

InventoryDB
Responsibility Collaborators
Knows SessionController
Remove one item from stock Shoppingcart
Add all items to the stock Shoppingcart

91
 CRC for CustomerInfoDB
CustomerInfoDB
Responsibility Collaborators
Knows SessionController,
RegistartionController
Create user account (user name, RegistartionController
password)
Knows customer infomation
Check valid user(user name, RegistartionController
password)
Save shopping cart Shoppingcart

Load shopping cart Shoppingcart

92