[SysML] #21. Understanding Activity Diagram - Auto EE Sys Engineer`s Blog

Activity diagrams are used to define and visualize the tasks performed within a system and the input/output flow and control flow between those tasks. These diagrams are particularly effective at showing the workflow of a system: what needs to happen and when, and what decisions need to be made along the way.

In SysML, Activity Diagrams allow you to break down the behavior of a complex system into steps, clearly expressing how each step is related to one another. In particular, it describes the process of converting inputs into outputs through the operation of a system.

SysML provides activity diagrams, sequence diagrams, and state machine diagrams to specify system behavior. They can all express sequential and simultaneous actions and occurrences of events over time, but each has strengths and weaknesses. Activity diagrams are particularly useful for expressing behavior through the flow of objects (matter, energy, data) and have the main advantage of being able to represent complex control logic and ongoing system behavior.

쉬운 목차

Understanding Activity Diagram

Advantages of Activity Diagrams

Ease of reading: Complex control logic can be expressed better than other diagrams.
Behavior Representation: Allows you to uniquely express ongoing system behavior.

Disadvantages of Activity Diagrams

Ambiguous: Activity diagrams can express the order in which tasks are performed, but there are limitations in expressing the structure that calls each task. This compares to the detail a sequence diagram can provide.

When is the Right Time to Create an Activity Diagram

Communication with stakeholders : Activity diagrams are very useful in communicating with stakeholders and clearly capturing and describing the expected behavior of the system and its actors. This provides a visual representation of the system’s behavior, making it easier for stakeholders to understand.
Communication within the team : Activity diagrams can be used to share and discuss with team members the expected behavior of the internal parts of the system. This helps build a common understanding of the system’s behavior within the team.
Not bound to a specific stage of the system life cycle : Activity diagram creation is not limited to a specific stage of the system development process. It can be useful in various stages of system development, including analysis, design, and verification.

Purpose of Activity Diagram

Use as an analysis tool : Activity diagrams are an effective tool for analyzing and understanding complex system behavior. By visualizing system flows and processes, you can understand and analyze system behavior more clearly. This is useful when collaborating with stakeholders.
Graphical Use Case Specification : Some modeling methodologies use activity diagrams to graphically represent the use cases of a system. It complements or replaces text-based use case specifications, providing a more intuitive understanding of the behavior of the use case. Whenever you add a new use case to your system model, you can create an activity diagram to model the behavior of the use case specifically.
There may be some limitations in providing clear specifications for detailed design or system implementation.

Basic structure of an activity diagram

Diagram header : act [model element type] activity name [diagram name]
Diagram Type: The diagram type of the activity diagram is indicated as “act”. This indicates that this is an activity diagram and is the unique identifier for this diagram in SysML.
Model Element Type : In activity diagrams, the model element type is usually “Activity”. However, other elements such as “control operators” may also be included. This means that an activity diagram goes beyond simply representing the sequence or flow of tasks, but also expresses how tasks are controlled and connected.

Characteristics of Activity

Definition of Activity : Activity is a model element and a type of behavior. They can also act as namespaces, like blocks or packages, and contain a set of named elements (nodes and edges) within the model hierarchy.
Distinction between Activity and Activity Diagram : The term “Activity” refers to a model element, which is different from an Activity Diagram. An activity diagram is just a view of the model, not the model itself.

Actions to begin and end execution

Basic requirements for running tasks

Before starting work, several prerequisites must be met:

Running status of owning activity : The activity to which the task belongs must be running. If an activity is inactive, the task cannot be started.
Token Requirement for Input Pins : The number of tokens available on each required input pin must be greater than the lower multiplicity limit. This means that sufficient input must be in place before work begins.
Token in control flow : Each operation must have a token available in the receiving control flow. This token is used to determine the progress of the operation.
Execution of tasks and consumption of tokens : On every input, tokens are consumed by the task. This means that the task runs using the resources it needs.

Requirements for Ending Tasks

Requirements for terminating a task are:

Token Requirement on Output Pins : The number of tokens available on each required output pin must be greater than the lower multiplicity limit. This means that the results of your work must be ready to be passed on to the next step.
Token placement in control flow : When a task ends, tokens on all output pins are placed for use by the next task, and a control token is placed for each outgoing control flow.

Emergency termination of task

When a task is running, when the activity that owns the task terminates, the task terminates as well. This indicates that tasks are closely linked to the life cycle of the activity.

Routing of tokens

Objects and control tokens are stored using control nodes that allow buffering, copying, and removal.

Elements in Activity Diagram

Call Behavior Actions

Call Behavior Actions are an important component of SysML, used to decompose complex behaviors into simple, manageable parts. In this post, we will take a closer look at how this component works and how it can be utilized in real-world modeling.

1. Definition

Call Behavior Actions are special actions that activate other actions. You can use it to decompose complex operations into simpler operations, making your system design more manageable.

2. How to use

Call Behavior Actions can invoke one of three main types:
- Interaction
- State Machine
- Other Activities

This typology makes it clear how the various functions and processes of the system relate to each other.

3. Notation

Call Behavior Actions are indicated by a rectangle with rounded corners, and the name is written inside in the format <action name> : <action name>. The modeler defines the name of the behavior, which must match a predefined name within the model hierarchy.

4. Meaning of the rake symbol

If a rake symbol is present, it indicates that the called activity is an activity.

Send Signal Action

The Send Signal Action is an essential tool in systems engineering for effectively modeling distributed and concurrent systems. These systems are often complex and require asynchronous mechanisms to efficiently transfer data or commands between various parts. In this post, I will explain in detail the functionality and importance of the signaling operation.

1. Application in system design

The Send Signal operation asynchronously creates a signal instance and sends it to a specific destination. This plays an especially important role in large-scale distributed systems where scalability and performance are important. It helps ensure that various parts of the system operate simultaneously and exchange necessary information in a timely manner.

2. Asynchronous mechanism

The signal generated by the signaling operation is transmitted from the sender to the destination in the form of matter, energy, or data. Because this process is asynchronous, the sender can immediately perform the next action without caring whether the signal was received or not. This helps maximize efficiency and reduce bottlenecks in the system.

3. Notation

The signaling task is represented in the activity diagram by a convex pentagon shaped like a sign. Inside you will see the name of the signal, which must match a signal defined within the model hierarchy.

Accept Event Action

Accept Event Task is a special kind of task used in activities that wait for an asynchronous event to occur. Typically, this asynchronous event means the receipt of a signal instance. Accepting an event operation indicates that the activity must wait for the occurrence of a specific signal or event before continuing execution.

1. Activation conditions for Accept Event Action

If the Send Signal operation created a signal instance, then Accept Event Action operation completes immediately and advances control flow to the next node.

2. Notation for Accept Event Action

Accept Event Action is represented by a concave pentagon that looks like a rectangle with a triangular groove cut out on one side. The string displayed inside usually matches the name of a signal defined somewhere in the model hierarchy.

3. Accept Event Action and asynchronous communication

Accept Event Action is used to model asynchronous communication within an activity or between different activities. This allows us to express synchronization for asynchronous events that occur between independently concurrent flows within the system.

Wait Time Actions

Wait Time Actions are a special kind of event acceptance action that waits for a time event to occur. This action indicates that the activity must wait for the occurrence of a specific time event before continuing execution. Typically, this time event can be an absolute time event or a relative time event.

1. Activation conditions for Wait Time Actions

Wait Time Actions can be activated when a control token arrives in an incoming control flow. If the specified time event has already occurred, the latency operation completes immediately and advances control flow to the next node. If a time event has not occurred, the wait time operation waits for that time event to occur.

2. Notation for Wait Time Actions

Wait Time Actions are represented by a stylized hourglass symbol, with a time expression string below it. This notation indicates that Wait Time Actions are waiting for a time-based event.

3. Time event expression

Absolute time events represent events that occur at a specific point in time, using expressions that start with the “at” keyword, for example at (1430 GMT).
Relative time events represent events that occur after a certain period of time, using expressions that start with the “after” keyword, for example after(30 days).

4. Applications of Wait Time Actions

Wait Time Actions are used to model time-based actions within a system. For example, it can be used to wait a certain amount of time before starting a certain task, or to model periodic tasks.

Control Node

Control nodes play an important role in activity diagrams and are used to control the execution flow of activities. Below is a description of the main types of control nodes and how they work:

Initial Node

Definition : Indicates the starting point of an activity.
Notation : Represented by a small black circle.
Role : Used to initiate control flow when the activity starts.

Activity Final Node

Definition : Indicates the end point of an activity. When this node is reached, the entire activity terminates.
Notation : Represented as a black circle with a larger circle surrounding it.
Role : Terminates execution of an activity and stops all execution flow.

Flow Final Node

Definition : Terminates a specific flow of execution, but does not terminate the activity itself.
Notation : Represented as an X.
Role : Terminates the execution of only a specific path, while other execution flows within the activity can continue.

Decision Node

Definition : Used to select one of several paths based on conditions.
Notation : Represented as a diamond shape.
Role : Implements conditional logic and branches the execution flow into one of several branches.

Merge Node

Definition : Merges multiple input flows into one output flow.
Notation : Represented by the same diamond shape as the decision node.
Role : Used to merge multiple branched flows back into one.

Fork Node

Definition : Splits one input flow into multiple parallel output flows.
Notation : Represented as a long black bar.
Role : Splits the execution flow in parallel, allowing multiple tasks to be started simultaneously.

Join Node

Definition : Combines multiple parallel input flows into one output flow.
Notation : Represented as a long black bar identical to the fork node.
Role : Rejoins multiple flows running in parallel into one, allowing sequential execution to continue.

Activity Partitions

Activity Splitting is used to convey the structure (block or part attribute) that performs each task within an activity diagram. It refers not only to the sequence of tasks within an activity, but also to the structural aspects of the system that performs those tasks.

Notation for Activity Splitting

An activity partition is represented by a large rectangle with a header at one end, where the header specifies the structure that the activity partition represents. Activity partitions can be oriented vertically or horizontally.

Relationship between activity partitions and structures

Tasks placed within an activity partition are assigned to the structure named in the header. This means that those structures are responsible for performing their tasks during system operation.
When an activity partition represents a block, operations involving all instances of that block can be performed.
If the activity partition represents partial properties, perform the operation containing only one of those partial properties.

Central buffer node & Data Store node

In the SysML activity diagram, the Central Buffer Node and Data Store Node provide advanced mechanisms for storage and management of object tokens. These nodes are particularly useful when modeling complex system behavior and have the following characteristics:

Central Buffer Node

Definition : The central buffer node provides storage for object tokens outside of pin and parameter nodes. Tokens flow into a central buffer node, are stored there, and then flow out again when needed.
Use Case : Used when needed between multiple producers and consumers of a single buffered token stream. This is in contrast to pin and activity parameter nodes, where there is only a single producer or consumer for a token.
Notation : Appears as a rectangle with the keyword «centralBuffer» above the name string.

Data Store Node

Definition : A data store node is a type of object node that provides a copy of a stored token. If the input token represents an object already in the store, the previous token is overwritten.
Use Case : Used when multiple tasks need to access the same object token while the activity is running. The data store supports import semantics for existing flowcharts.
Notation : Appears as a rectangle with the keyword «datastore» above the name string.

Common Features of Central Buffer Node and Data Store Node

Both node types store tokens only while the parent activity is running. If the token value requires persistent storage, you should use a property.
Data storage nodes and central buffer nodes facilitate the flow and management of data in complex system operations. For example, these nodes can be utilized to store the current image from a video capture activity and use that image for various processing tasks.

Interruptible Regions

Interruptible regions are regions that group a subset of tasks within an activity and contain a mechanism to interrupt the execution of those tasks. This region can terminate all operations within the region when certain conditions are met, for example when a certain signal is received.

Interrupt Edge

Interrupt edge is a special type of edge that starts from a node inside the interruptible area and connects to a node outside it. This edge can be both control and object flow, and serves to interrupt the execution of operations within the interruptible region.

Enabling and stopping interruptible regions

When an interruptible region is entered, at least one task within that region begins execution.
An interrupt in the interruptible area occurs when a token is acknowledged through an interrupt edge. This terminates all tasks running within the region, and execution continues on the activity node that accepted the token at the interrupt edge.
Interruptible regions are indicated by a dotted round corner box, and the region name may appear inside. Breaking edges are indicated by a lightning bolt symbol or a regular flow line with a small lightning annotation floating near the center.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #7. How to draw a Req Diagram with EA

[SysML] #8. Understanding SysML UseCase Diagram

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram

[SysML] #12. Understanding Part Property of Block