This is going to focus on the process of tracking maintenance, which has a number of activities that we want to be able to visualize. But as with most activity diagrams one of the most important parts of this entire model is giving us the ability to check to see what happens when things don't go right, and being able to visualize the branching logic on when we expected one thing to happen but something else happened. That's really the point of pretty much every activity diagram that we're going to be using in this entire course.

Our start point when a user has some type of maintenance inquiry. So imagine that you want to give truck drivers the ability to say, "I think there might be something the matter with my truck." Or it may just be time to go in for regular maintenance on it, such as an oil change or new brakes or something like that.

We first have to go through this technical diagnosis checkpoint. So right here we want to be able to have one activity where there's some type of review process.

Remember, the whole point of each one of these projects is to focus on specific types of behaviors that you would build, not just in a system like this, but in many other types of systems. So imagine that you're building some type of work flow management type of system where you have users that can submit requests, such as saying that they have an expense and they want to be able to get it paid back from the company. You're going to have this type of step where we have a first line of technical diagnosis where the data gets run through a process and somebody, some type of admin, or some user on the system, has the ability to see all the data, and then from there they can pass it to the first set of the branching logic.

Next, it's checking to see can it be fixed right now. If it is some very quick issue that doesn't require a lot of work then we send them straight to the maintenance step. We have one other QA process where we make sure that everything works, and if so then they're on their way. That is the easiest scenario. In my experience this very rarely occurred. Usually it couldn't be fixed immediately, so it got branched into another type of process.

Next, we have an activity "Assign service center/team member". This is a common activity in a lot of systems.

Further along, we have "Perform detailed technical diagnosis." Now this is different than "First line technical diagnosis," which is a high level diagnosis.

The reason I'm going into detail on these activity diagrams is not because I think you're going to be tasked with building out a fleet management system. What I'm wanting to impart more than anything is to show the level of detail that you want to build into the system. You want to have enough activities in here that it matches the level of functionality that's going to have to be built into the code base.

After it's checked for the detailed technical diagnosis, it checks whether new parts or assembly are required. If no, then we can move to booking a technical specialist. If parts or assembly are required, then it's going to book those required parts. It'll check if those parts are in stock or not. If not, then it's going to have to order those from the vendor. After those are restocked, we'll be ready to book the technical specialist. If the parts are in the system and they are available then it can go straight to booking the specialist.

From there, it follows down into the last activity where we check to see if we performed the maintenance. If the vehicle is OK, we're ready to go. If not, it goes all the way back up to the detailed technical diagnosis.

Now this goes back to what I said at the very beginning of this guide one of the most important components of building an activity diagram is not the best case scenario. If that was the case, we would simply be able to take it from a maintenance inquiry, to performing the technical diagnosis, and then take it to maintain. However that would be missing some very critical components that have to be considered when building out this type of feature.