Use case diagrams 2014

2,306 views

Published on

Published in: Education, Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,306
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
169
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Use case diagrams 2014

  1. 1. Use Case Diagrams Inge Powell
  2. 2. Definition – What does Use Case mean? • “A use case is a software and system engineering term that describes how a user uses a system to accomplish a particular goal. A use case acts as a software modeling technique that defines the features to be implemented and the resolution of any errors that may be encountered.” • http://www.techopedia.com/
  3. 3. Use cases define the system. They show interactions between actors and the system to create a working structure. Although you might break them down to smaller components, uses cases will show: • Actors: Actors are the users that interact with the system, can be human roles or system. • Processes: Use cases show the processes that actors use to show the intended behaviour of the system. • System: Use cases should show all the processes, describing the activities for each actor that match the system functional requirements.
  4. 4. Use Case Diagrams ACTORS
  5. 5. ACTORS Actors are the people who will interact with the system, who does what. Typically in a simple Use Case diagram, they are depicted with stickmen.
  6. 6. ACTORS Although typically they are depicted with stickmen………………….. Sometimes they are also shown more graphically
  7. 7. ACTORS The actors are annotated with their role.. Administrator Operator Customer Client Manager
  8. 8. ACTORS Actors are not ALWAYS people, however you can still depict them with stickmen. Administrator Administrator Customer Customer Bank Bank Website Server Website Server
  9. 9. Use Case Diagrams SYSTEM BASICS
  10. 10. SYSTEM Ovals show each functional requirement of the system, the steps or processes. When we show these functional requirements as a whole process from start to finish we show them inside the system boundary.
  11. 11. SYSTEM Select Customer We write the function in the ovals Order System Select Customer We give the overall process a title to show what we are depicting. Create Order Select Products Take Payment
  12. 12. SYSTEM We show which actor interacts with each process Order System Select Customer Create Order Select Products Phone Operator Process Payment
  13. 13. SYSTEM Regardless of whether this is a two way process, we show who initiates the process with an arrow. Order System Select Customer Create Order Select Products Phone Operator Process Payment
  14. 14. SYSTEM Information from the system is shown with an arrow back to the user. Order System Select Customer Create Order Select Products Phone Operator Take Payment Order Status
  15. 15. SYSTEM Often there are more than one user who interacts with the system. Online orders Select Customer Create Order Select Products Bank Make Payment Payment Authorisation Process Order Order Clerk Confirm Order Customer
  16. 16. Use Case Diagrams <<INCLUDES>>
  17. 17. INCLUDES Sometimes a process has more steps to complete that process. Note the direction of arrows. Create Order <<include>> Add Delivery Address <<include>> Select Delivery Option
  18. 18. INCLUDES Sometimes a process has a lot more steps to complete that process. <<include>> Create Order <<include>> Add Delivery Address Select Delivery Option <<include>> <<include>> Add Billing Address Enter Delivery Notes
  19. 19. INCLUDES We only show the include on the main process if it does not become too confusing, the idea is to keep it simple Order System Select Customer <<include>> Search Customer Create Order <<include>> Delivery Option Phone Operator Select Products Take Payment
  20. 20. INCLUDES Otherwise we show it separately Order System Select Customer Create Order <<include>> Create Order <<include>> Add Delivery Address Select Delivery Option <<include>> <<include>> Select Products Phone Operator Take Payment Add Billing Address Enter Delivery Notes Notice that this is not a FULL system, so we do NOT enclose it in the system box.
  21. 21. INCLUDES It is perfectly acceptable to show some important ‘include’ inside the main system box, and some separately. Order System Select Customer <<include>> Search Customer Create Order Phone Operator Select Products Take Payment <<include>> Create Order <<include>> Add Delivery Address Select Delivery Option <<include>> <<include>> Add Billing Address Enter Delivery Notes
  22. 22. INCLUDES It is also acceptable to show more than one set of breakdowns outside the main system box. Create Order <<include>> Order System Select Customer Add Delivery Address <<include>> Select Delivery Option <<include>> <<include>> <<include>> Add Billing Address Search Customer Enter Delivery Notes Create Order <<include>> Phone Operator Select Products Select Products <<include>> Search Products Enter Quantity <<include>> <<include>> Take Payment Select size Select Colour
  23. 23. INCLUDES Includes is used to show a process that is always part of the parent process. Is it a parent process or a child process? • Try and think in levels. • An order management process might be shown as one process box in a larger system. • Its child processes might include select customer, create order, add products, take payment. • The children of these process might include, search customer, delivery type, quantity, etc. • Think of titles for the overall process, that becomes the parent.
  24. 24. Use Case Diagrams <<EXTEND>>
  25. 25. EXTENDS extend are different to include. Includes means that a process IS made up of smaller processes. extend means a process MIGHT include more smaller processes. Sometimes a process has a step that it might include to complete that process. Note the direction of arrows. Select Customer <<extend>> Search by Postcode <<extend>> New Customer
  26. 26. EXTENDS In this example, an existing customer might order a lollypop or beach ball. No extend required. But if they were a new customer or ordered a chemical product, more processes might be required. Sometimes a process might include a lot more steps that could potentially be needed to complete that process, but not always. <<extend>> Create Order <<extend>> New Customer Include COSH <<extend>> <<extend>> Check Licence Check Age Restrictions
  27. 27. EXTENDS We only show the extend on the main process if it does not become too confusing, the idea is to keep it simple. Order System Select Customer <<extend>> New Customer Create Order <<extend>> Arrange Air Mail Phone Operator Select Products Take Payment
  28. 28. EXTENDS Otherwise we show it separately Order System <<extend>> Select Customer Create Order Create Order <<extend>> Safety Instructions Include COSH <<extend>> <<extend>> Select Products Phone Operator Check Licence Check Age Restrictions Take Payment Notice that this is not a FULL system, so we do NOT enclose it in the system box.
  29. 29. EXTENDS It is perfectly acceptable to show some important ‘extend’ inside the main system box, and some separately. Order System Select Customer <<extend>> <<extend>> New Customer Create Order Create Order <<extend>> Safety Instructions Include COSH <<extend>> <<extend>> Phone Operator Select Products Take Payment Check Licence Check Age Restrictions
  30. 30. EXTENDS Note that you can mix include and extend. It is also acceptable to show more than one set of breakdowns outside the main system box. Create Order <<include>> Order System Select Customer <<extend>> Delivery Options Include COSH <<extend>> <<extend>> <<include>> Search Customer Create Order Select Products <<extend>> Check Licence New Customer <<include>> Check Age Restrictions Select Products <<include>> Search Products <<extend>> <<extend>> Phone Operator Take Payment Select size Select Colour Enter Quantity
  31. 31. Use Case Diagrams SYSTEM LEVELS
  32. 32. LEVELS Where do I start? At what level am I creating the use case for? There is a difference between Business Level Use Case and System Level Use Case: • Business Level Use Case: Try to show the whole business in its most simple forms including all actors who will be included. • System Level Use Case: Try to show the system in complete processes. For example the customer management system, the order system or booking process.
  33. 33. LEVELS Note that you would show the customers or shareholders at this level even if they have no direct contact with the actual system. Business Use Case Business use case is the top most level. Sooooper shops Ltd Orders Customer Order Clerk Fulfil Orders Manage Database Admin Supplier Invoices Payments Shares Manager Shareholder
  34. 34. LEVELS Note that there is a line to the customer, yet no arrow. shows a data transfer but no initialisation. Note also, rather than have lines cross over which would confuse the system, an actor is just repeated A BUSINESS Use Case may show system, it will show where the information comes from even if that actor has no direct interaction with the system.. Orders System Select Customer Order Clerk Create Order Select Products Make Payment Bank Payment Authorisation Process Order Confirm Order Order Clerk Customer
  35. 35. Levels Note that the customer, is shown on this diagram to clarify, but is not necessary. Note in this system it is clear that the customer has no direct interaction. A System Use Case will show a complete process rather than an overall picture. Orders System Select Customer Create Order <Telephone Order> Order Clerk Select Products Order Clerk Make Payment Payment Authorisation <Confirm Order> Process Order Customer Confirm Order Bank Customer
  36. 36. LEVELS A System Use Case will show a complete process rather than an overall picture. Orders System The subtle difference in this Use Case is that the system sends out a confirmation email direct to the customer. Select Customer Create Order <Telephone Order> Order Clerk Select Products Order Clerk Make Payment Payment Authorisation Process Order Customer Confirm Order Bank Customer
  37. 37. LEVELS Remember to show the FULL system process including any further levels of process. Create Order <<include>> Order System Select Customer <<extend>> Delivery Options Include COSH <<extend>> <<extend>> <<include>> <<extend>> Search Customer New Customer Create Order Phone Operator Select Products Check Licence <<include>> Check Age Restrictions Select Products <<include>> Search Products <<extend>> <<extend>> Take Payment Select size Select Colour Enter Quantity
  38. 38. LEVELS Note that this process has been simplified for example purposes and would probably include some more process as discussed earlier. These Use Cases are unlikely to be used in isolation, and are likely to have an additional narrative. Order System Select Customer <<include>> <<extend>> Search Customer New Customer Create Order Select Products Take Payment Phone Operator • Operator receives a call from the customer. • Operator selects the customer. • This will include searching to find if the customer exists. • This may also include creating a new customer. • Operator will create the order. • Operator will select products. • Operator will take payment.
  39. 39. Use Case Diagrams THINK!
  40. 40. THINK! It is important to note that there is not always a „correct‟ version. But there are wrong ways, so ask yourself: • Actors: Am I correctly showing who has access to the system, who uses which process? • System: Is it clear what the system does? • Goals: Is the full process shown? • Clear: Can I clarify the diagrams? • Too Simple: Do I need to add more breakdowns to clarify the process? • Too Complicated: Do I need to split some breakdowns out of the main system?
  41. 41. THINK! I have seen „extends‟ not „extend‟. You only use „extend‟ Why? UML changes over time to keep up with real world systems. • Extends: Used to be shown on models as <<extends>>, but was shortened to <<extend>> to keep the diagram as short as possible. • Both are still widely accepted and neither is wrong. <<extend>> is just more up to date.
  42. 42. THINK! I have seen „includes‟ not „include‟. You only use „include‟ Why? UML changes over time to keep up with real world systems. • Includes: Used to be shown on models as <<includes>>, but was shortened to <<include>> to keep the diagram as short as possible. • Both are still widely accepted and neither is wrong. <<include>> is just more up to date.
  43. 43. THINK! I have seen „include‟ and „uses‟. You have not used „uses‟, why not? In UML diagrams, „include‟ is now used now to cover both includes and uses. • Includes: <<includes>> used to be shown on models just to show that a sub process was an integral part of the main process. • Uses: <<uses>> used to be shown on models to show that a sub process was a re-usable part of the main process. It may also have been used elsewhere. • Both are still widely accepted and neither is wrong. <<include>> is just more up to date.

×