Presentation is loading. Please wait.

Presentation is loading. Please wait.

Class 11 Outline Business – Qs on artifact model assignment? – Qs on draft project models? Activities – Card Sorting – Use Cases.

Similar presentations


Presentation on theme: "Class 11 Outline Business – Qs on artifact model assignment? – Qs on draft project models? Activities – Card Sorting – Use Cases."— Presentation transcript:

1 Class 11 Outline Business – Qs on artifact model assignment? – Qs on draft project models? Activities – Card Sorting – Use Cases

2 Work Model Concepts (1) Representing task, process, procedure, workflow, actions, decisions Functional decomposition – Given a task, what are its subtasks? – Given a subtask, what are its subtasks? – and so on. Endpoint will be individual steps that can be implemented in the system Task: Apply to Graduate School Subtasks: identify schools, take GREs, write essay, request recommendation letters, … Subtask: take GREs sub-subtasks: find a testing site, register for a test date, study, sleep well, show up… Task subtask sub- subtask

3 Use Cases The term “use case” is over-used. Sometimes it refers to a broad overview like a scenario, and is similar to a business case to describe and justify the system development. In UML, it has a more specific definition. A Use Case models how the user(s) and the system interact. The boundary of the system and the system subcomponents are more clearly specified. – Can be high-level overview or more specific task (leveled). – Think about what has to occur, without getting bogged down on how it must occur. Can be a diagram or a text form.

4 Use Case Diagram Components The system and system boundary Actors who interact with the system – people, groups of people (e.g., departments, personas) – other systems High-level tasks or functions that actors need the system to do Connections between actors and use cases: how they communicate Connections between tasks or functions: expected sequence of events.

5 Use Case Example Domain Weather-R-Us operates an extensive website dedicated to all things weather- related. It wants to update the website to better attract and serve users. They have started to develop use cases for the functions they want to maintain, as well as for new attractions. Example use cases: Check 3-day forecast for location X is a use case aimed at the no-nonsense user who just needs to see a short-term forecast. Examine historical records for location X is a use case that will help users learn what the weather was like on a particular date, or to compare “old” weather with current weather. (In these use case titles, “X” stands for the location for which the user wants information. ) The next 2 slides show a high-level overview use case of the proposed Weather- R-Us website, with arrows pointing out the components. The slide after them gives more explanation of the use case.

6 High Level View system boundary actors (person) actors (other systems)

7 High Level View connections between actors and tasks major tasks of the Weather-R-Us system

8 Notes on the High Level View. This diagram was drawn using Visio. Purpose: give a broad view of (1) the major functions (tasks) of the proposed system, (2) who will use the system, and (3) the other systems that support the system. The system boundary is represented by the box. Actors (people, systems): are outside the system boundary descriptive name human actors represent the system users system actors, e.g. backend databases that contain the information needed for the tasks. tasks can decompose into lower-level use cases to describe the sub-tasks within it. Connections: plain lines, not arrows.

9 Use Cases: Diagram components plain lines (not arrows) for interactions If actor always initiates interaction, you may point an arrow from the actor to the use case Uses, or includes is a keyword with a special arrow. – Task 1 uses task 2 if 2 is always a component of 1. – Similar to a subroutine or defined function in programming – includes was used in the original UML, replaced by uses in UML 2.0 Extends is a keyword and special arrow – Task 2 extends task 1 if 2 can be a component of 1. – 2 is an option There are other components, but this is a good basic set to get started with.

10 This use case represents one of the functions shown on the high level view. Only actors involved in the use case are shown. The functions are sub-tasks of the use case. extends first step final step

11 Check 3-day forecast for location X functionally decomposes task from high level view into its subtasks. actors: Practical User, Location Database, and Forecast Database. connections between tasks indicate their sequence; you could use arrows pointing to the next task instead. Practical User selects “3-day forecast” service selects location by entering a zipcode or city and state. system looks up location ID in Location Database, and if validated, use ID to look up the forecast in the Forecast Database. display forecast to Practical User Note focus on what happens, not how it happens. For example, the forecast could be displayed as text, or a diagram, or an audio file, etc. extends “If invalid, show…” is an optional task used only if location ID is invalid error handling

12 Use Cases: Text Template Miles & Hamilton (2006) template for text Use Cases. more detailed information in the text may be better for documentation. – Use case name – Related Requirements – drawn from the client RFP, your information gathering, a scenario, or other source – Goal In Context – what the case accomplishes – Preconditions – what has to occur, or be true for the use case to work; the state of the system or state of the world – Successful End Condition – state of system – Failed End Condition – state of system – Primary Actors – often the initiator – Secondary Actors – other participants – Trigger – what causes use case to execute – Main Flow – sequence of actions

13 Use Case NameCheck 3-day forecast for location X Related RequirementsUsers should have a choice of ways to select the location. Users should have a choice of ways to view the forecast. Goal In ContextAllow user to select location; system displays 3-day forecast PreconditionsLocation must be in Location Database Successful End ConditionSystem displays 3-day forecast Failed End ConditionSystem gives user another chance to enter valid location. If location isn’t in database, no forecast can be displayed Primary ActorsPractical user Secondary ActorsLocation Database, Forecast Database TriggerPractical user selects the "3-day-forecast" service Main FlowStepAction 1User selects the "3-day-forecast" service 2User enters location name: zip code or city and state 3System looks up location identifier in Location Database 3aIf invalid location, system shows error message and prompts user to try again 4System uses valid location identifier to look up 3-day forecast in Forecast Database 5System displays 3-day-Forecast

14 uses (includes) Compare the use case diagrams for the 3-day forecast and the historical records. Notice that they both require the user to select a location by entering a zipcode or city and state. The system looks up the location ID in the location DB, and if the location is invalid, gives the user a second chance (using the “extends” arrow). Weather is closely tied to location: imagine how many times this sequence would be repeated in the full set of Weather-R-Us use cases! Good design practice suggests that the location validation sequence should be defined once. Each use case that needs it can incorporate it by referring to the definition. 1.Define the frequently-used sequence as a use case, Enter and verify location identifier 2.In the 3-day forecast use case, remove the sequence and substitute a single task bubble labeled Enter and verify location identifier 3.The “uses” arrow that points to it indicates that it is itself defined as a use case. 4.Do the same wherever location validation is needed.

15 Use case for validating location

16 Check 3-day forecast for location X using Enter and verify location identifier refers to use case indicates use case definition

17 The Storm Tracker The high level Use Case for Weather-R-Us includes the Storm Tracker, who wants to monitor an ongoing storm system such as a hurricane or blizzard from the comfort of his/her computer. 1.Define a brief persona for the Storm Tracker 2.Design the Storm Tracker’s Monitor Ongoing Storm System use case. Use the diagram form. – How does the Storm Tracker interact with the system? What are the subtasks? – You can use Enter and verify location identifier, if needed. – Do you need to use extends? 3.Sketch the use case diagram on a board.


Download ppt "Class 11 Outline Business – Qs on artifact model assignment? – Qs on draft project models? Activities – Card Sorting – Use Cases."

Similar presentations


Ads by Google