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.
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
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
includeslink (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
extendslink 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
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.
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
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
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
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
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
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
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
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.
The authors thank Richard Solly, Pete Cripps, Bruce Anderson, and Sunny Shah for their constructive feedback on early versions of this article.
- Check out the other parts of this series:
- 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
- Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.