UML Use Case Diagrams

  • View
    89.389

  • Download
    3

Embed Size (px)

DESCRIPTION

Course on Use case modeling with UML

Text of UML Use Case Diagrams

  • Session 4: Specifying Requirements with Use Case Diagrams Analysis and Specification of Information Systems Winter 2008 Eran Toch http://www.technion.ac.il/~erant Specification and Analysis of Information Systems Spring 2005 1
  • Outline Introduction Use Case Diagrams Writing Use Cases Linking Use Cases Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 2
  • Where are we? Phase Actions Outcome Business Initiation Raising a business need documents Interviewing stakeholders, exploring the Organized Analysis system environment documentation Analyze the engineering aspect of the Logical System Specification system, building system concepts Model Program, build, unit-testing, integrate, Testable Implementation documentation system Testing & Integrate all components, verification, Testing results, Integration validation, installation, guidance Working sys System Maintenance Bug fixes, modifications, adaptation versions Introduction | Diagrams | Writing | Linking | Guidelines 3
  • Source of Requirements Initial requirements come from the customer, by: Documents, such as RFI/RFP Meetings, reports Advanced requirements come from the analysts, after studying: Scope and price Feasibility (technological, organizational etc) Prototypes Final requirements are stabilized in an iterative process. Introduction | Diagrams | Writing | Linking | Guidelines 4
  • Requirements vs. Design Requirements: What the system should do More abstract Design: How the system should do it More detailed Introduction | Diagrams | Writing | Linking | Guidelines 5
  • Types of Requirements Visible Functional Requirements The system will deliver cash to the customer Cash will be delivered after card Functional was taken out Visible Qualitative Requirements Requirements The authorization process will take Hidden Functional no more than 1 sec Requirements Qualitative The user interface will be easy to Requirements use Hidden Requirements Database maintenance processes will occur every night Introduction | Diagrams | Writing | Linking | Guidelines 6
  • Outline Introduction Use Case Diagrams Writing Use Cases Linking Use Cases Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 7
  • Use Cases Use Case Actor Use case in diagram Use Case in script Illustration A use case is a contract of an interaction between the system and an actor. A full use-case model comprise of: A diagram, describing relations between use-cases and actors. A document describing the use case in details Introduction | Diagrams | Writing | Linking | Guidelines 8
  • Objective 1. Create a semi-formal model of the functional requirements 2. Analyze and define: Scope External interfaces Scenarios and reactions Introduction | Diagrams | Writing | Linking | Guidelines 9
  • What Makes Good Use-Case Specification? Lack of ambiguity Each requirement must be interpreted in a single manner. Completeness They should cater for all current demands of the system. Consistency Requirements should not conflict with each other. If there are, tradeoffs must be detected and discussed. Avoid design Requirements should raise a need, not answer it. (Why?) Introduction | Diagrams | Writing | Linking | Guidelines 10
  • Use Cases as Means of Communication Customers Designers Users The use case should stimulate a discussion about what the system should do, mainly with people who are outside of the development team. Introduction | Diagrams | Writing | Linking | Guidelines 11
  • A Simple Example Handle Message Cellular Phone Handle Call External Phone Company Bill Management Customer System Actors Association Use Case boundary Example Introduction | Diagrams | Writing | Linking | Guidelines 12
  • Finding Actors External objects that produce/consume data: Must serve as sources and destinations for data Must be external to the system Humans Machines External systems Sensors Organizational Units Database Printer Introduction | Diagrams | Writing | Linking | Guidelines 13
  • Actors can be generalized The child actor inherits all use-cases associations Perform Sale Register Client Sales Person Should be used if (and only if), the specific actor has more responsibility than the Perform Business Sale generalized one (i.e., associated with more use- Institutional cases) Sales Person Cancel Sale Sales Manager Example Introduction | Diagrams | Writing | Linking | Guidelines 14
  • Outline Introduction Use Case Diagrams Writing Use Cases Linking Use Cases Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 15
  • Structure of a Use Case Specification Name Actors Trigger Preconditions Post conditions Success Scenario Alistair Cockburn Writing Effective Alternatives flows Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 16
  • Triggers What starts the use-case? Examples: Customer reports a claim Customer inserts card System clock is 10:00 Introduction | Diagrams | Writing | Linking | Guidelines 17
  • Preconditions What the system needs to be true before running the use-case. Examples User account exists User has enough money in her account There is enough disk space Introduction | Diagrams | Writing | Linking | Guidelines 18
  • Post-Conditions A post-condition is the outcome of the use-case. Examples Money was transferred to the user account User is logged in The file is saved to the hard-disk Minimal guarantee The minimal things a system can promise, holding even when the use

Recommended

View more >