1. Chapter 3: Software Design –Use case Diagram Nouf Alghanmi

2. Introduction Use cases allows for documenting the system from the users’ points of view. By “user” we mean anything external to the system, which interacts with the system. – E.g., a person, another information system, a hardware device. Use case modeling helps with three of the most difficult aspects of development: Capturing requirements Planning iterations of development Validating systems 2

3. Introduction A use case diagram shows only a small part of the information we need. Each use case must be described in detail using text. ⇒ The use case diagram can be seen as a concise summary of the information contained in all the descriptions of the use cases. 3

4. Introduction Main notations of a use case diagram Actors Use cases Relations Between actors and use cases Between actors Between use cases 4

5. Actors Actor: a person or thing interacting with the system so that it can respond to business events An actor, shown as a stick person, represents a kind of user of the system. Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for non-human actors. There is a solid line connecting an actor to a use case if the actor may interact with the system to play some part in the task. 5

6. Actors Representation of an external person, software, process, organization, etc. interacting with the system being developed. The actor can consult or modify the state of the system: interaction with the use case by sending messages. As an answer to the actor’s action, the system provides a service: the use case corresponding to the desired functionality. 6

7. Actors All actors must have names according to the assumed role, Examples of actor names (user roles): – Customer – WebClient – Student – Passenger – Payment System 7

8. Actors Categories of actors – Principal actors – Support actors – “Backstage” actors 8

9. Actors Principal actors External participants interacting with the system in the context of the use case. those using system services Direct beneficiaries of the provided service. Security attendant in the “UCIRes-AC” system. 9

10. Actors Support actors Participants providing a service that contributes to the realization of the use case. (contributors) providing services to the system E.g., Security officers in the “UCIRes-AC” system. 10

11. Actors “Backstage” actors Indirect beneficiaries of a use case. Security General Management Office in the “UCIRes-AC” system. Library manager in the “Library” case study. 11

12. Actors 12

13. Relationship between actors Generalization We can define abstract or concrete actors and specialize them using generalization relationship. Generalization between actors is rendered as a solid directed line with a large arrowhead (same as for generalization between classes). 13

14. Web Client actor is abstract superclass for Administrator, Editor and customer 14

15. Use Case Each use case describes a unit of complete and useful functionality that the subject (system under construction or consideration) provides to its users. Each use case must have a name. Examples of use case names: – Place Order – Update Subscription – Transfer Funds Use case is usually shown as an ellipse containing the name of the use case. 15

16. Relationships Between Use Cases Use cases could be organized using following relationships: 1.Generalization 2. Extend 3. Include 16

17. Generalization Allows for a sub-use case to specialize the behavior of a base use case (abstract) 17

18. The > relationship Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case. The extension takes place at one or more extension points defined in the extended use case. 18

19. The > relationship We use the relation > to underline an alternative scenario complex enough to be a use case. Is not necessarily executed even if the base use case is instantiated. Executed only if one of the corresponding extension points is reached. 19

20. The > relationship The condition of the extend relationship as well as the references to the extension points are optionally shown in a comment note attached to the corresponding extend relationship. 20

21. 21

22. The > relationship > represents that the source use case makes uses of the target use case. Called at a specific point within the main flow. Executed necessarily within the base case. We use the > relation in order to: - Factorize sub functions that are common between use cases. - Decompose a complex use case into sub-cases. 22

23. The > relationship 23

24. The > relationship 24

25. Relationships between use cases > relation From base case into included case.From extended case into base case. Execution: unconditional, the included case is always executed by the base case (main flow). Execution: conditional, the extended case is not necessarily executed by the base case. Dependency: the base case is not autonomous without the included case. Dependency: the base case is necessarily autonomous even when the extended case is not available. 25

26. Steps to draw Use Case Diagram Identify actors Relationships between actors Identify use cases for each actor Relationships between use cases Detailed description of the most important use cases 26

27. Use case Scenario Scenarios are real-life examples of how a system can be used. A scenario is an instance of a use case They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes. 27

28. A. Name/Title: Give a short, descriptive name to the use case. B. Actors: List the actors who can perform this use case. C. Goals: Explain what the actor or actors are trying to achieve. D. Pre-conditions: State of the system before the use case. E. Summary: Give a short informal description. F. Related use cases. G. Default scenario: Describe each step. H. Post-conditions: State of the system in following completion.....etc A and G are the most important 28

29. Example 1 : Automated Teller Machine (ATM ) Customer uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer funds.ATM Technician provides maintenance and repairs. All these use cases also involve Bank whether it is related to customer transactions or to the ATM servicing 29

30. 30

31. Checking balances, depositing funds, withdrawing cash and/or transfer funds are kinds of ATM transaction. On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and entering a personal identification number (PIN).Customer Authentication is required for every ATM transaction. 31

32. If needed, customer may ask ATM for help. ATM Transaction is at the location specified by the Menu and the bank customer requests help, e.g. by selecting Help menu item. ATM Technician maintains or repairs Bank includes Replenishing ATM with cash, ink or printer paper, Upgrades of hardware, firmware or software, and remote or on-site Diagnostics 32

33. 33