Use Cases Object Oriented Analysis & Design
Use-Case diagrams: example Object Oriented Analysis & Design
What is Requirements Engineering About? • • • correct consistent complete Effectively generating High Quality Requirements: • modifiable • non-ambiguous • traceable • understandable • verifiable • annotated Requirements Engineering Requirements Management Requirements Development Elicitatio n Analysis Change Control Version Control Modeling & Specification Tracing & Impact Analysis Verification & Validation Status Tracking Best Practices, Methods, Tools and Processes for Requirements Engineering Object Oriented Analysis & Design
Use Cases & Early Testing Paradigm Requirements Validation Quality Assurance Faster Time to Market System Design Detailed Design Implementation System Test Integration Test Module Test Build Object Oriented Analysis & Design
Software Production Cycle Design Specification (Design Model Generation) Design Specifications & Models Design Tools Code Creation Documentation Build Code SDE, SCM Tools Change Request Requirements Specifications & Models (Use Cases) Change Requests Documentation Build-triggered Installation Requirements Tools Shipped Product Capture with Customers Requirements “validation” Test Plans, Scenarios, Cases Test Creation Test Tools Testable version Test Execution Traceability, Change Management, Impact Analysis Object Oriented Analysis & Design
Software Production Cycle Design Specification (Design Model Generation) Design Specifications & Models Design Tools Code Creation Documentation Build Code SDE, SCM Tools Change Request Requirements Specifications & Models (Use Cases) Change Requests Documentation Build-triggered Installation Requirements Tools Shipped Product Capture with Customers Requirements “validation” Test Plans, Scenarios, Cases Test Creation Test Tools Testable version Test Execution Traceability, Change Management, Impact Analysis Object Oriented Analysis & Design
What is a Use Case? • A Use Case is – a set of scenarios that describe the behavior (or desired behavior) of a system and its users – at a superficial level of detail – with “sunny-day” and “rainy-day” scenarios – with some generalization of the roles and activities • A Use Case is the set of scenarios that provides positive value to one or more external actors – actors are the people and/or computer systems that are outside the system under development – scenarios are dialogs between actors and the system – no information about the internal design Object Oriented Analysis & Design
Use-Case (Cont. ) • A use-case is – a set of activities within a system – presented from the point of view of the associated actors – leading to an externally visible result – a (simplified) part of a business process model • WHAT is the system supposed to do – – not for functional decomposition simplified and limited graphical notation other diagrams and text templates used to support it combined with prototypes Object Oriented Analysis & Design
More on Actors • Actor, entity, control, boundary, source/sink, . . . • An actor is – a class that forms a system boundary, – participates in a use-case, – but is not within our responsibility as systems analyst/designer • Examples are – end-user (roles) – external systems – time related events – external, passive objects (entities) • Actor types – Primary – a stakeholder that calls on the system to deliver one of its services – Secondary or supporting actors – ia an external actor that provides service to the system under design Object Oriented Analysis & Design
More on Scenarios • A scenario is a little story • It describes one possible course of events: Ø Customer puts ATM card into machine and types password Ø System validates the card and password Ø System prompts the customer for a transaction type and amount Ø Customer selects “withdraw $100 from checking” Ø System checks with the central bank make sure customer has sufficient funds Ø System dispenses the cash, returns card, and prints receipt Ø System asks customer if he/she would like another transaction Object Oriented Analysis & Design
The UML Use Case Diagram • In UML (Unified Modeling Language), it is possible to show a picture of the system as a group of use cases: – each stick figure is an actor – each ellipse represents a use case • The diagram is deceptively simple – behind each ellipse, there might be a whole bunch of scenarios – sunny-day, alternatives, failures – the diagram is only a “summary” withdraw cash Customer check balance Bank Employee service ATM Object Oriented Analysis & Design
Different styles of use cases • Text formats: – informal paragraph summary – the paragraph will describe who starts the scenario, the key actions by the actors and the system, and how to handle failures – numbered list of steps – in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end • Graphical formats: – UML Sequence Diagrams (also known as message sequence charts) Object Oriented Analysis & Design
Example use case Use case name: Ticket Buyer buys a lottery ticket Primary actor: Ticket Buyer Precondition: Ticket Buyer has $1 Main scenario: 1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a ticket 2. System asks the Ticket Buyer for his/her choice of lucky number 3. Ticket Buyer chooses a number 4. System asks for $1 5. Ticket Buyer supplies $1 6. System prints a lottery ticket and gives it to the Ticket Buyer Variations: 2. Ticket Buyer chooses a number: 2 a. using keypad 2 b. fills in circles on card 2 c. asks for a “quick pick” Object Oriented Analysis & Design
Example use case (continued) • The use case isn’t finished… – still need to handle failures – go through the steps, list the various ways that they could fail: • Ticket Buyer can’t decide on a number, changes his/her mind • Ticket Buyer fills in too many circles on the card • System can’t print a ticket because it is out of ticket paper – for some failures, the system can recover – for other failures, the use case will “fail” Object Oriented Analysis & Design
Object Oriented Analysis & Design
Example use case Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart) Note: the scenario explains “what” happens but not “how” it happens (that will be in the design) Ticket buyer Ticket machine Sell me a ticket Prompt for lucky number Number choice Prompt for $1 Insert $1 Dispense ticket Object Oriented Analysis & Design
A bit on Use Case Theory • Each use case represents a “goal” of one of the actors – the use case is “the set of all scenarios that might happen” in trying to reach that goal – success or failure scenarios – each scenario is a series of smaller subgoals • if you can succeed in each step, you will reach the goal • if a step fails, then there might be an alternative series of steps that get to the goal • the substeps might be lower-level use cases, or they might just be “things implemented in the design” • It is possible to write “business-level” use cases – organizational goals (marketing, finance, systems engineering, installation) • Or “system-level” use cases – goals of specific users • Or “subsystem-level” use cases – goals of the other subsystems Object Oriented Analysis & Design
Use Case Tips • When you do “use case brainstorming”: – try to create a list of actors: write down a definition of the actor that everyone can agree on – actors are “roles”, not job titles – in the scenarios, start each step with the name of an actor or the system – use strong, active verbs in the steps of the scenarios • not: Make, Report, Organize, Record, Retrieve, Search • better: Create, View, Calculate, Register, Find, Browse • not “the lucky number is entered” • better: “the Ticket Buyer enters the lucky number” Object Oriented Analysis & Design
How many use cases is enough? • It depends… – make sure you cover the major goals of each actor – don’t forget OA&M – administrative use cases usually include initialization, running backups, diagnosing problems, and reporting current status to another system – some systems might need 100200 use cases, but most only have 20 -40 – do some “abstraction” to reduce the number of scenarios Object Oriented Analysis & Design
Exercise • What are the main actors and use cases for an Online Banking System? – Actors: • • – Use cases • • • Object Oriented Analysis & Design
Why use cases? • Why write use cases instead of “normal” functional requirements? – Use cases hold functional requirements in an easy-to-read, easy-to-track format – Each use case gives information on how the system will deliver a “goal” to one of the users of the system • a use case explains how a goal succeeds/fails using scenarios • the scenarios provide context – traditional requirements are often too ambiguous • “If you have a requirement that doesn’t help meet any of the users’ goals, why do you have the requirement in the system? ” • also need to look at the goals of the “stakeholders” – Use cases show only the Functional requirements • the use cases are a framework to attach non-functional requirements and other project details Object Oriented Analysis & Design
Use Cases and Requirements • The use cases are not all of the requirements – because some things don’t fit into scenarios – Business Rules (structural facts, computation rules, action restricting rules, action triggering rules) – Non-functional Requirements: security, reliability, performance, usability, flexibility (all of the “-ilities”) • Links to use cases – The Business Rules and the Non-functional Requirements are written in text, and they have links to the use cases where they are pertinent – Some folks store these items in a spreadsheet or a repository tool (such as Telelogic DOORS or Rational Requisite. Pro) Object Oriented Analysis & Design
After the use cases are written, what next? • Object oriented modeling – using CRC cards or other informal brainstorming techniques – use cases describe the “externallyvisible behavior” of the system – an object model describes the internal behavior • Design decisions can be linked back to a use case – just put comments in your code or model – search for the comments whenever the use cases are modified • Test planning – each use case needs to be converted into test scenarios and test cases Connection Customer Network Elem Report create archive Object Oriented Analysis & Design
Iteration management with use cases • A use case model can be very useful in a project with rapid iteration – for each iteration, identify which use cases are “in” the iteration • that is, will some or all of the use case’s scenarios work? • track progress by counting scenarios (with priority weighting) – typical iteration scheme: • first iteration: highest priority use cases, sunny-day scenarios only • second iteration: add a few second-tier use cases, start implementing the failure scenarios that fail completely • later iterations: add a few more use cases, start filling in the “recovery” scenarios – you might choose certain use cases as “high-priority” because they help validate key parts of the architecture Object Oriented Analysis & Design
Representing use cases - more details Use- Case diagramms - use-cases Use-Case Number (ID) & Name place phone call – – Actors Pre- & postconditions Non-functional requirements Behavior - main scenario • sequence diagram(s) • decomposition in smaller UC diagrams UC description – – – error-handling & exceptions Other examples, prototypes, etc. open questions & contacts other diagrams Object Oriented Analysis & Design
Use-Case diagrams - actors Textual stereotype (class) “actor“ cellular network Visual stereotypes (classes) boundary/interface actor persons & roles control entity passive objects data stores Object Oriented Analysis & Design
Use-Case diagrams (1) • show use-cases & actors • connected by „associations“ • refined by inheritance stereotypes – “uses” • re-use of a set of activities (use-case) • partitioning of activities • points to the re-used use-case – “extends” • variation of a use-case • points to the standard use-case Object Oriented Analysis & Design
elicit customer needs “extends “ make an interview “uses “ produce a SRS Object Oriented Analysis & Design
A typical Use-Case diagram name: anydiag information A system X uc-1 system Y uc-2 “uses” uc-3 uc-4 user-role 1 user-role 2 Object Oriented Analysis & Design
Use- Case diagrams (2) • Focus of the diagram is the part of the business process that is going to be supported by the IT system. • It is the end-user perspective that is modeled. • It is goal driven • UC diagrams help to identify system services. • UC diagrams are NOT used as DFDs. • Sequences, branching, loops, rules, etc. cannot (and should not!) be directly expressed. • UC diagrams are often combined with activity diagrams. • UC diagrams can be further decomposed. Object Oriented Analysis & Design
diagram name: anything uc-1 uc-2 uc-3 Use Case diagram decomposition uc-4 Diagram name: anything-level 2 -for-uc 4 uc-4. 1 uc-4. 2 Object Oriented Analysis & Design
Use-Case diagrams: example (2) anybody check travel options clerk “uses” flight db search for a flight traveler book a flight pay with cc customer “actor“ flight res-sys “uses” clerk “extends” Pay a bill “actor“ credit-card sys prepare-travel Object Oriented Analysis & Design
Use Case Fundamentals Step 1: Create a list of Actors Customer Support hotline person Administrator Repair person Step 2: Create a list of Goals Web-based music distribution system: UC 1: Customer downloads a song UC 2: Customer searches music directory UC 3: Administrator adds a new user UC 4: Administrator updates directory UC 5: Support hotline person investigates a Customer problem UC 6: Support hotline person authorizes Customer refund UC 7: Repair person runs diagnostics Step 3: Write simple use cases with only sunny-day scenarios UC 1: Customer downloads a song Precondition: Song file is on a server Main scenario: 1. Customer chooses song 2. System checks availability and price; prompts Customer for payment 3. Customer enters credit card info 4. System sends credit card transaction to Bank 5. Bank returns transaction number 6. System transmits the song to Customer’s computer Step 4: Review the use cases with customer (or customer surrogate) Object Oriented Analysis & Design
Use Case Fundamentals Step 5: Identify failure conditions 2 a. Song is not available 3 a. Customer quits without entering credit card info 4 a. Link to Bank is down 5 a. Credit card is rejected by Bank 6 a. Server fails during transmission 6 b. Customer cancels during transmission Step 6: Write a selected set of failure scenarios and alternatives 5 a. Credit card is rejected by Bank: 5 a 1. System reports failure to the Customer, prompts Customer for a different credit card 5 a 2. Customer enters card info 5 a 3. go to step 4 Step 7: Internal review • review the scenarios and failure branches with testers, developers, project managers Ongoing: make links to other requirements, update use case model as needed • define the business rules and non-functional requirements (in text documents, with links to the use case model) • add new use cases and new scenarios for new actors and goals; new variations for existing use cases Object Oriented Analysis & Design
To describe your use cases use the template in this section or see a detailed template at http: //members. aol. com/acockburn/papers/uctempla. htm Object Oriented Analysis & Design
References • Books: – Alistair Cockburn, Writing Effective Use Cases – Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context – Steve Adolph and Paul Bramble, Patterns for Effective Use Cases • Web sites: – – http: //www. usecases. org http: //agilealliance. org http: //members. aol. com/acockburn/papers/usecases. htm Object Oriented Analysis & Design
Agile development • Some important goals in today’s software development: – focus on the customers’ needs – adapt to changing requirements; support iterative development – document the core requirements faster • The “agile development” approach: – everyone collects requirements using scenarios or stories – project managers assign priorities (with the help of the customer) – everyone plans to add “variations” of the scenarios – but don’t implement every variation in. Analysis & Design Object Oriented the first
Use Cases contribute to agility • It is important to be “agile” – Requirements • get direct customer involvement in documenting the requirements – using scenarios and use cases – Architecture • make better architectural decisions – use the high -runner, high-priority scenarios to assess “candidate architectures” – Project management • use cases can help to plan an iterative development process – Test • update the tests as the requirements change Object Oriented Analysis & Design
OOAD. . . Object Oriented Analysis & Design
Use cases and RM Tools Object Oriented Analysis & Design
Storing Use Cases in DOORS A Use Case is stored in the DOORS “hierarchical object structure”: entire DOORS module a Use Case object in DOORS Object Oriented Analysis & Design
Object Oriented Analysis & Design
Storing Use Cases in DOORS • In DOORS, a use case will be represented as a simple hierarchical document: Object Type Use Case Actor In Control Step Number Description Next Step 4. 3 Use Cases 4. 3. 1 Use Case Heading 4. 3. 1. 1 Use Case Name Customer downloads a song 4. 3. 1. 2 Use Case Level User Goal 4. 3. 1. 3 Short Description A Customer can order a song on the web, pay for it by credit card … 4. 3. 1. 4 Primary Actor Customer Object Oriented Analysis & Design
Storing Use Cases in DOORS • Continuation of the previous page… Object Type Actor In Control Step Number Description Next Step 4. 3. 1. 5 Identifier 10101 4. 3. 1. 6 Preconditions Song file is on the server. Customer has a valid credit card. 4. 3. 1. 7 Main Scenario Custome r System 1 Customer chooses song 2 Custome r System 3 System checks availability and price; prompts Customer for payment Customer enters credit card info Bank 5 System 6 4 System sends credit card transaction to Bank returns transaction number Bank System transmits the song to Customer’s computer SUCCESS Object Oriented Analysis & Design
Storing Use Cases in DOORS • Continuation of the previous page… Object Type Actor In Control Step Number Description Next Step 4. 3. 1. 8 Post-conditions Customer has download song to his/her computer. 4. 3. 1. 9 Variations 4. 3. 1. 10 Extensions 4. 3. 1. 11 Sequence Diagram Visio Sequence Diagram Object Oriented Analysis & Design
Different styles of use cases • Graphical format: – UML Sequence Diagram (also known as message sequence chart) • Text formats: – informal paragraph summary: who starts the scenario, the key actions by the actors and the system, and how to handle failures – numbered list of steps: a list of sentences describing the actions of each actor and/or the system; failure scenarios can be written as branch scenarios at the end • The previous example shows two different representations for the same sunny-day scenario – a sequence diagram and a textbased numbered list of steps – either the text format or the graphical format can be used to drive the generation of test scenarios Object Oriented Analysis & Design
Extensions in DOORS • Here is an example of two extensions with the extension scenarios filled in. Object Type Actor In Control Step Number Description Next Step 4. 3. 1. 10 Extensions 5 a 5 a. Credit card is rejected by Bank: System 5 a 1 Custome r 5 a 2 5 a 1. System reports failure to the Customer, prompts Customer for a different credit enters card info 5 a 2. Customer card System 6 a 1 6 a. Server fails during transmission of song: 6 a 1. System cancels customer charge System 6 a 2. System displays error message 6 a 4 FAIL Object Oriented Analysis & Design
Actors in DOORS • The Actors are described in one section of the DOORS module Object Type Actor In Control Step Number Description Next step 4. 1 Actors Actor 4. 1. 1 Customer Actor Customer is a person who uses the system to download songs and search for song titles. 4. 1. 2 Administrator is a person who configures new song servers and song directories. Actor 4. 1. 3 Hotline Support Person A person who answers customers questions, authorizes refunds. Actor 4. 1. 4 Repair Person Actor 4. 1. 5 Bank Object Oriented Analysis & Design
Storing Use Cases in DOORS: Summary • Need #1: OK to have a partially completed use case model – with some of the use cases completely done but others with just a goal and preconditions – sunny-day scenario and extensions can be added later • Need #2: text or graphics – use either text or graphics to represent the main success scenario and/or failure scenarios • Need #3: links to other requirements (in the same module or in other modules) – links between other non-use case requirements and specific steps of a use case or the entire use case Object Oriented Analysis & Design
Скачать презентацию Use Cases Object Oriented Analysis Design
73128d595da1217b9f528e59daf4cc56.ppt