Scenario

1. Scenario • A scenario is a sequence of steps describing an interaction between a user and a system. Use case is a set of scenarios tied together by a common user goal. • Buy a Product scenario that would say this: • The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up e-mail. • This scenario is one thing that can happen. However, the credit card authorization might fail, and this would be a separate scenario. In another case, you may have a regular customer for whom you don't need to capture the shipping and credit card information, and this is a third scenario. • All these scenarios are different yet similar. The essence of their similarity is that in all these three scenarios, the user has the same goal: to buy a product. The user doesn't always succeed, but the goal remains. This user goal is the key to use cases: A use case is a set of scenarios tied together by a common user goal.

2. A user placing an order with a sales company might follow these steps.  • Browse catalog and select items. • Call sales representative. • Supply shipping information. • Supply payment information. • Receive conformation number • from salesperson.

3. Use Cases • A use case is a set of scenarios that describing an interaction between a user and a system.  A use case diagram displays the relationship among actors and use cases.  The two main components of a use case diagram are use cases and actors. • An actor is represents a user or another system that will interact with the system you are modeling.  A use case is an external view of the system that represents some action the user might perform in order to complete a task. • Use cases are used in almost every project.  The 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.  • A use case is a high-level piece of functionality that the system will provide. In other words, a use case illustrates how someone might use the system. Use Case

4. Use Cases contd… • Use case specify what a system can does but does not specify how it does • Each use case has short description which define the purpose of use case • There are three types of flows: the primary, alternate, and error flows. Any deviation • from the primary use case known as alternative flow The flow of events describes, step- • by-step, what will happen to execute the functionality in the use case. The flow of events • focuses on what the system will do, not how it will do it. • Use cases are a technique for capturing the functional requirements of a system. • Use cases work by describing the typical interactions between the users of a system • and the system itself, providing a narrative of how a system is used. • The pre conditions for a use case list the conditions that have to be met • before the use case start. The post conditions must be true after the use case • finished executing e.g. A use case must always be run after another use case

5. Purchase Ticket Scenario The steps for the primary flow of events include: 1. The use case begins when the customer selects the option to view flight information. 2.The system prompts for the departure and destination cities and the departure and return dates. 3.The user enters the departure and destination city, departure date, and return date. 4.The system displays a list of available flights, including the fare. A1: There are no available flights. 5.The user selects the flight they would like to reserve. 6.The system displays all available fare options for that flight. 7. The user selects the fare option they would like to reserve. A2: The user selects a free ticket through frequent-flyer membership. 8. The system displays the fare that the user will pay. 9. The user confirms the rate. 10. The system prompts for a credit card type, number, name, and expiration date. 11. The user enters the card type, number, name, and expiration date. 12. The system submits the credit purchase. A6: Account not found A7: Insufficient funds E1: Credit system not accessible 13.The system reserves a seat on the plane for the user. 14.The system generates and displays a confirmation code to the user. 15.The user confirms receipt of the code. 16.The use case ends.

6. Alternate Flows A1: No available flights 1. The system displays a message that there are no available flights for the departure and destination cities, departure date, and return date entered. 2. The user confirms the message. 3. The flow returns to the primary flow, step 2. A2: Free ticket through frequent-flyer membership 1. The system prompts for the frequent-flyer number. 2. The user enters the number. 3. The system confirms the validity of the number. A3: Invalid number 4. The system confirms that there are enough miles on this membership to qualify for the free ticket. A4: Not enough miles to qualify for a free ticket A5: No frequent-flyer tickets available 5. The ticket fare is set to $0. 6. The flow returns to the primary flow, step 8. A3: Invalid frequent-flyer number 1. The system displays a message that the frequent-flyer number is invalid. 2. The user reenters the number or selects the option to cancel the frequent-flyer request. 3. If the user reenters the number, the flow returns to step 1 of alternate flow A2. 4. If the user cancels the frequent-flyer request, the flow returns to step 6 of the primary flow.

7. A4: Not enough frequent-flyer miles to qualify for free ticket 1. The system displays a message that there are not enough miles to qualify. The message contains the required number of miles and the number of miles available. 2. The flow returns to step 6 of the primary flow. A5: No frequent-flyer tickets available 1. The system displays a message that there are no frequent-flyer tickets available for the selected flight. 2. The flow returns to step 6 of the primary flow. A6: Credit account not found 3. The system displays a message that the credit account was not found. 4. The flow returns to step 10 of the primary flow. A7: Insufficient funds 1. The system displays a message that there were not enough funds on the card to complete the transaction. 2. The flow returns to step 10 of the primary flow. Error Flows E1: Credit system not available 1. The system displays a message that the credit system is not available. 2. The flow returns to step 10 of the primary flow.

8. You begin by picking one of the scenarios as the main success scenario. You start the body of the use case by writing the main success scenario as a sequence of numbered steps. You then take the other scenarios and write them as extensions, describing them in terms of variations on the main success scenario. Extensions can be successes—user achieves the goal, as in 3a—or failures, as in 6a.

9. ATM machine • Customer enter a card • System prompts for a pin number • Customer enters a pin number • System check the pin number • If the pin number is valid the system acknowledge the Entry • Exceptional flow of events • The customer cancels the transaction at any time by pressing cancel • Customer clears the pin number • If the pin number is invalid the use case restarts and locks the system if it • receive continuously three wrong pin numbers

10. Actors • An actor is a role that a user plays with respect to the system. Actors might include customer, customer service rep, sales manager, and product analyst. Actors carry out use cases. A single actor may perform many use cases; conversely, a use case may have several actors performing it. Usually, you have many customers, so many people can be the customer actor. Also, one person may act as more than one actor, such as a sales manager who does customer service rep tasks. An actor doesn't have to be human. If the system performs a service for another computer system, that other system is an actor. • Actors are not part of the system they are out of the System e.g. loan officer and customer. • A use case can have more then one actors and an actor can play more then one role • Use cases include anything that is within the system; actors include anything that is external to the system. • Three types of Actors • First type is physical person. • Other system that interact with the system. • Third is time; Passing certain amount of time trigger some event.

11. Kinds of Use Case Relationships • There are three types of relationships between use cases: an includes relationship, an extends relationship, and a generalization relationship. • There is only one relationship allowed between actors. This is a generalization relationship. • Association • The association relationship is used to show the relationship between a use case and an actor. In UML, association relationships are diagrammed using an arrow: • Customer Purchase Ticket • Customer Purchase Ticket Credit System • The use case initiates communication with the credit system actor. As the "Purchase Ticket“ use case is being run, the reservation system initiates communication with the credit system to check the card and complete the transaction. Although information flows in both directions—from the reservation system to the credit system and back again—the arrow indicates only who initiated the communication.

12. Includes Relationship An includes relationship allows one use case to use the functionality provided by another use case. This relationship can be used in one of two cases. First, if two or more use cases have a large piece of functionality that is identical, this functionality can be split into its own use case. Each of the other use cases can then have an includes relationship with this new use case. The second case where an includes relationship is helpful is a situation in which a single use case has an unusually large amount of functionality. An includes relationship can be used to model two smaller use cases instead. Includes relationships are shown with dashed arrows and the word <<include>>. In this example, the "Check Credit" use case will check that a valid card number was entered and that the credit account has sufficient funds to complete the transaction. Because this functionality is used during the Purchase Ticket process, there is an includes relationship between them. An includes relationship suggests that one use case always uses the functionality provided by another. No matter how you proceed through the Purchase Ticket use case, the "Check Credit" use case is always run. Purchase Ticket <<include>> Check Credit

13. Extends Relationship In contrast, an extends relationship allows one use case the option to extend the functionality provided by another use case. It is very similar to an includes relationship, because in both of these types of relationships, you separate some common functionality into its own use case. In UML, the extends relationship is shown as a dashed arrow with the word <<extend>>. An extends relationship In this example, the "Check Credit" use case extends the "Change Reservation" use case. While the "Change Reservation" use case is running, "Check Credit" runs if and only if the amount of the reservation has changed. If the amount has not changed, "Check Credit" does not need to run. Because "Check Credit" is optionally run, there is an extends relationship between the use cases. The arrow is drawn from the use case that is optionally run ("Check Credit") to the use case that is being extended ("Change Reservation"). Change Reservation << extends>> Check Credit

14. Generalization Relationship A generalization relationship is used to show that several actors or use cases have some commonality. For example, you may have two types of customers: corporate customers and individual customers. You can model this relationship using the notation displayed in the Figure. This diagram shows our two types of customers: individual and corporate. Because the individual and corporate actors will be directly instantiated, they are called concrete actors. Because the customer actor is never directly instantiated, it is an abstract actor. It exists only to show that there are two types of customers.

15. Employee Customer Hourly Employee Salaried Commercial Employee Customer Abstract Actor Generalization

16. Kinds of Use Case Relationships association The communication path between an actor and a use case that it participates in. The association relationship is used to show the relationship between a use case and an actor. extend The insertion of additional behavior into a «extends» base use case that does not know about it use case A relationship between a general use case generalization and a more specific use case that inherits and adds features to it. include The insertion of additional behavior into a «include» base use case that explicitly describes the insertion

17. Some things to keep in mind as you are creating Use Case diagrams include: • Do not model actor-to-actor associations (although generalizations are OK). By definition, the actors are outside the scope of the current project. The communication between the actors, therefore, is also outside the scope of what you're building. You can use a workflow diagram to examine the actor associations. • Do not draw an association directly between two use cases (although includes or extends relationships are OK). The diagrams show what use cases are available, but don't show in which order the use cases will be executed, so there shouldn't be an association between use cases. • Every use case must be initiated by an actor. That is, there should be an arrow starting with an actor and ending with the use case. Again, the exception here is an includes or extends relationship. • Think of the database as a layer underneath the entire Use Case diagram. You can enter information in the database using one use case, and then access that information from the database in another use case. You don't have to draw associations from one use case to another to show information flow.