Now, each one of the solution videos in this course is going to be broken down into its own individual guide. The reason is that there are a few goals that I want to accomplish with the solutions. One is definitely so that you can have something to compare with what you've already put together in your own project. So, being able to check and see if what you built is similar to what we have here.

The other reason, though, is because when you're out in the industry when you're working on your own real-world development projects, I want to give you guides that you can reference. For example, we're going to talk about a use case diagram in this guide. And so in your future projects, you may want to be able to come back and look and see what the correct syntax and structure are for a use case diagram. So you can come back and look at one guide instead of having to sift through a number of them. So with all of that being said, let's jump into this first solution where we walk through a use case diagram for building the Twitter functionality.

Here we have two actors. We have an author and we have a follower. You can think of an author as someone who authors a tweet.

Now, remember, your solution does not have to match all of the elements that I have because I want you to be able to use some of your own creativity and didn't want to lock you down into a set of requirements where you weren't able to explore what your own solution would look like. Here, we do have two actors though, because we want to have someone who is going to write tweets, and then we're going to have someone who can follow those. That's one of the most core fundamental types of features that Twitter makes available.

So let's walk through what an author can do in this use case diagram. They can write a tweet. As you can see, we have this "Write a tweet" use case and inside of "Write a tweet" there are a number of items that this includes. Writing a tweet might be something where they write a tweet from scratch. However, they also will be able to retweet a tweet. They can also like a tweet and they can also send a message. This would be such as forwarding a tweet. So this is some of the functionality that is wrapped up inside of the "Write a tweet" use case.

Now, we also can get into the ability where we have an extension on this tweet. If you have used Twitter at all you know that you can write a regular tweet that just has some text content, but you can also upload an image to the tweet and have that shared. So that's why we have a metaclass of <<extend>>. It's extending the functionality of the tweet where you can attach an image to a post.

We additionally have this follower actor. So what we have to do in modeling out this use case diagram is build in the type of functionality where we want to be able to show what one actor does, and then also the types of use cases and the type of functionality that one of the other actors is going to have. And so in this case let's see what a follower can do.

A follower can write a tweet, they can retweet tweet, they can like a tweet, and they can message. Now technically this is a very basic kind of use case here, because an author and a follower are technically interchangeable. If you're following another user, then you're still an author. Every user on Twitter is an author and that's a reason why the functionality that you have as an author extends to every one of the use cases.

The reason why it's important to have this secondary actor here is because we need to be able to see what a follower has access to. Imagine a scenario where we're not rebuilding Twitter but we're rebuilding, say, Wikipedia, where different users can also edit posts. So not only would they be able to write their own post, they could also go and edit a post. And so you'd have other functionality for the secondary type actor. Now, Twitter doesn't have that functionality so we didn't build it in, but that's why it's important to include all of the various actors that are going to be interacting with a specific use case.

Now, when I was originally learning about UML, I would usually run into a couple problems. One is that I'd make a system overly complex, where I would go in and I would take a very simple process and then I would build way too many actors, too many use cases, too many extensions, too many includes, and the system would be very hard to read. And then there were also times where I would oversimplify things and I would not have the right kinds of connections.

One thing that I want you to do is to be able to learn from this solution. If you fell into one of those camps where you made something that was overly complex or you made something that was too simple, don't worry, that was exactly the way that I did it. The only way you're going to learn how to build out an effective diagram is by trial and error and being able to work through problems until you find the right balance. Remember, the goal is, and this is what helps me now in building these, is being able to think of the core functionality that the application needs. This gets a little bit into user experience but also into how the code should be structured. And so the goal of this is, if I were to hand this off to a developer, or if I were to take this and write the system myself, I want to build it in a way where I can look at this use case diagram and in just a few minutes be able to take this and then start to build a framework in my mind for how the system should be modeled.

So nice job going through the use case diagram portion of this project and in the next guide we're going to dive into the class diagram.