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

Slides:



Advertisements
Similar presentations
Use Case & Use Case Diagram
Advertisements

Chapter 7 Structuring System Process Requirements
Information System Engineering
CS3773 Software Engineering Lecture 03 UML Use Cases.
Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l.
Systems Analysis and Design in a Changing World, Fourth Edition
SwE 313 Case Study Registration System.
Documenting Requirements using Use Case Diagrams
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Use Case Modeling.
Use Case Modeling. Kendall & Kendall© 2005 Pearson Prentice Hall18-2 Commonly Used UML Diagrams The most commonly used UML diagrams are: – Use case diagram,
Chapter 7 Structuring System Process Requirements
RUP Requirements RUP Artifacts and Deliverables
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Scenario A scenario is a sequence of steps describing an interaction between a user and a system. Use case is a set of scenarios tied together by a common.
Systems Analysis and Design in a Changing World, Fourth Edition
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
Chapter 6: Structuring Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Use Case Diagrams. Introduction In the previous Lecture, you saw a brief review of the nine UML diagrams. Now that you have the clear, you'll start to.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Use Cases. 2 A use case... –Specifies the behavior of a system or some subset of a system. –Is a system-level function. –Does not indicative how the specified.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Use Cases Discuss the what and how of use cases: Basics Examples Benefits Parts Stages Guidelines.
Use Cases Preparation for Thursday 10/2/14. Process or Workflow Model Concepts Representing task, process, procedure, workflow, actions, decisions Functional.
 Sequence Diagrams Introduction.  Sequence Diagrams  Review Schedule Sheridan.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Use Case Analysis Chapter 6.
Systems Analysis and Design in a Changing World, Fourth Edition
Using Use Case Diagrams
Chapter 4: Business Process and Functional Modeling, continued
Business System Development
Chapter 5 System modeling
CMPE 280 Web UI Design and Development August 29 Class Meeting
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases Discuss the what and how of use cases: Basics Benefits
Lec-5 : Use Case Diagrams
Recall The Team Skills Analyzing the Problem (with 5 steps)
Storyboarding and Game Design SBG, MBG620 Full Sail University
Use Case Model.
Use case Diagram.
Use Case Model Use case diagram.
UML Activity Diagrams.
SE-565 Software System Requirements IV. Use Cases
Concepts, Specifications, and Diagrams
IMPORTANT NOTICE TO STUDENTS:
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Systems Analysis and Design in a Changing World, 6th Edition
Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer
Chapter 9 Use Cases.
Week 12: Activity & Sequence Diagrams
Object Oriented Analysis and Design
Use Cases.
Software Design Lecture : 15.
Use Case Model Use case diagram – Part 2.
Using Use Case Diagrams
Seminar 2 Design of Informatics Systems
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Interaction Modeling Extracted from textbook:
Engineering Quality Software
Use Case Modeling Part of the unified modeling language (U M L)
CS 425 Software Engineering
Welcome 1 This is a document to explains the chosen concept to the animator. This will take you through a 5 section process to provide the necessary details.
Use cases Dr. X.
Presentation transcript:

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

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

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.

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.

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.

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

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

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.

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.

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

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

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

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

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.

Use case for validating location

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

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.