Not because I believe it's the perfect example, but because this is a very common process that developers need to model. This is the concept of building e-commerce into a system and depending on what type of job that you're in this is probably going to have to be built out at some point or another. This is an activity diagram that I personally would be able to take and it would give me a very nice visualization of the functionality that I need to build into the system. Not just from being able to track a user going from page to page, but really one of the biggest takeaways for this project is to be able to visualize what happens when things don't go right.

It's very easy and it's one of the most natural things for us to do, is to build out a system like this where we just imagine everything working. But the problem is when we do that, and when we model out a perfect type of scenario, then we're not going to build in the types of checks and balances to make sure that, when a user does something wrong or they have, for example, a bad credit card, that you're able to capture that and able to model what you want the system to do.

When everything goes right, that's actually a relatively simple thing to model. The complexity comes in when you have to model what happens when one thing or even multiple things don't go right. That's where the complexity comes into the system, not only in building out the diagram but also when it comes to building that into a codebase.

So, from our start point, the user has a few different branches right from the beginning. So there might be something where they're searching for a product, or they might want to browse categories, or they might want to view previously saved items. So those are the three potential options.

Now, you also could throw in that if you have a number of items just on the home page they could select a product right there, and that would be perfectly fine to add a fourth branch. But for right here, this outlines the core functionality, so that's what I went with for the solution.

From this point, say that we have searched for a product and we have found it. If that's the case, that would take us to a "View product" page. This is where we can view the product. If not, then it should give them the ability to browse categories, and from there they can pick out a product and then be taken to the view product page. Obviously they can also click on "View saved cart items", and it would just take them to the cart page. That's one of the more straightforward approaches.

Also if they want to go straight to the categories, from there they can select the product. Ultimately, no matter what they do, it's going to take them to a view product page.

From this perspective, what we can do is set up the product parameters. So this might be things such as giving them the ability to select different sizes. Since this a coffee ordering service they might be able to say "I want a quantity of 5" or maybe this specific product only has a small or large, and it doesn't have a medium size. So it's being able to set all of that up, which you're going to do in code and then it's going to translate into what they can do in the system. So they're setting up all of the different optional items like quantity and size. And then from there they can add to the cart.

Now this is where we check in and we look at what type of user we're actually working with. So we send it down to a decision point and we check: are they registered? If no, then we're going to send them to a registration page. If they already are registered then we're going to immediately send them to the view cart page.

So let's imagine that they are not registered. They're a brand new user, they come in, they register, they're going to be redirected to the cart page after that.

Hopefully you can see how helpful this could be when you're modeling a system. Essentially what we're doing is, we're taking a user story, we're taking some type of scenario that we want a user to have and the experience we want them to have and we're building out the system. But even though we haven't actually talked about code at all, by being able to look at this type of diagram, you can come in and see the types of pages that you need to create, and even some of the data elements, like product parameters. And then we know that we're going to need to build in user registration. And so you have all of these types of features that, even though we're not explicitly saying, "Go and build this into the system," by analyzing what the experience needs to be, then we can take this, read it, and then go and code it based off of these types of behavior elements.

Now that we're at the View Cart stage, we have the next set of actions. First it checks to see if the cart is OK. It's asking them "Are you sure that you are ready to go? Is everything in the cart correct?" If they say yes, then it takes them down to the Checkout process. If they say no, then it gives them the ability to update the cart. So imagine a scenario where they picked out five elements and they only wanted four or something like that. They can update the cart, and then after it's been updated, we'll still take them to Checkout.

You'll notice I have multiple Checkout options. With these elements, we have some flexibility. These might all be on the same page, or they might all be on separate pages. And so this gives us a little bit of flexibility based off of usually what the UX people have built out. So if you have a set of screens and wireframes this will say that it either needs to be on one page or they may have a step by step process.

So everything there is good, and you'll notice we have no branches from this stage. Now, once everything is in, we check to see if the payment was a success. If yes, then they are redirected to the payment success page and they're done. That's the entire system. If the payment was not a success, for example, if whoever you're using for billing says there was an issue with the credit card, then they're sent to a payment failure page, and it gives them the ability to enter in new information or try again. If they try again, then they're taken back to "Checkout: choose payment type", and if not then we send them to "Update cart." Maybe they remove some items and it takes them through the whole system again.

So this is how you can build out a full activity diagram for an e-commerce system in UML.