The\u00a0Unified Modeling Language<\/b>\u00a0(UML<\/b>) is a general-purpose, developmental,\u00a0modeling language<\/a>\u00a0in the field of\u00a0software engineering<\/a> that is intended to provide a standard way to visualize the design of a system.<\/p>\n The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at\u00a0Rational Software<\/a> in 1994\u20131995, with further development led by them through 1996.<\/p>\n In 1997, UML was adopted as a standard by the\u00a0Object Management Group<\/a>\u00a0(OMG), and has been managed by this organization ever since. In 2005, UML was also published by the\u00a0International Organization for Standardization<\/a>\u00a0(ISO) as an approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of UML. In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from 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":"Activity diagram<\/h3>\n
Construction<\/span><\/h4>\n
\n