Section 3.1. Activity Diagram Essentials

3.1. Activity Diagram Essentials

Let's look at the basic elements of activity diagrams by modeling a process encountered earlier in the bookthe steps in the blog account creation use case. Table 3-1 contains the Create a new Blog Account use case description (originally Table 2-1). The Main Flow and Extension sections describe steps in the blog account creation process.

Table 3-1. Create a new Blog Account use case description

Use case name	Create a new Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new blog account from the Administrator.
Preconditions	The system is limited to recognized authors, and so the author needs to have appropriate proof of identity.
Successful End Condition	A new blog account is created for the author.
Failed End Condition	The application for a new blog account is rejected.
Primary Actors	Administrator.
Secondary Actors	Author Credentials Database.
Trigger	The Administrator asks the Content Management System to create a new blog account.
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects an account type.
	3	The Administrator enters the author's details.
	4	The author's details are verified using the Author Credentials Database.
	5	The new blog account is created.
	6	A summary of the new blog account's details are emailed to the author.
Extensions	Step	Branching Action
	4.1	The Author Credentials Database does not verify the author's details.
	4.2	The author's new blog account application is rejected.

Figure 3-2 shows this blog account creation process in activity diagram notation. An activity diagram is useful here because it helps you to better visualize a use case's steps (compared to the table notation in the use case description), especially the branching steps that depend on whether the author is verified.

In Figure 3-2, the activity is launched by the initial node , which is drawn as a filled circle. The initial node simply marks the start of the activity. At the other end of the diagram, the activity final node, drawn as two concentric circles with a filled inner circle, marks the end of the activity.

Figure 3-2. Activity diagrams model dynamic behavior with a focus on processes; the basic elements of activity diagrams are shown in this blog account creation process

In between the initial node and the activity final node are actions , which are drawn as rounded rectangles. Actions are the important steps that take place in the overall activity, e.g., Select Account Type, Enter Author's Details, and so on. An action could be a behavior performed, a computation, or any key step in the process.

The flow of the activity is shown using arrowed lines called edges or paths. The arrowhead on an activity edge shows the direction of flow from one action to the next. A line going into a node is called an incoming edge, and a line exiting a node is called an outgoing edge. Edges string the actions together to determine the overall activity flow: first the initial node becomes active, then Ask System to create new Blog Account, and so on.

The first diamond-shaped node is called a decision, analogous to an if-else statement in code. Notice that there are two outgoing edges from the decision in Figure 3-2, each labeled with Boolean conditions. Only one edge is followed out of the decision node depending on whether the author is authorized. The second diamond-shaped node is called a merge. A merge node combines the edges starting from a decision node, marking the end of the conditional behavior.

The word "flow" was mentioned several times previously and you may askwhat's flowing? The answer depends on the context. Typically, it's the flow of control from one action to the next: one action executes to completion, then gives up its control to the next action. In later sections you'll see that, along with control, objects can flow through an activity.