Icon class icon_class far fa-file-alt icon_class_computed far fa-file-alt Keywords UML Unified Modeling Language UML-2.5.1 Specification keywords UML-2.5.1 Copyright information About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes Snippets (quotes/extracts) NOTE. Operation referenced in the CallEvent of an AcceptCallAction should not have an associated method Behavior. Otherwise, a call to the Operation will have the immediate effect of executing the method and will not be placed into the event pool ... If an AcceptEventAction is used in an Activity, there are special rules for when it is enabled .. If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution. However, in addition, an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence. That is, it does not terminate after accepting an Event occurrence and outputting any values (as described above), but continues to wait for another Event occurrence. Such an AcceptEventAction is terminated when its immediately containing Activity (or StructuredActivityNode) is terminated. If the triggers of an AcceptEventAction are all for ChangeEvents and/or CallEvents, then the AcceptEventAction has no result OutputPins (unless the AcceptEventAction is an AcceptCallAction ...) Features represent structural and behavioral characteristics of Classifiers. DataTypes model Types whose instances are distinguished only by their value A provided Interface may be shown using the lollipop notation ... attached to the Port. A required Interface may be shown by the socket notation attached to the Port. Receptions are shown in the receptions compartment using the same notation as for Operations with the keyword «signal». Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices. However, whereas encapsulated composite States and their internals are contained within the StateMachine in which they are defined, submachines are, like programming language macros, distinct Behavior specification ... Consequently, they require a more complex binding. This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which represent references to corresponding submachine StateMachines. The concept of ConnectionPointReference is provided to support binding between the submachine State and the referenced StateMachine. A ConnectionPointReference represents a point on the submachine State at which a Transition either terminates or originates. That is, they serve as targets for incoming Transitions to submachine States, as well as sources for outgoing Transitions ... Each ConnectionPointReference is matched by a corresponding entry or exit point in the referenced submachine StateMachine. This provides the necessary binding mechanism between the submachine invocation and its specification. A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. It is, therefore, semantically equivalent to a composite State. The Regions of the submachine StateMachine are the Regions of the composite State. The entry, exit, and effect Behaviors and internal Transitions are defined as contained in the submachine State. NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine. A submachine StateMachine can be entered via its default (initial) Pseudostate or via any of its entry points (i.e., it may imply entering a non-orthogonal or an orthogonal composite State with Regions). Entering via the initial Pseudostate ... An entry point is equivalent to a junction Pseudostate (fork in cases where the composite State is orthogonal): Entering via an entry point implies that the entry Behavior of the composite state is executed, followed by the Transition from the entry ... Any guards associated with these entry point Transitions must evaluate to true in order for the specification to be well formed. a submachine Statemachine can be exited as a result of: reaching its FinalState; triggering of a group Transition originating from a submachine State, or; via any of its exit points. Exiting via a FinalState or by a group Transition has the same meaning as for ordinary composite States. 14.2.3.5 ConnectionPointReference ... a connection point reference represents a usage (as part of a submachine State) of an entry/exit point defined in the StateMachine referenced by the submachine State. Connection point references of a submachine State can be used as sources/targets of Transitions. They represent entries into or exits out of the submachine StateMachine referenced by the submachine State. Connection point references are sources/targets of Transitions implying exits out of/entries into the submachine StateMachine referenced by a submachine State. An entry point connection point reference as the target of a Transition implies that the target of the Transition is the entryPoint Pseudostate as defined in the submachine of the submachine State. As a result, the Regions of the submachine ... An exit point connection point reference as the source of a Transition implies that the source of the Transition is the exit point Pseudostate as defined in the submachine of the submachine State that has the exit point connection point defined. When a Region of the submachine StateMachine reaches the corresponding exit point, the submachine state is exited via this exit point. 14.2.3.6 FinalState: FinalState is a special kind of State signifying that the enclosing Region has completed. Thus, a Transition to a FinalState represents the completion of the behaviors of the Region containing the FinalState. initial - An initial Pseudostate represents a starting point for a Region; that is, it is the point from which execution of its contained behavior commences when the Region is entered via default activation. initial - ... It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard. There can be at most one initial Vertex in a Region. join – This type of Pseudostate serves as a common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions. Transitions terminating on a join Pseudostate cannot have a guard or a trigger. Similar to junction points in Petri nets, join Pseudostates perform a synchronization function, whereby all incoming Transitions have to complete before execution can continue through an outgoing Transition. fork – fork Pseudostates serve to split an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State. The Transitions outgoing from a fork Pseudostate cannot have a guard or a trigger. An InitialNode is a ControlNode that acts as a starting point for executing an Activity. An Activity may have more than one InitialNode. If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode. (Additional concurrent flows may begin at input ActivityParameterNodes and enabled ExecutableNodes ... junction – This type of Pseudostate is used to connect multiple Transitions into compound paths between States. For example, a junction Pseudostate can be used to merge multiple incoming Transitions into a single outgoing Transition representing a shared continuation path. .. a junction Pseudostate ... can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints. NOTE. Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch. junction – ...It may happen that, for a particular compound transition, the configuration of Transition paths and guard values is such that the compound transition is prevented from reaching a valid state configuration. In those cases, the entire ... (As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition. This Transition is enabled if all the guards attached to the other Transitions evaluate to false). choice – This type of Pseudostate is similar to a junction Pseudostate ... and serves similar purposes, with the difference that the guard Constraints on all outgoing Transitions are evaluated dynamically ... Consequently, choice is used to realize a dynamic conditional branch. It allows splitting of compound transitions into multiple alternative paths such that the decision on which path to take may depend on the results of Behavior executions performed ... choice – ... If more than one guard evaluates to true, one of the corresponding Transitions is selected. The algorithm for making this selection is not defined. choice – ... If none of the guards evaluates to true, then the model is considered ill formed. To avoid this, it is recommended to define one outgoing Transition with the predefined “else” guard for every choice Pseudostate. entryPoint – An entryPoint Pseudostate represents an entry point for a StateMachine or a composite State that provides encapsulation of the insides of the State or StateMachine. In each Region of the StateMachine or composite State owning the entryPoint, there is at most a single Transition from the entry point to a Vertex within that Region. entryPoint – ... NOTE. If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. entryPoint – ... NOTE. ... If multiple Regions are involved, the entry point acts as a fork Pseudostate. exitPoint – An exitPoint Pseudostate is an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or StateMachine. Transitions terminating on an exit point within any Region of the composite State or a StateMachine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior). exitPoint – ... If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Pseudostate. junction – ... If more than one guard evaluates to true, one of these is chosen. The algorithm for making this selection is not defined. deepHistory – This type of Pseudostate is a kind of variable that represents the most recent active state configuration of its owning Region. ... a Transition terminating on this Pseudostate implies restoring the Region to that same state ... deepHistory – ... The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State A deepHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State. shallowHistory – ... this type of Pseudostate is a kind of variable that represents the most recent active substate of its containing Region, but not the substates of that substate. A Transition terminating on this Pseudostate implies rest shallowHistory – ... A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State. This substate is the default shallow history state of the composite State. shallowHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State. terminate – Entering a terminate Pseudostate implies that the execution of the StateMachine is terminated immediately. The StateMachine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are ... aborted 16.8.3.3 Add Structural Feature Value Actions: An AddStructuralFeatureValueAction is a StructuralFeatureAction for adding a value to a StructuralFeature of an object. The value to be added is given on the value InputPin, which is required. This InputPin has the same type as the StructuralFeature and a multiplicity of 1..1 (that is, a single value is added). If the StructuralFeature is an Association end, the semantics are the same as for a CreateLinkAction ..., where the participants in the link are the object being acted on and the new value. If isReplaceAll is true, then the existing values of the StructuralFeature are removed before the new value is added, except if the StructuralFeature already contains the new value, in which case it is not removed under this option. If isReplaceAll is true ... The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1. If isReplaceAll is false and the StructuralFeature is unordered and unique, then adding a value that is already contained in the StructuralFeature has no effect. Adding a value to an ordered StructuralFeature requires an insertion point for the new value given in the insertAt InputPin, which is required for ordered StructuralFeatures when isReplaceAll is false and omitted for unordered StructuralFeatures. NOTE. Values of StructuralFeatures may be ordered even if the upper multiplicity is 1. If the insertAt InputPin is present, it has type UnlimitedNatural and multiplicity 1..1 An insertion point that is a positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer 1 meaning the new value will be first in the sequence. A value of unlimited (“*”) for the insertion point means to insert the new value at the end of the sequence. The semantics are undefined for a value of 0 or an integer greater than the number of existing values Reinserting an existing value at a new position in an ordered, unique StructuralFeature moves the value to that position (this works because such StructuralFeature values are ordered sets). The insertion point is ignored if it is used when isReplaceAll=true. The semantics are undefined for adding a value that violates the upper multiplicity of the StructuralFeature, and for adding a new value to a StructuralFeature with isReadonly=true after initialization of the object that would have the value. A LiteralNull is intended to be used to explicitly model the lack of a value. LiteralNull: In the context of a MultiplicityElement with a multiplicity lower bound of 0, this corresponds to the empty set (i.e., a set of no values). It is equivalent to specifying no values for the Element. A LiteralString specifies a constant value of the PrimitiveType String. Though a String is specified as a sequence of characters, String values are considered to be primitive in UML, so their internal structure is not specified as part of UML semantics. A LiteralInteger specifies a constant value of the PrimitiveType Integer. A LiteralBoolean specifies a constant value of the PrimitiveType Boolean. A LiteralUnlimitedNatural specifies a constant value of the PrimitiveType UnlimitedNatural. A LiteralReal specifies a constant value of the PrimitiveType Real. The notation for a LiteralNull varies depending on where it is used. It often appears as the word “null.” Other notations are described elsewhere for specific uses. A LiteralString is shown as a sequence of characters within double quotes. The String value is the sequence of characters, not including the quotes. The character set used is unspecified. A LiteralInteger is shown as a sequence of digits representing the decimal numeral for the Integer value. A LiteralBoolean is shown as either the word “true” or the word “false,” corresponding to its value. A LiteralUnlimitedNatural is shown either as a sequence of digits or as an asterisk (*), where an asterisk denotes unlimited. Note that “unlimited” denotes the lack of a limit on the value of some element (such as a multiplicity upper bound), not a value of “infinity.” A LiteralReal is shown in decimal notation or scientific notation. Decimal notation consists of an optional sign character (+/-) followed by zero or more digits followed optionally by a dot (.) followed by one or more digits. Scientific notation consists of decimal notation followed by either the letter “e” or “E” and an exponent consisting of an optional sign character followed by one or more digits. ... Expressions are ValueSpecifications that specify values resulting from a computation. A StringExpression is an Expression that specifies a String value that is derived by concatenating a list of substrings. The substrings are given as either a list of LiteralString operands or as a list of StringExpression subExpressions (but it is not allowed to mix the two). The String value of a StringExpression is obtained by concatenating, in order, the String values of either the operands or the subExpressions, depending on which is given. An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or based on a textual statement in a language other than UML. A CallEvent is denoted by the name of the triggering Operation, optionally followed by an assignment specification: <call-event> ::= <name> [‘(‘ [<assignment-specification>] ‘)’] <assignment-specification> ::= <assigned-name> [‘,’ <assigned-name>]* <assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation to a Property or Variable of the context object for the triggered Behavior. <assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to support this notation. ... AcceptEventAction is an Action with Triggers for one or more Events. When an AcceptEventAction is executed, it waits for an Event occurrence to be dispatched from the event pool of the context object for its execution that matches one of its Triggers. The context object for an AcceptEventAction is the context object of the Behavior execution within which the AcceptEventAction is executing (which may be the Behavior execution itself ...) An AcceptEventAction is a wait point ... except only the AcceptEventAction waits, rather than the whole Activity (Activities can have other Actions executing while AcceptEventActions are waiting). If a matching Event occurrence for an AcceptEventAction is dispatched from the event pool, then the AcceptEventAction is enabled to continue. However, if the containing Behavior execution has more than one waiting Trigger that matches ... If the Trigger on the AcceptEventAction is chosen, then it completes and produces output on any result OutputPins. An AcceptEventAction with a trigger for a SignalEvent is informally called an accept signal action. If an accept signal action has isUnmarshall=false, then it must have a single result OutputPin on which the Signal instance associated with an accepted SignalEvent occurrence is placed. If it has isUnmarshall=true, then it must have result OutputPins corresponding to each of the attributes of the Signal of the SignalEvent (in order), and the attribute values of the Signal instance associated with an accepted SignalEvent occurrence ... A CallAction is an InvocationAction that calls a Behavior or an Operation. There are three kinds of CallActions A CallBehaviorAction is a CallAction that invokes a Behavior directly, rather than calling a BehavioralFeature that, in turn, results in the invocation of a Behavior. A CallOperationAction is a CallAction that transmits an Operation call request message to the target object, where it may cause the invocation of an associated Behavior. The target object is taken from the target InputPin of the CallOperationAction. A StartObjectBehaviorAction is a CallAction that starts the execution either of a directly instantiated Behavior or of the classifierBehavior of an object. The object to be started is taken from the object InputPin. If the input object is an instantiated Behavior that is not already executing, then it begins executing. If the input object has a classifierBehavior that is not already executing, then it is instantiated and started. In either case ... Behaviors and Operations have totally ordered lists of owned Parameters, and these Parameters are matched to Pins on a CallAction using that ordering. The argument Pins of a CallAction are matched, in order, to the sublist of input Parameters, while the result Pins are matched, in order, to the sublist of output Parameters. The type, ordering, and multiplicity of the argument and result pins of a CallAction shall be the same as the corresponding Parameters. 15.4.3.1 Object Nodes - An ObjectNode holds object tokens during the course of the execution of an Activity. Except in the case of an input ActivityParameterNode ... the tokens held by an ObjectNode arrive from incoming ActivityEdges. Except in the case of an output ActivityParameterNode, tokens held by an ObjectNode may leave the node on outgoing ActivityEdges. A token may traverse only one of the outgoing edges. An ObjectNode may contain multiple object tokens with the same value. Such tokens are not normally combined (but see the special semantics for DataStoreNodes ...). ObjectNodes are TypedElements ... If an ObjectNode has a type specified, then any object tokens held by the ObjectNode shall have values that conform to the type of the ObjectNode. If no type is specified, then the values may be of any type. Null tokens (object tokens without a value) satisfy the type of all object nodes. ObjectNodes may also specify an inState set of States. If such a set is specified, then any object token held by the ObjectNode shall have a value with a type that has or inherits a StateMachine as its classifierBehavior that has all of the states .. An ObjectNode may not contain more tokens than specified by its upperBound, if any. If an ObjectNode has an upperBound, then this ValueSpecification shall evaluate to an UnlimitedNatural value. The upperBound is evaluated each time a token is offered ... If the number of tokens already held by the ObjectNode is greater than or equal to the evaluated upperBound, then the ObjectNode shall not accept any further tokens until some of the ones it is holding are removed. If the removal of one or more tokens brings the number of tokens held below the evaluated upperBound, then the ObjectNode may accept any pending offers up to the limit of the upperBound. If the upperBound evaluates to *, then there is no limit on the number of tokens the ObjectNode may hold. 15.4.3.2 Activity Parameter Nodes - As a kind of Behavior, an Activity may have Parameters When the Activity is invoked, values may be passed into the Activity execution on input Parameters (i.e., those with direction in or inout) and values may be passed out .. on output Parameters (i.e., those with direction inout, out or return). Within an Activity, inputs to and outputs from an Activity are handled using ActivityParameterNodes. Each ActivityParameterNode is associated with one Parameter of the Activity that owns the node. The type of an ActivityParameterNode shall be the same as the type of its associated Parameter. An ActivityParameterNode shall have either all incoming or all outgoing ActivityEdges. An ActivityParameterNode with outgoing edges is an input ActivityParameterNode, while an ActivityParameterNode with incoming edges is an output ActivityParameterNode. (Note that whether an ActivityParameterNode is for input or output is not determined until at least one ActivityEdge is connected to it.) An Activity shall have one ActivityParameterNode corresponding to each in, out, or return Parameter and two ActivityParameterNodes for each inout Parameter. An in Parameter shall not be associated with an output ActivityParameterNode and an out or return Parameter shall not be associated with an input ActivityParameterNode (though either may be associated with an ActivityParameterNode that does not have .. An inout Parameter shall be associated with at most one input ActivityParameterNode and at most one output ActivityParameterNode. 15.4.3.3 Central Buffer Nodes - A CentralBufferNode acts as a buffer between incoming ObjectFlows and outgoing ObjectFlows. It accepts all object tokens offered to it on all incoming flows, which are then held by the node. Held object tokens are offered to outgoing flows according to the general ordering rules for ObjectNodes. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting ... 15.4.3.4 Data Store Nodes - A DataStoreNode is a CentralBufferNode that holds its object tokens persistently while its activity is executing. When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ... ... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even When a DataStoreNode accepts an object token, if that token contains an object with the same identity as an object contained in a token already held by the node, then the duplicate object token shall not be placed on the DataStoreNode. Unlike a regular CentralBufferNode, a DataStoreNode contains objects uniquely. The selection and transformation Behaviors on outgoing ObjectFlows can be used to get information out of a DataStoreNode as if a query were being performed. A Trigger specifies a specific point at which an Event occurrence may trigger an effect in a Behavior. A Trigger may be qualified by the Port on which the Event occurred. trigger_with_ports: If a Trigger specifies one or more ports, the event of the Trigger must be a MessageEvent. A Vertex is an abstraction of a node in a StateMachine graph. It can be the source or destination of any number of Transitions. A Pseudostate is an abstraction that encompasses different types of transient Vertices in the StateMachine graph. A StateMachine instance never comes to rest in a Pseudostate, instead, it will exit and enter the Pseudostate within a single ... step TransitionKind is an Enumeration type used to differentiate the various kinds of Transitions. internal - Implies that the Transition, if triggered, occurs without exiting or entering the source State (i.e., it does not cause a state change). This means that the entry or exit condition of the source State will not be invoked. An internal Transition can be taken even if the S[t]ateMachine is in one or more Regions nested within the associated State. local - Implies that the Transition, if triggered, will not exit the composite (source) State, but it will exit and re-enter any state within the composite State that is in the current state configuration. external - Implies that the Transition, if triggered, will exit the composite (source) State. A Region is a top-level part of a StateMachine or a composite State, that serves as a container for the Vertices and Transitions of the StateMachine. A StateMachine or composite State may contain multiple Regions representing behaviors that may occur in parallel. 14.5.2 FinalState - A special kind of State, which, when entered, signifies that the enclosing Region has completed. 14.5.2 FinalState ... If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed. In general, a ValueSpecification is a model element that is considered semantically to yield zero or more values. An Interval is a ValueSpecification specified using two other ValueSpecifications, the min and the max. 16.4.3.5 Value Specification Actions - A ValueSpecificationAction is an Action that evaluates a ValueSpecification and places the resulting value on its result OutputPin. a LiteralSpecification may be used in a ValueSpecificationAction to produce a constant value. Using an InstanceValue in a ValueSpecificationAction is similar to creating an instance using a CreateObjectAction, except that values may be given for the StructuralFeatures of the instance using slots on the InstanceSpecification of the InstanceValue. isControl : Boolean [1..1] = false Indicates whether the Pin provides data to the Action or just controls how the Action executes. A DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens. decisionInput : Behavior [0..1] ... A Behavior that is executed to provide an input to guard ValueSpecifications on ActivityEdges outgoing from the DecisionNode. decisionInputFlow : ObjectFlow [0..1] ... An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode. zero_input_parameters If the DecisionNode has no decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has no in parameters. DecisionNode::edges The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows. decision_input_flow_incoming The decisionInputFlow of a DecisionNode must be an incoming ActivityEdge of the DecisionNode. two_input_parameters If the DecisionNode has a decisionInputFlow and a second incoming ObjectFlow, then any decisionInput has two in Parameters ... DecisionNode::incoming_outgoing_edges A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge. incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ... A decisionInput Behavior has no out parameters, no inout parameters, and one return parameter. 15.3.3.6 Decision Nodes - A DecisionNode is a ControlNode that chooses between outgoing flows. A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Action::/input : InputPin [0..*] ... The ordered set of InputPins representing the inputs to the Action. Property::isDerivedUnion : Boolean [1..1] = false Specifies whether the property is derived as the union of all of the Properties that are constrained to subset it. A Property may be marked as being a derived union, by setting isDerivedUnion to true. This means that the collection of values denoted by the Property in some context is derived by being the strict union of all of the values denoted ... A Property may be marked as the subset of another subsettedProperty. In this case, calculate a set by eliminating duplicates from the collection of values denoted by the subsetting property in some context. Then that set shall be included in (or the same as) a set calculated by eliminating duplicates from the collection of values denoted by the subsettedProperty in the same context. Property::subsettedProperty : Property [0..*] ... The properties of which this Property is constrained to be a subset, if any. UseCase::extend : Extend [0..*]{subsets A_source_directedRelationship::directedRelationship, subsets Namespace::ownedMember} ... The Extend relationships owned by this UseCase. A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject. UseCase::extensionPoint : ExtensionPoint [0..*]{subsets Namespace::ownedMember} ... The ExtensionPoints owned by this UseCase. UseCase::include : Include [0..*]{subsets A_source_directedRelationship::directedRelationship, subsets Namespace::ownedMember} ... The Include relationships owned by this UseCase. UseCase::subject : Classifier [0..*] ... The subjects to which this UseCase applies. Each subject or its parts realize all the UseCases that apply to it. A UseCase is shown as an ellipse, either containing the name of the UseCase or with the name of the UseCase placed below the ellipse. An optional stereotype keyword may be placed above the name. A subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name in the top-left corner, with the UseCase ellipses visually located inside this rectangle. The same modeled UseCase may be visually depicted as separate ellipses within multiple subject rectangles. Where a subject is a Classifier with a standard stereotype, the keyword for the stereotype shall be shown in guillemets above the name of the subject. In cases where the metaclass of a subject is ambiguous, the keyword . corresponding to the notation for the metaclass of Classifier (see 9.2.4) shall be shown in guillemets above the name. «Refine» Abstraction Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design. The mapping specifies the relationship between the two elements or sets of elements. The mapping ... Message::signature : NamedElement [0..1] ... The signature of the Message is the specification of its content. It refers either an Operation or a Signal. If a request-message-label does not include an input-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all in and inout ownedParameters of an Operation or attributes of a Signal ... Note that the parentheses are not considered part of the input-argument list, so a request-message-label without an input-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. A reply-message-label is used for reply Messages. It has the following form ... The message-name appearing in a reply-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply). Otherwise the name is unconstrained. A reply-message-label may optionally have an assignment-target given to the left of the message-name, with a corresponding returned value denoted by the optional value-specification given after a colon at the end of the reply-message-label. If the Message has a signature that is an Operation with a return parameter, then this assignment-target and/or value-specification corresponds to the argument for that parameter (if no assignment-target is given, it is considered to be unknown). If the Message has a signature without a return parameter, then no assignment-target or value-specification may be given for the reply-message-label as a whole. If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. However, if the Message has a signature that is an Operation with out or inout ownedParameters, then ... An output-argument always explicitly names the parameter to which it is to be matched. Any parameters that are not named are considered to have implicit wildcard arguments. (There is thus no need for an explicit wildcard notation for output-arguments.) If a reply-message-label does not include an output-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all out and inout ownedParameters of the signature Operation (if any). Note that the parentheses are not considered part of the output-argument list, so a reply-message-label without an output-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. An output-argument with an explicit assignment-target given may also optionally include a value-specification. If a value-specification is given, then this denotes the returned value for the argument. Otherwise the argument has no modeled returned value If an output-argument does not have an explicit assignment-target specified, it is considered to have an unknown assignment target. In this case, it is required to include a value-specification, which denotes the returned value for the argument. If the identity of a reply Message is obvious (e.g., when its sendEvent is the only reply within the extent of an ExecutionOccurence where there is only one receipt of an Operation call message), the label may be omitted to simplify the diagram. If the reply Message has a signature, then wildcard arguments are provided for all return, out and inout ownedParameters of the signature Operation. Parameters may also be marked as streaming (i.e., have the isStreaming property be true). Such Parameters allow values to be passed into and out of a Behavior execution any time during its course, rather than just on invocation and completion. If an input Parameter is streaming, then argument values may be provided for the Parameter during the course of a Behavior execution rather than just at invocation. One or more argument values may be posted to a streaming input Parameter at or any time after the invocation of a Behavior and before its completion. These argument values are then available to affect the further course of the Behavior execution ... If an output Parameter is streaming, then a Behavior execution may provide result values for the Parameter during its course rather than just at completion. One or more result values may be posted to a streaming output Parameter any time after the invocation of a Behavior up to or at its completion. These result values are then available to affect the further course of the execution of the invoking Behavior.. An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure. The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6. The standalone Pin in the notation maps to an OutputPin and an InputPin and one ObjectFlow edge between them in the underlying model. This form should be avoided if the Pins are not of the same type. Multiple arrows coming out of a standalone Pin rectangle is an optional notation for multiple edges coming out of an OutputPin. Control Pins are shown with the textual annotation {control} placed near the Pin symbol. ObjectNode::isControlType : Boolean [1..1] = false Indicates whether the type of the ObjectNode is to be treated as representing control values that may traverse ControlFlows. ObjectNode::ordering : ObjectNodeOrderingKind [1..1] = FIFO Indicates how the tokens held by the ObjectNode are ordered for selection to traverse ActivityEdges outgoing from the ObjectNode. ObjectNode::inState : State [0..*] ... The States required to be associated with the values held by tokens on this ObjectNode. ObjectNode::selection : Behavior [0..1] ... A Behavior used to select tokens to be offered on outgoing ActivityEdges. ObjectNode::upperBound : ValueSpecification [0..1] The maximum number of tokens that may be held by this ObjectNode. Tokens cannot flow into the ObjectNode if the upperBound is reached. If no upperBound is specified, then there is no limit on how many ... A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are use to control the execution of ExecutableNodes object_nodes ControlFlows may not have ObjectNodes at either end, except for ObjectNodes with control type. A control Pin (with isControl=true) must have a control type (isControlType=true), so that they may be used with ControlFlows. Control Pins are ignored in the constraints that Actions place on Pins (including matching to parameters for InvocationActions ...). Tokens arriving at a control InputPin have the same semantics as control tokens arriving at the Action, except that control tokens can be buffered in control Pins. Tokens are placed on control OutputPins according to the same semantics as tokens placed on ControlFlows coming out of an Actions. no_executable_nodes ObjectFlows may not have ExecutableNodes at either end. An ObjectFlow is an ActivityEdge that is traversed by object tokens that may hold values. Object flows also support multicast/receive, token selection from object nodes, and transformation of tokens. A Class is shown using the Classifier symbol. As Class is the most widely used Classifier, no keyword is needed to indicate that the metaclass is Class. A Class has four mandatory compartments: attributes, operations, receptions ... and internal structure ... A Class may also have optional compartments as described for Classifiers in general Note that this notation for the subject classifier differs from the normal Classifier notation – it has no header or compartments. Note also that the subject rectangle does not imply that the subject classifier owns the contained UseCases, but merely that the UseCases apply to that classifier. In particular, there is scope for confusion between a UseCase appearing visually contained in a boundary rectangle representing a Classifier that is its subject, and appearing visually contained in a compartment of a Classifier that is its owner... A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its... A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. A subject of a UseCase could be a system or any other element that may have behavior, such as a Component or Class. Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality must always be completed for the UseCase to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the UseCase can be initiated again, or in an error state. UseCases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the UseCases may also state the requirements the specified subject poses on its environment by defining how the Actors should interact with the subject so that it will be able to perform its services. The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, as well as by pre-conditions, post-conditions and natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the UseCase and its Actors as the Classifiers that type its parts. UseCases may have associated Actors, which describe how an instance of the Classifier realizing the UseCase and a user playing one of the roles of the Actor interact. Two UseCases specifying the same subject cannot be associated as each of them individually describes a complete usage of the subject. A UseCase may be owned either by a Package or by a Classifier. Although the owning Classifier typically represents a subject to which the owned UseCases apply, this is not necessarily the case ... UseCases need not be owned by their subject. A Comment is shown as a rectangle with the upper right corner bent (this is also known as a “note symbol”). The rectangle contains the body of the Comment. The connection to each annotatedElement is shown by a separate dashed line. A stereotype must be contained, directly or indirectly, in a profile. Just like a Class, a Stereotype may have Properties, which have traditionally been referred to as Tag Definitions. When a Stereotype is applied to a model element, the values of the Properties have traditionally been referred to as tagged values. Classifier::isAbstract : Boolean [1..1] If true, the Classifier can only be instantiated by instantiating one of its specializations. An abstract Classifier is intended to be used by other Classifiers e.g., as the target of Associations or Generalizations Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol to the textual representation that would be shown if the member were not inherited. Property is indirectly a kind of RedefinableElement, so Properties may be redefined. The name and visibility of a Property are not required to match those of any Property it redefines. A derived Property may redefine one which is not derived. An implementation shall ensure that the constraints implied by the derivation are maintained if the Property is updated. If a Property has a specified default, and the Property redefines another Property with a specified default, then the redefining Property’s default is used in place of the more general default from the redefined Property. A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation. This means that the complete semantics of the client Element(s) are either semantically or structurally dependent on the definition of the supplier Element(s). A Usage is a Dependency in which the client Element requires the supplier Element (or set of Elements) for its full implementation or operation. A Connector specifies links ... between two or more instances playing owned or inherited roles within a StructuredClassifier. Each link may be realized by something as simple as a pointer or by something as complex as a network connection, and may represent the possibility of instances being able to communicate because their identities are known by virtue of being passed in ... In contrast to Associations, which specify links between any suitably-typed instance of the associated Classifiers, Connectors specify links between instances playing the connected roles only. Each Connector may be attached to two or more ConnectableElements, each representing a set of instances that contribute to the instantiation of the containing StructuredClassifier. A ConnectorEnd is an endpoint of a Connector, which attaches the Connector to a ConnectableElement. A Connector specifies links that enables communication between two or more instances. In contrast to Associations, which specify links between any instance of the associated Classifiers, Connectors specify links between instances playing the connected parts only. A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances Such a Port is called a behavior Port. If there is no Behavior defined for this EncapsulatedClassifier, any communication arriving at a behavior Port is lost. A delegation Connector is a Connector that links a Port to a role within the owning EncapsulatedClassifier. It represents the forwarding of requests (Operation invocations and Signals). A request that arrives at a Port that has a delegation Connector to one or more Properties or Ports on Properties will be passed on to those targets for handling. Delegation Connectors can be used to model the hierarchical decomposition of behavior, where services provided by an EncapsulatedClassifier may ultimately be realized by one that is nested multiple levels deep within it. A PrimitiveType defines a predefined DataType, without any substructure. A PrimitiveType may have algebra and operations defined outside of UML, for example, mathematically. A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances. If a DataType has attributes (i.e., Properties owned by it and in its namespace) it is called a structured DataType. Instances of a structured DataType contain attribute values matching its attributes. Instances of a structured DataType are considered to be equal if and only if the structure is the same and the values of the corresponding attributes are equal. A DataType may be parameterized, bound, and used as TemplateParameters. An InstanceSpecification is a model element that represents an instance in a modeled system. An InstanceSpecification can act as a DeploymentTarget in a Deployment relationship, in the case that it represents an instance of a Node. It can also act as a DeployedArtifact, if it represents an instance of an Artifact. InstanceSpecification::classifer : Classifier [0..*] ... The Classifier or Classifiers of the represented instance. If multiple Classifiers are specified, the instance is classified by all of them. InstanceSpecification::slot : Slot [0..*] ... A Slot giving the value or values of a StructuralFeature of the instance. An InstanceSpecification can have one Slot per StructuralFeature of its Classifiers, including inherited features. ... InstanceSpecification::slot : Slot [0..*] ... It is not necessary to model a Slot for every StructuralFeature, in which case the InstanceSpecification is a partial description. InstanceSpecification::specification : ValueSpecification [0..1] ... A specification of how to compute, derive, or construct the instance. Slot::definingFeature : StructuralFeature [1..1] ... The StructuralFeature that specifies the values that may be held by the Slot. Slot::owningInstance : InstanceSpecification [1..1] ... The InstanceSpecification that owns this Slot. Slot::value : ValueSpecification [0..*]{ordered, subsets Element::ownedElement} ... The value or values held by the Slot. The operations compartment of a Class contains notation for its ownedOperations ... The receptions compartment contains ownedReceptions ... The set of Interfaces realized by a BehavioredClassifier are its provided Interfaces, which represent the services and obligations that instances of that BehavioredClassifier offer to their clients. Interfaces may also be used to specify required Interfaces, which are specified by a Usage dependency between the BehavioredClassifier and the corresponding Interfaces. Required Interfaces specify services that a BehavioredClassifier needs in order to perform its function and fulfill its own obligations to its clients. A given BehavioredClassifier may implement more than one Interface and that an Interface may be implemented by a number of different BehavioredClassifiers. A MessageEvent specifies the receipt by an object of either an Operation call or a Signal instance. An Event is the specification of some occurrence that may potentially trigger effects by an object. A ChangeEvent models a change in the system configuration that makes a condition true. A TimeEvent is an Event that occurs at a specific point in time. A trigger for an AnyReceiveEvent is triggered by the receipt of any message that is not explicitly handled by any related trigger. A CallEvent models the receipt by an object of a message invoking a call of an Operation. A SignalEvent represents the receipt of an asynchronous Signal instance. In general, a StateMachine can have multiple Regions, each of which may contain States of its own, some of which may be composites with their own multiple Regions, etc. Consequently, a particular “state” of an executing StateMachine instance is represented by one or more hierarchies of States, starting with the topmost Regions of the StateMachine and down through the composition hierarchy to the simple, or leaf, States. Similarly, we can talk about such a hierarchy of substates within a composite State. This complex hierarchy of States is referred to as a state configuration (of a State or a StateMachine). For example, one valid state configuration for an execution of the StateMachine depicted in Figure 14.9 is: <CourseAttempt - Studying – (Studying::Lab2, Studying::TermProject, Studying::FinalTest)>. An executing StateMachine instance can only be in exactly one state configuration at a time, which is referred to as its active state configuration. StateMachine execution is represented by transitions from one active state configuration to another in response to Event occurrences that match the Triggers of the StateMachine. A State is said to be active if it is part of the active state configuration. A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited. A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated ... ... the entry Behavior of the State is executed (if defined) upon entry, but only after any effect Behavior associated with the incoming Transition is completed. ... if a doActivity Behavior is defined for the State, this Behavior commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent Behaviors associated with entering the State, such as the entry ... When exiting a State, regardless of whether it is simple or composite, the final step involved in the exit, after all other Behaviors associated with the exit are completed, is the execution of the exit Behavior of that State. If the State has a doActivity Behavior that is still executing when the State is exited, that Behavior is aborted before the exit Behavior commences execution. When exiting from a composite State, exit commences with the innermost State in the active state configuration. This means that exit Behaviors are executed in sequence starting with the innermost active State. If the exit occurs through an exitPoint Pseudostate, then the exit Behavior of the State is executed after the effect Behavior of the Transition terminating on the exit point. When exiting from an orthogonal State, each of its Regions is exited. After that, the exit Behavior of the State is executed. Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if defined) of that State has completed execution. A Transition represents an arc between exactly one source Vertex and exactly one Target vertex (the source and targets may be the same Vertex). It may form part of a compound transition, which takes the StateMachine from one steady State configuration... Transition::kind : TransitionKind [1..1] = external Indicates the precise type of the Transition. Transition::container : Region [1..1] ... Designates the Region that owns this Transition. Transition::effect : Behavior [0..1] ... Specifies an optional behavior to be performed when the Transition fires. Transition::guard : Constraint [0..1] ... A guard is a Constraint that provides a fine-grained control over the firing of the Transition. The guard is evaluated when an Event occurrence is dispatched by the StateMachine. ... Transition::guard : Constraint [0..1] ... If the guard is true at that time, the Transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed. Transition::redefinedTransition : Transition [0..1] ... The Transition that is redefined by this Transition. Transition::/redefinitionContext : Classifier [1..1] ... References the Classifier in which context this element may be redefined. Transition::source : Vertex [1..1] ... Designates the originating Vertex (State or Pseudostate) of the Transition. Transition::target : Vertex [1..1] ... Designates the target Vertex that is reached when the Transition is taken. Transition::trigger : Trigger [0..*] ... Specifies the Triggers that may fire the transition If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by default or explicitly. If the Transition terminates on the edge of the composite State (i.e., without entering the State), then all the Regions are entered using the default entry rule above. If the Transition explicitly enters one or more Regions (in case of a fork), these Regions are entered explicitly and the others by default. Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing. Exit points are the inverse of entry points. That is, Transitions originating from a Vertex within the composite State can terminate on the exit point. In a well-formed model, such a Transition should have a corresponding external Transition outgoing from the same exit point, representing a continuation of the terminating Transition. If the composite State has an exit Behavior defined, it is executed after any effect Behavior of the incoming inside Transition and before any effect Behavior of the outgoing external Transition. Entry points represent termination points (sources) for incoming Transitions and origination points (targets) for Transitions that terminate on some internal Vertex of the composite State. In effect, the latter is a continuation of the external incoming Transition, with the proviso that the execution of the entry Behavior of the composite State (if defined) occurs between the effect Behavior of the incoming Transition and the effect ... If there is no outgoing Transition inside the composite State, then the incoming Transition simply performs a default State entry. Two types of history Pseudostates are provided. Deep history (deepHistory) represents the full state configuration of the most recent visit to the containing Region. The effect is the same as if the Transition terminating on the deepHistory Pseudostate had, instead, terminated on the innermost State of the preserved state configuration, including execution of all entry Behaviors encountered along the way. Shallow history (shallowHistory) represents a return to only the topmost substate of the most recent state configuration, which is entered using the default entry rule. In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate, using the default ... This is a Transition that originates in the history Pseudostate and terminates on a specific Vertex (the default history state) of the Region containing the history Pseudostate. This Transition is only taken if execution leads to the history Pseudostate a Otherwise, the appropriate history entry into the Region is executed (see above). If no default history Transition is defined, then standard default entry of the Region is performed .... A Transition is a single directed arc originating from a single source Vertex and terminating on a single target Vertex (the source and target may be the same Vertex), which specifies a valid fragment of a StateMachine Behavior. It may have an associated effect Behavior, which is executed when the Transition is traversed (executed). NOTE. The duration of a Transition traversal is undefined, allowing for different semantic interpretations, including both “zero” and non-“zero” time. Transitions are executed as part of a more complex compound transition that takes a StateMachine execution from one stable state configuration to another. A Transition may own a set of Triggers, each of which specifies an Event whose occurrence, when dispatched, may trigger traversal of the Transition. A Transition trigger is said to be enabled if the dispatched Event occurrence matches its Event type. When multiple triggers are defined for a Transition, they are logically disjunctive, that is, if any of them are enabled, the Transition will be triggered. The semantics of a Transition depend on its relationship to its source Vertex. Three different possibilities are defined, depending on the value of the Transition’s kind attribute ... kind = external means that the Transition exits its source Vertex. If the Vertex is a State, then executing this Transition will result in the execution of any associated exit Behavior of that State. kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). ... kind = local ... However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State. kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry Behaviors are executed ... kind = internal ... This kind of Transition can only be defined if the source Vertex is a State. Transitions of the kind internal are not shown explicitly in diagrams. An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity. Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity. All concrete kinds of ExecutableNodes are Actions ... An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it. An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ... An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ... Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed. The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode. While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing]. In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution. When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ... An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows. InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. There are two kinds of ActivityEdges: A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...). ControlFlows are used to explicitly sequence execution of ActivityNodes, as the target ActivityNode cannot receive a control token and start execution until the source ActivityNode completes execution and produces the token. An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes. Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens There are three kinds of ActivityNodes: ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...). ObjectNodes hold object tokens accepted from incoming ObjectFlows and may subsequently offer them to outgoing ObjectFlows (with a modeler-specified exception for ControlFlows, see isControlType for ObjectNodes ...). ExecutableNodes actually carry out the desired behavior of an Activity. If an ExecutableNode has incoming ControlFlows, then there must be tokens offered on all these flows that it accepts before beginning execution. A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges. If the incoming edge is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node. If at least one of these offers is accepted, the offered tokens are removed from their original source and the acceptor receives a copy of the tokens. A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow. A MergeNode is a control node that brings together multiple flows without synchronization. A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows. All tokens offered on the incoming edges of a MergeNode are offered to the outgoing edge. There is no synchronization of flows or joining of tokens. An OpaqueAction is an Action whose specification may be given in a textual concrete syntax other than UML. An OpaqueAction may also be used as a temporary placeholder before some other kind of Action is chosen. A FinalNode is a ControlNode at which a flow in an Activity stops. A FinalNode shall not have outgoing ActivityEdges. A FinalNode accepts all tokens offered to it on its incoming ActivityEdges. There are two kinds of FinalNode: A FlowFinalNode is a FinalNode that terminates a flow. All tokens accepted by a FlowFinalNode are destroyed. This has no effect on other flows in the Activity. An ActivityFinalNode is a FinalNode that stops all flows in an Activity (or StructuredActivityNode, see sub clause 16.11). A token reaching an ActivityFinalNode owned by an Activity terminates the execution of that Activity. Pins are used to specify the inputs and outputs for Actions. An Action may accept inputs and produce outputs, as specified by InputPins and OutputPins of the Action, respectively. Each Pin on an Action specifies the type and multiplicity for a specific input or output of that Action. Action::/output : OutputPin [0..*] ... The ordered set of OutputPins representing outputs from the Action. An InputPin is a Pin that holds input values to be consumed by its Action. An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin. The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action. Tokens consumed by an Action are immediately removed from its InputPins when the action begins an execution (except in some cases for StructuredActivityNodes, where tokens may remain on InputPins during the Action execution ...) An OutputPin is a Pin that holds output values produced by an Action. For each execution, an Action cannot terminate itself unless it can put at least as many values into its outputs as required by the multiplicity lower bounds on those OutputPins. Values that may remain on the OutputPins from previous executions are not... An Action may not put more values into an output in a single execution than the [upper] multiplicity of that OutputPin. ValuePins and ActionInputPins are InputPins, but are not used in the determination of whether an Action is enabled for execution. If an Action has no other way to start execution, simply having ValuePins or ActionInputPins for its inputs will not enable.. When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and the results are provided as inputs to the Action when it begins execution. A ValuePin provides a value by evaluating a ValueSpecification ... When the Action is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution. When an Action in an Activity completes execution, object tokens for output data placed on its OutputPins may be offered on any outgoing ObjectFlows from those Pins ... In addition, control tokens shall be offered on any outgoing ControlFlows ... The time at which an Action executes and what inputs are accepted by each execution are determined by the kind of Action it is, characteristics of its InputPins, and the Behavior in which it is used. An Action continues executing until it has completed. The detailed semantics of the execution of an Action and the definition of its completion depend on the particular kind of Action being executed. When completed, an Action execution provides any output data on the OutputPins of the Action, and it terminates. However, if the Action is an invocation of a Behavior with streaming Parameters ... then the Action execution may also post data to OutputPins corresponding to streaming output Parameters before completion of the execution ... The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin. For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution. If the Action is an invocation of a Behavior with streaming Parameters ... the Action execution may consume additional data supplied to InputPins corresponding to streaming input Parameters ... Otherwise ... any additional data on InputPins has no effect A DecisionNode accepts tokens on its primary incoming edge and offers them to all its outgoing edges. However, each token offered on the primary incoming edge shall traverse at most one outgoing edge. Tokens are not duplicated. a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode Join nodes may have a joinSpec, which is a ValueSpecification that determines the condition under which the join will emit a token. If a JoinNode has a joinSpec, then this ValueSpecification is evaluated whenever a new token is offered to the JoinNode ... joinSpec ... This evaluation shall not be interrupted by any new tokens offered during the evaluation, nor shall concurrent evaluations be started when new tokens are offered during an evaluation. The ValueSpecification shall evaluate to a Boolean value. If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote a Boolean value indicating the presence (true) or absence (false) of an offer from a ControlFlow ... If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote ... the value associated with an object token offered from an ObjectFlow (if any). Alternatively, the joinSpec may consist of an Expression with the name of a single Boolean operator and no operands specified. In this case, the value of the joinSpec shall be given by applying the given operator to Boolean values indicating ... If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge. The ActivityEdges going out of ForkNodes continue to hold the tokens they accept until all pending offers have been accepted by their targets. As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes ... and ExecutableNodes ...). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired. A LoopNode is a StructuredActivityNode that represents an iterative loop. A LoopNode consists of a setupPart, a test and a bodyPart, which identify subsets of the ExecutableNodes contained in the LoopNode. Any ExecutableNode in the LoopNode must be included in the setupPart, test or bodyPart for the LoopNode. The setupPart of a LoopNode is executed first. When the setupPart has completed execution, the iterative execution of the loop begins. Execution of the test section may precede or follow execution of the bodyPart, depending on whether isTestFirst is true or false, respectively. ... If the bodyPart is executed first (isTestFirst=false), it is always executed at least once ... The test section has an Action owning the decider OutputPin with type Boolean identified by the LoopNode. When the test section has completed execution, if the value on the decider OutputPin is true, then the bodyPart is executed. Otherwise ... After each execution of the bodyPart, the test section is executed again, for the next iteration of the loop. A LoopNode may also define a set of loopVariable OutputPins used to hold intermediate values during each loop iteration. These OutputPins may have outgoing ActivityEdges, in order to make the values they hold available within the test and bodyPart ... If a LoopNode has loopVariable OutputPins, then it must also have matching sets of loopVariableInput InputPins, bodyOutput OutputPins (owned by Actions within the bodyPart), and result OutputPins. When the LoopNode begins executing, the tokens on the loopVariableInput InputPins are moved to the corresponding loopVariable OutputPins before the first iteration of the loop. After the completion of each execution of the bodyPart of the LoopNode, any remaining tokens on the loopVariable OutputPins are destroyed and tokens on the bodyOutput OutputPins are copied to the corresponding loopVariable OutputPins so that they are ... Once the test fails and the loop is completed, the tokens on the bodyOutput OutputPins from the last iteration are moved to the result OutputPins and offered on any edges outgoing from those OutputPins. SendSignalAction::target: The InputPin that provides the target object to which the Signal instance is sent SendSignalAction::signal: The Signal whose instance is transmitted to the target. InvocationAction::onPort : Port [0..1] For CallOperationActions, SendSignalActions, and SendObjectActions, an optional Port of the target object through which the invocation request is sent. InvocationAction::argument : InputPin [0..*] The InputPins that provide the argument values passed in the invocation request. Trigger::port : Port [0..*] A optional Port of through which the given effect is detected. Trigger::event : Event [1..1] The Event that detected by the Trigger. 14.2.3.8.3 Completion Transitions and completion events: A special kind of Transition is a completion Transition, which has an implicit trigger. The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State. Completion events have dispatching priority. That is, they are dispatched ahead of any pending Event occurrences in the event pool. If a role is typed by a classifier other than Class, the name compartment of the part box symbol contains the appropriate keyword (e.g., «component») above the name. For some kinds of Classifiers, optionally in the right hand corner an icon denoting the kind of Classifier can be displayed. In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes. This means that: Not all words appearing between guillemets are necessarily keywords, and words appearing in guillemets do not necessarily represent stereotypes. UML 2.5.1: «Trace»: Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. UML 2.5.1: «Trace»: As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal. If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges. If the DecisionNode does not have a decisionInput, then the value contained in the object token on the decisionInputFlow is made available to the guards on each outgoing edge, regardless of whether the primary incoming flow is a ControlFlow or an ObjectFl A CreateObjectAction is an Action that creates an instance of the specified Classifier. CreateObjectAction::classifier : Classifier [1..1] The Classifier to be instantiated. CreateObjectAction::result : OutputPin [1..1]{subsets Action::output} The OutputPin on which the newly created object is placed. If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specific val The evaluated default then becomes the initial value (or values) of the Property. If a Property has a specified default, and the Property redefines another Property with a specified default, then the redefining Property’s default is used in place of the more general default from the redefined Property. Property::defaultValue : ValueSpecification [0..1] Specifies a ValueSpecification that represents a value to be used when no argument is supplied for the Parameter. A ValueSpecification is the specification of a (possibly empty) set of values. A ValueSpecification is a ParameterableElement that may be exposed as a formal TemplateParameter and provided as the actual parameter in the binding of a template. CallBehaviorAction::behavior : Behavior [1..1] ... The Behavior being invoked. A Property may represent an attribute of a Classifier, a memberEnd of an Association, or in some cases both simultaneously. An Actor specifies a role played by a user or any other system that interacts with the subject. If onPort is given, then the Port shall be an owned or inherited feature of the type of the target InputPin of the Action. As a specialization of Classifier, Enumerations can participate in generalization relationships. An Enumeration that specializes another may define new EnumerationLiterals that are not defined in the generalizing Enumeration; in such a case the set of applicable literals comprises inherited literals plus locally-defined ones. External links https://www.omg.org/spec/UML/2.5.1/PDF Visit also UML zone Object Management Group™ (OMG™) Visit also (backlinks) OMG Systems Modeling Language (SysML) 1.7beta1 On OMG copyright in text extracts and figures reproduced for educational purposes HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study Semantics of a Foundational Subset for Executable UML Models 1.4 OMG Systems Modeling Language (SysML) 1.6 Flags
