If you look at the GitHub page for this project and go down to usage, you'll see that we have a number of different calls we can make. We can call Parser:parse(). We also have conditionals, so if a country code is supplied then it will show us what to do then, and it has all kinds of different features that we need to model right here.

You didn't have to do anything besides show how the system could take in data, and how it could send messages back and forth between methods and between modules.

Here, you can see first and foremost who the participants are. This is a relatively small system.

Remember that what these lines present is the role that this particular module or process is going to play inside of the system. So when one of these elements is communicating with the other it's going to have a line. And what this typically represents is that one module or method is sending a message to another module or method. That is one of the key components to understanding how a sequence diagram works is being able to understand how the message sending component of the application is going to operate.

Let's start at the beginning. We're representing a start point by saying that this is when a client or a user is passing in data to Parser:parse(). The very first thing that this gets is some type of string data. Now what we're doing is checking to see if it can delete all the symbols except numbers. We remove parentheses, dots, dashes, and we're left with a plain string of numbers. The parse system has the ability to clean out any non-numbers.

Notice how Parser:parse() sends a message to itself. Whenever you have a module that's communicating with itself, this is how to visualize it.

After it has performed this process it sends a number length validation message. It sends the string to the Parser:digit_length_validator() module. This is simply going to check to see if the number of digits is valid. We'll get an error for anything lower than 10 digits.

The way the messages work is that it has a solid line for when you're sending a message, and then the response is in a dotted line. The reason for that is because we need to be able to visualize that these responses may be different.

After we've gotten the response from Parser:digit_length_validator(), then we send a request over to CountryCodes:country_code_validator() to check to see if it has a valid country code. It will return an error if the country code is invalid, or give the all clear if it is valid.

The last item, going to our endpoint, is returning a parsed phone number.

That is a basic sequence diagram in UML.