Use Case Diagrams Examples Here we provide some examples of UML of UML use case diagrams: diagrams:
Business Model - Airport Check-In and Security Screening Business Model - Restaurant e-Library OPAC Point of Sales Terminal Online Shopping Credit Card Processing System Bank ATM Hospital Management
Airport Check-In and Security Screening This is an example of Business of Business Use Case Diagram which is created during Business Modeling and is rendered here in notation used by Rational Unified Process (RUP). Business actors are Passenger, Tour Guide, Minor (Child), Passenger with Special Needs (e.g. with disabilities), all playing external roles in relation to airport business. Business use cases are Individual Check-In, Group Check-In (for groups of tourists), Security Screening, etc. - representing business functions or processes taking place in airport and serving the needs of passengers. Business use cases Baggage Check-in and Baggage Handling extend Check-In use cases, because passenger might have no luggage, so baggage check-in and handling are optional.
An example of use case diagram for airport check-in and security screening
Restaurant Here we provide two alternative examples of Business of Business Use Case Diagram for a Restaurant rendered in notation used by Rational Unified Process (RUP). First example shows external business view of a restaurant. We can see several business actors having some needs and goals as related to the restaurant and business use cases expressing expectations of the actors from the business.
Business use case diagram for Restaurant - External view Meal, Candidate - to Apply for Job, Job, and Contractor - to fix some For example, Customer wants to Have Meal, Chef or Waiter. Waiter. They are not external roles but part of appliances. Note, that we don't have such actors as Chef or the business we model - the Restaurant, thus - they are not actors. In terms of RUP Chef and Waiter are business workers. workers. Second example shows internal business view of a restaurant. In this case we can see that restaurant has several business processes represented by business use cases which provide some services to external business actors. actors. As in the previous example, actors have some needs and goals as related to the restaurant. This approach could be more useful to model services that the business provides to different types of customers, but reading this kind of business use case diagrams could be confusing.
For example, Customer is now connected to Serve Meal use case, Supplier - to Purchase Supplies. We have now new actor Potential Customer participating in Advertise use case by reading ads and getting some information about restaurant. At the same time, Contractor actor is gone because Repair Appliances is not a service usually provided by restaurants.
Business use case diagram for Restaurant - Internal view Still, in this example we don't have actors as Chef or Waiter for the same reasons as before - they both are not external roles but part of the business we model.
e-Library OPAC An Online Public Access Catalog (OPAC) is e-Library website which is part of Integrated Library System (ILS), also known as a Library Management System (LMS), and managed by a library or group of libraries. Patrons of the library can search library catalog online to locate various resources - books, periodicals, audio and visual materials, or other items under control of the library. Patrons may reserve or renew item, provide feedback, and manage their account.
An example of use case diagram for e-Library Online Public Access Catalog
Point of Sales Terminal An example of use cases for Point of Sale (POS) Terminal or Checkout. A retail POS system typically includes a computer, monitor, keyboard, barcode scanners, weight scale, receipt printer, credit card processing system, etc. and POS terminal software.
Top level use cases for Point of Sales Terminal. Checkout use case involves Customer, Clerk and Credit Payment Service actors and includes scanning items, calculating total and taxes, payment use cases. This is an example of large and complex use case split into several use cases each describing some logical unit of behavior. Note, that including use case becomes incomplete by itself and requires the included use cases to be complete.
Checkout use case in detail.
Payment use case is represented using generalization relationship. It means that only one specific type of payment is accepted - either by cash, or by credit, debit, or with check. An alternative to such representation could be to use include relationship so that not just single but several forms of payment could be accepted from the same client during checkout.
Online Shopping Web Customer actor uses some web site to make purchases online. Top level use cases are View Items, Make Purchase and Client Register. View Items use case could be used by customer as top level use case if customer only wants to find and see some products. This use case could also be used as a part of Make Purchase use case. Client Register use case allows customer to register on the web site, for example to get some coupons or be invited to private sales. Note, that Checkout use case is included use case not available by itself - checkout is part of making purchase. Except for the Web Customer actor there are several other actors which will be described below with detailed use cases.
Online Shopping - Top Level Use Cases View Items use case is extended by several optional use cases - customer may search for items, browse catalog, view items recommended for him/her, add items to shopping cart or wish list. All these use cases are extending use cases because they provide some optional functions allowing customer to find item. Customer Authentication use case is included in View Recommended Items and Add to Wish List because both require customer to be authenticated. At the same time, item could be added to the shopping cart without user authentication.
Online Shopping - View Items Use Case Checkout use case includes several required uses cases. Web customer should be authenticated. It could be done through user login page, user authentication cookie ("Remember me") or Single Sign-On (SSO). Web site authentication service is used in all these use cases, while SSO also requires participation of external identity provider. Checkout use case also includes Payment use case which could be done either by using credit card and external credit payment service or with PayPal.
Online Shopping - Checkout, Authentication and Payment Use Cases
Credit Card Processing System Use Cases In this use cases example, Credit Card Processing System (Credit Card Payment Gateway) is a subject, i.e. system under design or consideration. Primary actor of the system is the Merchant’s Credit Card Processing System. The merchant submits a credit card transaction request to the credit card payment gateway on behalf of a customer. Bank which issued customer's credit card is actor which could approve or reject the transaction. If transaction is approved, funds will be transferred to merchant's bank account. Authorize and Capture use case is the most common type of credit card transaction. The requested amount of money should be first authorized by Customer's Credit Card Bank, and if approved, is further submitted for settlement. During the settlement funds approved for the credit card transaction are deposited into the Merchant's Bank account. In some cases, only authorization is requested and the transaction will not be sent for settlement. In this case, usually if no further action is taken within some number of days, the authorization expires. Merchants can submit this request if they want to verify the availability of funds on the customer’s credit c ar d, if item is not currently in stock, or if merchant wants to review orders before shipping.
Capture (request to capture funds that were previously authorized) use case describes several scenarios when merchant needs to complete some previously authorized transaction - either submitted through the payment gateway or requested without using the system, e.g. using voice authorization.
Credit Card Processing System Use Cases. Credit use case describes situations when customer should receive a refund for a transaction that was either successfully processed and settled through the system or for some transaction that was not originally submitted through the payment gateway. Void use case describes cases when it is needed to cancel one or several related transactions that were not yet settled. If possible, the transactions will not be sent for settlement. If the Void transaction fails, the original transaction is likely already settled. Verify use case describes zero or small amount verification transactions which could also include verification of some client's data such as address. You can find excellent resources, documentation, white papers, guides, etc. related to the credit card processing at Authorize.Net - Payment Gateway to Accept Online Payments.
Bank ATM Use Cases An automated teller machine (ATM) or the automatic banking machine (ABM) is banking subsystem (subject) that provides bank customers with access to financial transactions in a public space without the need for a cashier, clerk or bank teller.
Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer funds (use cases). ATM Technician provides maintenance and repairs. All these use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.
An example of use case diagram for Bank ATM subsystem - top level use cases. On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and entering a personal identification number (PIN). Customer Authentication use case is required for every ATM transaction so we show it as include relationship. Including this use case as well as transaction generalizations make the ATM Transaction an abstract use case.
Bank ATM Transactions and Customer Authentication Use Cases Example. If needed, customer may ask ATM for help. ATM Transaction use case is extended via Menu extension point by the ATM Help use case whenever ATM Transaction is at the location specified by the Menu and the bank customer requests help, e.g. by selecting Help menu item.
Bank ATM Maintenance, Repair, Diagnostics Use Cases Example. ATM Technician maintains or repairs Bank ATM. Maintenance use case includes Replenishing ATM with cash, ink or printer paper, Upgrades of hardware, firmware or software, and remote or on-site Diagnostics. Diagnostics is also included in (shared with) Repair use case.
Hospital Use Cases Hospital Management System is a large system including several subsystems or modules providing variety of functions. Hospital Reception subsystem or module supports some of the many job duties of hospital receptionist. Receptionist schedules patient's appointments and admission to the hospital, collects information from patient upon patient's arrival and/or by phone. For the patient that will stay in the hospital ("inpatient") she
or he should have a bed allotted in a ward. Receptionists might also receive patient's payments, record them in a database and provide receipts, file insurance claims and medical reports.
An example of use case diagram for Hospital Reception.
UML Use Case Diagrams: Tips and FAQ
Contents: What is a UML Use Case Diagram (UCD), and when should I use it? How do you know who the actors are in a UCD? How do you know what to put in the "System" box? The actors in my diagram have interactions. How do I represent them? I am trying to represent a sequence of actions that the system performs. How do I do it? How is a UML Use Case Diagram different from a traditional flow chart? When do I use the uses arrow? When do I use the extends arrow? What is the difference between uses and extends? The scenario I want to describe branches into several possible outcomes, or has some error conditions. How can I represent that with Use Case Diagrams?
What is a UML Use Case Diagram (UCD), and when should I use it? UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them. UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between
these elements. You should use UCDs to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.) Example: A UCD is well suited to the task of describing all of the things that can be done with a database system, by
all of the people who might use it (administrators, developers, data entry personnel.) You should NOT use UCDs to represent exception behavior (when errors happen) or to tr y to illustrate the sequence of steps that must be performed in order to complete a task. Use Sequence diagrams to show these design features. Example: A UCD would be poorly suited to describing the TCP/IP network protocol, because there are many
exception cases, branching behaviors, and conditional functionality (what happens when a packet is lost or late, what about when the connection dies?) Back to top
How do you know who the actors are in a UCD? When working from an Action/Response table, itentifying the actors is easy: entities whose behavior appears in the "Actor's Actions" column are the actors, and entities whose behavior appears in the "System's Response" column are components in the system. If you are working from an informal narrative, a sequence diagram, or a scenario description, the actors are typically those entities whose behavior cannot control or change (i.e., agents that are not part of the system that you are building or describing.) The most obvious cand idates for actors are the humans in the system; except in rare cases when the system you are describing is actually a human process (such as a specific method of dealing with customers that employees should follow) the humans that you must interact with will all be actors. If your system interacts with other systems (databases, servers maintained by other people, legacy systems) you will be best to treat these as actors, also, since it is not their behavior that you are interested in describing. Example: When adding a new database system to manage a company's finances, your system will probably have to
interface with their existing inventory management software. Since you didn't write this software, don't intend to replace it, and only use the services that it provides, it makes sense for that system to be an actor. Back to top
How do you know what to put in the "System" box? The system box only appears on the top-level diagram (remember that a typical UML Use Case description will be composed of many diagrams and sub-diagrams), and should contain use case ovals, one for each top-level service that your system provides to its actors. Any kind of internal behavior that your system may have that is only used by other parts of the system should not appear in the system box. One useful way to think of these top-level services is as follows: if a use case represents a top-level service, then it should make sense for the actors who interact with it to request only that service of your system in a single session (in whatever sense a "session" is intelligible in your system.) Example: In the diagram below we would like to represent the use cases for a camera. Suppose we choose "Open
Shutter", "Flash", and "Close Shutter" as the top-level use cases. Certainly these are all behaviors that a camera has, but no photographer would ever pick up their camera, open the shutter, and then put it down, satisfied with their photographic session for the day. The crucial thing to realize is that these behaviors are not done in isolation, but are rather a part of a more high-level use case, "Take Picture". (Note that it do es make sense for a photographer to "Take Picture" just once during a session with their camera.)
Back to top
The actors in my diagram have interactions. How do I represent them? If there are interactions between the actors in your system, you cannot represent those interactions on the same diagram as your system. What you can do instead is draw a separate UCD, treating one of the actors itself as a
system, and your original system (along with the other actors) as actors on this new diagram. Example: Suppose you wanted to diagram the interactions between a user, a web bro wser, and the server it
contacts. Since you can only have one system on the diagram, you must choose one of the obvious "systems", such as the server. You might then be tempted to draw interaction lines between the actors, but this is a problem because it isn't clear what the interaction means, so it isn't helpful to show it here. A more useful solution would be to draw two diagrams, showing all of the interactions, as below.
Back to top
I am trying to represent a sequence of actions that the system performs. How do I do it? Using a UML Use Case Diagram, you can't. UCDs are meant to be a top-down, horizontal description of functionality, not a blow-by-blow desrciption of behavior. For the most part, it isn't a good idea to try to represent sequences of actions with Use Case diagrams. You should use a Sequence Diagram or a traditional flow chart instead. (It is possible to represent simple branching conditions with a UCD, as described below, but you should use this technique
sparingly because it can render a diagram unreadable.) Back to top
How is a UML Use Case Diagram different from a traditional flow chart? As mentioned above, UCDs represent functionality in a top-down way, whereas flow charts represent behavior in a linear, time-based way. Also, the way you develop them is all-together different. Example: (This text refers to the diagrams below.) When constructing a UCD, the initial step is to identify all of the
top-level behavior. Once you have done this (not a very tricky process) you have already described, at least in a highlevel way, all of the things your system knows how to do. You can then continue to add detail by decomposing your use cases into more use cases which are used by the top-level use cases. At every stage of development, though, your UCD is a complete description of the system's functionalty: it may lack detail, but it will not lack feature set elements. And if functionality or behavior is added or deleted over the life of your project, the scope of the change you need to make is proportional to both the scope of the change in the system itself, and the maturity of your model. This is useful because it means that when your model is very young (only high-level diagrams drawn) making sweeping changes to the system does not involve throwing very much work away. A flow chart, however, does not correctly describe the system until you have finished drawing it, and even then small changes in the system will result in significant reworking of your flow charts. In general, UCDs support the process of analysis and design much better than flow charts.
Back to top
When do I use the uses arrow? The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use c ase, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior. Example: Suppose you wanted to add detail to the diagram shown below, representing an airline reservation
system. First, you would create a separate diagram for the top-level services, and then you would add new use cases that make up the top-level ones. There is a uses edge from "Check in Passenger" to "Weigh Luggage" and from "Check in Passenger" to "Assign Seat"; this indicates that in order to Check in a Passenger, Luggage must be Weighed and a Seat must be Assigned. Similarly, the diagram indicates that in order to add a reservation to the system, the
available space must be checked and the passenger's information must be recorded. You c ould imagine breaking these use cases down further to show more detail.
Back to top
When do I use the extends arrow? The extends arrow (or extends edge) is drawn from a use case X to a use case Y to indicate that the process X is a special case behavior of the same type as the more general process Y. You would use this in situations where your system has a number of use cases (processes) that all have some subtasks in common, but each one has something different about it that makes it impossible for you to just lump them all together into the same use case. Example: Suppose you wanted to add detail to the diagram shown below, representing an airline reservation
system. Specifically, what you would like to show is that not all of the seats aboard the airplane are exactly alike (some window and some aisle seats), and sometimes passengers will express a preference for one of these types of seats but not the other. But of course, they cannot just be given their preference right away, because the seat they want might not be available. Therefore, the process of assigning a window seat involves checking for the availability
of window seats, whereas the process of assigning an aisle seat involves checking for the availability of aisle seats. But even though these processes are different, they are quite similar in a number of other ways, so it doesn't make sense to ignore their similarities. Fortunately, UML lets us have both: we wri te that assigning these two types of seats are different processes, but they are similar in that both processes extend a common, more general process (assigning seats.)
Back to top
What is the difference between uses and extends? Probably the best way to think about these diagram elements is as follows: - "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in the process of completing task "X", task "Y" wi ll be completed at least once. - "X extends Y" indecates that "X" is a task fo the same type as "Y", but "X" is a special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.
Example:indicates that inorder to successfully "Check-in", you m ust "Weigh luggage" and "Assign a seat", some
number of times, in some order. The key, though, is that all UCs used by a use case MUST BE DONE before that use case be considered to be complete. Once you realize that there are several types of seat assignment, you might be tempted to draw a diagram using the uses edge like the one below, but this doesn't make sense: This diagram says that in order to assign a seat you must assign both a window seat AND an aisle seat to the passenger. Never fear, however; this situation is correctly handled by the extends relationship. Using the extends relationship (as shown in the following diagram), we can express that there are two ways to assign a seat: assigning a window seat and assigning an aisle seat, but only one need be completed in the process of assigning the passenger a seat.
Back to top
The scenario I want to describe branches into several possible outcomes, or has some error conditions. How can I represent that with Use Case Diagrams? Representing failure and branching conditions is often best done with a Sequence Diagram or flow chart, but there are some grey-area cases when it isn't clear whether or not a Use Case Diagram is appropriate. A rule of thumb: if in representing the branching actions in the Use Case Diagram you must add significantly more use case ovals, and the resulting diagram is muddy or confusing, consider using a different diagramming style. With that said, it is possible to represent simple branching behavior with UCDs, although I would like to again stress that UCDs ARE NOT FLOW CHARTS. This is done by realizing that if the use case, or process that you are trying to represent can have two significantly different outcomes (success and failure, for example), then that means that you really have two different use cases: one in which the process succeeds, and one in which the process fails. Of course, these two use cases are related in that they are both extensions of the original use case, so you would draw the original use case with the two branches extending from it. I consider this almost an abuse of the meaning of the extends edge, because it really isn't being used here to represent a taxonomy of use cases (which is its purpose) but
is instead taking advantage of the specific abstract definition of the relation to hack flow-chart-like behavior out of the UCD style. Again, USE THIS TECHNIQUE SPARINGLY; IT CAN QUICKLY MAKE A DIAGRAM UNREADABLE.
Example: Suppose that we want to represent the use cases of a normal CD player. When all goes well, the CD player
retracts the tray upon which the CD sits, reads it, and starts playing. (The use case for this behavior is represented below. The top-level diagram has been omitted for brevety.) Unfortunately, some users will command the system to play a CD even when there is no CD in the tray. We therefore have a failure condition, under which the system must do something other than play the CD (namely, prompt the user for a CD.) To represent this, we modify the normal diagram with some extra use cases, in which the presence of the CD is verified. The behavior of playing the CD extends the behavior of verifying that the CD is present in that it is the special case of verifying the CD's presence in
which the CD is present. The other special case of verifying the CD's presence is that this is done and the CD is not present, so the user is prompted for a CD. I will say one last time that this use of extension is a bit of a reach, but it is an elegant way to express multiple behaviors of a single use case when the number of such behaviors is small.
Back to top
Maintained by Rus Heywood
