Welcome Sample Reuse Use Case Model

8/8/2019 Welcome Sample Reuse Use Case Model

1/18

Sample Workproduct Service Creation Use Case Model

Sample Service Creation Use Case Model

Author: Calvin Lawrence

Document:


2/18


Document:

Document History

Document LocationThis is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Referto the author if you are in any doubt about the currency of this document.

Revision History

Date of this revision: 12-Dec-2006 Date of next revision (date)

Approvals

This document requires following approvals. Signed approval forms are filed in the Quality section of thePCB.

Name Title

(name) (title)

Distribution

This document has been distributed to

Name Title

(name) (title)


3/18


Contents1. Introduction.............................................................................................................4

1.1 Identification ....................................................................................................................................41.2 Description ......................................................................................................................................41.3 Purpose...........................................................................................................................................41.4 References......................................................................................................................................4

2. Use Case Overview................................................................................................52.1 Preamble.........................................................................................................................................52.2 Actors ..............................................................................................................................................52.3 Use Case List ..................................................................................................................................62.4 Use Cases.......................................................................................................................................6

2.4.1 UC-S1-01: Account On-Boarding Using Web Interface .........................................................62.4.2 UC-S1-02: Customer Order Onboarding ................................................................................82.4.3 UC-S1-03: Credit Authorization Service................................................................................112.4.4 UC-S1-04: Out-of-stock Ordering Service (success)............................................................122.4.5 UC-S1-05: Out-of-stock Ordering Service cant procure product (failure)............................142.4.6 UC-S1-06: Account Security Authorization Service for ordering..........................................16

Document:


4/18


1. IntroductionThis chapter identifies the document and the (sub) system to which it relates, describes the contents ofthe document, and states its purpose.

1.1 Identification

This document describes the Use Case Model for the IBM SOA Configuration for Leveraging Legacy andPackaged Applications. Use cases are provided for several examples of the configuration.

1.2 Description

The Use Case Model work product describes the functional requirements of the system underdevelopment. The model uses structured text to specify the ways in which users in specific roles will use

the system (i.e., use cases). The textual descriptions describing the use cases are from a users point ofview; they do not describe how the system works internally or its internal structure or mechanisms.

The Use Case Model consists of the following:

Preamble general considerations, style and assumptions

Actors their role and brief description

Use case list the names and numbers of the use cases

Use cases definitions of each kind of system usage using a standard template

1.3 PurposeThe main purpose of use case modeling is to define the boundary of the proposed software in terms of itsfunctional behavior. It is the part of the contract between the client and the development team. It tellsthe client what will be delivered, and it tells the development team what it must build. It also:

Provides a basis of communication between end users and system developers

Is the primary driver for estimating the application development effort

Provides a basis for planning the development of the releases

Provides a basis for identifying objects, object functionality, interaction, and interfaces

Provides the primary basis for defining the user interface requirements

Provides a basis for defining test cases

Serves as the basis for acceptance testing

Provides a basis for producing user support materials, such as user documentation and electronicperformance support interventions

1.4 References

Document:


5/18


2. Use Case Overview

2.1 PreambleThis document describes use cases for patterns that deal with creating services.

1. Expose Legacy via Service Component: Utilizing a Service Component decouples serviceinterface from the implementation details

2. Direct Access to Legacy: Legacy platform provides service invocation framework, i.e., CICS3.1 provides Web services support natively.

3. Third-party consumer: Architecture will consume credit validation service from third-partypartner that owns Credit Service.

4. Third-party provider: Out-of-Stock third-party provider will provide procurement service to beutilized by architecture to complete order process.

These are generic patterns, which are described in this document in the context of specific examplesdrawn from the IBM SOA Configuration for Leveraging Legacy and Packaged Applications.

These use cases are described in the following context:

1. A customer asks to open a new account. The customer service rep or a remote sales rep logsonto the Account Management application to handle the request.

2. After a customer has a valid account, the customer continues to order the product of their choice.The CSR or Remote Sales Rep manages and procures the order using the Order Managementand Procurement system.

3. The Partner Credit Authorization service is called from a partner location (Credit ManagementPartner). If the customers credit score is accepted, then the item is ordered.

4. The customer orders an item that is not in stock. The out-of-stock service is invoked from apartner location to procure the product(s).

5. If the item is located by the out-of-stock partner procurer, a message is sent back to the callingapplication indicating that the order was received and processed, and a date when the productwill be shipped is provided.

2.2 Actors

Name Short DescriptionCustomer A customer of the company.CSR Customer Service Rep (Lily) at store location.Sales Rep (Remotesales office)

Account Manager (Albert) for the Account On-boarding process.

Security System Enterprise security system which checks authorization of users to accessservices / data.

Web Service (EJB) Mediates service requests.Account History Application that manages account history (CICS).

Partner Credit ScoringService (CSS)

Remote service, provided by a partner, that provides credit scores.

Customer ManagementSystem (CMS)

Maintains customer information.

Out-of-stock System application that procures out-of-stock items, provided by a partner.Business Analyst A LOB professional who designs and documents business processes.Integration Developer An IT professional who works with Business Analysts to define business.

Document:


6/18


processes in technical terms, i.e. BPEL specifications.Pricing Service An application with a Web services interface that provides pricing information.Order Capture System An application with a Web services interface that processes purchase orders.

2.3 Use Case List

Number NameUC-S1-01 Account On-Boarding Using Web interfaceUC-S1-02 Customer Order On-BoardingUC-S1-03 Credit authorization ServiceUC-S1-04 Out-of-stock Ordering Service (success)UC-S1-05 Out-of-stock Ordering Service cant procure product (failure)UC-S1-06 Account Security Authorization Service for ordering

2.4 Use Cases

2.4.1 UC-S1-01: Account On-Boarding Using Web Interface

VersionIssuedate

Author Changes

0.1 01-15-07 CLawrence

First release

Version

Scope & LevelGoal in contextPreconditions Users authenticated to Web interface (Web server/portal)

Successful outcome Request for new account is either approved or declined.

Failure OutcomeConditionleading tooutcome

Authorizationerror

Error returned to user User notauthorized toaccess service

Local serviceunavailable

Error returned to user Local serviceprovider hasfailed; user not

authorized toaccess remoteservice provider

Failure outcomes

Remote serviceunavailable

Error returned to user Remote serviceprovider hasfailed;connection toremote serviceprovider hasfailed.

Primary actor Account Management System

Secondary actorsCSRAccount Owner

Security System

Document:


7/18


ESBAccount HistoryCredit Scoring Service (CSS)Customer Management System (CMS)

Main scenario

1. The CSR enters information regarding the request to open a new

account and line of credit and submits the request to the portal.2. The portal sends the request details as an eForm to the Content

Manager.3. The portal sends an asynchronous (WMQ) notification about the request

to the ESB.4. The ESB sends this notification to the task queue for the appropriate

region that houses the CICS region, i.e., Southeast.5. The Account Manager opens the Accounts Review page on the

portal/Web interface. The Security System intercepts the request andrequires the Account Manager to authenticate by entering a user ID andpassword.

6. The Account Managers credentials are validated by the Security System,which generates a token and passes it to the portal.

7. The portal validates the token, creates a session for the AccountManager, and generates the Accounts Review page. This page has fourportlets.

8. The first portlet makes an asynchronous (SOAP/JMS) request to the ESBto retrieve all pending new account requests for the Account Managersregion.

9. The ESB sends a request to retrieve the requested information regardingpending new account requests from the task queue for the given regionand returns it to the Account Request portlet.

10. The Account Manager selects a pending new account request from thetask list on the Account Request portlet. This portlet sends asynchronous message to the other three portlets with informationregarding the customer and the new account request.

11. The second portlet on the Accounts Review page makes synchronous(SOAP/HTTP) requests to the ESB to retrieve account history informationfor the customer.

12. The ESB sends requests to the Account History application (CICS) andreturns the account history to the second portlet for display to theAccount Manager. This display includes Account Owner names withtheir instant messaging (Sametime) status.

13. The third portlet on the Accounts Review page sends an asynchronous(WMQ) message for a credit score on the customer to the ESB.

14. The ESB routes the message to a remote Credit Scoring Service,through a partner gateway.

15. The CSS returns the credit score through an asynchronous message(WMQ) to the ESB, which routes the message to the third portlet which

displays the credit score to the Account Manager.16. The fourth portlet on the Accounts Review page displays an eForm that

the Account Manager can use to accept or decline the new accountrequest.

17. The Account Manager has a question about an account on the AccountHistory and sees that the Account Owner is online. The AccountManager clicks the Account Owners name in the Account History portlet,enters a message, and sends it.

18. The portal sends a synchronous message to the Account Owners portalwindow. The Account Owner replies to the message. The portal sendsthe reply to the Account Manager.

19. The Account Manager enters the decision to accept or decline the newaccount request into the eForm on the fourth portlet.

20. The fourth portlet sends a synchronous (SOAP/HTTP) request to the

Document:


8/18


Customer Management System (WebSphere app) to take appropriateaction on the new account request.

Alternatives Not documented

Variations1. Instead of the CSR submitting the new account request, the customersubmits it directly via a customer portal. The other steps would be the same.

Related information Not documentedIssues Refer to Risk Assessment.

2.4.1.1 UC-S1-01 Use Case Diagram

U s e C a s e : U C - S 1 - 0 1 A c c o u n t O n b o a r d in g

C u s t o m e r

C S V

C I C S

A c c o u n t O n b o a r d i n g

M id d l e w a r e

2.4.2 UC-S1-02: Customer Order Onboarding

Version VersionIssuedate

Author Changes

Document:


9/18


0.1 C.Lawrence

First release

Scope & LevelGoal in contextPreconditions Users authenticated to portal, Credit Score is accessible

Successful outcome Request for a new order is completed


Authorizationerror

Error returned to user User notauthorized orderproducts

Local service

unavailable

Error returned to user Local service

provider hasfailed; user notauthorized toaccess remoteservice provider

Failure outcomes



Primary actor Order Manager

Secondary actors

CSRAccount OwnerSecurity SystemESBAccount HistoryCredit Scoring Service (CSS)Customer Management System (CMS)

Main scenario

1. The CSR enters the requested product information in the system.2. An asynchronous (WMQ) request to order a product is sent to the Order

Management System with the Customer ID and Product Informationprovided by the customer.

3. The Order Management System sends the request to the ESB.4. The ESB sends request to the Enterprise Order System on the

designated CICS system.5. The CICS system processes the order and tries to procure the item by

sending a notification to the warehouse management system. If theitems is located in the warehouse management system, a message issent back to the calling Order Management Onboarding process. TheCSR enters the requested product information in the system

6. An asynchronous (WMQ) request to order a product is sent to the OrderManagement System with the Customer ID and Product Informationprovided by the customer.

7. The Order Management System sends the request to the ESB.8. The ESB sends request to the Enterprise Order System on the

designated CICS system.9. The CICS system processes the order and tries to procure the item by

sending a notification to the warehouse management system. If the

Document:


10/18


items is located in the warehouse management system, a message issent back to the calling Order Management Onboarding process.

10.


Variations

1. Instead of the CSR submitting the new account request, the customer

submits it directly via a customer portal. The other steps would be thesame.

Related information Not documented

Issues Refer to Risk Assessment


C u s t o m e r

C S V

C I C S

O r d e r O n b o a r d in g

M id d l e w a r e

U s e C a s e : U C - S 1 -0 2 O r d e r M a n a g e m e n t

Document:


11/18


2.4.3 UC-S1-03: Credit Authorization Service

VersionIssue

date

Author Changes

0.1 13-Nov-06

C.Lawrence

First release

Version

Scope & LevelGoal in contextPreconditions Users authenticated to system

Successful outcomeNumeric credit score is retrieved successfully from the Credit authorizationsystem


Authorizationerror



Error returned to user Local serviceprovider hasfailed; user notauthorized toaccess remoteservice provider

Failure outcomes

Remote service

unavailable

Error returned to user Remote service

provider hasfailed;connection toremote serviceprovider hasfailed.

Primary actor Account Management System

Secondary actors

Business AnalystIntegration DeveloperCSRAccount OwnerSecurity SystemContent Manager (CM)

ESBAccount HistoryCredit Scoring Service (CSS)Customer Management System (CMS)E-mail SystemCustomer

Main scenario

1. CSR/Sales Rep/System request credit authorization on a potentialcustomer.

2. The CSR enters information regarding the request to check to seewhether or not the customer is approved credit wise to continue theorder process..

3. The request is routed to the ESB and the ESB determines the correctCredit reporting partner to use based on the region in which the customer

resides.

Document:


12/18


4. The ESB routes the asynchronous message to the Partner Creditapplication.

5. The Credit application sends a message back to the ESB that getsrouted back to the calling Order Management Application.

6. If the score is higher than 600, the customer can continue the ordering

process, if less, then the customer is declined and no further processingwill take place.

Alternatives None documented.VariationsRelated informationIssues Refer to Risk Assessment


C u s t o m e r

C S V

O r d e r O n b o a r d i n g

C r e d i tA u t h o r i z a t i o n

P a r t n e r

U s e C a s e : U C - S 1 - 0 3 C r e d it C h e c k

C r e d i t O K

2.4.4 UC-S1-04: Out-of-stock Ordering Service (success)

VersionIssuedate

Author Changes

0.1 13-Nov-06

C.Lawrence

First release

Version

Scope & LevelGoal in contextPreconditions Users authenticated to portal.

Successful outcome Request for new account is either approved or declined.

Document:


13/18



Authorizationerror

Error returned to user User notauthorized to

access serviceLocal serviceunavailable


Failure outcomes



Primary actor CSR (at a Third-Party Call Center)

Secondary actors

Account ManagerAccount OwnerSecurity SystemContent Manager (CM)ESBAccount HistoryCredit Scoring Service (CSS)Customer Management System (CMS)

Main scenario

1. The CSR enters the requested product information in the system.2. An asynchronous (WMQ) request to order a product is sent to the Order

Management System with the Customer ID and Product Information providedby the customer.3.The Order Management System sends the request to the ESB.

4. The ESB sends request to the Enterprise Order System on the designatedCICS system.

5. The CICS system processes the order and tries to procure the item bysending a notification to the warehouse management system. If the items islocated in the warehouse management system, a message is sent back to thecalling Order Management Onboarding process. The CSR enters therequested product information in the system

6. An asynchronous (WMQ) request to order a product is sent to the OrderManagement System with the Customer ID and Product Information provided

by the customer.

7. The Order Management System sends the request to the ESB.


9. The CICS system can not processes the order and tries to procure theitem, by sending a notification to the warehouse management system.If the item(s) is not located in the warehouse management system, amessage is sent back to the calling Order Management Onboarding processindicating that the item can not be ordered.10. Steps 1-3 above is repeated.11. The ESB sends a Web service request to the out-of-stock Partner system

to procure the item(s)

Document:


14/18


12. The products is located and processed by the out-of-stock Partnersystem.

13. The out-of-stock Partner system sends a request back to the ESBindicating that the products has been ordered. The ESB routes themessage back to the Order management Onboarding process indicating

that the process is complete.Alternatives Not documentedVariations Not documentedRelated informationIssues Not documented


Cus tomer

C SV

CICS

Order Onboarding

Midd leware

Use Case: UC-S1-04 Out-of -Stock Order ing

Out-of -S tock

Par tner

1

2

4

5

6

Order Success

Order Fai lure

2.4.5 UC-S1-05: Out-of-stock Ordering Service cant procure product(failure)

VersionIssuedate

Author Changes

0.1 C.Lawrence

First release

Version

Scope & Level

Document:


15/18


Goal in contextPreconditions Users authenticated to portal

Successful outcomeOut-of-stock Partner program sends a message back to calling programindicating that the product(s) can not be ordered from their warehouse.

Failure Outcome

Condition

leading tooutcome

Authorizationerror




Failure outcomes



Primary actor CSR

Secondary actors

Account OwnerSecurity SystemContent Manager (CM)ESBAccount HistoryCredit Scoring Service (CSS)

Customer Management System (CMS)

Main scenario

1. The CSR enters the requested product information in the system.2. An asynchronous (WMQ) request to order a product is sent to the OrderManagement System with the Customer ID and Product Information providedby the customer.3.The Order Management System sends the request to the ESB.


5. The CICS system processes the order and tries to procure the item bysending a notification to the warehouse management system. If the items islocated in the warehouse management system, a message is sent back to thecalling Order Management Onboarding process. The CSR enters the

requested product information in the system.6. An asynchronous (WMQ) request to order a product is sent to the OrderManagement System with the Customer ID and Product Information providedby the customer.

7. The Order Management System sends the request to the ESB.


9. The CICS system can not processes the order and tries to procure theitem by sending a notification to the warehouse management system.If the item(s) is not located in the warehouse management system, amessage is sent back to the calling Order Management Onboarding process

indicating that the item can not be ordered.

Document:


16/18


10. Steps 1-3 above is repeated.14. The ESB sends a Web service request to the out-of-stock Partner system

to procure the item(s).15. The products can not be located and processed by the out-of-stock

Partner system.

The out-of-stock Partner system sends a request back to the ESB indicatingthat the product can NOT be ordered. The ESB routes the message back tothe Order management Onboarding process indicating that the process iscomplete.


Variations Not documented

Related information UC-S1-01: Account On-Boarding Using Simple PortletsIssues Not documented


Customer

C SV

CICS

Order Onboarding

Middleware

Use Case: U C-S1-05 O ut-of-Stock Order ing ( fa ilure)

Out-of-StockPar tner

1

2

4

5

6

Order F ai lure

Use C ase: UC-S1-04 O ut-of-Stock Order ing

Order F ai lure

2.4.6 UC-S1-06: Account Security Authorization Service for ordering

VersionIssuedate

Author Changes

0.1 C.Lawrence

First release

Version

Document:


17/18


Scope & LevelGoal in contextPreconditions

Successful outcome User authenticates system successfully

Failure Outcome

Condition

leading tooutcome

Authorizationerror




Failure outcomes



Primary actor CSR

Secondary actors

CustomerPricing ServiceEJBOrder Capture System

Main scenario

1. CSR passes User credentials to the Account management service.2. The Account Management services calls the security service to

determine whether or not the Customer is already registered in thedatabase.3. If the customer is registered, then the security service passes the

customer order privileges (Platinum-Gold-Silver-No Order).

Alternatives Not documentedVariations Not documentedRelated information Not documentedIssues Not documented

Document:


18/18



C u s t o m e r

C S V

O r d e r O n b o a r d in g

S e c u r it y

S e r v e r

U s e C a s e : U C - S 1 - 0 6 A u t h e n t i c a t io n

Documents

Welcome Sample Reuse Use Case Model