The use case diagram can be based on the projects you are working on in this class. It can either be the current AS-IS system or the proposed TO-BE system (or the value proposition). 1. Who are the actors that use the system? 2. What are the main “things” (functional requirements) these actors do? 3. Based on the actors and use cases, draw a use case diagram (see the video and restaurant example on D2L on Assignments and Week 5). 4. Create one expanded use case description (a Word template is available on D2L). It fine to create some high-level use cases, too.
Template For an Expanded Use Case* Use Case: Name of the use case as it appears in the use case diagram Preconditions: What must take place before the use case begins Trigger What happens to trigger or initiate the use case Actors: List of actors associated with the use case Goal: The goal or purpose of the use case Overview: High-level description of the use case Related Use Cases: Uses cases that are included with other use cases Successful course of events Describes the typical course of events in terms of the actor input and the system response Actor action System response Alternative courses This section describes the main alternative courses of action *Feel free to use a variation of this template. Lab 3-Use Cases Lab 3: Use Case Diagram and Descriptions Introduction The use case model consists of a use case diagram, a set of use case descriptions, a set of actor descriptions and a set of scenarios. The use case diagram models the problem domain graphically using four concepts: the use case, the actor, the relationship link and the boundary. Using the Wheels Case Study, the UML symbols used to model these concepts are shown in here (and also in Fig. 3-12, p. 81 of the textbook). Below is an example of a use case of the Wheels case study. The functionality of the new system has been divided into five use cases: 'Maintain bike list', 'Maintain customer list', 'Handle enquiries', 'Issue bike' and 'Handle bike return'. Conceptually a use case diagram is similar to a top-level menu which lists the five main things that the system does. MISOnlineMIS-541 InformationSystemsAnalysis&Design USE CASES USE CASE DIAGRAM 41 Receptionist System boundary @ A use case: an ellipse labelled wi th the name of the use case. Conventionally we start each use case name wi th a verb to make the point that use cases represent processes. So we have 'Maintain customer list' ra ther than 'Customer list', 'Handle enquir ies ' ra ther than 'Enquiries ' . An actor: a stick figure labelled wi th the name of the actor. We capitalize actor names so that they are easy to ident ify as such (e.g. Administrator , Receptionist). The stick figure icon is used even when the actor is non-human, e.g. another computer system or an organization. A use case relationship: a line l inking an actor to a use case. The line shows us which actors are associated wi th which use cases. This relat ionship is also k n o w n as a communicat ion association. Receptionist The boundary : a line drawn round the use cases to separate them from the actors and to delineate the area of interest. Can be labelled to indicate the diagram domain. The b o u n d a r y is often omitted. Figure 3.1 The UML symbols for use case diagrams Figure 3.2 cases: 'Maintain bike list', 'Maintain customer list', 'Handle enquir ies ' , 'Issue bike' and 'Handle bike re turn ' . Conceptual ly a use case diagram is similar to a top-level menu which lists the five main things that the system does. Each use case is l inked by a line to an actor. The actor, represented by a stick figure, is the person (sometimes a computer system or an organization) who uses the system in the way specified in the use case or who benefits from the use case. Admin~ist Recep~fio Use case diagram for Wheels TheUseCase When identifying use cases, the task is to divide up the system’s functionality into chunks, into the main system activities. What dictates the split is what the user sees as the separate jobs or processes, i.e., the tasks he or she will do using the system. In use cases, we are just attempting to capture the user’s view of the system. Identifying use cases from scenarios. Another approach to identifying use cases is to start with scenarios. As mentioned in the Wheels case study, a scenario describes a series of interactions between the user and the system in order to achieve a specified goal. A scenario describes a specific sequence of events, for example what happened when Annie successfully issued a bike to a customer. Each use case represents a group of scenarios. Scenarios belonging to the same use case have a common goal, such that each scenario in the group describes a different sequence of events involved in achieving (or failing to achieve) the use case goal. There are a lot of details, but the example below is a scenario belonging to the 'Issue bike' use case. MIS 541 Online Page ! of !2 5 USE CASES USE CASE DIAGRAM 41 Receptionist System boundary @ A use case: an ellipse labelled wi th the name of the use case. Conventionally we start each use case name wi th a verb to make the point that use cases represent processes. So we have 'Maintain customer list' ra ther than 'Customer list', 'Handle enquir ies ' ra ther than 'Enquiries ' . An actor: a stick figure labelled wi th the name of the actor. We capitalize actor names so that they are easy to ident ify as such (e.g. Administrator , Receptionist). The stick figure icon is used even when the actor is non-human, e.g. another computer system or an organization. A use case relationship: a line l inking an actor to a use case. The line shows us which actors are associated wi th which use cases. This relat ionship is also k n o w n as a communicat ion association. Receptionist The boundary : a line drawn round the use cases to separate them from the actors and to delineate the area of interest. Can be labelled to indicate the diagram domain. The b o u n d a r y is often omitted. Figure 3.1 The UML symbols for use case diagrams Figure 3.2 cases: 'Maintain bike list', 'Maintain customer list', 'Handle enquir ies ' , 'Issue bike' and 'Handle bike re turn ' . Conceptual ly a use case diagram is similar to a top-level menu which lists the five main things that the system does. Each use case is l inked by a line to an actor. The actor, represented by a stick figure, is the person (sometimes a computer system or an organization) who uses the system in the way specified in the use case or who benefits from the use case. Admin~ist Recep~fio Use case diagram for Wheels A use case is a complete end-to-end use of the computer, a complete path through the system. A use case must deliver some benefit to the actor associated with it; it must have a goal. Each use case will have several scenarios associated with it. Some will be successful, i.e. achieve the use case goal, some will not. The software developer needs to be aware of all possible scenarios because the system must be able to cope with them all and respond appropriately. UseCaseDescrip,ons The use case description is a narrative document that describes, in general terms, the required functionality of the use case. Typically it describes the use case goal and gives a general description of what usually happens, the normal course of events, adding a brief description of any minor variations. The description is written in terms of what the system should do, not how it should do it. What happens behind the scenes in terms of coding, data storage structures and other implementation details is not relevant in a use case description, only what the user sees happening. In other words, the use case describes the system as the user sees it. High-level description. It is useful to have two distinct types of use case description. In the early stages of software development, when no detailed decisions have been made about the design of the system and particularly the design of the user interface, it is enough to have short, unstructured descriptions, known as high- level descriptions. These descriptions need only document the purpose of the use case, the actors involved and give a general overview of what happens. Here is an example: MIS 541 Online Page ! of !3 5 USE CASES THE USE CASE 43 scenario describes a specific sequence of events, for example what happened when Annie successfully issued a bike to a customer (see Figure 3.3). Depending on the stage they have reached, system developers can use scenarios to describe what did actually happen (or might typically have happened) on one occasion or how they want things to happen in the new system. A careful study of scenarios depicting both typical and exceptional uses of the system is a very good way to understand what the system does and how it is used. It~ a bottom up approach to understanding a system. You start by looking at the details of how the system is used and from this work out what the overall aims and objectives are and from this what the use cases are. Each use case represents a group of scenarios. Scenarios belonging to the same use case have a common g o a l - each scenario in the group describes a different sequence of events involved in achieving (or failing to achieve) the use case goal. Figures 3.3 and 3-4 describe scenarios belonging to the 'Issue bike' use case; in both cases Annie is trying to issue a bike to a customer. 9 Stephanie arrives at the shop at 9.ooam one Saturday and chooses a mountain bike 9 Annie sees that its number is 468 9 Annie enters this number into the system 9 The system confirms that this is a woman~ mountain bike and displays the daily rate (s and the