Antecedentes Históricos

In this section, basic elements used in UML/SysML ADs are initially reviewed and then a simple AD example is introduced to show the applicability of this diagram. Definitions and terminologies adopted in this work used in UML Specification 2.5 Standard.

An AD is used to describe industrial systems and processes flow, expressing how actions are taken, what they do, when they take place, where they take place and how they affect other actions around them, i.e. their effects. An AD consists of nodes such as the initial, activity final, opaque action, decision, etc. and edges such as the control flow edges, used to link nodes together. The concept of this diagram is based upon the flow of tokens. These tokens can represent data, information, items, energy, etc. Tables 2.1 and 2.2 review the basic AD node notations, whereas the most commonly used AD edge is described in Table 2.3.

26

Table 2.1 includes the control flow nodes used in Activity Diagrams to coordinate the flows between other nodes. In an AD, the token flow starts using an activity initial

node and is terminated by an activity final or a flow final node. The difference

between these two terminal nodes is that the former represents the completion of all flows existing in a process, whereas the latter the completion of a flow, destroying all tokens arriving at it without affecting any other flow existing in the activity. Additionally, as seen in Table 2.1, decision and merge nodes share the same notation: a diamond shape, whereas similarly fork and join nodes use the same notation: a bar (vertical/horizontal). Fork nodes that synchronise outgoing concurrent flows and join nodes that synchronise incoming concurrent flows, have been introduced in the AD to enable modelling of parallel activities.

Table 2.1 Notation and Description of Activity Diagram Control Nodes

Nodes

Notation _Description

Name Symbol

Activity Initial

Node Represents the beginning of a process/workflow. Activity Final

Node Represents the completion of a process/workflow. Flow Final

Node Represents the completion of one flow exists in a process. Decision Node Represents the branching of two or more activity _flows.

Merge Node Represents the merging of two or more activity _flows.

Join Node Represents the combination of two concurrent _{activities, reintroducing them into the flow as one.}

Fork Node Represents the separation of one activity flow into _{two concurrent activities.}

Apart from the control nodes, additional fundamental AD nodes such as action and

activities are reviewed in Table 2.2. The execution of an action node shows the

27

in an AD. There are various kinds of actions in UML2/SysML. Among them, the opaque action node, which is considered as one of the most commonly deployed in ADs, is a type of action that can be used to represent implementation of information or a temporary placeholder before other actions are chosen. The execution of an

activity node shows the executions of actions included within it, i.e. an activity node

contains an AD.

Table 2.2 Notation and Description of Activity Diagram Nodes

Nodes Notation

Description Name Symbol

Action This node cannot be further decomposed within the activity. An action node that represents a single step within an activity can have input and output control flow edges.

Activity Represents a behaviour composed of actions.

Table 2.3 shows the most commonly used AD edge, the control flow edge, which connects the nodes together and enables the flow of tokens.

Table 2.3 Notation and Description of Activity Diagram Edge

Edges Notation Description Name Symbol Control Flow

This edge illustrates the control flow within an activity. Within the control flow, an incoming arrow starts a single step of an activity; after the step is completed, the flow continues along the outgoing arrow.

Figure 2.4 illustrates a simple Activity Diagram (OMG Unified Modelling Language (UML), Version 2.5, 2015) including one initial node, two activity final nodes, 5 opaque action nodes, one merge node, one decision node and one fork node. Interconnections between the nodes are represented by the control flow edges (arcs). The diagram in Figure 2.4 shows a process in which a proposal can have two outcomes, either to be published or rejected. It is seen from the AD that once a

28

proposal is modified (‘Modify Proposal’) and reviewed (‘Review Proposal’) then a decision is made, using the decision node. There are three outgoing edges from the decision node dictating the three following paths for the proposal to: (i) be accepted and published (‘Publish Proposal’); (ii) be rejected without considering publication (‘Notify of Rejection’); and (iii) require further modification and hence a notification for this modification is identified using the ‘Notify of Modification’ opaque action node and concurrently the proposal returns though the merge node to the first opaque action node (‘Modify Proposal’) as seen in the AD for modification.

Figure 2.4 UML Activity Diagram Example (OMG Unified Modelling Language (UML), Version 2.5, 2015)

The diagram in Figure 2.4 shows a process in which a proposal can have two outcomes, either to be published or rejected. It is seen from the AD that once a proposal is modified (‘Modify Proposal’) and reviewed (‘Review Proposal’) then a decision is made, using the decision node. There are three outgoing edges from the decision node dictating the three following paths for the proposal to: (i) be accepted and published (‘Publish Proposal’); (ii) be rejected without considering publication (‘Notify of Rejection’); and (iii) require further modification and hence a notification for this modification is identified using the ‘Notify of Modification’ opaque action node and concurrently the proposal returns though the merge node to the first opaque action node (‘Modify Proposal’) as seen in the AD for modification. The first two paths can terminate the process illustrated in Figure 2.4. In this diagram a loop is identified, once the proposal token returns to the merge and ‘Modify Proposal’ nodes after it has passed from the decision and fork nodes, as seen in Figure 2.4.