Object-Oriented Analysis and Design for Information Systems: Modeling with UML, OCL, and IFML (2014)

CHAPTER 2

Business Modeling

Business modeling is the first time-consuming activity that is performed during the development of most projects in the software industry. Although business use case diagrams and other UML diagrams are currently used to help teams understand business processes, sometimes the connections between those elements are not clear. This chapter shows how business use cases may be used to produce a high-level view of a business, and how they can be detailed by using business activity diagrams and state machine diagrams that describe key business processes and key business objects. It also shows how business use case diagrams may be used to define the scope of a system.

Keywords

Business modeling; business use case diagram; activity diagram; state machine diagram; project scope

Key Topics in this Chapter

• General View of the System

• Business Use Case Diagram

• Activity Diagram

• State Machine Diagram

2.1 Introduction to business modeling

The Inception phase of the Unified Process (UP) consists of a period of time when the analysts are looking to gather information about the business to be automated or restructured. It is assumed that the knowledge that the analysts have about the business is minimal, and that the interaction with the stakeholders will be intense. The goal in this phase is to discover if it is worth it to do the analysis without developing too deep into the project.

Usually, before starting to discover and analyze system requirements, it is necessary to understand the goals of the target organization. This view can be obtained by the UP discipline called business modeling.

Business modeling is, therefore, an activity that supports the discovery of system requirements by helping the team perceive the wider business context where the future system will operate. Different text or diagram artifacts can support it, as this chapter presents.

The artifacts in this phase usually do not need to be too detailed. Meetings with stakeholders could produce a record (minutes) that probably can register several ideas about the goals of the company and the automation opportunities. By using this information, the team may build a general view of the business.

Starting with the records obtained, the team can organize an initial document for the project, which can be called general view of the system or executive summary. That document usually includes the scope declaration.

Other relevant information is usually included in the general view as well, such as stakeholders, power assignment, risk analysis, preliminary budget and schedule, and the project premises.

The scope declaration of the project may be related to the business analysis activities. After discovering useful information about the business, the team is better able to determine what must and what must not be included in the project. The general view of the system may be elaborated with the help of some UML diagrams. Business use case diagrams (Section 2.3), and business activity diagrams (Section 2.4) may be used, and occasionally state machine diagrams (Section 2.5) can be used as well. Alternatively, the Business Process Model and Notation,¹ BPMN,² may be used instead of the UML activity diagrams. These diagrams help in determining if the scope of the project is complete and consistent with the goals of the organization.

Business modeling consists of studying and understanding the organization and its processes, because usually the system to be developed will not be an isolated product, but an organic part of the organization context. The goals of this discipline are to:

• Understand the structure and dynamics of the target organization in which the software will be used.

• Understand the current problems of the target organization and identify potential improvements that can be obtained with the software.

• Assure that clients, users, and the development team share a consistent understanding of the target organization.

• Derive the requirements that will lead to the desired improvements.

One of the critical points for the success of a software development project is its funding. In order to keep interest in the development of a software product a client must always stay convinced that its investment represents a gain, and not a waste of time and money. Comprehension of the business model is fundamental so that the development team can keep the client interested in the project.

Another important aspect of business modeling is to bring the business team and the software engineering team closer, so that the actual problems of the organization and its needs are understood, analyzed, and solved using information technology.

Business modeling is very important when significant behavioral changes are introduced to a group of people. In this case, business context and the consequences of installing a new system must be acknowledged and studied. It may be less important when such behavioral changes are not expected.

Thus, business modeling may have different levels of importance depending on the project needs. Kruchten (2003) identifies six scenarios of growing complexity in terms of the need for business modeling:

• Organizational chart: It may be necessary only to build an organizational chart in order to know the sectors and responsibilities related to the area in which the project is inserted. In this case, business modeling, in general, is very simple, and happens only during Inception. The organizational chart will help analysts to locate the people that are responsible for the different aspects related to the future system, and what degree of authority is assigned to each one when deciding the requirements.

• Domain modeling: If the goal of the project is to build applications to manage and present information, then business modeling may be performed during domain analysis, that is, when a static model of the information (conceptual model) is produced. In this case, business modeling is performed during Inception and Elaboration.

• One company, many systems: It may be the case that the team is developing a whole family of systems for a company. In this case, business modeling is not only about one system, but spreads along many projects, and could even be a separated project of its own. It will help to discover individual system’s requirements as well as to determine a common architecture for the whole family.

• Generic business model: If the goal is to build one or more systems that will serve a pool of organizations, then business modeling is useful in order to align the different organizations to a common business view, or, if that is not possible, to obtain a business view in which the specifics of the organizations are visible.

• New business: If an organization decides to start a new business, and a whole set of systems must be developed to give support to it, then a significant business modeling effort must be undertaken. In this case, the goal of business modeling is not only to find requirements, but to verify the effective viability of the new business. Thus, business modeling, in that situation, could be an independent project.

• Renewal: If an organization decides to completely renew its way of business, then business modeling will be a separate project, performed in several steps: vision of the new business, reverse engineering of the existing business, direct engineering of the new business, and installation of the new business.

Other factors that increase or decrease the need for business modeling in a project are:

• Well-defined and stable requirements at the beginning of the project (for example, creating a substitute for an existing system) reduce the need to perform intense business modeling.

• If the new system is going to change the way people do their work, then special attention must be paid to business modeling, especially when the business model is going to be changed or rebuilt after the automation of some business use cases.

• If the project has important risks, especially business risks, then business modeling must be more detailed and intense.

• If the user community is large and heterogeneous, then business modeling probably will be more difficult.

• If it is necessary to integrate the new system with hardware and legacy systems, then the comprehension of those elements must be included in business modeling, generating more work.

• More uncertainty about requirements means more attention to business modeling.

No matter the level of detail and effort to be put into business modeling, every project must begin with preliminary documentation that allows for an understanding of its scope. A project with poorly defined scope will certainly give rise to discomfort or even fights between the client and development team, regarding the inclusion (or lack of inclusion) of certain features.

2.2 General view of the system

The activities related to the definition of the scope of a project should usually take a relatively small fraction of the time of the whole project, although variations may exist depending on the kind of the project: projects with simple and well-defined requirements may demand no more than a couple of days of business modeling while complex and large projects may demand weeks or months. At the time of scope definition, all information about the company business must be explored by interviewing users, clients, and domain specialists, as well as by the examination of documents, reports, existing systems, and related bibliography.

For most projects, the first question the analyst should answer is the following: What is the vision of the company for the project? In other words, what does the company want with the project? Why is it being proposed, and why is the company going to spend money with it?

At that moment, another question, often forgotten, may be raised: Buying or developing? Sometimes, the product the client wants is available for purchase.

These questions must be answered in a relatively short time. That is why it is suggested that the Inception phase proceed relatively quickly. Why? Because, at this time, the client and the development team usually do not have an idea of the real extension of the project and it is, from the point of view of both, an investment on the future, and, therefore, a risk.

The general view of the system or executive summary is a free format document, where the analyst may report the relevant items she discovered about the system after the initial interviews with the stakeholders. The document usually includes the scope declaration for the project.

We do not intend to propose rules for writing that document. But it is suggested that it should not be too long. A few pages of text and some diagrams seem to be sufficient to describe in a summarized way the scope of most systems. More than that could mean that too much detail was included in the summary. These details could be alternatively addressed in other documents such as the list of risks, requirements, or use cases.

The scope declaration in the general view must present, in general lines, the product that must be developed: what must be included, and what could be included but should not. This information may be obtained initially by interviewing the stakeholders, and may be refined later with the use of the diagrams presented in this chapter.

If possible, the main deliverables of the project should be also defined in the general view as well as the time frame when the client is going to receive some kind of delivery from the development team. Normally, this list of deliverables consists of implemented versions of the software, but the list can also include other items, such as design, manuals, installation media, training, etc. It can be very difficult to establish deadlines for deliveries before doing the requirements analysis of the system, because estimation effort techniques such as function points (Albrecht and Gaffney Jr., 1983), use case points (Karner, 1993), or COCOMO II (Boehm, 2000) can only be applied after a good deal of the requirements is known. Thus, the information about deadlines at this early stage is more a guess than a formal strong commitment for development.

The general view document may also contain some acceptance criteria for the product, that is, quantifiable items that will be used to decide whether the project was a success or not. The product acceptance criteria must at least include metrics for deadlines, budget, and quality. If subjective criteria such as “customer satisfied,” “system easy to use,” or “state-of-the-art technology” are used, they must be quantified, that is, it must be defined how to measure “customer satisfaction,” “ease of use,” “state of the art,” and so on. Examples of quantifiable acceptance criteria are “the system must support up to 50,000 simultaneous accesses without degrading performance,” “the system must eliminate the need to use paper for performing processes x and y,” and “the system must allow selling up to 100 books a minute on the Internet.”

More information may be added to the general view document if needed (for example, main risks, technologies to be used, etc.). The general view of the system is the base agreement document for the client and the developer. It will be taken as a basis for planning the rest of the project.

It is important to mention that when the general view is being built, the requirements analysis has not yet been completed, and therefore the information mentioned in the general view consists of early commitments. It is expected that the requirements analysis will detail the scope in depth, but not augment its extension. For example, in requirements analysis the process of selling books may be detailed with discounts, sales, delivery, and so on (considering that “selling books” is mentioned in the scope declaration), but if the payment roll of the company was not mentioned in the scope declaration, then the inclusion of that item in the project would require a renegotiation of the scope declaration.

Pressman (2008) proposes a number of techniques to communicate with stakeholders in order to discover business goals, for example:

• Traditional focus groups, where a trained analyst meets with a group of end-users or people representing their roles.

• Electronic focus groups, where the meetings are conducted by the use of electronic media.

• Iterative surveys, where a number of surveys are conducted among end-users, presenting them some questions and asking for clarification.

• Exploratory surveys, where an exploratory research is conducted among end-users that use a similar existing product.

• Scenario building, where a group of end users is led to produce a description of a number of scenarios for using the system.

The last option seems to be very popular among agile method practitioners, where scenarios are sometimes identified as user stories.

Figure 2.1 presents a general view with very preliminary scope declaration for a fictional virtual bookstore Livir,³ which will be used to illustrate the modeling techniques within this book. This text would have been obtained after a quick preliminary meeting with the client. Using this as a basis, a deeper study may be conducted with business use cases and other diagrams, so that the information contained in it is refined, as shown below in this chapter. The document is divided into two parts:

• A simple vision statement of what the project will offer to customers and the business that’s creating it.

• The constraints for version 1.0.

FIGURE 2.1 General view for the Livir project.

To allow for the presentation of this project in a book, a series of simplifications were considered. The description and modeling of a real project would be much more extensive. Furthermore, the models presented would sometimes only be partial at a given time, being refined or changed later.

It can be seen that the general view is a nonstructured view of the project. It includes business information for managers, and operational information for developers. Sometimes, even details about the technology to be used can be described if necessary. What the analyst must consider is that the general view describes the main concerns of the clients and those concerns will be better structured later during analysis and design.

A good analyst must act like a psychoanalyst, that is, she must avoid speaking in the place of the client. The analyst must help the client to speak; when the client starts to report some of her needs, the analyst must hear, instead of presenting fast prebuilt (and often mistaken) solutions. The analyst must motivate the client to detail her requirements and must question those requirements so that the client can decide which are urgent and which are not.

2.3 Business use cases

Jacobson (1994) presents in detail techniques for business modeling with business use cases. In general, in business models, there are entities (people or companies) external to the target organization, called business actors, and internal entities, called business workers. Business use cases are the processes performed by those actors and workers that allow them to reach some of the company business goals.

The business use case model considers the entire company as a system, and the actors may be people, companies, or other organizations that create business or maintain relationships with the business (Kroll and Kruchten, 2003).

The first thing the team must think about when doing business modeling is that what is being modeled is not a software system. A company is being modeled. Business information is sought from higher-level management people and specialists, because they know and sometimes create the company goals.

The quantity of business use cases that will be identified may be relatively small. A business process is a long-range process that is performed by the company; think, for example, of selling products, conducting marketing, providing services, solving customer problems, etc. Each process of this type must contribute to a business goal. This is not the moment for detailing such processes. For example, selling products may include many subprocesses such as registering customers, offering products, sending products, applying discounts, etc. But those processes (that later possibly will be identified as system use cases if they are going to be automated) are involved by the highest-level process, which is Sell books.

Although UML still does not have a standard symbol to differentiate business use cases from system use cases (Chapter 3), it is usual to represent business use cases with the stereotype business, or by cutting the use case ellipse with an edge as shown in Figure 2.2.

FIGURE 2.2 Business use case.

In this example, Sell books is a business use case because it involves a relationship between the company and an external entity (a customer), producing a perceptible and consistent result: one or more books sold. This use case possibly will be performed by the customer with the collaboration of some workers inside the company; it may or may not use software systems.

Use case names must be chosen carefully, because at this stage they will summarize critical information about the system, and wrong choices may prevent the team and stakeholders from sharing comprehension about the real intention of business actors and workers. Blain⁴ presents some best practices collected from many sources:

• Good use case names reflect user goals. Names such as Access system or Open main window must be avoided because they reflect technology and not a business goal. Also names without verbs such as Invoice must be avoided because it is not clear what is going to happen to the invoice. Better names might be Generate invoice, Cancel invoice, Pay invoice, etc.

• Good use case names are as short as possible. Although some people may propose that a use case name should not have more than two or three words (or any other number), it is unfeasible to define such a limit because there is a risk of losing clarity on the business goal if the name is too short. As Blain points out, which word could be removed from the name Collect late payment without obscuring its meaning? However, that name is better than Collect late payment from customers that are past due.

• Good use case names use meaningful verbs. Use case names not only should have strong verbs, but they must be meaningful. A meaningless verb is one that does not make clear what the use case accomplishes; for example what does a use case such as “Process order” accomplish? What result does it produce? A name such as “Separate ordered items for dispatch” would be more meaningful in that case.

• Good use case names use active voice. As in general writing, active voice is preferable to passive voice. Pay for order is better than The order is paid.

• Good use case names use present tense. The present tense indicates what the user is trying to do. Past and future tense may sound confusing and unnecessary.

• Good use case names do not identify the actor. As use cases are linked to actors, actors are not part of their names. Thus, a use case name must not identify the actor as in Manager creates sales report. Just name the use case Create sales report and link it to a manager or other actors if necessary.

• Good use case names are consistent. The same naming rules and naming conventions should be applied along a project or group of projects. Avoid, for example, naming one use case Generate sales report and another Produce reservations report. Chose one verb for that meaning and use it consistently.

Additionally, Probasco (2001) proposes that the list of use case names should resemble a to do list. Thus, instead of writing Cash withdrawal, Funds transfer, and ATM service, it would be better to write Withdraw cash, Transfer funds, and Service the ATM, respectively.

Probasco also insists that the meaning of a use case name must be precise. For example, is Auction a good use case name? Is it a verb or a noun? If you consider that it is a noun and that a verb must be added, is Execute auction a good name? The verb Execute would probably be a programmer’s choice, but it probably has no meaning for an auctioneer (Is the Auction going to be shot to death?). In this case, an idea would be to talk to a domain specialist in order to obtain a better name. On the other hand, even if “auction” is indeed a verb it is not sufficiently clear. Is it the auction of a single item? Is it the auction of a complete set of items? Is it simply an auction participant placing a bid? In that case, names such as Auction items, Auction single item, or Place bid would be clearer.

2.3.1 Business actors and business workers

During business modeling there are two kinds of actors that must be addressed (Figure 2.3):

• Business actors: People, organizations, or even systems that perform some activities belonging to the process, but which are not part of the target company. That is, they are not under company control. Business actors could be, for instance, customers, publishers, external auditors, partner companies, or even other automatic systems that the target company could interact with.

• Business workers:⁵ People, organizations, or even systems that perform some activities belonging to the process and that are part of the target company. They could be the company’s employees, its departments, or even existing software systems belonging to the company. Graphically, they are distinguished from business actors by the use of the stereotype worker.

FIGURE 2.3 Business actor (left) and business worker (right).

This differentiation is important because business actors usually cannot be automated, that is, they will not be replaced by computational systems. However, business workers roles can possibly be replaced by automatic systems (English, 2007).

Business actors and business workers are linked to the business use cases they participate in by connecting lines without arrows,⁶ as shown in Figure 2.4.

FIGURE 2.4 Links between business actors, business workers, and business use cases.

2.3.2 Automation opportunities

A bookstore that intends to sell through the Internet, like Livir, should produce a business model that identifies its main business use cases, external actors (customers, publishers, etc.), and business workers (managers, clerks, etc.). If we suppose that the bookstore company already exists and has no automation at all or very incipient automation, then the business workers will be, basically, real people. These workers may be candidates for automation if there is interest in increasing the level of automation of the company. For example, the role of the clerk that currently helps customers find books on the shelves may be replaced in the virtual bookstore by an automatic guidance system. However, the customer role cannot be replaced by an automatic system.

Every business worker role will usually not be replaced. It will depend on the scope of the project to be defined. An advantage in making the business use case diagram, then, is to help in visualizing and making decisions on automation. With the diagram, it is possible to visualize what must stay inside and outside the automation scope, depending on the project’s goals.

Normally, during an automation process within a company, it is useful to replace at least the workers’ roles that correspond to mere proxies, that is, the ones that simply perform actions in the place of an external actor. In the case of the bookstore, the sales clerk role is necessary only to help the customer at the physical store. But, when the sales are moved to virtual space, that role is not necessary anymore, because the customer may easily find her way on the website.

The association of the business use cases with the company’s major business goals helps to identify the scope of the system, that is, the activities that will be effectively automated in the project that is being initiated. In the example of Figure 2.5, all use cases are candidates for automation at differing levels of priority. However, the company could be interested only in implementing sales and acquisition at this point, leaving marketing and customer services left to a second project.

FIGURE 2.5 Business use cases: candidates for automation.

The system boundary can be used to identify the set of business use cases and business workers that will be automated, as shown in Figure 2.6.

FIGURE 2.6 System boundary being used to indicate the scope of the project.

The business use case diagram shows that the automation project will include the processes of buying and selling books and the role of the clerk. It also shows that the processes of advertisement and gaining client loyalty are outside the scope of the project.

However, a deeper analysis may show that the worker that buys books for the bookstore cannot be easily automated. It might be the case that all books could be automatically bought by an automatic process that could analyze potential sales and stock, without the participation of any human being. But, if that is not the case, the best thing to do is to consider that the clerk really has two different roles: help the customer (that role will be automated) and buy books for the bookstore (that role will not be automated). Figure 2.7 shows an evolution of the diagram where part of the responsibility of the clerk is reassigned to a worker named “Acquisition manager.” There is no one-to-one equivalence between a role and a person: a person may perform many roles and a role may be performed by many different people.

FIGURE 2.7 An actor is split because only part of its role will be automated.

If the project, on the other hand, consists of a number of subprojects or stages, in which different parts of the company would be automated, that could also be indicated by the use of different system boundaries in the diagram: one for each subproject or stage.

The next step that leads to the requirements analysis is the detailed study of the business use cases that will be automated. The level of precision and detail depends on the objectives of the project, as already discussed early in this chapter.

2.4 Business activity diagram

The UML activity diagram is a very popular option for studying the details of a business use case. With this diagram, the different activities performed by business actors and workers in order to reach the general goal of the use case can be specified.

For a better understanding of the way the company works through its use cases, it is possible to create an activity diagram for each business use case that is going to be automated. The activity diagrams can be used to represent processes at the organizational level.

2.4.1 Basic elements

Much of the UML activity diagram is similar to a flowchart. There are activities sequentially linked. Decision points and loops may be used and even parallelism may be expressed in such diagrams.

The activity diagram may be divided into swim lanes, each one representing an actor or worker that participates at a set of activities. As in the use case diagram, an actor or worker may be a person, a department, a computational system, or even a complete organization.

The process represented in the diagram usually has an initial node, represented by a solid circle , and an activity final node, represented by a solid circle inscribed in a circumference . The initial node may not be considered mandatory in some cases when the beginning of the process can be inferred by observing an activity that does not have an antecessor. However, the use of that mark improves the readability of the diagram because it is easier to see where the process really begins.

The activities are represented by action nodes . When an activity is represented inside a swim lane it means that the corresponding actor is the one responsible for the activity.

Flows or dependencies between activities are represented by arrows →. Flows usually link two activities, indicating precedence between them.

A path is a sequence of activities linked by flows: →→→→.

In the Livir example, the activity diagram may be used as a way to visualize the details of business use cases such as Sell books. The model presented in Figure 2.8 shows a first approach to the process.

FIGURE 2.8 First approach to an activity diagram for modeling the book sales business process.

The diagram that is starting to be designed in Figure 2.8 is not intended to be a model for the system to be built and should not be thought of like that. Its utility is to help the team understand which activities and actors are involved with the main business processes of the company, so that, using that information, they can perform a more effective requirements analysis later. The logical path of the diagram must be understandable and validated by business people.

Later, the analyst will examine in detail each of the activities that must be performed. If a given activity belongs to the scope of the system that is going to be implemented, then it must be a target for a more detailed analysis.

2.4.2 Control flow nodes

Two control flow nodes are common in the activity diagram: decision nodes and parallelism nodes.

• The decision nodes (branch and merge nodes) are represented by diamonds . The flows coming out of the decision node must have guard conditions (a logic expression between brackets). Two or more flows may leave a decision node, but it is important that the guard conditions are mutually exclusive, that is, only one of them may be true at a time.

• The parallelism nodes (fork and join nodes) are represented by bars . The flows coming out of a fork node are performed in parallel.

The diagram in Figure 2.8 is still a very crude representation of the real process of selling books. Just to illustrate a possible evolution of that diagram, let’s examine the situation when some of the ordered books are not available in stock. It would be necessary to order them from one of the publishers and add them to the customer order after arrival. Figure 2.9 shows this situation by indicating that if some books are not available, then they have to be ordered from publishers, and the order is sent only after they arrive.

FIGURE 2.9 Example of decision control flow.

Just below the Confirm payment activity there is a branch node represented by the diamond. As noted before, the decision node allows only one exit flow to be followed. The guard conditions ([some books missing] and [all books in stock]) are mutually exclusive. From the branch node, the flow follows one of the alternate paths until reaching the merge node that is depicted just above the Send books activity.

Later, the analyst could discover that the model is still not satisfactory. For instance, even if some books are not in stock, the order could be sent in two or more deliveries. Thus, two paths could be performed in parallel: sending the books that are available in stock and, if necessary, ordering the other books, and sending them later, as shown in Figure 2.10.

FIGURE 2.10 Example of parallel flows.

The bar below the Confirm payment activity in Figure 2.10 represents a fork node because it starts two parallel paths, and the other bar represents a join node because it synchronizes the parallel paths into a single path.

The single path after a join node can only be followed if all paths that come to the join node have been followed. It can be seen that in that model, if all the books are in stock, only one of the parallel paths will have activities to be performed, because the other path immediately goes to the merge and join nodes.

The fork, join, decision, and merge nodes, as well as the initial and activity final nodes, may be placed inside swim lanes. However, this does not affect their semantics. Thus, the choice of a swim lane to place such nodes is only due to visual suitability.

Another node that can be useful sometimes is the flow final node, , which terminates a path (parallel or not) that is being performed. The difference between it and the activity final node is that in the case of the activity final node, all flows of the activity diagram are terminated when a single flow reaches it, while in the case of the flow final node only one flow (among other parallel flows) is terminated, but the activity continues.

In the use case of Figure 2.7, only one actor (customer) and one worker (clerk) participate in the use case Sell books. However, after detailing the activities related to that use case, as done in Figure 2.10, it was discovered that two more actors are necessary: the Publisher and the Credit card operator. Additionally, the Publisher is an actor that has to be linked to the use case Buy books. Thus, depending on the level of detail desired at this point of the project, the business use case diagram may be updated to reflect those discoveries, as seen in Figure 2.11.

FIGURE 2.11 Business use case diagram updated with information discovered with the activity diagram.

Other options for detailing a business use case are the UML sequence diagram and communication diagram. However, those diagrams are used to represent messages being sent to elements. It is not always quite natural to find names to label those messages in the case of a business process, and meaningless names such as “seek data” and “check result” are chosen eventually. Thus, the activity diagram is a more natural choice to describe what happens in the real world, inside an organization of people. However, as will be seen in Section 5.8, sequence diagrams are very useful to detail system use cases, because system use cases usually consist of a sequence of information flows being exchanged between actors and a system.

2.5 State-dependent aspects of a business

Besides business use cases, which may be detailed by activity diagrams, it may be important to understand other aspects of a business that do not always appear clearly in such diagrams, such as some key business objects that change state during their life cycle.

Thus, another UML diagram that can help the team to understand the organization’s business is the state machine diagram. Like the activity diagram, this is a behavioral diagram, but, instead of modeling activities in processes, it represents a set of states in which a system, actor, or entity could be at a given instant.

The state machine diagram specifies events in its flows. An event triggers the flow that takes the entity from one state to another. That is, the flows are labeled with events that, if they occur, make the entity change from one state to another.

Those occurrences may be, however, restricted by guard conditions. For example, the login event may only send the system to a logged state if the password is correct.

Graphically, the events are represented in the flows by simple expressions, and guard conditions are represented between brackets, as in the case of activity diagrams.

The transitions in a state machine diagram can also include effects that are performed in response to a state transition. For example, the transition activated by the event login and guarded by the condition [password correct] can activate the action /grant access, which is an effect of the transition (not its cause). Actions associated to transitions are represented by expressions initiated by a slash (/).

As an example on how that diagram can be useful during business analysis, we can imagine that a team is interested in understanding the life cycle of a book in the bookstore. Examining the different states of a key business object such as a book for this project may reduce the risk of underestimating the complexity of the system requirements.

Thus, the team may discover that the book is initially registered in the catalog of a publisher. The bookstore can then order a set of copies of the book. When the delivery arrives, the book is added to stock and made available for sale. Once sold, the book is removed from stock and taken to the shipment department. In some situations, books may return to the bookstore, for example, due to a wrong address, or for being damaged during shipment. In the first case, the bookstore must contact the customer and, depending on the contact, it can cancel the sale or resend the book. The book life cycle finishes only when the transport company confirms the delivery. All those changes of state (transitions) are represented in Figure 2.12.

FIGURE 2.12 First state machine model for the life cycle of a book.

However, the model presented in Figure 2.12 is still incomplete regarding the possible transitions of a book. For example, a delivered book can return damaged and, in that case, cannot be resent or sold again. This can be represented by adding a guard condition to the transition that goes from the Returned state to the Sent state, and adding a new final state in which the book is discarded, as shown in Figure 2.13.

FIGURE 2.13 State machine diagram with guard conditions.

These guard conditions are still very informal. But this is acceptable during business modeling, because the goal is to understand the organization of the business, not specify a computational system. Nevertheless, precise guard conditions may be obtained if a formal language such as OCL (Object Constraint Language) is used. Later in this book expressions using OCL are introduced.

In some situations it is possible that an event causes a transition from more than one state. In the example of Figure 2.13, it can be imagined that a book may not only be damaged when it is in state Returned, but also when it is in other states like In store and Sold. Then, a transition to Discarded should exist from those three states. However, to abbreviate this set of transitions a superstate may be used instead.

In Figure 2.14, any transition from the superstate In store represents a set of transitions from each of its substates. In the case of a transition to the superstate, it is necessary to establish which of the substates would be the initial one. In order to do that it is necessary to include an initial state inside the superstate, or, instead, make the transition go straight to the substate.

FIGURE 2.14 State machine diagram with a superstate.

An object may be simultaneously at more than one single state. For example, a book may be a special offer or not from the moment it is ordered from the publisher until the moment it reaches a final state as discharged or sold. Thus, a book may be modeled with two concurrent states: the first state determines if it is a special offer or not, and the second state determines its status regarding sales. In the diagram in Figure 2.15 the concurrent states are represented inside orthogonal regions in a superstate.

FIGURE 2.15 State machine diagram with regions.

When a transition leaves the superstate, then all concurrent substates are also left. For example, when an arrival confirmation or discard event happens in the diagram in Figure 2.15, both concurrent states cease to be active and the book is considered to be at a final state.

The analysis on the states of a book could continue. For example, it would be possible to determine that a book in state Sold, Returned, or Sent could not change price from Normal price to Special offer and vice versa. That could be modeled by adding a guard condition to the transitions from states Normal price and Special offer: [not in state Sold, Sent, or Returned].

Utilizing a state machine diagram to represent a business object is useful for improving the discovery of system requirements related to some key business objects, as shown in Section 3.4.

2.6 Remarks

It is important to remember that the goal of business modeling is usually to find a general view of the business, and not a detailed specification of its processes. Thus, in most cases, the team’s goal is to concentrate on discovering information about the business, and not on formally specifying how the business works as if it was a machine.

A question still may be asked: Which business elements deserve the production of a state machine or activity diagram? Unless stated to the contrary, it is not advisable to prepare a diagram for every business element, because, if this is done, Inception would take too long to complete, and its objectives would be hindered. What is usually needed at that point is a model for some key elements, so that their behavior can be better understood and their requirements derived later.

A clue to identify those key elements is to ask what the business objects are. In the case of a bookstore, they are books, in the case of a hotel, lodging, in the case of a court, criminal processes, and so on. Thus, those are the key elements that must be modeled in greater detail to help in understanding the business.

A second question could be the following: Which diagram should we use – activity or state machine? The answer depends on the nature of the element to be modeled. A state does not correspond necessarily to an activity. A TV, for instance, may be in state off, when it is doing nothing. An activity diagram is useful when modeling people, organizations, or systems doing things. On the other hand, the state machine diagram is useful when a single entity passes through different states in which it is not necessarily doing something. Furthermore, the activity diagram usually details a business use case (that is, a process like selling, buying, checking, etc.), while the state machine diagram is usually associated with a business object (like books, people, orders, etc.).

Business modeling is not just about building diagrams, however. The purpose of diagrams is to help understand the context and the initial general requirements of a project and a system. Business modeling is one of the key activities that help a team to identify and prepare for project risks. Other risk mitigation activities may also be performed during Inception, such as proof-of-concept, workshops, prototyping, early tests, etc. Any strategy that helps in understanding the big picture and identifying the major risks and complexities of a project are valid.

2.7 The process so far

2.8 Questions

1. What is the purpose of business modeling?

2. Business modeling can occur with different levels of intensity for different kinds of projects. Explain and give examples!

3. What is the difference between a business worker and a business actor?

4. Which aspects of a business may be detailed by an activity diagram? Which may be detailed by a state machine diagram?