UML Use Case Modeling.

UML Use Case Modeling

Object-Oriented Analysis - Instructor Notes
Objectives Object-Oriented Analysis - Instructor Notes 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. Introduce the concepts in this module. Do not approach this module as an exhaustive treatise on building a use-case model. Rather, this module is intended to give the student a sound understanding of how to use a use-case model. There are exercises where the students are required to find actors and use cases. They are intended to help the student understand the use-case diagram by experiencing some of the problems that go into creating an effective use-case model. The Requirements Overview module provides an overview of the activities that immediately precede Analysis and Design. It is meant to describe the interface between the Requirements and the Analysis and Design disciplines. The Requirements Overview module provides enough information to give you an appreciation for the Requirements discipline, and enable you to read and interpret the Requirements artifacts that serve as the starting point for the Analysis and Design activities. Module 2 – Modeling System Behavior with Use Cases

The Purpose of the Requirements Discipline
Object-Oriented Analysis - Instructor Notes 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. Treat this slide as background information for the student. This course is not going to teach requirements management, but it attempts to provide enough background so that the student can appreciate the work that precedes analysis and design. The purpose of the Requirements discipline is to: Establish and maintain agreement with the customers and other stakeholders on what the system should do. Provide system developers with a better understanding of the system requirements. Define the boundaries of (delimit) the system. Provide a basis for planning the technical contents of iterations. Provide a basis for estimating cost and time to develop the system. Define a user-interface for the system, focusing on the needs and goals of the users. Module 2 – Modeling System Behavior with Use Cases

Requirements in the Context of SDLC or RUP
Object-Oriented Analysis - Instructor Notes Emphasize that Analysis & Design gets its primary input artifacts from the Requirements discipline. This is the RUP chart that was introduced in the Best Practices module. The Requirements discipline is related to other process disciplines. The Business Modeling discipline provides Business Rules, a Business Use-Case Model and a Business Object Model, including a Domain Model and an organizational context for the system. The Analysis & Design discipline gets its primary input (the use-case model and the Glossary) from Requirements. Flaws in the use-case model can be discovered during analysis & design; change requests are then generated, and applied to the use-case model. The Test discipline tests the system to verify the code against the Use-Case Model. Use Cases and Supplementary Specifications provide input on requirements used in planning and designing tests. The Project Management discipline plans the project and each iteration (described in an Iteration Plan). The use-case model and Requirements Management Plan are important inputs to the iteration planning activities. Module 2 – Modeling System Behavior with Use Cases

Relevant Requirements Deliverables or Artifacts
Object-Oriented Analysis - Instructor Notes Relevant Requirements Deliverables or Artifacts Emphasize that the Use-Case Model not only contains the actors and use cases and their relationships, but also contains the detailed information for each use case (documented in Use-Case Specifications). These are the artifacts that drive the analysis and design of the system, and each is discussed, in detail, later in this module. The other artifacts produced during Requirements do not have as much of an impact on the Analysis and Design activities, so they are not listed here and are not covered in this course. For more information on the Requirements discipline, suggest the Requirements Management with Use Cases (RMUC) course. Though not explicitly listed as a Requirements artifact, the Use-Case Modeling Guidelines document is very important, as it is where the conventions for how to write use cases are described (for example, how to reference actors, glossary terms, use of caps, italics, boldface, etc.). Templates for these artifacts are delivered with the Rational Unified Process. Use-Case Model Glossary Actors Use Cases The Use-Case Model describes what the system does. The Use-Case Model serves as a contract between the customer, the users, and the system developers. It allows customers and users to validate that the system becomes what they expected and allows System developers to ensure that what they build is what is expected. The Use-Case Model consists of use cases and actors. Each use-case in the model is described in detail, showing step by step how the system interacts with the actors and what the system does in the use case. The Use-Case Specification is the document where all of the use-case properties are documented (for example, brief description, use-case flows of events, etc.). The Supplementary Specification contains those requirements that don’t map to a specific use case (for example, nonfunctional requirements). The Supplementary Specification is an important complement to the use-case model. Together, they capture all requirements (functional and nonfunctional) that need to be described for a complete system requirements specification. The Glossary defines a common terminology for all models and contains textual descriptions of the required system. ... Supplementary Specification Use-Case Specifications Module 2 – Modeling System Behavior with Use Cases

What Is a Use-Case Model?
Object-Oriented Analysis - Instructor Notes 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). This slide is part of the “Fundamentals of Visual Modeling with UML” course. Actors and use cases are discussed on the next several slides. Use this slide to set the context for that discussion. You might describe a use-case model as a menu. Students can place themselves in a role (actor) and see the options available to them on this system. A use-case model does NOT imply the order that use cases execute. View Report Card A use-case model describes a system’s functional requirements in terms of use cases. It is a model of the system's intended functionality and its environment. The use-case model serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle. When the customer approves the use-case model, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development. Potential users use it to better understand the system. Designers use it as a basis for their work and to get a system overview. Testers use it to plan testing activities (use-case and integration testing) as early as possible. Those developing the next version of the system use it to understand how the existing version works. Documentation writers use the use cases as a basis for writing the system's user guides. The architect uses the use-case model to identify architecturally significant functionality. The manager uses it to plan and follow up on the use-case modeling and the subsequent design. Register for Courses Student Login Module 2 – Modeling System Behavior with Use Cases

What is Use Case Modeling?
Object-Oriented Analysis - Instructor Notes 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. No system exists in isolation. Every system interacts with people or automated systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior. Use cases are the mechanism for capturing the desired behavior for the system that is under development, but they do not specify how the behavior is to be implemented. The UML specifies a model for communicating system behavior, the use-case model. Module 2 – Modeling System Behavior with Use Cases

Usages of a Use Case Model

The software development life cycle

Use Case Granularity Source:

Major Concepts in Use-Case Modeling
Object-Oriented Analysis - Instructor Notes 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 An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a 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. A use case describes what a system does, but it does not specify how it does it. Use Case Module 2 – Modeling System Behavior with Use Cases

What Are the Benefits of Use-Case Models?
Object-Oriented Analysis - Instructor Notes 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 This slide is part of the “Fundamentals of Visual Modeling with UML” course. Yes, you are selling the concept of a use-case model here. Many of your students may not immediately recognize the need for the use-case model because it is so simple. This slide is intended to bring out some of the problems that this model resolves. Feel free to add your own experiences here. There are many ways to model a system, each of which may serve a different purpose. However, the most important role of a use-case model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand. The Use-Case model is also used to identify the actors that interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs, ensuring that the system turns out to be what the users expected. Module 2 – Modeling System Behavior with Use Cases

System Surroundings and Actors
Object-Oriented Analysis - Instructor Notes 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 This slide outlines some actors that the requirements team can overlook. It is very important that all the actors for a system are identified up front since use cases are identified based on the system’s actors. For a Depot-Handling System, which supports the work in a depot, there are several categories of users: Depot Staff, Order Registry Clerk, Depot Manager. All these categories have specific roles in the system and you should therefore represent each one by a separate actor. In a recycling machine used for recycling cans, bottles, and crates, Customer is the main actor, the one for whom the system is primarily built. Someone has to manage the machine, however. This role is represented by the actor, Operator. A ventilation system that controls the temperature in a building continuously gets metered data from sensors in the building. Sensor is therefore an actor. An automated teller machine must communicate with the central system that holds the bank accounts. The central system is probably an external one, and should therefore be an actor. If you are building a Internet-based application, your primary actors are anonymous. You don't really know who they are, and you cannot make any assumptions about their skills and background. But you can still describe the role you expect them to play towards your system. Module 2 – Modeling System Behavior with Use Cases

Useful Questions in Finding Actors
Object-Oriented Analysis - Instructor Notes 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? Note that it is more useful to find actors before use cases. After you determine your audience (actors), you can determine the required functionality for your system. Think about the individuals who use the system. How can you categorize them? It is often a good habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs. The following questions may be useful when identifying 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? There are several different aspects of a system's surroundings that you will represent as separate actors. Users who execute the system's main functions Users who execute the system's secondary functions External hardware the system uses Other systems interacting with the system Actor Module 2 – Modeling System Behavior with Use Cases

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 One individual can play many different roles. For example, in the ATM problem, the same person could play the role of bank customer and bank teller. The actor should reflect the role and not the person. 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. Several users can play the same role, meaning they can be the same actor. In that case, each user constitutes an instance of the actor. However, in some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system. The same user can also act as several actors (that is, the same person can take on different roles). The actor's name must clearly denote the actor's role. Make sure there is little risk in the future of confusing one actor's name with another. Define each actor by writing a brief description that includes the actor's area of responsibility, and what the actor needs the system for. Because actors represent things outside the system, you need not describe them in detail. The brief description of the actor should include information about: What or whom the actor represents Why the actor is needed What interests the actor has in the system The brief description should be, at most, a few sentences long. Example: In the use-case model of the Recycling Machine, the three actors are briefly described as follows: Recycler: The Recycler collects bottles, cans, and crates at home and brings them back to the shop for a refund. Operator: The Operator is responsible for maintenance of the recycling machine. Manager: The Manager is responsible for questions about money and the service the store delivers to the customers. Minder as Professor Professor A User May Have Different Roles Minder as Student Student Module 2 – Modeling System Behavior with Use Cases

Use Case Modeling: Core Elements

Use Case Modeling: Core Relationships
<<extend>>

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

Example: Online HR System

Case Study: Course Registration Problem Statement
Object-Oriented Analysis - Instructor Notes 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. Direct the Students to the Course Registration Problem Statement in the Course Registration Requirements document. Give them an opportunity to read the problem statement themselves and discuss any questions, comments, or issues. If the students should question the length of the problem statement, tell them that every project is different with respect to the level of detail that is included in the Problem Statement. A Problem Statement can range from a few sentences to a multipage formal requirements document. The standards for these documents must be established and documented for each project. Do not spend too much time here. The goal is for them to have an understanding of the problem to be solved in the Course Registration System. Before you discuss the details of the artifacts which drive the analysis and design discipline, it is important that you understand the problem domain that is the basis for all of the course exercises. With regards to the formal Requirements artifacts, the Problem Statement is part of the Vision document. The other sections have been omitted for scoping reasons. For more information on the Vision document, see the Requirements discipline of the Rational Unified Process. Module 2 – Modeling System Behavior with Use Cases

Practice: Find the Actors
Object-Oriented Analysis - Instructor Notes 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 Give the class a few minutes to read the problem statement, then guide them in this practice. A session may start as follows. What is an actor? Walk the class through the questions for identifying actors. When someone identifies an actor, have him/her describe the actor. Make sure the class stays within the scope of the problem statement. Avoid trying to discover actors for scenarios that are not described here. Refer to the earlier questions that can be used to find an actor. Module 2 – Modeling System Behavior with Use Cases

Finding Use Cases: Focus on the Actor
Object-Oriented Analysis - Instructor Notes 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? A common question is “How do I find my use cases?” RUP suggests that you start with the actors and determine what functionality the system should provide to the actors, those then are your initial use cases. If the student would like further training on finding use cases you can recommend the Requirements Management with Use Cases (RMUC) course offered by Rational University. After you complete your first outline of the actors, the next step is to look for the system's use cases. The first use cases are very preliminary, and you may have to change them a few times until they are stable. If the system's vision or requirements are deficient, or if the system analysis is vague, the system's functionality will be unclear. Therefore, you must constantly ask yourself if you have found the right use cases. Furthermore, you should be prepared to add, remove, combine, and divide the use cases before you arrive at a final version. You get a better understanding of the use cases once you have described them in detail. The best way to find use cases is to consider what each actor requires of the system. Remember the system exists only for its users, and should therefore be based on the users' needs. You will recognize many of the actors' needs through the functional requirements made on the system. Module 2 – Modeling System Behavior with Use Cases

MOT Analysis Example: Credit Card
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 MOT: Moment of Truth

Practice: Solution Object-Oriented Analysis - Instructor Notes A person who is registered to take courses at the University The external system responsible for student billing At a minimum, your students should have discovered these actors. 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 These are some of the actors you should have found from the Problem Statement. These actors are used in the sample case study as you move forward in this course. The person who is responsible for the maintenance of the course registration system Registrar Module 2 – Modeling System Behavior with Use Cases

Name Use Cases 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. Register for Courses Login Each use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name. Maintain Student Information Module 2 – Modeling System Behavior with Use Cases

Practice: Finding Use Cases
Object-Oriented Analysis - Instructor Notes 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 Give the class a few minutes to read the problem statement, then guide them in this practice. A session may start as follows: Using the actors who have already been identified, what use cases can you find? Walk the class through the questions for identifying use cases. 2. When someone identifies a use case, have him/her describe the use case. 3. Make sure the class stays within the scope of the problem statement. 4. Avoid trying to discover use cases that cannot be supported by the problem statement. Refer to the earlier questions that can be used to find a use case. Remember to only identify use cases that can be supported by the Problem Statement. Module 2 – Modeling System Behavior with Use Cases

Practice: Solution Object-Oriented Analysis - Instructor Notes At a minimum, the students should have found these use cases (or something that is very close to these use cases). Register for Courses View Report Card Login Select Courses To Teach Close Registration Maintain Professor Information Maintain Student Information Submit Grades These are some of the use cases you should have found from the Problem Statement. These use cases will be used in the sample case study as you move forward in this course. Module 2 – Modeling System Behavior with Use Cases

Use Cases and Actors Object-Oriented Analysis - Instructor Notes 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. The communicate-association can also be drawn in the other direction. A use case can initiate communication with an actor. Usually, this occurs with a nonhuman actor. a use case: . . .describes a sequence of actions, performed by a system, that yields a result of value to the user. It is important to show how actors relate to the use case. Therefore, on finding a use case, establish the actors that interact with it. To do this, you must define a communicate-association that is navigable in the same direction as the transmission between the actor and the use case. Actors may be connected to use cases only by an association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one able to send and receive messages. Module 2 – Modeling System Behavior with Use Cases

Concept: Communicate-Association
Object-Oriented Analysis - Instructor Notes Use cases and actors interact by sending signals to one another. To indicate such interactions, use a communicate-association. The communicate- association is modeled as an association between the actor and the use case. The <<communicates>> stereotype does not have to be displayed because this is the only kind of association between actors and use cases. Use cases and actors interact by sending signals to one another. To indicate such interactions, use a communicate-association between use case and actor. A use case has at most one communicate-association to a specific actor, and an actor has at most one communicate-association to a specific use case, no matter how many signal transmissions there are. The complete network of such associations is a static picture of the communication between the system and its environment. Communicate-associations are not given names. Because there can be only one communicate-association between a use case and an actor, you need only specify the start and end points to identify a particular communicate-association. Use cases may not communicate directly with each other using a communicates-association. However, they may communicate indirectly through shared actors. Use Case Actor Communicate-Association Module 2 – Modeling System Behavior with Use Cases

Practice: Use Case and Actor Communication
Object-Oriented Analysis - Instructor Notes 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. Give the class a few minutes to read the problem statement, then guide them in this practice. A session may start as follows: using the actors and use cases that have already been identified, what communicate-associations can you find? Module 2 – Modeling System Behavior with Use Cases

Use Case and Actor Communication
Object-Oriented Analysis - Instructor Notes Course Catalog View Report Card Register for Courses Submit Grades Select Courses to Teach Student Professor Billing System Maintain Student Information Maintain Professor Information Login Close Registration Registrar Congratulate the students! They have just built their first use-case diagram. Review the questions in the student notes with the class. This exercise should help them understand what a rich communication tool that a use-case diagram can be. “Which use case comes first, Register for Courses or View Report Card?” Of course, this is a trick question. You can’t make that assumption from looking at this model. It isn’t intended to show order. These are some of the communicate-associations you should have found. Use these communicate-associations in the sample case study as you move forward in this course. You have just built your first use-case diagram. See if you can use the diagram to answer the following questions. 1. Which use cases is a student able to perform? A professor? The Course Catalog? 2. If Charlie is a student and professor, which use cases can he execute? 3. Describe the functionality of this system. 4. Describe the actor relationships for the Close Registration and Select Courses to Teach use cases. 5. What doesn’t this model say? 6. Which use case needs to run first, Register for Courses or View Report Card? Module 2 – Modeling System Behavior with Use Cases

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.

Use-Case Specifications
Object-Oriented Analysis - Instructor Notes Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams Use-Case Specifications ... Use-Case Model Actors Use Cases The flow of events is understood by the customer. The flow of events describes how and when the use case starts and ends, when the use case interacts with the actors, and the information exchanged between an actor and the use case. The flow of events does not describe user interface details. A use-case specification contains all textual information for a use case. A use case model contains the properties of a use case, including diagrams. Note that a use-case model is a use-case specification AND diagram. The use case has a set of properties as shown in the graphic. The use case properties may be documented in use-case specifications, which may include: Brief description describes the role and purpose of the use case in a few lines. Flows of events are textual descriptions of what the system does with regard to the use case. There may be multiple flows of events, for example, a basic flow and alternative flows. Relationships are communicate-associations. The use case includes and extends relationships that the use case participates in. Activity diagrams can be used to illustrate the structure of the flow of events. Use-case diagrams can be used to show the relationships involving the use case. Special requirements is a textual description that collects all use-case requirements, like nonfunctional requirements that are not considered in the use-case model, yet need to be taken care of during design or implementation. Preconditions define a constraint on the system for when the use case may start. Postconditions define a constraint on the system for after the use case has terminated. Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen dumps from a user-interface prototype. Module 2 – Modeling System Behavior with Use Cases

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 …

Use Case Flow of Events Has one normal, basic flow  Happy Case Several alternative flows Regular variants of the basic flow Odd cases Exceptional flows handling error situations In the Maintain Student Information use case, there may be separate subflows for adding, deleting, and modifying student information. Don’t be too concerned with the exact definition “basic” versus “alternate or exception.” Readability and understandability are key here. Note: The colors are not distinguishable in the black and white books. That’s okay. The picture still provides value as the alternate flows are visible. A use case’s flow of events: Contains the most important information derived from use-case modeling work. Should describe the use case's flow clearly enough for an outsider to easily understand it. Should present what the system does, not how the system is designed to perform the required behavior. A use case’s Contents Guidelines: Details the flow of events. All "what“ questions should be answered. Remember that test designers use this text to identify test cases. Describes how the use case starts and ends. Describes the flow of events, not only the functionality. To reinforce this, start every action with "When the actor. . .” Describes only the events that belong to the use case and not what happens in other use cases or outside the system Describes the data exchanged between the actor and the use case. Does not describe the details of the user interface unless it is needed to understand the behavior of the system. Avoids vague terminology such as "for example", "etc. " and "information." Module 2 – Modeling System Behavior with Use Cases

What Are Scenarios? Object-Oriented Analysis - Instructor Notes A scenario is an instance of a use case In the same way that an object is an instance of a class, a scenario is an instance of a use case. A scenario is an instance of a use case. It is one flow through a use case. Each use case has a web of flows of events with a scenario being an instance of a particular flow of events. The scenario may involve the basic flow and any number of alternative flows in any number of combinations. In the above example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described. How many scenarios are needed? Simple answer: as many as one needs to understand the system being developed. You should elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate the use case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios. Scenarios make excellent test cases. Module 2 – Modeling System Behavior with Use Cases

Glossary Object-Oriented Analysis - Instructor Notes The Glossary does not document things purely in the solution space, such as mechanisms, key abstractions related only to the solution space, architectural patterns being used, and the like. Do not overload the Glossary with those sorts of things - it’s primarily a ‘user-oriented’ document. The SAD is better at communicating the common architectural “house rules”. A template for the Glossary ships with the Rational Unified Process. 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.1 Course: A class offered by the university. 2.2 Course 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.3 Course Catalog: The unabridged catalog of all courses offered by the university. Glossary The Glossary defines important terms used in the project. There is one Glossary for the system. This document is important to many developers, especially when they need to understand and use the terms that are specific to the project. The glossary is used to facilitate communications between domain experts and developers. The Glossary is developed primarily during the inception and elaboration phases, because it is important to agree on a common terminology early in the project. In Inception/Elaboration, it is used by domain experts (for example, business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration/Construction, developers use the Glossary to explain technical terms used in the other four models. A system analyst is responsible for the integrity of the Glossary, ensuring that the Glossary is produced in a timely manner and is continuously kept consistent with the results of development. The above slide is just a sample outline for the Glossary. Not all of these elements need to be in the Glossary. A project needs to establish the template to be used on that particular project. Introduction: A brief description of the glossary and its purpose. Terms: Define the term in as much detail as necessary to completely and unambiguously characterize it. Module 2 – Modeling System Behavior with Use Cases

Supplementary Specification
Object-Oriented Analysis - Instructor Notes Functionality Usability Reliability Performance Supportability Design constraints Those nonfunctional requirements that can be tied to a particular use case should be documented in the use case “special requirements” property. The Rational Unified Process ships with templates for the supplementary specification. Supplementary Specification The nonfunctional requirements and functional requirements not captured by the use cases are included in the supplementary specifications. The Supplementary Specifications include constraints on the implementation. Functionality: List of the functional requirements that are general to many use cases. Usability: Requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements or training requirements that specify how readily the system can be used by its actors. Reliability: Any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or defects per thousand lines of code should be stated. Performance: The performance characteristics of the system. Include specific response times. Reference related use cases by name. Supportability: Any requirements that enhance the supportability or maintainability of the system being built. Design Constraints: Any design constraints on the system being built. Supplementary Specifications go hand in hand with the use-case model, implying that: They are initially considered in the inception phase as a complement to defining the scope of the system. They are refined in an incremental fashion during the elaboration and construction phases. Online Resource: Module 2 – Modeling System Behavior with Use Cases

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? Complete checklists are provided in the online Rational Unified Process. A normal system has 20 to 50 use cases. A very large system has no more than 100 use cases. The number of use cases is more a measure of the complexity of the interaction between the system and the actors. A big, but simple, system may have a few use cases, but a small system (that may be complex to build) may have lots of use cases. The number of use cases a project may initially identify may be large (because they are doing functional decomposition). The idea of fewer use cases helps to push them towards the real usage of use cases - thinking of functionality rather than algorithms when doing functional requirements analysis. The above, as well as the remaining checklists in this section, is a sample of the kinds of things to look for when reviewing the use-case model. Explicit, detailed checklists should be established for the project to support the review of the use-case model. Verify that there are no open questions. The use cases you found must be able to perform all system behaviors; if not, some use cases are missing. If you intentionally left any requirements to be dealt with in the object models, such as nonfunctional requirements, you must mention this. Put the reference in the Supplementary Specification(s) unless the requirement concerns a specific use case, in which case state it in the Special Requirements section of the use case. The use-case model should not present more functions than were called for in the requirements. Traceability from the original requirements to the use cases and the Supplementary Specification is critical for project management, impact assessment and to make sure nothing has been missed. The packaging should make the use-case model simple and intuitive to understand and maintain. Module 2 – Modeling System Behavior with Use Cases

Verify Actors Object-Oriented Analysis - Instructor Notes 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? Make sure that all the roles in the system's environment have been accounted for and modeled. You won’t be able to do this fully until you have found and described all the use cases. Remove any actors not mentioned in the use-case descriptions or that have no communicate-associations with a use case. However, an actor mentioned in a use-case description is likely to have a communicates-association with that particular use case. You should be able to name at least two people who would be able to perform as a particular actor. If not, see if the role the actor models is part of another role. If so, you should merge the actors. If any actors play similar roles in relation to the system, they should be merged into a single actor. If a particular actor uses the system in several completely different ways, or has several completely different purposes for using the use case, then there should probably be more than one actor. If two actors play the same role in relation to a use case, then actor-generalizations should be used to model their shared behavior. It is important that actor names correspond to their roles. Module 2 – Modeling System Behavior with Use Cases

Verify Use Cases Object-Oriented Analysis - Instructor Notes 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? Note: These checkpoints really only apply to concrete use cases, not use cases that extend other use cases or are used by other use cases. Use-case uses and extends are not covered in this course for scoping reasons. A use case that does not interact with an actor is superfluous. You should remove it. If two use cases are always activated in the same sequence, you should probably merge them into one use case. Use cases that have very similar behaviors or flows of events, or are similar in the future, should be merged into a single use case. This makes it easier to introduce future changes. Note: you must involve the users if you decide to merge use cases because the users, who interact with the new, merged use case, is probably affected. If some part of the flow of events is already part of another use case, the subflow should be extracted and then be used by all of the use cases in question. Note: you must involve the users if you decide to reuse the subflow, because the users of the existing use case are probably affected. Each use-case name must describe the behavior the use-case supports. The names and descriptions must be understood by the users and customers. Module 2 – Modeling System Behavior with Use Cases

Verify Use-Case Specifications
Object-Oriented Analysis - Instructor Notes 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? Include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements. Behavior might exist that is activated only when a certain condition is not met. There should be a description of what happens in such a case. If you want your use-case model to be easy to understand, you might have to split up complex use cases. A use case that contains disparate flows of events is very difficult to understand and to maintain. It is best to divide such use cases into two or more separate use cases. Module 2 – Modeling System Behavior with Use Cases

Verify Glossary Object-Oriented Analysis - Instructor Notes 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? If each glossary term is not included somewhere in the use-case descriptions, that may imply that a use case is missing or that the existing use cases are not complete. It is more likely, though, that the term is not included because it is not needed, and it should be removed from the glossary. A term should represent the same thing in all use-case descriptions. Module 2 – Modeling System Behavior with Use Cases

Library System Use Case
Object-Oriented Analysis - Instructor Notes 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 Solution: Module 2 – Modeling System Behavior with Use Cases

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.

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?

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

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

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.

Review Questions Object-Oriented Analysis - Instructor Notes 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? Question 1: The use-case model, supplementary specifications and the glossary are the main artifacts of Requirements. Question 2: The Use-Case Model describes what the system does. The Supplementary Specification contains those requirements that don’t map to a specific use case. The Glossary defines a common terminology for all models. Question 3: It is a model of the system's intended functionality and its environment. The use-case model serves as a contract between the customer and the developers. Question 4: An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Question 5: 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. The use case properties may be documented in use-case specifications, which may include: brief description, flow of events, relationships, activity diagrams, use-case diagrams, etc. Question 6: A scenario is an instance of a use case. It is one flow through a use case. Module 2 – Modeling System Behavior with Use Cases

Exercise Object-Oriented Analysis - Instructor Notes Create a payroll system for restaurants and hotels. Make certain that the usual deductions are taken into consideration. The payroll must accommodate both salaried and hourly employees. The waiters are salaried employees, but the busboys are hourly employees. The payroll system must print checks weekly. The system will produce a payroll register which will be turned over to auditors monthly. Income and tax reports (such as W-2s* in the U.S.) must be prepared according to legal requirements. Reports concerning voluntary deductions will be prepared for various agencies on a quarterly basis. ? The payroll must treat part-time employees as hourly employees. Full-time employees and salaried employees may take advantage of the various company benefits, part-time employees may not. Restaurant employees will be able to eat meals at their restaurant but will have the cost of the meals deducted from their paycheck. Hotel employees will have room costs deducted if they live in the hotel. There are voluntary deductions and mandatory government deductions that must be taken into account. *W-2 = U.S. annual income statement Continued… The purpose of this exercise is for students to create a use-case model. Break students into groups, no more than four students per team. Each group should work separately since you to want to compare each group’s results at the conclusion of the exercise. Show the students where to find the problem statement. At the end of this exercise, students should understand that while use-case models are fairly easy to understand, they are not that easy to build! Use this exercise to revisit some of the slide topics and possibly to answer more detailed questions. The goal of this exercise is for you to model the system behavior of the Payroll System. The problem statement is under the “Problem Statement” tab in the Payroll System Requirements document. Do not to look ahead in the Requirements document for the answers! Module 2 – Modeling System Behavior with Use Cases

Exercise Object-Oriented Analysis - Instructor Notes Identify for the Payroll System Actors Use cases Name the use cases Produce the use-case model for the Payroll System. Provide: Actor descriptions Brief use-case descriptions Compare your results to other groups. Are there differences? Why? How would you resolve these differences? Review which items the class is responsible for identifying. If necessary, quiz the class on questions that can be helpful in finding use cases and actors. Review the importance of a good use-case name. Using the Problem Statement, identify potential actors for the Payroll System. Remember, actors are external to the system and can initiate communication or be passive participants with the system. Refer to the following slides, if needed. Useful Questions in Finding Actors, p. 2-14 After you’ve identified all the actors for the Payroll System, identify potential use cases. Use cases are defined as 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. Remember that the use case should represent a full series of actions and not a number of individual operations. Refer to the following slides if needed. How to Find Use Cases, p. 2-22 Naming the Use Case, p. 2-23 For the final part of this exercise, each group will discuss its use-case model. As a class, attempt to homogenize your models into one final use-case model. Finally, compare your use-case model to the one in the course solution. Module 2 – Modeling System Behavior with Use Cases

Use Case Diagram UML Notation Guide

Use Case Relationships
Object-Oriented Analysis - Instructor Notes Use Case Relationships <<includes>> and <<extends>> Fig. 3-45, UML Notation Guide Module 2 – Modeling System Behavior with Use Cases

Actor Relationships

Online HR System: Use Case Relationships

Online HR System: Update Benefits Use Case
Actors: employee, employee account db, healthcare plan system, insurance plan system Preconditions: Employee has logged on to the system and selected "update benefits" option Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. … Alternative courses If health plan is not available in the employee’s area the employee is informed and asked to select another plan...

Model user requirements with use cases.
When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method start with use cases and derive your structural and behavioral models from it. If you are not using a use-case driven method make sure that your use cases are consistent with your structural and behavioral models.

Use Case Modeling Tips Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams Factor out common usages that are required by multiple use cases If the usage is required use <<includes>> or <<uses>> If the base use case is complete and the usage may be optional, consider use <<extends>> A use case diagram should contain only use cases at the same level of abstraction include only actors who are required Large numbers of use cases should be organized into packages

Set Display Options

A Use Case Diagram Created in Visio

Display Options for Communications

Model Explorer Linking an Linking a model element to another diagram

Exercise: Automated Teller Machine (ATM)
Brief Statement of Purpose: An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement Additional Notes: Users shall be able to access the ATM by punching in their account number and PIN. Once the system has verified that the account is active and the PIN matches with the account number, the system offers the users four choices. Users can withdraw money, deposit money, check balance or quit the session. The user must have a minimum of $100 in his / her account. At the end of any transaction a printed copy of the transaction is provided to the user. A transaction could be - withdraw money, deposit money or check balance. Once the user has completed a transaction, the system offers the user the same four choices, until the user decides to quit.

Requirements Brief Summary of Requirements: The ATM is required:
1. To allow authorized card holders to make transactions 1. Card holders shall view and/or print account balances 2. Card holder shall make cash withdrawals 3. Card holder shall make cash or check deposits 4. Card holder shall quit session 2. To allow bank members to access additional, special services 1. A bank member shall be able to order a statement 2. A bank member shall be able to change security details (e.g. PIN number) 3. To allow access to authorized bank staff 1. Authorized staff can gain access to re-stock the machine 2. Authorized staff are able to carry out routine servicing and maintenance 4. To keep track of how much money it contains and alert bank staff when stocks are getting low.

Exercise Requirements
Identify the actors Identify the uses cases Draw the top level Use-Case diagram Develop a detailed Use-Case analysis for a use case. Your analysis should contain a brief description of the use case, the basic and alternative flows, pre and post conditions.

The authoring life cycle of Use Cases

Context of a System The whole is more than the sum of the parts
The whole determines the sum of the parts The parts cannot be understood if considered in isolation from the whole The parts are dynamically interrelated and interdependent -- Fredrick Hagel ( )

UML Use Case Modeling.

Similar presentations

Presentation on theme: "UML Use Case Modeling."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

UML Use Case Modeling.

Similar presentations

Presentation on theme: "UML Use Case Modeling."— Presentation transcript:

Similar presentations

About project

Feedback