Use case model

From Wikipedia, the free encyclopedia

Use Case Model is a model that describes a system’s functional requirements in terms of use cases. Consists of all the actors of the system and all the various use cases by which the actor interact with the system, thereby describing the total functional behaviour of the system.

Use case modelling allows future users of a software system as much input as possible into its design. it uses the vocabulary of the users, not programmers. This focus on users means that the initial specification of the program can be understood both by its users and by the software engineers designing it.

There are two main entities in the use case approach: actor and use cases.

1. Actors An actor is a person who will use the system we are designing. A bank customer interacting with the software of an automated teller machine is an actor. An astronomer inputting the coordinates of a star to a telescope aiming program is an actor. A bookstore clerk checking the computer to see if a particular book is available is an actor. Usually an actor initiates some operation, although sometimes the actor may act in other ways, such as receiving information or assisting in an operation.

In a large project, just identifying all the actors may be difficult. The designer needs to look for people or other systems that: 1. Provide information to the system 2. Need information from the system 3. Assist other actors

2. Use Cases A use case is a specific task, usually initiated by an actor. it describes a single goal the actor wants to attain. Examples are the withdrawal of cash by the bank customer, the aiming of the telescope by the astronomer, and the investigation of a book's availability by the bookstore clerk. In general, everything you want the system to do should be specified by a use case.

When to Use: Use Cases Diagrams

   Use cases are used in almost every project.  They are helpful in exposing requirements and
 planning the project. During the initial stage of a project most use cases should be
 defined, but as the project continues more might become visible. 

How to Draw: Use Cases Diagrams

   Use cases are a relatively easy UML diagram to draw, but this is a very simplified
 example.  This example is only meant as an introduction to the UML and use cases.
   If you would like to learn more see the Resources page for more detailed resources on UML.

   Start by listing a sequence of steps a user might take in order to complete an action.
   For example a user placing an order with a sales company might follow these steps. 

      1. Browse catalog and select items.
      2. Call sales representative.
      3. Supply shipping information.
      4. Supply payment information.
      5. Receive conformation number from salesperson.

   These steps would generate this simple use case diagram:

   This example shows the customer as an actor because the customer is using the ordering system.
   The diagram takes the simple steps listed above and shows them as actions the customer might perform.
   The salesperson could also be included in this use case diagram because the salesperson is also
  interacting with the ordering system. 

   From this simple diagram the requirements of the ordering system can easily be derived.
   The system will need to be able to perform actions for all of the use cases listed.  As the project progresses other use cases might appear. 
  The customer might have a need to add an item to an order that has already been placed.
   This diagram can easily be expanded until a complete description of the ordering system is derived capturing
  all of the requirements that the system will need to perform.

Scenarios A use case usually consists of a number of scenarios. the use case specifies a goal,
while a scenario represents a particular outcome when attempting to reach that goal.
For example, let's consider a use case consisting of a bookstore clerk querying the store's
computer system for the location of a particular book. There are several possible outcomes or scenarios: -> The book is in the store and the computer displays its shelf location. -> The book is out of stock, but the system gives the customer the opportunity to order it
from the publisher. -> The book is not out of stock, it's out of print; so the system informs the customer that
she or he is out of luck.