When I built the system, I was able to break it into these five modules. Remember one of the most important elements of a package diagram is being able to show the dependencies. If you did not build your system to have the proper types of dependencies I recommend looking back at your project and see how that can be cleaned up a little bit.

Starting on the top left hand side we have our Personnel module. This is going to track drivers, the admins, etc. We have the ability to hire, to leave, to have authentication, and to log out. These could be users of the system, and they may also be truck drivers who may not have to log into the system.

When it comes to analyzing the dependencies, remember that a dependency doesn't just mean that we have to be careful about removing certain modules. It also means that Personnel can access Vehicles but Vehicles is not going to access Personnel directly. So dependencies also represent the access levels that these modules have between each other.

The reason why Personnel has a dependency on Partners and why it can access Partners is because only a user has the ability to add a contract or delete a contract, and Personnel is where all of our users are. So that's a module in Partners that the Personnel Module needs to be able to access. And so that's why this particular component has to be able to communicate with it and why it also depends on it personnel. Does that make any sense. Living by itself if it is not in this scenario going to be communicating with the vehicle module and with the partner module. Now technically you could create a system where the Personnel Module does not have those same types of dependencies. So imagine if you built a system that had authentication as its own application and it worked among all kinds of different applications. So I built a system like that where it did communicate with a enterprise fleet management system and then it communicated with an asset management system and add all of these different apps that it could pass users through and so you only had to log in to one app but it could go and could communicate with all of these other ones. In that case there isn't that same level of dependency because Personnel can live by itself. But in this case we really care about how the users can interact with partners with vehicles and so on and so forth. That's the reason why those are represented that way.

In Vehicles, you can see that we have a few actions such as being able to assign, maintain, buy, and sell. From there, the dependencies and the access points are that a Vehicle has to be able to have some type of communication with Parts. And the reason for that is because you're going to have this entire library of parts in the database and the vehicle is going to have its own set of requirements. Anytime you use a phrase such as "needs access to" that means that there is a dependency there. So our Vehicles need access to our Parts catalog. And just like that, vehicles also need access to Maintenance.

The Maintenance module is the entire process of being able to start, finish, and then maintain the supply of all of those various elements required to build this system out.

One thing that I also want to point out to you is that we have Parts and we have Maintenance. Now technically, Parts is going to be able to be translated directly into a class and a database and that's where you're going to be storing all of your types of items. Maintenance is very different. This is not going to just be a database class with methods. This is going to be almost like a miniature application in itself. It's going to have a number of classes and modules and helper methods all built into this system. It's going to have its own workflow just like you saw in the activity diagram. So that's something that is a very important point when understanding how to construct package diagrams is just because you have two components that look the same that does not mean that they are going to have the same type of behavior or that you're going to be able to translate that directly into code.

This is part of the reason why package diagrams are the diagrams that you build at the very beginning of your project. It's your way of being able to brainstorm and create some type of organization for how you want to structure your code base.

Let's move to our last module: Partners. Partners can provide information to Personnel. That's a reason why personnel needs to have access point to it. But partners needs access to the Maintenance module, because partners are going to interact with the supply system, and they're going to have to pass back which parts they have in what quantities. If you look back at the activity diagram, this all goes back to that one sequence where the system checks to see if a product is available and then it can perform ordering.

Now this package diagram is much more complex than our phone parser one. And for very good reason that application was much smaller than this fleet management system. And in actuality this was the first draft of the fleet management package diagram the one that I ended up building is much different and much larger. I didn't want to show you the complete and final diagram because I didn't want you to think that I had gotten it absolutely right the first time. No one knows the kind of system we're going to build until we actually start getting into it. If it was possible to construct these type of UML diagrams perfectly before touching the code then you wouldn't really need programmers. All you'd need is a set of computers that could read these diagrams and then go build the system for you. Instead, the whole purpose of these models and these type of diagrams is to give you a head start. It's to give you the ability to take a set of requirements and users stories and all of those types of components and structure them in a visual way so that you are able to get a little bit closer to actually building the system.