UML

1. UML Use Case Modeling

2. Objectives • Identify actors from a problem statement. • Identify use cases from a problem statement. • Learn how to create a use-case diagram that accurately models the system. • Learn how to write use-case specification, glossary, and supplementary specification document.

3. The Purpose of the Requirements Discipline • The Requirements discipline intends to: • Find agreement on what the system should do. • Provide a better understanding of the system requirements. • Define the boundaries of the system. • Provide a basis for planning the technical contents of iterations. • Provide a basis for estimating cost. • Define a user-interface for the system.

4. Requirements in the Context of SDLC or RUP

5. Relevant Requirements Deliverables or Artifacts Use-Case Model Glossary Actors Use Cases ... Supplementary Specification Use-Case Specifications

6. What Is a Use-Case Model? • A model that describes a system’s functional requirements in terms of use cases. • A model of the system’s intended functionality (use cases) and its environment (actors). View Report Card Register for Courses Student Login

7. What is Use Case Modeling? A a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (i.e., use cases) that are meaningful to users (i.e., actors). • System behavior is how a system acts and reacts. • It is an outwardly visible and testable activity of a system. • System behavior is captured in use cases. • Use cases describe the system, its environment, and the relationship between the system and its environment.

8. Usages of a Use Case Model

9. The software development life cycle

10. Use Case Granularity Source: http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/jul02/TopTenWaysJul02.pdf

11. Major Concepts in Use-Case Modeling • An actor represents anything that interacts with the system. • A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. Actor Use Case

12. What Are the Benefits of Use-Case Models? • Used to communicate with the end users and domain experts • Provides buy-in at an early stage of system development • Insures a mutual understanding of the requirements • Used to identify • Who interacts with the system and what the system should do • The interfaces the system should have • Used to verify • All requirements have been captured • The development team understands the requirements

13. System Surroundings and Actors • Users who execute the system’s • Main functions • Secondary functions, such as system administration • External hardware that the system uses • Other systems interacting with the system

14. Useful Questions in Finding Actors • Who will supply, use, or remove information? • Who will use this functionality? • Who is interested in a certain requirement? • Where in the organization is the system used? • Who will support and maintain the system? • What are the system’s external resources? • What other systems will need to interact with this one? Actor

15. Actors and Roles • An actor represents a role that a human, hardware device, or another system can play. • The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. • Actor names should clearly denote the actor’s role • Actor description: • Area of responsibility • Dependency of the actor on the system Minder as Professor Professor A User May Have Different Roles Minder as Student Student

16. Use Case Modeling: Core Elements

17. Use Case Modeling: Core Relationships <<extend>>

18. Use Case Modeling: Core Relationships (cont’d) <<include>>

19. Example: Online HR System

20. Case Study: Course Registration Problem Statement Course Registration Problem Statement (From Visual Modelling with Rational Rose and UML, Terry Quatrani 1998) The university will require a new Course Registration system. At the beginning of each semester, professors at the university will register the courses that they are going to teach with the system. The system then will allow students to request a course catalogue containing a list of course offerings for the coming semester. Information about each course such as professor, department and prerequisites are included. The student then can select four-course offering. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. For each semester, there is a period of time that students can change their schedule through adding or dropping courses. Professors must be able to access the system to indicate which courses they will be teaching and to see which students signed up for their course offerings.

21. Practice: Find the Actors • In the Course Registration System Requirements document, read the Problem Statement for the Course Registration case study. • As a group, identify the following: • Actors • Description of the actor

22. Finding Use Cases: Focus on the Actor • The system exists only for its users • Use cases should be based on the user’s needs • Answer the following questions to find use cases. • For each actor you have identified, what are the tasks the system would be involved in? • Does the actor need to be informed about certain occurrences in the system? • Will the actor need to inform the system about sudden, external changes? • What information must be modified or created in the system?

23. MOT Analysis Example: Credit Card MOT: Moment of Truth • Pri to MOT • Recognition • Information gathering • Comparison • MOT • Applying for Credit Card • Receiving Credit Card • Using Credit Card • Providing Information • Changing and Upgrading • Gifts giving • Emergency Assisting • After MOT • No usage follow-up • Stop membership follow-up

24. Practice: Solution A person who is registered to take courses at the University The external system responsible for student billing Billing System Student The unabridged catalog of all courses offered by the University A person who is teaching classes at the University Course Catalog Professor The person who is responsible for the maintenance of the course registration system Registrar

25. Name Use Cases Register for Courses Login • The name indicates what is achieved by its interactions with the actor(s). • The name may be several words in length. • No two use cases should have the same name. Maintain Student Information

26. Practice: Finding Use Cases • In the Course Registration System Requirements document, read the Problem Statement for the Course Registrations case study. • As a group, using the actors identified in the earlier practice session, identify the following: • Use Cases • Use-Case names

27. Practice: Solution Register for Courses View Report Card Maintain Professor Information Close Registration Maintain Student Information Login Select Courses To Teach Submit Grades

28. Use Cases and Actors • A use case models a dialog between actors and the system. • A use case is initiated by an actor to invoke a certain functionality in the system. a use case: . . .describes a sequence of actions, performed by a system, that yields a result of value to the user.

29. Concept: Communicate-Association • Use cases and actors interact by sending signals to one another. • To indicate such interactions, use a communicate-association. Use Case Actor Communicate-Association

30. Practice: Use Case and Actor Communication • In the Course Registrations System Requirements document, read the Problem Statement for the Course Registration case study. • As a group, using the actors and use cases identified in the earlier practice session, identify: • Communicate-associations between the actors and the use cases.

31. Use Case and Actor Communication View Report Card Student Register for Courses Maintain Professor Information Course Catalog Login Maintain Student Information Select Courses to Teach Registrar Professor Close Registration Submit Grades Billing System

32. Develop a Library System Use Cases Exercise • Identify actors • Determine major use major use cases • Draw a use case diagram The library system is designed for a local public library.

33. Use-Case Specifications Use-Case Model Actors Use Cases ... Use-Case Specifications • Name • Brief description • Flows of Events • Relationships • Activity diagrams • Use-Case diagrams • Special requirements • Pre-conditions • Post-conditions • Other diagrams

34. Use Case Description: Change Flight • Actors: traveler, client account db, airline reservation system • Preconditions: • Traveler has logged on to the system and selected ‘change flight itinerary’ option • Basic course • System retrieves traveler’s account and flight itinerary from client account database • System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. • System asks traveler for new departure and destination information; traveler provides information. • If flights are available then • … • System displays transaction summary. • Alternative courses • If no flights are available then …

35. Use Case Flow of Events • Has one normal, basic flow  Happy Case • Several alternative flows • Regular variants of the basic flow • Odd cases • Exceptional flowshandling error situations

36. What Are Scenarios? • A scenario is an instance of a use case

37. Glossary Glossary Course Registration System Glossary 1.Introduction This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. 2.Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. 2.1Course: Aclass offered by the university. 2.2Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered. 2.3Course Catalog: The unabridged catalog of all courses offered by the university.

38. Supplementary Specification Supplementary Specification • Functionality • Usability • Reliability • Performance • Supportability • Design constraints Online Resource: http://www-106.ibm.com/developerworks/rational/library/3975.html#N10071

39. Verify a Use Case Model • Is the use-case model understandable? • By studying the use-case model, can you form a clear idea of the system's functions and how they are related? • Have all functional requirements been met? • Does the use-case model contain any superfluous behavior? • Is the division of the model into use-case packages appropriate?

40. Verify Actors • Have all the actors been identified? • Is each actor involved with at least one use case? • Is each actor really a role? Should any be merged or split? • Do two actors play the same role in relation to a use case? • Do the actors have intuitive and descriptive names? Can both users and customers understand the names?

41. Verify Use Cases • Is each use case involved with at least one actor? • Is each use case independent of the others? • Do any use cases have very similar behaviors or flows of events? • Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? • Do customers and users understand the names and descriptions of the use cases?

42. Verify Use-Case Specifications • Is it clear who wishes to perform a use case? • Is the purpose of the use case also clear? • Does the brief description give a true picture of the use case? • Is it clear how and when the use-case's flow of events starts and ends? • Does the communication sequence between actor and use case conform to the user's expectations? • Are the actor interactions and exchanged information clear? • Are any use cases overly complex?

43. Verify Glossary • Does each term have a clear and concise definition? • Is each glossary term included somewhere in the use-case descriptions? • Are terms used consistently in the brief descriptions of actors and use cases?

44. Library System Use Case A library contains books and journals. The task is to develop a computer system for borrowing books. In order to borrow a book the borrower must be a member of the library. There is a limit on the number of books that can be borrowed by each member of the library. The library may have several copies of a given book. It is possible to reserve a book. Some books are for short term loans only. Other books may be borrowed for 3 weeks. Users can extend the loans. 1. Draw a use case diagram for a library system. 2. Give a use case description for two use cases: • Borrow a copy of a book • Extend the loan of a book http://www.cs.nott.ac.uk/~sxp/OOMethods/Exer1.pdf

45. Step Wise Refinement of Use Case Model The eight basic steps to generate use cases model for each business process area: Step 1: Confirm actors and goals. Have all actors and their goals been identified? Which actors can be generalized (combined)? Which goals are potential use cases? Step 2: Develop an outline of the use case(s). For the goals identified as potential use cases, what are the key pieces? For each outline level, what are key data? Outline all use cases. Prioritize the use-case flows. Decide on a final use-case list (for initial pass). Step 3: Write a brief description of the use case(s). What two or three sentences describe all actors and the basic flow? Generate content first, and worry about wordsmithing it later. Step 4: Detail the basic flow. What event starts the use case? How does the use case end? How does the use case repeat some behavior? What is the "happy" (best case) path? There is one and only one basic flow.

46. Step Wise Refinement of Use Case Model Step 5: Detail the alternate flows.Are there optional situations for the use case? What might go wrong? What might not happen? Which resources might be blocked? Which alternate flows are special — perhaps nonfunctional — requirements (i.e., they apply to this use case only)? Step 6: Review the use case(s). Are there more use cases? Should some use cases be redefined? Which ones can be combined? Step 7: Record pre- and post-conditions. What was the previous state before this use case comes into play? What happens once the use case is complete? Step 8: Develop generalizations for all use cases. Determine shared content and process for the use cases. What items have been noted for the glossary or as global business rules? Who has the most recent and accurate source document? Where is it located?

47. Reminders • Write something readable. • Casual, readable use cases are still useful whereas unreadable use cases won’t get read. • Work breadth-first, from lower precision to higher precision. • Precision Level 1: Primary actors name and goal • Precision Level 2: The use case brief; or the main success scenario • Precision Level 3: The extension conditions • Precision Level 4: The extension handling steps • For each step: • Show a goal succeeding. • Capture the actor’s intention, not the user interface details. • Have an actor pass information, validate a condition, or update state. • Write between-step commentary to indicate step sequencing (or lack of). • Ask “why” to find a next-higher level goal • For data descriptions (only put Precision Level 1 into the use case text): • Precision Level 1: Data nickname • Precision Level 2: Data fields associated with the nickname • Precision Level 3: Field types, lengths, and validations Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley

48. The Writing Process 1. Name the system scope and boundaries. Track changes to this initial context diagram with the in/out list. 2. Brainstorm and list the primary actors. Find every human and non-human primary actor, over the life of the system. 3. Brainstorm and exhaustively list user goals for the system. The initial Actor-Goal List is now available. 4. Capture the outermost summary use cases to see who really cares. Check for an outermost use case for each primary actor. 5. Reconsider and revise the summary use cases. Add, subtract, or merge goals. Double-check for time-based triggers and other events at the system boundary. 6. Select one use case to expand. Consider writing a narrative to learn the material. Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley

49. Continued… 7. Capture stakeholders and interests, preconditions and guarantees. The system will ensure the preconditions and guarantee the interests. 8. Write the main success scenario (MSS). Use 3 to 9 steps to meet all interests and guarantees. 9. Brainstorm and exhaustively list the extension conditions. Include all that the system can detect and must handle. 10. Write the extension-handling steps. Each will end back in the MSS, at a separate success exit, or in failure. 11. Extract complex flows to sub use cases; merge trivial sub use cases. Extracting a sub use case is easy, but it adds cost to the project. 12. Readjust the set: add, subtract, merge, as needed. Check for readability, completeness, and meeting stakeholders’ interests.

50. Review Questions • What are the main artifacts of requirements? • What are the requirements artifacts used for? • What is a use-case model? • What is an actor? • What is a use case? • What is the difference between a scenario and a use case?