UML Modeling: Activity Diagram

UML is a unified modeling language. This UML language consists of several different types of diagrams. In this article we are discussing about the activity diagram.

Introduction

In its fundamental form, an activity diagram is a simple and intuitive explanation of what happens in a workflow, what actions can be performed in parallel, and whether there are alternative paths through the workflow. These diagrams as defined in the Unified Modeling Language [UML1.3] they are derived from a variety of techniques to visually illustrate workflows. Much of the basis for defining the information in these diagrams is found in [Martin & Odell].

We can use activity diagrams to visualize the workflow of a business use case. An absolute workflow explanation will have a basic workflow and one or more alternative workflows. This workflow has a structure that we can describe textually, using informal if, if-then-else, or do-until statements of different types. For a simple workflow with a simple structure, such textual definitions may be moderately adequate, but in the

In the case of more complex structures, these diagrams help to illuminate and create more noticeable what the workflow is. Historically, these diagramming techniques have typically been used in the business process modeling domain, but you can use them in the systems modeling domain as well.

History:

In June 2003, The Rational Edge featured a new series of articles by Donald Bell, IBM Global Services, called UML Basics. The purpose of this series is to help readers become familiar with the major diagrams that make up much of the UML. Part I gave an overview of these diagrams; This month, we continue the series with a closer look at this diagram, recounting the complete set of UML v1.4 notation in this diagram.

The purpose of the activity diagram.

The purpose of this diagram is to represent the technical flow of events that are part of a larger activity. In projects where there are use cases, these diagrams can model an accurate use case at a more complete level. However, these diagrams can be used independently of the use cases to model a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data mart fills the data warehouse of a corporate sales system. Since it models the procedural flow, the activity diagram focuses on the series of execution actions and the situations that activate or guard those actions. This diagram is also focused only on the internal actions of the activity and not on the actions that call the activity in its process flow or that trigger the activity based on some event.

Although UML Sequence Diagrams can represent the same information as Activity Diagrams, I personally find these diagrams to be excellent for modeling enterprise-level functions. This is because these diagrams demonstrate all possible sequence flows in an activity, whereas a sequence diagram typically illustrates only one flow in an activity. Also, business managers and the business process workforce seem to prefer these diagrams over sequence diagrams: an activity diagram has a less “technical” appearance and therefore less threatening to business people. Also, business managers are used to seeing flowcharts, so the “look” of an activity diagram is familiar to them.

When to use: activity diagrams

These diagrams should be used in combination with other modeling techniques, such as interaction diagrams and state diagrams. The key motivation for using these diagrams is to model the workflow behind the system being planned.

Activity diagrams are also useful for:

1. Analyze a use case describing what actions are required to occur and when they must occur.
2. Describe a complicated sequential algorithm.
3. Modeling of applications with parallel processes.

However, activity diagrams should not take the position of interaction diagrams and state diagrams. these diagrams do not provide details about how objects behave or how objects collaborate.

Definition:

Activity diagrams are graphical demonstrations of step-by-step activity and action workflows with maintenance for option, iteration, and concurrency. In the Unified Modeling Language, these diagrams can be used to represent the business and operational step-by-step workflows of the mechanisms in a system. This diagram illustrates the flow of control in general.

Activity diagrams express the workflow performance of a system. These diagrams are parallel to state diagrams because activities are the state of doing something. The diagrams describe the status of the activities presenting the sequence of activities executed. These diagrams can confirm activities that are conditional or parallel.

Structure:

Activity diagrams are built from a restricted number of shapes, joined by arrows. The most significant shape types:

• Rounded Rectangles correspond to Activities;
• Diamonds symbolize Decisions;
• The bars represent the start (split) or end (join) of concurrent activities;
• The black circle represents the start (initial state) of the workflow;
• The black circle within a circle means the end (final state).
• The arrows go from the beginning to the end and represent the order in which the activities happen.

Therefore, all these shapes can be considered as a flowchart shape. Common flowchart methods lack constructs to express concurrency. However, the join and divide symbols in these diagrams only determine this for easy cases. The meaning of the representation is not understandable when randomly combined with decisions or iterations.

Description, meaning and sequence of the basic notations:

• Starting node: The filled circle is the starting point of the diagram. An initial node is not necessary, although it makes the diagram much easier to read.
• End node of the activity: the circle filled with a border is the end point. An activity diagram can have zero or more activity end nodes.
• Activity: The rounded rectangles represent activities that occur. An activity can be physical, such as Inspect Forms, or electronic, such as Show Create Student Screen.
• Flow/Border or Arrows on Diagram: Although there is a subtle difference between flows and borders, I have never seen a practical purpose for the difference, although I have no doubt that it exists. I will use the term flow.
• Fork: There is a black bar with a flow going in and several going out. This denotes the beginning of a parallel activity.
• Join: There is a black bar with several streams going in and one going out. All flows entering the junction must reach it before processing can continue. This denotes the end of parallel processing.
• Condition: In the diagram, there is a text like [Incorrect Form] in a flow, defining a guard that must evaluate to true to traverse the node.
• Ruling: There is a diamond with one flow going in and several going out. The outgoing streams include conditions, although some modelers won’t indicate the conditions if it’s obvious.
• Merge: There is a diamond shape with several streams going in and one going out. The implication is that one or more incoming flows must reach this point until processing continues, based on any protection on the outgoing flow.
• Partition: It is organized in three partitions, also called lanes, which indicate who/what is performing the activities (Requestor, Registrar or System).
• Sub-Activity Indicator: The rake in the bottom corner of an activity, such as the Apply to College activity, indicates that the activity is described by a more detailed activity diagram.
• Final flow: If there is a circle with the X passing through it, it is called final flow. This indicates that the process stops at this point.