UML is a Unified modeling language. This UML language consists of several different types of diagrams such as Use case diagram, Class diagram, Sequence diagram, Communication diagram, State machine diagram, Activity diagram, Component diagram, Deployment diagram, Package diagram, Object diagram, Composite structure diagram, Timing diagram, and interaction overview diagram. In this article we are discussing about activity diagram.

Introduction

In its fundamental form, an activity diagram is a straightforward and intuitive explanation of what happens in a work flow, what actions can be done in parallel, and whether there are alternative paths through the work flow. Activity diagrams as defined in the Unified Modeling Language [UML1.3] are derived from a variety of techniques to visually illustrate work flows. Much of the basis for the definition of the activity diagram information is found in [Martin & Odell].

We can use activity diagrams to visualize the work flow of a business use case. An absolute work flow explanation will have a basic flow, and one or several alternative flows. This work flow has a structure that we can describe textually, using informal if, if-then-else, or a do-until statements of different types. For a simple work flow with a simple structure such textual definitions may be moderately adequate, but in the case of more composite structures, activity diagrams assist to illuminate and create more noticeable what the work flow is. Historically, activity diagramming techniques have typically been used in the business process modeling domain, but you can use it in the system modeling domain too.

History:

In June 2003, The Rational Edge introduced a new article series by Donald Bell, IBM Global Services, called UML basics. The reason of this series is to help readers become familiar with the major diagrams that create much of the UML. Part I offered a general overview of these diagrams; this month, we continue the series with a close look at the activity diagram, counting this diagram's complete UML v1.4 notation set.

The activity diagram's purpose

The purpose of the activity diagram is to represent the technical flow of events that are part of a larger activity. In projects in which use cases are present, activity diagrams can model a precise use case at a more comprehensive level. However, activity diagrams can be used independently of use cases for modeling 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 populates a corporate sales system's data warehouse. Since it models procedural flow, the activity diagram focuses on the action series of execution and the situations that activate or guard those actions. The activity diagram is also focused only on the activity's interior actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event.

Although UML sequence diagrams can depict the same information as activity diagrams, I personally find activity diagrams excellent for modeling business-level functions. This is because activity diagrams demonstrate all possible sequence flows in an activity, whereas a sequence diagram typically illustrates only one flow of an activity. In addition, business managers and business process workforce seem to favor activity diagrams more than sequence diagrams -- an activity diagram is less "techie" in appearance, and therefore less threatening to business people. Moreover, business managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.

When to Use: Activity Diagrams

Activity diagrams should be used in combination with other modeling techniques such as interaction diagrams and state diagrams. The key motivation to utilize activity diagrams is to model the work flow behind the system being planned.

Activity Diagrams are also useful for:

• Analyzing a use case by describing what actions require occurring and when they should arise.

• Describing a complicated sequential algorithm.

• Modeling applications with parallel processes.

However, activity diagrams should not take the position of interaction diagrams and state diagrams. Activity diagrams do not give detail about how objects behave or how objects collaborate.

Definition:

Activity diagrams are graphical demonstrations of work flows of stepwise activities and actions with maintain for option, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to portray the business and operational step-by-step work flows of mechanisms in a system. An activity diagram illustrates the in general flow of control.

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

Structure:

Activity diagrams are constructed from a restricted number of shapes, linked with arrows. The most significant shape types:

• Rounded Rectangles correspond to Activities;

• Diamonds symbolize Decisions;

• Bars represent the start (split) or end (join) of concurrent activities;

• Black circle stands for the start (initial state) of the work flow;

• Encircled black circle signifies the end (final state).

• Arrows run from the start towards the end and represent the order in which activities happen.

Therefore, all these shapes can be considered as a form of flowchart. Usual flowchart methods are short of constructs for expressing concurrency. However, the join and split symbols in activity diagrams only determine this for easy cases. The sense of the representation is not understandable when they are randomly combined with decisions or iterations.

Description, meaning, and sequence of the basic notations:

• Initial node:

The filled in circle is the starting point of the diagram. An initial node isn’t necessary although it does make it drastically easier to read the diagram.

• Activity final node:

The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes.

• Activity:

The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.

• Flow/edge or arrows on the diagram:

Although there is a subtle difference between flows and edges I have never seen a practical purpose for the difference although I have no doubt one exists. I’ll use the term flow.

• Fork:

There is a black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity.

• Join:

There is a black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing.

• Condition:

In the diagram, there is a text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node.

• Decision:

There is a diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious.

• Merge:

There is a diamond shape with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow.

• Partition:

This is organized into three partitions, also called swimlanes, indicating who/what is performing the activities (Applicant, Registrar, or System).

• Sub-activity indicator:

The rake in the bottom corner of an activity, such as in the Apply to University activity, indicates that the activity is described by a more finely detailed activity diagram. In Figure 2the Enroll in Seminar activity includes this symbol.

• Flow final:

If there is the circle with the X through it called flow final. This indicates that the process stops at this point.

Note: We can include a standard UML note to indicate that the merges does not require all specific number of flows to arrive before processing can continue. An alternative way to model this would have been with an OR constraint between the no match and applicant not on match list flows. However preferring notes makes stakeholders as well as flow creator easier to understand.