Use Case Diagrams

Behavioral Modeling Diagrams
Use Case Diagrams
A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases.
OMG's UML standard defines a graphical notation for diagramming use cases, but no format for describing use cases. While the graphical notation and descriptions are important, they are documentation of the use case—a purpose that the actor can use the system for.
The true value of a use case lies in two areas:
  • The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.
  • The position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

More formally, a use case is made up of a set of scenarios. Each scenario is a sequence of steps that encompass an interaction between a user and a system. The use case brings scenarios together that accomplish a specific goal of the user.
There’s no rocket science to it at all: a usage case is simply a reason to use a system. For example, a bank card holder might need to use an ATM to get cash out of their account. It’s as simple as that.
A use case can be specified by textually describing the steps required and any alternative actions at each step. For example, the use case for withdrawing cash from an ATM machine might be shown as:
  1. Customer enters the Card
  2. ATM checks for validity of card, ask card holder to enter PIN
  3. Customer enters PIN.
  4. ATM validates the PIN.
  5. and so on....
Alternative: Search Failed
If the search fails at 3, then the user is redirected back to the search screen at step 1
Actor
The use case diagram allows a designer to graphically show these use cases and the actors that use them. An actor is a role that a user plays in the system. It is important to distinguish between a user and an actor (better thought of as a role). A user of the system may play several different roles through the course of his, her or its job (since an actor may be another system). Examples of actors are salesperson, manager, support person, and web store system. It is possible that the same person may be a sales person and also provide support. When creating a use case model, we are not concerned with the individuals, only the roles that they play.
Use Cases
A use case is a single unit of meaningful work. It provides a high-level view of behavior observable to someone or something outside the system. The notation for a use case is an ellipse.
The notation for using a use case is a connecting line with an optional arrowhead showing the direction of control. The following diagram indicates that the actor "Customer" uses the "Withdraw Cash" use case.
Use Case Definition
A use case typically Includes:
  • Name and description
  • Requirements
  • Constraints
  • Scenarios
  • Scenario diagrams
  • Additional information.
Name and Description
A use case is normally named as a verb-phrase and given a brief informal textual description.
Requirements
The requirements define the formal functional requirements that a use case must supply to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract or promise that the use case will perform an action or provide some value to the system.
Constraints
A constraint is a condition or restriction that a use case operates under and includes pre-, post- and invariant conditions. A precondition specifies the conditions that need to be met before the use case can proceed. A post-condition is used to document the change in conditions that must be true after the execution of the use case. An invariant condition specifies the conditions that are true throughout the execution of the use case.
Scenarios
A Scenario is a formal description of the flow of events that occur during the execution of a use case instance. It defines the specific sequence of events between the system and the external actors. It is normally described in text and corresponds to the textual representation of the sequence diagram.
Including Use Cases
Use cases may contain the functionality of another use case as part of their normal processing. In general it is assumed that any included use case will be called every time the basic path is run.
Use Cases may be included by one or more Use Case, helping to reduce the level of duplication of functionality by factoring out common behavior into Use Cases that are re-used many times.
Extending Use Cases
One use case may be used to extend the behavior of another; this is typically used in exceptional circumstances. For example, if before modifying a particular type of customer order, a user must get approval from some higher authority, then the use case may optionally extend the regular use case.



0 Ask a Question or Comment:

The latest info about icet, icetcounselling details and very good stuff on UML,Behavioral Modeling Diagrams and SOFTWARE TESTING,various testing methods.

Blogger Templates by OurBlogTemplates.com 2008