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 UML state machine<\/b>, also known as\u00a0UML statechart<\/b>, is an extension of the\u00a0mathematical<\/a>\u00a0concept of a\u00a0finite automaton<\/a>\u00a0in\u00a0computer science<\/a>\u00a0applications as expressed in the\u00a0Unified Modeling Language<\/a>\u00a0(UML) notation.<\/p>\n The concepts behind it are about organizing the way a device, computer program, or other (often technical) process works such that an entity or each of its sub-entities is always in exactly one of a number of possible states and where there are well-defined conditional transitions between these states.<\/p>\n UML state machine is an object-based variant of\u00a0Harel statechart<\/a>, adapted and extended by UML. The goal of UML state machines is to overcome the main limitations of traditional\u00a0finite-state machines<\/a>\u00a0while retaining their main benefits. UML statecharts introduce the new concepts of\u00a0hierarchically nested states<\/a>\u00a0and\u00a0orthogonal regions<\/a>, while extending the notion of\u00a0actions<\/a>. UML state machines have the characteristics of both\u00a0Mealy machines<\/a>\u00a0and\u00a0Moore machines<\/a>. They support\u00a0actions<\/a>\u00a0that depend on both the state of the system and the triggering\u00a0event<\/a>, as in Mealy machines, as well as\u00a0entry and exit actions<\/a>, which are associated with states rather than transitions, as in Moore machines.<\/p>\n The term “UML state machine” can refer to two kinds of state machines:\u00a0behavioral state machines<\/i>\u00a0and\u00a0protocol state machines<\/i>. Behavioral state machines can be used to model the behavior of individual entities (e.g., class instances), a subsystem, a package, or even an entire system. Protocol state machines are used to express usage protocols and can be used to specify the legal usage scenarios of classifiers, interfaces, and ports.<\/p>\n","protected":false},"excerpt":{"rendered":"Construction<\/span><\/h4>\n
\n
State Diagrams<\/h3>\n