Now, once again this is most likely going to look very different than what you've personally built out but I want to walk through the way that I personally like to think about it so that you can use it for your own types of diagrams. And one the key components that I want to stress before we even get into the solution is the way that I personally like to think about package diagrams. Packages are what I like to construct before I touch code. This is essentially my whiteboarding experience this is where I go in and I start to list off the types of features and modules I know I'm going to need to build into the system. I can't translate this directly into code but I can use it to be able to get me to that next step and so that is really what package diagrams are all about.

For example starting up here in our user module the user module I know is going to need to use several items. So I have an artifact here called use and that's perfectly optional. You don't have to put it there but the reason why sometimes I like to do it is for these diagrams as they become more complex the association and what it represents becomes more important. So here there is a very big difference between a module that uses another module compared with a module that simply has access to one of the other modules just like we have between the trip and the user.

This does not denote a deep level of dependency or coupling. Instead it simply says that this trip module here needs to access the user module. It still is a dependency because a trip cannot happen without users. However the main and primary objective that I want to focus on is that the trip can access the user.

Now let's go down the tree of everything that the user module needs to use. It needs to use authentication. This tells me I'm going to have to build in a way for users to log in and securely check to see if they are who they say they are. They also are going to need a profile. So I know I'm going to have to keep track of data such as their rating and to be able to see a historical list of all of the other places that they have been. And then also because one of the best benefits of using Uber is that you don't have to manually enter your payment information each time the way you do with a taxi. The payment module is going to be nested inside and the user module is going to use that payment module. And then from there the payment module is going to have its own set of nesting.

This is something that I really wanted you to focus on when it came to building out this diagram is figuring out exactly how you could integrate nesting. Because for example having a single and shared payment module should not directly be accessible by the user module. These are items that should only be used directly from the payment module because essentially a single payment is a type of payment and shared is also a type of payment. So our payment module is simply going to use these items.

That doesn't mean that we have to use inheritance or any thing object oriented It simply is referencing that this payment module needs to have access and needs to use the code inside of these libraries.

Now moving on to the next set of modules and our trip module we have already mentioned that it needs to be able to have access to users. So this is going to give us the ability to perform tasks such as finding who the user is if they're logged in successfully. If so then you could perform tasks such as seen their destination and seeing where they're starting from. Now some of the other items that need to be inside the trip module one it needs the ability to import an SMS gateway. So if you are sending any kinds of text messages or anything like that which uber allows then the trip module needs to have access to that code. Now you may wonder why did I not just include SMS gateway inside and said I want to be able to use of this. And part of the reason is that this comes down to a code structuring kind of decision. I do not want to use the SMS Gateway. I actually just want to import this library so the rest of my system can use it.

Now that may seem very subtle and it is. And that's perfectly fine if you didn't use an artifact like this in fact it's probably rare for anyone to do that. But I wanted to include it in here because myself as a developer would most likely have included this as an import statement because this is a third party library. So I would be importing this I wouldn't be creating it from scratch. Now if I continue down the stack to see what exactly the trip module needs to use. Well it needs to use search and search could mean many different things it could be searching for a destination it could be searching for a point of interest an address and so this would be relatively vague because a number of details would have to be added to it. And then also I would need the ability to have some type of booking engine so this would be a module that would connect and would pass my trip module details in here so it would keep track of where I started from what my destination was going to be and then it would perform all of the tasks associated with booking that ride.

Now, Uber is much more extensive than this. If I were to build out a package diagram for the entire system it would be pages and pages long. The core functionality that I wanted you to build in was what you would imagine designing if the creators of Uber came to you before it was a system and they just told you some of the basic user stories you could be able to create a package diagram like this and that would give you a starting point on building out the rest of the application.