UML Use Case Diagrams

106,118 views
106,113 views

Published on

Course on Use case modeling with UML

Published in: Education, Technology, Business
14 Comments
83 Likes
Statistics
Notes
No Downloads
Views
Total views
106,118
On SlideShare
0
From Embeds
0
Number of Embeds
3,153
Actions
Shares
0
Downloads
3,527
Comments
14
Likes
83
Embeds 0
No embeds

No notes for slide

UML Use Case Diagrams

  1. 1. 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
  2. 2. Outline • Introduction • Use Case Diagrams • Writing Use Cases • Linking Use Cases • Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 2
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. Outline • Introduction • Use Case Diagrams • Writing Use Cases • Linking Use Cases • Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 7
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Outline • Introduction • Use Case Diagrams • Writing Use Cases • Linking Use Cases • Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 15
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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 case execution ended in failure – Examples: Money is not transferred unless authorization is granted by the user • Success guarantee – What happens after a successful conclusion of the use-case. – Examples: The file is saved; Money is transferred Introduction | Diagrams | Writing | Linking | Guidelines 19
  20. 20. Success Scenario • The success scenario is the main story-line of the use-case • It is written under the assumption that everything is okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case • It is composed of a sequence of action steps • Example: Interaction step 1. User enters product name, SKU and description Validation 2. System validates product SKU Step 3. System adds the product to the DB and shows a confirmation message Internal Change (plus) Interaction Step Step Introduction | Diagrams | Writing | Linking | Guidelines 20
  21. 21. Success Scenario Example 1. User enters a keyword 2. System presents a set of search results, and sponsored products, all of which include name, short description and price 3. User selects a product 4. System displays a product page, including product information, reviews and related products 5. User adds the product to the shopping cart Introduction | Diagrams | Writing | Linking | Guidelines 21
  22. 22. Guidelines for Effective Writing • Use simple grammar • Only one side (system or actor) is doing something in a single step System Actor • Write from an “objective” point Actor asks for money of view System asks for amount – Bad: “Get the amount form the Actor gives the amount user and give him the money” • Any step should lead to some System produce the money progress – Bad: “User click the enter key” Introduction | Diagrams | Writing | Linking | Guidelines 22
  23. 23. Steps – cont’d • Branches: – If the user has more than 10000$ in her account, the system presents a list of commercials – Otherwise… • Repeats: – User enters the name of the item he wishes to buy – System presents the items – User selects items to buy – Systems adds the item to the shopping cart – User repeats steps 1-4 until indicating he is done Introduction | Diagrams | Writing | Linking | Guidelines 23
  24. 24. Use-Cases – Common Mistakes • Complex diagram • No system • No actor • Too many user interface details – “User types ID and password, clicks OK or hits Enter” • Very low goal details – User provides name – User provides address – User provides telephone number – … Introduction | Diagrams | Writing | Linking | Guidelines 24
  25. 25. Alternative Flows • Used to describe exceptional Starting points functionality • Examples: – Errors Exceptions – Unusual or rare Success Shortcuts cases Scenario – Failures – Starting points Endpoints – Endpoints – Shortcuts Introduction | Diagrams | Writing | Linking | Guidelines 25
  26. 26. Alternative Flows - Example • Errors: – “Case did not eject properly” – “Any network error occurred during steps 4-7” – “Any type of error occurred” • Unusual or rare cases – “Credit card is defined as stolen” – “User selects to add a new word to the dictionary” • Endpoints – “The system detects no more open issues” • Shortcuts: – “The user can leave the use-case by clicking on the “esc” key Introduction | Diagrams | Writing | Linking | Guidelines 26
  27. 27. Outline • Introduction • Use Case Diagrams • Writing Use Cases • Linking Use Cases • Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 27
  28. 28. Linking Use-Cases • Linking enables flexibility in requirements specification – Isolating functionality – Enabling functionality sharing – Breaking functionality into manageable chunks • Three mechanism are used: – Include – Extend – Inheritance Introduction | Diagrams | Writing | Linking | Guidelines 28
  29. 29. The “Include” Construct • Include is used when: – Decomposing complicated behavior – Centralizing common behavior • The base use case explicitly incorporates the behavior of another use case at a location specified in the base. Perform <<include>> Fill-in billing Sale info Example Introduction | Diagrams | Writing | Linking | Guidelines 29
  30. 30. Writing Include • If a base use-case include another use-case, we will add a reference as a step: – System presents homepage – User performs login to the system OR <include: login to the system> Introduction | Diagrams | Writing | Linking | Guidelines 30
  31. 31. Extend – Graphical Representation • The base use case can incorporate another use case at certain points, called extension points. • Note the direction of the arrow – The base use-case does not know which use-case extends it <<extend>> Product is a gift Perform Sale Gift wrap After checkout Products Example Introduction | Diagrams | Writing | Linking | Guidelines 31
  32. 32. Writing Extend • Scenarios do not include direct references • Instead, they include extension points, such as: User enters search string System presents search results Extension point: results presentations OR <extension point: results presentations> • The extension use-case includes conditions in which the extension is being committed – Example: if the user belongs to the “rich clients” group – If more than two commercials were found Introduction | Diagrams | Writing | Linking | Guidelines 32
  33. 33. Example: Amazon Shopping Cart Product Page Review Writing Page Introduction | Diagrams | Writing | Linking | Guidelines 33
  34. 34. Example – cont’d «extend» Rank Search «include» Supplier Product View Product Details After page Write generation «extend» Revie «include» Navigate w Deals «extend» Add to cart Customer «include» Checkou t «extend» user is not a member Login Register Handle Order Status «include» Introduction | Diagrams | Writing | Linking | Guidelines 34
  35. 35. Generalization between Use-Cases • The child use case inherits the behavior parent use case: – The interaction (described in the textual description) – Use case links (associations, include, extend, generalization) • Child use-case can substitute parent Use case • Overriding occurs through the textual description 1. Transfer call to available representative 2. Mark representative as busy 3. Start record call 4. Stop record call Handle Call 5. Log call details 6. Mark representative as free Handle Technical Handle Sale Call Assistance Call Customer Tech Assistant Representative Representative Example Introduction | Diagrams | Writing | Linking | Guidelines 35
  36. 36. Generalization Hazards • Combining generalizations of actors and use- cases can be dangerous Submit and Get Grade Submit Exam Undergrad Student Undergrad Student Submit Exam Submit Thesis Submit Thesis Graduate Student Graduate Student Bad: Undergrad can submit Good: Only graduate thesis student can submit thesis Introduction | Diagrams | Writing | Linking | Guidelines 36
  37. 37. Example: Phone Company Operational System Orange’s objective: Build a system that handles SMS messages, handles calls (for 2 and 3 generation phones), including conference calls and multiple calls from a single phone. The system must support users on the move. Who are the actors? The Cellular Phone External Phone companies Introduction | Diagrams | Writing | Linking | Guidelines 37
  38. 38. Example: Cell Company System External Phone Company Handle Cell Migration <<include>> <<include>> Handle SMS Handle Call Message while talking <<extend>> Cellular Phone Handle Voice <<extend>> {phone initiate call } Call {incoming call } Handle Conference Call Handle Multiple Handle Video Calls Call 3G Phone Introduction | Diagrams | Writing | Linking | Guidelines 38
  39. 39. Outline • Introduction • Use Case Diagrams • Writing Use Cases • Linking Use Cases • Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 39
  40. 40. How to Model? Bottom-up Process Top-down Process Starting with throwing all Starting with an overview of scenarios on the page, and the system, and then splitting then combining them: Use-cases Bullets File save format Paragraph action print format s Save Font Formattin load as Viewing forma g actions t Actions preview Introduction | Diagrams | Writing | Linking | Guidelines 40
  41. 41. How to Model – cont’d • Most of the analysis process are actually Combined Introduction | Diagrams | Writing | Linking | Guidelines 41
  42. 42. Combining Processes • Number Limit: – The diagram should have between 3 to 10 base use-case. No more than 15 use cases (base + included + extending). • Abstraction: – All use-cases should be in similar abstraction levels. • Size: – Use cases should be described in half a page or more. • Interaction: – Use-cases which are carried out as part of the same interaction. UC UC UC Introduction | Diagrams | Writing | Linking | Guidelines 42
  43. 43. Dividing Processes • Size: – If a use-cases takes more than a page, consider include/extend • Weak dependency: – If the dependency between two parts of a use-case is weak, they should be divided. UC Introduction | Diagrams | Writing | Linking | Guidelines 43
  44. 44. More Guidelines • Factor out common usages that are required by multiple use cases – If the usage is required use <<include>> – If the base use case is complete and the usage may be optional, consider use <<extend>> • A use case diagram should: – contain only use cases at the same level of abstraction – include only actors who are required Introduction | Diagrams | Writing | Linking | Guidelines 44
  45. 45. Scope • A good way to decide on the scope is by in/out lists: Topic In Out Any non-software parts of the system  Statistical analysis of logs  Interfacing with credit card systems  Database cleaning processes  Backup of logs  … Alistair Cockburn “Writing Effective Use Cases” Introduction | Diagrams | Writing | Linking | Guidelines 45
  46. 46. When Are we Done? • When every actor is specified. • When every functional requirement has a use-case which satisfies it. • A tractability matrix can help us determine it:     Use Cases     Requirements Introduction | Diagrams | Writing | Linking | Guidelines 46
  47. 47. Moving on • Data entering and exiting the system is represented by data entities in structural diagrams. • Behavior induced by use cases can be captured in behavioral diagrams. Use Case 1 Class C Class A Use Case 3 Use Case 2 Class D Class B Introduction | Diagrams | Writing | Linking | Guidelines 47
  48. 48. Summary  Introduction to the Unified Modeling Language (UML) To Use Case Diagram  Use Case Diagrams Dual presentation of use-cases Include, Extend, Inheritance  Writing Use Cases Preconditions & Post-conditions Main scenario vs. Alternative Flow  Guidelines for Effective Use Cases Introduction | Diagrams | Writing | Linking | Guidelines 48

×