Project Solution: Uber Use Case Diagram
I really enjoyed putting this diagram together specifically because it does a very nice job of showing not only the functionality of the application but also how users should be interacting with this.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

large

Remember that use case diagrams give us the ability to build our entire authorization system. Now also note authorization is different than authentication authentication. Is the system that allows users to log in securely. Authorization, shows what types of features and components that a user should have access to. Now here we have three actors we have the passenger actor we have the driver and then we have the system itself. Now a passenger has the ability to interact with every one of the listed components. You can go down the line all the way from search for trip details, requesting a ride, canceling a ride, booking a ride, all the way through leaving a tip. Now the driver only has access to a few of those use cases.

A driver has to be able to book a ride. And when I'm saying Book ride what I mean is not book a ride with another driver but they need to be able to interact when a passenger is requesting that ride so that they can say yes I would like to accept that. So they're going to have to have access to that. Now with uber, uber drivers also have the ability to rate the right. So Uber lets their drivers not only drive but also say if the experience with the passenger was good or not. So that is a use case that's actually shared by both drivers and passengers. It's a pretty basic set of use cases for the driver.

Now let's look at the system itself. Now when a passenger says they want to search for trip details that's going to interact with the system. So there's going to be some type of Geospatial type of search engine that occurs and that is going to be what the system is in charge of the passengers to type in an address and the system is going to return back what the potential route would be along with any of the details such as the estimated time of arrival and anything else that the user needs. Now when it comes to the passenger requesting a ride the system needs to be able to interact with that as well. Now technically you could say that the system is in charge of everything here and that's the reason why I added this type of distinction where this is not the system as a whole. This is the navigation engine. So just to be clear on that the system is going to represent what is being managed from a navigation perspective. So every time a passenger requests a ride that needs a navigation component every time the passenger books a ride that needs a navigation component as well. Because if you've ever taken an uber you know that as you're on your journey the system is constantly updating your little dot and showing you how close you're getting to your destination. Now the last item here that I'm going to discuss is this cancel a ride use case. So this is something that you may notice that nothing directly has access to canceling this ride.

The reason for this is because even though canceling a ride can be performed by the passenger it needs to have a ride to cancel first. So this may have been different than what you implemented in your own solution and that's perfectly fine if you drew a line between the passenger actor to cancel a ride that would still be valid and you're definitely not going to get any points marked off for that. But I included this because this is an important if not subtle kind of difference to show that the process of canceling a ride is dependent on a ride being there to cancel.

Each one of these other items has the ability in a sense to stand on its own. So sharing trip details. This one is going to be able to live by itself whereas cancel ride that is going to be happening while the request process is occurring. So when you request a ride during that time you have the ability to cancel this. Now once you have booked the ride you can no longer cancel that. And so then it just keeps on going down the line.

Now there are subtle differences with each one of our solutions. I'm already very confident about that. And that's perfectly fine. This is also going to on your own experience and your own knowledge of the uber system the main components I wanted you to focus on is building out a system where one actor really interacts with pretty much every component in the entire system. And then you have these other actors that can add functionality just like we have with our navigation engine system and with our driver.