\u2022 Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors.
\n\u2022 These are commonly called control flow and object flow models.
\n\u2022 The actions coordinated by activity models can be initiated
\n\u2013 because other actions finish executing,
\n\u2013 because objects and data become available,
\n\u2013 or because events occur external to the flow.<\/p>\n
\u2022 Possibly more than any other UML<\/a> diagram, activity diagrams<\/a> 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. \u2022 An action execution corresponds to the execution of a particular action. \u2022 An action is a named element that is the fundamental unit of executable functionality. The execution of an action represents some transformation or processing in the modeled system<\/a>, be it a computer system or otherwise. \u2022 Activity modeling emphasizes the input\/output dependencies, sequencing, and conditions for coordinating other behaviors.
\n\u2022 Software modeling, activities typically represent a behavior invoked as a result of a method call.
\n\u2022 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.
\n\u2022 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.
\n\u2022 Activity diagrams capture activities that are made up of smaller actions.<\/p>\nActions & Activities<\/h4>\n
\n\u2022 Similarly, an activity execution is the execution of an activity, ultimately including the executions of actions within it.
\n\u2022 Each action in an activity may execute zero, one, or more times for each activity execution.
\n\u2022 At the minimum, actions need access to data, they need to transform and test data, and actions may require sequencing.
\n\u2022 The activities specification (at the higher compliance levels) allows for several (logical) threads of control executing at once and synchronization mechanisms to ensure that activities execute in a specified order.<\/p>\nActions<\/h4>\n
\n\u2022 The action begins execution by taking tokens from its incoming control edges and input pins. When the execution of an action is complete, it offers tokens in its outgoing control edges and output pins, where they are accessible to other actions.<\/p>\nActivity Modeling<\/h4>\n
\n\u2022 Uses secondary constructs to show which classifiers are responsible for those behaviors.
\n\u2022 Focus is on what tasks need to be done, with what inputs, in what order, rather than who\/which performs each task.<\/p>\n","protected":false},"excerpt":{"rendered":"