Chapter 4  Use Cases

What is a use case? According to Wikipedia - ‘A use case in software and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes "who" can do "what" with the system in question.’

In my opinion, that is a pretty good description of an Application Use Case (AUC). But there is another type of use case that requires clarification of that description; the Business Use Case (BUC):

The BUC is described in a technology-free terminology and describes a business process that is used by business actors (people or systems external to the business). The BUC describes a process that provides value to the ‘primary’ business actor, in terms of the business workers and their interactions with supporting actors.

In short; an AUC describes a user’s interaction with a system (notice that the ‘user’ may actually be another system), whereas a BUC describes a person’s interaction with the people in a business organization.

When writing a BUC I like to think of the business as being able to perform their job using the lowest technology available to them; in most cases this will simply be a pencil and paper. After all, if the business loses access to electricity, that should not necessarily prevent them doing their job, albeit inefficiently.

Another way to think of the business use case is to realize that when we write the BUC it is often with the intention of automating some part of the business process. At the time of writing the BUC, that process is performed manually. Once the business process becomes automated, we do not need to go back and alter the BUC in order to reflect that it is no longer manual. The BUC should still be valid, so long as we did not change the business process as a result of automating it.

[For the purposes of not repeating myself, unless otherwise stated, I am going to use the word 'system' to represent either the business or the application throughout this chapter. So, when you see 'system use case' for example, it means both BUC and AUC.]

4.1    Requirement Types

Before getting into the details of the different use case types, I should explain my philosophy on requirement types. When adopting a use case approach to software development, I keep the requirements at 2 levels; the business level and the application level. I do not think of one being more detailed than of the other, but simply that one is automation independent, the other is application specific. [In fact I prefer not to think of the business level requirements as requirements at all, but simply as a description of what the business does.]

You will also find in my work a Vision Document that describes the overall objective of a development effort. This document is at a higher level of abstraction than both the business and application requirements. Generally, I do not recommend creating requirements out of the vision document, but I can envision instances where it is necessary.

At the business level I have BUC requirements and business rules. Each step in the BUC becomes a requirement. Business rules encompass everything else that is not a step in the BUC. Business rules can be written in the step, but since a business rule may impact many steps across several BUCs, you will find yourself repeating parts of the requirement. Instead the business rule is created as a separate requirement and referenced from the appropriate steps.

Similarly, at the application level there are 2 types of requirement, the AUC step and the supplementary requirement. The supplementary requirement is a constraint upon the AUC and will often be derived from a business rule. Supplementary requirements are referenced from the steps that they impact.

Other works on requirements management will describe many other types of requirement. For example, Stakeholder Requests, Customer Requirements, Regulatory Requirements, Assumptions, Constraints, Non-Functional Requirements, Usability Requirements and so on. If it really is necessary to identify each of these types I would group them by type, but I consider these all to be types of supplementary requirement, business requirement or a part of the Vision document.

Keeping my requirement types down to a minimum keeps the process for managing requirements less complex.

In summary, a Vision defines the scope of the project (which maps to ->) business use cases that define the impacted areas of the business (which map to ->) application use cases that identify the applications that are impacted by the project. BUCs are constrained by Business Rules (BR) and AUCs are constrained by Supplementary Requirements (SR). This is as complicated as it needs to be for the majority of projects.

                                                                              Figure 1:    Requirement Type Relationships

[Notice that a BR and a SR must impact at least 1 BUC or AUC respectively. I can think of no reason for defining a constraint that has no impact on the functionality.]

4.2    A Short History of Use Cases

The use case was formulated by Ivar Jacobson in the 1960s. They were adopted by Rational in 1995. Use cases are introduced into the Unified Modeling Language (UML) and the UML is adopted by the OMG in 1997.

4.3    Typical Shared Components of a Use Case

The following information is typically common to both AUCs and BUCs.

4.3.1     Goals

Describes what it is that this use case trying to achieve. The goal is described in terms of the primary actor and explains what benefit the actor is acquiring as a result of the actions described in the use case.

4.3.2     Description

This is an overview of the use case. It is used to set the scope of the use case prior to the details being added.

4.3.3     Primary Actor

The primary actor is the role or system that is gaining benefit from the use case. Each use case has exactly one primary actor. If it is discovered that another role (or possibly application, in the case of the AUC), is gaining benefit from the same use case, then the actors are combined and described in terms of a single actor that fulfills both roles.

4.3.4     Secondary Actors

Use cases may have any number of secondary actors. Secondary actors are outside the control of the use case, and are interfaces to the use case that allow the use case to fulfill its purpose. Secondary actors may be roles or systems.

4.3.5     Preconditions

Use cases describe a series of actions that occur once a trigger has occurred while the system is in the use cases' initial state. The preconditions describe how the system under discussion reached that initial state. Often the precondition will be described in terms of the execution of another use case.

4.3.6     Postconditions

Postconditions are the state that the system may be in after the use case has finished executing. Note that there may be several different outcomes to a use case, but only one is the desired outcome, or postcondition.

4.3.7     Basic Workflow

The basic workflow describes a sequence of interactions between the use case and its actors that achieve the expected result, or postcondition. This is described in terms of steps. Steps are events recognized by the system, or actions that are performed by the system.

4.3.8     Alternate Workflows

If the use case deviates from the expected flow of actions, then these interactions are described with an alternate flow of events. An alternate flow of events always returns back to the basic workflow in order to achieve the expected postcondition.

4.3.9     Extension Workflows

Extension workflows describe an alternate flow of events that lead to an alternate postcondition. Generally, extension workflows describe a course of actions that result in an undesired postcondition, but they may also achieve the desired result and more.

4.3.10  Use Case Diagram

The use case diagram simply shows the use case as an oval connected to its actors with relationships.

4.3.11  Activity Diagram

The activity diagram is a graphical representation of the steps in the use case.

4.4    Information that is Specific to an AUC

An application use case describes the interaction between an application and its actors. As such there is only a single worker in the AUC; the application. Because of this, the steps of in the flow of an AUC must be externally visible to at least one actor of the AUC.[1]

The following are sections of an application use case that do not pertain to a business use case.

4.4.1     Supplementary Requirements

Supplementary requirements are generally applied to the whole application and as such reside in their own repository, but those that are specific to one use case may be listed with the use case.

4.4.2     Performance requirements

Performance requirements are a type of supplementary requirement. I list them in their own section because each interaction between the AUC and one of its actors has an implied performance requirement. These requirements may be listed as supplementary requirements in their own repository as requirements that apply to the whole application, or if the use case has unique timing constraints they are listed in the use case document.

4.4.3     Interface Requirements

These are another type of supplementary requirement that define interfaces between systems. These will generally be documented in an interface specification and referenced from within the use case specification.

4.5    Information that is Specific to a BUC

The steps of a business use case describe the interactions between a worker of the BUC and either an actor or another worker. This enforces the idea that for every action in the use case someone is getting benfit from that action. (I.e. we are not doing things without understanding why we are doing them.)

The following are sections of a business use case that are not applicable to an application use case.

4.5.1     Workers

An AUC is executed by a single application, but the steps in a BUC may be performed by several different roles. The roles that execute those steps are the 'workers' within the use case.

4.5.2     Business Rules

These are restrictions on the execution of the BUC steps. These may be timing, data, regulatory requirements, or anything that imposes a constraint on the business.

4.5.3     Artifacts

These are the objects within the business that are impacted by the BUC. These could be things such as customer records, food (if describing a restaurant) or vehicle parts for a repair shop.

4.5.4     Automation

Often the purpose of detailing a BUC is with the intent of automating all or part of the process. The automated steps are called out within the BUC.

4.6    Guidelines for Detailing Use Cases

I would like to call them rules because unless it absolutely does not make sense, I adhere to the following guidelines when writing my use cases. The objective is to maintain a consistent look and feel to the use cases.

·         The preconditions are the state of the system as a result of another system use case executing. If it is not necessary for another use case to have executed (not necessarily to completion), prior to this use case starting then the precondition is 'N/A' (or 'None').

·         For consistency I always write actor events and system actions as steps on separate lines. (I have tried writing the event and the system action on the same line, giving them a single step number, but prefer keeping the steps short and to the point. It also makes the use cases easier to manipulate.)

·         An alternate workflow always returns to the basic workflow. Even if the next step of the alternate flow is 'the use case ends', I will write it as 'the use case returns to step x' where 'x' is the last step number in the basic workflow.

·         An extension workflow always terminates with an alternate postcondition to that in the basic workflow. As such it will not return to the basic workflow.

·         I like to start my use cases with the words 'the use case starts when …' and end every workflow with the words 'the use case ends'.

·         Write the basic workflow in a purely positive light. Do not write something along the lines of 'if something goes wrong then goto step x else do something'. Instead write it as 'nothing goes wrong and the system does something'. Then in the alternative start with the words 'at step y, something went wrong and the system does some alternative action'. What we are doing is referencing the basic workflow from the alternative workflow, but not the other way round. We only need the one cross-reference.

I do not make any specific recommendations for the format of the text that makes up the steps of the use case, nor do I have specific recommendations for numbering schemes. My only recommendation is keep it simple (KISS) and be consistent.

Also, I do not have any recommendations for documenting steps that are indeterminate; i.e. when 2 steps may run in parallel. I have tried combining them into a single sentence and applying the same number to them or alternatively listing the steps without numbers. Neither scheme do I find satisfactory.

4.7    Modeling Use Cases

Now that we have an understanding of the components of use cases the following sections will describe how to model them with UML. As with everything else, I want to use the simplest notation that does the job and has only one interpretation. UML allows several ways to describe the same concept. That is why the notation you see in the following sections is a subset of UML and does not grasp the richness of the whole language.

4.7.1     Notation for Use Case Diagrams

Use case diagrams are relatively simple diagrams, comprising use cases,  actors and relationships between them.

4.7.1.1     Use Case

 - The symbol for a use case is an oval. If the oval has a line through it then it represents a BUC. A use case has exactly 1 primary actor and 0 or more secondary actors. A use case may be connected to 0 or more use case fragments via ‘extends’ or ‘includes’ relationships. Label the use case such that it describes doing something to something.

4.7.1.2     Actor

 - The symbol for an actor is a stick figure. If the stick figure has a line through its head it represents a business actor. An actor connects to 1 or more use cases. If the actor represents a person label it with the role that the person plays in relation to the use case. If the actor represents a system label it with the name of the system.

4.7.1.3     Relationship

 - The relationship is represented by a line with or without an arrowhead at one end. The relationship connects an actor to a use case or a use case fragment to a use case. The arrowhead is used to identify the primary actor of a use case or indicate in which direction an ‘extends’ or ‘includes’ relationship is operating. [An extending use case relationship is directed towards the main use case, whereas an including use case relationship is directed away from the main use case.] The relationship is unlabeled or the label indicates whether it is an ‘includes’ or an ‘extends’ relationship.

4.7.2     Examples of the Rules for Drawing Use Case Diagrams

Below is a business use case diagram for a restaurant. It shows use cases that describe a customer having a meal at a restaurant, and the chef receiving food supplies for the restaurant. The primary actor (receiving the benefit) of the 'Eat food' use case is the customer. The primary actor of the 'Purchase Food Supplies' use case is the chef. Note that in neither case do we get any idea who the workers are that are performing the activities within the use case.

                                                                                Figure 2:    Restaurant Use Case Diagram

Both use cases have exactly 1 primary actor. How do we know from this diagram? Because the primary actor is connected to the use case via a relationship with an arrowhead at the use case end of the line.

The 'Purchase Food Supplies' use case has a secondary actor. We know that 'Food Store' is a secondary actor because the line representing the relationship between it and the use case has no arrowhead.

The notation is identical for both the BUC diagram and the AUC diagram. The only difference is the symbols for the actor and the use case have a line through them.[2]

When drawing use case diagrams I recommend that you keep the component coupling down to a minimum. That is, do not link one actor symbol to several use cases. Instead duplicate the actor symbol for each use case that it connects to.  So if I added another use case named 'Handle Customer Complaint', my diagram now looks like the following.

                                                                        Figure 3:    Many Use Cases With The Same Actor

The reason for this is because as your use case model grows, you will be moving use cases from one diagram to another. If an actor symbol is connected to several use cases the action to move that use case to another diagram, involves breaking the connection to the actor[3], cutting the use case from the diagram, pasting it to the other diagram and reconnecting the use case to its actors. The way I have drawn my use cases, you simply select the use case plus all its actors, cut and paste to the other diagram. [Also, it is really easy to move them around the diagram without getting your lines crossed.]

 [What about the 'duplication' issue, I hear you ask? It is not really duplication, because you are only copying the symbol, not the actor. Changing attributes of the actor causes those changes to be reflected in every instance, so you are only making the change once.]

I recommend a similar layout when connecting 'included' and 'extending' use case fragments[4]. Again you may place these as many times as you like on as many diagrams as you like without any duplication of work. The notation for 'extends' and 'includes'[5] relationships is exactly as it comes out of the box.

                                                                     Figure 4:    Visio extends and includes Relationships

4.7.2.1     The Actors Diagram

One final rule that needs clarification. That is the rule that a use case may only have a single primary actor. What if I have two roles that derive the same benefit from the BUC, or two actors that may perform same the system functionality that is captured by an AUC? [An example might be both an Administrator and a Project Manager can maintain user accounts.] We create a role that describes the appropriate action being performed by that use case. Connect an actor with that role name to the use case with a relationship indicating that this is the primary actor. Every role that would be a primary actor becomes a subclass of this generalized actor. This is described by connecting them to the generalized actor with a generalization relationship on an actors diagram. [In fact there is no reason why you could not use an actors diagram to describe other relationships between your actors; if you so wish and your tool permits it.] Below is an example of how to describe two primary actors that both manage user accounts.

                                                       Figure 5:    Actors Diagram[6] and Accompanying Use Case Diagram

Both the Administrator role and the Manager role are types of User Account Manager. The User Account Manager becomes the primary actor of the use case.

That's it for Use Case diagrams! Activity diagram notation is a little more complicated.

4.7.3     Notation for Use Case Activity Diagrams

The notation for UML 2.x activity diagrams includes symbols for; Partition, Initial Node, Final Node, Action, Accept Event, Send Signal, Structured Activity, Decision, Merge, Fork, Join,  Control Node, Object Node, Central Buffer, Data Store, Activity Parameter, Input Pin, Output Pin, Value Pin, Object Flow, Control Flow and just a plain Flow.

I am not going to pretend to understand the semantics behind most those elements. Instead I will choose the minimum set of elements that are needed to model the details of a use case and define consistent meanings for them when used for use case modeling. Each of the following subsections contain the symbol used[7] to represent the element, a description of its purpose on an activity diagram, its label, the rules of its use and how it is related to the text of a use case.

[The notation in both BUC and SUC activity diagrams is identical.]

4.7.3.1     Event Flow

 - Otherwise known as a control flow in UML or a transition in Visio. The event flow represents something that has occurred; for example, the triggering event of the use case. An event flow is directed and the direction is represented by an arrowhead at one end of the flow. The event flow may only be traversed along the direction indicated by the arrowhead. An event flow connects any two other symbols, where the rules for those elements allow them to be connected. An event flow may not connect at both ends to the same element. The event flow represents one or more externally visible event(s) between the AUC and one of its actors or an event between actors or workers in a BUC. Label an event in past tense, i.e. <something happened> or you may leave it blank, when:

·         There was no action between it and the previous event, and the previous event has a label, The event takes the name of the previous event.

·         There is no action between it and subsequent events that all have labels. All of the subsequent events are captured by this flow.

 [Generally the event flow will represent one or more input events to the use case from an actor or worker, but these rules allow outout events to be represented by event flows also.] The event  flow represents a step in the workflow text of the use case.

4.7.3.2     Initial Node State

 - This is the starting point when executing the use case. There is exactly 1 initial node on a use case activity diagram. There is exactly 1 use case triggering event exiting from this node. There are no events entering this node. The initial node represents the preconditions of the use case. Label the initial node with the name(s) of the precondition(s) of the use case.

4.7.3.3     Action

 - The action describes activity that is performed by the system in response to an event occurring. An action has exactly one event entering, and one event exiting it. The action represents a step in the workflow text of the use case. Label the action with text that describes an activity in the present tense. I.e. <doing something>.

4.7.3.4     Decision

 - The decision acts very much like the decision in a flowchart. Its label always asks a question. It has a single event entering, and several events exiting it. The labels[8] on the events exiting the decision must equal all possible answers to the question being asked by the decision. In addition, the answers to the question may not overlap [only one path may be taken upon exiting the decision]. For this reason, I try to limit my decisions to responses of simple 'Yes' or 'No' answers. In this manner I do not need to be concerned whether there is overlap or missing values in the answers. The decision is a representation of a branch from the current flow to an alternate or extension flow in the text of the use case. For every decision leading to an alternate flow there must be an equivalent following merge.

4.7.3.5     Merge

 - The merge is the opposite of a decision. It has several events entering, and only a single event exiting. For every merge in the diagram there must be an equivalent decision. The merge allows an alternative path to rejoin the main flow. As such it does not require a label. It represents the last line of an alternate flow, which contains the text 'the use case continues from step ..'.

4.7.3.6     Fork

 - A fork allows the current flow to be split into several flows running in parallel. A fork is used when the sequence of steps is indeterminate (i.e. there are no requirements around ordering). A fork has a single event entering, and several events exiting it. For every fork in the diagram there must be an equivalent following join. I have never found a satisfactory method of representing the flows exiting a fork in a textual use case. Forks do not require labels.

4.7.3.7     Join

 - A join is the opposite of a fork. It allows several parallel paths to merge into a single flow. It has several events entering and a single event exiting it. For every join in the diagram there must be an equivalent preceding fork. Joins do not require labels.

4.7.3.8     Activity Final State

 - The activity final state terminates a use case flow. This could be the main flow or an extending flow. It has exactly one event entering it. It represents a postcondition of the use case and the event entering it represents the text 'the use case ends'. Label the final state with the name of the postcondition that it represents.

4.7.3.9     Object Flow

 - The object flow connects a single action to a single object node. The arrowhead indicates whether the object is an input to the action or being manipulated by the action. There is no equivalent in the textual workflow of the use case. Object flows are not labeled.

4.7.3.10  Object Node

 - The object node represents a thing (artifact) that is being manipulated or used by the action. If the object flow that is connecting the object to the action is in the direction of the object the artifact is being manipulated (produced), otherwise it is being used (consumed). The object node represents the artifacts in the text of the use case. The object node takes the name of the object, its class and the state that the object is in, after it has been manipulated, or when is used, by the action it connects to.

4.7.3.11  Activity

 - The activity element does not come with Visio 2007,[9] but it is a part of UML 2. I am using this to represent a sequence of actions. For example, if you have a use case fragment included in the steps of your use case, then this symbol may be used to represent those included steps and the use case fragment is referenced from within the activity. Label the activity with the name of the use case fragment that it represents.

4.7.4     Examples of Using the Rules for Activity Diagrams

As you may have noticed, these rules are very restrictive. If you find them too restrictive for your purposes, take what you want and ignore the others. I use these rules to help me verify that my use case is correct and complete. It is a good idea to understand what it is that the guidelines are trying achieve prior to documenting them.

Using these rules ensures that both the textual version and the activity diagram should have the same number of alternate paths, extensions and postconditions. For every decision in the activity diagram there should be an equivalent alternate or extension flow. Every action and event should map to 1 or more steps in the use case. (I stop short of insisting that the number of steps are equal, but if you really want accuracy there is no reason why you could not go back and update the text in the steps of the use case to reflect the events and actions in the activity diagram.)

If you cannot model every path through your use case on a single activity diagram within your guidelines, then either your guidelines are too restrictive or your use case is incorrect. Within these guidelines I believe that I can model any valid textual use case.

4.7.4.1     Two Events Exiting from an Action

You might ask; why can I not have two events exiting an action? As shown below:

                                                                                  Figure 6:    Action With 2 exiting events

My response is a question to you; do the events represent a decision being made, or are they parallel flows as the result of a fork?

Instead of being open to interpretation, I want my diagram to explicitly state what action is occurring (without having to look at the details of the action). If I want a decision to occur as a result of the action I will indicate that in the diagram.

                                                                                 Figure 7:    Representation of a Decision

Or if the action is followed by two parallel flows;

                                                                Figure 8:    Representation of a Fork With 2 Parallel Flows

But what if the flow exiting the action represents several unrelated asynchronous events? Then I do not label the flow exiting the action. (This situation will only occur if the flow is input to a decision.) See the diagram below for an example:

                                                                     Figure 9:    Unrelated Events Exiting From An Action

In this Figure 8: (which is a situation that I came across in the example at the end of this chapter[10]), while waiting for the customer to make an entry to the system, it is possible for an event to occur elsewhere that causes the system to reset the user interface. (This might be because the customer took too long to make a change.) Both events are shown as exiting the action by the unlabeled flow, but then the decision will determine which of the 2 events occurred.

4.7.4.2     Several Events from the Initial state

Similarly, the same rules apply to the initial state.

Consider that the use case describes two initial paths depending upon which command is entered. You might want to represent a basic flow and alternate flow as follows:

                                                                                 Figure 10:   Initial State With Two Events

If the two flows represent alternative paths exiting the initial state:

                                                                                 Figure 11:   Merge From The Initial State

Then we have just broken the rule that every merge must follow a previous decision.

Similarly, if the two flows represent parallel actions being initiated from the trigger of the initial state:

                                                                              Figure 12:   Initial State With Parallel Events

Again, it may appear obvious that these are parallel activities, but the rule that every join must have a preceding fork is broken.

This is how I would represent Figure 10: and Figure 11: respectively.

                                                   Figure 13:   Correct Representation of Two Events from the Initial State

Another reason why I impose rules that are unnecessary and require the author to add extra elements to the diagram, is because I am enforcing the rule, that if there are two ways of doing something, pick one and stick with it. The representation in Figure 12: is necessary. The notation in Figure 10: and Figure 11: is not.

4.7.4.3     Merging

We could represent a merge by simply having the two event flows enter the same action, as shown below:

                                                                               Figure 14:     Merging Flows into an Action

But what about the case where the two flows meet at a fork? A fork only allows one event to enter. We need to represent this scenario with the diagram below:

                                                                           Figure 15:   Correct Representation of a Merge

Again we have two ways to represent the same thing, but only Figure 14: works in every instance. So pick the notation in Figure 14: and disallow any alternatives.

4.7.4.4     Forks and Joins

All forks must have a following join that merges all paths back into a single flow of events. This is perhaps the toughest rule to justify. I have read rules concerning joins that state, the join can be exited when all paths entering the join have completed. This statement would make the following diagram correct:

                                                                                  Figure 16:     A Fork flow without a Join

But the following structure would also be correct:

                                                                                        Figure 17:     Forks without a Join

I don’t get it! The forked flow to the left has joined back to the basic flow. The flow to the right never joins back to the basic flow, but is still running in parallel to the basic flow. If it’s not the basic flow and it’s not an alternate flow (because an alternate flow branches from a decision) then what is it? Even if you could come up with an elaborate description of what is happening, imagine the complicated scenarios that one could create using forks whose flows do not subsequently join. Use cases are supposed to be simple animals.

Again, invoking the rule that if there is two ways to do something pick one and stick with it, I insist that every forked flow merges back to the flow that it forked from via a join. Figure 15: now looks like this:

                                                                                        Figure 18:   Paired Fork and Join

Terminating a flow with a forked execution might on the face of it appear to be a way to allow the basic flow to continue while a parallel flow is executing. If we put a join at the end of both flows, as shown in Figure 15: neither flow can continue past the join until the other flow has finished (also leads to potential deadlock). If you wish the basic flow to continue through to termination without the parallel flow holding up execution, simply add the join just prior to the final state. See below:

                                                                                        Figure 19:   Nested Parallel Flows

Now the flow to the left may continue through to completion without having to wait for the parallel flow on the right. [Completion is the join; remember the flow entering the final node simply states, ‘the use case ends’.] Similarly the right hand flow does not need to wait for the left flow to complete.

4.7.4.5     Objects

Here is a good method for checking that every step in your use case is performing value for the system. Ensure that each action manipulates some artifact and that the artifact is used by an actor or worker of the use case. Connect at least one object to each action using an outgoing (arrowhead connected to the object) object flow to indicate what artifacts are being manipulated by the action. Then add objects to represent artifacts that are being consumed by the action. Connect these to the action with an incoming (arrowhead connected to the action) object flow. If you cannot discover an artifact that the action outputs to, then consider revising the steps related to that action in the use case.

[Addendum: There may be waiting steps in your use case, i.e. steps that have no activity, but simply wait for an event to occur. These steps may not produce any output, but then neither do they have an associated worker.]

4.7.5     Summary of Activity Diagram Rules

Sticking to these (or whatever equivalent guidelines you use), greatly helps to check the use case for, consistency (have we captured all of the alternate paths?), correctness (are the steps in the right order?) and completeness (are we missing any steps?).

If you do deviate from the guidelines (and I frequently deviate from my own guidelines) I recommend adding a note explaining why. In general, if you find that is more than 1 way of modeling, I recommend explaining why you choose your way over the others. But overall I suggest eliminating all but 1 of those ways; if nothing else it saves on notes.

4.7.6     Addendum

It is possible for the decision and merge to be the same symbol on the diagram. Consider the following example:

                                                                              Figure 20:   Combined Decision and Merge

A command is entered by the primary actor. The system executes the command and waits for the primary actor to enter another command. If the primary actor enters the ‘Exit’ command at any time the use case ends.

We could have drawn the merge symbol above the decision, but in this example it is unnecessary and the 2 symbols are combined.

4.8    Example Use Cases

Let’s see the whole procedure in action. I am going to describe an example vision for a restaurant.[11] The vision statement goes something along the lines of: ‘As a restaurant owner I wish to reduce the wait staff to a minimum. They are expensive, they eat the food, they break the crockery and they steal things when my back is turned. To this end I wish to replace the waiters with an automated menu system, which allows customers to:

·         Offer the customer a greeting.

·         Display the menu for today (it will change regularly, but remains constant every day).

·         Select items from the menu for the kitchen to prepare.

·         Inform the kitchen of each table’s order.

·         Inform the customer when their meal is ready and where to pick it up.

·         Allow the customer to add to their order at any time.

·         Allow the customer to pay for their order (and leave a tip if they so wish).

·         Give the customer a receipt and offer them a farewell message.’

4.8.1     Business Use Case

A business use case for the Automated Menu System project may look like this:

4.8.1.1     Name

Serve Customer Business Use Case

4.8.1.2     Description

The referenced document contains a great storyboard sketch of the BUC. It describes a person entering a restaurant, being assigned a table, having their coat checked, being shown to their table, ordering lunch, being delivered food, paying the bill and retrieving their coat.

4.8.1.3     Objectives of the business use case.

To provide a satisfactory meal for a customer in return for payment.

4.8.1.4     Performance Goals

At peak time (lunch hour) to have customers in and out of the restaurant within 1 minute for every $ they spend. For example, a customer whose bill comes to $30 will be in the restaurant for ½ an hour.

4.8.1.5     Primary Actor

Customer – the person being served by the restaurant.

4.8.1.6     Secondary Actors

None.

4.8.1.7     Business Workers

Normally I would define the actors and workers in a project repository and not duplicate their definitions in the use case. For this example I have pulled their definition into the use case text.

Head Waiter – Arranges for the customer to be assigned to a table.

Cloakroom Attendant – Manages the customer’s non-essential belongings while they are seated.

Table Waiter – Takes the customer's order and delivers their food.

Cashier – Takes the customer's payment.

Cook – Prepares the food.

4.8.1.8     Preconditions

The restaurant is open to customers.

4.8.1.9     Successful Postcondition

The restaurant has received the customer's payment.

4.8.1.10  Alternative Postconditions

The customer leaves without paying.

4.8.1.11  Workflow

The following workflows describe the different paths through the use case. The Basic Workflow describes the expected or normal flow of events.

4.8.1.12  Basic Workflow

1.      The use case starts when, the customer enters the restaurant.

2.      The headwaiter greets the customer.

3.      The customer requests a table.

4.      The head waiter arranges for seating for the customer.

5.      Seating is arranged and the head waiter asks if the customer would like to check their coat.

6.      The customer hands their belongings to the cloakroom attendant.

7.      The cloakroom attendant takes the customers belongings and hands the customer a token.

8.      The head waiter shows the customer to their table.

9.      The head waiter hands the customer a menu.

10.  The table waiter is informed they have a new customer.

11.  The table waiter asks the customer for their order. (They are probably going to list recommendations and specials that are not on the menu first, but let's keep it simple.)

12.  The customer gives their meal order to the table waiter.

13.   The table waiter takes the customer order to the kitchen.

14.   The cook takes the order and prepares the meal.

15.   The meal is ready and the table waiter is informed.

16.  The table waiter delivers the meal to the customer's table.

17.  The customer finishes with their meal and asks the waiter for the bill. (Again, keeping it simple by leaving out the waiter asking if the customer would like anything else.)

18.  The table waiter gives the customer the bill.

19.  The customer makes a payment to the cashier.

20.  The cashier gives the customer a receipt.

21.  The customer gives the cloakroom attendant back their token.

22.  The cloakroom attendant returns the customer belongings.

23.  The table waiter cleans the table in preparation for the next customer.

24.  The table is prepared and the table waiter informs the head waiter that the table is free. (This and the previous step are performed in parallel to steps 19, 20, 21 and 22, demonstrating why the text method of detailing use cases is awkward.)

25.  The use case ends.

4.8.1.13  Alternative Workflows

A.1   The customer has nothing to checkin.

26.  At step 5 the customer has nothing to checkin to the cloakroom and the use case continues from step 8.

27.  At step 21 the customer has nothing to retrieve from the cloakroom and the use case continues from step 23.

28.  At step 31 the customer has nothing to retrieve from the cloakroom and the use case continues from step 34.

A.2   The customer finds a fly in their soup

29.  At step 17 the customer is not satisfied with their meal.

30.  The waiter fetches the head waiter to the table.

31.  The head waiter agrees to not give the customer a bill.

32.  The customer gives the cloakroom attendant back their token.

33.  The cloakroom attendant returns the customer belongings.

34.  The table is cleaned in preparation for the next customer.

35.  The table is prepared and the table waitier informs the head waiter that the table is free.

36.  The use case ends.

Some points of note:

·         Steps 21, 22 and 23 are duplicated in the extension flow. In order to avoid duplication we can pull out these steps into a use case fragment and ‘include’ the fragment in this use case.

·         Steps 5, 17, 21 and 31 all contain branches to alternate workflows, yet no mention is made of this fact in the basic workflow. Keep the basic path ‘happy’ by only describing the expected steps of the use case. Alternate workflows will capture to unexpected steps.

4.8.1.14  Business Rules

Dress Code

37.  To use the restaurant customers must be attired according to the restaurant’s dress code. [Impacts step 2]

Seating Rules

38.  Customers will be seated on a first come first served basis, unless every restaurant table is occupied, in which case the largest party that may be seated at a free table will be seated first. [Impacts step 4]

4.8.2     The BUC Activity Diagram

The complete diagram encompasses more than a full page, so I will only display the more interesting activities.

I believe that the diagrams in Figure 19: and Figure 22: capture all of the above rules and a few additional features too. These are explained in the following notes.

                                                                       Figure 21:   Serve Customer BUC Activity Diagram

Note 1 – This is the initial state ‘Restaurant Is Open’ (to customers) and the triggering event exiting this state. The reason why the arrow is bent is because if had drawn it straight some of the text becomes unreadable.

Note 2 – Have you noticed that there is one common activity diagram element that I missed from the list in Section 1.7.2? Swimlanes! I despise swimlanes for several reasons including;

·         They waste whitespace on my diagram,

·         They restrict the flexibility of the layout of my diagram,

·         And, I cannot find a modeling tool that has successfully implemented swimlanes in such a manner, that when I edit my activity diagram the swimlanes do not cause the layout of the diagram to become totally destroyed.

[Rant over.]

There are many ways that you may indicate the workers of each action in your activity diagram, without the use of swimlanes. These include adding stereotypes to the actions. (I.e. adding a waiter stereotype would indicate that this is a ‘waiter’ type of action.) In Figure 19: I have used color to indicate which worker performs what action.

Note 3 – Notice that every action includes an output flow to an object. You might argue that a ‘Greeting’ is not an artifact, but when we start modeling the application we may discover that this was a useful object to capture.

Note 4 – The seating chart is changed by the head waiter and as a result the table object has its status changed from ‘Open’ to ‘Reserved’.

Note 5 – This is an example of an alternate workflow. Notice that the flow begins with a decision and ends with a merge. The decision asks the question, does the customer wish to make use of the cloakroom?

Note 6 – An example of an activity. In this instance the activity is being used to indicate that there are a lot of missing actions here, and not that they are captured by a use case fragment.

Note 7 – This is an example of an extended flow. We know that it is an extension to the use case, because it does not return to the basic flow.

Note 8 – This is an example of a fork. Notice how more eloquent this notation is than trying to describe this activity with text.

Note 9 – Retrieve Coat and Clean Table are use case fragments that are ‘included’ in the flow of this use case.

Note 10 – A non-successful postcondition.

Note 11 – This is the successful postcondition.

Notice how the basic flow runs vertically down the page. Alternate and extended flows are drawn off to the left and right of the basic flow. (Another reason not to use swimlanes.)

The following objects, and their definitions, have been identified as being impacted by the Serve Customer BUC.

·         Bill – A request for the customer to pay the cashier the amount indicated.

·         Cloakroom Request – An inquiry as to whether the customer wishes to make use of the restaurant’s cloakroom to stow their belongings.

·         Customer Belongings – That are exchanged for a cloakroom token.

·         Kitchen – Where food is prepared.

·         Meal – Food served to a single customer at a single seating.

·         Menu – What the customer uses to order food.

·         Order – A combination of items from the menu for a single table.

·         Payment – Money handed to the cashier.

·         Restaurant – Where food is served to customers.

·         Seating Chart – Displays which tables are reserved and which are free, as well as their size and location in the restaurant.

·         Table – Reserved for customers in order that they may be served food.

·         Token – A unique identifier for customer items in the cloakroom.

Putting this in a diagrammatic form we see these objects described in Figure 20:

                                                                         Figure 22:   Serve Customer BUC Class Diagram

This is the complete BUC. There is more activity in the business modeling process, including determining which steps in the BUC are to be automated. This process is not necessarily the responsibility of the BA. The appointed systems analysts, lead architects and the business SMEs need to also be involved. Therefore, I consider those actions as falling on the interface between the Business Modeling and the Requirements disciplines.

In the next chapter I will describe a process for moving from the above BUC to AUCs. For now I will just present an example of a potential AUC for the Automate Restaurant project.

4.8.3     Example Application Use Case

[Since we are no longer discussing the ‘business’, for the purposes of the AUC, the word ‘system’ is going to mean the ‘hardware and software that is used to fulfill the requirements of the AUC’.]

For iteration 1 of the Elaboration phase (that’s the 2^nd of 4 phases in RUP terminology, Inception, Elaboration, Construction and Transition), it has been decided that the ordering food from the menu steps will be completely automated by the Menu Ordering System. Here is the goal of the AUC, followed by the AUC itself:

4.8.3.1     Goals

To allow a customer to order any item from the menu and when it arrives at a pickup area, inform the customer where they may retrieve their meal from.

4.8.3.2     Name

Order Food Application Use Case

4.8.3.3     Description

The following description forms an overview of the detail in the steps of the basic flow of the AUC.

The customer arrives at the table. The system greets the customer and prompts the customer to display the menu. When prompted the system displays the first page of the menu. The customer may browse every page of the menu using the interface controls. (The menu items and menu  size could change daily.) The customer will select the items for their meal. Once they have finished selecting the customer orders their meal. The order will be processed by the kitchen and once prepared the customer is informed how to retrieve their meal from the service area. Once the meal is retrieved the system will stop prompting the customer to retrieve it.

4.8.3.4     Usage

Usage describes the expected average use of the system and the peak use. It is sometimes useful to know when the peak usage occurs so that the system does not schedule any unnecessary maintenance activity or batch jobs at that time.

Assume a maximum usage of 15 minutes out of every 30 minutes per table with 105 tables in the restaurant, from 12noon-1pm. Normal usage is assumed to be 10 minutes every hour per table.

4.8.3.5     Primary Actor

The actors are defined in a repository somewhere. We do not repeat their definitions in the use case.

Customer.

4.8.3.6     Supporting Actors

The supporting (or secondary actors) are all the other roles or systems that are interfacing with the menu ordering system during this AUC.

Kitchen Staff, Stock Taking System, Administrator, Meal Sensor.

4.8.3.7     Preconditions

The precursor use case to this AUC, is itself, or any other use case that displays the welcome screen.

The welcome screen is displayed.

4.8.3.8     Successful Postcondition

How does the application know that the customer has picked up their meal? I am assuming that there is some sort of sensor that can detect when there is a meal in the serving area. This sensor is outside of our application, but it will inform our system when it changes state, (either ‘Meal’ or ‘No Meal’).

Customer has picked up their meal from the serving area.

4.8.3.9     Alternate Postcondition

This postcondition could happen for any number of reasons (the customer leaves the restaurant, the customer has a heart-attack, the customer is locked in the washroom, etc) none of which are relevant to this AUC.

The customer does not pick up their meal within 10 minutes of it being delivered to the pickup area.

4.8.3.10  Basic Flow

Note that the steps in the use case are written as dryly as possible, using as few different words as possible, while being grammatically correct and containing every detail that is required to implement the use case. As with everything else, if you can use 2 words in the steps of the use case that have the same meaning, pick one and use it consistently. (We want the use case story to be as boring as possible.)

1.      The use case starts when, the customer initiates communication with the system.

2.      The system greets the customer and displays the instructions screen.

3.      The customer selects the menu screen.

4.      The system displays the menu index and requests that the customer select a category (menu items will be categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’, etc).

5.      The customer selects a category of menu items.

6.      The system displays the first page of the selected items.

7.      The customer changes page and the system displays the selected page (the system keeps rotating the pages as they are changed within the selected category).

8.      The customer selects items to order and deselects ordered items from the displayed page.

Although relatively simple to model with an activity diagram, the following 2 steps were extremely difficult to ‘model’ with text.

9.      The customer changes page and the use case continues from step 7, until the customer selects a different category or places an order.

10.  The customer selects a different category and the use case continues from step 5, until the customer places an order.

11.  The customer orders their selection,

12.  The system displays the total price and requests the customer for confirmation of the order.

13.  The customer confirms the order.

14.  The system displays the order items to the kitchen staff.

15.  The system displays the ordering menu to the customer, where they may edit, or cancel their order.

16.  The kitchen staff inform the system of the location of the customer food.

17.  The system informs the customer where their food is located and the system informs the Stock Taking System of the contents of the meal.

18.  The food is picked up from the serving area and the system displays the welcome screen to the customer.

4.8.3.11  Alternate Flows

A.1   The Customer Changes their Mind

19.  At step 15, the customer edits their order and the use case continues from step 5.

A.2   The food is not picked up

20.  At step 17, after 10 minutes the food is not picked up and the system sends a request to the administrator to reset the table menu.

4.8.3.12  Performance Requirements

For each step in the AUC that is performed by the system, make sure that it has an associated timing.[12] Any steps that do not have an associated time-out requirement cannot be fully tested.

21.  By default, all responses to the customer will occur within 2 seconds.

22.  All responses to selected items will occur within .5 seconds.

23.  When the customer places an order the kitchen staff will be informed within 30 seconds.

24.  When the location of the food is entered into the system, the customer is informed within 30 seconds.

25.  Once the food has been picked up, the system displays the welcome screen within 10 seconds.

26.  All messages to the administrator will be displayed within 5 seconds of the event occurring.

27.  The Stock Taking System must be informed of the customer ordered items before 6am the following day.

4.8.3.13  Supplementary Requirements

We captured some supplementary requirements during the detailing of the use case steps. I am going to move (not copy) them here and reference the step that they were moved from.

Supplementary (including performance) requirements will be moved their own repository if they are duplicated between use cases. Only supplementary requirements that are specific to a single use case remain with the use case. Ideally we want them to remain with the use case, but unfortunately, the duplication rule takes precedence.

28.   Menu items will be categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’, etc

Obviously this requirement needs clarification from the business; ‘etc’ is not a word that belongs in a requirements document.

29.  The system keeps rotating the pages as they are changed within the selected category.

Or to put it another way, when ‘Next’ is selected while the last page is displayed, the first page will be displayed, and when ‘Previous’ is selected while the first page is displayed, the last page will be displayed. For all other pages, selecting ‘Previous’ will display the previous page and selecting ‘Next’ will display the next page.

[Do not assume that everyone reading this requirement will have the same understanding of the word ‘rotating’. There is bound to be someone out there that interprets ‘rotate’ as meaning ‘turn the page over’. If in doubt, spell it out.[13]]

4.8.3.14  Interface Requirements

System to actor interface requirements are captured with use case storyboards. Since these are specific to the system, they belong with the application.

System to system (Stock Taking System, for example) interface requirements impact both systems and form a contract between the 2 applications. In this case neither application is allowed to change that interface without getting permission from the other system. (I have never worked in an environment where the system interfaces have been properly controlled.)

4.8.3.15  Diagrams

Let’s go ahead and capture the above use case with an AUC activity diagram, but first here is the use case diagram.

                                                                              Figure 23:   Order Food Use Case Diagram

The first thing I noticed when trying to model the above AUC, was that it is way too complicated. There are too many steps to fit on a single page.

[A rule of thumb that I use when doing any sort of modeling: Some people like to use the rule 7+/-2 in order to determine complexity. My rule is; if it does not fit on a single page[14] such that the contents are clear to the reader, then the diagram is too complex and should be broken up. In this case a ‘page’ is letter size 8.5” by 11”.]

                                                                            Figure 24:   Serve Customer Activity Diagram

Note that an AUC activity diagram does not require swimlanes; because there is only 1 worker – the system.

Notice that the event flow exiting the ‘Waiting For Customer Input’ action, carries both the unrelated events ‘Customer Changes Order’ and ‘Welcome Screen displayed’.

4.9    Summary

The activity diagram is a great tool for modeling use cases, but even in UML 2 there are too many ambiguities to use it straight from the box. This document addressed where a UML notation’s meaning was unclear by restricting the use of the notation when there are more than 1 ways to describe an activity and by clearly defining the meaning of each notation when used for use case modeling.