Chapter 3: Business Modeling

Figure 3.21: Synchronization in an activity diagram

To show which activities affect a business object:

1.

Select the Object Flow toolbar button.

2.

Drag and drop from the activity that changes the state of the object to the object itself. A dashed arrow will appear between the two. Figure 3.22 shows an example of how creating a rejection letter sets the state of the request object to Denied.

Figure 3.22: Object flow in an activity diagram

Summary

In this chapter we discussed business modeling. We began by examining why we would want to do business modeling in the first place. It is not right for all projects, but there are many times when business modeling can add a great deal of value to a project. We then moved on to discuss some of the fundamental elements of business modeling, including business actors, business use cases, business workers, and organization units, and how you would find some of these things in your organization.

From there, we moved into a discussion of the details of a business use case. You model the flow through a use case either by using text or via an activity diagram. Activity diagrams have the advantage of clarity and ease of use, especially when considering a workflow that is large and complex. We examined the different pieces of an activity diagram, including swimlanes, activities, actions, objects, transitions, and synchronizations.

Once we examined the business−modeling ideas, we moved on to how these items can be modeled using Rational Rose. We walked through the Rose toolbars and specification windows to examine the details of the

102

Chapter 3: Business Modeling

elements that can be added to a Rose model.

In the next chapter, we'll begin the process of system modeling. Business modeling isn't as concerned with what is automated by a particular system. System modeling, in contrast, is focused on the implementation of a particular software project. Business modeling helps us set the context for the system model.

103