Technology Trends -- Software Modelling from UML to Kanban

CHLOE: Hi. My name's Chloe, and I'll be teaching you everything you need to know about UML use case diagrams. We'll start with a high-level overview, then we'll talk about systems, actors, use cases, and relationships. And finally, we'll build an entire use case diagram together and go over examples to explain these concepts in depth.

Have you ever had an idea that makes perfect sense in your head, but when you try to explain it to someone else, they're completely lost? Maybe your idea is for a new app, and every time you talk about it, people don't really understand how they'd interact with the app or what it would do. This type of scenario is where a use case diagram is very helpful.

Here's a simple description of a use case diagram. First, it shows a system or application. Then it shows the people, organizations, or other systems that interact with it. And finally, it shows a basic flow of what the system or application does. It's a very high-level diagram, and typically won't show a lot of detail, but it's a great way to communicate complex ideas in a fairly basic way.

Before we really get into the tutorial, let's talk about how you're going to make a use case diagram. You can draw them out with pen and paper, but a diagramming application is going to be much easier. Today, I'll be using Lucidchart and you can, too, for free, actually.

Just click the link to access Lucidchart's website. Enter email address, and you'll have a free Lucidchart account in just a few seconds. It's easy to use, and you can follow along with me as we build a use case diagram.

OK. So we're going to break down use case diagrams into four different elements-- systems, actors, use cases, and relationships. Let's start with systems. A system is whatever you're developing. It could be a website, a software component, a business process, an app, or any number of other things.

You represent a system with a rectangle, and you put the name of the system at the top. We're going to build a use case diagram for a very simple banking application. We'll call our system Banking App.

This rectangle helps define the scope of this system. Anything within this rectangle happens within the Banking App. Anything outside of this rectangle doesn't happen in the Banking App.

The next element is an actor which is depicted by this stick figure. An actor is going to be someone or something that uses our system to achieve a goal. That could be a person, an organization, another system, or an external device.

So who or what is going to be using our Banking App? The most obvious actor is a customer. We are going to have customers that download and use our Banking App. Another actor that we'll want in our diagram is the bank. The bank is going to provide information that feeds into our Banking App, like transactions and account balances.

Here are a couple of things to keep in mind when dealing with actors. First, it's important to note that these actors are external objects. They always need to be placed outside of our system.

Second, actors need to be thought of as types, or categories. For our Banking App, an actor isn't going to be a specific individual or a specific organization. We wouldn't label our actors as John and Chase Bank. We want to keep things categorical.

So right now, we're saying that both customers and banks are going to use our app, and this brings up the topic of primary and secondary actors. A primary actor initiates the use of the system, while a secondary actor is more reactionary. So, in our example, which actor is primary and which actor is secondary?

The primary actor is customer. The customer is going to initiate the use of our system. They're going to pull out their phone, open up our Banking App, and do something with it. The bank, on the other hand, is a secondary actor. The bank is only going to act once the customer does something.

If the customer goes on the app to see how much money is in their account, only then does the bank engage with our system to provide the balance. Primary actors should be to the left of the system, and secondary actors should be to the right. This just visually reinforces the fact that customer engages with the Banking App, and then the bank reacts.

The next element is a use case. And this is where you really start to describe what our system does. A use case is depicted with this oval shape, and it represents an action that accomplishes some sort of task within the system. They're going to be placed within the rectangle because they're actions that occur within the Banking App.

So what is our Banking App going to do? We're going to keep things very simple. Our Banking App is going to allow a customer to log in, check their account balance, transfer funds between accounts, and make payments towards bills.

So if this is what our Banking App does, we're going to have use cases that describe each of those actions. We'll have a use case called login, another called check balance, another called transfer funds and, finally, make payment. You can see that each of these use cases starts with a verb and reinforces an action that takes place. We also want them to be sufficiently descriptive. If this use case just said transfer, that'd be too vague.

Finally, it's good practice to put your use cases in a logical order, when possible. That's why we put log in at the top. That's the first thing that will happen when a customer uses our Banking App.

The final element in use case diagrams are relationships. An actor, by definition, is using our system to achieve a goal. So each actor has to interact with at least one of the use cases within our system. In our example, a customer is going to log into our Banking App, so we draw a solid line between the actor and the use case to show this relationship.

This type of relationship is called an association, and it just signifies a basic communication or interaction. A customer is going to interact with the rest of these use cases as well. They're going to check balance, transfer funds, and make payment, so we'll draw solid lines out to each of those as well.

Secondary actors will also have relationships. Remember, each actor has to interact with at least one use case, so which use cases will the bank interact with? When a customer wants to check their balance on the app, the bank is going to provide the correct amount. Let's draw a line between bank and check balance.

Similarly, when a customer wants to transfer funds or make a payment, the bank is going to follow through with those transactions. We don't need to draw a line to log in because that process happens within the Banking App. There is no need for the bank to actually get involved with the login process.

There are three other types of relationships in addition to association. There's include, extend, and generalization. Let's build out this diagram with additional use cases in order to explain these types of relationships.

When a customer types in their login information, our Banking App is going to verify the password before completing the login process. But if the password is incorrect, the Banking App is going to display an error message. So let's create two new use cases for verify password and display login error.

When a customer wants to transfer funds or make a payment, our Banking App is going to make sure there's enough money to complete those transactions. So we'll also create another use case called verify sufficient funds. And finally, when a customer wants to make a payment, our Banking App is going to give them the option of paying from either their checking account or their savings account. So we'll create two more use cases called pay from checking and pay from savings.

Let's circle back to this verify password use case and talk about relationships again. How does verify password relate to the rest of the diagram? Neither of our actors are directly initiating this action. It's just immediately going to happen within our Banking App every time there's an attempt to log in. This is an include relationship.

An include relationship shows dependency between a base use case and an included use case. Every time the base use case is executed, the included use case is executed as well. Another way to think of it is that the base use case requires an included use case in order to be complete. When you have an include relationship, you draw a dashed line with an arrow that points towards the included use case.

So, in our example, log in is the base use case, and verify password is the included use case. Every time a customer logs in, our Banking App will automatically verify password. This login use case won't be complete unless verify password is complete. So we draw a dashed line with the arrow pointing towards the included use case, and we write include in double chevrons.

The next type of relationship is the extend relationship. An extend relationship has a base use case and an extend use case. When the base use case is executed, the extend use case will happen sometimes, but not every time. The extend use case will only happen if certain criteria are met.

Another way to think of it is that you have the option to extend the behavior of the base use case. When you have an extend relationship, you draw a dashed line with an arrow that points towards the base use case. In our example, log in is a base use case, and display log in error is an extended use case.

Our Banking App won't display a log in error message every time a customer logs in. This will only happen once in a while when a customer accidentally enters an incorrect password. Since this is an extend relationship, we draw a dashed line with an arrow that points to the base use case, and write extend between double chevrons.

Hopefully, this thoroughly explains the difference between include and extend relationships, but just in case, here's a very basic example to help differentiate between the two. If you sneeze, you will close your eyes. That's an included relationship because it's going to happen every time.

Additionally, if you sneeze, you might say excuse me. That's an extended relationship because it supplements the sneeze, but isn't completely necessary in the sneezing process. Just remember that include happens every time, extend happens just sometimes, and don't forget that the arrows point in opposite directions.

One quick thing to note is that multiple base use cases can point to the same included or extended use case. For example, both transfer funds and make payment are going to point to verify sufficient funds as an included use case. We want our Banking App to make this check every time either of these base use cases occur. You don't need to duplicate the verify sufficient funds use case, the simpler your diagram, the better.

The last type of relationship we'll discuss is generalization, also known as inheritance. When you make a payment from our Banking App, you can do so from either your checking account or your savings account. In this scenario, make a payment is a general use case, and pay from savings and pay from checking are specialized use cases.

You could also use the terms parent and children. Each child shares the common behaviors of the parent, but each child adds something more on its own. To show that this is a generalization, we draw this type of arrow from the children up to the parent. You can have generalizations on use cases like we have here.

You can also have generalizations with actors. In certain scenarios, you might want to distinguish between a new customer and a returning customer. You can make them both children to a general customer actor, which would allow you to have certain behaviors or qualities unique to each of these children.

One last shape that we'll quickly talk about is a use case with extension points. You can see an example here. The name of the use case is above the line, and then there are extension points below the line. Extension points are just a detailed version of extend relationships.

This use case shows that a customer can set up their profile in our Banking App. And then these extension points show us that when a customer is setting up their profile, they'll have the option to navigate to a couple different screens. If a customer is confused, they can go to Profile Help.

And if they want details regarding their private information, they can go to Privacy Info. Those extension points branch off to extended use cases-- Go to Profile Help and Show Privacy Info. We can even add a note to show what sort of conditions would lead to these extension points.

Now we have a complete use case diagram with various elements that help explain what our Banking App does. This is a very basic example. But remember that even complex systems should be restricted to a simplistic visualization of functionality, behavior, and relationships. If you'd like to take a closer look at this example, click on the Card in the upper right-hand corner. You'll find this exact Banking App example, plus several other examples and resources.

Thanks for watching this tutorial on UML use case diagrams. Please subscribe to our channel to see more helpful tutorials. Leave a comment below if you have any thoughts or questions. And lastly, click here to try Lucidchart for free, and start making your own UML diagrams.

[MUSIC PLAYING]

MAX REHKOPF: Kanban is a work management system designed to help you visualize your work, limit work in progress, and maximize efficiency, which we call flow. "Kanban" is the Japanese word for "visual signal." With so many of us working in services and technology, oftentimes our work is invisible or intangible. Kanban helps you visualize your work so you can understand it better, show it to others, and keep everyone on the same page. Most teams realize this benefit by building a Kanban board, filling it with Kanban cards, and setting up a work in progress limit.

I'm Max. I'm a product marketing manager on Jira software. And I'm naturally kind of a chaotic person. I seem to always find myself in fast-paced environments. I've been on really dysfunctional teams, and in the past, been in dysfunctional organizations.

The number of times that I've seen Kanban kind of bring method to the madness to change the culture of the organization and just help me get work done has me basically shouting from the rooftops about Kanban. So I actually have a lot to say. And I've broken this conversation up into a series of videos all here on our YouTube channel. So the first thing that I would ask is that you subscribe to the channel so you can hear this whole conversation play out. I want to show you something.

One of my favorite things about Kanban is the Kanban starts with what you do now. This is actually one of the Kanban principles, another being that Kanban respects current roles and responsibilities exactly the way that they are today. You simply apply the Kanban methodology to how you currently work. Another Kanban principle is that Kanban encourages acts of leadership from all levels. It's on the team to work together to make Kanban work for you.

Now, if those principles are something you can get excited about, then you might want to start by making a Kanban board. So this is what I wanted to show you. It's a Kanban board that I built to visualize all the concepts we're covering in this video series.

I just finished talking about the Kanban principles. And it's important that I started on the right side of the board here. Kanban is a pull system, which means, when you have bandwidth, you look to the left and pull cards from left to right. Since I have bandwidth now, I'm ready to start my discussion of Kanban boards.

Kanban boards like this one can be built on walls, windows, whiteboards, or with a suite of digital tools like Trello and Jira. Their purpose is to categorize all the stages of work that a work item flows through from something you haven't started to something that's done. This is called a workflow.

You'll notice that each stage in the workflow has its own column. And our workflow is super simple. Your workflow might be more complex, but I'd encourage you to start as simple as possible. You can always add more columns later.

So for now, I'm done with this quick explanation of Kanban boards. I'm going to take this card from something I'm doing to something that's done. Since I have bandwidth again, I'm ready to move a card from today into doing. Let's kick off our Kanban of Kanban cards.

For the agile software developers among us, cards should be a familiar concept. You can think of them as one Kanban card per user story. For the rest of us, we can just back up. You can think of Kanban cards as being work items, one card per work item. You want to make cards for all the things you're working on and place them in the appropriate stage of the workflow.

Kanban cards should have a title, and a description, and an owner. You can also add any other helpful information like a due date. Then your card should start to gain a little bit of a history as your team leaves updates on the card as it moves from one stage of the workflow to the other.

The Kanban card should be small enough that your team can make progress on them in a reasonable amount of time. You don't want them so large that it'll take you weeks to move the card forward. And you don't want them so small that it's literally every task that you're working on. Can you imagine how chaotic your board would be if it was every task your team was working on? You want to avoid that.

Once you build a board and you fill it with cards, you'll start to realize one of the key benefits of Kanban. You'll see columns that start to bunch up, revealing a bottleneck in your workflow. You'll also get a sense of what size cards your team can move forward in a timely manner. These efficiencies, we like to call flow. And Kanban is built to help teams flow work better from the backlog to done.

Once you understand flow, you can start to measure it. Kanban teams concern themselves with lead time, which is the time that it takes for a card to flow through your workflow from when you start working on it to when you're done. It's in the hands of the customer.

And with that, I feel done with my conversations about lead time. And thanks to this board that I built, I actually know that I'm done. I have visual assurance that I've done all the things that I set out to do in this video. It's a good feeling.