Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck

Slides:



Advertisements
Similar presentations
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Advertisements

CPSC 333: Foundations of Software EngineeringJ. Denzinger 2.2. Use Cases: Scenario based requirements modeling Recommended: Booch, Rumbaugh, Jacobson:
Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Object-Oriented Analysis and Design
Use Cases Elizabeth Bigelow CS C 9/15/2000.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Use Case Modeling. Watch the video on use cases Review at minute 2:41-3:37.
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Use Cases 1. Last week  Introduction to software engineering  How is it different from traditional engineering?  Introduction to specification  Operational.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Use Case Model Use case diagram.
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.
Unified Modeling Language User Guide Section 4 - Basic Behavioral Modeling Chapter 16 - Use Cases Chapter 17 - Use Case Diagrams.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Unified Modeling Language Introduction.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Unified Modeling Language Introduction.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Introduction to the Unified Modeling Language.
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.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Pepper modifying Sommerville's Book slides
Using Use Case Diagrams
Chapter 5 System modeling
Use Case Modeling - II Lecture # 27.
Chapter 5 – System Modeling
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Introduction to the Unified Modeling Language
Architecture Concept Documents
Department of Computer Science
Use Case Model.
Business Models Modeling.
Use Case Model Use case diagram.
Week 10: Object Modeling (1)Use Case Model
UML Use Case Diagrams.
System Modeling Chapter 4
Requirements: Use Case Models and Narratives
By Dr. Abdulrahman H. Altalhi
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer
Chapter 9 Use Cases.
Object Oriented Analysis and Design
Introduction to UML.
Use Cases.
Introduction to the Unified Modeling Language
Chapter 20 Object-Oriented Analysis and Design
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Introduction to the Unified Modeling Language
Software Construction Lecture 2
Analysis models and design models
Software Design Lecture : 15.
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Use Case Model Use case diagram – Part 2.
An Introduction to Software Architecture
Using Use Case Diagrams
Copyright 2007 Oxford Consulting, Ltd
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Interaction Modeling Extracted from textbook:
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Rational Rose 2000 Instructor Notes Use Case Realization Structure
Use Case Modeling Part of the unified modeling language (U M L)
Design Yaodong Bi.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Software Development Process Using UML Recap
Presentation transcript:

Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission) Additional information: http://www.rational.com/uml/resources.html Coming up: Introduction

Introduction Use Case: “... a typical interaction between a user and a computer system”, Booch Here, “user” is anything that needs or invokes the functionality of the system “Computer system” is the system being modeled Use cases can capture and document the user-visible functionality of a system Use cases capture how the system will benefit the user Each use case achieves a discrete goal for the user Examples of modeling languages: Data Flow Diagrams Entity Relationship Diagrams Flow Charts Context Diagrams State Charts Object-oriented Systems Modeling (OSM) The term model is actual a more appropriate term for what Booch, et al.m informal refer to as a modeling language. Coming up: Example Use Case Diagram

Example Use Case Diagram Coming up: Goals

Goals Use cases help everyone come to a common understanding of what the system should do Developers End-users Domain Experts Use-cases are a communication tool for the design (not the implementation) Use cases represent a functional requirement of your system (as a whole) Examples of modeling languages: Data Flow Diagrams Entity Relationship Diagrams Flow Charts Context Diagrams State Charts Object-oriented Systems Modeling (OSM) The term model is actual a more appropriate term for what Booch, et al.m informal refer to as a modeling language. Coming up: User Goals

User Goals User Goals are statements that represent what the users need to accomplish, independent of specific software features Examples of user goals for a Student Records Management System Ensure that a student’s records reflects courses taken and grades received in those courses Allow only authorized faculty and staff to update student records Ensure that students can obtain copies of their own (and only their) records in a timely manner Coming up: System Interactions

System Interactions Represent expected interacts between users and the computer-based system Suggest how the system fulfills a user goal Examples: A teacher alters a course grade for a student by selecting a semester selecting a course selecting a student reviewing the previous grade entering a new grade confirming the change A process for an administrator to create a new user A process for granting a user access rights Coming up: User Goals vs. System Interactions

User Goals vs. System Interactions In some cases, system interactions and user goals can be very similar However, confusing system interactions with user goals or neglecting to identify user goals can fail to bring out and document the reasons why a system should must certain features result in lost opportunities for creativity Coming up: User Goals vs. System Interactions

User Goals vs. System Interactions User goals help answer “What” and “Why” questions System interactions help answer “How” questions (from a user’s perspective) We will model user goals with Uses Cases Later, we will model system interactions with interaction diagrams or activity diagrams Coming up: Use Case Diagrams

Use Case Diagrams Use Case Diagrams provide a visual way to document user goals and explore possible functionality Three primary modeling components: Actors Use Cases Relationships between use cases Record class grades Review Transcripts Teacher Student Authorized Staff Worker Coming up: Actors

Actors Actors are things outside the system that need to interact with the system Actors carry out use cases Actors are represented as stick figures Although users are actors, not all actors are users Actors can be external software systems External hardware (sensors, actuators, etc.) Actors can be people that need the functionality of the system, but may not be the ones who actually invoke the software commands Coming up: Hints for Finding Actors

Hints for Finding Actors Who or what will use the main functionality of the system? Who or what will provide input to this system? Who or what will use output from this system? Who will need support from the system to do their work? Are there any other software systems with which this one needs to interact Are there any hardware devices used or controlled by this system? Coming up: Hints for Modeling Actors

Hints for Modeling Actors An actor can be a role that a user plays with respect to the system A single person may play different roles A single actor may perform many use cases A use case may be performed by many actors Show external systems as actors only when they are the ones who need a use case Don’t worry too much about the details of an actor or the relationship between actors and use cases Coming up: Relationships Between Actors

Relationships Between Actors Actors are Classifiers, meaning they are sets of instances Therefore, an actor (a set of instances) can be a subset of another actor (another set of instances) Generalization / Specialization Student Do this when very obvious Graduate Student Coming up: Use Cases

Use Cases Each use case represents something the user needs to do with the system – a goal A use cases is given a short name and textual description (optional) Use cases can be large or small from a conceptual perspective Use cases can relate to each other via dependencies, such as <<extends>> <<includes>> Generalization or <<refines>> (“is a”) Validate User (General) --- Specialization: retinal scan, key-card scan Extends - Hire Employee --- Hire international employee Includes - process data --- login to system Coming up: Use Cases

Use Cases Includes Extends Generalization Validate User (General) --- Specialization: retinal scan, key-card scan Extends - Hire Employee --- Hire international employee Includes - process data --- login to system Extends adds functionality usually for abnormal case, generalization/specialization replaces functionality After a while you realize extends and generalization are not too different. Just know generalization and includes… forget about extends Coming up: Use-Case Relationships

Use-Case Relationships Includes Dependency: Defines how one use case can invoke behavior defined by another use case Alter Student Grade <<includes>> Record Grades for a Section Teacher Coming up: Use-Case Relationships

Use-Case Relationships Extends dependency: defines a use-case that is a variation of another, usually for handling an abnormal situation Alter Student Grade <<extends>> Alter student grade for a class taken more than a year ago Authorized Staff Worker Coming up: Use-Case Relations

Alter Student Grade for a Graduate Course Use-Case Relations Generalization: Defines one use case as a generalization of another. Alter Student Grade Alter Student Grade for a Graduate Course Teacher Coming up: Hints for Finding Use Cases

Hints for Finding Use Cases Try listing actors first and then look at the activities each needs to perform and then try to express the goal that represent these activities although this will uncover many valuable use cases, it will not find them all Try listing external events and then look at what the system needs to do in response to each one. This technique will find some additional use cases, but not all Be patient, allow the use cases to unfold Don’t over do it – Use Case Diagram should be broad-brush characterizations of user goals Coming up: Hints for Modeling Use Cases

Hints for Modeling Use Cases Establish the context of a user goal by identifying the actors For each actor, consider the behavior that it expects or requires the system to provide Name these common behaviors as use cases Factor common behavior into new use cases Relate the use cases using the extend, includes, and refines dependencies Adorn uses cases with notes Coming up: Use-Case Relations

Use Case Diagrams A use case diagram consists of actors, use cases, and relations among use cases A use case diagram can also include notes constraints subjects (like the system) to show ownership of the use cases packages to group elements into larger conceptual chunks instances of use cases or actor, to show specific examples Coming up: A Well-structured Use Case Diagram

A Well-structured Use Case Diagram Describes the flow of events clearly enough for an outsider to understand it Factors in common behavior by pulling such behaviors from other use cases it includes Factors variants out by having other use cases “extend” itself Provides detail consistent with its level of abstraction Is not so minimal that it misinform the reader about important semantics Coming up: Benefits of Use Cases

Benefits of Use Cases Use cases diagrams capture user-visible functions Identifying actors help capture who needs the system functionality Relationships between use cases document opportunities for reuse Use cases provide a basis planning and scheduling incremental development Use cases can provide a basis for system testing Coming up: Use cases for CS421

Use cases for CS421 Show system boundary (Warning: skip this if not supported by the tool – like Netbeans! Show Actors outside boundary Use extend, include, generalization/specialization where appropriate Typically one diagram for your project is sufficient Coming up: Use cases for CS421

Use cases for CS421 Show system boundary (Warning: skip this if not supported by the tool – like Netbeans!) Coming up: Use cases for CS421

Use cases for CS421 Use Case Description about slide #18 For each use-case (oval) in your diagram include the use-description text described in the slide for Chapter 7, titled: Use Case Description about slide #18 Coming up: Questions

Questions Who might be interested in reviewing or using use case diagrams? When in the development life cycle should we employ use cases? What do use cases have to do with object-orientation? What level of use-case granularity is best? How many use cases are enough? Can other modeling activities help in discovering use cases? When in the development life cycle do we stop referring to or refining the use cases? What should the text description of use case contain? End of presentation