Business Analysis Model

Now that you have established what you do for those business actors outside your business, you need to ask:

• What is my business going to do internally to provide the services the business actors want?

• What people, assets, information, etc. will we use to provide such services?

So, let's say you have completed the business use case models for the Process Sale, Bill Customer, Manage Inventory, and Ship Order business use cases of your retail store. You look at the business use case diagrams and activity diagrams, and you determine that there are a number of internal people in your business that are involved in these activities. These business workers are shown in Figure 2-11.

These workers have to use assets of your business to accomplish their functions. Some of these assets, or business entities, for the retail system are shown in Figure 2-12.

How do these business workers and entities relate? That is depicted in the business analysis model. This is an inside look at how your people (the business workers) interact with other business workers, business actors, and business entities to achieve the business processes (i.e., business use cases) that were just defined in the business use case model.

Look to the business use case model and activity diagrams to give you the starting information you need to create the business analysis model. You then add how you desire your business to operate internally, that is, the design of your in-house business operation. In this case, from the prior models, we know customers will be buying products (we hope). Product would be a business entity. Thus, we derive that we must maintain an inventory (also a business entity) of products. Therefore, we need an inventory worker to maintain the inventory of our products. Let's say that our business use case model has also specified that customers may order a group of products, which they want to be shipped to them. Therefore, we determine the need for a shipping worker (business worker) to create a shipping schedule (business entity) and an inventory worker (business worker) to assemble the order (business entity).

A partial business objects diagram for these requirements is shown in Figure 2-13. Technically, this is a class diagram (more on these in Chapter 4). However, because the typical class diagram you will see looks very different (they use different icons), to avoid confusion, we distinguish the two by calling these business objects diagrams. We use this name because this diagram depicts the things (i.e., the objects) that are used in your business to perform its function.

As part of the business analysis model, the business objects diagram shows the static relationships between the people and things in your system. In Figure 2-13, you see a new type of association—an aggregation (shown as a line with a hollow diamond on one end). An aggregation indicates that one thing is part of another. In this figure, a product is part of an order. But what does that really mean?

Watch Out—What ARE You Modeling? You have to be careful that you make clear the aspect of the things you are modeling. In the preceding example, we said that a product is part of an order. As we have modeled this in Figure 2-13, we are not modeling the actual physical products and the physical “order” that arrives on your doorstep. We are modeling the informational aspects of the products that are in the order. This would manifest itself in the real world as a packing list, for example. How do we show this? Through the use of an aggregation. Another way to think of such a relationship is the idea of containment—not physical, but a logical containment, as might be represented in a bill of materials or a parts list. If you want to represent a more physical containment, this would be shown with a composition aggregation. (This is depicted similarly to an aggregation, but the diamond on the association is solid.) What's the difference? With composition, the product may only exist in one order (i.e., you and I cannot both receive the same physical product). With aggregation, both of our packing lists can have the same product on them. We will discuss aggregation and composition further in Chapter 5.

To be more explicit, you can add numbers to the ends of associations to indicate how many things participate in the relationship. This is called multiplicity. In this case, there is a “1..*” annotation on the order-product association on the product end. This means an order can contain “one or many” products (the asterisk means “many”). The other end of the association shows a “1,” which indicates that a product may be part of only one order. Multiplicity can be shown as a single number (e.g., 5) or as a range (e.g., 0–12, meaning between 0 and 12 things can participate in the association, or 7–*, meaning from seven to an unlimited number of participants). Multiplicity will be discussed further in Chapters 4 and 5.

Sequence Diagrams

The previous business objects diagram captured the static relationships between the things in your business. You now need to establish the dynamic interaction of these things in operation over time. This can be depicted in a type of UML interaction diagram called a sequence diagram. A sequence diagram shows all the interactions between the model elements for a given scenario in time order. (Sequence diagram basics, discussed here, have been augmented in UML 2.0. These changes will be discussed in Chapter 8, “Is That All There Is?.”)

Using the information from the previous models, we show how a sale would be processed for a telephone order of some products (again starting with a best case scenario). First, the customer initiates a call to your telesalesperson, and basic information is gathered (see Figure 2-14).

Reading down the diagram vertically (time flows downward), we see that the customer calls our salesperson, who needs to gather information on the customer. (The arrows on this diagram indicate the interactions that flow between the various model elements. The lines that run vertically below the model elements are called lifelines.) Thus, we need to create a new business entity, Customer. (This obviously is not the same as the business actor customer. The business actor is external to the system. The business entity Customer resides inside our system and is a proxy, that is, a substitute or surrogate that represents the real customer. This will likely manifest itself during implementation as a record in a customer database.) The salesperson asks the Customer for his or her personal information and adds it to the customer business entity. You can see how this process of incrementally performing more detailed modeling results in the discovery of additional key elements of our system.

The customer then orders various products (see Figure 2-15). This requires the salesperson to create an order and add products to the order. This is repeated for all products. The order is completed, the price is calculated, and the total price is provided to the customer. You will note the recursive message, “Calculate Total Price,” that flows out of and then back to the order's lifeline. This merely indicates that order knows that it needs to calculate its own price and does so. This may seem an odd situation—an order calculating its own price? But in object-oriented systems, this is quite common. Responsibilities are typically assigned to the element (or object) that holds the information necessary to fulfill them. In this way, the information can remain encapsulated in one element.

Then, the customer provides credit-card information to the salesperson, who stores that information in the customer business entity and also sends it and the total price of the order to the credit-card company (a new business actor not previously identified) for verification (see Figure 2-16). Note how key information, such as name, credit-card number, expiration date, and total price, are passed as parameters of the message “verify credit information.” This is needed to determine if the customer has sufficient credit. The credit-card company approves, and the order number is given to the customer.

You can see how further development of the business models drives out critical details that may have been overlooked in the initial pass. In fact, this type of modeling is quite iterative.

From the Real World—Doesn't Play Well with Other Children We were working with a customer on using the UML for database design. On our last day, I was leaving for our final meeting when I saw that my rental car and three others had been broken into (eight o'clock in the morning, right in front of the hotel), and all the contents had been stolen—luggage, laptop, everything was gone. All I had was my cell phone. I called the police. They came, did the interviews, and kept the car to dust for fingerprints, etc. After the meeting, we went to the airport. After finishing all the exciting paperwork about the theft with the rental car company, we flew home. A few days later, I realized I never paid the rental car company for the days I used the car. I called customer service and explained the situation, and the very courteous service agent was glad to help me. Then she asked, “May I have your rental agreement number?” I had just told her everything was stolen. I didn't have the rental agreement number or even the rental agreement. That was OK. She offered a solution. She said I should go to the rental desk at the airport where I picked up the car. They might still have the rental paperwork around. I should get the rental agreement number from them and call her back. Then I could give the number to her, and she would be able to help me give her the payment. I should fly back to Atlanta to get the number and call her back? Not likely! We can see here that, although the individual systems the rental car company had in place (reservations, rental, customer service systems) did their individual jobs, they did not work in concert to serve the businesses needs (i.e., to get paid). The individual systems did not share one of the most important pieces of data their own business created—the rental agreement number. Obviously, the company never modeled any use case (if any at all) where the customer may not have a rental agreement number (e.g., car stolen, rental agreement lost, billing error, etc.)—a parameter that would be easily shown in a sequence diagram as being passed across business functions. Therefore, their systems could not interoperate effectively.

Lessons Learned Along with the physical aspects (e.g., people, things) of your business, model the operation of the business, too. Create models of your business systems to understand how they will operate together. Remember to consider how your various systems interact to provide your business services. Leave nothing in your car unattended.

You can also see where these models position you to easily refine your business processes further. Consider the sequence diagram in Figure 2-15. Prudence would dictate that before adding a product to the order, you check inventory to see if it is in stock. This is easily done by adding the Inventory business entity and the appropriate messages to and from it. Another consideration—the storing of the credit-card information in Customer. Although this seems like a reasonable thing to do, you should consider it carefully.

Doing so implies that you need to create processes to update, delete, and report on that information. Or do you just plan to keep repeatedly dumping information into Customer on every purchase?

In summary, a business analysis model establishes what you do inside your business to fulfill its purpose. The business objects model shows which people use which things to complete their function. Sequence diagrams show how these elements interact with each other to complete the various business scenarios. Together these provide the internal view of how your business responds to requests from the outside world.

Taken together, the business use case model and the business analysis model depict how “business can be described in terms of processes that achieve goals by collaborating with different types of resource objects.” [ERIK1]