Tim Weilkiens , in Systems Engineering with SysML/UML, 2007
3.6.5 Initial and Final Nodes
Definition
An initial node is the starting point for a control flow that is started as the activity is invoked.
An activity final node terminates the entire activity as soon as a single flow arrives at the node.
A flow final node terminates the flow in an activity that arrives at this node.
A control token is placed on each initial node, thus starting a flow, as soon as an activity is invoked. An activity can have from none to any number of initial nodes. If there are more than one initial nodes, then there are concurrent flows right at the start of the activity (Figure 3.46). An initial node is denoted as a black filled circle (Figure 3.46).
FIGURE 3-46. Example with two initial nodes.
An activity final node terminates the entire activity as soon as a token hits the node, regardless of how many other tokens (i.e., flows) are still underway in that activity (Figure 3.47). The notation for an activity final node is a black filled circle with an open outer circle. It probably reminds you of a bull's eye from the game of darts.12 It's the target you want to hit. In Figure 3.47, you can see an activity that contains three tokens after it had been invoked. The entire activity is terminated as soon as an activity final node is reached.
In contrast to activity final nodes, a flow final node swallows the token that hits it, while all other tokens in the activity continue rolling. This means that only this one flow is terminated. If it is the only or final flow in the activity, then the entire activity is terminated by the motto "the last one turns the light off."
The notation for a flow final node is a circle with a cross, similar to the lamp symbol used in electrical engineering (Figure 3.48). Note that there is no causal connection.
Michael Jesse Chonoles , in OCUP Certification Guide, 2018
16.1.3 Concurrent (Multi-Token) Diagrams
16.1.3.1 Explicit Token Creation
Single-threaded activities are very limiting; in most real applications, many things can be going on at once. UML supports several ways of creating additional tokens that can independently traverse an activity diagram at the same time.
An explicit way of creating additional tokens is to use the Fork Control node (see Table 16.2 Line 3). When a token comes in at the input edge, it is duplicated as needed to populate the output edges. Downstream this produces concurrent behavior in the paths of the tokens. "Concurrency" is used in UML to mean that the relative order of the behaviors or events is not defined and may overlap.
Table 16.2. Activity Diagram Basics: Actions and Control Nodes
General Type
Symbol
Name(s)
Description
1
Executable node
All these Executable Nodes below (the actions) start when all input edges are sufficiently populated
2
Executable node
Action
When the action finishes, all the output edges are populated
Roundangle
3
Control node
Fork
The input flow and its token are copied and emitted on each of the outgoing edges
This copies the tokens and increases the number of tokens in the diagram, enabling concurrent processing
4
Control node
Join
When all the input flows (along with their tokens) arrive at the Join, an output flow is emitted (with its token) on the output edge
This eliminates all but one of the tokens arriving
If not all of the edges have tokens, processing cannot continue and hangs at the Join
5
Control node
Flow Final
Any token reaching the Flow Final is destroyed (i.e., consumed); however, if there are more active tokens in the diagram, execution is continued until they are also consumed
In Fig. 16.8, we depict an example of explicit token creation using the Fork control node. An identical token is then sent to each of the A1.a and A1.b behaviors. We have no idea which behavior starts first. We say that the two behaviors start concurrently. Also, we have no idea which behavior ends first. All behaviors stop when the first token reaches an Activity Final Node.
Figure 16.8. Explicit token creation via fork node inducing concurrency.
In Fig. 16.9, we see a diagram that is equivalent to Fig. 16.8. Every Initial Node in an activity diagram causes new tokens to be emitted on its outgoing edges when the diagram starts. All these tokens are created concurrently. When the behaviors finish, control is passed to the Activity Final Node. The diagram is finished as soon as a first token reaches the Activity Final Node.
Figure 16.9. Explicit token creation via initial nodes inducing concurrency.
16.1.3.2 Implicit Token Creation: Forking a New Path
Control Tokens can be created whenever a fork occurs, not just the explicit ones caused by UML fork node or caused by additional initial nodes. Any activity diagram executable node that has more than one control flow leaving it, when it finishes, will place concurrent control tokens on the output edges (see Fig. 16.10). In this case, Action A has two control flow outputs and thus, both B1.a and B1.b start concurrently when A finishes. The diagram ends whenever either B1.a or B1.b finishes, causing a token to reach the Activity Final Node, which ends the diagram.
Figure 16.10. Forking without the fork node.
16.1.3.3 Multiple Forks
Though all of the above examples show a token forking into two tasks, UML allows for more flexible forking. In Fig. 16.11, we see a fork that produces from 3 to 5 possible tasks. The first two possible tasks are guarded and will only be created if the governing guards are true.
Figure 16.11. Multiple forks with some guarded.
16.1.3.4 Forking vs Spawning
You may read that the UML Fork node spawns a new task or something like that. We typically do not use the "spawn" terminology, as it usually implies a hierarchical relationship between the associated tasks7. "Forking" is more appropriate as each token/task is independent. When a fork occurs, it is not that a new subordinate token is created. A fork is a clone of a task, while spawn could be considered as a child. Generally, this distinction is not important, though it may help in understanding what is going on.
Michael Jesse Chonoles , in OCUP Certification Guide, 2018
1.
Which symbol is used to start a UML 2.5 Activity Diagram?
A.
a
B.
b
C.
c
D.
d
E.
e
F.
f
2.
Which action is guaranteed to be the last one to finish executing?
A.
X1
B.
X2
C.
X3
D.
X4
E.
X5
F.
There is no guaranteed "last" step to execute as the order is unpredictable
3.
Which actions will never start?
A.
None of the actions will start
B.
Action1, Action2, and Action3
C.
Action2 and Action3
D.
Action0 and Action1
E.
Action1
F.
All actions start
4.
Many of the Activity Diagram nodes or actions have matching inverses; e.g., we can match an Initial Node with an Activity Final Node. Which choice below does not have such an inverse?
A.
Fork Node
B.
Decision Node
C.
Join Node
D.
Send Signal Action
E.
Wait Time Action
5.
Which of the symbols below indicates a type of action?
A.
B.
C.
D.
E.
6.
An Activity has an Activity Final Node, with more than one incoming edge. When does the Activity finish?
A.
The Activity finishes when all the incoming edges have supplied at least one token.
B.
The Activity finishes when at least one incoming edge has supplied one token.
C.
The Activity finishes when the majority of incoming edges have supplied at least one token.
D.
The Activity finishes when at least one incoming edge has supplied one token and no token is moving in other parts of the diagram.
E.
The Activity finishes when at least one incoming edge reaches a Flow Final Node, not an Activity Final Node.
7.
Which of following Nodes may not be part of an Activity Diagram?
A.
Activity Parameter Node
B.
Control Node
C.
Executable Node
D.
Object Node
E.
Sentinel Node
8.
Examine the Activity Diagram fragment below. What sequence of behavior completions is not legal?
A.
A1, A2
B.
A1, A3, A2
C.
A1, A3, A4, A2
D.
A1, A2, A3, A4
E.
The diagram is missing a join node and cannot finish.
9.
Which action might never start?
A.
X1
B.
X2
C.
X3
D.
X4
E.
X5
10.
Which symbol, if reached, always indicates the end of execution of an Activity Diagram?
A.
a
B.
b
C.
c
D.
d
E.
e
F.
f
11.
What statement is true about the diagram Exercise1 below?
A.
It is an invalid diagram as it has multiple Initial Nodes.
B.
It is an invalid diagram as it has multiple Activity Final Nodes.
C.
It is an invalid diagram as it has two Actions with the same name.
D.
It is a valid diagram.
12.
The Chess game starts when two Players and the Referee shows up. Which diagram reflects that situation?
A.
B.
C.
D.
13.
On an Activity Diagram, a diamond-shaped symbol appears. It has one edge going in and three edges leaving. What can we say about this symbol?
A.
It is a decision node with a three-way decision.
B.
It is a decision node with a four-way decision.
C.
It is a merge node with a three-way decision.
D.
It is a merge node, which merges three paths.
E.
It is a fork node, which forks to three paths.
14.
When discussing an Activity Diagram, what is a token?
A.
A token is used to get you on a subway in some
cities.
B.
A token is a small symbol that looks like a ball with an arrowhead.
C.
A token represents an object or focus of control that traverses Activity Diagram edges or resides at a node.
D.
A token represents a guard condition on an Activity Diagram.
15.
Which diagram fragment conveys the modeler's intent correctly?
A.
B.
C.
D.
16.
Which of the following potential Activity Diagram model elements do not belong?
Raul Sidnei Wazlawick , in Object-Oriented Analysis and Design for Information Systems, 2014
2.4.1 Basic elements
Much of the UML activity diagram is similar to a flowchart. There are activities sequentially linked. Decision points and loops may be used and even parallelism may be expressed in such diagrams.
The activity diagram may be divided into swim lanes, each one representing an actor or worker that participates at a set of activities. As in the use case diagram, an actor or worker may be a person, a department, a computational system, or even a complete organization.
The process represented in the diagram usually has an initial node, represented by a solid circle
, and an activity final node, represented by a solid circle inscribed in a circumference . The initial node may not be considered mandatory in some cases when the beginning of the process can be inferred by observing an activity that does not have an antecessor. However, the use of that mark improves the readability of the diagram because it is easier to see where the process really begins.
The activities are represented by action nodes
. When an activity is represented inside a swim lane it means that the corresponding actor is the one responsible for the activity.
Flows or dependencies between activities are represented by arrows →. Flows usually link two activities, indicating precedence between them.
A path is a sequence of activities linked by flows:
→→→→.
In the Livir example, the activity diagram may be used as a way to visualize the details of business use cases such as Sell books. The model presented in Figure 2.8 shows a first approach to the process.
Figure 2.8. First approach to an activity diagram for modeling the book sales business process.
The diagram that is starting to be designed in Figure 2.8 is not intended to be a model for the system to be built and should not be thought of like that. Its utility is to help the team understand which activities and actors are involved with the main business processes of the company, so that, using that information, they can perform a more effective requirements analysis later. The logical path of the diagram must be understandable and validated by business people.
Later, the analyst will examine in detail each of the activities that must be performed. If a given activity belongs to the scope of the system that is going to be implemented, then it must be a target for a more detailed analysis.
Terry Halpin , Tony Morgan , in Information Modeling and Relational Databases (Second Edition), 2008
Activity Diagrams
Activity diagrams are mainly focused on the flow of control within a set of related activities. The level of granularity is not defined by UML, so the scope of each individual activity is at the discretion of the modeler. This has the advantage that activity diagrams can be used for both high level and low level descriptions, but places the onus of defining activity boundaries onto some other authority. Activities are considered to be composed of atomic actions. Activities can be interrupted, but actions cannot, which implies that any interruption to an activity must take place on a boundary between actions. We have already seen flow-of-control chaining of activities earlier in this chapter, and it's not surprising that UML activity diagrams are seen as a candidate notation for documenting business processes. The underlying semantics of activity diagrams changed between UML versions 1 and 2. In UML 1, activity diagrams were seen as a special kind of state machine description and shared a great deal of terminology with UML statecharts. In UML 2, the semantics of activity diagrams became realigned to be closer to the semantics of Petri nets.
An activity diagram consists of a number of nodes connected by arrowed lines (directed edges). There are three main types of node: action nodes, object nodes, and control nodes. Action nodes represent some work being carried out and are shown as a rectangle with rounded corners. The rectangle typically contains the name of the action: other information may optionally be added that we won't consider here. Object nodes, shown as rectangles with square corners, represent an object type, for example, a business entity such as an invoice that may be passed from one activity to another. Object nodes are generally only shown when some special consideration needs to be given to the objects being passed: routine use of business objects by activities is just assumed. The "flow" along the activity edges is either of control tokens, indicating the transfer of control from one activity to another, or of objects. Since the edges are directed, there is no assumed direction of flow, although diagrams are conventionally laid out so that the main flows are either left to right or top to bottom.
Control nodes are abstract activity nodes that coordinate flows in an activity diagram and come in various subtypes. An initial node is represented by a filled circle and represents a starting point for the activity diagram. There can be more than one initial node. There are two kinds of final node. An activity final node is shown as a target symbol, and an activity diagram can have more than one of these. As soon as an activity final node receives a token, the entire activity immediately terminates even if there are other control tokens active in other paths. A flow final node, shown as an "X" in a circle, destroys any token that reaches it, without affecting any other concurrent flows.
A decision node, denoted by a diamond shape, has one input edge and one or more output edges. A token arriving on the input edge will leave on only one of the output edges (i.e., exclusive-or). To control this, the output edges have guard conditions, denoted inside square brackets. The guard conditions should be complete and disjoint to ensure that token flow is not inadvertently halted or duplicated. A default branch can be provided by specifying it with the guard condition [else].
The diamond shape used for a decision node is also used for a merge node. This performs the complementary action to a decision node by bringing together multiple alternate flows on its input edges. Any token arriving on an input edge is offered to the output edge. There is no synchronization of tokens arriving on the incoming edges.
A fork node splits a flow into multiple concurrent flows. It is shown as a solid bar with one input edge and two or more output edges. Each token arriving on the input edge is duplicated and offered to each output edge. There is no sequencing implied between the outgoing flows.
A join node is used to combine parallel flow paths. The join notation is the same as for a fork, except that the join has multiple input edges and one output edge. An optional join expression determines how incoming tokens are combined to produce an output token. The default is "and", implying that the join waits for a token to arrive on each incoming edge before producing a token on the output edge (i.e., synchronization).
The UML 2 specification does not require that branches introduced in the diagram should be balanced. In other words, multiple paths introduced by decisions or forks do not necessarily have to be recombined by the complementary merges or joins. Although this provides maximum flexibility in defining a process, it can also provide subtle traps for the unwary and can lead to unsound process definitions.
Figure 15.35 shows an example activity diagram for a simple sales process. The diagram is based on an example given in the UML specification, modified slightly to contain examples of the features we discuss. Although the modified diagram is still syntactically legal, it represents an unsafe process design, as we will see shortly. The diagram is self-explanatory, but not unique, in the sense that the same process could have been depicted in a number of slightly different ways.
Figure 15.35. An activity diagram for a simple sales process.
For example, the join and the fork that immediately follow it could have been combined into a join/fork construct that would have appeared as a thick bar with two edges entering and two edges leaving. Combining a join and a fork in this way can make diagrams slightly tidier, but has no effect on the semantics.
The execution of the process can be simulated by tracing the flow of a token in a particular instance of the process represented by the diagram. The token originates at the initial node. A customer places an order, which is received by the company's sales department. The first decision is to either accept or reject the order. The two guard conditions, [rejected] and [accepted], are mutually exclusive. If the token takes the [rejected] branch, it immediately reaches the merge and appears on its output edge. After the order is closed, the token reaches the activity final node, which immediately ends the process instance. If the token takes the [accepted] branch, the order is filled. When the token reaches the fork, two tokens are generated. The upper token causes the order to be shipped, and the lower token stimulates a series of actions to invoice the customer and eventually receive payment.
The upper and lower branches have no implied timing constraints: either of them could be the first to complete. The following join waits for a token to arrive on both branches before emitting its own single token. This immediately forks into two other branches. The token on the upper branch reaches the merge that we have already discussed and causes the order to be closed. The token on the lower branch reaches a decision. If the customer is a new customer, then they are added to the customer database, but for an existing customer the token is immediately consumed by the flow final node.
The second fork in the diagram is not balanced (there is no corresponding join), but we eliminate the token in the lower branch because it eventually reaches a flow final node. This ensures that adding the customer to the database does not interfere with the closing of the order. However, the design is unsound because the lower branch is in a race with the upper branch. Once the order is closed, a token will reach the activity final node and immediately terminate the process, regardless of the status of the token in the other branch. This could result in a new customer not being added to the database, contradicting the process designer's original intentions.
One other feature of activity diagrams is support for swimlanes. These are optional, but can be used to indicate features such as separation of responsibilities, usage of resources, geographical distribution, and so on. As with other features, the precise meaning of a swimlane is not defined in UML: the interpretation is left up to the user of the activity diagram. Figure 15.36 shows the process model of Figure 15.35 with swimlanes added. In Figure 15.36 the swimlanes are drawn to indicate who carries out the actions (customer or sales clerk). The invoice object is used by both, and so is shown on a swimlane boundary. Multiple orthogonal swimlanes can be defined: for example, one axis could represent organizational units and the other could represent resource types. The result resembles a kind of Venn diagram with the actions placed in whichever swimlane intersection is appropriate. However, this quickly gets difficult to draw and can be confusing to read.
Figure 15.36. An activity diagram with swimlanes.
Activity diagrams also provide for the hierarchical composition/decomposition of actions. A structured activity of this kind can be treated at one level as a single action, but can be expanded if required to show the breakdown into its subordinate activities. Activities can be nested in this way to any level that's useful.
Activity diagrams have a number of other features that we haven't space to discuss here. Examples include signaling between system elements, events used to trigger activities, the definition of interrupts and interruptible regions of activity, and so on. Many of these features can be useful in the definition of software, but are less relevant for conceptual modeling.
Sanford Friedenthal , ... Rick Steiner , in A Practical Guide to SysML (Third Edition), 2015
9.6 Using Control Flows to Specify the Order of Action Execution
As mentioned previously, there are control semantics associated with object flow, such as when an action waits for the minimum required number of tokens on all input pins before proceeding with its execution. However, sometimes the availability of object tokens on required pins is not enough to specify all the execution constraints on an action. In this case control flows are available to provide further control using control tokens. Although object flows have been described first in this chapter, the design of an activity need not necessarily start with the specification of object flows. In traditional flow charts, it is often the control flows that are established first and the routing of objects later.
In addition to any execution prerequisites established by required input pins, an action also cannot start execution until it receives a control token on all input control flows. When an action has completed its execution, it places control tokens on all outgoing control flows. The sequencing of actions can thus be controlled by the flow of control tokens between actions using control flows.
An action can have more than one control flow input. This has the same semantics as connecting the multiple incoming control flows to a join node, and connecting the output control flow from the join node to the action. Similarly, if an action has more than one control flow output, it can be modeled by connecting the action via an outgoing control flow to a fork node with multiple control flow outputs. As described in Section 9.6.2, control tokens can be used to disable actions as well as enabling them.
9.6.1 Depicting Control Logic with Control Nodes
All the constructs used to route object flows can also be used to route control flows. In addition, a join node has special semantics with respect to control tokens; even if it consumes multiple control tokens, it emits only one control token once its join specification is satisfied. Join nodes can also consume a mixture of control and object tokens, in which case once all the required tokens have been offered to the join node, all the object tokens (but none of the control tokens) are offered on the outgoing flow.
In addition to the constructs described in Section 9.5.1, there are some special constructs that provide additional control logic:
•
Initial node—when an activity starts executing, a control token is placed on each initial node in the activity. The token can then trigger the execution of an action via an outgoing control flow. Note that although an initial node can have multiple outgoing flows, a control token will only be placed on one. Typically, guards are used when there are multiple flows in order to ensure that only one is valid, but if this is not the case, then the choice of flow is arbitrary.
•
Activity final node—when a control or object token reaches an activity final node during the execution of an activity, the activity execution terminates.
•
Flow final node—control or object tokens received at a flow final node are consumed but have no effect on the execution of the enclosing activity. Typically they are used to terminate a particular sequence of actions without terminating an activity. An example of when a flow final node is used is when a fork node has two output flows to two concurrent actions. If one of the action terminates but the other continues as part of a processing chain, a flow final node can be used to indicate that one action has completed its execution without terminating the activity.
A control flow can be represented either by using a solid line with an arrowhead at the destination end like an object flow or, to more clearly distinguish it from object flow, by using a dashed line with an arrowhead at the destination end. An initial node symbol is shown as a small solid black circle. The activity final node symbol is shown as a bulls-eye, Examples of the initial and activity final nodes are shown in Figure 9.12.
The flow final node symbol is a hollow circle containing an X. Figure 9.21 contains an example of a flow final node.
The console software provides the capability to drive a camera through a preset scan route, as shown in Figure 9.12. The activity Follow Scan Route will follow a route that is a set of positions for the camera defined in terms of pan-and-tilt angles. It has one input parameter, the route as a fixed-length collection of positions with size route size. When started, the activity resets its count property, then iterates over all points in the route—incrementing count for every point. It terminates when the return value of the associated decision input behavior evaluates to false (and thus satisfies the [false] rather than the [true] guard) indicating that the last point in the route is reached. The decision input condition is an opaque expression written in Alf (see Section 9.14.2 for a description of the Alf programming language). As with constraints, the language used to specify the action can be added in braces before the expression. The Position Camera activity is invoked for each position token offered on the route parameter. Control flows dictate the order in which the activity executes.
FIGURE 9.12. Control flow in activities.
Note that in this case there is a combined merge and decision symbol that accepts two input control flows and has two output control flows: one leads to an activity final node and the other leads into another iteration of the algorithm. The activity's count property is initialized and incremented using actions this.count=0; and this.count=this.count+1; these are opaque actions; that is, their function is expressed in some language external to SysML (in this case Alf).
9.6.2 Using Control Operators to Enable and Disable Actions
An action with nonstreaming inputs and outputs typically starts once it has the prerequisite incoming tokens and terminates execution when it completes the production of its outputs. However, the completion of the action execution may need to be controlled by a control input, particularly if the action is a call action with streaming inputs and/or outputs. To achieve this, a value can be sent via a control flow to the action to enable or disable its invoked activity. SysML provides a specific control enumeration for this called ControlValue, with values enable and disable. For an action to receive this control input, it needs to provide a control pin that can receive it. A control value of enable has the same semantics as the arrival of a control token, and a control value of disable will terminate the invoked activity.
A special behavior called a control operator produces control values via an output parameter, typed by ControlValue. A control operator can include complex control logic and can be reused in many different activities via a call behavior action. A control operator is also able to accept a control value on an appropriately typed input parameter and will treat it as an object token rather than a control token.
The control value type could be extended in a profile (see Chapter 15) to include other control values in addition to enable and disable. A control operator could then output these new values. A control value of suspend, for example, might not terminate execution of the action like disable. The action would allow execution to resume where it left off when it received a resume control value.
The definition of a control operator is indicated by the presence of the keyword «controlOperator» as the model element kind in the diagram label on the activity diagram frame.
Figure 9.13 shows a simple control operator, called Convert Bool to Control, that takes in a Boolean parameter called bool in and, depending on its value, either outputs an enable or disable value on its control out output parameter. The values are created using primitive actions, called value specification actions, whose purpose is to output a specified value. By convention, the input and output pins of these actions are elided. (See Section 9.14.3 for a discussion of primitive actions.) Convert Bool to Control is a generally useful control operator that can be reused in many applications.
FIGURE 9.13. Using a control operator to generate a control value.
A control operator is a kind of behavior and so may be invoked using a normal call behavior action. A call behavior action that invokes a control operator has the keyword «controlOperator» above its name string. A control pin symbol is a standard pin symbol with the addition of the property name control in braces floating near the pin symbol.
A test signal is not always wanted on the video output. A mechanism to inhibit test signal production is shown in Figure 9.14. The Convert Bool to Control control operator shown in Figure 9.13 reads a Boolean flag test value from the activity Receive Test Messages to generate an enable or disable value on a pin called control out. This pin in turn is connected via a control flow to the inhibit pin of the Generate Test Signal activity. Generate Test Signal interprets this input as a control value because inhibit is a control pin, as indicated by the annotation {control}. When Generate Test Signal is enabled, it reads the time at 2 Hz from an accept time event action (see Section 9.7 for a discussion of time events). The activity Receive Test Messages is defined in Figure 9.24.
FIGURE 9.14. Using a control operator to control the execution of an activity.
Sanford Friedenthal , ... Rick Steiner , in Practical Guide to SysML, 2008
Activities as Methods
When used as a method, an activity needs to have the same signature (i.e., same parameter names, types, multiplicities, and directions) as the associated service definition, called in SysML a behavioral feature. There are two types of behavioral feature. An operation supports synchronous requests (i.e., the requester waits for a response) and asynchronous requests (i.e., the requester does not wait for a response). A reception only supports asynchronous requests. A reception indicates that the object can receive signals of a particular kind, as the result of a send signal action (see Section 8.7). A method is invoked when the owning block instance (object) consumes a request for its associated behavioral feature. The activity executes until it reaches an activity final node, when the service is deemed to be handled, and if the request is synchronous, any output arguments are passed back to the initiator of the request.
SysML has a specific action to invoke methods via operations, called a call operation action. This has pins matching the parameters of the operation, and one additional input pin used to represent the target. When the action is executed, it sends a request to the target object that handles the request by invoking the method for the feature, passing it the input arguments, and passing back any output arguments.
If an activity invoked as the result of a call operation action has streaming parameters, then the pins of the call operation action may consume and produce tokens during execution of the activity. However, in a typical client/server approach to system design, all parameters are nonstreaming to fit more easily into a client/server paradigm.
Figure 8.24 shows the Surveillance System block with one of its ports, called status. The status port provides an interface Camera Status that includes an operation called get camera status as shown, with an input parameter called camera id and an output parameter called camera status. The activity Handle Status Request, shown originally in Figure 8.10, is designated to be the method of get camera status, so it has the same parameters. A call operation action for get camera status will result in the invocation of Handle Status Request with an argument for camera id, and it will expect a response on camera status. A call operation action for get camera status is shown, with pins corresponding to the two parameters and also a pin to identify the target; that is, the Surveillance System to which the request must be sent.
Figure 8.24. A block with behavioral features and associated methods.
Sanford Friedenthal , ... Rick Steiner , in A Practical Guide to SysML (Third Edition), 2015
3.3.2 SysML-Lite Air Compressor Example
The following is an example of using SysML-Lite to model an air compressor that is used to power a pneumatic tool. This model is highly simplified for the purposes of illustration and includes the same kind of diagrams that were shown in Figure 3.3.
Figure 3.4 shows the package diagram for the Air Compressor Model and includes packages for Requirements, Behavior, Structure, and Parametrics. This model organization follows a similar pattern as described in the section on SysML-Lite above and shown in Figure 3.3.
FIGURE 3.4. This package diagram is used to organize the Air Compressor Model into packages for Requirements, Structure, Behavior, and Parametrics. Each package contains model elements that can be related to model elements in other packages.
The Requirements package contains a set of requirements that would generally be found in a system specification for the air compressor. The requirements are captured in the requirement diagram in Figure 3.5. The top level requirement called Air Compressor Specification contains a functional requirement to compress air, performance requirements that specify the maximum pressure and maximum flow rate, a requirement to specify storage capacity, power requirements to specify the source power needed to compress the air, and reliability and portability requirements. The text for the Storage Capacity requirement appears in the diagram, whereas the text for the other requirements is not displayed to reduce the clutter.
FIGURE 3.5. This requirement diagram presents the requirements contained in the Requirements package to specify the Air Compressor. Each requirement can include the requirements text that is typically found in a specification document.
The Behavior package contains an activity diagram, shown in Figure 3.6, called Operate Air Tool, that specifies how the Air Compressor interacts with the external systems, including the Air Tool, the Atmosphere, and indirectly with the Operator. The Air Compressor and the external systems are shown as activity partitions. The Air Compressor performs the function (i.e., action) called Compress Air, which has a low pressure air input and a high pressure air output. The activity begins at the initial node (i.e., dark-filled circle), and then the Operator executes the Control Tool action. The activity completes its execution at the activity final node (i.e., bulls-eye symbol), after the Operator completes the Control Tool action. The Compress Air action is further decomposed in Figure 3.9.
FIGURE 3.6. This activity diagram specifies the interaction between the Air Compressor, Operator, Air Tool, and Atmosphere to perform the Operate Air Tool activity.
The Structure package contains the blocks presented in the block definition diagrams in Figure 3.7 and Figure 3.8. The block definition diagram in Figure 3.7 called Air Compressor Top Level includes a block called the Air Compressor Context that is composed of the Air Compressor and the entities that are external to the Air Compressor representing the user, external system, and the physical environment. In this example, the user is the Operator, the external system is the Air Tool, and physical environment is the Atmosphere. The block definition diagram in Figure 3.8 is called Air Compressor System Hierarchy. The Air Compressor block in this figure is the same block that is shown in Figure 3.7, but this figure shows that the Air Compressor block is composed of components that include the Motor Controller, Motor, Pump, and Tank. The Air Compressor, Motor, Tank, and Pump all include value properties that are used to analyze the flow rate requirements.
FIGURE 3.7. This block definition diagram shows the Air Compressor, Operator, Air Tool, and Atmosphere as blocks. The Air Compressor Context block provides the context for the Air Compressor.
FIGURE 3.8. This block definition diagram shows the Air Compressor and its components. The Air Compressor block is the same block that is shown in Figure 3.7.
The activity diagram in Figure 3.9 decomposes the action called Compress Air from Figure 3.6 to specify how the components of the Air Compressor interact to compress the air. The activity partitions in this activity diagram correspond to the components of the air compressor. The Motor Controller performs actions to Sense Pressure and Control Motor. The Motor performs the action to Generate Torque, the Pump performs the action to Pump Air, and the Tank performs the action to Store Air. The low pressure air input and high pressure air output are consistent with the input and output of the Compress Air action in Figure 3.6. This activity is contained in the Behavior package along with the Operate Air Tool activity in Figure 3.6.
FIGURE 3.9. This activity diagram shows how the components of the Air Compressor interact to perform the Compress Air action from Figure 3.6.
The internal block diagram named Interconnection in Figure 3.10 shows how the components of the Air Compressor from Figure 3.8 are interconnected. The diagram frame corresponds to the Air Compressor block and the ports on the diagram frame depict the external interfaces of the Air Compressor. The ports on the parts represent the component interfaces, and the connectors connect the ports to one another. The component parts shown on the internal block diagram are contained in the Structure package along with the blocks on the block definition diagram.
FIGURE 3.10. This internal block diagram shows how the components of the Air Compressor are interconnected via their ports, which specify the component interfaces.
The block definition diagram called Analysis Context in Figure 3.11 is used to define the context for performing the flow rate analysis. In particular, it includes a block called Flow Rate Analysis to represent the analysis. This block is composed of a constraint block called Flow Rate Equations, which contains the equations used to analyze flow rate. In this particular example, only the parameters of the flow rate equations are shown, and not the equations. The Flow Rate Analysis block also refers to the Air Compressor Context block from Figure 3.7, which is the subject of the analysis.
FIGURE 3.11. This block definition diagram is used to specify the Flow Rate Analysis in terms of a constraint block that defines the equations and parameters for the analysis (equations not shown), and the Air Compressor Context, which is the subject of the analysis.
Defining the Analysis Context enables a parametric diagram to be created for the Flow Rate Analysis block as shown in Figure 3.12. The diagram shows the value properties of the Air Compressor and its parts, including flow rate, tank volume and pressure, motor horsepower, and pump efficiency, and the binding of these properties to the parameters of the Flow Rate Equations. The flow rate analysis equations can be solved by an analysis tool to determine the property values for the Air Compressor and its parts. The analysis context pattern is described further in Chapter 8, Section 8.10 and Chapter 17, Section 17.3.6.
FIGURE 3.12. This parametric diagram shows the Flow Rate Analysis and how the parameters of the equations are bound to the properties of the design. Once captured, this analysis can be provided to an analysis tool to perform the analysis. The equations are not shown in the figure.
This air compressor example illustrates how a system can be modeled with a subset of SysML diagrams and language features called SysML-Lite. Even a simple model such as this can contain many model elements and quickly become difficult to manage. A modeling tool is needed to efficiently build a model that is self consistent and to manage complexity. The following section describes how a typical SysML modeling tool is used to build this model.
