Lecture#04, use case diagram

24
BY: ALTAF HUSSAIN MS(CSE), NUST SSO. KRL USE CASES & Use Case Diagram

Transcript of Lecture#04, use case diagram

Page 1: Lecture#04, use case diagram

BY:ALTAF HUSSAINMS(CSE), NUST

SSO. KRL

USE CASES &

Use Case Diagram

Page 2: Lecture#04, use case diagram

INTRODUCTION

No system exists in isolation. Every interesting system interacts with human or automated actor that use that system for some purpose, and those actors expect that system to behave in a predictable way.

A USE CASE specifies the behavior of a system or a part of a system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable results of value to an actor.

Page 3: Lecture#04, use case diagram

USE CASEs & ACTORs

We apply use cases to capture the intended behavior of the system we are developing, without having to specify how that behavior will be implemented.

Use case provide a way for our developers to come to a common understanding with your system’s end user and domain experts.

In addition use cases serve to help validate our architecture and to verify our system as it evolves during development.

As we implement the system, these use cases are realized by collaborations whose elements work together to carry out each use case.

Page 4: Lecture#04, use case diagram

USE CASEs & ACTORs

A use case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actor) with the system itself ( and its key abstraction).

These behaviors are in effect system-level functions that we use to visualize, specify, construct and document the intended behavior of our system during requirement capturing and analysis.

A use case represents the functional requirements of our system as a whole

Page 5: Lecture#04, use case diagram

USE CASEs & ACTORs

A use case involves the interaction of actors and the system.

An actor represents a coherent set of roles that users of use case play when interacting these use cases.

Actor can be human or they can be automated systems.

For example in modeling a bank, processing a loan involves, among other things, the interaction of customer and loan officer.

Page 6: Lecture#04, use case diagram

Use Case & Flow of Events

A use case specify what a system (subsystem, class or interface) does but it does not specify how it does it.

Modeling use cases we try to keep clear the separation of concerns between outside and inside view.

We specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily.

Writing use cases, we specify the flow of events, we include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flows of the behavior.

Page 7: Lecture#04, use case diagram

Example of Use Case & Flow of Events

In the context of ATM system, consider the use case ValidateUser.

Main Flow of events: The use case starts when the system prompts the

customer for a PIN number. The Customer can now enter a PIN number via keypad. The Customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case.

Exceptional Flow of events: The Customer can cancel a transaction at any time by

pressing the Cancel button, thus restarting the use case. No changes are made to the Customer’s account.

Page 8: Lecture#04, use case diagram

Example of Use Case & Flow of Events

Exceptional Flow of events: The Customer can clear a PIN number before

committing it and reenter a new PIN number.Exceptional Flow of events:

If the Customer enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancel entire transaction, preventing the Customer from interacting with the ATM for 60 seconds.

Use Cases can be specified in a number of ways, including informal structured text (as in this example), formal structured text (with pre- and post-conditions), and with pseudo code.

Page 9: Lecture#04, use case diagram

Use Cases & Scenarios

An interaction diagram includes collaboration and sequence diagrams.

Typically first we describe the flow of events for a use case in text.

As we refine our understanding of the system, we want to also use interaction diagrams to specify these flows graphically.

Typically we use one sequence diagram to specify the use case’s main flow and variations of that diagram to specify a use case’s alternate or exceptional flows.

Page 10: Lecture#04, use case diagram

Use Cases & Scenarios

It is desirable to separate main versus alternate flows because a use case describes a set of sequences, not just single sequence, and it would be impossible to express all the details of an interesting use case in just a single sequence.

For example in a HR System, we might find a use case Hire Employee. This general business function might have many possible variations. we might hire a person from another company (the most common scenario); we might transfer a person from one division to another (common in international companies); or we might hire a foreign national (which involves its own special rule). So each of these variants can be expressed in different sequence.

Page 11: Lecture#04, use case diagram

Use Cases & Scenarios

Actually one use case (Hire Employee) describes a set of sequences in which each sequence in the set represents one possible flow through all these variations.

Each sequence of a use case is called a Scenario.A scenario is a specific sequence of actions that

illustrates behavior. Scenarios are to use cases as instances are to classes,

meaning that a scenario is basically an instance of a use case.

For each use case we will find primary scenario (which define essential sequences) and secondary scenarios (which define alternate sequences).

Page 12: Lecture#04, use case diagram

Organizing Use Cases

We organize use cases by specifying generalization, include, and extend relationships among them.

We apply these relationships in order to factor common behavior (by pulling such behavior from other use cases that it includes) and in order to factor variants (by pushing such behavior into other use cases that extend it).

Generalization among use cases is like generalization among classes. It means that the child use case inherits the behavior and meaning of the parent use case; the child may add to or override the behavior of its parent; and the child may be substituted any place the parent appears (both parent or child may have concrete instances).

Page 13: Lecture#04, use case diagram

Organizing Use Cases

For example, in a banking system, we might have the use case Validate User, which is responsible for verifying the identity of the user.

We might have its two specialized children of this use case Check Password and Retinal Scan. Both of these behave like Validate User and may be applied anywhere Validate User appears, yet both of which add their own behavior (the former by checking a textual password and the later by checking the unique retina patterns of the user.

Generalization is rendered as solid directed line with a large open arrowhead, just like generalization among classes.

Page 14: Lecture#04, use case diagram

Organizing Use Cases

An Include relationship between use cases means that the base use cases explicitly incorporates the behaviors of another use case at a location specified by base.

The include use case never stands alone, but it is only instantiated as a part of some larger base use case that includes it.

We can think of it as the base use case pulling the behavior from the supplier use case.

We might include relationship to avoid describing the same flow of events several times, by putting the common behavior in a common use case of its own (the use case that is included by the base use case).

Page 15: Lecture#04, use case diagram

Organizing Use Cases

An Extend relationship between use cases means that the base use case implicitly incorporates the behavior of another use case at a location specified indirectly by the extending use case.

The base use case may stand alone, but under certain conditions, its behavior may be extended by the behavior of another use case.

These base use case may be extended at certain point called the extension points.

We can think of extend as pushing the behavior to the base use case. Extend relationship is used to model the part of use case that the user may see as optional system function.

Page 16: Lecture#04, use case diagram

Organizing Use Cases

Using Extend relationship we separate optional behavior from mandatory one. Similarly we use it to model separate sub flow that is executed only under given conditions.

Page 17: Lecture#04, use case diagram
Page 18: Lecture#04, use case diagram

Organizing Use Cases

Organizing use cases by extracting common behavior (though include relationships) and

distinguishing variants (through extend relationship) is an important part of creating simple, balanced, and understandable set of

use cases for a system.

Page 19: Lecture#04, use case diagram

USE CASE DIAGRAM

Use Case Diagram is one of five diagrams in UML for modeling the dynamic aspects of systems (Activity diagrams, Statchart diagram, Sequence diagram, Collaboration diagram & four other type of diagrams in UML for modeling dynamic aspects of a system).

Use case diagram show use cases, actors and their relationships to model the context of a system, subsystems, or a class or model the requirements of behavior of these elements.

Use Case diagram is central to model the behavior of a system.

Page 20: Lecture#04, use case diagram

USE CASE DIAGRAM…

Suppose someone hands you a box. On one side of that box there are some buttons and a small LCD panel. Moreover, the box is nondescript; you are not even given with a hint about how to use it. You could randomly punch buttons and see what happens, but you would be hard to pressed to figure out what that box does or how to use it properly unless you spent a lot of trial-and-error time.

Software intensive systems can be like that. If you are a user, you might be handed an application and told to use it. If the application follows normal conventions of operating system you are use to, you might be able to get it to do something useful after a fashion, but you’d never come to understand its more complex & subtle behavior that way.

Page 21: Lecture#04, use case diagram

USE CASE DIAGRAM…

Simply we apply use case diagram to visualize the behavior of a system so that users can comprehend how to use that element and so that developers can implement that element.

Page 22: Lecture#04, use case diagram

USE CASE DIAGRAM EXAMPLE

Page 23: Lecture#04, use case diagram

USE CASE DIAGRAM EXAMPLE

Last slide Use Case diagram show the context of a Credit Card Validation System, with an emphasis on the actors that surround the system. We will find Customer, of which there are two kinds (Individual Customer and Corporate Customer). These actors are the roles that human play when interacting this system. In this context, there are also actors that represent other institutions, such as Retail Institution (with which a Customer performs a card transaction to buy an item or service) and Sponsoring financial institution (which serves as the clearinghouse for the credit card account). In the real world, these later two actors are likely software intensive systems themselves.

Page 24: Lecture#04, use case diagram

Questions…