Accept Call Action

A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.

An action is a named element that is the fundamental unit of executable functionality.

The execution of an action represents some transformation or processing in the modeled system, be it a computer system or otherwise.

An action represents a single step within an activity, that is, one that is not further decomposed within the activity.

An action has pre- and post-conditions.

A accept event action is an action that waits for the occurrence of an event meeting specified conditions.

An accept call action is an accept event action representing the receipt of a synchronous call request. In addition to the normal operation parameters, the action produces an output that is needed later to supply the information to the reply action necessary to return control to the caller. This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

Properties

Mandatory

Action Kind: The value must be 'acceptCallAction'.
The value must be ''.

Rules

Name: The value can be anything.
The name of the item.
Keywords: The value can be anything.
A keyword is a lightweight variant of a stereotype to extend the semantics of a model element. As opposite of stereotypes, keywords does not have do be defined in a profile.

If several keywords are given, they should be separated by commas.
Stereotypes: The value can be anything.
A stereotype defines how a model element may be extended, and enables the use of platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass.

Stereotypes should be given in the format 'profile::stererotype'. Stereotypes should be separated by commas.
Documentation: The value can be anything.
A textual description of the element.
Visibility: The value shall be a valid literal from the enumeration Visibility Kind.
Determines where the item appears within different Namespaces within the overall model, and its accessibility.
Leaf: The value shall be non-empty.
Indicates whether it is possible to further specialize an item. If the value is true, then it is not possible to further specialize the item.
Unmarshall: The value shall be non-empty.
Indicates whether there is a single output pin for the event, or multiple output pins for attributes of the event.

Parent

An element of one of the following kinds:

Activity (Activity)
An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions.
Structured Activity Node (Structured Activity Node)
A structured activity node is an executable activity node that may have an expansion into subordinate nodes as an activity group. The subordinate nodes must belong to only one structured activity node, although they may be nested.

Because of the concurrent nature of the execution of actions within and across activities, it can be difficult to guarantee the consistent access and modification of object memory.
In order to avoid race conditions or other concurrency-related problems, it is sometimes necessary to isolate the effects of a group of actions from the effects of actions outside the group. This may be indicated by setting the mustIsolate attribute to true on a structured activity node.

If a structured activity node is "isolated," then any object used by an action within the node cannot be accessed by any action outside the node until the structured activity node as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the node.

Nested Elements

Rules

Arbitrary number of elements of the following kinds:
- Action Input Pin (Pin)
  A pin provides values to actions and accept result values from them. A pin is an object node for inputs and outputs to actions.
  
  An input pin is a pin that holds input values to be consumed by an action.
  
  An action input pin is a kind of pin that executes an action to determine the values to input to another.
- Constraint (Constraint)
  A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
- Input Pin (Pin)
  A pin provides values to actions and accept result values from them. A pin is an object node for inputs and outputs to actions.
  
  An input pin is a pin that holds input values to be consumed by an action.
- Output Pin (Pin)
  A pin provides values to actions and accept result values from them. A pin is an object node for inputs and outputs to actions.
  
  An output pin is a pin that holds output values produced by an action.
- Value Pin (Pin)
  A pin provides values to actions and accept result values from them. A pin is an object node for inputs and outputs to actions.
  
  An input pin is a pin that holds input values to be consumed by an action.
  
  A value pin is an input pin that provides a value by evaluating a value specification.

Outgoing

Rules

Arbitrary number of elements of the following kinds:
- Control Flow (Control Flow)
- Object Flow (Object Flow)

Incoming

Rules

Arbitrary number of elements of the following kinds:
- Control Flow (Control Flow)
- Object Flow (Object Flow)

Relations

Rules

Arbitrary number of elements of the following kinds:
- Abstraction (Abstraction)
  An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints.
- Dependency (Dependency)
  A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.
  
  This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).
- Information Flow (Information Flow)
  An information flow specifies that one or more information items circulates from its sources to its targets.
  
  Informationflows require some kind of information channel for transmitting information items from the source to the destination. An information channel is represented in various ways depending on the nature of its sources and targets. It may berepresented by connectors, links, associations, or even dependencies.
  
  For example, if the source and destination are partsin some composite structure such as a collaboration, then the information channel is likely to be represented by aconnector between them. Or, if the source and target are objects (which are a kind of instance specification), they may berepresented by a link that joins the two, and so on.
- Realization (Realization)
  Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
- Substitution (Substitution)
  A substitution is a relationship between two classifiers signifies that the substituting classifier complies with the contract specified by the contract classifier. This implies that instances of the substituting classifier are runtime substitutable where instances of the contract classifier are expected.
- Usage (Usage)
  A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. A usage is a dependency in which the client requires the presence of the supplier.

Accept Call Action (Action)

Accept Call Action (Action)

Properties

Mandatory

Rules

Parent

Nested Elements

Rules

Outgoing

Rules

Incoming

Rules

Relations

Rules

Usage