SOFTWARE REQUIREMENT

ENGINEERING

Experiment 05
Introduction to Use cases and drawing use case
models

CLO 1: Apply the knowledge for solving problems of varying complexities

CLO 2: Use modern tools and languages.

CLO 3: Construct the experiments/projects of varying complexities.

CLO 4: Demonstrate a unique solution of problem under discussion.

Use Cases: What They Are

I recently bought a digital camera. When I was shopping for it, I encountered a wide variety of
possibilities. How did I decide which one to buy? I asked myself exactly what I wanted to do with
a camera. Did I want extreme portability or did I want a larger camera with a bigger lens?
Would I be taking distance shots? Did I want to take pictures and post them on the Web? Did I
primarily want to make prints? If so, how large? Did I want to make short movies? With sound?

We all go through a process like this when we make a non-impulse purchase. What we're doing
is a form of use case analysis: We're asking ourselves how we're going to use the product or
system we're about to shell out good money for, so we can settle on something that meets our
requirements. The important thing is to know what those requirements are. This kind of
process is particularly crucial for the analysis phase of system development. How users will use
a system drives the way you design and build it.

The use case is a construct that helps analysts work with users to determine system usage. A
collection of use cases depicts a system in terms of what users intend to do with it. Think of a
use case as a collection of scenarios about system use. Each scenario describes a sequence of
events. Each sequence is initiated by a person, another system, a piece of hardware, or by the
passage of time. Entities that initiate sequences are called actors. The result of the sequence
has to be something of use either to the actor who initiated it or to another actor.

An Example: The Soda Machine

Suppose you're starting out to design a soda machine. In order to get the user's point of view,
you interview a number of potential users as to how they'll interact with the machine. Because
the main function of a soda machine is to allow a customer to buy a can of soda, it's likely the
users will quickly tell you that you're concerned with a set of scenarios—a use case, in other
words—that you could label "Buy soda." Let's examine each possible scenario in this use case.
In normal system development, remember, these scenarios would emerge through
conversations with users.
 Figure 1. A use case specifies a set of scenarios for accomplishing something useful for an
actor. In this example, one use case is "Buy soda."

The "Buy Soda" Use Case

The actor in this use case is a customer who wants to purchase a can of soda. The customer
initiates the scenario by inserting money into the machine. He or she then makes a selection. If
everything goes smoothly, the machine has at least one can of the selected soda in stock, and
presents a cold can of the soda to the customer.

In addition to the sequence of steps, other aspects of the scenario deserve consideration. What
preconditions motivate the customer to initiate this scenario in the "Buy soda" use case? Thirst
is the most obvious one. What postconditions result as a consequence of the scenario's steps?
Again, the obvious one is that the customer has a soda. Is the scenario I described the only
possible one for "Buy soda"? Others immediately come to mind. It's possible that the machine
is out of the soda the customer wants. It's possible that the customer doesn't have the exact
amount of money the soda costs. How should you design the soda machine to handle these
scenarios?

out-of-soda scenario

Let's turn to the out-of-soda scenario, another sequence of steps in the "Buy soda" use case.
Think of it as an alternative path through the use case. The customer initiates the use case by
inserting money into the machine. He or she then makes a selection. The machine does not
have at least one can of the selected soda, so it presents a message to the customer, saying it's
out of that brand. Ideally, the message should prompt the customer to make another selection.
The machine should also offer the customer the option of getting his or her money back. At this
point the customer selects another brand and the machine delivers (if it's not sold out of the
new selection), or takes the option of receiving the money. The precondition is a thirsty
customer. The post condition is either a can of soda or the returned money.

Incorrect-amount-of-money scenario.

Of course, another out-of-soda scenario is possible: The "out of brand" message could display
as soon as the machine's stock disappears and remain on until the machine is resupplied. In
that case, the user might not insert money in the first place. The client for whom you're
designing the machine might prefer the first scenario: If the customer has already inserted
money, the tendency might be to make another selection rather than to ask the machine to
return the money.
Now let's look at the incorrect-amount-of-money scenario. Once again, the customer initiates
the use case in the usual way, and then makes a selection. Let's assume the machine has the
selection in stock. If the machine has a reserve of appropriate change on hand, it returns the
difference and delivers the soda. If the machine doesn't have a reserve of change, it returns the
money and presents a message that prompts the user for correct change. The precondition is
the usual one. The post condition is either a can of soda along with change, or the returned
money that was originally deposited. Another possibility is that as soon as the machine's
change reserve is depleted, a message appears informing potential customers that correct
change is required. The message would remain visible until the machine's reserve is resupplied.

Additional Use Cases

You've examined the soda machine from the viewpoint of one user: the customer. Other users
enter the picture as well. A supplier has to restock the machine, (Figure 2) and a collector
(possibly the same person as the supplier) has to collect the accumulated money from the
machine (Figure 3). This tells us we should create at least two more use cases, "Restock" and
"Collect money," whose details emerge through interviews with suppliers and collectors.

Figure 2. Restocking a soda machine is an important use case.

Figure 3. Collecting the money from a soda machine is another important use case.
Consider the "Restock" use case. The supplier initiates this use case because some interval (say,
two weeks) has passed. The supplier's representative unsecures the machine (probably by
unlocking a lock, but that gets into implementation), pulls open the front of the machine, and
fills each brand's compartment to capacity. The representative also refills the change reserve.
The representative then closes the front of the machine and secures it. The precondition is the
passage of the interval, the postcondition is that the supplier has a new set of potential sales.

For the "Collect money" use case, the collector also initiates because an interval has passed. He
or she would follow the same sequence of steps as in "Restock" to unsecure the machine and
pull open the front. The collector then removes the money from the machine, and follows the
"Restock" steps of closing and securing the machine. The precondition is the passage of the
interval, and the postcondition is the money in the hands of the collector. Notice that when we
derive a use case, we don't worry about how to implement it. In our example we're not
concerned with the insides of the soda machine. We don't care about how the refrigeration
mechanism works, or how the machine keeps track of its money. We're just trying to see how
the soda machine will look to someone who has to use it. The objective is to derive a collection
of use cases that we will ultimately show to the people who will design the soda machine and
the people who will build it. To the extent our use cases reflect what customers, collectors, and
suppliers want, the result will be a machine that all these groups can easily use.

Including a Use Case

In the "Restock" use case and the "Collect" use case, you'll note some common steps. Both
begin with unsecuring the machine and pulling it open, both end with closing the machine and
securing it. Can we eliminate the duplication of steps from use case to use case? We can. The
way to do it is to take each sequence of common steps and form an additional use case from
each one. Let's combine the "unsecure" and "pull open" steps into a use case called "Expose the
inside" and the "close machine" and "secure" steps into a use case called "Unexpose the
inside." (OK. I've invented a word here—unexposed. Hide or conceal just didn't seem
appropriate!) Figure 4 illustrates these combinations of

Steps.
 Figure 4. You can combine some of the steps that make up a use case. The combination of
steps constitutes an additional use case.

With these new use cases in hand, the "Restock" use case starts off with the "Expose the inside"
use case. The supplier's representative then goes through the steps as before and concludes
with the "Unexpose the inside" use case. Similarly, the "Collect" use case starts off with the
"Expose the inside" use case, proceeds as before, and finishes with the "Unexpose the inside"
use case. As you can see, "Restock" and "Collect" include the new use cases. Accordingly, this
technique of reusing a use case is referred to as including a use case.

Figure 5 : The soda machine use case model with inclusion.

Extending a Use Case

It's possible to reuse a use case in a way other than inclusion. Sometimes we create a new use
case by adding some steps to an existing use case. Let's go back to the "Restock" use case.
Before putting new cans of soda into the machine, suppose the supplier's representative notes
the brands that sold well and the brands that did not. Instead of simply restocking all the
brands, the rep might pull out the brands that haven't sold well and replace them with cans of
the brands that have proven to be more popular. He or she would then also have to indicate on
the front of the machine the new assortment of available brands. If we add these steps to
"Restock" we'll have a new use case that we can call "Restock according to sales." This new use
case is an extension of the original, and this technique is called extending a use case.

Figure 6. A use case diagram showing extension and inclusion.

Extension, Inclusion, and Confusion

In my experience, people who are used to modeling process flows (from pre-UML times) are sometimes
confused by the direction of dependency arrows. The confusion often emerges when it comes to
modeling extension and inclusion of use cases. This happens because process-flow veterans are used to
seeing arrows that denote sequences of operations or activities: The first one in a sequence connects
with the second one via an arrow that points from the first to the second. Thus in a use case diagram
that shows Use Case A including Use Case B, their tendency is to think that Use Case A takes place first,
followed immediately by Use Case B. Many times—by the nature of inclusion—the opposite turns out to
be true. The key is to bear in mind that a dependency arrow doesn't specify the direction of a process.
Instead, it specifies the direction of a relationship. A dependency arrow that starts at Use Case A and
ends at Use Case B means that A depends on B, not that A precedes B.

Generalization
Classes can inherit from one another, and so can use cases. In use case inheritance, the child use case
inherits behavior and meaning from the parent and adds its own behavior. You can apply the child
wherever you apply the parent.

Suppose you're modeling a soda machine that allows a customer to buy either a can of soda or a cup of
soda. In that case, "Buy soda" would be a parent use case, and "Buy a can of soda" and "Buy a cup of
soda" would be child use cases. You model generalization of use cases the same way you model
generalization of classes—with a solid line that has an open triangle pointing at the parent, as in
Figure.7.

Figure 7 The generalization relationship for use cases

The generalization relationship can exist between actors, too. You might have represented both the
supplier's representative and the collector as agents of the supplier. If you rename the representative as
the Restocker, the Restocker and Collector are both children of the Supplier Agent, as Figure 8 shows.

Figure 8 Like classes and use cases, actors can be in a

 generalization relationship.

Modeling With StarUML

Actor

Semantics

An actor defines a coherent set of roles that users of an entity can play when interacting with
the entity. An actor may be considered to play a separate role with regard to each use case with
which it communicates.

Procedure for creating Actor

In order to create Actor, click [Toolbox] -> [UseCase] -> [Actor] button and click the position
where to place Actor. Actor is shown in the form of stick man or rectangle with icon, that is
decoration view. To display actor in decoration view, select [Format] -> [Stereotype Display] ->
[Decoration] menu item or select [Decoration] item in [ ] combo button on toolbar.

Procedure for creating multiple UseCases used by Actor at once

In order to create multiple UseCases related to Actor at once, use shortcut creation syntax of
Actor.
 1. At the Actor's quick dialog, enter UseCase's name after "-()" string. To create multiple
UseCases, enter same but separate UseCase's name by "," character.

2. And press [Enter] key. Several UseCases associated with the Actor are created and
arranged vertically.

UseCase

Semantics

The use case construct is used to define the behavior of a system or other semantic entity
without revealing the entity’s internal structure. Each use case specifies a sequence of actions,
including variants, that the entity can perform, interacting with actors of the entity.

Procedure for creating UseCase

In order to create UseCase, click [Toolbox] -> [UseCase] button and click the position where to
place UseCase on the [main window].

UseCase is expressed in the forms of textual, decoration, iconic. To change UseCase's view
style, select menu item under [Format] -> [Stereotype Display] or select [ ]button's combo
item.
Association / Derected Association

Semantics

A association is an association among exactly two classifiers (including the possibility of an

association from a classifier to itself).

Procedure for creating association

In order to create association, click [Toolbox] -> [UseCase] -> [Association] button, drag from
first element, and drop to second element in the [main window].

Procedure for creating directed association

The procedure is equal to the association's, drag and drop in the arrow direction.

Or create association, click the actor-side association end. At the quick dialog, uncheck
navigable and association becomes directed.
Procedure for creating element related to association/directed assocition

In order to create element associated with current element, use shortcut creation syntax.

1. Double-click element and enter element's names associated after "--" or "->" string at the quick
dialog. Separate element names with "," character to relate multiple elements.

2. Press [Enter] key and several elements associated with selected element are created and
arranged automatically.

Generalization

Semantics

Generalization is the taxonomic relationship between a more general element (the parent) and
a more specific element (the child) that is fully consistent with the first element and that adds
additional information.
Procedure for creating generalization

In order to make generalization, click [Toolbox] -> [UseCase] ->[Generalization] button, drag
from child element and drop to parent element in the [main window].

Procedure for creating multiple child actors inherited from actor

To create multiple elements inherited from some element,

1. Enter with "<=" string as following at the quick dialog, and several elements inherited from
selected element are created at once.

2. Child elements are generated below selected element and arranged automatically.

If you want to create multiple parent element at once, enter "=>" string instead of "<=" in the
quick dialog.
Dependency

Semantics

A dependency is a type of relationship that signifies that one element, or group of elements,
acting as the client depends on another element or group of elements that act as a supplier. It
is a weak relationship that denotes that if the supplier is changed the client may be affected. It
is a unidirectional relationship.

Procedure for creating dependency

In order to create dependency, click [Toolbox] -> [UseCase] -> [Dependency] button, drag
element and drop to other element depended.

Procedure for creating other usecase depended by current usecase

Enter with "-->" string at the quick dialog as following.

So dependency relationship is created between two elements.

Include

Semantics

An include relationship defines that a use case contains the behavior defined in another use
case.

Procedure for creating include

In order to create include relationship, click [Toolbox] -> [UseCase] -> [Include] button, drag
from element including and drop to element included in the [main window].
Procedure for creating other usecase included by current usecase

Enter with "-i>" string at the quick dialog as following.

So include relationship is created between two elements.

Extend

Semantics

An extend relationship defines that instances of a use case may be augmented with some
additional behavior defined in an extending use case.

Procedure for creating extend

In order to create extend, click [Toolbox] -> [UseCase] -> [Extend] button, drag from element
extending and drop to element extended in the [main window].
Procedure for creating other usecase extending current usecase

Enter with "<e-" string at the quick dialog as following.

So extend relationship is created between two elements.

System Boundary

Semantics

A System Boundary is a type of partition that represents the boundary between the thing you
are representing with the use cases (inside the boundary) and the actors (outside the
boundary). Its most typical usage is the boundary of an entire system. Use cases can be used to
represent subsystems and classes and so the boundary may be more specific than an entire
system. A package with a stereotype topLevel can be used as a boundary and name space
within the use case model to denote the same thing as the use case boundary.

Procedure for creating system boundary

In order to create system boundary, click [Toolbox] -> [UseCase] -> [System Boundary] button,
drag from the starting point of system boundary and drag to right-bottom point of system
boundary.
Lab tasks
1. Draw use case diagram for Soda Machine .

2. Draw use case diagram for an ATM Machine .