Usually, when I'm building our use case diagrams I'm focusing on the permissions and I'm building a tool that will let me build my authorization system. But here I think we can take it a step further and we can get even closer to what the implementation is going to look like. In this particular application gives us a really nice opportunity for doing that.

So first let's take a look at each one of our actors. We have a marketing specialist. We have the system notification engine component of the system and then we have a customer. One of the most important elements of this diagram is being able to integrate an actor who is never going to technically interact with the system itself at least in the traditional way. The only type of action and use case that the customer is going to do is they're going to submit a form. After that the dialogue the communication.

All of those elements are going to happen outside of the system. And from that point it's going to be only the marketing specialist who is interacting with us. If we think of a real world use case this would be like a potential customer going and typing in a contact form on a Web site from there that kicks off a process where it notifies the marketing specialist and it's perfectly fine if you included these types of artifacts such as include here, I do those simply because I want to give myself a little notation to let me know that in this submit form I'm going to have to include this module this notification module. But if you did not have that in there it's still perfectly valid UML. So following the chain of events after we've notified the marketing specialist from there it goes and it starts sending the communications out.

Now sending communication can mean many different things for this type of system. It might be an email it might be an SMS it might be some outside service like hipchat or slack and we need to be able to take all of that into account. Whenever I have a system that needs these type of extensions where it's one action such as sending a message but that action may have to get visualized and may have to happen in many different formats than what I typically do is I create this type of wrapper module like send communication and then all of the other actors all the other use cases can interact with this one use case and then it can be in charge of routing traffic to whatever outlet it needs to go to. So it's going to send communication. And that may be an email, SMS message, or anything like that. And the marketing specialist also has this kind of communication layer. Now I'm going to get into him at the very end.

Let's moved to the notification engine what it is in charge of is sending special offers sending reminders and the cool thing about building a system like this is we can leverage this communication module, so it's not just how a user is interacting with the marketing specialist and vice versa. We can use each one of these communication components for other things. Since this is being modeled on a real world application that we're currently building out I can give you a really good example of how this works. Not only will a lead start the communication chain but also we're using our notification system to do tasks such as sending out these type of offers. So if we have a restaurant that has a number of people who have signed up they can go and the notification system can send SMS messages to their users promoting specials such as happy hour deals or coupons. And even though this communication module in this sense is usually used for managing leads it can also be leveraged for all kinds of other use cases so that is something to keep in mind whenever you're building any type of system whether it's say an image uploader many times an image uploader can also be a file uploader for PDF's and Word documents in with the proper software engineering you can build your systems to become much more scalable so that one module has the ability to perform many different tasks not by itself we still need to follow our good design patterns but what it can do is wrap up and extend itself. And that's the reason why I added these extend types of artifacts here to show that these elements these are going to have to be modules possibly and applications all by themselves but they're going to interact with this send communication type of process.

Now lastly coming to the marketing specialists. They're the ones who are going to be interacting with the system the most. So they need to be able to view reports, manage contacts, manage forms, and then lastly as we've already mentioned participate in this entire communication chain. So this is something that is a little bit different than some of the other use case diagrams we've built up until this point. And it is a very important type of diagram to understand mainly because there are going to be many times where you do have to build use cases where you have one actor such as we have with our customers here who has limited system interaction. But you still have to model what those interactions are going to look like and how it fits in with the rest of the system.

And then secondly the most important thing that I want you to take away from this particular solution is how you can visualize some type of abstract wrapper like we have here with send communication so that you can build your systems in a way that they're scalable and that they're flexible.