Sre Lab 06

UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA
FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING
SOFTWARE ENGINEERING DEPARTMENT
LAB 06
Problem analysis of Case Study/projects and identification of Stake Holders. Full
dressed Use cases
Case Studies:
1. Car Match Sharer

2. VolBank
Use Cases
Use cases are text stories, widely used to discover and record requirements. They influence many
aspects of a project including OOD and will be input to many subsequent artifacts in the case
studies. OOD (and all software design) is strongly related to the prerequisite activity of
requirements analysis, which often includes writing use cases. Requirements analysis may
include stories or scenarios of how people use the application; these can be written as use cases.
Use cases are not an object-oriented artifact they are simply written stories. Under normal
circumstances, 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. They serve to communicate from one person to another,
often to people with no special training. Simple text is, therefore, usually the best choice.
Basic Notation for Use Case:
In a use case diagram use case are drawn as an ellipse. The name of the use case is usually written
inside the ellipse, but can be placed beneath it.
use case name
Use case name
Figure 2.1: Use Cases
Software Requirements Engineering 3rd Semester-SE UET Taxila

Note: do not mix these two styles in the same model.
Use case names are text strings that contains letters, numbers and most punctuation marks except
for the colon, which is used to separate use case names from the names of packages and it is good
idea to keep them short.
Use case names are normally made up of an active verb and a noun phrase that concisely describe
the behavior of the system that you are modeling.
For example:
Register Car Sharer, Match car Sharers or Record Sharing agreement are the names of use cases
for the Case Study CarMatch
Register car sharer
Figure 2.2: Use Case Example
Procedure for creating UseCase using StarUML
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.
Actors
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.
Kind of Actors:
An actor is anything with behavior, including the system under discussion (SuD) itself when it
calls upon the services of other systemst. Actors are roles played not only by people, but by
organizations, software, and machines. There are three kinds of external actors in relation to the
SuD:
Primary actor has user goals fulfilled through using services of the SuD.
o Why identify? To find user goals, which drive the use cases?
o For example, Car Match Administrator.
Supporting actor provides a service (for example, information) to the SuD. Often a
computer system, but could be an organization or person.
o Why identify? To clarify external interfaces and protocols.
o For Example, Web server.
Offstage actor has an interest in the behavior of the use case, but is not primary or
supporting;
o Why identify? To ensure that all necessary interests are identified and satisfied.
Offstage actor interests are sometimes subtle or easy to miss unless these actors
are explicitly named.
o For example, a government tax agency, Third Party companies
Basic Notation for Actor:
Actor is drawn as a stick person with role name written beneath
Actor role name
Figure 2.2: Actor
When dealing with human actors, it is important to remember that the name of an actor is the
name of the role that the actor performs in relation to the system and not just the job title.
For example:
In a CarMatch office there may be people with different job titles (clerk, receptionist and
supervisor) who can all register new car sharers in the system. Rather than drawing three different
actors, we identify what is common to their jobs and create an actor for that role, in the case
CarMatch Administrator

CarMatch Administrator
Figure 2.4: Actor Example
Procedure for creating Actor using StarUML
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.
Associations
Actors are connected to the use cases with which they interact, by a line that represents a
relationship between the actors and the use cases. The relationship indicates that there is an
association between an actor and a use case. This means that a particular system in that actor role
will communicate with particular instances of the use case, in which they will participate in the
sequence of events that is represented by the use case.
Figure 2.5: Association between actor and use case
Note: in practical terms; the use case will eventually be implemented as some kind of computer
program and the actors will use the program by entering information, receiving information or
both.
A single actor may be associated with more than one use cases or a single use case may be
associated with more than one actors

Figure 2.6: Actors and Use Cases
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.
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. And press
[Enter] key.
Several UseCases associated with the Actor are created and arranged vertically.
Behavior Specifications:
As mentioned above in the manual, that use case represents sequence of activities, that results in
some observable outcome for the actor or actors who interact with it. The sequence of activities is
documented in a behavior specification. The link to a behavior specification may be represented
in a CASE tool by a link to a diagram that provides the specification. This could be a sequence
diagram or a communication diagram and others.
Often an internal specification is provided as a use case description. In a CASE Tool it may be
possible both to enter an informal description of a use cases behavior and to specify it formally
by linking it to another diagram.
Some UML diagrams have formal rules about the syntax of textual information. This makes it
possible to execute the model and simulate the system and eventually to translate the model into
program code in a language such as java or C++.However, use case descriptions do not have
formal syntax and you can write the descriptions in the format that is most useful to you. You
may be working in an organization that has its own rules or guidelines for how use cases are
documented, in which case you should abide by those guidelines. The guidelines may include the
use of a template for writing use case descriptions and the sections of the template may include
pre conditions and post conditions that can be formally specified in Object Constraint Language
(OCL).
Three common approaches to writing use case descriptions:
1. Simply to write one or few statements describing sequence of activities.
For example:
You can add details for Register Car Sharer as follows
The user will enter the name, address and telephone number of the potential car sharer. For
each journey that this person wants to share, the start address, the destination address, the
start time and the finish time of the journey are entered.
Figure 2.7: Simple Use Case Description for Register Car Sharer
2. To list in two columns the activities of actor and the responses of the system.
3. To use a document template that contains sections for different aspects of the use case that
you want to record.
In StarUML you could generate the Use Case Document and complete its description. Follow the
following steps to generate the Use Case Description Document
To generate artifacts by template, it must be applicable to current working UML model.

1.Select [Tools]->[StarUML Generator...] Menu
2.In the [Select templates for generation] Page, Check templates to generate in the ListBox and
Click [Next] Button.

3. To bind values with parameters, Click Button of each template item in the ListBox, and set values
of parameter as you want. (Refer to Registering Template for more information about template
parameters)

4.In the [Select target path] Page, Select a folder that generated artifacts will be placed and click
[Next] button.

If you want to create a new folder, click [New Folder...] button and input name of the new
folder.
5.In the [Generating...] Page, click [Generate] button. You can check the progress of generation and
it will be logged on Logs. If you want to cancel the generation process, click [Cancel] button. When
all artifacts are successfully generated, [Finish] will be enabled and clicking it will finish the artifact
generation. To see generated artifacts, double-click the item that want to see in the [Generation
List] then the generated artifact will be opened.

Your Use case document has been generated you can open the document and edit its details.
Starting a Use Case Analysis
Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure is:
1. Choose the system boundary. Is it just a software application, the hardware and application as
a unit, that plus a person using it, or an entire organization?
2. Identify the primary actors those that have goals fulfilled through using services of the system.
3. Identify the goals for each primary actor.

4. Define use cases that satisfy user goals; name them according to their goal. Usually, user-goal
level use cases will be one-to-one with user goals, but there is at least one exception, as will
be examined.
Choose the System Boundary
If the definition of the boundary of the system under design is not clear, it can be clarified by
further definition of what is outside the external, primary and supporting actors. Once the external
actors are identified, the boundary becomes clearer.
Steps 2 and 3: Find Primary Actors and Goals
It is artificial to strictly linearize the identification of primary actors before user goals; in a
requirements workshop, people brainstorm and generate a mixture of both. Sometimes, goals
reveal the actors, or vice versa.
Guideline: Brainstorm the primary actors first, as this sets up the framework for further
investigation.
Are There Questions to Help Find Actors and Goals?
In addition to obvious primary actors and goals, the following questions help identify others that
may be missed:
Who starts and stops the system? Who does system administration?
Who does user and security management? Is "time" an actor because the system
does something in response to a time
event?
Is there a monitoring process that restarts the system if Who evaluates system activity or
it fails? performance?
How are software updates handled? Push or pull Who evaluates logs? Are they remotely
update? retrieved?
In addition to human primary actors, are there any Who gets notified when there are errors
external software or robotic systems that call upon or failures?

Who starts and stops the system? Who does system administration?
services of the system?
How to Organize the Actors and Goals?
There are at least two approaches:
1. As you discover the results, draw them in a use case diagram, naming the goals as use
cases.
2. Write an actor-goal list first, review and refine it, and then draw the use case diagram.
Why Ask About Actor Goals Rather Than Use Cases?
Actors have goals and use applications to help satisfy them. The viewpoint of use case modeling
is to find these actors and their goals, and create solutions that produce a result of value. Rather
than asking "What are the tasks? one starts by asking: "Who uses the system and what are their
goals?" In fact, the name of a use case for a user goal should reflect its name, to emphasize this
view point Goal: register the car sharers; use case Register Car Sharer
Thus, here is a key idea regarding investigating requirements and use cases:
Imagine we are together in a requirements workshop. We could ask either:
"What do you do?" (roughly a task-oriented question) or,
"What are your goals whose results have measurable value?"
Prefer the second question.
Answers to the first question are more likely to reflect current solutions and procedures, and the
complications associated with them.
Answers to the second question, especially combined with an investigation to move higher up the
goal hierarchy ("what is the root goal?") open up the vision for new and improved solutions,
focus on adding business value, and get to the heart of what the stakeholders want from the
system.
Other Ways to Find Actors and Goals? Event Analysis

Another approach to aid in finding actors, goals, and use cases is to identify external events. What
are they, where from, and why? Often, a group of events belong to the same use case.
Define Use Cases
In general, define one use case for each user goal. Name the use case similar to the user goal for
example, Goal: process a sale; Use Case: Process Sale.
Start the name of use cases with a verb.
A common exception to one use case per goal is to collapse CRUD (create, retrieve, update,
delete) separate goals into one CRUD use case, idiomatically called Manage <X>. For example,
the goals "edit user," "delete user," and so forth are all satisfied by the Manage Users use case.
What Tests Can Help Find Useful Use Cases?
There are several rules of thumb, including:
1. The Boss Test

2. The EBP Test
3. The Size Test
The Boss Test
Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss
happy?
If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results
of measurable value. It may be a use case at some low goal level, but not the desirable level of
focus for requirements analysis.
That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the
boss test, but may be important and difficult.
The EBP Test
An Elementary Business Process (EBP) is a term from the business process engineering field

A task performed by one person in one place at one time, in response to a business event, which
adds measurable business value and leaves the data in a consistent state, e.g., Approve Credit or
Price Order
The Size Test
A use case is very seldom a single action or step; rather, a use case typically contains many steps,
and in the fully dressed format will often require 310 pages of text. A common mistake in use
case modeling is to define just a single step within a series of related steps as a use case by itself,
such as defining a use case called Enter an Item ID. You can see a hint of the error by its small
size the use case name will wrongly suggest just one step within a larger series of steps, and if
you imagine the length of its fully dressed text, it would be extremely short.
Reasonable Violations of the Tests
Although the majority of use cases identified and analyzed for an application should satisfy the
tests, exceptions are common.
Relationships among Use Cases
Inclusion
Sometimes one use case includes the functionality of another use case .Inclusion enables you to
reuse one use case's steps inside another use case. To represent inclusion, you use a dashed line
connecting the use case with an arrowhead pointing to the depended-on use case.
Near the line, you add the keyword include in guillemets (<<.>>).including use case
means that one use case always includes another.
For Example:
In CarMatch Sharing, there is a use case to process payments from car sharers .this can exist as a
free standing use case to deal with payments that can come from members whose details were
transferred from the web server, but when a new car sharer is added manually, the membership
payment is always processed at the same time. So the use case Process Payment is both a use
case on its own and included in the use case Manually add Car Sharer
Extension allows you to create a new use case by adding steps to an existing use case. Like
inclusion, you visualize extension with a dependency line (dashed line and arrowhead) along with
a keyword. In this case the keyword is extend.
For Example:
If a car sharer is paying by cash or cheque, then the Process payment use case contains all the
functionality that is required. However, if payment is by bank direct debit, or by credit or debit
card, then the Process payment use case can be extended by either the use case Process card
payment or the use case Process direct debit.
The names of the points in the use case at which the extension takes place can be shown in a
compartment in the use case ellipse in the diagram. The compartment is headed extension points.
For the link to be followed into an extending use case and the sequence of activities in that use
case to be carried out, some condition must evaluate to be true. In the example there are three

conditions, payment type=credit or debit card, paymentType =cash or cheque and

paymentType=direct debit. In this case, only one of these can be true, so at most one of the
extending use cases will be used.
Generalization has one use case inheriting from another grouping. 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.
For example:
Consider the use cases to add new car sharers to the system: there is one use case for adding new
car sharers manually, one for the web service and another for transferring them in from the web
server .these three use cases all serve the same overall function, but they are different in some
aspects of how they operate. We can consider the three use cases as specializations of use case
Register car sharer and Register car sharer as the general case. This can be represented in a use
case diagram through the use of Generalization.
The diagram indicates that the three use case Manually add Car Sharer, Add car sharer web
service and Transfer car sharer from web server inherit some of the functionality from the use
case Register car sharer but that they differ from it in some way .In this case ,it is because one
will be linked to a user interface to allow CarMatch Administrator actor to enter the details, the
second will receive the details as an XML document from a third party ,while the third will have
an interface to the data on the web server.

Grouping is a simple way of organizing a set of use cases. This could happen when a system
consists of a number of subsystems .Another possibility is when youre interviewing users in
order to gather requirements for a system. Each requirement would be represented as a separate
use case. Youll need some way of categorizing the requirements. The most straightforward way
to organize is to group related use cases into a package. A package appears as a tabbed folder. The
grouped use cases appear inside the Folder.
Generalization between actors:
It is possible for a generalization association to exist between actors
For example:
At CarMatch, the Franchisee can handle the registration of new car sharers, but can also be the
recipient of management reports. Rather than show both the Franchisee and the CarMatch
Administrator in association with every use case that they share. It is possible to show the
Franchisee as a specialization of the CarMatch Administrator. This means that the Franchisee can
do everything that the CarMatch Administrator can do and more.

Task:
Study VolBank case study and identify the stake holders, use cases, actors and apply use
cases and actors relationships and associations.
Draw the model in StarUML.

Sre Lab 06

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sre Lab 06

Uploaded by

Copyright:

Available Formats

UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA

FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING

SOFTWARE ENGINEERING DEPARTMENT

1. Car Match Sharer

Basic Notation for Use Case:

use case name

Use case name

Figure 2.1: Use Cases

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Note: do not mix these two styles in the same model.

Register car sharer

Figure 2.2: Use Case Example

Procedure for creating UseCase using StarUML

SOFTWARE ENGINEERING DEPARTMENT

o For example, Car Match Administrator.

o Why identify? To clarify external interfaces and protocols.

o For Example, Web server.

o For example, a government tax agency, Third Party companies

Basic Notation for Actor:

Actor is drawn as a stick person with role name written beneath

Actor role name

Figure 2.2: Actor

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Figure 2.4: Actor Example

Procedure for creating Actor using StarUML

Figure 2.5: Association between actor and use case

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Figure 2.6: Actors and Use Cases

Procedure for creating multiple UseCases used by Actor at once

SOFTWARE ENGINEERING DEPARTMENT

You can add details for Register Car Sharer as follows

To generate artifacts by template, it must be applicable to current working UML model.

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Starting a Use Case Analysis

3. Identify the goals for each primary actor.

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

Choose the System Boundary

Steps 2 and 3: Find Primary Actors and Goals

Are There Questions to Help Find Actors and Goals?

Software Requirements Engineering 3rd Semester-SE UET Taxila

SOFTWARE ENGINEERING DEPARTMENT

services of the system?

How to Organize the Actors and Goals?

There are at least two approaches:

Why Ask About Actor Goals Rather Than Use Cases?

Imagine we are together in a requirements workshop. We could ask either:

"What do you do?" (roughly a task-oriented question) or,

"What are your goals whose results have measurable value?"

Prefer the second question.

Other Ways to Find Actors and Goals? Event Analysis

Software Requirements Engineering 3rd Semester-SE UET Taxila