Business Use Case Model

Bringing these elements (business actors and business use cases) together, we create the business use case model for your business.

Business Use Case Diagrams

We start with a business use case diagram, which provides the context in which your business operates. It depicts what is outside of your business (the business actors), what is inside the business (the business use cases), and the relationships between the two (see Figure 2-5). “A business use case diagram is a diagram of the intended functions of the business and is used as an essential input to identify roles and deliverables in the organization.” [LEFF1] It is a context diagram for your business.

The lines with arrowheads in business use case diagrams are associations between the business actor and the business use case. They indicate a relationship between the two model elements they connect. The direction of the arrow shows which element initiates the activity. In the example in Figure 2-5, the salesperson uses (i.e., initiates) the Process Sale business use case. An association can exist without an arrowhead. This represents a bi-directional communication path. (The <<include>> and <<extend>> notation will be discussed in Chapter 3, along with more about use cases in general.)

From the Real World—That's Not Right! I'm Calling the UML Police! We told you that we would be pragmatic in this book. The preceding discussion qualifies. Technically, having an arrowhead on the associations between actors and use cases is not permitted. However, when designing systems in the real world, this minor deviation has value. In moderate-sized systems that may have, for example, six use cases, you could easily have over a dozen actors. In large systems or in enterprise-level design (systems of systems), there can be many more. Using arrows enables you to immediately see which actors are active (initiating use cases) and which are passive (instead of initiating a use case, the use case may be providing something to that actor). Having an association between actors is also not allowed, but in the real world, actors do communicate directly with each other, particularly if they are people. This is important to depict so that you correctly represent how your business operates. Seeing the arrows between actors may cause you to decide that such an interaction should not occur, or maybe it should be automated—an important decision for your business and your system architecture. Now we do not recommend that you redefine the UML's semantics for every fleeting whim. (We have seen projects try that—and fail miserably.) Just keep in mind that a key purpose for using the UML is communication. That's what it's all about—getting your ideas across to others. Sometimes, small tweaks can add big value, even if they are not “by the book.”

Lessons Learned The goal of using the UML is to clearly express your designs, not to conform blindly to the UML specification. If being “creative” in your use of the UML achieves this goal, that's fine. Just be careful not to completely redefine the UML semantics or use its elements in ways that could be interpreted incorrectly by others. In other words, be very careful.

Now that you have established the business use cases, you need to define what they mean. Never assume that everyone knows or agrees on what these major business functions are or what they do. (Remember the “Real World—Three Years in Three Days” example earlier.) To make this knowledge explicit, you should write a short description of each business use case's function. The description should provide an overview: what the business use case is, what it does and why (i.e., its “mission”), when it is used, and any other important information specific to this business use case. This should be one or two paragraphs, just enough so that anyone could read that definition and understand the overall purpose of the business use case. For example, if the business use case is “account management,” the description might read:

Account management: This business use case provides services that enable the small business and retail customers, at a branch office, during normal business hours, to perform actions regarding savings and checking accounts. These would include opening, closing, transferring, changing registration of, and merging accounts. This use case does not include account inquiries, deposits, withdrawals, or online functions.

Once agreed to, this provides the context for developing the details of the business use case. This is done using activity diagrams.

Activity Diagrams

Now that you know the people, businesses, and systems you interact with and what services you provide to meet their needs, you need to understand how they interact to provide that service. What are the details behind each of the business use cases? For example, for the Process Sale business use case, how does a customer actually purchase a retail product? What are the steps taken and by whom? That transaction could take place like this:

1.	Customer enters store and chooses product(s).
2.	Customer presents product to salesperson.
3.	Salesperson scans product (repeat for all products).
4.	Salesperson provides total cost.
5.	Salesperson inquires as to payment method.
6.	Customer provides payment.
7.	Payment is accepted by salesperson.
8.	Receipt and product are given to customer.

Or it could be:

1.	Customer enters store and chooses product(s).
2.	Customer presents product to salesperson.
3.	Salesperson inquires as to payment method.
4.	If payment by credit card, customer provides card to salesperson (if not, go to step 6).
5.	Salesperson swipes card.
6.	Salesperson scans product (repeat for all products).
7.	Salesperson provides total cost.
8.	If payment by credit card, customer authorizes payment. (Otherwise, customer provides payment and payment is accepted by salesperson.)
9.	Receipt and product are given to customer.

Or even:

1.	Customer enters store and chooses product(s).
2.	Customer inserts credit or debit card into scanning station.
3.	Customer scans product (repeat for all products).
4.	Scanning station provides total cost.
5.	Customer authorizes payment.
6.	Payment is validated.
7.	Receipt is given to customer.

Although this sounds like a simple process flow, as you can see, there could be many different ways this transaction might take place. That is why it is critical to get agreement on the workflow. Real workflows are more complex than this example, with many decision points, alternate paths, and combinations of activities. That is why a visual model is important. An activity diagram can depict such flows in a way that is easy to follow and understand.

Let's revisit the first variant of this transaction, as described previously, using an activity diagram. Activity diagrams show the interactions between the business actors and your business. Let's begin at the beginning:

1.	Customer enters store and chooses product(s).
2.	Customer presents product to salesperson.
3.	Salesperson scans product (repeat for all products).

This gives us the beginnings of the activity diagram for the Process Sale business use case (see Figure 2-6).

Here, you see that the two business actors' names (Retail Customer, Salesperson) are shown at the top of the columns in the diagram. These columns are called swimlanes. (Note that in UML 2.0, these are referred to as partitions.) Any activity (shown in the ovals—note that in UML 2.0, these are called “actions.” UML 2.0 still has an element called an activity, which can contain actions and control nodes and is used to specify behavior) in a given column is performed by the person, organization, or system listed at the top of the swimlane. The flow starts at the start state (the solid dot) and flows as indicated by the arrows.

Even at this early point, the activity diagram shows an area that needs to be discussed by your team. This flow says the salesperson scans the product. Who said there is a scanner? A scanner is an implementation decision that you seem to be making very early in the development of your system. Generally, this is not a wise thing to do. There are still some stores out there that do not have UPC scanners. They still enter the prices by hand. These diagrams can help you challenge your assumptions early, before costly implementation begins.

In fact, if the scanner fails, the salesperson would need to enter the price by hand (or maybe even have to perform the dreaded “price check”). Here is the first case of finding an alternate flow. When doing your initial activity diagrams, it is a good approach to diagram the best-case scenario first and then go back later and add the alternate scenarios that you discover.

Continuing:

4.	Salesperson provides total cost.
5.	Salesperson inquires as to payment method.

See Figure 2-7.

Hold on! What is this “customer acknowledgment” activity? That is not in the original flow. As we created this diagram, we realized that having the workflow go directly from step 4 to step 5 was not really correct. If it was correct, why would the salesperson provide the total cost to the customer if the customer just immediately moves to asking about the payment? The reason the salesperson provides the total cost is to give the customer an opportunity to object. What if the customer does not have enough money to pay for everything? What if the price from the scanner is different from what the customer read on the price tag? Here, we see the value of these diagrams in providing the opportunity to question the business workflow (which looked fine in text format but was shown to be wrong when diagrammed) and raising the possibilities of additional alternate workflows. Continuing with the workflow:

6.	Customer provides payment.
7.	Payment is accepted by salesperson.

See Figure 2-8.

Here, we add the payment. We can see this is obviously too simple. This flow should vary based on payment method (cash, credit, gift certificate, coupons, discount card, etc.). This is another set of alternate flows to revisit later. Continuing with the workflow:

8.	Receipt and product are given to customer.

See Figure 2-9.

Which is given to the customer first…the receipt or the product purchased? In this case, it does not matter. These activities can happen in parallel. This is shown in the activity diagram by using a synchronization point (the horizontal black bar). The two flows that come out of the bar indicate they can happen independently. When two (or more) flows come into a synchronization point, this indicates that the workflow cannot continue until all the inflowing activities are complete.

We have also added a terminating activity, Customer Leaves, to the flow. At first glance, this does not seem to add much value, but it does add clarity so that you can see explicitly how this interaction between your business actor and your business use case ends. Also, if this were to be an online store, Customer Leaves would have many business and application design implications. For instance, when your customer leaves your online store (i.e., your web site), you could not immediately give the products to the customer—instead, the business flow would initiate a fulfillment activity, and that in turn would cause you to modify the payment activities because you would need to account for shipping and handling charges. You could not give the customer a receipt—but you could send them an email receipt. The explicit end of the flow is shown at the end state (bull's-eye) symbol.

The end of this workflow might raise the question, “Why not have 'Give Receipt to Retail Customer' and 'Give Product to Retail Customer' both flow into a synchronization point to ensure that the customer does not leave without her product or receipt?” This is a good question that you should consider. The answer depends on how you want to have your business operate. Are you going to take any overt actions to ensure that the customer can't leave without both her products and receipts (some stores do check your receipts as you leave)? If so, the additional sync point is a good idea. If your business is going to take no such actions, it would be incorrect to add the sync point. These are the kinds of issues that rarely come out with purely textual specifications. Visual models make things and their relationships obvious and thus provide the level of focus that simple text cannot.

Alternate Flows

Developing that simple activity diagram raised a number of questions that need to be resolved for the workflow of the Process Sale business use case. Many of them were possible alternate flows:

• Scanner fails, manual price entry.

• Scanner fails, price information not available to salesperson, manual price check.

• Customer does not accept total price, insufficient funds, cancel entire sale.

• Customer does not accept total price, insufficient funds, exclude one or more products from sale.

• Customer does not accept total price, expecting different price, resolve pricing.

• Customer does not accept total price, doesn't want to pay that much, cancel sale.

• Payment method is rejected (e.g., store only accepts certain credit cards).

…and so forth.

These flows can be depicted using a decision point (shown as a diamond). You can see how these can be used in the alternate flow for scanner problems in Figure 2-10.

In summary, business use case diagrams provide a context for your business—what is inside the business and what is outside. They show which people or systems interact with your business. They capture the interfaces between your business and the world outside. Activity diagrams depict the basic workflow of how a business operates. They define in more detail the interface between your business and the business actors. They enable you to understand how people or systems interact with your business, the processes that are followed, and the activities that are performed. In this way, you obtain a basic understanding of the way the job gets done.

Watch Out—Business Rules Business rules are policies, constraints, or other rules that you impose on your business. For example, “a savings account can have as many as two owners” is a business rule. As you start to develop your activity diagrams, you are starting to create, implicitly or explicitly, business rules. You will see them start to take shape here and in subsequent diagrams. They will be further developed in the upcoming sequence diagrams and eventually take form in the design of the system, when you reach the class diagrams. The caveat here is to be aware that you are creating such rules and to do so consciously.

From the Real World—The “25 Rule” The rental-car shuttle bus was waiting to leave to return us to the airport. In typical fashion, the driver came around and asked everyone to which airline they were going. The young man sitting next to me fumbled over his words for a moment, then sheepishly looked up at the driver. He said he wasn't going to the airport. He needed to go to another rental car company. This was puzzling but became more so when the driver said, “Ah. The 25 rule, eh?” The young man nodded. This riveted my attention. I had to ask about this “25 rule.” I found that in most areas of the United States, you can't rent a car from many rental car companies unless you are over 25 years of age. This young man had a reservation for a rental car, but when he arrived at the lot, the rental people there invoked the “25 rule.” This major rental car company had obviously never modeled the business. Otherwise, why would their reservation people give the gentleman a reservation, only to have the fulfillment people at the rental site deny him a car? This lack of an integrated business (i.e., Reservations and Rental Fulfillment not operating by the same business rules) costs the company time and money, misuses personnel and equipment, incurs an opportunity cost, and definitely does not please the customer.

Lessons Learned Modeling your business makes clear how different part of your business interact. Modeling your business makes your business rules explicit.