Level: Introductory Arthur V. English, Senior Learning and Development Consultant, Unisys Corporation
15 Apr 2007 from The Rational Edge: Learn about the differerences and similarities between business use cases and system use cases, including what UML diagrams should be used to model these use cases via IBM Rational Software Architect or other modeling tools.
| New forum for Rational Edge readers |
|---|
| At the end of this article, you'll find a link to a new forum created specially for readers of The Rational Edge ezine. Get ready to add your thoughts about this article or other topics you've found in our pages. |
 Most software architects recognize business modeling as an important activity in developing software solutions. Successful solutions support the business; they solve business problems and satisfy business goals.
After developing a sound business model, business-process analysts can explore different business improvement options, such as eliminating redundant tasks, and automating repetitive and mundane tasks or those prone to errors. The IBM® Rational Unified Process®, or RUP®, and the Unisys 3D Visual Enterprise, or 3D-VE, provide a systematic approach to visually representing a business model using the Unified Modeling Language (UML), as well as deriving a starting-point system use-case model that is consistent and traceable back to the business model.
This article provides an overview of the RUP business modeling process and addresses the following questions:
- How is the business use-case-model similar to the system use-case model?
- How is the business use-case model different from the system use-case model?
- Which UML diagrams should I use for business modeling?
- What is the relationship between the business use-case model and the system use-case model?
Background
But before I address those questions, I would like to explain why I picked this particular topic to write about. I have been working with system use cases as a software architect since the early 1990s. I did not get introduced to business use cases until 2002, when I was the chief architect for the Integrated Justice Information Sharing (IJIS) framework solution developed by Unisys Global Public Sector. IJIS has now evolved into the Unisys Information Sharing Management Framework (ISM).
ISM is a set of reusable components that support universal business processes of information sharing. The ISM Framework integrates diverse types of justice and public safety systems using Service Oriented Architecture (SOA) technology to share critical data, documents, and images at key decision points. The ISM solution will offer the Justice and Public Safety community a business framework, technology framework, foundation application software and methodology that allows government agencies to continue to use their legacy systems.
ISM was designed using RUP, and the ISM business model was one of the first artifacts developed for the ISM project. Developing the ISM business model was a meaningful learning experience for me: One of the first things I learned is that there is a lot of confusion about how to develop a business model, and the literature that provides guidance for developing a UML business model is relatively sparse and somewhat inconsistent.
Since I left Unisys Global Public Sector to join Unisys University as a Learning and Development Consultant, I have been responsible for developing and delivering software architecture and IBM Rational tools training. One of my responsibilities is teaching the IBM Rational course "Mastering Requirements Management with Use Cases" (MRMUC). The primary focus of this course is developing system use cases, but the course only offers a limited discussion of what a business model is and how it relates to the system use-case model. One of the goals of this article, therefore, is to provide supplemental material for the MRMUC course.
This article assumes that you have a basic knowledge of system use-case modeling and the RUP requirements discipline. If you are not familiar with system use-case modeling, I suggest you study the RUP requirements discipline.
As noted earlier, the literature on business modeling is sparse, but here are a few references that I have found particularly useful, above and beyond the information you will find in RUP:
- Writing Effective Use Cases, by Alistair Cockburn. This is my favorite book on writing both business and system use-case specifications. Alistair stresses that the most important part of a business or system use-case model is the use-case specification. This book focuses on use-case specifications, not UML.
- UML for the IT Business Analyst, by Howard Podeswa. This book focuses on using UML for developing a business model and complements Alistair's book. UML for the IT Business Analyst helped round out my education in how to develop an effective business use-case model.
- The Rational Edge article "Effective Business Modeling with UML: Describing Business Use Cases and Realizations," by Pan-Wei Ng. That article has some similarity to this article. That article is written from a UML 1.x viewpoint. This article is written from a UML 2.0 viewpoint and provides more depth to the relationship between the business use-case model, business analysis model, and system use-case model.
Now that I have completed the preliminaries, let's start answering some questions.
How is the business use-case model similar to the system use-case model?
A business use-case model is very similar to a system use-case model in many ways. Both models have use-case specifications. If you examine the RUP templates for business use-case specifications and system use-case specifications, you will find the format to be very similar. Both contain Preconditions, Postconditions, Extension Points, and Special Requirements. A business use-case specification has basic workflow and alternative workflow instead of basic Flow of Events and Alternative Flows.
The format of a business and system use-case specification is very similar but diverges because of design scope. The design scope of a business use case is business operations. It is about a business actor outside the organization achieving a business goal with respect to the business organization. Let's look at the RUP definition of a business use case:
"A Business Use Case describes a business process from an external, value-added point of view. Business Use Cases are business processes that cut across organization boundaries, possibly including partners and suppliers, in order to provide value to a stakeholder of the business."
While concise, this definition identifies some important points, such as:
- A business use case describes business processes -- not software system processes.
- A business use case provides value to stakeholders. Stakeholders may be either business actors or business workers.
- A business use case can cut across organizational boundaries. Some architects take this point too literally. Many business use cases do cut across organizational boundaries, but some business use cases focus on only one organization. I will give you some examples a little later in this article.
Let's also consider the business use case definition in Podeswa's book UML for the IT Business Analyst:
"Business Use Case: A business process, representing a specific workflow in the business; an interaction that a stakeholder has with the business that achieves a business goal. It may involve both manual and automated processes and may take place over an extended period of time."
This definition addresses the idea of providing value by achieving a business goal. It expands on the RUP definition by describing a business process as a specific workflow that may involve both manual and automated processes. This definition also points out that the workflow may take place over an extended period of time. All of these are very important points.
So what about system use cases? The design scope of a system use case is the computer system to be designed. It is about a system actor achieving a goal with the computer system. A system use case is how actors communicate with computer technology, not business processes.
Cockburn's Writing Effective Use Cases uses the same use-case specification template for both business and system use cases. The difference between a business use case and system use-case specification using this template is the design scope, not the template. Cockburn likes to categorize use cases by goal level, as shown in Table 1.
Table 1: Alistair Cockburn's categories for both business and system use cases | Very High Summary |  | Summary |  | User Goal |  | Subfunction |  | Too Low |
Cockburn's primary focus in Writing Effective Use Cases is system use cases, but he also pays a lot of attention to business use cases. Instead of using different template types to differentiate between business and system use cases, Cockburn uses goal levels. So what do these icons and goal levels mean?
The icons themselves represent a simple system, based on how high or low the use cases are in relation to "sea level" -- the actual level of the user. The sweet spot for system use cases is the User Goal, indicated by the Sea Level icon. Sometimes it is necessary to decompose complex system use cases into other use cases that have Subfunction goals, designated by the Fish icon. But you should always avoid decomposing Sea Level system use cases into Clam or Too Low system use cases.
As you might guess, the Summary or Kite use cases would be business use cases. The Cloud or Very High Summary goal use cases may also be business use cases.
Cockburn's approach is to look at use cases as a spectrum, from the highest-level business goals of an organization to the requirement details of implementing a software solution that satisfies these business goals. This approach views system use cases as a decomposition of business use cases. This use-case decomposition approach can be used to help you derive a system use-case model from the business model, as I will discuss later.
So what else is similar between the business use-case model and the system use-case model diagrams?
- Both have actors. In a business use case diagram, you stereotype an actor as a <<BusinessActor>>.
- Both have use cases. In a business use-case model, you stereotype a use case as a <<BusinessUseCase>>.
- Both have a communicates-association between actors and use cases.
- Business use cases, as well as system use cases, can have include, extend, and generalization associations.
The communicates-association in a use case diagram is usually a point of confusion for people learning use-case modeling. Should I use an arrow? In which direction should the arrow go? A communicates-association has been represented since the 1.4 UML specification as a solid line. The line can be adorned with an arrowhead. The line and arrow represent a two-way dialog between the actor and the system. If an arrowhead is present, then only the "thing" at the tail of the association can initiate communication. No arrowhead means that either end can initiate communication (not that both ends initiate communication).
The UML 2.0 spec makes this simpler. UML 2.0 does not allow the capability to have a navigable association between an actor and a use case or a business actor and a business use case. I personally like the arrow, but if you use IBM Rational Software Architect (RSA) as your UML modeling tool, you cannot draw an arrow between an actor and a use case. There is nothing wrong with RSA. UML 2.0 is the reason the communicates-association is not navigable.
Now that I have discussed the similarities between the business use-case model and system use-case model, let's look at the differences.
How is the business use-case model different from the system use-case model?
There are three important differences between a business use-case model and a system use-case model: design scope, white-box versus black-box, and business workers.
Scope
In the previous section, I discussed design scope via Alistair Cockburn's designations of above, below, or just at "sea level."
Business use cases focus on business operations. They represent specific workflows in the business that achieve business goals. Business processes may involve both manual and automated processes and may take place over an extended period of time.
System use cases focus on the software system to be designed. How do actors interact with the software system? The flow of events that we write in a system use-case specification should be sufficiently detailed to be used as the starting point for writing system test scripts.
White-box versus black-box
Business use cases are often written in a white-box form. They describe the interactions between people and departments in the organization being modeled. We use business use cases to describe how the organization works today in the "as is" business model. We then refactor the "as is" business use-case model to look toward the future design of the organization being modeled. What new roles and departments do we need to create to provide more value or eliminate business problems? What roles and departments need to disappear?
System use cases are almost always written in a black-box form. They describe how actors external to the software system interact with the system being designed. System use cases elaborate the system requirements. The purpose of the system use-case model is to document requirements from a stakeholder's perspective, not to design how to satisfy the requirements.
Business workers
So what about business workers? In a system use-case diagram, you only have actors interacting with use cases. But in a business use-case diagram, you can have both business actors and business workers interacting with business use cases.
A business actor is someone external to the business. It can be a role or another organizational entity. For example, in a criminal justice system, a business actor would be the witness, the subject under suspicion, an external government agency such as Health and Human Services, or a business entity such as a credit bureau.
A business worker is someone or some department that is internal to the business. In a criminal justice system, a business worker would be a law enforcement officer, judge, prosecuting attorney, or parole officer. When you realize a business use case and create Sequence and/or Communication diagrams to show how business actors, business workers, and business entities collaborate to execute the business use case, you will carry over the business workers from the business use-case model to the business analysis model, as well as add additional business workers that are required to provide the business use-case functionality. Figure 1 shows a sample business use case diagram based on the ISM project.
Figure 1: ISM business use-case diagram
Click to enlarge
Figure 1 shows one business actor: the Suspect. There are three business workers: Law Enforcement, Prosecutor, and Court. There are four business use cases: Arrest Subject, Request Warrant, Capture Fingerprints and Mugshot, and Release on Bail. Capture Fingerprints and Mugshot is always included as a mandatory behavior from the Arrest Subject base business use case. Release on Bail is optional behavior that extends the Arrest Subject business use case.
Earlier, I discussed how a business use case can cut across organization boundaries, and many do. The Request Warrant is a good example. It involves Law Enforcement and the Court. Business use cases can also focus on only one organization. Capture Fingerprints and Mugshot is a good example of this.
Which UML diagrams should I use for business modeling?
Before I discuss the UML diagrams you use in business modeling, I would like to mention a few tips about using RSA and UML 2.0 to create business use case diagrams:
- In UML 1.x, you could stereotype an actor as a business worker. In UML 2.0, you must create a class and then stereotype it as a business worker. In UML 2.0, you can stereotype an actor as a business actor, but you cannot stereotype an actor as a business worker.
- In UML 2.0, the association between a business use case and a business worker is navigable. The association between a business actor and a business use case is not navigable.
- As a best practice, I recommend turning off navigation between business use cases and business workers to keep business workers consistent with business actors. Business workers and their use case association should be drawn in the same way business actors communicate with business use cases.
- You must select the Profiles tab in the Properties window for your project and then click on the Add Profile button to add business modeling and robustness analysis stereotypes to the project. In IBM Rational Rose, this was automatically included. In UML 2.0, profiles are used to package stereotype and tagged value UML extensions. The UML 2.0 specification requires that you add a profile to your UML modeling project to use business modeling stereotypes.
The UML business model consists of two models: the business use-case model in the Use-Case View and the business analysis model in the Logical View.1 The main diagram in the business use-case model is the business use case diagram. Optionally, you can also include a UML Activity diagram for individual business use cases to graphically show workflow processes, as shown in Figure 2, the Activity diagram for the Arrest Subject business use case.
Figure 2: ISM Arrest Subject business use-case Activity diagram
Click to enlarge
The business analysis model describes the realization of business use cases by interacting business workers and business entities. It serves as an abstraction of how business workers and business entities need to be related and how they need to collaborate in order to perform the business use cases. There are three types of UML diagrams in the business analysis model, as shown in Figure 3: Class, Sequence, and Communications diagrams.
Figure 3: Business analysis model diagrams
The primary diagram in the business analysis model is the Sequence diagram. You manually create Sequence diagrams that show how business actors, business workers, and business entities interact to perform a business use case. A Sequence diagram shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged.
Formerly named a Collaboration diagram in UML 1.x, a Communication diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction by their links to each other and the messages they send to each other. Communication diagrams and Sequence diagrams both show interactions, but they emphasize different aspects. Sequence diagrams show time sequences clearly but do not show object relationships explicitly. Communication diagrams show object relationships clearly, but time sequences must be obtained from sequence numbers.
Both diagrams show the same behavior, but in different ways. I personally prefer the Sequence diagram because it is usually easier to read and follow. You can also use the View of Participating Classes (VOPC) to show a static view of the business actors, business workers, and business entities that collaborate to perform a business use case.
Figure 4 shows the Sequence diagram for the ISM Arrest Subject business use-case realization. Figure 5 shows the VOPC for the ISM Arrest Subject business use case realization. Figure 6 shows the Communication diagram for the ISM Arrest Subject business use case realization.
Figure 4: ISM Arrest Subject business use-case realization Sequence diagram
Click to enlarge
In this part of the ISM Arrest Subject business Sequence diagram, shown in Figure 4, there are three business workers that have been carried over from the business use-case model: Law Enforcement, Subscriber, and Criminal Justice System. Criminal Justice System is a generalization of Law Enforcement, Court, Prosecutor, etc. To keep the Sequence diagram simple, we used this generalization to represent any criminal justice system that ISM could work with.
Figure 4 also shows two new business workers introduced into the business analysis model: the Records Management System (RMS) and the ISM Broker. The RMS is usually a commercial off-the-shelf (COTS) solution that local law enforcement uses as a criminal case management system. The ISM Broker is an automation candidate or proxy for the software solution that Unisys is planning to develop.
The Unisys ISM solution integrates multiple diverse justice systems using a hub-and-spoke SOA technology to share mission-critical data, documents, images, and transactions at key decision points. ISM can be implemented on either Microsoft BizTalk Server or IBM WebSphere Business Integration. The ISM Broker serves as the conduit for data sharing within the justice community and leverages current technology to push, pull, publish, and subscribe information to support day-to-day justice operations.
Figure 5: ISM Arrest Subject business use-case realization VOPC diagram
The VOPC diagram in Figure 5 shows a static view of the business actors, business workers, and business entities that participate in the Arrest Subject business use case. Notice the operation shown for each business worker. These operations are called business responsibilities. A more accurate name for the VOPC diagram is View of Participating Business Actors, Business Workers, and Business Entities. In this example, only business workers collaborate to perform the business use case.
Figure 6: ISM Arrest Subject business use-case realization Communication diagram
Click to enlarge
As I noted earlier, the Communication diagram (shown in Figure 6) is another way of observing the behavior shown in the Sequence diagram. RSA provides an automation capability to create a Communication diagram from a Sequence diagram or vice versa.
There is one more question to answer.
What is the relationship between the business use-case model and the system use-case model?
Figure 7, Business to System Use-Case Flow Down, comes from an IBM Rational course I teach, "Mastering Requirements Management with Use Cases."
Figure 7, Business to System Use Case Flow Down
Figure 7 illustrates one of the most difficult topics to teach in the course, because most of the groundwork you need to understand this figure is not covered in the standard course materials. One of the purposes of this article is to provide that additional groundwork.
Figure 7 shows a clear mapping between things found in a business model and the things in your system use-case model. In this particular example, it shows that a system can automate the responsibilities of a business worker. It also shows that key business workers are candidates for automation.
Remember, a business model consists of both the business use-case model and the business analysis model. The business analysis model is a realization of the business use-case model and has tight integration and traceability. The system use-case model traces to the business analysis model. The business analysis model traces to the business use-case model.
Using this approach, you can build a system use-case model that flows down from the business analysis model. This provides consistency and traceability to your overall UML model.
So where do the system actors and system use cases come from? System actors are created based on the business actors and business workers in the business analysis model. Business actors that interact with business worker automation candidates always become system actors. Business workers that interact with business worker automation candidates that are not automation candidates become system actors. For example, Law Enforcement and Court in the ISM business analysis model become system actors. The ISM Broker is a "pure" automation candidate. It will not become a system actor.
What do I mean by pure? Simply that the only purpose of the automation candidate is to be a proxy for the software solution we are developing. Notice the Loan Specialist in Figure 7. The Loan Specialist business worker transforms into both a system actor and a system use case. Allow me to explain.
The Loan Specialist is a role in the business model represented in Figure 7. In our system use-case model, there needs to be an actor that does the role of the Loan Specialist. But we are also automating some of the business responsibilities of the Loan Specialist in the new software solution we are developing. Those business responsibilities in the business analysis model become system use cases in the system use-case model.
Other pure business worker automation candidates will not be transformed into system actors in the system use-case model. This answers the question, "Where do the system use cases come from?" System use cases are created based on the business responsibilities of business worker automation candidates in the business analysis model. If you return to Figure 5, the VOPC diagram that shows the ISM Broker, each of the business responsibilities, such as Query for Information, can be transformed into a system use case in the system use-case model.
The analysis model shows how the business entities map to classes in the system analysis model. These classes represent the "data" that the system will work with.
Summary
My goal has been to provide an overview of RUP business modeling in comparison to system use-case modeling. I discussed the similarities and differences as well as the relationship between the business use-case model and the system use-case model. If you have any questions about these comparisons and relationships, I can be reached at
arthur.english@unisys.com
References
- Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley: 2001.
- Podeswa, Howard. UML for the IT Business Analyst. Thomson Course Technology: 2005.
- Eriksson, Hans-Erik and Magnus Penker. Business Modeling with UML: Business Patterns and Business Objects. Wiley: 1999.
- Ng, Pan-Wei. "Effective Business Modeling with UML: Describing Business Use Cases and Realizations." Rational Edge: 2002.
- Booch, Grady, Jacobson, Ivar, and Rumbaugh, James. The Unified Modeling Language Reference Manual, Second Edition. Addison-Wesley: 2005.
Notes
1 The Use-Case View and the Logical View are part of the UML 4+1 View Model Architecture. For further information about the 4+1 View Model Architecture, you should study the URUP Software Architecture Concept in the Analysis & Design Discipline.
Discuss this article now!
Dear Reader: A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
About the author  | | | Arthur V. English, an award-winning book author and software developer, is a Senior Learning and Development Consultant with Unisys Corporation. Arthur has achieved Rational Unified Process (RUP), Rational Object Oriented Analysis and Design (OOAD), Microsoft Certified Solution Developer (MCSD), Microsoft Certified Systems Engineer (MCSE), and Justice Information Exchange Model (JIEM) certifications. |
Rate this page
| 
