Диаграмма деятельности
Диагра́мма де́ятельности англ. activity diagram — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью англ. activity понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий англ. action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
Наиболее близким и точным аналогом диаграмм деятельности являются математически строгие дракон-схемы визуального алгоритмического языка ДРАКОН. Более отдаленным аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.
Activity diagrams
Activity diagrams are graphical representations of workflows of stepwise activities and actions[1] with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
Contents [hide]
|
[edit] Construction
Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types:
rounded rectangles represent activities;
diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent activities;
a black circle represents the start (initial state) of the workflow;
an encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which activities happen.
Hence they can be regarded as a form of flowchart. 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.
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 Petri net-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
[edit] Applications
An activity Diagram showing MESI protocol in a (>2 cores) processor.
In SysML the activity diagram has been extended to indicate flows among steps that convey physical matter (e.g., gasoline) or energy (e.g., torque, pressure). Additional changes allow the diagram to better support continuous behaviors and continuous data flows.
[edit] Alternatives
In UML 1.x, an alternative to activity diagrams is the UML state machine diagram, in which states can be used to represent activities (namely the state of that activity being performed), and transitions represent the start or completion of activities.
This mapping of activity diagram features to state diagram were formalized in UML 1.x, leaving activity diagrams little more than the use of state machines to capture behavior and partially concurrent behavior within a work flow.
Despite the (small) advantages of using UML 1.x activity diagram over state machines, such as the ability to cover the behaviors of collaborating elements, while state machines are limited to a single element, many modelers continued using state diagrams. State machines were attractive to use as the states may also represent conditions that hold before or after the activities. Activity diagrams and state diagram had similar abilities to express concurrency, though the run-to-completion (RTC) semantics of State machines limited the expressiveness of the concurrency.
Perhaps the most important reason why state machines were more popular in UML 1.x over activity diagrams was that the tool vendors were slow to implement robust activity diagram capabilities.[original research?]
With UML 2.x, the foundation of activity diagram changed from being based on state-machine semantics to now being based on Petri net semantics. This vastly expanded the number of circumstances where activity diagrams are more appropriate to capture the paths of workflow in a system. Now with the advent of robust activity diagram implementations, activity diagrams are now generally used more than state machine diagrams.