jim richardson oom cs377 phase 5 ip (2)

33
Running head: OBJECT ORIENTED METHODS CS377 1 Object Oriented Methods Jim Richardson Individual Project: Phase 5 Object-Oriented Design Revision CS377 Professor J. Williams Colorado Technical University June 22, 2014

Upload: jim-richardson

Post on 18-Jul-2015

85 views

Category:

Technology


3 download

TRANSCRIPT

Running head: OBJECT ORIENTED METHODS CS377 1

Object Oriented Methods

Jim Richardson

Individual Project: Phase 5

Object-Oriented Design Revision

CS377

Professor J. Williams

Colorado Technical University

June 22, 2014

OBJECT ORIENTED METHODS CS377 2

Table of Contents

Creating Use Case Diagrams – Phase 1 .......................................................................................... 3

Enterprise description ................................................................................................................. 3

Project description....................................................................................................................... 4

Use Case Diagram....................................................................................................................... 5

Updated Use Case Diagram: Reflects the addition of an outside order-review agency ......... 6

Use Case narrative ...................................................................................................................... 7

Creating Class Diagrams – Phase 2 .............................................................................................. 12

Updated Class Diagram ............................................................................................................ 13

Updated Class Diagram: Reflects the addition of an outside order-review agency ............. 14

Sequence and Collaboration Diagrams – Phase 3......................................................................... 15

Sequence Diagram .................................................................................................................... 15

Updated Sequence Diagram...................................................................................................... 17

Updated Sequence Diagram: Reflects addition of third party access ................................... 18

Updated Sequence Diagram: Reflects addition of third party access ................................... 19

Collaboration Diagram.............................................................................................................. 20

Updated Collaboration Diagram ............................................................................................... 21

Updated Collaboration Diagram: Reflects addition of third party access ............................ 22

State Transition Diagrams and Activity Diagrams – Phase 4 ....................................................... 24

State Transition Diagram 1: ...................................................................................................... 24

State Transition Diagram 2: ...................................................................................................... 25

Updated State Transition Diagram: Reflects addition of third party access ......................... 26

Activity Diagram 1: .................................................................................................................. 27

Activity Diagram 2: .................................................................................................................. 28

Updated Activity Diagram: Reflects addition of third party access ..................................... 29

Object-Oriented Design Revision – Phase 5................................................................................. 30

Object-Oriented Recap:............................................................................................................. 30

Change Control Documentation: .............................................................................................. 32

References:.................................................................................................................................... 33

OBJECT ORIENTED METHODS CS377 3

Creating Use Case Diagrams – Phase 1

Enterprise description

With the onslaught of high definition televisions and the demand for high definition

sound, a family owned dealer inaugurated commercial service by providing the Kansas City,

Missouri metro area with high quality, high definition audio components and accessories at

reasonable prices. Established in 1999, respective family owned dealer adapted a moniker,

becoming JaGR’s Refined Sound and Kansas City’s leading source for quality audio

components. Witnessing an immediate growth in cliental and business interactions, JaGR’s

Refined Sound expanded their inventory and warehouse to accommodate the metro area’s

demand for superior components. Two short years later, in 2001, JaGR’s Refined Sound opened

their second location, to better serve the growing client base, as well as an effort to increase their

product lines and inventory. As of 2014, six franchised locations serve the Kansas City and

surrounding areas. In light of recent e-commerce growth and intentions of serving global

markets, JaGR’s Refined Sound aspires to capitalize upon the convenience of ordering-from

home and e-commerce success. Therefore, in order to increase revenue and cliental, JaGR’s

Refined Sound launches an online ordering project. Essentially, through a series of “requests for

proposals”, JaGR’s Refined Sound establishes a report with R3 Technology, and initializes a

contract to commence web development. Fundamentally, JaGR’s Refined Sound will offer the

same service and products online, as they do in store. However, in order to maximize simplicity

and minimize complexity of ordering options, JaGR’s Refined Sound’s online ordering system

will only accept credit cards as payment. Before commencing development of JaGR’s Refined

Sound’s, R3 Technology and JaGR’s Refined Sound will inaugurate a brainstorming session,

complete with diagrams, to ensure the system will function as intended. Therefore, by adhering

OBJECT ORIENTED METHODS CS377 4

to industry standards, R3 Technology and JaGR’s Refined Sound will launch with Unified

Modeling Language (UML) Use Case Diagrams.

Project description

Essentially, JaGR’s Refined Sound will implement an online ordering system, so that

customers, locally and globally, will be able to order high quality, high definition audio

components and accessories from the comfort of their home. Principally, JaGR’s Refined

Sound’s online ordering system will only accept credit card payments. The online ordering

system will consist of a secure website portal, which will provide the customer with peace of

mind as they shop online, place items into their virtual shopping cart, enter their credit card

information, update payment or order entries, and place and view their order. The online

ordering system will be simple in the fact that customer payments will appear in JaGR’s Refined

Sound’s online account. Once the payment processes and posts onto JaGR’s Refined Sound’s

online account, the order manager will be able to review respective customer’s order and manage

the process by notifying warehouse attendants of which products to prepare for shipment.

Additionally, JaGR’s Refined Sound’s online ordering system will provide the ordering manager

with options to view an order and corresponding payment entry, and delete orders and

corresponding payment entries as necessary. Meanwhile, the warehouse attendant will be able to

view the order to verify that all items and the order are accurate, as well as to ensure posted

payment correlates with the corresponding order.

OBJECT ORIENTED METHODS CS377 5

Use Case Diagram

OBJECT ORIENTED METHODS CS377 6

Updated Use Case Diagram: Reflects the addition of an outside order-review agency

OBJECT ORIENTED METHODS CS377 7

Use Case narrative

Use Case: Create an order

Section Main

Actors Customer and Employee

Purpose The purpose of the Use Case “Creating an order” emerges as a function that provides a customer with an opportunity to place desired item(s) into their virtual shopping cart. Thus formally

creating an order

Overview Once the item(s) enter the shopping cart, the system reviews the current inventory to ensure availability. If respective item(s) are

available, the system de-allocates the item(s) from inventory and retains the desired item(s) until the customer enters payment

information.

Typical course of events The customer browses through the selection of products, selects the products by placing them into the virtual shopping cart. The customer repeats this process until there are no more desired items

left to purchase. As each item enters the shopping cart, the system verifies inventory, de-allocates respective item(s) from current

inventory, and retains the item(s) in the shopping cart to guarantee availability to the customer. Once the customer is ready to check out, they progress to the “enter payment” screen by clicking “check

out”.

System response The system accepts item(s) into the virtual shopping cart, de-allocates item(s) from current inventory, and retains desired item(s)

until the customer enters payment information.

Alternative courses An error could occur during the ordering process; such as the shopping cart fails to retain the item(s) until the customer enters payment information, in which the customer could contact the

nearest store and speak with an employee. Once a customer contacts and communicates with an employee, an employee is capable of

manually overriding the system by entering the order from the server side.

System response Initially, an error could indicate that the shopping cart does not

recognize an item in the shopping cart, and would then not de-allocate or retain the item(s). Once the system experiences employ override, on the server side, the system would reflect the order by

de-allocating and retaining the item(s) until payment information is entered.

Use Case: Enter payment information

Section Main

Actors Customer and Employee

Purpose The “Enter payment information” process provides a customer with

OBJECT ORIENTED METHODS CS377 8

an opportunity to enter their credit card information to finalize the purchase of the item(s) they placed into their virtual shopping cart. Once purchased, the item(s) will be available to prepare for

shipment or picked-up by the customer.

Overview Essentially, the “Enter payment information” process guarantees that the desired item(s) are available and the de-allocation from

inventory is successful. Principally, the “Enter payment information” is a secure connection that allows the customer to enter

their credit card information and accepts their form of payment for desired products. .

Typical course of events The typical course of action is the system progresses from the virtual shopping cart screen to the “Enter payment information” screen so

that the customer is able to enter their credit card information. Once the customer enters credit card information, the system verifies the

credit card information, verifies available inventory, and removes desired amount of items from the available inventory. Then the system sends a confirmation number to the customer, verifying the

process is complete. Meanwhile, the system notifies the Order Manager that a customer has placed an order.

System response The system secures a portal, presents the “enter payment

information” screen, allows a customer to enter credit card information, verifies credit card, verifies inventory, charges credit card, returns a confirmation number to the customer, and then

notifies that an order is available for review.

Alternative courses The system could encounter an error when validating the credit card or verifying inventory, to which the system would issue an error

message and contact information so that the customer could contact the corresponding store for over the phone ordering by an employee manually entering the credit card information from the server side by

accessing the “Update payment entry” option.

System response In the event that the system is unable to verify credit card information or verify available inventory, the system will notify both

the customer and the Order Manager of the corresponding error. Once the error message appears, the customer has the option of

contacting the store so that an employee can manually enter the data from the server side by accessing the “Update payment entry” option.

Use Case: Update payment entry

Section Main

Actors Customer and Order Manager

Purpose The purpose of the “Update payment entry” action is so that a customer or Order Manager is able to either enter new credit card

information or re-enter preexisting credit card information when an

OBJECT ORIENTED METHODS CS377 9

error occurs during the initial attempt.

Overview During the ordering process, and before submitting the order, the system will offer an opportunity to the customer to change or re-

enter their credit card information. Additionally, the “Update payment entry” will be an option, from the server side, for the Order Manager to enter the credit card information manually into the

system when a customer has an issue or the system malfunctions on the client side.

Typical course of events The system secures a portal, presents the “enter payment

information” screen, allows a customer to enter credit card information, verifies credit card, verifies inventory, presents the option to “Update payment entry” by allowing the customer to

change or re-enter credit card information. Then the “enter payment information” or “Update payment entry” action charges the

corresponding credit card, returns a confirmation number to the customer, and notifies the corresponding location that an order is available for review. Additionally, the “Update payment entry”

option provides the Order Manager with an opportunity to enter the credit card information manually from the server side.

System response The system secures a portal, presents the “enter payment

information” screen, allows a customer to enter credit card information, verifies credit card, verifies inventory, presents the option to “Update payment entry” by allowing the customer to

change or re-enter credit card information. Then the “Update payment entry” charges credit card, returns a confirmation number

to the customer, and then notifies the corresponding location that an order is available for review.

Alternative courses The system could encounter an error when validating the credit card or verifying inventory, to which the system would issue an error

message and contact information so that the customer could contact the corresponding store for over-the-phone ordering. Once the

customer contacts the corresponding Order Manager, the system will present an option for the Order Manager to enter the credit card information manually from the server side by accessing the “Update

payment entry” option.

System response The system would return an error message, complete with contact information, to the customer and notify the corresponding Order

Manager that an error occurred during credit card or inventory verification. Once the error message appears, the customer has the

option of contacting the store so that an Order Manager can manually enter the data from the server side. Once the Order Manager manually updates the payment entry, the system will verify

the credit card information and available inventory. Then the “Update payment entry” option will charge the credit card and return

confirmation to the customer.

OBJECT ORIENTED METHODS CS377 10

Use Case: View an order and payment entry

Section Main

Actors Customer, Employee, and outside Order Review and Survey Agency

Purpose The purpose of the “View an order and payment entry” option is so that the customer can review their complete recent order and

payment entry. Additionally, the “View an order and payment entry” provides an employee with an opportunity to verify payment and confirm which product(s) to prepare for shipment to the

corresponding customer. Furthermore, by allowing a third party access to the “View and order and payment entry” use case, the third

party “Order Review and Survey Agency” can accurately track products sold and compile a list of most sold items, as well as relate this information back to JaGR’s Refined Sound, to which will

provide adequate and precise market research. Additionally, this market research will aid JaGR’s Refined Sound in determining price

points for products.

Overview The system will store the most recent order for review by the customer, employee, and third party survey agency. After placing

the order, the system will return an order confirmation to the corresponding location so that an employee can verify processed payment for products. The confirmation will serve as a pick-list for

the employee as they prepare items for shipment, as well as a form for tracking list for survey purposes.

Typical course of events The system stores the most recent order and payment transaction for

review by the customer. Additionally, the system issues an order confirmation to the corresponding location so that an employee can verify payment for products and serve as a pick-list. Once the

payment experiences verification, the third party Survey Agency will be able to collect the data of products sold, to which will aid in

generating an accurate survey that will indicate the most sold, least sold, and average product movement. This report will assist JaGR’s Refined Sound in determining and adjusting prices according to

market research.

System response The system will store each customer’s recent and open order, complete with payment verification. Upon request, the system will

display order and payment details to both the customer and an employee. The system will provide both customer and employee with options to print the “View an order and payment entry” screen

for personal records and to serve as a pick-list. After receiving payment, the system will make the list of products sold available for

review by the outside third party survey agency.

Alternative courses The system could encounter an error during the storing or displaying process of an order entry. The system could fail to release the list of products sold or refuse third party views.

System response In the event that an error occurs, the system will issue an error message to the corresponding parties (i.e. employee, customer,

OBJECT ORIENTED METHODS CS377 11

and/or third party survey agency), stating that the corresponding entry or list is irretrievable.

Use Case: Delete an order and payment entry

Section Main

Actors Order Manager

Purpose The purpose of the “Delete an order and payment entry” is so that an Order Manager can delete an order if the item is no longer available

or the customer cancels or returns an item.

Overview In the event that a customer decides to cancel an order or return an item, or an item is not available, an Order Manager can return the funds to the customer’s credit card and delete the entry from the

system so that the credit card does not experience additional or accidental charges. In addition, the “Delete an order and payment

entry” option allows Order Managers to clean out the system by removing outdated and archaic orders or expired credit card entries.

Typical course of events The system will offer an option to organize order entries by

ascending or descending order by date and credit card expiration date. Once all entries experience sorting by predetermined order, an Order Manager can view each entry and delete entries as necessary.

Once an Order Manager deletes an entry, the entry is removed from the system’s memory and database.

System response The system presents a sorted list of entries and allows options of

deletion. Once an entry is deleted, the system reclaims the corresponding space in memory and shifts the subsequent entries up one space, per deleted entry.

Alternative courses An error could occur during the deletion process, to which would

leave partial information on the system’s memory and in the database, causing the subsequent entries to shift up and assume the

previous entry’s partial data.

System response The system shifts partial data up one space in memory, combining the intended deleted data with saved data, causing inaccuracies within the remaining entries. In the event that this instance occurs,

the Order Manager must realign the database manually by deleting the residual information and realigning the entries.

OBJECT ORIENTED METHODS CS377 12

Creating Class Diagrams – Phase 2

In light of manual processes performed, below is an updated Class Diagram that illustrates the

removal of unnecessary elements, such as the Warehouse Attendant and Order Manager.

OBJECT ORIENTED METHODS CS377 13

Updated Class Diagram

OBJECT ORIENTED METHODS CS377 14

Updated Class Diagram: Reflects the addition of an outside order-review agency

OBJECT ORIENTED METHODS CS377 15

Sequence and Collaboration Diagrams – Phase 3

Sequence Diagram

OBJECT ORIENTED METHODS CS377 16

OBJECT ORIENTED METHODS CS377 17

Updated Sequence Diagram

OBJECT ORIENTED METHODS CS377 18

Updated Sequence Diagram: Reflects addition of third party access

OBJECT ORIENTED METHODS CS377 19

Updated Sequence Diagram: Reflects addition of third party access

OBJECT ORIENTED METHODS CS377 20

Collaboration Diagram

OBJECT ORIENTED METHODS CS377 21

Updated Collaboration Diagram

OBJECT ORIENTED METHODS CS377 22

Updated Collaboration Diagram: Reflects addition of third party access

OBJECT ORIENTED METHODS CS377 23

OBJECT ORIENTED METHODS CS377 24

State Transition Diagrams and Activity Diagrams – Phase 4

State Transition Diagram 1:

OBJECT ORIENTED METHODS CS377 25

State Transition Diagram 2:

OBJECT ORIENTED METHODS CS377 26

Updated State Transition Diagram: Reflects addition of third party access

OBJECT ORIENTED METHODS CS377 27

Activity Diagram 1:

OBJECT ORIENTED METHODS CS377 28

Activity Diagram 2:

OBJECT ORIENTED METHODS CS377 29

Updated Activity Diagram: Reflects addition of third party access

OBJECT ORIENTED METHODS CS377 30

Object-Oriented Design Revision – Phase 5

Object-Oriented Recap:

Object Management Group (OMG) created the Unified Modeling Language (UML) to

increase uniformity and standardize the process of creating graphical representations, otherwise

known as diagrams, for illustrating various system processes, relationships between processes,

and sequential order or general flow of processes. Incorporating UML into the development life

cycle is a sure method of increasing comprehension and providing an avenue for gaining

immediate awareness of system or software processes. Fundamentally, incorporating UML

assists development by providing an avenue or medium for pseudocode and actual program code

to emerge (Davoren, 2011). Therefore, in light of the fact that pseudocode and actual coded

attributes and methods materialize within the diagramming processes, UML diagram

conventions is beneficial and aids in software or systems development.

From a personal perspective, incorporating UML as the foundation for development of

JaGR’s Refined Sound’s online website and ordering system enhances the process of future

system development. Essentially, by designing and utilizing Use Case Diagrams, we have a

better perspective of the intended processes. First, incorporating the Use Case Diagram allows us

to obtain a high-level view of the proposed system and accurately determine the Use Case

scenarios that are necessary for achieving the intended results. Second, integrating the

subsequent level of diagrams, the Class Diagrams, provides the developer with an avenue to

determine the methods, attributes, and relationships between the actual objects or classes.

Furthermore, by assimilating the Class Diagram we are able to preemptively determine the

variables, method designations, and corresponding attributes for coding the program, as well as

discover applicability of classes and relationships between classes or determine general

OBJECT ORIENTED METHODS CS377 31

applicability and functionality of each individual class. Third, as we develop the Sequence

diagram, we can determine the sequential order of processes adequately, to which will aid in

formulating and calling the methods, in correct sequential order, within the actual program

during the software or system development process. Furthermore, the Sequence Diagram will

provide an avenue for discovering additional requirements or reasons to eliminate redundant

methods or processes.

Next, the Collaboration diagram is beneficial and enhances the development process by

providing an additional perspective of the general flow of processes. Additionally, the

Collaboration diagram enhances the development process by providing a lower-level view of

relationships between classes. Fourth, the State Transition provides an overarching view of how

the system will interact with the predetermined processes, as well as indicate criterion that causes

the system to transition from one state to the next, resulting in an immediate awareness of the

parameters required. Lastly, the Activity Diagram emerges as a beneficial implementation

because of lower-level view of process flow. By incorporating the Activity Diagram, we can

determine the actual flow of the program, from one process to another. Furthermore, in light of

the fact that the Activity Diagram encompasses decisional elements, we can gain supplemental

insight as to how the system should function when options emerge, such as continue or

terminate. Generally, all six diagrams are an integral portion of the design process because each

provides variant perspectives of the system, as well as variant views of how the system should

function. Therefore, from personal sentiments, each diagram has a specific purpose and function,

to which all serve one purpose, ensuring the system has an adequate foundation of research and

information through exposing the system from different perspectives.

OBJECT ORIENTED METHODS CS377 32

Change Control Documentation:

Change Control

Original Information Changes Made Location of Change Reason for Change

Class Diagram contained Customer, Order Manager, Warehouse Attendant, Payment Information, Inventory, and Product classes

Eliminated Order Manager and

Warehouse Attendant

Class Diagram (p. 13) Because the Order Manager and

Warehouse Attendant performed manual

processes, it is essential that we eliminate manual

processes because the system does not

perform these functions automatically or from

a program perspective

The original diagram included Customer, Create Order, Verify Inventory, and Enter Payment Information

Modify Create Order,

View Inventory, and Enter Payment

Information objects to reflect objects instead of processes

Sequence Diagram (p.

17)

Change was necessary

because the original information indicated

processes instead of designating objects

OBJECT ORIENTED METHODS CS377 33

References:

Davoren, J. (2011, November 15). What are the benefits of uml? Retrieved from Demand Media

website: http://www.ehow.com/info_12198566_benefits-uml.html