Project 5: Design the Uber Ride Sharing System
Uber is a massive enterprise with servers all over the world. There are probably more applications than we even know about. With this project we're going to pick and choose some of the more visible services that Uber provides and model those systems.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license
APPLY NOWLEARN MORE

You're going to build four different diagrams: an activity diagram, a package diagram, a use case diagram, and a deployment diagram. There's a reason why I picked those and in that order. It comes down to developing a mental framework for how to approach projects and different features that you're going to be asked to build.

I love starting off with activity diagrams because they provide a really nice high-level approach for how the entire system is going to work. When I'm working on the package diagram or the deployment diagram, I'll continually reference the activity diagram because it outlines how the entire system works.

Activity Diagram Requirements

  • Car ordering service process (8-12 activities)

Example Activities:

  • Setting a destination
  • Taking a car
  • Sharing trip details

Example branching logic:

  • Is the trip possible?
  • Share payment with others?

Branching logic is a component that allows the system to make decisions. For example, you may check to see if a trip is possible. If it is, then you're going to send the user in one direction. If not, then you'll direct them to a different activity.

I recommend for you to investigate the different services that Uber offers because that's what you can incorporate in this activity diagram. This is going to be a pretty large diagram comparatively. To some of the other ones, we've done so far because there are so many different options that are provided in this kind of service.

After you've completed the activity diagram, then it's time for the package diagram, which will allow us to set a frame around the entire system. I want you to examine Uber's mobile application itself. That is the only package that I want you to be concerned about.

Package Diagram Requirements

Mobile app modules and dependencies

Main modules:

  • User
  • Trip

Submodules:

  • Authentication
  • Booking
  • Payment

Nested modules:

  • Single payment
  • Shared payment

One of the biggest reasons to use a package diagram is when you're trying to wrap your mind around a system. You can start to see what you're going to need without getting too far into the weeds. We're simply trying to model the high-level structure.

Next is to create a use case diagram.

Use cases are primarily used to test for and model how the authorization system should work in the application. Think of real-world examples.

Use Case Diagram Requirements

Mobile app modules and dependencies

Actors:

  • Passenger
  • Driver
  • System

Use cases:

  • Search for Trip Details
  • Request Ride
  • Cancel Ride
  • Book Ride
  • Share Trip Details
  • Rate Ride
  • Update Payment information
  • Leave Tip

Last is the deployment diagram. I could probably spend an entire course examining how the entire Uber system could be modeled in a deployment diagram. Instead what I want you to do is model how a deployment system will work with a mobile application. It's pretty rare for mobile apps to just live by themselves. I imagine the Uber app by itself can't do anything without an outside API, so I want you to model just the mobile portion of how that system would be deployed.

Deployment Diagram Requirements

Android deployment process with dependencies (3-4 nodes)

  • API
  • Smartphone device
  • Android app

The more important thing is what kind of components are needed inside of those nodes. Just as important is to define how the dependencies will work: which components and which nodes truly cannot live by themselves, and which ones need to be able to communicate in order to work properly.