Behavioral Diagrams

• Structural
• Behavioral

Behavioral diagrams illustrate how our system should behave, how it should act, how it should interact with the internal systems, how it interacts with outside actors/individuals/users that are going to be working with the system.

The diagrams we're going to walk through are the

• Activity
• Use Case
• State machine
• Sequence.

We're going to walk through a high-level overview of each of these later on in the course.

Activity Diagrams

This is the activity diagram and it is powerful. Activity diagrams are very easy for non-technical users to see and understand.

When working with a non-technical executive, they may have no idea what UML is, what it stands for, or the components. An activity diagram allows them to look at a board and see what the system is supposed to do from start to finish. Activity diagrams have a nice syntax for both you as a developer along with people who maybe are not quite as technical.

I leverage activity diagrams whenever I'm building a system from scratch. I want to put on a board exactly what is happening at each stage of a user's lifecycle or a systems type of workflow. The elements that are comprised inside of an activity diagram are

• Initial State or Starting Point
• Activity or Action State
• Action Flow
• Decisions or Branching
• Guards
• Final state or End Point

For an example activity diagram, we have a coffee ordering service.

• You can see that it starts with an order, someone is going online and ordering coffee.
• It goes to a decision point based off on the user's decision.

Hopefully, you can see how powerful an activity diagram can be, with one set of elements we've been able to create and render the entire experience that a user would have on a website. This is pretty complex behavior, however, if you handed this to me I would already have ideas on how to build this type of application.

Activity diagrams are high-level because all we care about are activities. We're not getting into the attribute names, method or function names here. We want to see what the experience looks like for a user.

We want to see what happens when the user

• searches for products
• finds a product
• they want to view the product
• What happens if they make a different decision
• They want to add it to the cart

This is a great way of showing all this inside of one diagram.

Use Case Diagram

The next diagram is the use case diagram, again they're a little bit more high level. They give you the ability to show everything that a user has access to. I like to use Use Case diagrams when I'm building out an application and I need to illustrate an authorization system. I want to show what users can do and what admin users can do.

The elements that are used inside of this diagram are

• Use cases
• Actors
• Subsystems
• Relationships.

An example Use Case diagram here is for a marketing engine, you can see actors are displayed on both sides. We have a marketing specialist and we have a customer. Inside of the entire diagram we have use cases, you can see everything that both actors have access to.

We also have connectors that are the actions that go in between each use case. For example, before the customer can get to the form use case, they have to fill something in that form. Whereas the marketing specialist can get to the form use case by generating it. There are different processes each of the actors have access to.

Imagine a scenario where you have an admin user and they are managing a number of employees. An employee might submit a timesheet and that admin user is the one who approves it. Both of those actors go to a timesheet but they have a completely different set of behavior that they have access to. The employee can only submit where the admin can change it, prove it, deny it, or add comments. If you are building some type of authorization system in your application, this is a way of illustrating that.

State Machine Diagram

The state machine diagram is a very old concept in computer science.

What is being visualized is what data looks like and actions at various stages of a software systems lifecycle. The elements are

• Entry point
• Choices
• Constraints
• States
• Transitions.

The example below shows a state machine diagram. We have a lead funnel diagram, It starts with the user (entry point). Each rectangle represents different state. We have a user who's a visitor, based off of their decisions, if they submitted a form then they can change into a converted state. If they qualify for CRM conditions they get moved into a lead state and so on and so forth.

The state machine diagram is a way of breaking down parts into small pieces and showing what users will have access to and show decisions that they have.

You may notice this looks very similar to an activity diagram, that's a good observation. You'll notice the longer you go into UML is there is not one diagram that's perfect for every situation and diagrams have a lot of overlap.

What diagrams you pick to use are going to be determined by the situation. You'll see that each has a scenario where one diagram is a little bit better than another diagram.

Sequence Diagram

Sequence diagrams are a common diagram that many senior-level developers like to use. The reason is, the more advanced as a developer you get, the more you start to think of your application as a system that sends messages either internally or externally. Being able to visualize what those messages look like is incredibly important.

Sequence diagrams are some of the more complex diagrams. This is one of the most important diagrams that you'll learn, they speak directly to the implementation. They speak to how the code needs to operate. If done well, it will make the implementation of the project much easier to build.

The elements that comprise a sequence diagram

• Class Roles or Participants
• Activation or Execution Occurrence
• Messages
• Lifelines.

Looking at an example, we are coming back to our phone parser code library. What we have here is all of those different elements I just spoke about.

If you start at the beginning, from data to parse, each one of those lines with an arrow that is a message. Messages can be sent to a module itself, the first one where it says "delete all symbols except numbers" is a message from the parse engine to itself. From there it goes down that lifeline, it goes down the activation point (the wide rectangle) then it goes to the next one. It sends a message to the digit length validator to validate the number length. The response is the dotted arrow, this is the message that is sent back.

If you think of a program at a very low level, all that matters is setting up the inputs and outputs. What is this method or class, what can be piped into it and what is the expected output? If your systems can think in those terms, what messages are being sent and what messages are being accepted, it is going to give clear understanding of the behavior of the system.

This example goes from starting with the data parsing to the end where the response is an expectation to have a parsed phone number.

If you showed me this diagram, and I didn't write this code, I'd be able to see the two most important parts of the system. I could see that I'm passing in data to parse and I'm expecting to get back a parsed phone number. I know the goal of the library, I could add comments if it helps clarify they expected inputs and outputs.