1. Lecture 6: Chapter 4:Test-based Use case Process Modeling Dr. Taysir Hassan Abdel Hamid November 17, 2013

2. Outline An example of Requirements Strategy Text-based use case Use Case Diagrams

3. Root Cause Analysis Example

4. Key Ideas Use cases are a text-based method of describing and documenting complex processes Use cases add detail to the requirements outlined in the requirement definition Systems analysts work with users to develop use cases Systems analysts develop process and data models later based on the use cases

5. 5 - 5 Roles of Use Cases A use case is a set of activities that produce some output result Describes how the system reacts to an event that triggers the system Trigger -- event that causes the use case to be executed Event-driven modeling – everything in the system is a response to some triggering event

6. Role of Use Cases All possible responses to the event are documented Use cases are helpful when the situation is complicated

7. Elements of a Use Case Basic information – Name, number and brief description – Trigger – event that causes the use case to being External trigger – some from outside the system Temporal triggers – time-based occurrences – Viewpoint of the use cases should be consistent Major inputs and outputs – Sources and destinations – Goal is to be all inclusive Details – Steps performed and the data inputs and outputs

8. Sample Use Case

11. Building Use Cases

12. Process of Developing Use Cases Identify the major use cases Identify the major steps within each use case Identify elements within steps Confirm the use case Cycle through the above steps iteratively

13. Step 1: Identify the major use cases ActivitiesTypical Questions Asked Start a use case form for each use case If more than nine, group into packages Ask who, what, and where about the tasks and their inputs and outputs: What are the major tasks performed? What triggers this task? What tells you to perform this task? What information/forms/reports do you need to perform this task? Who gives you these information/forms/reports? What information/forms/reports does this produce and where do they go?

14. Step 2: Identify the major steps within each use case ActivitiesTypical Questions Asked For each use case, fill in the major steps needed to process the inputs and produce the outputs Ask how about each use case: How do you produce this report? How do you change the information on the report? How do you process forms? What tools do you use to do this step (e.g., on paper, by email, by phone)?

15. Step 3: Identify elements within steps ActivitiesTypical Questions Asked For each step, identify its triggers and its inputs and outputs Ask how about each step How does the person know when to perform this step? What forms/reports/data does this step produce? What forms/reports/data does this step need? What happens when this form/report/data is not available?

16. Step 4: Confirm the use case ActivitiesTypical Questions Asked For each use case, validate that it is correct and complete Ask the user to execute the process using the written steps in the use case – that is, have the user role-play the use case

17. CD SELECTIONS

19. 5 - 19 CD SELECTIONS

20. Another Example

23. UML: Use case Diagram

25. Structure Diagrams Structure diagram shows static structure of the system and its parts on different abstraction and implementation levels and how those parts are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts.

26. Behavior Diagrams Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time.

28. Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors) to provide some observable and valuable results to the actors or other stakeholders of the system(s). Use case diagramsuse casesactors

29. Note, that UML 2.0 to 2.4 specifications also described use case diagram as a specialization of a class diagram, and class diagram is a structure diagram.class diagramstructure diagram

30. Business Use Case Diagram Business Use Case diagrams are used to represent the functionality provided by an organization as a whole They answer the questions "What does the business do?" and "Why are we building the system?" Business Use Case diagrams are drawn from the organizational perspective They do not differentiate between manual and automated processes Business Use Case diagrams show the interactions between business use cases and business actors

31. Business Use Case Diagram cont. When using UML to build software, business modeling can help to understand the context of the system to be build If we fail to understand the business, we may make faulty assumptions about what the software should do and how it can best be used by the business community The "world around the system" is an important consideration when building software Business modeling gives the team a view of the business itself, the workflows within it, and the way the new system will help automate portions of the workflow

32. Elements of Business Use Cases NotationRepresentationElement Business use cases Business actors Business workers A business actor is anyone or anything that is external to the organization but interacts with it (Individual, group, company,…) Secondary Actor It represents the workflow within the organization. It keeps focus on what the business is doing Named in the form of A business worker is a role within the organization Primary Actor Associations An arrow from a business actor or a business worker to a use case suggests that the actor or worker initiates the use case

35. Use Case Diagram Use cases represent system functionality, the requirements of the system from the user's perspective Use cases just focus on automated processes Use Case diagrams show the interactions between use cases and actors There is not a one-to-one relationship between business use cases and use cases.

36. Examples of systems: Web Site Payment System Automated Teller Machine (ATM) Library System

37. Actor An actor is anyone or anything that is outside the system’s scope but interacts with it (Individual, group, company,…) There are three primary types of actors: Users of the system  physical person, or a user who will be directly using the system Other systems that will interact with the system being built Time  Time becomes an actor when the passing of a certain amount of time triggers some event in the system (out of control) Elements of Use Case Diagram

38. Use Case It is the functionality the system will provide a value to the end user Use cases are an implementation-independent: High-level view of what the user expects from the system Focus on what the system should do, not how the system will do it A typical system will have somewhere between 20 and 70 use cases The use cases should be named in user terms, not technical terms, and should be meaningful to the customer Elements of Use Case Diagram

39. Use Case cont. So, when you have the final list of use cases, how do you know if you've found them all? - Is each functional requirement in at least one use case? If a requirement is not in a use case, it will not be implemented. - Have you considered how each end user will be using the system? - What information will each end user be providing for the system? - What information will each end user be receiving from the system? - Have you considered maintenance issues? Someone will need to start the system and shut it down. - Have you identified all of the external systems with which the system will need to interact? - What information will each external system be providing to the system and receiving from the system? Elements of Use Case Diagram

40. Use Case: Flow of Events To actually build the system, though, you'll need more specific details. These details are written as the flow of events The purpose of the flow of events is to document the flow of logic through the use case Although it is detailed, the flow of events is still implementation-independent Elements of Use Case Diagram

41. Use Case: Flow of Events Users There are three primary users of the flow of events: 1- The customers will be reviewing this document to make sure it accurately reflects their expectations 2- The system designers will be using it to create the system design and eventually to build the system 3- The quality assurance team will use the flow of events to create test scripts The flow of events must give them enough information to understand the sequence of events that needs to occur through the use case Elements of Use Case Diagram

42. Relationships The association relationship is used to show the relationship between a use case and an actor There are three types of relationships between use cases Includes relationship Extends relationship Generalization relationship These relationships are used when there is a certain amount of commonality between the use cases There is only one relationship allowed between actors. This is a generalization relationship Elements of Use Case Diagram

43. Relationships: Association Association relationship is used to show the relationship between a use case and an actor Every use case must be initiated by an actor, With the exception of use cases in includes and extends relationships Elements of Use Case Diagram

44. Includes relationship Include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case.directed relationshipuse cases The include relationship could be used: – to simplify large use case by splitting it into several use cases, – to extract common parts of the behaviors of two or more use cases. > Purchase Ticket Check Credit

45. A large use case could have some behaviors which might be detached into distinct smaller use cases to be included back into the base use case using the UML include relationship. The purpose of this action is modularization of behaviors, making them more manageable.

49. Relationships: Extends 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 Elements of Use Case Diagram An abstract use case is one that is not started directly by an actor. Instead, an abstract use case provides some additional functionality that can be used by other use cases. Abstract use cases are the use cases that participate in an includes or extends relationship > Change ReservationCheck Credit

50. Relationships: Generalization Generalization relationship is used to show that several actors or use cases have some commonality For example, you may have two types of customers. If the type A customers will be initiating some use cases that type B customers will not, it's probably worth including the actor generalizations. If both types of customers use the same use cases, it's probably not necessary to show an actor generalization Elements of Use Case Diagram Salaried Employee Employee Hourly Employee Phone Salesperson Salesperson In person Salesperson

51. Example of Business use case: Airport Check-in and Security Screening Business actors are Passenger, Tour Guide, Minor (Child), Passenger with Special Needs (e.g. with disabilities), all playing external roles in relation to airport business. Business actors Business use cases are Individual Check-In, Group Check-In (for groups of tourists), Security Screening, etc. - representing business functions or processes taking place in airport and serving the needs of passengers. Business use cases

52. Business use cases Baggage Check-in and Baggage Handling extend Check-In use cases, because passenger might have no luggage, so baggage check-in and handling are optional.

54. Restaurant Business Use case Example We can see several business actors having some needs and goals as related to the restaurant and business use cases expressing expectations of the actors from the business.business actorsbusiness use cases

56. E-library Use Case Patrons of the library can search library catalog online to locate various resources - books, periodicals, audio and visual materials, or other items under control of the library. Patrons may reserve or renew item, provide feedback, and manage their account.

58. Website administration use case