Process-oriented modeling for SOA, Part 4: Tying it all together with a case study

How your process model drives the use case and service models

Learn how a process model drives both a use case model and service model. This article ties everything together with a case study about home shopping that illustrates the concepts in the previous parts of this series. In this series, learn about a new business process decomposition technique that can help you specify business processes that are aligned with a Service-Oriented Architecture (SOA).

Mike Evans (mike.w.evans@uk.ibm.com), Senior Managing Consultant, Business Analyst, IBM

Photo of Mike EvansMike is a business analyst for IBM Global Business Services UK. He works with clients on complex systems integration programs to help them develop requirements to support their business objectives and define appropriate solutions.



Ruud Schoonderwoerd (ruud.schoonderwoerd@uk.ibm.com), Managing Consultant, IT Architect, IBM

Ruud Schoonderwoerd photoRuud Schoonderwoerd is a managing consultant and IT architect for IBM Global Business Services in the UK. He works on large IT programs at IBM client sites, focusing on BPM, SOA, and delivery methods.



24 March 2009

Also available in Chinese Vietnamese Spanish

Introduction

In Parts 1 and 2 of this series you learned a method for creating process models that are closely aligned to a Service-Oriented Architecture (SOA) based target architecture. The models show better fidelity to the actual solution being implemented. Part 3 extends the principle, describing a use case modeling technique based on the process model, making the use cases similarly aligned to the target architecture.

This article uses an example case study of a hypothetical company, Books R Us, to illustrate the concepts in the first three parts of this series. Learn how a process model drives both a use case model and service model.


Home shopping case study

The fictitious Books 'R Us sells books online. Customers can browse the catalog of books in a variety of ways, and can order books from the company’s Web site. Third party retailers can order books with a Business-to-Business (B2B) Web services interface and can link it to their own systems. Once a customer or business partner places an order from either of these two channels, the order is fulfilled. Fulfillment involves processing payment and shipping the products to the customer. Specific problems, relating to payment and stock, that can occur during fulfillment are covered in the case study.

About the examples

For brevity, not all of the processes are documented, though examples are provided in each of the process layers. Where a process and the accompanying use case are documented, they are represented in bold type in the diagrams.

The use cases are presented in outline format rather than fully elaborated use case specifications. For example, the flows are summarized rather than presented as detailed, step-by-step main and alternative scenarios. Business rules have not been defined.

The process models themselves are based on Business Process Modeling Notation (BPMN) version 1.1. The notation may deviate slightly from the discussion of process patterns in Part 2, which used BPMN version 1.0. This article also uses certain conventions to make the diagrams as clear and concise as possible. The example uses the same icons as in Part 2, as shown below.

Figure 1. Key to diagrams
Key to diagrams

Representing user interactions with BPMN 1.1

The BPMN notation has many subtleties. Though BPMN was not designed for modeling user interfaces, it does support various ways to represent user interactions. To make things more compact, the case study uses a notation that is not strictly in accordance with the BPMN standard. Figure 2 shows an example.

Figure 2. Screenflow notation
Screenflow notation

The notation, by a strict interpretation of the BPMN standard, means that multiple paths could be chosen in parallel, but this is not what we mean. We hope you'll make allowances for the alternative in Figure 2.


Customer experience layer

Figure 3 shows the customer experience process, which is the virtual layer. Of course, the customer experience is not easily modeled as an unambiguous process; it is meant to show the consumer processes within a context.

Figure 3. Customer experience process: Shop for Books
Customer experience process: Shop for Books

Use case model

Later sections of this article show the process decomposition beneath the customer experience process Shop For Books, and show system use case outlines for each process. The resulting use case model is shown in Figure 4 as a summary. In reality, this is an output from the modeling exercise rather than the starting point.

Figure 4. Home shopping use case model (end result)
Home shopping use case model (end result)

Process summary

In Figure 5 you see a "value chain" illustration of the end-to-end process showing the sequence in which the use cases are performed.

Figure 5. Home shopping process summary
Home shopping process summary

Consumer process layer

This section walks through the numbered use cases in the Consumer Process section at the top of Figure 4.

Use Case UC01: Select Product

Customers start in the online shop, where they browse books and may insert a book in their basket. This use case can be repeated for multiple books.

Goal
To select a product and add to the shopping basket.
Trigger
User selects to browse the product catalog.
Primary actor
Customer.
Pre-conditions
The customer is online.
Post-conditions
A product has been added to either a preexisting basket or a newly created one if no basket is available.

Or, in the case of a timeout, nothing will have happened.

Flow
Use Case UC01: Select Product
Use case description
The system presents the shop to the user with options to navigate by category or to do a search. The user may also select a product to view the product detail. The use case ends when the customer chooses to add a product to their shopping basket, or as a result of a timeout.

Use Case UC02: Checkout Online

The customer will need to checkout after finishing putting books in the basket.

Goal
To place an order for items currently in the shopping basket.
Trigger
User selects to proceed to checkout.
Primary actor
Customer.
Pre-conditions
One or more products must be in the customer’s shopping basket.
Post-conditions
An order has been placed for the items in the basket.

Or, an order has not been placed where: the user cannot log on, their delivery or payment details could not be captured successfully, the user cancelled, or the session timed out.

Flow
Use Case UC02: Checkout Online
Use case description
This use case lets the user place an order for the items in their shopping basket. The system first ensures that the user is logged in, then captures their delivery address and payment details. The system shows an order summary for the user to confirm. Once the order is confirmed, the short-running process Place Order is invoked. Upon successful completion of Place Order, a final confirmation is displayed to the user.
Includes
UC04 Capture Address Online, UC05 Capture Payment Details Online, UC10 Place Order, UC12 Login

Use Case UC03: Place B2B Order

Books ‘R Us also supports an ordering channel for its business partners using a B2B interface. Both this channel and the online channel use the same Place Order use case.

Goal
To place one or more orders through a B2B interface.
Trigger
A third party business partner submits a batch of one or more orders.
Primary actor
Third party retail system.
Pre-conditions
None.
Post-conditions
Zero or more orders have been placed. A batch of responses has been returned to the third party system.
Flow
Use Case UC03: Place B2B Order
Use case description
This use case lets a third party retailer submit orders to the bookshop through a B2B interface. The orders are extracted from the batch and processed in turn by the Place Order short-running process. The responses are merged and returned to the third party system.
Includes
UC10 Place Order

Long-running process layer

This section walks through the use case in the Long Running section of Figure 4.

Use Case UC06: Fulfill Order

When a new order is placed (by the Place Order use case), the order fulfillment process is started. This is a long-running process.

Goal
To dispatch products to a customer in response to a placed order.
Trigger
A new order has been placed.
Primary actor
N/A
Pre-conditions
A new, valid order must have been placed.
Post-conditions
The order items have recorded as dispatched. Customer payment was collected. A dispatch confirmation notice was sent to the customer.

Or, one or more items ordered are unavailable, or payment cannot be taken. If either remain unresolved, the customer receives confirmation of order cancellation.

Or, the order is modified to deal with unavailable items and fulfilled per the other post-conditions.

Flow
Use Case UC06: Fulfill Order
Use case description
This use case represents a long-running process that orchestrates the activities to fulfill an order that has been placed. If the order items are in stock, a Human Activity is invoked to route the order to the warehouse for the appropriate items to be picked and dispatched, and for payment to be collected. A confirmation is then sent to the customer and the order status is updated to record that it has been successfully fulfilled.

If the order items are not in stock but are expected, the process waits for stock to be replenished.

If the order items are not in stock and are not expected, another Human Activity is invoked to resolve the unavailable items. This may involve contacting the customer for an order modification.

If there are problems with taking the payment details, another Human Activity is invoked to resolve the payment issues.

If either of the human activities do not result in successful resolution, a confirmation is still sent to the customer, but this time the content of the confirmation will be different. For example, it will inform the customer of an order cancellation.

Includes
UC009 Pick, Dispatch, Take Payment, UC011 Resolve Items Unavailable, UC012 Resolve Payment Issues

Human activities layer

This section explores the use cases in the Human Activity layer in Figure 4.

Use Case UC07: Pick, Dispatch, Take Payment

The main aspects of fulfilling an order are picking items from a store house, taking payment, and dispatching the goods. These are often done by a single person so are grouped into a single human activity in the process model.

Goal
Take order payment and dispatch order items to the customer.
Trigger
An order has been assigned to the user, who selects it from the worklist.
Primary actor
Order picker.
Pre-conditions
The ID of a valid, new order is passed into the process.
Post-conditions
Payment has been taken and order items have been dispatched.

Or, the order has been parked (with reason provided in the result passed back to the calling long-running process).

Flow
Use Case UC07: Pick, Dispatch, Take Payment
Use case description
This use case represents a Human Activity performed by a warehouse worker who picks orders. The user records each item as picked as the products are found in the warehouse. Once all items have been picked, the customer's payment is processed and the system displays the shipping details to enable the order picker to dispatch the items. The use case ends once dispatch is confirmed.

If items are unavailable, or the payment is unsuccessful, the order can be parked and the use case ends in failure.

Use Case UC08: Resolve Items Unavailable

The Fulfil Order long-running process also has human activities for solving problems with orders. One of these is the unavailability of items in the storehouse.

Goal
To resolve issues of stock availability.
Trigger
The user selects an order from the worklist.
Primary actor
Order fixer.
Pre-conditions
An order must have been identified for which one or more items are unavailable.
Post-conditions
The order has been modified and the issue recorded as resolved.

Or, the order has been cancelled.

Flow
Use Case UC08: Resolve Items Unavailable
Use case description
This use case represents a Human Activity performed by a customer service representative who resolves issues of stock availability. The user can browse and search the intranet shop for alternative products (perhaps while in contact with the customer), and can modify the order to replace or remove the unavailable items. The use case ends once the user confirms that the unavailable items have been resolved.

Or, the user may select to cancel the order.


Short-running process layer

This section walks through a use case in the Short Running area at the bottom of Figure 4.

Use Case UC10: Place Order

Placing an order is a central use case in our scenario. This short-running process follows the Execute Transaction pattern described in Part 2 of this series.

Goal
To validate and store a submitted order.
Trigger
An order is submitted.
Primary Actor
N/A
Pre-conditions
An order for one or more products must have been submitted.
Post-conditions
A valid new order has been stored.
Flow
Use Case UC10: Place Order
Use case description
This use case represents a short-running process that validates the details of a submitted order and stores the new order ready for onward processing. Validations performed include the product details, address, and payment details.

Should any of the validations fail, an error message is returned to the caller. If the validation is successful, the order is created and the order details returned to the caller. The new order event triggers subsequent processing.


Service model

You can directly derive the service model from the process and use case decompositions above. All processes beneath the consumer process layer are exposed through services. And, the Place B2B Order consumer process is exposed as a service to third party retail systems.

Services in the automated activities layer are identified from the detailed steps within the processes in the higher layers. It is assumed that Human Activities are invoked by means of a service call. The resulting service model is shown in Figure 6.

Figure 6. Service model for Home Shopping scenario
Service model for Home Shopping scenario

Conclusion

In this series you learned about a process-driven technique for defining the shape of a service-oriented solution. We covered process-oriented modeling, from process maps to use cases and services. The examples in the article outlined the beneficial results.

Business alignment

This technique yields models that should be easily understood by business stakeholders, which has been confirmed by the authors' practical experience with the technique. Each process represents concepts that should be clear to non-technical stakeholders. For example, consumer processes represent an organization's channels, short-running processes represent the transactions it supports, and long-running processes represent workflow. All of these may be supported by services in the form of automated activities. The technique leads to concise (yet complete) process maps that avoid the myriad of spaghetti-like connections across multiple pages.

Facilitate re-use

The service model in Figure 6 demonstrates reuse, where multiple invocation arrows arrive at the same service. For example:

  • The Place Order service is being reused by two channels (online and B2B).
  • Various Automated Activity services are reused by multiple processes, such as Get Order Details.

The example is incomplete, but you can expect there to be many more opportunities for reuse. For example, if you completed the Modify Order transaction you'd expect to reuse some of the same validation services as those used by Create Order.

Enhanced traceability

In the IT industry, demonstrating that a solution does what it was required to do is problematic. This problem is typically solved in one of two ways:

  • Architects often design a solution that is closely aligned to the structure of the requirements, which in many cases takes the shape of a use case model. The structure is often devised by business analysts whose primary concern is satisfying their business clients. They are not concerned with the IT architecture, which can lead to poor, inflexible, and arbitrary architectures.
  • To avoid the situation above, architects design separate solutions, and maintain elaborate and expensive traceability matrices to somehow demonstrate that each requirement is being met. The traceability artifacts are often so big, complex, and unmanageable that they hide the questions they're meant to answer, such as “If I test this part of the system, which requirements will I have tested?” or "Are all requirements met?"

Traceability becomes much easier if what is required is expressed in the context of the architecture that will be adopted for the solution. Traceability is greatly enhanced on SOA projects if architects and business analysts work closely together, and they are using the process-oriented modeling technique described (in combination with existing systems analysis).

Resources

Learn

  • Check out the other parts of this series:
    • Part 1 explores the process decomposition technique for SOA that this article is based on.
    • Part 2 provides process modeling examples by means of business process patterns.
    • Part 3 explains how this technique can be extended to use case modeling.
  • The process models in this article aim to adhere to the latest specification of the BPMN standard (Business Process Modeling Notation 1.1).
  • The consultants and architects at IBM Global Business Services have extensive experience in applying techniques like this.
  • Use Case Modeling provides an excellent introduction to use case modeling.
  • "Service-oriented modeling and architecture" (developerWorks, Nov 2004) discusses the highlights of service-oriented modeling and architecture.

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=378100
ArticleTitle=Process-oriented modeling for SOA, Part 4: Tying it all together with a case study
publish-date=03242009