Process-oriented modeling for SOA, Part 3: Use case modeling

How to define use cases that align with SOA

Learn how business analysts and architects can specify use cases that are in alignment with Service-Oriented Architecture. This article describes a use case modeling technique based on the process modeling technique described in Part 1. 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.



10 March 2009

Also available in Chinese Vietnamese Spanish

Introduction

In Parts 1 and 2 of this series you learned a method for specifying process models that are closely aligned to a Service-Oriented Architecture (SOA) based target architecture. These models show better fidelity to the actual solution being implemented. This article extends the principle to the definition of use case models.

Part 4 will use an example case study to illustrate the concepts in the first three parts.

Learn about a use case decomposition technique based on the process model, making the use cases similarly aligned to the target architecture.

Why we need SOA aligned use case models

Use case modeling is used in IT projects to capture the functional requirements of a system. Use case models are based on constructs that support re-use, which should translate nicely to an architecture such as SOA that promotes re-use. Unfortunately, most use case modeling techniques used today are based on concepts that pre-date SOA and business process management (BPM), with the following consequences:

  • Use cases are often too literally translated into technical artifacts (such as flows and services), which leads to poorly designed systems that don't deliver the benefits of SOA.
  • Out of necessity, designs often involve a re-factoring of the structure initially defined in the use case model, yielding systems that implement functions that cannot easily be traced back to the requirements. The lifetime and usefulness of the original use cases are reduced. Client expectation management, efficiency of the IT delivery process, end-to-end traceability, testing, and future re-use are also problematic.

A closer alignment of the functional models to the architecture has many benefits. It facilitates communication between business stakeholders and technologists, speeds project delivery, and significantly increases the potential for re-use. Re-use in the requirements space can correspond directly to re-use in the architecture.

Use case models you develop with the technique described in this article can remain valid and useful beyond delivery. They will correspond to real system artifacts being delivered, such as services, processes, or user interface components. The use case models can be used as reference for new projects seeking re-use beyond the lifetime of a single delivery project. Often, the resulting use cases are analogous to services, so specification of the use cases is the first step in the specification of services.

SOA aligned use case modeling

Figure 1 shows the process decomposition structure proposed in Part 1. Each process belongs to one of the layers. Processes can only call or subscribe to events from sub-processes in downstream layers, as indicated by the arrows. Each process should be agnostic of the processes in the upstream layers.

Figure 1. Process decomposition framework
Process decomposition framework

"Includes" and "Extends" relationships

There is a lot of confusion around the difference between the Includes and Extends relationships in a use case model, what they mean and how they should be used. The key difference between them is about where awareness of the relationship resides, and it is this difference that dictates which is the more appropriate to use in a given situation.

Includes

Where Use Case A includes Use Case B, it is A that "knows about" B. Use Case B has no knowledge of which use cases it is being included by. Within the flow of Use Case A, Use Case B is performed in its entirety before Use Case A continues (although we shall slightly modify this in the case of "fire-and-forget" invocations). Use Case A must then deal appropriately with the output and post-conditions of Use Case B (whether it succeeded or failed). The Includes relationship should be used to avoid repeating the same content in multiple use cases - in other words to extract common functionality and enable it to be re-used.

Extends

Where Use Case B extends Use Case A, it is now B that "knows about" A. Use Case A has no knowledge of any use cases that extends it. However, Use Case A must define one or more "extension points" within its flow. The extending use case B effectively "listens" to use case A and is invoked at a particular extension point. In contrast to the Includes relationship, Use Case A now continues without waiting for Use Case B to complete (since it is not aware of its invocation), and similarly does not deal with any success or failure post-conditions. It is far less common to use (or to need) the Extend relationship, but it can be very helpful when defining new functionality to be added to an existing system, or more importantly in the context of this approach, to define event driven processing.

Consumer processes, and all processes in the layers below, are implemented in the technology solution. The manual or "customer experience" process layer is a virtual layer that shows all of the non-automated activity in the business; it illustrates how the system-supported processes fit into this context.

You can now use the process decomposition structure to drive how requirements are specified. Each process in the model is specified in further detail in the form of a use case -- the resulting use case structure mirrors the process decomposition structure.

  • Each process will correspond to a system use case (except manual and customer experience processes that lie outside the system boundary).
  • The invocation of a sub-process is equivalent to a use case includes link (see sidebar), enabling the sub-process to be defined in a separate use case that can be re-used by other processes in the layers above.
  • The use case extends link may be appropriate to support event-driven architecture concepts.

    For example, a short-running process generates an event that results in launching a long-running process. The long-running process extends the short-running process, and the short-running process remains unaware of the long-running process (see Event Based SOA in Part 1).

  • Automated activities equate to steps within the use cases in the higher layers, though there may be exceptions to this (described later).

Applying these principles results in a use case structure that is also layered, in the same way as the process model, as shown in Figure 2.

Figure 2. Layered use case model
Layered use case model

Each use case defines a corresponding process in more detail. It also defines the characteristics of the service that will be used to invoke that process. For example, the pre- and post-conditions, inputs, and outputs of the use case define the service dependencies, boundary, and data requirements.

Manual processes and customer experience processes

The "Manual processes and customer-experience processes" layer, at the top of Figure 1, is for setting the context for processes in the lower layers. It is to show how the system processes fit into the overall business process. The processes in this layer lie outside the system boundary, and don't describe system functions, so there's no need for a corresponding system use case.

Process summary

In addition to the Manual and customer-experience processes and the use case model, another useful communication tool is a summary of the end-to-end process to show the overall use case sequence. The summary is helpful because:

  • The use case model is static; it doesn't show the sequence in which the use cases are performed. In simpler models the sequence can often be inferred, but this might not be the case in more complex models.
  • The customer experience process obeys the layering principle and therefore does not show any processes beneath the consumer layer. Its value is in showing what the external consumer "sees," but it doesn't serve as a summary for stakeholders who need to review the model as a whole.

The notation chosen for the summary can vary, though you should be careful about using BPMN as that may imply precision that is not there. For example, a value chain style notation could be used.

Consumer process use cases

Consumer processes (see Figure 1) translate comfortably into the traditional view of a use case because they're focused on interactions between actors (end users or external systems) and the system. These use cases include reusable business processes (long or short running) in the layers below.

Long and short running process use cases

Process orchestration versus chaining

A common mistake in use case modeling is to define relationships between use cases to describe the sequence in which they are performed. For example, you must log on to the system before submitting an order. The dependencies between use cases should be described in the use case pre- and post-conditions, rather than modeled as a relationship (Logon should not include Submit Order). Linking use cases together to describe the business process is sometimes called chaining. It does not reflect the actual system behavior, leads to use case models that are hard to understand and maintain, and disguises areas where the system is truly orchestrating process.

Where the system actively manages the dependencies between use cases by invoking them in sequence (for example, in a workflow process), this can and should be modeled as one use case including other use cases in a specified sequence. The system is acting as the overall process controller rather than the end user.

Part 1 explained that long and short running processes are executed in the business process layer of the architecture, potentially by a business process orchestration engine. For both long and short running process use cases, there is no Primary Actor; they are always triggered by other use cases and don't directly involve any user interaction. All steps will describe system processing, or inclusion of other use cases (for example, a long-running process use case may include a human activity use case).

Short-running process use cases can also be extended by a long-running process use case as a result of an event that they generate. You should clearly note, in the process diagram and use case flow, where a process is invoked in fire-and-forget mode, since an includes relationship traditionally implies that the included use case must be completed before continuing.

A use case being equivalent to a long-running process is counter to the traditional rules of use case identification (one actor, one place, one time). You can think of a long-running process as a workflow process; it may wait for an external event to happen, or call upon one or more people to perform a task. However, the information needed to specify a long-running process is the same as that required in other use case specifications. By representing the long-running process as a use case, the use case model clearly represents the other activities being orchestrated by the long-running process (see sidebar).

A long-running process triggered by an event is described with the extends relationship. In addition to initiating the start of a long running process, an event may also prompt a long running process that is waiting to continue. It is proposed that the extends relationship should also be used to represent this continuation link. In this way, all event based dependencies are represented in the use case model. Figure 3 shows examples of the different uses of the extends relationship.

Figure 3. Uses of the extends relationship
Examples of the different uses of the extends relationship

This is a slight modification to the traditional meaning of the extends relationship, which is necessary because long-running processes break the usual "one actor, one place, one time" rule. Perhaps a more meaningful term in this instance would be is informed by or waits for, but let's stop short of proposing a new stereotype for this purpose.

Human activity use cases

As with consumer processes, human activity use cases describe interactions between a user and the system. A human activity, sometimes called a workflow activity, is initiated by a long-running process and might typically begin with the user selecting the activity from a worklist. Once the user has completed the activity, all subsequent business processing should be handled by the long running process. The scope of the human activity should be limited to the user interaction. The outputs of the human activity use case (successful or otherwise) must be detected and handled by the long-running process use case that included it.

Automated activity use cases

Business rules
Business rules, defined in conjunction with use cases, provide a powerful mechanism for defining reusable business logic across the use case model. Business rules represent system logic, typically to perform one of the following:

  • Derivation of data (such as calculation of a fee)
  • Automated decision making (checking eligibility or validating a transaction)

Business rules are best documented separately from the use cases (to enable re-use), with each rule cross-referenced from the use case steps that use it.

With this approach, business rules equate to automated activities in the process model.

In general, automated activities correspond to the steps in the use case flows (main scenario and alternative flows). Automated activities may correspond to business rules, referenced in the use cases, that can be re-used or data operations. Such automated activities are often too fine grained to warrant a use case of their own.

In some cases, however, it may be useful to define an automated activity as a separate use case in its own right. For example, an interface to an external system that involves complex interaction may require several steps or alternative flows to be defined. These should be documented as a separate use case to facilitate re-use of the interface.

From process and use case models to service models

As you learned in Part 1, long running processes, short running processes, and automated activities are all invoked by a service. Consumer processes generally are not (they consume services), except where the process is exposed to an external consumer, such as a business partner using a Business-to-Business (B2B) interface.

If you apply the use case modeling technique described in this article, use cases (except Consumer use cases) will correspond to services in the same way. Conveniently, use case specifications share many characteristics with service specifications; the use case specifications can be seen as an early version of the service specification. Both have:

  • A unique name
  • A goal or purpose
  • Inputs and outputs
  • Pre- and post-conditions
  • An associated process flow
  • Dependencies on other use cases or services

Concluding thoughts

Processes, services, and service operations

The terms "process" and "service" are often used interchangeably: both satisfy a particular objective, and have clearly defined inputs and outputs. There are however clear differences in definition:

  • A service defines what is being provided, while hiding the how. It focuses on the objective, and represents the interface instead of the implementation.
  • A (business) process defines the steps and flow that are needed to provide the corresponding service. A process model can be used to define how a service is being provided. The individual steps within a process can in turn invoke other (lower layer) services.

SOA literature often mentions the term "service operation". Strictly speaking, when adhering to the Web services standard WSDL, a service is a grouping of service operations. In our article we have not applied this strict definition: whenever we mention the word service, this could be interchanged with service operations. However, this means that an additional step that identifies the decomposition of services into service operations is still required.

In this article you learned how the process decomposition technique in parts 1 and 2 of this series can be extended to use cases. The identification of the use cases is driven by process models that are in alignment to an SOA. The requirements, as articulated in the use cases, are brought much closer to implementation in the form of services in an SOA.

Business analysis and IT architecture

SOA-aligned, process-driven use case modeling, if done well, results in better fidelity of a requirements specification to the real solution. Because of the close link, it is best performed by a business analyst and an architect together, or by people with strong skills in both areas. We predict that the application of techniques like those in this series will lead to a blurring of boundaries between business analyst and architect roles. Individuals with both skills will be in increasing demand.

Top-down and bottom-up

The approach to use case modeling can be considered a top-down approach for SOA design, where service operations are identified based on where they are needed. Within the context of IBM's method for Service-Oriented Modeling and Architecture (SOMA), this would be part of the Domain Decomposition step.

Whether the business analyst or architect makes the right choice of services depends on other factors, such as what services are already supported by an organization's existing systems. In a mature SOA environment, information about the services is available in a service repository and can be "included" in functional requirement models. In less mature environments, an existing systems analysis is needed to fully understand what is already available. In SOMA it would fall under Existing System Analysis.

Stay tuned for Part 4, which will use a case study to illustrate the techniques in the first three parts.


Acknowledgments

The authors thank Richard Solly, Pete Cripps, Bruce Anderson, and Sunny Shah for their constructive feedback on early versions of this article.

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.
  • Use Case Modeling provides an excellent introduction to use case modeling, and has valuable, practical advice on the use of includes and extends relationships in Chapter 10.
  • "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=374825
ArticleTitle=Process-oriented modeling for SOA, Part 3: Use case modeling
publish-date=03102009