05 use-case-modeling-1mon
Download as ppt, pdf0 likes1,150 views
The document discusses use case modeling. It defines key concepts like use cases, actors, and relationships. It provides guidelines for creating use case diagrams and descriptions. An example use case model is shown for a Traffic Violations Report System (TVRS) with use cases like adding, removing, and editing traffic violations. Specific details are given for the "Remove Traffic Violation" use case.
![TVRS - Add TV
(With planted mistakes)
1. TVRS prompts Policeman for confirmation.
2. Policeman confirms
TVRS asks PolicemenDB
6. PolocemenDB is asked whether or not the
policeman is known
7. PolicemenDB replies that the policeman is
known
8. TVRS asks the OffendersDB whether or not the
offender is known
[Extenstion Point]
9. OffendersDB replies that the
offender is known ?Always
!Always
28 Use Case Modeling](https://image.slidesharecdn.com/05-use-case-modeling-1mon-111006082003-phpapp01/85/05-use-case-modeling-1mon-28-320.jpg)
![TVRS New Offender
Name: New Offender [extends Add
Traffic Violaton ]
Actors:
Goal:
References to requirements:
Pre-conditions:
Offender is not stored in the OffendersDB
31 Use Case Modeling](https://image.slidesharecdn.com/05-use-case-modeling-1mon-111006082003-phpapp01/85/05-use-case-modeling-1mon-31-320.jpg)
![TVRS New Offender
Description:
9a: OffendersDB replies that the offender is not
known. [Add Traffic Violation]
9b: TVRS displays an empty Offender Details
form
9c: Policeman enters offender details and calls
for saving the new details
9d: TVRS prompts Policeman for confirmation
9e: Policeman confirms
9f: TVRS requests OffendersDB to store the new
offender
9g: OffendersDB replies that offender was stored
successfully
32 Post-conditions: Case Modeling
Use
New Offender is stored in the offenders DB](https://image.slidesharecdn.com/05-use-case-modeling-1mon-111006082003-phpapp01/85/05-use-case-modeling-1mon-32-320.jpg)
05 use-case-modeling-1mon
- 1. Use Case 亰舒亞于舒仍舒仍 弌亠仄 4
- 2. 丱亳仍亳亶仆 舒亞仍亞舒 Use Case 亞亢 ﾑ 于 ? Use Case-勵勵亟亳亶仆 舒亳亞 Use Case 亰舒亞于舒仆 唏亞亢勵勵仍仍 System-亳亠仄 Actor-仂仂仍仂亞 Use Case Use Case-亳亶仆 仂仍弍仂仂亟 Example: TVRS Use Cases 2 Use Case Modeling
- 3. What is a Use Case? Ivar Jacobson 亞亟亞 勵仆 1994 仂仆亟 勵勵亞仆. Use case 仆 亳亠仄 亟 勵亶仍亟仍勵勵亟亳亶仆 亟舒舒舒仍舒仍 ﾐ. Use case-亳亶仆 亞仂仍 勵亶仍亟仍 仆 亳亠仄亳亶仆 仂仂仍仂亞亳亟 亳亶 亰勵亶仍亳亶仆 仆 勵 亟勵仆亞 仂亟仂仂亶 弍仂仍亞仂亢 勵亰勵勵仍. 弌亳亠仄 豫丕 亳亶亟亞 亞亟亞亳亶亞 仂仂仍仂亞仆 唏唏唏仍仍唏唏 仂亟仂仂亶仍亟仂亞. Use Case Model 弍仂仍 仂弍亠从 舒仆亟舒仍舒 亰舒亞于舒亳仍亞舒舒仆 亠仆亳从 丿. 3 Use Case Modeling
- 4. Benefits of Use Cases 丱亞仍亞亳亶仆 唏唏唏仍仍唏唏 亞舒舒仆 勵亶仍 舒亢亳仍仍舒亞舒舒仆 舒舒亟仍舒亞亟亞 亞仍仍仆舒. 弌亳亠仄 ﾑ 亳亶 于 亞亟亞亳亶仆 仂亶仍亞仂仄亢仂亶 舒亶仍弍舒亞 唏亞亟唏亞. 弌亳亠仄亳亶仆 亠勵勵亟亳亶亞 亳亶 仆唏唏仍勵勵亟亳亶亞 弌亳亠仄 亟 勵亶仍亟仍勵勵亟 弍仂仍仂仆 从仍舒亟亞 仆从亳仂仆舒仍 舒舒亟仍舒亞亟舒舒 舒仍舒仄 弍勵 亞舒亞舒 弍仂仍仂仄亢亞 仂仍亞仂仆仂. 4 Use Case Modeling
- 5. UML Use Case Diagrams A Use Case 亰舒亞于舒 仆 仆亞 于仍 仂仍仂仆 Use case 亟亳舒亞舒仄仄亟舒舒 仆 仆 UML- (Unified Modeling Language) 亳仍亳亶仍亞亟亟亞. UCD 仆 4 亞仂仍 仍亠仄亠仆亶: System- 仂亟仂仂亶仍仂亞亟仂仆 Actors-亳亠仄 仆亶 舒亳仍舒 use-case-勵勵 亟, 于仍 勵亶仍亳仍亞仆勵勵亟 亳亠仄 仆 亞勵亶亞亞亟 relationships 亟 仍亠仄亠仆勵勵亟亳亶仆 舒仄舒舒仍亟 5 Use Case Modeling
- 6. System Use case 亰舒亞于舒亳仍舒仍仆 仆亞 舒仍舒仄 仆 亳亠仄亳亶仆 勵 磶亞舒舒亞 仂亟仂仂亶仍仂仆 弍舒亶 仂亶. 弌亳亠仄亳亶仆 勵仆亟 舒 仂仍弍仂亞亟仂仍亞勵亶 亰勵亶仍亳亶亞 仂亟仂仂亶仍仂 舒舒亟仍舒亞舒亞勵亶. 仍 亟舒舒仍亞舒于舒亟 仆 舒于仂仄舒舒舒, 舒仍 仆 亞舒舒舒 亞勵亶亞亞亟 于 ? 亊仄舒 亟舒舒仍亞舒于舒亟 仆 唏唏 亳亠仄勵勵亟 亞勵亶亞亞亟 于 ? 勵 亳亶亟仍亳亶亞 亳亠仄亳亶仆 勵 磶亞舒舒 仂仍舒仆 舒仆亞舒仆舒. 6 哦唏仆 于亳仍弍舒舒舒 Use Case Modeling
- 7. System (cont.) UCD-亟 亳亠仄亳亶亞 亞 唏仆唏亞唏唏 舒仍仆舒. 丐亞 唏仆唏亞亳亶仆 亟仂仂 舒仍仆 亟 亳亠仄亳亶仆 仆亳亶亞 舒仍亟舒亞. Traffic Violations Report System 7 Use Case Modeling
- 8. Actor 丱仆 仆亞 于仍 礆舒 仆亞 ﾐ 亳亠仄亶 舒舒仆舒(仄亟仍仍 仂仍亳仍仂仆仂). 仂仍仂亞 亟勵勵勵亟 仆 亳亠仄亶 磠亢 舒亳仍舒仆 勵亶仍亟仍 亳亶亳亶亞 舒仍仆舒. 亳 仆: 丶舒亞亟舒舒亞亳亶仆 舒亢亳仍舒仆 唏亞唏亞亟唏仍 仂仍仆舒 仍舒 舒亢亳仍舒仆 唏唏仍唏仍 亳亶仆/唏亞唏亞亟唏仍 亞舒仆舒 亠仆亠亢亠弌舒亳亳从 仄亟 舒仆舒 亞 亞仍亞 仄舒亞舒亟亞勵亶 仆亞 仂仍仂仆 亟勵亳亶亞 亞勵亶亞仆. 8 Use Case Modeling
- 9. Actor (勵亞仍亢.) 仂仍仂亞亳亟 仆 亰仂亳仍亞亟舒亶: 舒仄仆 亰唏仍亳亶亞 仆仄 舒仄仆 亰唏仍亳亶亞 勵亰 仂仍仂亞 仆 亰舒舒于舒仍 勵仆 弍舒亶 舒仍弍舒亞勵亶. 舒亞舒亟亞勵亶 唏唏 亞舒亟仆 亳亠仄, 仆 唏亞亢亳亞亟仆 亳亠仄亶 仂仍弍仂亞亟仂仆仂. 仂仍仂亞 仆 亟勵亶 仂仍弍仂仂仂亶 9 仆仍亞亟仆. Use Case Modeling
- 10. Actor Icons-仂仂仍仂亞仆 仄亟亞仍亞 << Actor >> Policeman 丶舒亞亟舒舒亞亳亶仆 舒亢亳仍舒仆 10 Use Case Modeling
- 11. Relationships between Actors When several actors as part of their roles, also play a more generalized role, it is described as generalization 舒舒舒 仂仂仍仂亞亳亟 The behavior of the general role is described in an actor super-class The specialized actors inherit the behavior of the super-class and extend it in some way Relationships between actors are not always necessary Manager Supervisor Policeman 11 Use Case Modeling
- 12. Use Case Represent a complete behavior as perceived by an actor A use case satisfies an actors goal Always initiated by an actor A use case is complete Dont divide a use case into smaller use cases that implement each other (functional decomposition) 12 Use Case Modeling
- 13. Use Case Description The scenarios of a use case are normally described textually A simple and consistent specification about how the actors and the system interact Use case description template Describe at the level of user intentions and system responses Free of technology and mechanism details, especially those related to user interface 13 Use Case Modeling
- 14. UC Description Template Name Name of use case, usually close to the users goal Forward traceability (unique) Actors Goal description Reference to requirements Backward traceability Pre-conditions The necessary conditions before the use case can be performed Could be other Use Cases as well Description A description of the basic or normal course that should be taken by the system if the system should perform as intended 14 Use Case Modeling
- 15. UC Description Template (cont.) Post-conditions The state of the system after the use case is performed The value delivered to the actor Distinguishes between variations and exceptions Variations Expected condition causing the branch Description of the alternative course or name of the extending Use Case Exceptions Unexpected condition causing the branch (conflicts with post-condition) Description of the alternative course 15 Use Case Modeling
- 16. Use Case (cont.) Use Case Icon An ellipsis containing the name of the Use Case Placed inside the boundaries of the modeled system Connected to at least one actor with a communication association Except for specialized / extending use cases. Traffic Violations Report system Add Traffic Violation Policeman 16 Use Case Modeling
- 17. Use Case Relationships Generalization: A generalized Use Case describes the common of other specialized Use Cases. Inclusion: A Use Case is a part of another Use Case. Extension: A Use Case may extend another Use Case. 17 Use Case Modeling
- 18. Generalization Relationships Used when a number of Use Cases all have some subtasks in common, but each one has something different about it The generalized and specialized use cases share the same goal A specialized Use Case may capture an alternative scenario of the generalized Use Case The Specialized use case may interact with new actors. The Specialized use case may add pre-conditions and post-conditions (AND semantics). Specialized Generalized 18 Use Case Modeling
- 19. Include Relationship In older versions: uses When a number of Use Cases have common behavior, which can be modeled in a single use case X << includes >> Y indicates that the process of doing X always involves doing Y at least once The included Use Case must be complete X must satisfy the pre-conditions of Y before including it Not necessarily preserves the pre or post conditions. X << include >> Y 19 Use Case Modeling
- 20. Extend Relationship Serves as extension point to another Use Case The extended Use Case must explicitly declare its extension points The extension conditions of the extended Use Case are part of the pre-conditions (AND semantics) << extend >> Add T.R. New Offender (9: OffendersDB replies) (9: OffendersDB replies) 20 Use Case Modeling
- 21. Recommended Workflow 1. Identify actors (and their relationships if necessary) 2. For each actor identified and until no new UC is discovered do a. Find all the goals of the actor b. Decide on the main course of success for each goal c. Create a Use Case for each of the goals New actors/goals may be discovered d. Validate/correct existing Use Cases 3. Draw the Use Case diagram Simplify model by repeating the process incase the produced diagram is too complex 21 Use Case Modeling
- 23. TVRS Use Case Model Traffic Violations Report System Edit T.V. <<extend>> (8) Replace Offender <<include>> OffendersDB Policeman Lookup T.V Add T.V. (9) <<extend>> PolicemenDB New Offender Remove T.V Supervisor 23 Use Case Modeling
- 24. TVRS - Remove TV External System Name: Remove Traffic Violation Actors: Supervisor, OffendersDB. Goal: Remove an existing Traffic Violation References to requirements: 1.2.3, 1.3.2.4, Pre-conditions: Normal Course of Lookup Traffic Violation UC is completed, and the details of an existing Traffic Violation are displayed Description: 1. Supervisor calls for deletion of the chosen Traffic Violation 2. TVRS prompts Supervisor for confirmation 24 Use Case Modeling
- 25. TVRS - Remove TV 1. Supervisor confirms 2. TVRS requests OffendersDB to delete the Traffic Violation from the offenders record 3. OffendersDB approves that the Traffic Violation has been deleted 4. TVRS allows Supervisor to look up a new Traffic Violation as described in the Lookup Traffic Violation UC Post-conditions: Removed Traffic Violation is no longer stored in the TVRS. Traffic Violation is removed from the 25 offenders record in the OffendersDB Use Case Modeling "Lookup Traffic Violation" form is displayed
- 26. TVRS - Remove TV Goal is not Exceptions: fulfilled 3a: Supervisor cancels: 3a1: TVRS Continues to item 6 without removing the Traffic Violation 5a: Traffic Violation is not removed from the OffendersDB 5a1: TVRS displays an error message describing the failure 5a2: TVRS continues to item 6 without clearing chosen Traffic Violation details, and without deleting the Traffic Violation 26 Use Case Modeling
- 27. TVRS - Add TV (With planted mistakes) Name: Add Traffic Violation Actors: Policeman, PolicemenDB, OffendersDB, Traffic Violation. TVRS Goal: Add a new Traffic Violation to OffendersDB. References to requirements: Pre-conditions: Pliceman tries toManagement window is displayed The Traffic Violation add Traffic Violation. 1. Policeman presses Add button Description: 1. Policeman calls for addition of a new Traffic Violation 2. TVRS displays an empty Traffic Violation Details form 3. Policeman enters violation details and calls for 27 Use Case Modeling saving the new Traffic Violation
- 28. TVRS - Add TV (With planted mistakes) 1. TVRS prompts Policeman for confirmation. 2. Policeman confirms TVRS asks PolicemenDB 6. PolocemenDB is asked whether or not the policeman is known 7. PolicemenDB replies that the policeman is known 8. TVRS asks the OffendersDB whether or not the offender is known [Extenstion Point] 9. OffendersDB replies that the offender is known ?Always !Always 28 Use Case Modeling
- 29. TVRS - Add TV (With planted mistakes) Post-conditions: New Traffic Violation is stored in the TVRS TVRS displays an empty Traffic Violation Details form Variations: 5a: Policeman cancels 5a1: TVRS shows error message and closes Traffic Violation Management window. 5a1: TVRS continues to item 2 without clearing the Goal traffic violation details entered by Policeman may be 9a: OffendersDB replies that the offender is not fulfilled known. Described in Use Case New Offender 7a: Policeman is not stored in the PolicemenDB 7a1: TVRS displays an error message 7a2: TVRS continues to item 2 without clearing Traffic Violation details entered by Policeman ... 29 Use Case Modeling
- 30. TVRS - Add TV (With planted mistakes) Exceptions: 3a: Policeman cancels addition of the new Traffic Violation 3a1: TVRS continues to item 2 without clearing the traffic violation details entered by Policeman 3a1: TVRS displays the "Traffic Violation Management" window without adding the Traffic Violation Use Case terminated 30 Use Case Modeling
- 31. TVRS New Offender Name: New Offender [extends Add Traffic Violaton ] Actors: Goal: References to requirements: Pre-conditions: Offender is not stored in the OffendersDB 31 Use Case Modeling
- 32. TVRS New Offender Description: 9a: OffendersDB replies that the offender is not known. [Add Traffic Violation] 9b: TVRS displays an empty Offender Details form 9c: Policeman enters offender details and calls for saving the new details 9d: TVRS prompts Policeman for confirmation 9e: Policeman confirms 9f: TVRS requests OffendersDB to store the new offender 9g: OffendersDB replies that offender was stored successfully 32 Post-conditions: Case Modeling Use New Offender is stored in the offenders DB
- 33. Rational Rose 33 Use Case Modeling