In its basic form, an activity diagram is a simple and intuitive illustration of what happens in a workflow, what activities can be done in parallel, and whether there are alternative paths through the workflow.<\/p>\n
A complete workflow description will have a basic flow, and one or several alternative flows. This workflow has a structure that we can define textually, using informal if, if-then-else, or do-until statements of various kinds. For a simple workflow with a simple structure, such textual definitions may be quite sufficient, but in the case of more complex structures, activity diagrams help to clarify and make more apparent what the workflow is.<\/p>\n
Historically, activity diagramming techniques have mostly been used in the business process modeling domain, but this article will also briefly discuss how you can use it in the system modeling domain.<\/p>\n
The purpose of this article is to show how you can use activity diagrams within the Rational Unified Process for business modeling as well as system modeling. Activity diagrams are often mentioned almost as a synonym to business modeling. For a more complete introduction to what business modeling is we refer to Kruchten,5 and for details to Jacobson et al.<\/p>\n
The reader of this article is assumed to be familiar with the basics of the Unified Modeling Language (UML).<\/p>\n
Activity diagrams<\/b>\u00a0are graphical representations of\u00a0workflows<\/a>\u00a0of stepwise activities and actions with support for choice, iteration and concurrency. In the\u00a0Unified Modeling Language<\/a>, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.<\/p>\n Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types:<\/p>\n Arrows run from the start towards the end and represent the order in which activities happen.<\/p>\n Activity diagrams can be regarded as a form of a structured\u00a0flowchart<\/a>\u00a0combined with a traditional data flow diagram. Typical flowchart techniques lack constructs for expressing concurrency. However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.<\/p>\n While in UML 1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x, the activity diagrams were reformalized to be based on\u00a0Petri net<\/a>-like semantics, increasing the scope of situations that can be modeled using activity diagrams. These changes cause many UML 1.x activity diagrams to be interpreted differently in UML 2.x.<\/p>\n UML activity diagrams in version 2.x can be used in various domains, e.g. in design of embedded systems. It is possible to verify such a specification using model checking technique.<\/p>\n","protected":false},"excerpt":{"rendered":"Construction<\/span><\/h4>\n
\n