1 Introduction
Activity modeling highlights the inputs, outputs, sequences and conditions for coordinating other behaviors of a system. SysML extensions to UML 2.1 activity diagrams are summarized below.
1.1 Control as data
Control is extended by SysML in activity diagrams:
 In UML 2.1 activities, control can only enable actions to start. Whereas in SysML, control can support both enabling and disabling of activities.
A control value is an input or output of a control operator. Control operator transforms its inputs into an output through complex logical operations. This output controls other actions.
1.2 Continuous systems
SysML provides extensions for continuous behaviors; however, these are applicable to any other distributed flow of information and physical items through a system. These extensions are:
Restrictions on the rate of flow of an entity along edges in an activity, or in and out of behavior parameters. SysML allows both continuous and discrete flows of material, energy and information. These two flows are unified under rate of flow, similar to that in traditional mathematical models of continuous change, where the discrete increment of time approaches zero.
Extension of object nodes, including pins, with the option of new values replacing values existing in the object nodes and also discarding values if they do not immediately flow downstream. These extensions help ensure that the most recent information is available to actions. They also help prevent fast or continuously flowing values from accumulating in an object node and also modeling transient values (e.g., electrical signals).
1.3 Probability
SysML assigns probability into activities as follows:
Extension of edges with probabilities that a value leaving a decision node or object node will traverse an edge
Extension of output parameter sets with probabilities that values will be output on a parameter set
1.4 Activities as blocks
In UML 2.1, activities (and all other behaviors) are described as classes and their instances as executions.
In SysML, all behaviors can appear on block definition diagrams and participate in generalization and association relationships. It clarifies the semantics of composition association between activities and its type. It defines consistency rules.
1.5 Timeliness
Simple time model in UML is used to represent timing and duration constraints on actions (denoted as constraint notes in an activity diagram) in an activity diagram.
UML 2 timing diagram can complement SysML behavior diagrams.
More advanced SysML techniques may include constraint blocks to specify resource and related constraints on inputs, outputs, and other system properties.
Diagram Elements
2.1 Control as Data
Table 1: Graphical nodes included inactivity diagrams
Table 3: Other graphical elements includedin activity diagrams
3 UML Extensions
3.1 Diagram Extensions
3.1.1 Activity
Notation
In UML 2.1, all behaviors and activities are classes and their instances are executions of the activity. Classes define the constraints under which the instances must operate.
Creating an instance of an activity causes the activity to execute.
Destroying an instance terminates the corresponding execution and also execution of other activities invoked by the instance at the same time.
Activities as blocks can have associations between each other, such as composition associations. Composition association means that destroying an instance at the whole end destroys instances at the part end.
If an activity invokes other activities, there may be a composition association, with the invoking activity being at the whole end and the invoked activity at the part end. Termination of an activity on the whole end causes end of activities on the part end.
Activitiesin block diagrams appear as regular blocks, as shown in Figure 1. The ,«activity» keyword is used to indicate that the Block Stereotype is applied toan activity.
Figure 1: Blockdefinition diagram with activities as blocks
Constraints
When composition association in block definition diagrams are defined between activities, the following constraint may appear:
The part end name must be the same as the name of a synchronous CallBehaviorAction in the composite activity. If the action has no name, and the invoked activity is only used once in the calling activity, then the end name is the same as the name of the invoked activity.
The part end activity must be the same as the activity invoked by the corresponding CallBehaviorAction.
The lower multiplicity at the part end must be zero.
The upper multiplicity at the part end must be 1 if the corresponding action invokes a nonreentrant behavior.
3.1.2 CallBehaviorAction
Stereotypesapplied to behaviors may appear on the notation for CallBehaviorAction wheninvoking those behaviors (Figure 2).
Figure 2: Cell Behavior Action notation. with behavior stereotype
CellBehaviorActionsin activity diagrams may show the action name with the name of the invokedbehavior using the colon notation (Figure 3).
Figure 3: Cell Behavior Action notation. with action name
3.1.3 Control Flow
Presentation option
Control flow notation includes a dashed line and stickarrowhead (Figure 4).
Figure 4: Control Flow notation
3.1.4 ObjectNode
Notation
Associations can be used between activities and classes that are the type of object nodes in the activity (Figure 5). Thus, the execution of the activity is connected with items that are flowing through the activity and contained by the object node at the time the link exists.
Names of the object node that correspond to the association can be used as end names of the association on the end towards the object node type.
If instances of the classifier flowing the activity are terminated when the activity is terminated, there may occur composite association.
Figure 5: Block definition diagram withactivities as blocks associated with types of object nodes
Object nodes in activity diagrams can sometimes show the node name with the name of the type of the object node (Figure 6a).
Stereotypes applying to parameters can appear on object nodes in activity diagrams (Figure 6b), when the object node notation is used as a shorthand for pins.
Figure 6: ObjectNode notation in activity diagrams
Constraints
When composition association in block definition diagrams are defined between activities and classifiers typing object nodes, the following constraint may appear:
The end name towards the object node must be same as the name of an object node in the activity at
the other end.
The classifier must be the same as the type of the corresponding object node.
The range of multiplicity at the object node type end must be zero to one.
3.2 Stereotypes
Figure 7 gives theabstract syntax for the stereotypes used in this unit.
Figure 7: Abstractsyntax for SysML activity extensions
3.2.1 Continuous
Continuous rate is defined as the rate of flow where increment of time between items approaches zero. It is not dependent on UML streaming. A streaming parameter may or may not result in continuous flows, and a continuous flow may or may not involve streaming parameters.
UML:
Does not restrict the rate at which tokens flow; the time between tokens can approach as near to zero as required
Does not restrict the kinds of values that flow through an activity and the value may be as small a number as needed, e.g., to simulate continuous material or energy flow
Cannot specify the exact timing of token flow.
3.2.2 ControlOperator
Description
Control operator can be defined as a behavior representing an arbitrary complex logical operator that can be used to start or end other activities.
When the «controlOperator» stereotype is applied to behaviors, the behavior considers control as data (i.e., accepts control values as inputs or gives them out as outputs).
Control values enable or disable the control operator execution based on their presence as data, and not
on their value.
Pins for control parameters are regular pins, not UML control pins.
When the «controlOperator» stereotype is not applied, the behavior may not have a ControlValue parameter.
Constraints
If the «controlOperator» stereotype is applied, the behavior must have at least one parameter typed by ControlValue, whereas if the stereotype is not applied, the behavior may not have any parameter typed by ControlValue.
A method behavior must have the «controlOperator» stereotype applied if its operation has the stereotype applied.
3.2.3 Discrete
Description
Discrete rate represents a rate of flow where increment of time between items in not zero.
Constraints
The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.
3.2.4 NoBuffer
Description
When the «nobuffer» stereotype is applied to object nodes, tokens arriving at the node after being refused by outgoing edges, or by actions for object nodes like input pins, are removed. This stereotype is used for fast or continuously flowing data values mainly to prevent buffer overrun. Both «nobuffer» and «overwrite» exert same effect on object nodes that are the target of continuous flows.
When the stereotype is not applied, tokens that are refused by outgoing edges, or action for input pins, arrive at an object node and are held there until they can leave the object node.
Constraints
The «nobuffer» and «overwrite» stereotypes cannot be applied to the same element at the same time.
3.2.5 Overwrite
Description
When the «overwrite» stereotype is applied to object nodes, a token arriving at a full object node (it can have as many tokens as allowed by its upper limits) replaces the existing tokens. This stereotype is used particularly for an input pin with an upper bound of 1. If the upper bound is >1, the token that would be selected last, as per the ordering kind for the node, will be replaced.
A null token removes all the tokens already present. The number of tokens replaced is equal to the weight of the incoming edge (which is equal to 1 by default). Both «overwrite» and «nobuffer» exert same effect on object nodes that are the target of continuous flows.
When the stereotype is not applied, tokens that arrive at object nodes do not replace the existing tokens.
Constraints
The «overwrite» and «nobuffer» stereotypes cannot be applied to the same element at the same time.
3.2.6 Optional
Description
When the «optional» stereotype is applied to parameters, the lower multiplicity must be zero, indicating that the parameter does not require any value to enable or disable any activity/behavior. When the lower multiplicity is required to be >0, it is called “required.” If the stereotype is not applied, the following constraint occurs.
Constraints
A parameter with «optional» stereotypes must have multiplicity. lower equal to zero, otherwise multiplicity. lower must be greater than zero.
3.2.7 Probability
Description
When the «probability» stereotype is applied to edges generated from the decision nodes and object nodes, an expression for the probability that the edge will be traversed is obtained. These must be between zero and one inclusive, and add up to one for edges with same source.
When the «probability» stereotype is applied to output parameter sets, we get the probability that the parameter set will be given values at runtime. These must be between zero and one inclusive, and add up to one for output parameter sets of the same behavior.
Constraints
The «probability» stereotype can be applied only to activity edges coming out of decision nodes or object nodes, or to output parameter sets.
If the «probability» stereotype is applied to an activity edge, it must be applied to all edges produced from the same source.
When the «probability» stereotype is applied to an output parameter set, it must be applied to all the parameter sets of the behavior or operation owning the original parameter set.
If the «probability» stereotype is applied to an output parameter set, all the output parameters must be in some parameter set.
3.2.8 Rate
Description
When the «rate» stereotype is applied to an activity edge, it specifies the expected number of objects and values that traverse the edge per time interval. In other words, this stereotype indicates the expected value rate at which these leave the source node and arrive at the target node, not the rate at which a value changes over time.
If the stereotype is applied to a parameter, the parameter should be streaming. The stereotype gives the number of objects or values flowing in or out of the parameter per time interval when the behavior or operation is carrying out.
Constraints
The parameter to which the «rate» stereotype is applied must be streaming.
The rate of a parameter must be less than or equal to the rates on edges that come into or go out from pins and parameters nodes corresponding to the parameter.
3.3 Model Libraries
Figure8 describes the SysML model library for activities.
Figure 8: Abstract syntax for SysMLactivity extensions
3.3.1 Control Value
Description
The Control Value enumeration can be used asthe type of behavior and operation parameters, object nodes, attributes, etc. for treating controlvalues as data and for UML control pins. The possible runtime values are
givenas enumeration literals. Modelers can extend the enumeration with additionalliterals and their own semantics.
The disable literal indicates terminationof an executing behavior, which can only be started again from
the beginning.The enable literal indicates starting a new execution of a behavior.
Constraints
UML4SysML::Object Node::is ControlType istrue for object nodes with type Control Value.
|
