- Read Tutorial
- Watch Guide Video
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.