A fleet management system allows a company to manage its fleet of vehicles, as well as many other types of things. In fact, this fleet management system started out with a project that just the fleet manager was using. Once the CEO saw it, he liked it so much he started using it for the entire company to manage their assets and to work with maintenance.

Most of the time, you're going to be asked to build something and you're not going to have a clear picture of what needs to be done. You're going to be given a set of requirements and then you're going to have to design a system off of that. That's what we're going to be doing in this module.

One of the biggest takeaways from this course is how to develop your own mental model and framework for planning and designing a system. I want to take you through what I would do, because, at this stage, it's a very vague project. They want a way of being able to maintain and keep track of all of their vehicles. There's not a lot of detail.

In this project, you're going to build four diagrams. I want to start by looking at the behavior, so we'll design an activity diagram first.

I want you to model in this is the entire process of maintenance. This should include between 8 to 12 activities.

Activity Diagram Requirements

• Maintenance activities (8-12 activities)
• Start point: Maintenance Inquiry
• Endpoint: Maintenance Complete

Example action items:

• Technical diagnosis
• Assign service member
• Order parts

Make sure that you have decision points, guards, and the other elements that are required inside of an activity diagram so that it can have dynamic behavior. Use your creativity, and think about the different requirements for the situation.

The fleet manager didn't give me a list of requirements. He said that he wanted to keep track of his vehicles, service records, maintenance logs, parts orders, and so on. If you're working with someone who's not very technical, then it can be incredibly helpful to spend some time modeling the behavior. This gives them an opportunity to look at the flow and decide if what you're building will suit their needs, or if there are more requirements that aren't being addressed.

After finishing your activity diagram, I would keep a high-level view because we're still trying to develop a complete understanding of the project and its requirements. We'll move to a package diagram next, but avoid defining any classes.

With a package diagram, I can model out all of the main modules that the system's going to need, and then I can model the different operations associated with each of them.

Package Diagram Requirements

Fleet management modules, operations + dependencies

Modules:

• Personnel
• Vehicles
• Parts
• Maintenance
• Partners

Think about how these modules might operate inside of a system that is designed to manage a fleet of vehicles. Then, think about how these modules might relate to each other. Last, include some operations specific to each module. It's still too early to be very detailed, so keep your approach high-level.

For the vehicle module, for example, you might include some type of buy/sell operation to be able to manage how you're acquiring these vehicles. That was important when I built out the original fleet management system. They needed to know when a vehicle was purchased and how much it was purchased for because that dictated how much money they were willing to spend on maintenance.

A very important point when it comes to building out any kind of system is to keep your approach as straightforward and as practical as possible. It's very easy to involve complex computer science concepts in our modeling, but what I've found is that I'm much more successful when I simply try to put myself in the shoes of the person I'm building it for. Whether that's the end-user or various members of the organization, at this stage I simply try to figure out what would make this program most helpful to the business.