Activity modeling focuses on the execution and flow of the behavior of a system, rather than how it is assembled. Possibly more than any other UML diagram, activity diagrams apply to much more than just software modeling. They are applicable to just about any type of behavioral modeling; for example, business processes, software processes, or workflows. Activity diagrams capture activities that are made up of smaller actions .
When used for software modeling, activities typically represent a behavior invoked as a result of a method call. When used for business modeling, activities may be triggered by external events, such as an order being placed, or internal events, such as a timer to trigger the payroll process on Friday afternoons. Activity diagrams have undergone significant changes with UML 2.0; they have been promoted to first-class elements and no longer borrow elements from state diagrams.
An activity is a behavior that is factored into one or more actions. An action represents a single step within an activity where data manipulation or processing occurs in a modeled system. “Single step” means you don’t break down the action into smaller pieces in the diagram; it doesn’t necessarily mean the action is simple or atomic. For example, actions can be:
Calls to other behaviors (modeled as activities)
Processors of data (attributes of the owning object, local variables, etc.)
Translating these ...