Scribd
Upload
8 views18 pages

Lecture 5

Use Case Modelling is a powerful UML tool that describes interactions between users and systems through Use Cases, which are typically named using verb/noun combinations. Actors, which can be people or external systems, initiate Use Cases, and the purpose of Use Cases is to define system scope, guide development, and facilitate communication between customers and developers. Proper granularity is essential, as Use Cases should focus on achieving goals for the actor rather than detailing every interaction.

Uploaded by

abdulbaseerk135
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
8 views18 pages

Lecture 5

Use Case Modelling is a powerful UML tool that describes interactions between users and systems through Use Cases, which are typically named using verb/noun combinations. Actors, which can be people or external systems, initiate Use Cases, and the purpose of Use Cases is to define system scope, guide development, and facilitate communication between customers and developers. Proper granularity is essential, as Use Cases should focus on achieving goals for the actor rather than detailing every interaction.

Uploaded by

abdulbaseerk135
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

Use Case Modelling

Chapter 7
Dr. Jibran Mir
Introduction
• A very powerful UML tool is the Use Case. A Use Case is simply a
description of a set of interactions between a user and the system. By
building up a collection of Use Cases, we can describe the entire
system we are planning to create, in a very clear andconcise manner.
• Use cases are usually described using verb/noun combinations . for
example, “Pay Bills”, “Update Payroll”, or “Create Account”.
• For example, if we were writing a missile control system, typical Use
Cases for the system might be “Fire Missiles”, or “Issue
Countermeasures”.
• Along with the name of the use case, we will provide a full textual
description of the interactions that will occur between the user and the
system. These textual descriptions will generally become quite
complicated, but the UML provides an astoundingly simple notation to
represent a Use Case, as follows:
Actor
• A Use Case cannot initiate actions on its own. An actor is someone
who can initiate a Use Case. For example, if we were developing a
banking system, and we have a Use Case called .withdraw money.,
then we would identify that we require customers to be able to
withdraw money, and hence a customer would become one of our
actors. Again, the notation for an actor is simple:
Figure 24 - UML Notation for an Actor
Actor
• Going further, actors can be more than just people. An actor can be
anything external to the system that initiates a Use Case, such as
another computer system.
• An actor could also possibly be a more abstract concept such as time,
or a specific date.
• For example, we may have a use case called “Purge Old Orders” in an
order processing system, and the initiating actor could be “Last
Working Day..
Actor and use case
• As we have noted, actors are related to Use Cases, in the sense that it
is an actor that will initiate a particular use case. We can represent this
on a Use Case diagram by connecting the actor to the use case:
Actor and Use case
• Clearly, for most systems, a single actor can interact with many use
cases, and a single use case can be initiated by many different actors.
This leads to the full use case diagram, an example of which follows:
The Purpose of Use Cases
• Use Cases define the scope of the System. They enable us to visualise
size and scope of the entire development.
• Use Cases are very similar to requirements, but whilst requirements tend
to be vague, confusing, ambiguous and poorly written, the tighter
structure of Use Cases tend to make them far more focused
• The “sum” of the use cases is the whole system. That means that anything
not covered by a use case is outside the boundary of the system we are
developing. So the Use Case diagram is complete, with no holes.
• They allow for communication between the customer and developers
(since the diagram is so simple, anyone can understand it)
The Purpose of Use Cases
• Use Cases guide the development teams through the development
process . We shall see that Use Cases are the backbone of our
development, and we refer to them in everything we do
• We’ll see that Use Cases provide a method for planning our
development work, and allow us to estimate how long the
development will take
• Use Cases provide the basis for creating system tests
• Finally, Use Cases help with the creation of user guides!
It is often claimed that Use Cases are simply an expression of the
system requirements. Anyone making this claim are clearly missing the
point of Use Cases
Use Case Granularity
• It can be difficult to decide upon the granularity of use cases - in a
particular scenario, should each user-system interaction be a use case,
or should the use case encapsulate all of the interactions?
• For example, let us consider the example of the ATM machine.
• We need to build the ATM system to allow a user to withdraw money.
• We might have the following series of common interactions in this
scenario:
Use Case Granularity
• enter card
• enter pin number
• select amount required
• confirm amount required
• remove card
• take receipt
Should each of these steps . for example, “enter pin number” be a use
case?
Mistake
• This is a classic mistake in the construction of Use Cases. Here, we
have generated a large number of small, almost inconsequential use
cases. In any non-trivial system, we would end up with a huge number
of Use Cases, and the complexity would become overwhelming.
• To handle the complexity of even very large systems, we need to keep
the Use Cases at a fairly .high level.. The best way to approach a Use
Case is to keep the following rule-of-thumb in mind:
A Use Case should satisfy a goal for the actor
• Applying this simple rule to our example above, we can ask the
question “Is take receipt”, for example, the goal for our customer?
Well, not really. It wouldn.t be the end of the world if the receipt
wasn.t dispensed.
• Apply the rule to the other Use Cases, and you’ll find that really, none
of them describe the goal of the user. The goal of the user is to
withdraw money, and that should be the use case!

You might also like