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?
|
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.
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.
|
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]