Activity diagram - Unified Modeling Language (UML) Tutorial

- [Instructor] Activity diagram is a behavioral diagram that captures the workflow or the process model of a system. If you have learned any kind of flowcharting before, you will find activity diagrams to be very intuitive and easy to draw and understand. To add to its simplicity, activity diagram is quite powerful in its ability to capture parallel tracks in a process, as well as multiple actors involved in a process. For example, let us say I go to a bank to open an account, I tell the front desk assistant and she hands over a form for me to fill in. While I do that, she goes to find the representative who will help me open the account after I have filled in the form. In this example, you see a process unfolding over time, there are three actors involved and the process has a parallel tract. When I'm filling the form, the front desk assistant is looking for and talking to the representative. This entire process can be modeled quite simply in activity diagram and that is why it is a good tool to model different use case scenarios, especially the complex ones, when you're writing up the use case specifications. Although a full scale activity diagram offers many specialized notations, I will cover the most basic six key elements shown in this sample diagram to help you get started. Among these, the first three are quite self-explanatory. The start and end nodes mark the scope of the activity diagrams. The rectangles are for actions that are taken within the activity that is being modeled, and flows are the arrows showing the sequence in which actions are conducted. Let us now look at the remaining three, starting with fork and join. Fork and join help model a parallel flow within an activity. Let us look at an example of event scheduling system that has a use case title, Book event venue. This use case is about booking a venue for an event being organized. In this scenario, event organizers submits the event details such as date, time, et cetera into the system. This event request reaches two people at the same time, making the use case split into two parallel flows. The first horizontal bar, which is called a fork, models the process splitting into two parallel tracks. A fork always has one incoming flow and more than one outgoing flows, indicating parallel tracks. Once the process forks, someone who handles venues for an organization checks the details, in parallel, another person in the organization checks if there is sufficient parking space available for the expected size of audience around the venue requested for. In the basic scenario of this use case, everything seems okay, so the two people checking the venue and its parking approve the request. Once the request has been approved, the two parallel flows join back into a single flow. This is indicated again by the second horizontal bar that is a join bar, with more than one incoming flows and a single outgoing flow. Finally, the event organizer sees the request has been accepted and so she confirms the event venue. It is important to note that for the outgoing flow to start all incoming flows coming into the join bar must have their actions completed. If not, the flow waits at the join bar. Let us now look at decision and merge notations that model conditional flow. Continuing with the same use case, let us say an alternate scenario is that before the parking person accepts requests, she checks if enough parking is available for the given audience size. If yes, she accepts the request, else, she rejects it. This check is the condition denoted by the diamond notation with the question in as text, and possible responses as the outflows. This node has one inflow and multiple guarded or conditional outflows that are mutually exclusive, that is unlike fork, where all outflows executed in parallel. Here, only one outflow will be executed depending on which condition is true. Then after the outflow actions are over, the flow meets a merge node that has multiple inflows and one outflow. Again, any one outflow with its actions completed will take the flow past the merge node. Then, when the event organizer is confirming the event, she checks if the parking request was accepted. If yes, then she confirms the event venue with parking, else, without it. Finally, when you want to model who is doing all these actions, then swimlanes can be very handy. As shown in these same scenarios, a revised version, we have three action doers or actors, each assigned to one swimlane. The actions that we have previously modeled are placed in the swimlane of the actor who does those actions. These swimlanes can be drawn vertically, as shown before, or horizontally, as shown here. I have drawn this diagram using Microsoft Visio because PlantUML doesn't support this feature as of this date. You may also have two dimensional swimlanes, where each dimension represents a specific category of actors. For example, in this case, let us say that this event management functionality is for a university that has many colleges. All preliminary checks about event venue and parking are done by the college staff and then the final decision is then taken by their centralized university department.