TeknikDergi.com

Yazılım İçin Aradığınız Herşey!

Sequence Diagrams for Scenarios of Business Use Cases

Sequence diagrams assist the detailing and specification of business use cases by emphasizing message exchange. The various scenarios of a business use case can be depicted in a sequence diagram. The representation is restricted to the message exchange within each business use case. Generally, the level of detail for these sequence diagrams is higher than for sequence diagrams spanning use cases.

Figure 3.28 shows a sequence diagram of the business use case check-in. This sequence diagram shows the scenario passenger check-in, as can be seen from the communication partners since the check-in representative does not appear. Sequence diagrams, just likeactivity diagrams, show if actors can carry out business use cases together or independently of one another (which cannot be seen in use case diagrams):

Figure 3.28 Sequence diagram of the business use case “Passenger Check-In”

High-Level Sequence Diagrams

We can use high-level sequence diagrams that span several business use cases to illustrate business processes at a coarse level. High-level sequence diagrams give a good overview of the interactions between customers, partners, and the business system. They serve as the basis for the electronic data transfer between the business system and customers, business partners, and suppliers (see Modeling for System Integration).

Figure 3.27 illustrates passenger services. The entire process spans the business use cases check-in and boarding:

Figure 3.27 Sequence diagram “Passenger Services”

Constructing Sequence Diagrams

The following checklist shows the necessary steps for the construction of sequence diagrams. Subsequently, we will further explain the individual steps.

Checklist 3.5 Constructing Sequence Diagrams in the External View

  • Designate actors and business system—Who is taking part?
  • Designate initiators—Who starts interactions?
  • Describe the message exchange between actors and business system—Which messages are being exchanged?
  • Identify the course of interactions—What is the order?
  • Insert additional information—What else is important?
  • Verify the view—Is everything correct?

 

Designate Actors and Business System—Who is Taking Part?

Sequence diagrams illustrate the interactions between actors and the business system. Fundamentally we have a pool of interaction partners from the use case diagrams. Depending on the flow that is being depicted in the sequence diagram, the appropriate actors and business systems can be selected from this pool.

In our case study (see Figure 3.24), we find the interaction partners passenger and passenger services for the above sequence diagram (Figure 3.23):

Figure 3.24 Constructing sequence diagrams

 

Designate Initiators—Who Starts Interactions?

For every sequence of interactions the actor who starts the interaction has to be identified. This actor is called the initiator. Since in the external view of the business model each business use case is initiated by an actor, we can here also select the actor from the pool of actors in the use case diagrams.

In our sequence diagram passenger check-in, the passenger starts the interaction by utilizing the service check-in from passenger services.

 

Describe the Message Exchange between Actors and the Business System—Which Messages are being Exchanged?

After the initiator has been defined, the subsequent progression of interactions has to be identified. For each communication step it has to be determined what information is exchanged. In this way the message will be defined. Messages are requests to do something directed toward a particular partner. The business objects that are exchanged with these messages also have to be defined.

 

Identify the Course of Interactions—What is the Order?

All messages are exchanged in a chronological order that has to be identified. Messages are inserted along the y-axis in increasing chronological order, from top to bottom (see Figure 3.25):

Figure 3.25 Constructing sequence diagrams

 

Insert Additional Information—What Else is Important?

Important activities of involved actors and business systems and important conditions can be inserted into the diagram as comments. Comments are inserted at the level of the appropriate message. Restrict this to important comments that have significance so that the diagram is not overcrowded with text (see Figure 3.26):

Figure 3.26 Constructing sequence diagrams

 

Verify the View—Is Everything Correct?

Completed sequence diagrams can be verified with the following checklist:

Checklist 3.6 Verifying Sequence Diagrams in the External View

  • Are all required sequence diagrams completed and available? There should be a sequence diagram for each business use case.
  • Are the sequence diagrams correct? Each sequence diagram contains only one object that represents the business system, and at most as many other objects as there are actors assigned to the business use case.
  • Is each actor that is listed in the use case diagram mentioned in at least one sequence diagram?
  • Is each actor who initiates a business use case mentioned as a starting point in one of the sequence diagrams?
  • Have all the important comments been inserted into the diagram? Are there maybe too many comments inserted into the diagram thereby reducing its clarity?

Sequence Diagrams

UML provides two types of diagrams for the representation of interactions: the sequence diagram and the communication diagram. Both diagrams visualize the exchange of information. However, the emphasis is different: communication diagrams emphasize the relationships of individual objects and their topology; sequence diagrams emphasize the chronological course of exchanged information. In the external view, we opt for the representation through sequence diagrams and do without communication diagrams for two reasons:

  • Sequence diagrams are easier to understand for developers and readers. In our practical work in projects we have observed a much higher acceptance of sequence diagrams because of their simplicity.
  • We avoid using unnecessarily many diagram types for the same facts. Less is often more!

If a customer or business partner uses an offered service, partners communicate with each other. The process can be described as a series of interactions. These interactions are clearly laid out in the sequence diagram, whereas the activities of each partner and the conditions under which the interactions take place are omitted in the diagram. However, they can be described with supplementary comments.

Like the activity diagrams, sequence diagrams can be modeled spanning several use cases, as well as being used to refine business use cases. A sequence diagram illustrates the various scenarios of a business use case.

Sequence diagrams can be used as the basis for message exchange between the business system and outside parties (Figure 3.22). We will treat this topic in Modeling for System Integration:

Figure 3.22 The elements of the sequence diagram

In a sequence diagram, we work with the following elements:

 

Comment

Sequence diagrams can be annotated with comments (UML generally permits comments in all diagrams.):

For instance, activities of partners or conditions can be specified as comments.

 

Object

Objects that are involved in interactions are placed on the x-axis. Objects are senders and receivers of messages in the sequence diagram:

In the business system model (external view) these objects represent the actors of the business system and the business system itself.

 

Message and Business Object

The messages that objects send and receive are shown on the y-axis. Messages are inserted in increasing chronological order from top to bottom. The direction of the arrow indicates the direction in which a message is sent:

The business object is listed in parenthesis. Business objects are conveyed together with messages. Some examples of business objects are tickets, boarding passes, and luggage. These examples will be treated in more detail in Package Diagram.

 

Reading Sequence Diagrams

Figure 3.23 shows a sequence diagram with the objects passenger and passenger services. The entire diagram documents the process of the business use case passenger check-in.

You begin reading a sequence diagram at the top (1). The starting point on the top left (1) is located on the vertical line that represents the passenger (2) as sender and receiver of messages. The flow begins when the passenger hands over his or her ticket (3) to passenger services for verification (4). The call verify (4) is the message; the ticket (3) that is handed over is the business object. The direction of the arrow indicates that the passenger is the sender of the message and passenger services the receiver (6). The receipt of the message at passenger services initiates activities, which is indicated by the gray vertical bar (7). The diagram does not show how passenger services handle the process, meaning that it does not show which activities are conducted:

Figure 3.23 Sequence diagram “Passenger Check-In”

Only the comment (5) can include a clue. Comments can be inserted at the left margin of the sequence diagram. An exact description of the processing can be found in the activity diagram ‘passenger checks in’ (see Figure 3.21 above).

In a final step, passenger services issues (8) a boardingpass (9) to the passenger. With that, the interaction that is illustrated in this sequence diagram is completed for both parties. This is indicated by the end of the wide gray vertical bar (10).

In the business model we do not utilize all the options of the sequence diagram. UML provides many more possibilities for this diagram type, but our experience showed that this is sufficient to communicate the essential aspects.

Constructing Activity Diagrams

As always, we want to point out that the use of suitable terminology and appropriate naming of actions and activities are essential for the clarity and comprehensibility of activity diagrams. Do not despair if it takes hours to find appropriate names—in most cases the effort is worth it.We recommend starting with activity diagrams that contain a low level of detail (‘high level’), which can span several business use cases. This gives a good overview of the chain of interactions between customers and partners and the business system.

Later, in more detailed steps the scenarios of business use cases can be described with activity diagrams. If a business use case is composed of several different scenarios, each is depicted in an activity diagram.

The following checklist shows the steps necessary for constructing activity diagrams:

Checklist 3.3 Constructing Activity Diagrams in the External View

  • Collect information sources—How am I supposed to know that?
  • Find activities and actions—What has to be done when actors draw upon offered goods and services?
  • Adopt actors from business use cases—Who is responsible for each action?
  • Connect actions—In which order are actions processed?
  • Refine activities—Do any other activity diagrams have to be added?
  • Verify the view—Is everything correct?

The order in which we present these steps was chosen deliberately. However, the order is not mandatory, since in practice the individual work steps often overlap heavily.

 

Collect Information Sources—How am I Supposed to Know That?

For the construction of activity diagrams we can use information that has already been collected for the construction of use case diagrams. Otherwise, the same advice holds true as in Constructing Use Case Diagrams.

 

Find Activities and Actions—What has to be Done When Actors Draw upon Offered Goods and Services?

Here too, we can start from a use case diagram. In the first step, we can derive activities from business use cases. Answering the following questions will help you find activities and actions:

  • Which work steps are required to carry out a business use case, meaning which steps are required to supply and process goods and services?
  • What do the individual actors do?
  • If several actors are involved in a business use case, which work steps are performed by each individual actor?
  • Which events initiate which work steps?
  • Which actions are so extensive that they have to be refined in another activity diagram?

In our case study, you can find the following work steps for passenger services:

  • Passenger checks in (derived from use case diagram); this entails issuing a boarding pass though passenger services.
  • Passenger boards airplane (derived from use case diagram).

In addition to this, there are other steps and events:

  • Passenger arrives at check-in counter and shows his or her ticket; this event initiates the check-in activity.
  • Luggage is loaded into the airplane by baggage transportation.

At first, just as above, activities can be described in an informal manner. We often find pre-existing documentation of processes, either informal or structured, which can be used as a basis to find activities and actions.

 

Connect Actions—In Which Order are Actions Processed?

Connecting the previously mentioned actions and activities into a flow generates an initial activity diagram. This flow is called control flow. The following questions will help you develop a control flow:

  • In which order are actions processed?
  • Which conditions have to be met in order for an action to be executed?
  • Where are branches necessary?
  • Which actions occur simultaneously?
  • Is the completion of actions necessary before the flow can proceed to other actions?

Passenger checks in, passenger boards, and loading luggage into airplane are complex activities, each of which is detailed in another activity diagram. The ‘fork’ within the action symbols indicates this:

Figure 3.19 A high-level activity diagram across several business use cases

 

Refine Activities—Do any Other Activity Diagrams have to be Added?

As we could see in Figure 3.19, it is necessary to refine several process steps. Here, we would like to display the activity of passenger checks in in more detail.

When a passenger checks in, he or she first shows his or her ticket at the check-in counter. The ticket will be checked for its validity. If the ticket is not OK the passenger will be referred to customer service. If the ticket is OK the passenger will check his or her luggage. If the luggage has excess weight he or she will pay an additional fee. The luggage will be forwarded to baggage transportation. The passenger receives his or her boarding pass.

Determine the level of detail in activity diagrams very consciously. Test which level of detail users of the diagrams can stand and which is the least amount of detail necessary. We cannot give universally valid rules, since the level of detail essentially depends on the target group and purpose of the model.

Now, we have the following additional actions (Figure 3.20):

Figure 3.20 Actions of an activity with a higher level of detail

 

Adopt Actors from Business Use Cases—Who is Responsible for Each Action?

In business processes it is important to know who is responsible for each individual action and who carries it out (Figure 3.21):

Figure 3.21 Activity diagram of a scenario of the business use case “check-in”

For the external view actors are adopted from the use case diagram. Each actor is responsible for a certain action and is recorded in a partition (swim lane) as the responsible party.

The individual activities are assigned to the responsible parties. The division of the activity diagram into partitions allows a clear overview of responsibilities. However, partitions can also be formed on the basis of other criteria.

An activity diagram could, for instance, be divided in such a way that manual, automated, and semi-automated actions would each make up one partition. This would be a good foundation for the conversion of flows into IT systems.

 

Verify the View—Is Everything Correct?

Just like use case diagrams, activity diagrams also have to be verified in terms of correctness of content, in cooperation with knowledge carriers.

Checklist Verifying Activity Diagrams in the External View

  • When constructing activity diagrams from the external view, always remember that internal procedures and business processes are irrelevant. Restrict your consideration to the description of those functionalities of the business system that are utilized by outsiders.
  • The conditions of different outputs should not overlap. Otherwise, the control flow is ambiguous, meaning that it is not clear where the flow proceeds after a decision node.
  • The conditions have to include all possibilities; otherwise, the control flow can get stuck. In case of doubt, insert an output with the condition ‘else’.
  • Forks and joins should be well balanced. The number of flows that leave a branch should match the number of flows that end in the corresponding join.

Activity Diagrams

Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate activities. In the external view, we use activity diagrams for the description of those business processes that describe the functionality of the business system.

Contrary to use case diagrams, in activity diagrams it is obvious whether actors can perform business use cases together or independently from one another.

Activity diagrams allow you to think functionally. Purists of the object-oriented approach probably dislike this fact. We, on the other hand, regard this fact as a great advantage, since users of object-oriented methods, as well as users of functional thinking patterns, find a common and familiar display format, which is a significant aid for business-process modeling.

Because it is possible to explicitly describe parallel events, the activity diagram is well suited for the illustration of business processes, since business processes rarely occur in a linear manner and often exhibit parallelisms.

Activity diagrams can be developed in various degrees of detail. They can be refined step by step. In the external view, activity diagrams, just like use case diagrams, exclusively represent business processes and activities from the outside perspective. Refining diagrams does not mean describing process details that are performed within the business system, which often leads to an unnoticed shift to the internal view (Figure 3.15):

Figure 3.15 Activity diagram “Passenger Services” with a low level of detail (“High Level”)
Figure 3.16 Activity diagram of the activity “Passenger checks in”

 

Activity

An activity diagram illustrates one individual activity. In our context, an activity represents a business process (Figure 3.16). Fundamental elements of the activity are actions and control elements (decision, division, merge, initiation, end, etc.):

Elements are connected by so-called “activity edges” and form the “control flow”, which can also be casually called ‘flow’. The execution of an activity can contain parallel flows. A border can surround the activity, meaning the entire activity diagram.

 

Action

An action is an individual step within an activity, for example, a calculation step that is not deconstructed any further. That does not necessarily mean that the action cannot be subdivided in the real world, but in this diagram will not be refined any further:

The action can possess input and output information The output of one action can be the input of a subsequent action within an activity. Specific actions are calling other actions, receiving an event, and sending signals.

 

Calling an Activity (Action)

With this symbol an activity can be called from within another activity. Calling, in itself, is an action; the outcome of the call is another activity:

In this way, activities can be nested within each other and can be represented with different levels of detail.

 

Accepting an Event (Action)

This action waits for an event to occur. After the event is accepted, the flow that comes from this action (and is defined in the activity diagram) is executed. Accepting events is an important element for business processes in activity diagrams:

Many business processes are initiated by events, for example, processing an order by the receipt of an order, or delivery by the receipt of a payment.

 

Accepting a Time Event (Action)

At a definite point in time, this action starts a flow in the activity diagram. An hourglass symbol can be used to represent the acceptance of a time event:

A typical example of a time event is triggering reminders after the deadline for payment has passed. We will discuss an example in Modeling for System Integration.

 

Sending Signals (Action)

Sending a signal means that a signal is being sent to an accepting activity:

The accepting activity accepts the signal with the action “accepting an event” and can react accordingly, meaning according to the flow that originates from this node in the activity diagram.

 

Edge (Control Flow)

Edges, represented by arrows, connect the individual components of activity diagrams and illustrate the control flow of the activity:

Within the control flow an incoming arrow starts a single step of an activity; after the step is completed the flow continues along the outgoing arrow. A name can be attached to an edge (close to the arrow).

 

Decision Node

The diamond below represents a conditional branch point or decision node. A decision node has one input and two or more outputs:

Each output has a condition attached to it, which is written in brackets. If a condition is met, the flow proceeds along the appropriate output. An ‘else’ output can be defined along which the flow can proceed if no other condition is met.

 

Merge Node

The diamond below has several inputs and only one output:

Its purpose is the merging of flows. The inputs are not synchronized; if a flow reaches such a node it proceeds at the output without waiting for the arrival of other flows.

 

Fork

For the branching of flows in two or more parallel flows we use a synchronization bar, which is depicted as a thick horizontal or vertical line:

Branching allows parallel flows within activities. A fork has one input and two or more outputs.

 

Join

For the consolidation of two or more parallel flows we also use a synchronization bar, which is depicted as a thick horizontal or vertical line:

During consolidation synchronization takes place, meaning the flow proceeds only after all incoming flows have reached the consolidation point. Join has two or more inputs and one output.

 

Initial Node

The initial node is the starting point of an activity. An activity can have more than one initial node; in this case several flows start at the beginning of an activity:

It is also possible that an activity has no initial node, but is initiated by an event (action: accepting an event).

 

Activity Final Node

The activity final node indicates that an activity is completed. An activity diagram can have more than one exit in the form of activity final nodes:

If several parallel flows are present within an activity, all flows are stopped at the time the activity final node is reached.

 

Flow Final Node

A flow final node terminates a flow. Unlike the activity final node, which ends an entire activity, reaching a flow final node has no effect on other parallel flows that are being processed within the activity at the same point in time:

In this way, parallel flows can be terminated individually and selectively.

 

Activity Partition

The individual elements of an activity diagram can be divided into individual areas or ‘partitions’. Various criteria can lead to the creation of these partitions: organization entities, cost centers, locations, etc:

Individual steps of an activity will be assigned to these partitions. Each partition is set apart from its neighboring partition by a horizontal or vertical continuous line; from this stems the term swim lanes. Each partition receives a name. Partitions can be arranged in a two-dimensional manner; in this case the activity diagram is divided into individual cells like a grid.

 

Reading Activity Diagrams

You start reading at the initial node, or in Figure 3.17 with the acceptance of the event passenger arrive sat check-in (1), and continue along the arrows of the control flow (2). The subsequent action passenger checks in (3) means that at this point the activity ‘passenger checks in’ is processed. This is depicted in more detail in another activity diagram as is indicated by the ‘fork’ in the action symbol:

Figure 3.17 An activity diagram

If you follow the control flow, next you will come to a conditional branch or decision node (4): if the check-in is OK the next step along the control flow can follow. Otherwise (5), the passenger cannot fly and the task of passenger services is completed. This can be seen at the black dot with border—the activity final node.

After successful check-in (7) you come to a black cross bar. All arrows that come from this bar (7) symbolize flows that are processed simultaneously. While the luggage is being loaded onto the airplane (9) the passenger is boarding the airplane (10). Between point (8) and point (11) the flows are independent from one another. At the second cross bar (11) the simultaneously processed flows (9 and 10) are merged, meaning that only when the passenger is on the plane (10) and the luggage has been loaded onto the plane (9), does the control flow continue below the cross bar (11). In our example, one more action (12) and subsequent to that the final state (13) follow, meaning that after the passenger is on the plane (10) and the luggage has been loaded onto the plane (9), the airplane can taxi toward the runway (12). You can see here that the last action airplane taxis toward runway (12) is only defined as a single action, even though this process is very complex and could be described in many other activity diagrams. In our context, however, it is not important to describe this step in detail.

Figure 3.18 An activity diagram with partitions

The activity diagram in Figure 3.18 is divided into two partitions: passenger (1) and passenger services (2). The passenger, for instance, carries out showing ticket at check-in counter (3), checking luggage (4), and paying fee (i). All other actions are located in the partition (swim lane) of passenger services (2) and are carried out by passenger services.

Constructing Use Case Diagrams

The following checklist shows the steps necessary for the construction of use case diagrams. After this, we will explain the individual steps further.

Checklist 3.1 Constructing Use Case Diagrams from the External View

  • Collect information sources—How am I supposed to know that?
  • Identify potential actors—Which partners and customers use the goods and services of the business system?
  • Identify potential business use cases—Which goods and services can actors draw upon?
  • Connect business use cases—Who can make use of what goods and services of the business system?
  • Describe actors—Who or what do the actors represent?
  • Search for more business use cases—What else needs to be done?
  • Edit business use cases—What actually has to be included in a business use case?
  • Document business use cases—What happens in a business use case?
  • Model relationships between business use cases—What activities are conducted repeatedly?
  • Verify the view—Is everything correct?

We deliberately chose the order in which the steps are performed. However, this order is not mandatory, since in practice, the individual steps often overlap heavily.

On one hand, a general understanding of the business system and business processes is important for the realization of each individual step. On the other hand, for many steps it is also necessary to consult knowledge carriers. It makes little sense to cling to the personal view of the analyst, who knows too little about the area of application.

 

Collecting Information Sources—How am I Supposed to Know That?

As a first step, it is important to find knowledge carriers, in order for analysts and knowledge carriers to work out the basic principles together. Such knowledge carriers are, for example:

  • People who are involved in performing, operating, and controlling business processes
  • Users of similar or related IT systems
  • Customers, who are often critical and creative knowledge carriers
  • Business partners
  • Domain experts
  • Management
  • External observers

Several helpful techniques have proven to be practical for the analysis and understanding of business processes:

  • Observing employees at work
  • Participating in the business processes being investigated
  • Taking the role of an outsider (e.g., of a customer)
  • Giving out surveys
  • Performing interviews
  • Brainstorming with everyone involved
  • Discussing with domain experts
  • Reviewing existing forms, documentation, specifications, handbooks, and work tools
  • Describing organizational structure and workflow management
  • Reviewing organization charts and job descriptions
  • Read through the introduction to the case study in Basic Principles and Background once more. In this introduction, we explain the basics of the case study, to help with understanding its business processes.
  • In your mind, run through all the roles that you can think of and their business processes (passenger, clerk in the duty-free shop, etc.).
  • Which activities can you think of from the view of the passenger? How would you try to freshen up your memory?

The result of this first step is often a collection of forms, work instructions, completed surveys, existing process descriptions, business objects such as tickets or boarding passes, etc. This overview is often not yet complete, and will be further extended during the modeling process.

 

Identifying Potential Actors—Which Partners and Customers Use the Goods and Services of the Business System?

This step is all about identifying potential actors. Here, this rule applies: the more the merrier. You can work with these actors in later steps; or they can be reduced in number or combined.

More potential actors can be found by answering the following questions (e.g., through consulting knowledge carriers). In doing this, it is advisable to create groups of people and types of organizations by abstracting directly from concrete examples of specific persons and organizations:

  • Which customers are customers of the business system, and which are customers of the business processes?
  • Who are the external partners of the business system? Which goods and services do these external partners use?
  • Which in-house positions and organization units are partners of the business system and use its goods and services?
  • With what external business systems does the business system interact?

As a first step, the previous explanations of our case study result in the following actors:

Figure 3.10 Potential actors

In addition to the passenger, who represents travelers, there is the check-in representative. The check-in representative is a person who is not the actual passenger, but an agent of the passenger. The check-in representative has the task of performing the check-in with the ticket of the passenger.

 

Identifying Potential Business Use Cases—Which Goods and Services can Actors Draw Upon?

This step is about finding potential business use cases. The rule—the more the merrier—applies here as well (in reasonable moderation). Potential business use cases can be found by answering the following questions:

  • Which goods or services are provided to and used by the customer?
  • Which goods or services are provided to and used by external partners?
  • Which goods and services that are provided by the business system involve suppliers (suppliers of goods and suppliers of services)?
  • What are the individual actors doing?
  • How and on what occasions does communication take place with other business systems or business partners?
  • Which events trigger what activities?

First considerations of our case study result in the following business use cases:

Figure 3.11 Potential business use cases

Initially, the business use cases can only be described in a concise and informal manner:

  • The check-in procedure includes submitting the ticket, baggage check-in, seat reservation, and issuing and handing over the boarding pass.
  • Passengers who only have hand luggage can use express check-in. No baggage check-in is performed.
  • During boarding, the boarding pass of the passenger is verified at the gate.
  • Automated check-in is conducted without the help of a check-in clerk, directly at a machine (screen). Baggage cannot be checked in.

 

Practical Tips

For us, in practice, the observation technique has proven effective for identifying business use cases. By observing people involved in the business processes, activity lists can be created. Following this, the activities can be grouped by events that lead to the first business use cases.

 

Connecting Business Use Cases—Who Can Make Use of What Goods and Services of the Business System?

By assigning business use cases to actors, a first draft of the use case diagram evolves (Figure 3.12). This is achieved by answering the following question:

  • Which customers or business partners have what functionalities available to them?
Figure 3.12 First draft of the use case diagram

With this first draft we obtain the basis from which we can further edit and refine the use case diagram.

The passenger can choose between a normal check-in, automated check-in, and express check-in. The passenger walks to the gate and presents his or her boarding pass. The check-in representative can perform a regular check-in, but is not able to perform express check-in and automated check-in.

 

Describing Actors—Who or What do the Actors Represent?

An actor in a diagram has to be named in a way that clarifies the role that is represented. Here, it is of utter importance that the terminology of the domain area, meaning a business-oriented term, is used. In addition to the name, an actor can be further defined with a description. The question to this end is:

  • How can an actor be described further? For instance, this description can include an area of responsibility, requirements from the system, or a formal definition of his, her, or its role. Don’t be afraid to add job descriptions or organizational profiles (for example of a catering company)—even if these are not represented in UML.

 

Searching for More Business Use Cases—What else Needs to be Done?

Once you have found several business use cases, they can be used as starting points for further questions. Starting from a particular business use case, the following questions can be asked:

  • Is there anything that has to be done at some point beforehand, prior to accessing a particular functionality?
  • Is there anything that has to be done at some point afterwards, after performing a particular business use case?
  • Is there anything that needs to be done if nobody performs a particular business use case?

In doing so, it is important to consider the proper business system. Many of the events that occur before or after a business use case take place outside the business system under consideration. In our case study, for instance, booking the flight or getting to the airport does not belong to the system being considered.

If we take a closer look, we notice that a passenger often travels with luggage, which he or she checks in. Baggage transportation is responsible for loading luggage into the airplane. Baggage transportation is carried out by an independent organization, known as a handling agent. Consequently, it is considered an actor, more specifically, an outside service provider. It does not matter for our diagram that individual employees of the partner enterprise perform these tasks.

Ten minutes before a flight leaves, baggage transportation requests a passenger list from passenger services, which includes every passenger who checked in, but did not board the airplane. On the basis of this list all affected luggage will be unloaded again from the airplane. If the flight is an international flight, the customs authorities of the country in which the destination airport is located also request a passenger list.

This results in two new actors: baggage transportation and the customs authorities at the destination airport (Figure 3.13):

Figure 3.13 Extended use case diagram

 

Editing Business Use Cases—What actually has to be Included in a Business Use Case?

Without a doubt, it is difficult to find the right amount of detail in the modeling of business systems. If almost all the activities of an actor in a business use case are combined, the use case diagram will lose practically all of its significance. If the activities are itemized too thoroughly, the use case diagram gets too complex and contains too many activities with interrelationships that are hardly recognizable.

Fortunately, some criteria will help you determine the optimal scope of a business use case. For this purpose, ask yourself the following questions:

  • Does the business use case consist of a behaviourally related sequence of interactions that belong together (an interaction sequence)? Items that are included in a business use case have to be directly related. Issuing a boarding pass and searching for lost luggage are not related at all. Business use cases that violate this criterion have to be divided. This prevents the occurrence of oversized business use cases.
  • How many actors are involved in a business use case? Business use cases that have too many actors have to be divided. This also prevents oversized business use cases.
  • Does the business use case deliver tangible and relevant goods or services? A business use case is not supposed to describe incomplete steps, for example, counting pieces of luggage. Rather, at least in a regular case, it is supposed to produce a benefit that has meaning from a customer’s perspective. Business use cases that violate this criterion have to be combined with other business use cases. This way, undersized business use cases are prevented.
  • Is the business use case never performed alone, but always in a sequence in combination with other business use cases? A business use case is not supposed to describe goods and services that are only used in combination with other goods and services. Business use cases that violate this criterion, have to be combined with other business use cases. This also prevents undersized business use cases.
  • Is the business use case initiated by an actor? Business use cases that are not initiated by an actor are not use cases but internal activities that are depicted in the internal view of the business system.

A review of the existing business use cases on the basis of these questions can lead to the consolidation or division of business use cases.

 

Documenting Business Use Cases—What Happens in a Business Use Case?

To understand a business use case, the information from the use case diagram is not sufficient. The chain of interactions and of the various scenarios that are behind each business use case have to be described. This means that the goods and services that the business system provides have to be described, namely the chain of events from the perspective of the customer or business partner.

In addition to purely verbal description, documentation in activity diagrams and sequence diagrams has proven to be especially valuable. The construction of these diagram types will be treated in the following sections: Activity Diagrams, and High-Level Sequence Diagrams.

 

Modeling Relationships between Business Use Cases—What Activities are Conducted Repeatedly?

If you realize that certain parts of an interaction are the same in several business use cases, you can extract these similarities and combine them into their own business use case. This new business use case can be used in other business use cases with an include relationship.

In our case study, the business use case issuing boarding pass has not yet been assigned. We know that the boarding pass is generated and issued during check-in. At some point during the business use cases check-in, express check-in, and automated check-in, the boarding pass is issued (see Figure 3.14):

Figure 3.14 Extended use case diagram

 

Verifying the View—Is Everything Correct?

All diagrams and records have to be verified by the knowledge carriers. What we should ask the knowledge carriers for every diagram or view is:

  • Is everything that is contained in the diagram correct and complete?

Even if knowledge carriers can read and understand diagrams themselves (they can use the reading directions in this text), we should still read the diagrams to them. Only with this last step is the circle completed. This results in a verified view, which reflects a current shared understanding of business systems and business processes.

The completed use case diagram can be verified with the following checklist:

Checklist 3.2 Verifying Use Case Diagrams from the External View

  • Completeness: The use case diagram is complete if there are no further business use cases in the system. All goods and services that are available to customers and partners of the business system are depicted in the form of business use cases (if necessary, business use cases can be spread out into several diagrams).
  • Extent: All business use cases that are included in the use case diagram are real business use cases, meaning they meet the definition of a business use case.
  • Degree of detail: The degree of detail of the business use cases meets the following requirements: A business use case represents a behaviorally coherent interaction sequence. A business use case is initiated by an actor, and has only a few actors. A business use case represents a functionality that is tangible and that yields a relevant result.
  • Relationships between business use cases: Include relationships are applied properly.
  • Naming and describing: The names of business use cases describe the functionalities that the business system provides. The naming was done in accordance with the normal terminology of the business system.
  • Actors: The actors in the use case diagram represent roles taken up by outside persons, organizations, or other business systems during interactions.

 

Practical Tips

When using use case diagrams for modeling business systems and business processes, it is advisable to keep the level of abstraction low. For the comprehensibility of the diagrams and for communication between the involved parties, it is better to add redundancies than to abstract too much.

It is of fundamental importance that the terminology of the business processes or the organization is used, and that the descriptions of the business use cases are chosen in a way that can be understood intuitively.

Terminology from the field of Information Technology does not belong in use case diagrams on the business-process level. The mixing of terms from the business process and IT communities leads to poor results. In reality, we often encounter use cases that are already very close to IT on the business-process level, e.g., updating a customer index. This leads to confusion in two aspects:

  • Users—meaning people who are involved in business processes, and who are not familiar with IT terminology—do not understand the business use cases. Since business use cases describe the performance requirements for a business system, the business system and business processes cannot be understood, and therefore cannot be verified. In a project with poorly formulated business use cases, an IT department presented the business use cases to users for verification and received just one short answer: “Men throwing arrows?!”.
  • Technical details on the level of business use cases distract from the business-process specific requirements for a system.
 

Use Case Diagrams

Use case diagrams show business use cases, actors, and the relationships between them. The relationships between actors and business use cases state that an actor can use a certain functionality of the business system. You will not find any information about how or in what chronological sequence these services are rendered (Figure 3.7):

Figure 3.7 The elements of the use case diagram

We use the following elements in use case diagrams:

 

Actor

An actor represents a role that an outsider takes on when interacting with the business system. For instance, an actor can be a customer, a business partner, a supplier, or another business system.

Every actor has a name:

Instead of a stick figure, other symbols can be used as well, if they fit the characteristics of the actor and lead to practical, easy-to-read diagrams.

 

Association

An association is the relationship between an actor and a business use case. It indicates that an actor can use a certain functionality of the business system—the business use case:

Unfortunately, the association does not give any information about the way in which the functionality is used. If a business use case includes several actors, it is not apparent in the use case diagram if each actor can conduct the business use case alone, or if the actors conduct the business use case together. In fact, association only means that an actor is involved in the business use case.

 

Business Use Case

A business use case describes the interaction between an actor and a business system, meaning it describes the functionality of the business system that the actor utilizes:

A business use case is described from the actor’s perspective. Apart from the special use of the business use case as a use case within a business system, there is no difference between the business use case and a ‘normal’ use case.

 

Include Relationship

The include relationship is a relationship between two business use cases that signifies that the business use case on the side to which the arrow points is included in the use case on the other side of the arrow. This means that for one functionality that the business system provides, another functionality of the business system is accessed.

In this way, functionalities that are accessed repeatedly can be depicted as individual business use cases, which can be used in multiple ways:

At times, the direction of the arrow can be confusing; the relationship has to be read alongside the direction of the arrow (check-in includes issuing the boarding pass).

 

Subject

A subject describes a business system that has one or more business use cases attached to it. A subject is represented by a rectangle that surrounds attached business use cases and is tagged with a name:

Depicting the subject (and with it the system limits) is optional.

 

Reading Use Case Diagrams

Figure 3.8 illustrates a use case diagram with the actors: the passenger (1) and the check-in representative (2), as well as the business use cases check-in (3) and express check-in (4):

Figure 3.8 Use case diagram

Depending on what you are interested in, you would begin reading with an actor or with a business use case. Starting with the actor, passenger (1), we find the associations (lines) to the two business use cases, check-in (3) and express check-in (4). This means that people, who appear as passengers, can either go through check-in, or express check-in, which can be conducted without luggage.

That one of the two business use cases is below the other means nothing. A use case diagram does not document a meaningful order in which business use cases could be conducted. Of course, the order matters for the description and linking of business processes. This aspect is pictured in activity diagrams (see Activity Diagrams).

The actor check-in representative (2) also has an association to the business use case check-in (3). This means that not only the passenger, but also someone who represents him or her can check in. That the actor, passenger (1), also has an association to the use case check-in (3) means that the passenger and the check-in representative can both check-in. However, what the diagram does not show clearly is that it does not mean that they perform the check-in together. This fact can only be described in another diagram (see Activity Diagrams) or in the form of a comment that can contain informal text.

That the actor check-in representative (2) only has an association to the business use case check-in (3) means that at the UML Airport a representative of the passenger cannot perform an express check-in (4).

You can see that such a simple diagram can contain quite a lot of information. The business use case check-in (3) and the business use case express check-in (4) each have an include relationship with issuing boarding pass (5) Use case diagrams. Both use the business use case issuing boarding pass at some point in their own interaction. (Use cases cannot define when another use case is executed.) Sometime during check-in the boarding pass is issued and handed to the passenger or check-in representative. Figure 3.9 attempts to clarify this procedure once more:

Figure 3.9 The include relationship between use cases

The Elements of a View

The following types of UML diagrams represent the external view:

  • Usecase diagrams show actors, business use cases, and their relationships. Use case diagrams do not describe procedures. Alternative scenarios also remain hidden. These diagrams give a good overview of the functionality of a business system.
  • Activity diagrams describe procedures, in our case, the business processes of the business system. The subjects of these descriptions are interactions between actors and the business system, meaning the goods and services that are offered to customers and business partners. On the basis of activity diagrams, outsiders can identify how to interact with the business system. They are especially useful to illustrate sequences, alternatives, and parallel events. Activity diagrams can be created in various degrees of detail.
  • Sequence diagrams show the chronological chain of interactions. They do not depict every event with all its branches and parallelisms, but the information that is exchanged between the involved parties. These diagrams are a good basis for data and information exchange with partners and customers (Figure 3.6):
Figure 3.6 The external view

UML diagrams for the description of business use cases can be annotated with written descriptions and illustrative figures. Not every diagram has to be used in each case. Which diagram type should be used depends on which system characteristics need to be emphasized. In any case, we recommend creating use case diagrams, because this diagram type is well suited for communicating with system partners and domain experts about the basic functionality and the context of the system. High-level activity diagrams with a low degree of detail, which can include several use cases, are also well suited for this purpose.

When refining business use cases and identifying the various scenarios, it becomes necessary to describe the various activities with activity diagrams.

Sequence diagrams show the information exchange with partners and customers (see Modeling for System Integration). In our practical experience, sequence diagrams meet great acceptance in the field of business-process modeling. This is because they are easy to read and require only a few graphical elements. As long as some basic knowledge exists about the technical events, sequence diagrams are often more appropriate for an overview of the interactions of a business system than activity diagrams.

External View

What Benefit does a Business System Provide?

As a customer or business partner of an organization, you don’t care if transactions within an organization take place manually or are IT-based. You are also not interested in how many forms employees of the organization have to fill out, whether it is 2 or 20. Customers and business partners are merely interested in what kind of goods and services can be offered, and how they can make use of them. The customer view describes the interactions with external parties, such as customers and partners, and presents the business system as a black box.

Consider a business system, such as passenger services or an airport newsstand from the outside. Which output is of interest for customers and business partners? Is the output a service or material goods?

From the business administrative view, the goal of a business system is (profitable) output. Output can generally be divided into goods and services. The production of goods could be, for example, the production of boxes of the finest Swiss chocolates.

But how do we distinguish services? Services are intangible goods, such as reserving a seat or loading luggage into an airplane. Unlike material goods, services can’t be rendered unless suppliers and customers make contact. However, a service can involve material goods. If a box of Swiss chocolates is sold at our newsstand, this transaction is a service. We can see from this example that the transaction of material goods is treated as a service because it involves a customer.

Consequently, the supply of material goods and services is relevant for the external view. The external view does not describe how employees and IT systems provide goods and services, and how business processes are transacted within the business system. In the external view, only those activities that involve outsiders are of concern.

In our case study, it is important for a passenger to know that he or she can check in with a valid ticket at the check-in counter, and that he or she will subsequently receive a boarding pass. What employees and IT systems actually have to do in order for him or her to receive a boarding pass remains hidden from the passenger—and in most cases he or she does not want to know, anyway.

In practice, we have observed that the external view is difficult to represent, if the employees of an organization, who are located within the business system, develop the model. It is difficult for a person within a business system, who knows all the internal transactions, to reconstruct the view of the customer, which does not consider internal transactions at all. If external and internal views are mixed, they inhibit the clear view from the outside of a business system and its business processes. (Thus, user-unfriendly systems are created!) Therefore, consult unbiased staff members, who can put themselves in the outsider’s place more easily, for instance, employees of other divisions or external consultants.

Business Use Cases

Before we converge to the business usecases, we would like to take a look at the general definition of a use case in UML. A use case is the specification of a set of actions performed by a system, which yields an observable result that is typically of value for one or more actors or other stakeholders of the system (OMG: Unified Modeling Language: Superstructure, Version 2.0, Revised Final Adopted Specification, October 2004).

What is an observable, valuable result in a business system? This question—how to find use cases—has preoccupied analysts and designers since the first day the term was used. The use cases of our business system are the services of a business system that are offered to customers, business partners, or other business systems. In contrast to this, the functionality that exists within a business system, which is neither visible nor accessible to outsiders, represents an internal activity, meaning an internal business process.

On the level of the business model we use the term business use case instead of use case. The reason behind this differentiation is a clear separation and the elimination of mix-ups in the transition from the business system model to the IT system model. The business use case is reserved to the business system model. Beyond this, there are no differences between a business use case and a use case.

Business processes can be performed manually or be IT-assisted. Nowadays, entire business processes can be initiated and conducted completely without human help. Corresponding to this reality, business use cases can comprise manual tasks, as well as IT-assisted activities.

If we look at our Hanseatic merchant’s trading office, we find exclusively business use cases that are conducted manually. If a customer of the trading office orders Russian fur, the clerk uses pen and ink to enter the order into the order book. Thus, business use cases already existed in medieval times.

In our case study, manually conducted passenger services as well IT-assisted activities are performed. For example, the IT system of passenger services performs seat reservations for passengers, while an employee conducts the verification of the ticket manually.

A passenger who checks in at a machine does not even encounter a human being. The check-in machine performs the entire business use case.

Actors

Outside of the business system are, for instance, customers or business partners, who use the output of the business system under consideration. It’s not necessary that these outsiders know in detail how a business case is conducted. For our passengers, it is important to know that they can buy a bottle of whiskey in the duty-free shop. The bottle of whiskey is a material good that the duty-free shop provides; selling the bottle to the customer, on the other hand, is a service. The passenger does not care how the duty-free shop employee conducts the sale. These outsiders are called actors (see Figure 3.5):

Figure 3.5 Outsiders and staff members

A business use case is always initiated by an actor, meaning that a customer or business partner utilizes a service. Our passenger, who strolls through the duty-free shop, considers a Scottish Malt Whisky a cheap bargain, and decides to buy a bottle. This makes him the initiator of the sale. During the transaction of a business use case, actors are able to interact with the humans and IT systems within the business system that are responsible for the transaction. For example, our passenger has to hand over a certain amount of money, in order to receive the bottle of whiskey.

Activities that are initiated by employees or IT system within the business system are not business use cases of the external view, but are activities of the internal view and will be represented in the activity diagram or sequence diagram of the internal view.

As you can see, the actors of business systems can be humans, organizations, or IT systems. Even if organizations are represented as actors, as in the case of baggage transportation, we ultimately find people or IT systems behind the actors that initiate and handle cases. However, what are relevant for our models are the roles that are played. On the level of the business system model, it is not important if it is a person, an IT system, an organization, or a division of an organization, a machine, or any other system that takes up a certain role.

Take another look at our case study and try to locate all persons, organization units, and IT systems involved. Then, try to structure them according to the following criteria:

  • Which is an outsider (customer, business partner, etc.) and what output does this outsider use?
  • What persons are located within passenger services as employees, and what tasks do they perform?
  • Which IT systems are involved?
  • In order for a passenger to buy a bottle of whiskey duty-free, an employee of the duty-free shop has to check the boarding pass of the passenger, accept money, pack the bottle in a bag, and hand out a receipt. Which of these activities belong to the internal view, and which belong to the external view?