Specification - UML

This is a translation of the human readable UML 1.5 specification published by the OMG as document formal/03-02-04 into an EMOF/OCL specification with embedded documentation.

Various details of the original specification have been corrected or modified to accomodate the use of EMOF and OCL2. In particular, the OCL constraints and side-effect free operations have been corrected in some cases to respect the more formal syntax of OCL2, and, where semantic errors have been made, the intent documented in natural language in the original specification. In all cases the original formulation of the OCL is preserved as a comment for comparison purposes.

The major consequence of moving from a MOF 1.2/UML meta-modelling formalism to EMOF is that association classes are not supported by EMOF. Several options are possible to handle this.

1. Association classes can be omitted, except where they are associated with an optional or 1..1 relationship, in which case the attributes of the association class may be merged into the many type, in the case of optional relationships, or either type in the case of 1..1 relationships, assuming in either case that there is no name clash with pre-existing attributes or other merged attributes.

2. Association classes can be replaced with normal classes serving as proxies. The association is modelled as two association between the original participants via the proxy class.

The former approach is taken in this specification, as, although less expressive, it is more usually compatible with external tools for XMI serialisation.

The following association classes are affected:

::Foundation::Core::ElementOwnership - merged with ::Foundation::Core::ModelElement

::Foundation::Core::TemplateParameter - merged with ::Foundation::Core::ModelElement

::Foundation::Core::ElementResidence - omitted

::"Model Management"::ElementImport - omitted

Constraints referring to these types and their attributes are rewritten or omitted as appropriate.

Contents:

Package - ::Foundation

Package - ::Foundation::Data Types

Enumeration - ::Foundation::Data Types::AggregationKind

An enumeration that denotes what kind of aggregation an Association is. When placed on a target end, specifies the relationship of the target end to the source end.

  • none

    The end is not an aggregate.

  • aggregate

    The end is an aggregate; therefore, the other end is a part and must have the aggregation value of none. The part may be contained in other aggregates.

  • composite

    The end is a compisite; therefore, the other end is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other composite.

Enumeration - ::Foundation::Data Types::CallConcurrencyKind

An enumeration that denotes the semantics of multiple concurrent calls to the same passive instance (i.e., an Instance originating from a Classifier with isActive=false).

  • sequential

    Callers must coordinate so that only one call to an Instance (on any sequential Operation) may be outstanding at once. If simultaneous calls occur, then the semantics and integrity of the system cannot be guaranteed.

  • guarded

    Multiple calls from concurrent threads may occur simultaneously to one Instance (on any guarded Operation), but only one is allowed to commence. The others are blocked until the performance of the first Operation is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks. Guarded Operations must perform correctly (or block themselves) in the case of a simultaneous sequential Operation or guarded semantics cannot be claimed.

  • concurrent

    Multiple calls from concurrent threads may occur simultaneously to one Instance (on any concurrent Operation). All of them may proceed conccurently with the correct semantics. Concurrent Operations must perform correctly in the case of a simultaneous sequential or guarded Operation or concurrent semantics cannot be claimed.

Enumeration - ::Foundation::Data Types::ChangeableKind

In the metamodel, ChangeableKind defines an enumeration that denotes how an AttributeLink or LinkEnd may be modified.

  • changeable

    No restrictions on modification.

  • frozen

    The value may not be changed from the source end after the creation and initialization of the source object. Operations on the other end may change a value.

  • addOnly

    If the multiplicity is not fixed, values may be added at any time from the source object, but once created a value may not be removed from the source end. Operations on the other end may change a value.

Enumeration - ::Foundation::Data Types::OrderingKind

Defines an enumeration that specifies how the elements of a set are arranged. Used in conjunction with elements that have a multiplicity in cases when the multiplicity value is greater than one. The ordering must be determined and maintained by operations that modify the set. The intent is that the set of enumeration literals be open for new values to be added by tools for purposes of design, code generation, etc. For example, a value of sorted might be used for a design specification.

  • unordered

    The elements in the set have no inherent ordering.

  • ordered

    The elements in the set have sequential ordering.

    Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools.

Enumeration - ::Foundation::Data Types::ParameterDirectionKind

In the metamodel, ParameterDirectionKind defines an enumeration that denotes if a Parameter is used for supplying an argument and/or for returning a value.

  • in

    An input Parameter (may not be modified).

  • out

    An output Parameter (may be modified to communicate information to the caller).

  • inout

    An input parameter that may be modified.

  • return

    A return value of a call.

Enumeration - ::Foundation::Data Types::PseudostateKind

In the metamodel, PseudostateKind defines an enumeration that discriminates the kind of Pseudostate.

  • choice

    Splits an incoming transition into several outgoing transitions. Each outgoing transition has a guard condition that is evaluated after prior actions on the incoming path have been completed. At least one outgoing transition must be enabled or the model is ill formed.

  • deepHistory

    When reached as the target of a transition, restores the full state configuration that was active just before the enclosing composite state was last exited.

  • fork

    Splits an incoming transition into several concurrent outgoing transitions. All of the transitions fire together.

  • initial

    The default target of a transition to the enclosing composite state.

  • join

    Merges transitions from concurrent regions into a single outgoing transition. All the transitions fire together.

  • junction

    Chains together transitions into a single run-to-completion path. May have multiple input and/or output transitions. Each complete path involving a junction is logically independent and only one such path fires at one time. May be used to construct branches and merges.

  • shallowHistory

    When reached as the target of a transition, restores the state within the enclosing composite state that was active just before the enclosing state was last exited. Does not restore any substates of the last active state.

Enumeration - ::Foundation::Data Types::ScopeKind

In the metamodel, ScopeKind defines an enumeration that denotes whether a feature belongs to individual instances or an entire classifier.

  • instance

    The feature pertains to Instances of a Classifier. For example, it is a distinct Attribute in each Instance or an Operation that works on an Instance.

  • classifier

    The feature pertains to an entire Classifier. For example, it is an Attribute shared by the entire Classifier or an Operation that works on the Classifier, such as a creation operation.

Enumeration - ::Foundation::Data Types::VisibilityKind

In the metamodel, VisibilityKind defines an enumeration that denotes how the element to which it refers is seen outside the enclosing name space.

  • public

    Other elements may see and use the target element.

  • protected

    Descendants of the source element may see and use the target element.

  • private

    Only the source element may see and use the target element.

  • package

    Elements declared in the same package as the target element may see and use the target element.

Class - ::Foundation::Data Types::ArgListsExpression

Extends: ::Foundation::Data Types::Expression

In the metamodel, ArgListsExpression defines a statement which will result in a set of object lists when it is evaluated.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::BooleanExpression

Extends: ::Foundation::Data Types::Expression

In the metamodel, BooleanExpression defines a statement that will evaluate to an instance of Boolean when it is evaluated.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::Expression

In the metamodel, an Expression defines a statement which will evaluate to a (possibly empty) set of instances when executed in a context. An Expression does not modify the environment in which it is evaluated. An expression contains an expression string and the name of an interpretation language with which to evaluate the string.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::Geometry

An uninterpreted type used to describe the geometrical shape of icons, such as those that may be attached to stereotypes. The details of this specification are not currently part of UML and must therefore be supplied by the implementation of a model editing tool, with the understanding that they will likely be tool-specific. This type is therefore not actually defined in the metamodel but is used only as the type of attributes.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::LocationReference

Designates a position within a behavior sequences for the insertion of an extension use case. May be a line or range of lines in code, or a state or set of states in a state machine, or some other means in a different kind of specification.

J.S. This should perhaps be a primitive type

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::Mapping

In the metamodel, a Mapping is an expression that is used for mapping ModelElements. For exchange purposes, it should be represented as a String.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::MappingExpression

Extends: ::Foundation::Data Types::Expression

An expression that evaluates to a mapping.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::Multiplicity

In the metamodel, a Multiplicity defines a non-empty set of non-negative integers. A set which only contains zero ({0}) is not considered a valid Multiplicity. Every Multiplicity has at least one corresponding String representation.

Properties:

Operations:

  • allows(i : ::Foundation::Data Types::Integer) : ::Foundation::Data Types::Boolean

    The allows operation takes an integer as input. It checks if a given integer cardinality is allowed by a multiplicity.

    Evaluates to: 

    -- original:
-- allows(i) = self.range->exists(r : MultiplicityRange |
-- 
--   r.contains(i)
-- )


-- errors:
-- semantic - 'allows(i) = ' syntax results in infinite
-- recursion

-- corrected:
self.range->exists(r : MultiplicityRange |

  r.contains(i)
)
  • compatibleWith(other : ::Foundation::Data Types::Multiplicity) : ::Foundation::Data Types::Boolean

    The operation compatibleWith takes another multiplicity as input. It checks if one multiplicity is compatible with another.

    Evaluates to: 

    -- original:
-- compatibleWith(other) =
--   Integer.allInstances()->forAll(i : Integer |
--
--   self.allows(i) implies other.allows(i)
-- )
  
-- errors:
-- semantic - 'compatibleWith(other) = ' syntax results in
-- infinite recursion
-- incompatibility - allInstances() not supported by OCL 2
-- incompatibility - allInstances() on Integer requires some
-- kind of intelligent lazy evaluation not implemented.

-- corrected:
let tightestLowerBound = 
  other.range->iterate(s : MultiplicityRange;
    tightest : MultiplicityRange =
      other.range->any(s | s.upper = -1) |
    
    if s.upper = -1
    then
      if s.lower < tightest.lower
      then s
      else tightest
      endif
    else tightest
    endif
  ).lower
in
self.range->forAll(r : MultiplicityRange |

  if r.upper = -1  then
    if other.upperbound() = -1 then
      
      other.lowerbound() >= tightestLowerBound
      or
      Sequence(Integer) { 
        
        r.lower .. tightestLowerBound
      }->forAll(i : Integer |
      
        other.allows(i)
      )              
    else
      false
    endif
  else
    Sequence(Integer) { 
      
      r.lower .. r.upper
    }->forAll(i : Integer |
    
      other.allows(i)
    )
  endif
)
  • lowerbound() : ::Foundation::Data Types::Integer

    The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity.

    Evaluates to: 

    -- original:
-- lowerbound = self.range->exists(r : MultiplicityRange |
--
--  r.lower = result
-- )
-- and self.range->forall(r : MultiplicityRange |
--   
--  r.lower <= result
-- )


-- errors:
-- parse - 'lowerbound = ' lowerbound not an attribute,
-- variable or type in this context
-- parse - type of body is boolean, not integer


-- corrected:    
self.range->any(r : MultiplicityRange |

  self.range->forall(s : MultiplicityRange |
  
    s.lower >= r.lower
  )
).lower
  • upperbound() : ::Foundation::Data Types::UnlimitedInteger

    The operation upperbound returns the highest upper bound of the ranges in a multiplicity.

    Evaluates to: 

    -- original:
--  upperbound = self.range->exists(r : MultiplicityRange |
--
--    r.upper = result
--  )
--  and self.range->forall(r : MultiplicityRange |
--
--    r.upper <= result
--  )

-- errors:
-- parse - 'upperbound = ' upperbound not an attribute,
-- variable or type in this context.
-- parse - type of body is boolean, not integer
-- incompatibility - encoding of UnlimitedInteger


-- corrected:
self.range->any(r : MultiplicityRange |


  r.upper = -1
  or
  self.range->forall(s : MultiplicityRange |
  
    s.upper <= r.upper
  )
).upper
  • is(lowerbound : ::Foundation::Data Types::Integer,
    upperbound : ::Foundation::Data Types::UnlimitedInteger) : ::Foundation::Data Types::Boolean

    The is operation determines if the upper and lower bound of the ranges are the ones given.

    Evaluates to: 

    -- original:
-- is(lowerbound, upperbound) =
-- (lowerbound = self.lowerbound 
-- and upperbound = self.upperbound)


-- semantic - 'is(lowerbound, upperbound) =' results in
-- infinite recursion.


-- corrected:
lowerbound = self.lowerbound() and
  upperbound = self.upperbound()

Invariants:

Class - ::Foundation::Data Types::MultiplicityRange

In the metamodel, a MultiplicityRange defines a range of integers. The upper bound of the range cannot be below the lower bound. The lower bound must be a nonnegative integer. The upper bound must be a nonnegative integer or the special value unlimited, which indicates there is no upper bound on the range.

Properties:

Operations:

  • contains(i : ::Foundation::Data Types::Integer) : ::Foundation::Data Types::Boolean

    The operation contains takes an integer as input and checks if a given integer is within the range specified by a multiplicity range.

    Evaluates to: 

    -- original:
-- contains(i) = (self.lower<=i and i<=self.upper)

-- errors:
-- semantic - 'contains(i) =' syntax results in infinite
-- left recursion. 
-- semantic - changed to accomodate encoding of
-- UnlimitedInteger

self.lower <= i
and
(
  i <= self.upper
  or
  self.upper = -1
)

Invariants:

Class - ::Foundation::Data Types::ProcedureExpression

Extends: ::Foundation::Data Types::Expression

In the metamodel, ProcedureExpression defines a statement that will result in a change to the values of its environment when it is evaluated.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::TimeExpression

Extends: ::Foundation::Data Types::Expression

In the metamodel, TimeExpression defines a statement that will define the time of occurrence of an event. The specific format of time expressions is not specified here and is subject to implementation considerations.

Properties:

Operations:

Invariants:

Class - ::Foundation::Data Types::TypeExpression

Extends: ::Foundation::Data Types::Expression

In the metamodel, TypeExpression is the encoding of a programming language type in the interpretation language. It is used within a ProgrammingLanguageDataType.

Properties:

Operations:

Invariants:

Primitive type - ::Foundation::Data Types::Boolean

In the metamodel, Boolean defines an enumeration that denotes a logicial condition.

Equivalent to the OCL boolean type.

Primitive type - ::Foundation::Data Types::Integer

In the metamodel, Integer is a classifier element that is an instance of Primitive, representing the predefined type of integers. An instance of Integer an element in the (infinite) set of integers (…-2, -1, 0, 1, 2...).

Equivalent to the OCL integer type.

Primitive type - ::Foundation::Data Types::Name

In the metamodel, a Name defines a token which is used for naming ModelElements. A name is represented as a String.

Equivalent to the OCL string type.

Primitive type - ::Foundation::Data Types::String

In the metamodel, String is a classifier element that is an instance of Primitive. An instance of String defines a piece of text.

Equivalent to the OCL string type.

Primitive type - ::Foundation::Data Types::UnlimitedInteger

In the metamodel, UnlimitedInteger is a classifier element that is an instance of Primitive. It defines a data type whose range is the nonnegative integers augmented by the special value "unlimited." It is used for the upper bound of multiplicities.

Equivalent to the OCL integer type.

Package - ::Foundation::Core

Class - ::Foundation::Core::Abstraction

Extends: ::Foundation::Core::Dependency

An abstraction is a Dependency relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional.

If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The situation is similar if there is more than one supplier element.

The UML standard stereotyped classes of Abstraction are Derivation, Realization, Refinement, and Trace. (These are the names for the Abstraction class with the stereotypes «derive», «realize», «refine», and «trace», respectively.)

Properties:

  • mapping : ::Foundation::Data Types::MappingExpression

    A MappingExpression that states the abstraction relationship between the supplier and the client. In some cases, such as Derivation, it is usually formal and unidirectional; in other cases, such as Trace, it is usually informal and bidirectional. The mapping attribute is optional and may be omitted if the precise relationship between the elements is not specified.

Operations:

Invariants:

Class - ::Foundation::Core::Artifact

Extends: ::Foundation::Core::Classifier

An Artifact represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component.

In the metamodel, an Artifact is a Classifier with an optional aggregation association to one or more Components. As a Classifier, Artifacts may have Features that represent properties of the Artifact (e.g., a “read-only” attribute or a “check in” operation). It should be noted that sometimes Artifacts may need to be linked to Classifiers directly, without introducing a ‘Component.’ For instance, in the context of code generation, the resulting Artifacts (source code files) are never deployed as Components. In that case, a «derive» Dependency can be used between the Classifier(s) and the generated Artifact.

The standard stereotypes of Artifact are «file», the subclasses of «file» («executable», «source», «library», and «document»), and «table». These stereotypes can be further subclassed into implementation and platform specific stereotypes (e.g., «jarFile» for Java archives).

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Association

Extends: ::Foundation::Core::Relationship,
::Foundation::Core::GeneralizableElement

An association defines a semantic relationship between classifiers. The instances of an association are a set of tuples relating instances of the classifiers. Each tuple value may appear at most once.

In the metamodel, an Association is a declaration of a semantic relationship between Classifiers, such as Classes. An Association has at least two AssociationEnds. Each end is connected to a Classifier - the same Classifier may be connected to more than one AssociationEnd in the same Association. The Association represents a set of connections among instances of the Classifiers. An instance of an Association is a Link, which is a tuple of Instances drawn from the corresponding Classifiers.

Properties:

Operations:

  • allConnections() : ::Foundation::Core::AssociationEnd[0, *] unique

    The operation allConnections results in the set of all AssociationEnds of the Association

    Evaluates to: 

    -- original:
-- allConnections = self.connection

-- errors:
-- parse - expression is of wrong type

-- Corrected:
connection->asSet()

Invariants:

  • [2] At most one AssociationEnd may be an aggregation or composition. 

    -- corrected:
self.allConnections()->select(


  aggregation =
    ::Foundation::"Data Types"::
      AggregationKind.aggregate
  or
  aggregation =
    ::Foundation::"Data Types"::
      AggregationKind.composite
)->size() <= 1
  • [3] If an Association has three or more AssociationEnds, then no AssociationEnd may be an aggregation or composition. 

    -- corrected:        
self.allConnections()->size() >= 3
implies
self.allConnections()->forAll(

  aggregation = 
    ::Foundation::"Data Types"::
      AggregationKind.none
)
  • [1] The AssociationEnds must have a unique name within the Association. 

    self.allConnections()->forAll(r1, r2 |

  r1.name = r2.name implies r1 = r2
)
  • [4] The connected Classifiers of the AssociationEnds should be included in the Namespace of the Association, or be Classifiers with public visibility in other Namespaces to which the Namespace of the Association has "access" Permissions. 

    -- original
-- self.allConnections()->forAll(r |
-- 
--   self.namespace.allContents()->includes(r.participant)
--   or
--   self.allConnections()->forAll(r |
--   
--     original
--     self.namespace.allContents->excludes(r.participant)
--     implies
--     self.namespace.clientDependency->exists(d |
--       d.oclIsTypeOf(Permission)
--       and
--       d.stereotype.name = "Access"
--       and
--       d.supplier.oclAsType(Namespace
--         ).ownedElement->select(e |
--         
--         e.elementOwnership.visibility =
--           ::Foundation::"Data Types"::
--            VisibilityKind.public
--         or
--         d.supplier.oclAsType(GeneralizableElement
--          ).allParents().oclAsType(Namespace
--          ).ownedElement->select(e |
--         
--           e.elementOwnership.visibility =
--             ::Foundation::"Data Types"::
--              VisibilityKind.public
--         )->includes(r.participant)
--         or
--         d.supplier.oclAsType(Package
--          ).allImportedElements()->select(e |
--         
--           e.elementImport.visibility =
--             ::Foundation::"Data Types"::
--              VisibilityKind.public
--         )->includes(r.participant)
--       )
--     )
--   )
-- )


-- errors
-- parse - wrong quotes on "Access"
-- incompatibility - elementOwnership.visibility is an
-- association class attribute, not supported by EMOF.

-- corrected:        
self.allConnections()->forAll(r |

  self.namespace.allContents()->includes(r.participant)
  or
  self.allConnections()->forAll(r |
  
    -- corrected
    self.namespace.allContents()->excludes(
      r.participant)
    implies
    self.namespace.clientDependency->exists(d |
      d.oclIsTypeOf(Permission)
      and
      d.stereotype->exists(s | s.name = 'Access')
    )
  )
)

Class - ::Foundation::Core::AssociationUMLClass

Extends: ::Foundation::Core::Class,
::Foundation::Core::Association

An association class is an association that is also a class. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not any of the classifiers.

JS: AssociationClass has been renamed AssociationUMLClass to avoid a name clash when the AssociationClass proxy for Association is generated in the JMI repository. This is a hack and should be fixed by improving name substitution in the JMI generator.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::AssociationEnd

Extends: ::Foundation::Core::ModelElement

An association end is an endpoint of an association, which connects the association to a classifier. Each association end is part of one association. The association-ends of each association are ordered.

In the metamodel, an AssociationEnd is part of an Association and specifies the connection of an Association to a Classifier. It has a name and defines a set of properties of the connection (e.g., which Classifier the Instances must conform to, their multiplicity, and if they may be reached from another Instance via this connection).

In the following descriptions when referring to an association end for a binary association, the source end is the other end. The target end is the one whose properties are being discussed.

Properties:

  • aggregation : ::Foundation::Data Types::AggregationKind

    When placed on one end (the “target” end), specifies whether the class on the target end is an aggregation with respect to the class on the other end (the “source”end). Only one end can be an aggregation. Possibilities are:

    • none - The target class is not an aggregate.

    • aggregate - The target class is an aggregate; therefore, the source class is a part and must have the aggregation value of none. The part may be contained in other aggregates.

    • composite - The target class is a composite; therefore, the source class is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other composite.

  • changeability : ::Foundation::Data Types::ChangeableKind

    Specifies whether or not links may be created or destroyed after the initialization of objects at the opposite ends. Possibilities are:

    • changeable - No restrictions on creation and destruction of links.

    • frozen - No links may be destroyed after the objects at the opposite ends have been initialized, and no new links may be created after the objects that would participate in the new link at the opposite ends have been initialized.

    • addOnly - No link may be destroyed after the objects at the opposite ends have been initialized. Links may be created anytime.

  • ordering : ::Foundation::Data Types::OrderingKind

    When placed on a target end, specifies whether the set of links from the source instance to the target instance is ordered. The ordering must be determined and maintained by Operations that add links. It represents additional information not inherent in the objects or links themselves.

    Possibilities are:

    • unordered - The links form a set with no inherent ordering.

    • ordered - A set of ordered links can be scanned in order.

    • Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools.

  • isNavigable : ::Foundation::Data Types::Boolean

    When placed on a target end, specifies whether traversal from a source instance to its associated target instances is possible. Specification of each direction across the Association is independent. A value of true means that the association can be navigated by the source class and the target rolename can be used in navigation expressions.

  • multiplicity : ::Foundation::Data Types::Multiplicity

    When placed on a target end, specifies the number of target instances that may be associated with a single source instance across the given Association.

  • targetScope : ::Foundation::Data Types::ScopeKind

    Specifies whether the target value is an instance or a classifier.

    Possibilities are:

    • instance. An instance value is part of each link. This is the default.

    • classifier. A classifier itself is part of each link. Normally this would be fixed at modeling time and need not be stored separately at run time.

  • qualifier : ::Foundation::Core::Attribute[0, *] ordered

    Opposite: ::Foundation::Core::Attribute.associationEnd : ::Foundation::Core::AssociationEnd[0, 1]

    An optional list of qualifier Attributes for the end. If the list is empty, then the Association is not qualified.

  • specification : ::Foundation::Core::Classifier[0, *]

    Opposite: ::Foundation::Core::Classifier.specifiedEnd : ::Foundation::Core::AssociationEnd[0, *]

    Designates zero or more Classifiers that specify the Operations that may be applied to an Instance accessed by the AssociationEnd across the Association. These determine the minimum interface that must be realized by the actual Classifier attached to the end to support the intent of the Association. May be an Interface or another Classifier. These classifiers do not indicate the classes of the participants in a link, merely the operations that may be applied when traversing a link.

  • participant : ::Foundation::Core::Classifier

    Opposite: ::Foundation::Core::Classifier.association : ::Foundation::Core::AssociationEnd[0, *]

    Designates the Classifier participating in the Association at the given end. A link of the Association contains a reference to an instance of the class (including a descendant of the given class or a class that realizes a given interface) in the given position in the link.

  • association : ::Foundation::Core::Association

    Opposite: ::Foundation::Core::Association.connection : ::Foundation::Core::AssociationEnd[2, *] unique ordered

    Designates the Association that owns the AssociationEnd.

Operations:

  • upperBound() : ::Foundation::Data Types::UnlimitedInteger

    The operation upperBound returns the maximum upperbound value across all potential ranges of a multiplicity.

    (rewritten from spec.)

    Evaluates to: 

    -- original:
-- self.range->iterate(
--   r : MultiplicityRange; upper : UnlimitedInteger = 0 |
--   
--   if upper = -1 or r = -1 then -1
--   else
--     r.upper.max(upper)
--   endif
-- )


-- corrected:
multiplicity.range->iterate(
  r : ::Foundation::"Data Types"::MultiplicityRange;
  upper :
    ::Foundation::"Data Types"::UnlimitedInteger = 0 |
  
  if upper = -1 or r = -1 then -1
  else
    r.upper.max(upper)
  endif
)

Invariants:

  • [2] An Instance may not belong by composition to more than one composite Instance. 

    self.aggregation =
  ::Foundation::"Data Types"::AggregationKind.composite
implies
upperBound() = 1
  • [1] The Classifier of an AssociationEnd cannot be an Interface or a DataType if the association is navigable away from that end. 

    (
  self.participant.oclIsKindOf(Interface)
  or
  self.participant.oclIsKindOf(DataType)
)
implies
self.association.connection->select(ae |

  ae <> self
)->forAll(ae |

  ae.isNavigable = false
)

Class - ::Foundation::Core::Attribute

Extends: ::Foundation::Core::StructuralFeature

An attribute is a named slot within a classifier that describes a range of values that instances of the classifier may hold.

In the metamodel, an Attribute is a named piece of the declared state of a Classifier, particularly the range of values that Instances of the Classifier may hold.

Properties:

Operations:

Invariants:

  • [1] Qualifier attributes have multiplicity of 1..1 

    -- original:
-- self.associationEnd->notEmpty()
-- implies
-- self.multiplicity.upperBound = 1
-- and
-- self.multiplicity.lowerBound = 1


-- errors:
-- parse - upperbound and lowerbound operations treated like
-- variables
-- type - associationEnd treated like collection

-- corrected:
(not self.associationEnd.oclIsUndefined())
implies
self.multiplicity.upperbound() = 1
and
self.multiplicity.lowerbound() = 1

Class - ::Foundation::Core::BehavioralFeature

Extends: ::Foundation::Core::Feature

A behavioral feature refers to a dynamic feature of a model element, such as an operation or method.

In the metamodel, a BehavioralFeature specifies a behavioral aspect of a Classifier. All different kinds of behavioral aspects of a Classifier, such as Operation and Method, are subclasses of BehavioralFeature. BehavioralFeature is an abstract metaclass.

Properties:

Operations:

  • hasSameSignature(b : ::Foundation::Core::BehavioralFeature) : ::Foundation::Data Types::Boolean

    The operation hasSameSignature checks if the argument has the same signature as the instance itself.

    Evaluates to: 

    self.name = b.name
and
self.parameter->size() = b.parameter->size()
and
Sequence(::Foundation::"Data Types"::Integer)
  { 1 .. self.parameter->size() }->forAll(
  index : ::Foundation::"Data Types"::Integer |
  
  b.parameter->at(index).type =
    self.parameter->at(index).type
  and
  b.parameter->at(index).kind =
    self.parameter->at(index).kind
)
  • matchesSignature(b : ::Foundation::Core::BehavioralFeature) : ::Foundation::Data Types::Boolean

    The operation matchesSignature checks if the argument has a signature that would clash with the signature of the instance itself (and therefore must be unique). Mismatches in kind or any differences in return parameters do not cause a mismatch.

    Evaluates to: 

    self.name = b.name
and
self.parameter->size() = b.parameter->size()
and
Sequence(::Foundation::"Data Types"::Integer)
  { 1 .. self.parameter->size() }->forAll(
  index : ::Foundation::"Data Types"::Integer |
  
  b.parameter->at(index).type =
    self.parameter->at(index).type
  or
  (
    b.parameter->at(index).kind = 
      ::Foundation::"Data Types"::
        ParameterDirectionKind.return
    and
    self.parameter->at(index).kind =
      ::Foundation::"Data Types"::
        ParameterDirectionKind.return
  )
)

Invariants:

  • [1] All Parameters should have a unique name. 

    self.parameter->forAll(p1, p2 |

  p1.name = p2.name
  implies
  p1 = p2
)
  • [2] The type of the Parameteres should be included in the Namespace of the Classifier. 

    self.parameter->forAll(p |

  self.owner.namespace.allContents()->includes(p.type)
)

Class - ::Foundation::Core::Binding

Extends: ::Foundation::Core::Dependency

A binding is a relationship between a template (as supplier) and a model element generated from the template (as client). It includes a list of arguments that match the template parameters. The template is a form that is cloned and modified by substitution to yield an implicit model fragment that behaves as if it were a direct part of the model. A Binding must have one supplier and one client; unlike a general Dependency, the supplier and client may not be sets.

In the metamodel, a Binding is a Dependency where the supplier is the template and the client is the instantiation of the template that performs the substitution of parameters of a template. A Binding has a list of arguments that replace the parameters of the supplier to yield the client. The client is fully specified by the binding of the supplier’s parameters and does not add any information of its own. An element may participate as a supplier in multiple Binding relationships to different clients. An element may participate in only one Binding relationship as a client.

Properties:

Operations:

Invariants:

  • [1] The client ModelElement must conform to the type of the supplier ModelElement in a Binding. 

    -- Original:
-- self.client.oclIsKindOf(self.supplier)

-- Errors:
-- parse - self.supplier, an object, is used as a 
-- meta-type
-- incompatibility - can't be expressed in OCL 2


-- Corrected:
true
  • [4] A Binding has one client and one supplier. 

    self.client->size() = 1
and
self.supplier->size() = 1
  • [5] A ModelElement may participate in at most one Binding as a client. 

    -- original:
-- Binding.allInstances()->forAll(b1, b2 |
--  b1 <> b2
--  implies
--  b1.client <> b2.client
-- )

-- errors:
-- incompatibility - uses allInstances()


-- corrected:
true
  • [2] Each argument ModelElement of the supplier must have the same type (or a descendant of the type) of the corresponding supplier parameter ModelElement in a Binding. 

    -- Original:
-- let range : Set(::Foundation::"Data Types"::Integer) =
--   Set(::Foundation::"Data Types"::Integer)
--     { 1..self.arguments->size()] }
-- in
-- range->forAll(index |
-- 
--   arguments->at(index).oclIsKindOf(
--   
--     supplier.templateParameter->at(index).oclType
--   )
-- )

-- Errors:
-- parse - self.arguments should be self.argument
-- incompatibility - can't be expressed in OCL 2 as can't
-- access the type of an element.


-- Corrected:
true
  • [3] The number of arguments must equal the number of parameters. 

    -- Original:
-- self.arguments->size() =
--  self.supplier.templateParameter->size()


-- Errors:
-- parse - self.arguments should be self.argument


-- Corrected:
self.argument->size() =
  self.supplier.templateParameter->size()

Class - ::Foundation::Core::Class

Extends: ::Foundation::Core::Classifier

A class is a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.

In the metamodel, a Class describes a set of Objects sharing a collection of Features, including Operations, Attributes, and Methods that are common to the set of Objects. Furthermore, a Class may realize zero or more Interfaces; this means that its full descriptor (see “Inheritance” on page 2-69 for the definition) must contain every Operation from every realized Interface (it may contain additional operations as well). A Class defines the data structure of Objects, although some Classes may be abstract (i.e., no Objects can be created directly from them). Each Object instantiated from a Class contains its own set of values corresponding to the StructuralFeatures declared in the full descriptor. Objects do not contain values corresponding to BehavioralFeatures or class-scope Attributes; all Objects of a Class share the definitions of the BehavioralFeatures from the Class, and they all have access to the single value stored for each class-scope attribute.

Properties:

  • isActive : ::Foundation::Data Types::Boolean

    Specifies whether an Object of the Class maintains its own thread of control. If true, then an Object has its own thread of control and runs concurrently with other active Objects. Such a class is informally called an active class. If false, then Operations run in the address space and under the control of the active Object that controls the caller. Such a class is informally called a passive class.

Operations:

Invariants:

  • [1] If a Class is concrete, all the Operations of the Class should have a realizing Method in the full descriptor. 

    -- Original:        
-- not self.isAbstract
-- implies
-- self.allOperations->forAll(op |
--   
--   self.allMethods->exists(m |
--   
--     m.specification->includes(op)
--   )
-- )

-- Errors:
-- parse - allOperations treated as attribute
-- parse - allMethods treated as attribute
-- parse - specification treated as collection

-- Corrected:
not self.isAbstract
implies
self.allOperations()->forAll(op |
  
  self.allMethods()->exists(m |
  
    m.specification = op
  )
)
  • [2] A Class can only contain Classes, Associations, Generalizations, UseCases, Constraints, Dependencies, Collaborations, "Data Types", and Interfaces as a Namespace. 

    -- Original:
-- self.allContents()->forAll(c |
-- 
--   c.oclIsKindOf(Class)
--   or
--   c.oclIsKindOf(Association)
--   or
--   c.oclIsKindOf(Generalization)
--   or
--   c.oclIsKindOf(UseCase)
--   or
--   c.oclIsKindOf(Constraint)
--   or
--   c.oclIsKindOf(Dependency)
--   or
--   c.oclIsKindOf(Collaboration)
--   or
--   c.oclIsKindOf(DataType)
--   or
--   c.oclIsKindOf(Interface)
-- )

-- Errors:
-- parse - UseCase not properly qualified
-- parse - Collaboration not properly qualified

self.allContents()->forAll(c |

  c.oclIsKindOf(Class)
  or
  c.oclIsKindOf(Association)
  or
  c.oclIsKindOf(Generalization)
  or
  c.oclIsKindOf(
    ::"Behavioral Elements"::"Use Cases"::UseCase)
  or
  c.oclIsKindOf(Constraint)
  or
  c.oclIsKindOf(Dependency)
  or
  c.oclIsKindOf(::"Behavioral Elements"::Collaborations::
    Collaboration)
  or
  c.oclIsKindOf(DataType)
  or
  c.oclIsKindOf(Interface)
)

Class - ::Foundation::Core::Classifier

Extends: ::Foundation::Core::GeneralizableElement,
::Foundation::Core::Namespace

A classifier is an element that describes behavioral and structural features; it comes in several specific forms, including class, data type, interface, component, artifact, and others that are defined in other metamodel packages.

In the metamodel, a Classifier declares a collection of Features, such as Attributes, Methods, and Operations. It has a name, which is unique in the Namespace enclosing the Classifier. Classifier is an abstract metaclass.

Classifier is a child of GeneralizableElement and Namespace. As a GeneralizableElement, it may inherit Features and participation in Associations (in addition to things inherited as a ModelElement). It also inherits ownership of StateMachines, Collaborations, etc.

As a Namespace, a Classifier may declare other Classifiers nested in its scope. Nested Classifiers may be accessed by other Classifiers only if the nested Classifiers have adequate visibility. There are no data value or state consequences of nested Classifiers (i.e., it is not an aggregation or composition).

Properties:

Operations:

  • allFeatures() : ::Foundation::Core::Feature[0, *] unique

    The operation allFeatures results in a Set containing all Features of the Classifier itself and all its inherited Features.

    Evaluates to: 

    -- Original:        
-- self.feature->union(
-- 
--   self.parent.oclAsType(Classifier).allFeatures()
-- )


-- Errors:
-- parse - self.parent not supported by Classifier


-- Corrected:
self.feature->asSet()->union(

  self.generalization.parent.oclAsType(
    Classifier).allFeatures()
)->asSet()
  • allOperations() : ::Foundation::Core::Operation[0, *] unique

    The operation allOperations results in a Set containing all Operations of the Classifier itself and all its inherited Operations.

    Evaluates to: 

    -- Original:
-- self.allFeatures()->select(f | f.oclIsKindOf(Operation))

-- Errors:
-- parse - type of select statement is Set(Feature),
-- not Set(Operation)

-- Corrected:
self.allFeatures()->select(f |

  f.oclIsKindOf(Operation)
).oclAsType(Operation)->asSet()
  • allMethods() : ::Foundation::Core::Method[0, *] unique

    The operation allMethods results in a Set containing all Methods of the Classifier itself and all its inherited Methods.

    Evaluates to: 

    -- Original:
-- self.allFeatures()->select(f | f.oclIsKindOf(Method))


-- Errors:
-- parse - type of select statement is Set(Feature),
-- not Set(Method)


-- Corrected:
self.allFeatures()->select(f |

  f.oclIsKindOf(Method)
).oclAsType(Method)->asSet()
  • allAttributes() : ::Foundation::Core::Attribute[0, *] unique

    The operation allAttributes results in a Set containing all Attributes of the Classifier and all its inherited Attributes.

    Evaluates to: 

    -- Original:
-- self.allFeatures()->select(f | f.oclIsKindOf(Attribute))


-- Errors:
-- parse - type of select statement is Set(Feature),
-- not Set(Attribute)

-- Corrected:
self.allFeatures()->select(f | 

  f.oclIsKindOf(Attribute)
).oclAsType(Attribute)->asSet()
  • associations() : ::Foundation::Core::Association[0, *] unique

    The operation associations results in a Set containing all Associations of the Classifier itself.

    Evaluates to: 

    self.association.association->asSet()
  • allAssociations() : ::Foundation::Core::Association[0, *] unique

    The operation allAssociations results in a Set containing all Associations of the Classifier itself and all inherited Associations.

    Evaluates to: 

    -- Original:
-- self.associations()->union(
-- 
--   self.parent.oclAsType(Classifier).allAssociations()
-- )

-- Errors:
-- parse - self.parent not defined on Classifier

-- Corrected:
self.associations()->union(

  self.generalization.parent.oclAsType(
    Classifier).allAssociations()
)->asSet()
  • oppositeAssociationEnds() : ::Foundation::Core::AssociationEnd[0, *] unique

    The operation oppositeAssociationEnds results in a set of all AssociationEnds that are opposite to the Classifier.

    Evaluates to: 

    self.associations()->select(a |

  a.connection->select(ae |
  
    ae.participant = self
  )->size() = 1
)->collect(a |

  a.connection->select(ae | ae.participant <> self)
)->union(

  self.associations()->select(a |
  
    a.connection->select(ae |
    
      ae.participant = self
    )->size() > 1
  )->collect(a |
  
    a.connection
  )
)->asSet()

Invariants:

  • [6] For each Operation in a specification realized by the Classifier, the Classifier must have a matching Operation. 

    -- Original:
-- self.specification.allOperations()->forAll(
--   interOp |
-- 
--   self.allOperations()->exists(op |
--   
--     op.hasMatchingSignature(interOp)
--   )
-- )

-- Errors:
-- parse - Attribute 'specification' not supported by
-- type Classifier.

-- Corrected:
true

-- Comment:
-- This invariant seems to make sense when describing
-- interfaces implemented by types, but has no clear
-- correspondance to the meta-model.
  • [7] All of the generalizations in the range of a powertype have the same discriminator. 

    self.powertypeRange->forAll(g1, g2 |

  g1.discriminator = g2.discriminator
)
  • [3] No opposite AssociationEnds may have the same name within a Classifier. 

    -- Original:      
-- self.allOppositeAssociationEnds()->forAll(p, q |
-- 
--   p.name = q.name
--   implies
--   p = q
-- )


-- Errors:
-- parse - allOppositeAssociationEnds() is actually called
-- oppositeAssociationEnds()

-- Corrected:
self.oppositeAssociationEnds()->forAll(p, q |

  p.name = q.name
  implies
  p = q
)
  • [4] The name of an Attribute may not be the same as the name of an opposite AssociationEnd or a ModelElement contained in the Classifier. 

    -- Original:
-- self.feature->select(a |
-- 
--   a.oclIsKindOf(Attribute)
-- )->forAll( a |
-- 
--   not self.allOppositeAssociationEnds()->union(
--   
--     self.allContents()
--   )->collect( q |
--   
--     q.name
--   )->includes(a.name)
-- )

-- Errors:
-- parse - allOppositeAssociationEnds() actually called
-- oppositeAssociationEnd()
-- parse - self.allContents() does not conform to type of
-- self.oppositeAssociationEnds()

-- Corrected:
self.feature->select(a |

  a.oclIsKindOf(Attribute)
)->forAll( a |

  not self.allContents()->union(
  
    self.oppositeAssociationEnds()
  )->collect( q |
  
    q.name
  )->includes(a.name)
)
  • [1] No BehaviouralFeature of the same kind may match the same signature in a Classifier. 

    -- Original:
-- self.feature->forAll(f, g |
-- 
--   (
--     (
--       f.oclIsKindOf(Operation)
--       and
--       g.oclIsKindOf(Operation))
--     or
--     (f.oclIsKindOf(Method) and g.oclIsKindOf(Method))
--     or
--     (
--       f.oclIsKindOf(::"Behavioral Elements"::
--         "Common Behavior"::Reception) 
--       and 
--       g.oclIsKindOf(::"Behavioral Elements"::
--         "Common Behavior"::Reception)
--     )
--   )
--   and
--   f.oclAsType(BehavioralFeature).matchesSignature(g)
--   implies
--   f = g
-- )

-- Errors:
-- parse - can't resolve matchesSignature(Feature)
-- need to cast to BehaviouralFeature

self.feature->forAll(f, g |

  (
    (
      f.oclIsKindOf(Operation)
      and
      g.oclIsKindOf(Operation))
    or
    (f.oclIsKindOf(Method) and g.oclIsKindOf(Method))
    or
    (
      f.oclIsKindOf(::"Behavioral Elements"::
        "Common Behavior"::Reception) 
      and 
      g.oclIsKindOf(::"Behavioral Elements"::
        "Common Behavior"::Reception)
    )
  )
  and
  f.oclAsType(BehavioralFeature).matchesSignature(
    g.oclAsType(BehavioralFeature))
  implies
  f = g
)
  • [2] No attributes may have the same name within a Classifier 

    self.feature->select(a | a.oclIsKindOf(Attribute))->forAll(
  p, q |
  
  p.name = q.name
  implies
  p = q
)
  • [5] The name of an opposite AssociationEnd may not be the same as the name of an Attribuet or a ModelElement contained in the Classifier. 

    -- Original:
-- self.oppositeAssociationEnds()->forAll(o |
-- 
--   not self.allAttributes()->union(
--     
--     self.allContents()
--   )->collect(q |
--   
--     q.name
--   )->includes(o.name)
-- )


-- Errors:
-- parse - allOppositeAssociationEnds() actually called
-- oppositeAssociationEnd()
-- parse - self.allContents() does not conform to type of
-- self.allAttributes()


-- Corrected:
self.oppositeAssociationEnds()->forAll(o |

  not self.allContents()->union(
    
    self.allAttributes()
  )->collect(q |
  
    q.name
  )->includes(o.name)
)
  • [8] Discriminator names must be distinct from attribute names and opposite AssociationEnd names. 

    -- Original:
-- self.allDiscriminators().name->intersection(
-- 
--   self.allAttributes().name->union(
--   
--     self.allOppositeAssociationEnds.name
--   
--   )
-- )->isEmpty()


-- Errors:
-- parse - self.allDiscriminators() not defined
-- parse - allOppositeAssociationEnds actually an operation
-- called oppositeAssociationEnds()

-- Corrected
self.powertypeRange.discriminator->intersection(

  self.allAttributes().name->union(
  
    self.oppositeAssociationEnds().name
  
  )
)->isEmpty()

Class - ::Foundation::Core::Comment

Extends: ::Foundation::Core::ModelElement

A comment is an annotation attached to a model element or a set of model elements. It has no semantic force but may contain information useful to the modeler.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Component

Extends: ::Foundation::Core::Classifier

A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.

A component is typically specified by one or more classifiers that reside on the component. A subset of these classifiers explicitly define the component’s external interfaces. A component conforms to the interfaces that it exposes, where the interfaces represent services provided by elements that reside on the component. A component may be implemented by one or more artifacts, such as binary, executable, or script files. A component may be deployed on a node.

Components may be specified in both design models (e.g., using static structure diagrams) and in implementation models (e.g., using implementation diagrams). When they are specified as part of a design model components need not be allocated to nodes, nor do they need to have any associated implementation artifacts.

In the metamodel, a Component is a child of Classifier. It does not have its own Features, but instead acts as a container for other Classifiers that have Features. A Component is specified by the Interfaces is exposes and the Classifiers that reside on it. The visibility attribute of the ElementResidence association defines whether a resident element is visible outside the Component: an external Interface of a Component has visibility value 'public'. A Component may be implemented by one or more Artifacts, and may be deployed on a Node.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Constraint

Extends: ::Foundation::Core::ModelElement

A constraint is a semantic condition or restriction expressed in text.

In the metamodel, a Constraint is a BooleanExpression on an associated ModelElement(s), which must be true for the model to be well formed. This restriction can be stated in natural language, or in different kinds of languages with a well defined semantics. Certain Constraints are predefined in the UML, others may be user defined.

Note that a Constraint is an assertion, not an executable mechanism. It indicates a restriction that must be enforced by correct design of a system.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::DataType

Extends: ::Foundation::Core::Classifier

A data type is a type whose values have no identity (i.e., they are pure values). Data types include primitive built-in types (such as integer and string) as well as definable enumeration types (such as the predefined enumeration type boolean whose literals are false and true).

In the metamodel, a DataType defines a special kind of Classifier in which Operations are all pure functions (i.e., they can return DataValues but they cannot change DataValues, because they have no identity). For example, an “add” operation on a number with another number as an argument yields a third number as a result; the target and argument are unchanged.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Dependency

Extends: ::Foundation::Core::Relationship

A term of convenience for a Relationship other than Association, Generalization, Flow, or metarelationship (such as the relationship between a Classifier and one of its Instances).

A dependency states that the implementation or functioning of one or more elements requires the presence of one or more other elements.

In the metamodel, a Dependency is a directed relationship from a client (or clients) to a supplier (or suppliers) stating that the client is dependent on the supplier (i.e., the client element requires the presence and knowledge of the supplier element). The kinds of Dependency are Abstraction, Binding, Permission, and Usage. Various stereotypes of those elements are predefined.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Element

An element is an atomic constituent of a model.

In the metamodel, an Element is the top metaclass in the metaclass hierarchy. It has two subclasses: ModelElement and PresentationElement. Element is an abstract metaclass.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Enumeration

Extends: ::Foundation::Core::DataType

In the metamodel, Enumeration defines a kind of DataType whose range is a list of predefined values, called enumeration literals.

Enumeration literals can be copied, stored as values, and passed as arguments. They are ordered within their enumeration datatype. An enumeration literal can be compared for an exact match or to a range within its enumeration datatype. There is no other algebra defined on them (e.g., they cannot be added or subtracted).

The run-time instances of a Primitive dataype are Values. Each such value corresponds to exactly one EnumerationLiteral defined as part of the Enumeration type itself. An Enumeration may have operations, but they must be pure functions (this is the rule for all DataType elements).

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::EnumerationLiteral

Extends: ::Foundation::Core::ModelElement

An EnumerationLiteral defines an element of the run-time extension of an Enumeration data type. It has no relevant substructure, that is, it is atomic. The enumeration literals of a particular Enumeration datatype are ordered. It has a name (inherited from ModelElement) that can be used to identify it within its enumeration dataype.

Note that an EnumerationLiteral is a ModelElement and may appear in (M1) models to define the structure of an Enumeration. In a run-time (M0) system, enumeration literals are DataValues in many-to-one correspondence to EnumerationLiterals that they represent. (This is a subtle but necessary distinction between M1 and M0 entities.) The run-time values corresponding to enumeration literals can be compared for equality and for relative ordering or inclusion in a range of enumeration literals.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Feature

Extends: ::Foundation::Core::ModelElement

A feature is a property, like operation or attribute, which is encapsulated within a Classifier.

In the metamodel, a Feature declares a behavioral or structural characteristic of an Instance of a Classifier or of the Classifier itself. Feature is an abstract metaclass.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Flow

Extends: ::Foundation::Core::Relationship

A flow is a relationship between two versions of an object or between an object and a copy of it.

In the metamodel, a Flow is a child of Relationship. A Flow is a directed relationship from a source or sources to a target or targets.

Predefined stereotypes of Flow are «become» and «copy». Become relates one version of an object to another with a different value, state, or location. Copy relates an object to another object that starts as a copy of it.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::GeneralizableElement

Extends: ::Foundation::Core::ModelElement

A generalizable element is a model element that may participate in a generalization relationship.

In the metamodel, a GeneralizableElement can be a generalization of other GeneralizableElements (i.e., all Features defined in and all ModelElements contained in the ancestors are also present in the GeneralizableElement). GeneralizableElement is an abstract metaclass.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Generalization

Extends: ::Foundation::Core::Relationship

A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element (it has all of its properties, members, and relationships) and may contain additional information.

In the metamodel, a Generalization is a directed inheritance relationship, uniting a GeneralizableElement with a more general GeneralizableElement in a hierarchy. Generalization is a subtyping relationship (i.e., an Instance of the more general GeneralizableElement may be substituted by an Instance of the more specific GeneralizableElement). See Inheritance for the consequences of Generalization relationships.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Interface

Extends: ::Foundation::Core::Classifier

An interface is a named set of operations that characterize the behavior of an element. In the metamodel, an Interface contains a set of Operations that together define a service offered by a Classifier realizing the Interface. A Classifier may offer several services, which means that it may realize several Interfaces, and several Classifiers may realize the same Interface.

Interfaces are GeneralizableElements.

Interfaces may not have Attributes, Associations, or Methods. An Interface may participate in an Association provided the Interface cannot see the Association; that is, a Classifier (other than an Interface) may have an Association to an Interface that is navigable from the Classifier but not from the Interface.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Method

Extends: ::Foundation::Core::BehavioralFeature

A method is the implementation of an operation. It specifies the algorithm or procedure that effects the results of an operation.

In the metamodel, a Method is a declaration of a named piece of behavior in a Classifier and realizes one (directly) or a set (indirectly) of Operations of the Classifier. There may be at most one method for a particular classifier (as owner of the method) and operation (as specification of the method) pairing.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::ModelElement

Extends: ::Foundation::Core::Element

A model element is an element that is an abstraction drawn from the system being modeled. Contrast with view element, which is an element whose purpose is to provide a presentation of information for human comprehension.

In the metamodel, a ModelElement is a named entity in a Model. It is the base for all modeling metaclasses in the UML (even though it is not displayed explicitly as such on diagrams for ElementOwnership, ElementResidence, ElementImport, TemplateParameter, TemplateArgument, and Argument). All other modeling metaclasses are either direct or indirect subclasses of ModelElement. Each ModelElement can be regarded as a template. A template has a set of templateParameters that denotes which of the parts of a ModelElement are the template parameters. A ModelElement is a template when there is at least one template parameter. If it is not a template, a ModelElement cannot have template parameters. However, such embedded parameters are not usually complete and need not satisfy well-formedness rules. It is the arguments supplied when the template is instantiated that must be well formed.

Partially instantiated templates are allowed. This is the case when there are arguments provided for some, but not all templateParameters. A partially instantiated template is still a template, since it still has parameters.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Namespace

Extends: ::Foundation::Core::ModelElement

A namespace is a part of a model that contains a set of ModelElements each of whose names designates a unique element within the namespace.

In the metamodel, a Namespace is a ModelElement that can own other ModelElements, like Associations and Classifiers. The name of each owned ModelElement must be unique within the Namespace. Moreover, each contained ModelElement is owned by at most one Namespace. The concrete subclasses of Namespace have additional constraints on which kind of elements may be contained. Namespace is an abstract metaclass.

Note that explicit parts of a model element, such as the features of a Classifier, are not modeled as owned elements in a namespace. A namespace is used for unstructured contents such as the contents of a package or a class declared inside the scope of another class.

Properties:

Operations:

  • allContents() : ::Foundation::Core::ModelElement[0, *] unique

    The operation allContents results in a Set containing all ModelElements contained by the Namespace.

    Evaluates to: 

    -- Original:
-- allContents = self.contents


-- Errors:
-- parse - allContents not supported by namespace (attempt
-- to assign value of operation)

-- Corrected:          
self.contents

Invariants:

  • [1] If a contained element, which is not an Association or Generalization has a name, then the name must be unique in the Namespace. 

    -- Original:
-- self.allContents->forAll(me1, me2 : ModelElement |
-- 
--   (
--     not me1.oclIsKindOf (Association)
--     and 
--     not me2.oclIsKindOf (Association)
--     and
--     me1.name <> ''
--     and
--     me2.name <> ''
--     and
--     me1.name = me2.name
--   )
--   implies
--   me1 = me2
-- )

-- Errors:
-- parse - allContents referenced as property not operation

-- Corrected:
self.allContents()->forAll(me1, me2 : ModelElement |

  (
    not me1.oclIsKindOf (Association)
    and 
    not me2.oclIsKindOf (Association)
    and
    me1.name <> ''
    and
    me2.name <> ''
    and
    me1.name = me2.name
  )
  implies
  me1 = me2
)
  • [2] All Associations must have a unique combination of name and associated Classifiers in the Namespace. 

    -- Original:
-- self.allContents->select(
-- 
--   oclIsKindOf(Association)
-- )->forAll(a1, a2 |
-- 
--   a1.name = a2.name
--   and
--   a1.connection.participant = a2.connection.participant
--   implies
--   a1 = a2
-- )

-- Errors:
-- parse - allContents treated as attribute
-- parse - connection is not a property of ModelElement,
-- need a cast.

-- Corrected:
self.allContents()->select(

  oclIsKindOf(Association)
).oclAsType(Association)->forAll(a1, a2 |

  a1.name = a2.name
  and
  a1.connection.participant = a2.connection.participant
  implies
  a1 = a2
)

Class - ::Foundation::Core::Node

Extends: ::Foundation::Core::Classifier

A node is a run-time physical object that represents a computational resource, generally having at least a memory and often processing capability as well, and upon which components may be deployed.

In the metamodel, a Node is a subclass of Classifier. It is associated with a set of Components that are deployed on the Node.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Operation

Extends: ::Foundation::Core::BehavioralFeature

An operation is a service that can be requested from an object to effect behavior. An operation has a signature, which describes the actual parameters that are possible (including possible return values).

In the metamodel, an Operation is a BehavioralFeature that can be applied to the Instances of the Classifier that contains the Operation.

Properties:

  • concurrency : ::Foundation::Data Types::CallConcurrencyKind

    Specifies the semantics of concurrent calls to the same passive instance (i.e., an Instance originating from a Classifier with isActive=false). Active instances control access to their own Operations so this property is usually (although not required in UML) set to sequential.

    Possibilities include:

    • sequential - Callers must coordinate so that only one call to an Instance (on any sequential Operation) may be outstanding at once. If simultaneous calls occur, then the semantics and integrity of the system cannot be guaranteed.

    • guarded - Multiple calls from concurrent threads may occur simultaneously to one Instance (on any guarded Operation), but only one is allowed to commence. The others are blocked until the performance of the first Operation is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks. Guarded Operations must perform correctly (or block themselves) in the case of a simultaneous sequential Operation or guarded semantics cannot be claimed.

    • concurrent - Multiple calls from concurrent threads may occur simultaneously to one Instance (on any concurrent Operation). All of them may proceed concurrently with correct semantics. Concurrent Operations must perform correctly in the case of a simultaneous sequential or guarded Operation or concurrent semantics cannot be claimed.

  • isAbstract : ::Foundation::Data Types::Boolean

    If true, then the operation does not have an implementation, and one must ve supplied by a descendant. If false, the operation must have an implementation in the class or inherited from an ancestor.

  • isLeaf : ::Foundation::Data Types::Boolean

    If true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden).

  • isRoot : ::Foundation::Data Types::Boolean

    If true, then the class must not inherit a declaration of the same operation. If false, then the class may (but need not) inherit a declaration of the same operation. (But the declaration must match in any case; a class may not modify an inherited operation declaration.)

  • specification : ::Foundation::Data Types::String

    Not documented in spec!

  • method : ::Foundation::Core::Method[0, *]

    Opposite: ::Foundation::Core::Method.specification : ::Foundation::Core::Operation

    Not documented in spec!

  • occurence : ::Behavioral Elements::State Machines::CallEvent[0, *]

    Opposite: ::Behavioral Elements::State Machines::CallEvent.operation : ::Foundation::Core::Operation

    Not documented in spec!

    from ::"Behavioral Elements"::"State Machines"::CallEvent, pg. 2-142

Operations:

Invariants:

Class - ::Foundation::Core::Parameter

Extends: ::Foundation::Core::ModelElement

A parameter is an unbound variable that can be changed, passed, or returned. A parameter may include a name, type, and direction of communication. Parameters are used in the specification of operations, messages and events, templates, etc.

In the metamodel, a Parameter is a declaration of an argument to be passed to, or returned from, an Operation, a Signal, etc.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Permission

Extends: ::Foundation::Core::Dependency

Permission is a kind of dependency. It grants a model element permission to access elements in another namespace.

In the metamodel, Permission in a Dependency between a client ModelElement and a supplier ModelElement. The client receives permission to reference the supplier’s contents. The supplier must be a Namespace.

The predefined stereotypes of Permission are access, import, and friend. In the case of the access and import stereotypes, the client is granted permission to reference elements in the supplier namespace with public visibility. In the case of the import stereotype, the public names in the supplier namespace are added to the client namespace. An element may also access any protected contents of an ancestor namespace. An element may also access any contents (public, protected, private, or package) of its own namespace or a containing namespace.

In the case of the friend stereotype, the client is granted permission to reference elements in the supplier namespace, regardless of visibility.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::PresentationElement

Extends: ::Foundation::Core::Element

A presentation element is a textual or graphical presentation of one or more model elements.

In the metamodel, a PresentationElement is an Element which presents a set of ModelElements to a reader. It is the base for all metaclasses used for presentation. All other metaclasses with this purpose are either direct or indirect subclasses of PresentationElement. PresentationElement is an abstract metaclass. The subclasses of this class are proper to a graphic editor tool and are not specified here. It is a stub for their future definition.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Primitive

Extends: ::Foundation::Core::DataType

A Primitive defines a predefined DataType, without any relevant UML substructure (i.e., it has no UML parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. Primitive datatypes used in UML itself include Integer, UnlimitedInteger, and String.

The run-time instances of a Primitive dataype are DataValues. The values are in many-to-one correspondence to mathemetical elements defined outside of UML (for example, the various integers).

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::ProgrammingLanguageDataType

Extends: ::Foundation::Core::DataType

A data type is a type whose values have no identity (i.e., they are pure values). A programming language data type is a data type specified according to the semantics of a particular programming language, using constructs available in that language. There are a wide variety of programming languages and many of them include type constructs not included as UML classifiers. In some cases, it is important to represent those constructs such that their exact form in the programming language is available.

The ProgrammingLanguagedData type captures such programming language types in a language-dependent fashion. They are represented by the name of the language and a string characterizing them, subject to interpretation by the particular language. Because they are dependent on particular languages, they are not portable among languages (except by agreement among the languages) and they do not map into other UML classifiers. Their semantics is therefore opaque within UML except by special interpretation by a profile intended for the particular language. Note that many or most programming language types can be directly represented using other UML classifiers, and such representation makes available deeper semantic analysis.

A ProgrammingLanguageDataType may omit its name. Two ProgrammingLanguageDataType elements without names are not considered equivalent.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Relationship

Extends: ::Foundation::Core::ModelElement

A relationship is a connection among model elements.

In the metamodel, Relationship is a term of convenience without any specific semantics. It is abstract.

Children of Relationship are Association, Dependency, Flow, and Generalization.

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::StructuralFeature

Extends: ::Foundation::Core::Feature

A structural feature refers to a static feature of a model element, such as an attribute. In the metamodel, a StructuralFeature declares a structural aspect of an Instance of a Classifier, such as an Attribute. For example, it specifies the multiplicity and changeability of the StructuralFeature. StructuralFeature is an abstract metaclass.

Properties:

  • changeability : ::Foundation::Data Types::ChangeableKind

    Whether the value may be modified after the object is initialized.

    Possibilities are: • changeable - No restrictions on modification.

    • frozen - No values may be added or removed after the object is initialized.

    • addOnly - Values may be added anytime. No values may be removed after the object is initialized.

  • multiplicity : ::Foundation::Data Types::Multiplicity

    The possible number of data values for the feature that may be held by an instance. The cardinality of the set of values is an implicit part of the feature. In the common case in which the multiplicity is 1..1, then the feature is a scalar (i.e., it holds exactly one value).

  • ordering : ::Foundation::Data Types::OrderingKind

    Specifies whether the set of instances is ordered. The ordering must be determined and maintained by Operations that add values to the feature. This property is only relevant if the multiplicity is greater than one.

    Possibilities are:

    • unordered - The instances form a set with no inherent ordering.

    • ordered - A set of ordered instances can be scanned in order.

    • Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools.

  • targetScope : ::Foundation::Data Types::ScopeKind

    Specifies whether the targets are ordinary Instances or Classifiers.

    Possibilities are: • instance - Each value contains a reference to an Instance of the target Classifier. This is the setting for a normal Attribute.

    • classifier - Each value contains a reference to the target Classifier itself. This represents a way to store meta-information.

  • type : ::Foundation::Core::Classifier

    Designates the classifier whose instances are values of the feature. Must be a Class, Interface, or DataType. The actual type may be a descendant of the declared type or (for an Interface) a Class that realizes the declared type.

Operations:

Invariants:

Class - ::Foundation::Core::TemplateArgument

Reifies the relationship between a Binding and one of its arguments (a ModelElement).

Properties:

Operations:

Invariants:

Class - ::Foundation::Core::Usage

Extends: ::Foundation::Core::Dependency

A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. The relationship is not a mere historical artifact, but an ongoing need; therefore, two elements related by usage must be in the same model.

In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier. How the client uses the supplier, such as a class calling an operation of another class, a method having an argument of another class, and a method from a class instantiating another class, is defined in the description of the particular Usage stereotype.

Various stereotypes of Usage are predefined, but the set is open-ended and may be added to.

Properties:

Operations:

Invariants:

Package - ::Foundation::Extension Mechanisms

Class - ::Foundation::Extension Mechanisms::Stereotype

Extends: ::Foundation::Core::GeneralizableElement

The stereotype concept provides a way of branding (classifying) model elements so that they behave in some respects as if they were instances of new virtual metamodel constructs. These model elements have the same structure (attributes, associations, operations) as similar non-stereotyped model elements of the same kind. The stereotype may specify additional constraints and tag definitions that apply to model elements. In addition, a stereotype may be used to indicate a difference in meaning or usage between two model elements with identical structure.

In the metamodel, the Stereotype metaclass is a subclass of GeneralizableElement. Tag definitions and constraints attached to a stereotype apply to all model elements branded by that stereotype. A stereotype may also specify a geometrical icon to be used for presenting elements with the stereotype.

If a stereotype is a subclass of another stereotype, then it inherits all of the constraints and tagged values from its stereotype supertype and it must apply to the same kind of base class. A stereotype keeps track of the base class to which it may be applied. Stereotypes are typically grouped in a Profile package.

Properties:

Operations:

  • findProfile(me : ::Foundation::Core::ModelElement) : ::Model Management::Package[0, *] unique

    The find profile operation returns either the single-element set containing profile package in which the model element is defined or an empty set if the element is not contained in any profile.

    Evaluates to: 

    -- Original:
-- if (me.namespace->notEmpty)
-- then
--   if (me.namespace.oclIsKindOf(Package) and
--     me.namespace.stereotype->notEmpty) and
--     me.namespace.stereotype->exists(s|s.name = profile)
--   then
--     result = me.namespace
--   else -- go up to the next level of namespace
--     result = findProfile (me.namespace)
-- else
--   result = me.namespace -- return empty set


-- Errors:
-- parse - me.namespace not a collection type, use
-- oclIsUndefined() instead
-- parse - Package type not properly qualified
-- parse - Package is a reserved word
-- parse - mismatched parentheses and notEmpty treated as
-- a property
-- parse - 'profile' string literal not quoted
-- parse - result cannot be resolved as a variable
-- parse - missing endifs
-- parse - type mismatches between results
-- semantic - result is undefined if me is undefined

-- Corrected:
if not me.oclIsUndefined()
then
  if
    not me.namespace.oclIsUndefined()
  then
    if 
      me.namespace.oclIsKindOf(
        ::"Model Management"::"Package") and
      me.namespace.stereotype->notEmpty() and
      me.namespace.stereotype->exists(s |
        
        s.name = 'profile'
      )
    then
      Set(::"Model Management"::"Package") {
      
        me.namespace.oclAsType(
          ::"Model Management"::"Package")
      }
    else -- go up to the next level of namespace
      findProfile (me.namespace)
    endif
  else
    Set(::"Model Management"::"Package") {}
  endif
else
  Set(::"Model Management"::"Package") {}
endif

Invariants:

  • [2] The base class name must be provided 

    -- Original:
-- Set (self.baseClass)->notEmpty

-- Errors:
-- parse - set inappropriately and pointlessly used
-- parse - no parameter list for notEmpty

-- Corrected:
self.baseClass->notEmpty()
  • [1] Stereotype names must not clash with any base class names. 

    -- Original:
-- Stereotype.allInstances->forAll(st | 
-- 
--   st.baseClass <> self.name
-- )

-- Errors:
-- incompatibility - allInstances not supported
-- semantic - allInstances not needed, self may be used
-- with a similar effect (note that the intent that
-- stereotype names should not clash with meta-type names
-- is not served fully in original formulation).
-- parse - baseClass has a collection type which is
-- incomparable with name


-- Corrected:
not baseClass->includes(self.name)
  • [5] All stereotype definitions must be contained either directly or transitively in a profile package. 

    -- Original:
-- findProfile(self)->notEmpty

-- Errors:
-- parse - parameter list missing for notEmpty()

-- Corrected
findProfile(self)->notEmpty()
  • [3] Tag names attached to a stereotype must not clash with M2 meta-attribute namespace of the appropriate base class element, nor with tag definition names of any inherited stereotype 

    -- cannot be specified with OCL, level M2 not accessible
-- correction:
true
  • [4] The base class of a stereotype must be the same or a subclass of the base class of parent stereotypes. 

    -- cannot be specified with OCL, level M2 not accessible
-- correction:
true

Class - ::Foundation::Extension Mechanisms::TagDefinition

Extends: ::Foundation::Core::ModelElement

A tag definition specifies the tagged values that can be attached to a kind of model element. Among other things, tag definitions can be used to define the virtual meta attributes of the stereotype to which they are attached. Some of these meta attributes may be references to other metamodel elements and, in effect, can be used to specify new one-way meta references. However, this latter feature should be used with discretion since it can easily be misused to define new semantics that are more than just refinement of the original UML metamodel.

Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype.

Properties:

Operations:

  • findProfile(me : ::Foundation::Core::ModelElement) : ::Model Management::Package[0, *] unique

    The find profile operation returns either the single-element set containing profile package in which the model element is defined or an empty set if the element is not contained in any profile.

    Copied from Stereotype type to fix invariant [2].

    Evaluates to: 

    if not me.oclIsUndefined()
then
  if
    not me.namespace.oclIsUndefined()
  then
    if 
      me.namespace.oclIsKindOf(
        ::"Model Management"::"Package") and
      me.namespace.stereotype->notEmpty() and
      me.namespace.stereotype->exists(s |
        
        s.name = 'profile'
      )
    then
      Set(::"Model Management"::"Package") {
      
        me.namespace.oclAsType(
          ::"Model Management"::"Package")
      }
    else -- go up to the next level of namespace
      findProfile (me.namespace)
    endif
  else
    Set(::"Model Management"::"Package") {}
  endif
else
  Set(::"Model Management"::"Package") {}
endif

Invariants:

  • [2] All tag definitions must be contained either directly or transitively in a profile package. 

    -- Original:
-- findProfile(self)->notEmpty

-- Errors:
-- parse - missing parameter list for notEmpty()
-- semantic - findProfile() not a member of TagDefinition
-- type


-- Corrected:
findProfile(self)->notEmpty()

Class - ::Foundation::Extension Mechanisms::TaggedValue

Extends: ::Foundation::Core::ModelElement

A tagged value allows information to be attached to any model element in conformance with its tag definition. Although a tagged value, being an instance of a kind of ModelElement, automatically inherits the name attribute, the name that is actually used in the tagged value is the name of the associated tag definition. The interpretation of tagged values is intentionally beyond the scope of UML semantics. It must be determined by user or tool conventions that may be specified in a profile in which the tagged value is defined. It is expected that various model analysis tools will define tag definitions to supply information needed for their operations beyond the basis semantics of UML. Such information could include code generation options, model management information, or user-specified semantics.

Any tagged value must have one or more reference value links or one or more data values, but not both.

Properties:

Operations:

Invariants:

  • [2] The data value of a tagged value must conform to the data type specified by the "tagType" attribute of the tag definition. 

    -- cannot be specified with OCL (requires an OCL function
-- that converts a string name into a corresponding 
-- metatype)
-- corrected:
true
  • [3] The model elements associated with a tagged value by the "referenceValue" association must be instances of the metaclass specified by the "tagType" attribute of the tag definition. 

    -- cannot be specified with OCL (requires an OCL function 
-- that converts a string name into a corresponding
-- metatype)
true
  • [1] The data value of a tagged value is exclusive to the "referenceValue” association. 

    -- original:
-- if (self.referenceValue->size > 0)
--  then (self.dataValue->size = 0)
--  else (self.dataValue->size > 0)
-- endif

-- Errors:
-- parse - parameter list missed off size()
-- parse - size() used on non-collection type, use 
-- oclIsUndefined() instead.

-- corrected:
self.referenceValue->size() > 0
implies
not self.dataValue.oclIsUndefined()

Package - ::Model Management

Class - ::Model Management::Model

Extends: ::Model Management::Package

A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail.

In the metamodel, Model is a subclass of Package. It contains a containment hierarchy of ModelElements that together describe the physical system. A Model also contains a set of ModelElements that represents the environment of the system, typically Actors, together with their interrelationships, such as Dependencies, Generalizations, and Constraints.

Different Models can be defined for the same physical system, where each model represents a view of the physical system defined by its purpose and abstraction level (for example, an analysis model, a design model, an implementation model). Typically different models are complementary and defined from the perspectives (viewpoints) of different system stakeholders. For example, a use-case model may be defined from the viewpoint of a business analyst stakeholder. Each Model is a complete description of the physical system. When Models are nested, the container Model represents the comprehensive view of the physical system given by the different views defined by the contained Models.

Properties:

Operations:

Invariants:

Class - ::Model Management::Package

Extends: ::Foundation::Core::Namespace,
::Foundation::Core::GeneralizableElement

A package is a grouping of model elements.

In the metamodel, Package is a subclass of Namespace and GeneralizableElement. A Package contains ModelElements like Packages, Classifiers, and Associations. A Package may also contain Constraints and Dependencies between ModelElements of the Package.

Each ModelElement of a Package has a visibility relative to the Package stating if the ModelElement is available to ModelElements in other Packages with a Permission («access» or «import») or Generalization relationship to the Package. An «access» or «import» Permission from one Package to another allows public ModelElements in the target Package to be referenced by ModelElements in the source Package. They differ in that all public ModelElements in imported Packages are added to the Namespace within the importing Package, whereas the Namespace within an accessing Package is not affected at all. The ModelElements available in a Package are those in the contents of the Namespace within the Package, which consists of owned and imported ModelElements, together with public ModelElements in accessed Packages.

Properties:

Operations:

  • contents() : ::Foundation::Core::ModelElement[0, *] unique

    The operation contents results in a Set containing the ModelElements owned by or imported by the Package.

    Evaluates to: 

    -- Original:
-- contents = self.ownedElement->union(self.importedElement)

-- Errors:
-- parse - contents cannot be resolved (unnecessary use of
-- operation name to define result)
-- parse - type of expression does not match type of operation
-- need cast to set.

-- Corrected
self.ownedElement->union(self.importedElement)->asSet()
  • allImportedElements() : ::Foundation::Core::ModelElement[0, *] unique

    The operation allImportedElements results in a Set containing the ModelElements imported by the Package or one of its parents.

    Evaluates to: 

    -- Original:
-- allImportedElements = self.importedElement->union(
-- self.parent.oclAsType(Package).allImportedElements->select( re |
--   re.elementImport.visibility = #public or
--   re.elementImport.visibility = #protected))


-- Errors:
-- parse - allImportedElements cannot be resolved (unnecessary
-- use of operation name to define result).
-- parse - parameter list omitted from allImportedElements()
-- incompatibility - enumation literal format
-- parse - parent not supported by type Package (use namespace
-- instead)
-- incompatibility - elementImport does not exist as
-- ElementImport association class omitted.

-- Corrected:
self.importedElement->union(

  self.namespace.oclAsType(Package).allImportedElements()
)->asSet()
  • allContents() : ::Foundation::Core::ModelElement[0, *] unique

    The operation allContents results in a Set containing the ModelElements owned by or imported by the Package or one of its ancestors.

    Evaluates to: 

    -- Original:
-- allContents = self.contents->union(
--   self.parent.allContents->select(e |
--     e.elementOwnership.visibility = #public or
--     e.elementOwnership.visibility = #protected))

-- Errors:
-- parse - allContents cannot be resolved (unnecessary use of
-- operation name to define result)
-- parse - parameter list omitted from allContents()
-- incompatibility - enumation literal format
-- parse - attribute parent not supported by package (use
-- namespace instead)
-- incompatibility - ElementOwnership association class merged
-- with ModelElement
-- parse - parameter list omitted from contents()

-- Corrected:
self.contents()->union(

  self.namespace.oclAsType(Package).allContents()->select(e |
  
    e.visibility = 
      ::Foundation::"Data Types"::VisibilityKind.public
    or
    e.visibility = 
      ::Foundation::"Data Types"::VisibilityKind.protected
  )
)

Invariants:

  • [3] No imported element (Association) may have the same name or alias combined with the same set of associated Classifiers as any Association owned by the Package or one of its supertypes. 

    -- Original:
-- self.allImportedElements->select( re |
-- 
--   re.oclIsKindOf(::Foundation::Core::Association)
-- )->forAll( re |
-- 
--   (
--     re.elementImport.alias <> ''
--     implies
--     not (
--     
--     self.allContents - self.allImportedElements)->
--     select( ve |
--     
--       ve.oclIsKindOf(::Foundation::Core::Association) 
--     )->exists(ve : ::Foundation::Core::Association |
--     
--       ve.name = re.elementImport.alias
--       and
--       ve.connection->size = re.connection->size and
--       Sequence {1..re.connection->size}->forAll( i |
--       
--         re.connection->at(i).participant =
--         ve.connection->at(i).participant
--       )
--     )
--   )
--   and
-- 
--   (re.elementImport.alias = '' implies
--     not (self.allContents - self.allImportedElements)->
--     select( ve |
--       not ve.oclIsKindOf(Association) )->exists( ve :
--       ::Foundation::Core::Association |
--         ve.name = re.name
--         and
--         ve.connection->size = re.connection->size and
--         Sequence {1..re.connection->size}->forAll( i |
--           re.connection->at(i).participant =
--           ve.connection->at(i).participant ) ) ) 
-- )

-- Errors:
-- incompatibility - elementImport not supported by
-- ModelElement (a reference to the association class 
-- ElementImport).  The attributes clash with ElementOwnership
-- but because of the many-to-many relationship cannot be
-- duplicated in the ModelElement type.  Imports therefore can't
-- be aliased and must be assumed to have the same visibility
-- and specification status as in their native package.


-- Corrected:
true
  • [1] No imported element (excluding Association) may have the same name or alias as any element owned by the Package or one of its supertypes. 

    -- Original:
-- self.allImportedElements->reject( re |
-- 
--   re.oclIsKindOf(::Foundation::Core::Association)
-- )->forAll( re |
-- 
--   (re.elementImport.alias <> '' implies
--     not (self.allContents - self.allImportedElements)->
--       reject( ve |
--         ve.oclIsKindOf (Association) )->exists ( ve |
--           ve.name = re.elementImport.alia
--           s))
--   and
--   (re.elementImport.alias = '' implies
--     not (self.allContents - self.allImportedElements)->
--       reject ( ve |
--         ve.oclIsKindOf (Association) )->exists ( ve |
--           ve.name = re.name) )
-- )


-- Errors:
-- incompatibility - elementImport not supported by
-- ModelElement (a reference to the association class 
-- ElementImport).  The attributes clash with ElementOwnership
-- but because of the many-to-many relationship cannot be
-- duplicated in the ModelElement type.  Imports therefore can't
-- be aliased and must be assumed to have the same visibility
-- and specification status as in their native package.


-- Corrected:
true
  • [4] Imported elements (Association) may not have the same name or alias combined with the same set of associated Classifiers. 

    -- Original:
-- self.allImportedElements->select ( re |
-- 
--   re.oclIsKindOf (::Foundation::Core::Association)
-- )->forAll ( r1, r2 : ::Foundation::Core::Association |
--     (r1.connection->size = r2.connection->size and
--     Sequence {1..r1.connection->size}->forAll ( i |
--       r1.connection->at (i).participant =
--         r2.connection->at (i).participant and
--       r1.elementImport.alias <> '' and
--       r2.elementImport.alias <> '' and
--       r1.elementImport.alias = r2.elementImport.alias
--       implies r1 = r2))
--     and
--     (r1.connection->size = r2.connection->size and
--       Sequence {1..r1.connection->size}->forAll ( i |
--         r1.connection->at (i).participant =
--           r2.connection->at (i).participant and
--         r1.elementImport.alias = '' and
--         r2.elementImport.alias = '' and
--         r1.name = r2.name
--         implies r1 = r2))
--     and
--     (r1.connection->size = r2.connection->size and
--     Sequence {1..r1.connection->size}->forAll ( i |
--       r1.connection->at (i).participant =
--         r2.connection->at (i).participant and
--       r1.elementImport.alias <> '' and
--       r2.elementImport.alias = ''
--       implies r1.elementImport.alias <> r2.name)))


-- Errors:
-- parse - parameter list omitted from allImportedElements()
-- parse - element type of first collection does not conform
-- to declared type of second iterator (Association).  Need a
-- cast.
-- parse - parameter list omitted from size()
-- parse - sequence declaration omits element type
-- incompatibility - elementImport no longer exists as
-- ElementImport association class omitted.


-- Corrected
self.allImportedElements()->select( re |

  re.oclIsKindOf(::Foundation::Core::Association)
).oclAsType(::Foundation::Core::Association)->forAll(
  r1, r2 : ::Foundation::Core::Association |

  (
    r1.connection->size() = r2.connection->size()
    and
    Sequence(::Foundation::"Data Types"::Integer) 
      {1..r1.connection->size()}->forAll( i |
    
      r1.connection->at(i).participant =
        r2.connection->at(i).participant and
      r1.name = r2.name
      implies r1 = r2
    )
  )
)
  • [5] A Package may only own or reference Packages, Classifiers, Associations, Generalizations, Dependencies, Comments, Constraints, Collaborations, StateMachines, Stereotypes, and TaggedValues. 

    -- Original:
-- self.contents->forAll ( c |
-- c.oclIsKindOf(Package) or
-- c.oclIsKindOf(Classifier) or
-- c.oclIsKindOf(Association or
-- c.oclIsKindOf(Generalization) or
-- c.oclIsKindOf(Dependency) or
-- c.oclIsKindOf(Comment) or
-- c.oclIsKindOf(Constraint) or
-- c.oclIsKindOf(Collaboration or
-- c.oclIsKindOf(StateMachine) or
-- c.oclIsKindOf(TaggedValue) or
-- c.oclIsKindOf(Stereotype))

-- Errors:
-- parse - Type names not properly qualified
-- parse - missing parentheses.

-- Corrected:
self.contents->forAll ( c |

  c.oclIsKindOf(Package) or
  c.oclIsKindOf(::Foundation::Core::Classifier) or
  c.oclIsKindOf(::Foundation::Core::Association) or
  c.oclIsKindOf(::Foundation::Core::Generalization) or
  c.oclIsKindOf(::Foundation::Core::Dependency) or
  c.oclIsKindOf(::Foundation::Core::Comment) or
  c.oclIsKindOf(::Foundation::Core::Constraint) or
  c.oclIsKindOf(::"Behavioral Elements"::Collaborations::
    Collaboration) or
  c.oclIsKindOf(::"Behavioral Elements"::"State Machines"::
    StateMachine) or
  c.oclIsKindOf(
    ::Foundation::"Extension Mechanisms"::TaggedValue) or
  c.oclIsKindOf(
    ::Foundation::"Extension Mechanisms"::Stereotype)
)
  • [2] Imported elements (excluding Association) may not have the same name or alias. 

    -- Original:
-- self.allImportedElements->reject( re |
-- 
--   not re.oclIsKindOf (::Foundation::Core::Association) 
-- )->forAll( r1, r2 |
-- 
--   (r1.elementImport.alias <> '' and
--     r2.elementImport.alias <> '' and
--     r1.elementImport.alias = r2.elementImport.alias
--     implies r1 = r2)
--   and
--   (r1.elementImport.alias = '' and
--     r2.elementImport.alias = '' and
--     r1.name = r2.name implies r1 = r2)
--   and
--   (r1.elementImport.alias <> '' and
--     r2.elementImport.alias = '' implies
--       r1.elementImport.alias <> r2.name)
-- )

-- Errors:
-- incompatibility - elementImport not supported by
-- ModelElement (a reference to the association class 
-- ElementImport).  The attributes clash with ElementOwnership
-- but because of the many-to-many relationship cannot be
-- duplicated in the ModelElement type.  Imports therefore can't
-- be aliased and must be assumed to have the same visibility
-- and specification status as in their native package.


-- Corrected:
true

Class - ::Model Management::Subsystem

Extends: ::Model Management::Package,
::Foundation::Core::Classifier

A subsystem is a grouping of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. In addition, the model elements of a subsystem are partitioned into specification and realization elements, where the former, together with the operations of the subsystem, are realized by the latter.

In the metamodel, Subsystem is a subclass of both Package and Classifier. As such it may have a set of Features, which are constrained to be Operations and Receptions, and Associations.

The contents of a Subsystem are divided into two subsets: specification elements and realization elements. The former subset provides, together with the Operations of the Subsystem, a specification of the behavior contained in the Subsystem, while the ModelElements in the latter subset jointly provide a realization of the specification. Any kind of ModelElement can be a specification element or a realization element.

The relationships between the specification elements and the realization elements can be defined in different ways (for example, with Collaborations or «realize» dependencies).

Properties:

Operations:

  • allSpecificationElements() : ::Foundation::Core::ModelElement[0, *] unique

    The operation allSpecificationElements results in a Set containing the Model Elements specifying the behavior of the Subsystem

    Evaluates to: 

    -- Original:
-- allSpecificationElements = self.allContents->select(c |
-- 
--   c.elementOwnership.isSpecification
-- )


-- Errors:
-- parse - allSpecificationElements can't be resolved
-- (unnecessary use of operation name to define result)
-- parse - parameter list omitted for allContents()
-- incompatibility - ElementOwnership association class merged
-- into ModelElement
-- parse - expression not compatible with operation type, need
-- cast to set.


-- Corrected  
self.allContents()->select(c |

  c.isSpecification
)->asSet()
  • contents() : ::Foundation::Core::ModelElement[0, *] unique

    The operation contents results in a Set containing the ModelElements owned by or imported by the Subsystem.

    Evaluates to: 

    -- Original:
-- contents = self.ownedElement->union(self.importedElement)


-- Errors:
-- parse - contents can't be resolved (unnecessary use of
-- operation name to define result)
-- parse - expression does not conform to operation, need
-- cast to set.


-- Corrected
self.ownedElement->union(self.importedElement)->asSet()

Invariants:

  • [2] For each Reception in an Interface offered by a Subsystem, the Subsystem itself or at least one contained specification element must have a matching Reception. 

    -- Original:
-- let allReceptions :
--   set(::"Behavioral Elements"::"Common Behavior"::Reception) =
--     self.allFeatures->select(f |
--   f.oclIsKindOf(Reception)) in
-- self.specification.allReceptions->forAll(interRec |
--   self.allReceptions->union
--     (self.allSpecificationElements->select(specEl|
--       specEl.oclIsKindOf(Classifier))->forAll(c|
--         c.allReceptions))->exists
--           ( rec | rec.hasSameSignature(interRec) ) )


-- Errors:
-- parse - allFeatures cannot be resolved (missing parameter
-- list)
-- parse - Attribute 'specification' not supported by type
-- (assume it refers to classifier supertype)
-- semantic - let expression used to define some kind of
-- template function to be applied to any self
-- parse - type of forAll expression not boolean
-- semantic - expression seems to be trivially true - need to
-- look at this again in the future to determine what was
-- intended


-- Corrected:
true
  • [3] The Features of a Subsystem may only be Operations or Receptions. 

    self.feature->forAll(f |

  f.oclIsKindOf(::Foundation::Core::Operation)
  or
  f.oclIsKindOf(
    ::"Behavioral Elements"::"Common Behavior"::Reception)
)
  • [4] A Subsystem may only own or reference Packages, Classes, DataTypes, Interfaces, UseCases, Actors, Subsystems, Signals, Associations, Generalizations, Dependencies, Constraints, Collaborations, StateMachines, and Stereotypes. 

    self.contents->forAll ( c |

  c.oclIsKindOf(Package) or
  c.oclIsKindOf(::Foundation::Core::"Class") or
  c.oclIsKindOf(::Foundation::Core::DataType) or
  c.oclIsKindOf(::Foundation::Core::Interface) or
  c.oclIsKindOf(::"Behavioral Elements"::"Use Cases"::UseCase)
  or
  c.oclIsKindOf(::"Behavioral Elements"::"Use Cases"::Actor)
  or
  c.oclIsKindOf(
    ::"Model Management"::Subsystem) or
  c.oclIsKindOf(
    ::"Behavioral Elements"::"Common Behavior"::Signal) or
  c.oclIsKindOf(::Foundation::Core::Association) or
  c.oclIsKindOf(::Foundation::Core::Generalization) or
  c.oclIsKindOf(::Foundation::Core::Dependency) or
  c.oclIsKindOf(::Foundation::Core::Constraint) or
  c.oclIsKindOf(
    ::"Behavioral Elements"::Collaborations::
      Collaboration) or
  c.oclIsKindOf(
    ::"Behavioral Elements"::"State Machines"::StateMachine) or
  c.oclIsKindOf(
    ::Foundation::"Extension Mechanisms"::Stereotype)
)
  • [1] For each Operation in an Interface offered by a Subsystem, the Subsystem itself or at least one contained specification element must have a matching Operation. 

    -- Original:
-- self.specification.allOperations->forAll(interOp |
--   self.allOperations->union
--     (self.allSpecificationElements->select(specEl|
--       specEl.oclIsKindOf(Classifier))->forAll(c|
--         c.allOperations))->exists
--           ( op | op.hasSameSignature(interOp) ) )

-- Errors:
-- parse - Attribute 'specification' not supported by type
-- (assume it refers to classifier supertype)
-- parse - allOperations not supported by ModelElement, need
-- cast and parameter list.
-- parse - forAll expression not boolean
-- semantic - this makes more sense if it compares methods to
-- operations


-- Corrected:
self.allOperations()->forAll(interOp |
  
  self.allMethods()->union(
  
    self.allSpecificationElements().oclAsType(
      ::Foundation::Core::Classifier).allMethods()
  )->exists(m | m.specification.hasSameSignature(interOp) )
)

Package - ::Behavioral Elements

Package - ::Behavioral Elements::Common Behavior

Class - ::Behavioral Elements::Common Behavior::AttributeLink

Extends: ::Foundation::Core::ModelElement

An attribute link is a named slot in an instance, which holds the value of an attribute. In the metamodel, AttributeLink is a piece of the state of an Instance and holds the value of an Attribute.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::ComponentInstance

Extends: ::Behavioral Elements::Common Behavior::Instance

A component instance is an instance of a component that resides on a node instance. A component instance may have a state.

In the metamodel, a ComponentInstance is an Instance that originates from a Component. It may be associated with a set of Instance, and may reside on a NodeInstance.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::DataValue

Extends: ::Behavioral Elements::Common Behavior::Instance

A data value is an instance with no identity.

In the metamodel, DataValue is a child of Instance that cannot change its state (i.e., all Operations that are applicable to it are pure functions or queries). DataValues are typically used as attribute values.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Exception

Extends: ::Behavioral Elements::Common Behavior::Signal

An exception is a signal raised by behavioral features typically in case of execution faults.

In the metamodel, Exception is derived from Signal. An Exception is associated with the BehavioralFeatures that raise it.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Instance

Extends: ::Foundation::Core::ModelElement

The instance construct defines an entity to which a set of operations can be applied and which has a state that stores the effects of the operations.

In the metamodel, Instance is connected to at least one Classifier that declares its structure and behavior. It has a set of attribute values and is connected to a set of Links, both sets matching the definitions of its Classifiers. The two sets implement the current state of the Instance. An Instance may also own other Instances or Links. Instance is an abstract metaclass.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Link

Extends: ::Foundation::Core::ModelElement

The link construct is a connection between instances.

In the metamodel, Link is an instance of an Association. It has a set of LinkEnds that matches the set of AssociationEnds of the Association. A Link defines a connection between Instances.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::LinkEnd

Extends: ::Foundation::Core::ModelElement

A link end is an end point of a link.

In the metamodel, LinkEnd is the part of a Link that connects to an Instance. It corresponds to an AssociationEnd of the Link's Association.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::LinkObject

Extends: ::Behavioral Elements::Common Behavior::Object

A link object is a link with its own set of attribute values and to which a set of operations may be applied.

In the metamodel, LinkObject is a connection between a set of Instances, where the connection itself may have a set of attribute values and to which a set of Operations may be applied. It is a child of both Object and Link.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::NodeInstance

Extends: ::Behavioral Elements::Common Behavior::Instance

A node instance is an instance of a node. A collection of component instances may reside on the node instance.

In the metamodel, NodeInstance is an Instance that originates from a Node. Each ComponentInstance that resides on a NodeInstance must be an instance of a Component that resides on the corresponding Node.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Object

Extends: ::Behavioral Elements::Common Behavior::Instance

An object is an instance that originates from a class.

In the metamodel, Object is a subclass of Instance and it originates from at least one Class. The set of Classes may be modified dynamically, which means that the set of features of the Object may change during its life-time.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Procedure

Extends: ::Foundation::Core::ModelElement

A procedure is a coordinated set of actions that models a computation, such as an algorithm. It can also be used without actions to express a procedure in a textual language.

In the metamodel, Procedure is a subclass of ModelElement. It can be linked to a Method or Expression to model how the method is carried out or the expression is evaluated.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Reception

Extends: ::Foundation::Core::BehavioralFeature

A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. The reception designates a signal and specifies the expected behavioral response. A reception is a summary of expected behavior. The details of handling a signal are specified by a state machine.

In the metamodel, Reception is a child of BehavioralFeature and declares that the Classifier containing the feature reacts to the signal designated by the reception feature. The isPolymorphic attribute specifies whether the behavior is polymorphic or not; a true value indicates that the behavior is not always the same and may be affected by state or subclassing. The specification indicates the expected response to the Signal.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::SendAction

Not in the 1.5 spec?

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Signal

Extends: ::Foundation::Core::Classifier

A signal is a specification of an asynchronous stimulus communicated between instances. The receiving instance handles the signal by a state machine. Signal is a generalizable element and is defined independently of the classes handling the signal. A reception is a declaration that a class handles a signal, but the actual handling is specified by a state machine.

In the metamodel, Signal is a child to Classifier, with the parameters expressed as Attributes. A Signal is always asynchronous. A Signal is associated with the BehavioralFeatures that raise it.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::Stimulus

Extends: ::Foundation::Core::ModelElement

A stimulus reifies a communication between two instances.

In the metamodel, Stimulus is a communication (i.e., a Signal sent to an Instance, or an invocation of an Operation). It can also be a request to create an Instance, or to destroy an Instance. It has a sender, a receiver, and may have a set of actual arguments, all being Instances.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Common Behavior::SubsystemInstance

Extends: ::Behavioral Elements::Common Behavior::Instance

A subsystem instance is an instance of a subsystem. It is the runtime representation of a subsystem, hence it can be connected to links corresponding to associations of the subsystem. Its task is to handle incoming communication by re-directing stimuli to the appropriate receiver inside the subsystem.

In the metamodel, SubsystemInstance is a subclass of Instance.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Collaborations

Class - ::Behavioral Elements::Collaborations::AssociationEndRole

Extends: ::Foundation::Core::AssociationEnd

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::AssociationRole

Extends: ::Foundation::Core::Association

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::ClassifierRole

Extends: ::Foundation::Core::Classifier

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::Collaboration

Extends: ::Foundation::Core::GeneralizableElement,
::Foundation::Core::Namespace

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::CollaborationInstanceSet

Extends: ::Foundation::Core::ModelElement

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::Interaction

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::InteractionInstanceSet

Extends: ::Foundation::Core::ModelElement

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Collaborations::Message

Extends: ::Foundation::Core::ModelElement

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Use Cases

Class - ::Behavioral Elements::Use Cases::Actor

Extends: ::Foundation::Core::Classifier

An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor may be considered to play a separate role with regard to each use case with which it communicates.

In the metamodel, Actor is a subclass of Classifier. An Actor has a Name and may communicate with a set of UseCases, and, at realization level, with Classifiers taking part in the realization of these UseCases. An Actor may also have a set of Interfaces, each describing how other elements may communicate with the Actor. An Actor may have generalization relationships to other Actors. This means that the child Actor will be able to play the same roles as the parent Actor, that is, communicate with the same set of UseCases, as the parent Actor.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Use Cases::Extend

Extends: ::Foundation::Core::Relationship

An extend relationship defines that instances of a use case may be augmented with some additional behavior defined in an extending use case.

In the metamodel, an Extend relationship is a directed relationship implying that a UseCaseInstance of the base UseCase may be augmented with the structure and behavior defined in the extending UseCase. The relationship consists of a condition, which must be fulfilled if the extension is to take place, and a sequence of references to extension points in the base UseCase where the additional behavior fragments are to be inserted.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Use Cases::ExtensionPoint

Extends: ::Foundation::Core::ModelElement

An extension point references one or a collection of locations in a use case where the use case may be extended.

In the metamodel, an ExtensionPoint has a name and one or a collection of descriptions of locations in the behavior of the owning use case, where a piece of behavior may be inserted into the owning use case.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Use Cases::Include

Extends: ::Foundation::Core::Relationship

An include relationship defines that a use case contains the behavior defined in another use case.

In the metamodel, an Include relationship is a directed relationship between two UseCases implying that the behavior in the addition UseCase is inserted into the behavior of the base UseCase. The base UseCase may only depend on the result of performing the behavior defined in the addition UseCase, but not on the structure; that is, on the existence of specific attributes and operations, of the addition UseCase.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Use Cases::UseCase

Extends: ::Foundation::Core::Classifier

The use case construct is used to define the behavior of a system or other semantic entity without revealing the entity's internal structure. Each use case specifies a sequence of actions, including variants, that the entity can perform, interacting with actors of the entity.

In the metamodel, UseCase is a subclass of Classifier, specifying the sequences of actions performed by an instance of the UseCase. The actions include changes of the state and communications with the environment of the UseCase. The sequences can be described using many different techniques, like Operation and Methods, ActivityGraphs, and StateMachines.

There may be Associations between UseCases and the Actors of the UseCases. Such an Association states that an instance of the UseCase and a user playing one of the roles of the Actor communicate. UseCases may be related to other UseCases by Extend, Include, and Generalization relationships. An Include relationship means that a UseCase includes the behavior described in another UseCase, while an Extend relationship implies that a UseCase may extend the behavior described in another UseCase, ruled by a condition. Generalization between UseCases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations.

The realization of a UseCase may be specified by a set of Collaborations; that is, the Collaborations define how Instances in the system interact to perform the sequences of the UseCase.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Use Cases::UseCaseInstance

Extends: ::Behavioral Elements::Common Behavior::Instance

A use case instance is the performance of a sequence of actions specified in a use case. In the metamodel, UseCaseInstance is a subclass of Instance. Each method performed by a UseCaseInstance is performed as an atomic transaction; that is, it is not interrupted by any other UseCaseInstance.

An explicitly described UseCaseInstance is called a scenario.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::State Machines

Class - ::Behavioral Elements::State Machines::CallEvent

Extends: ::Behavioral Elements::State Machines::Event

A call event represents the reception of a request to synchronously invoke a specific operation. (Note that a call event instance is distinct from the call action that caused it.) The expected result is the execution of a sequence of actions which characterize the operation behavior at a particular state.

Two special cases of CallEvent are the object creation event and the object destruction event.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::ChangeEvent

Extends: ::Behavioral Elements::State Machines::Event

A change event models an event that occurs when an explicit boolean expression becomes true as a result of a change in value of one or more attributes or associations. A change event is raised implicitly and is not the result of some explicit change event action.

The change event should not be confused with a guard. A guard is only evaluated at the time an event is dispatched whereas, conceptually, the boolean expression associated with a change event is evaluated continuously until it becomes true. The event that is generated remains until it is consumed even if the boolean expression changes to false after that.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::CompositeState

Extends: ::Behavioral Elements::State Machines::State

A composite state is a state that contains other state vertices (states, pseudostates, etc.). The association between the composite and the contained vertices is a composition association. Hence, a state vertex can be a part of at most one composite state. Any state enclosed within a composite state is called a substate of that composite state. It is called a direct substate when it is not contained by any other state; otherwise it is referred to as a transitively nested substate. CompositeState is a child of State.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::Event

Extends: ::Foundation::Core::ModelElement

An event is a specification of a type of observable occurrence. The occurrence that generates an event instance is assumed to take place at an instant in time with no duration.

Strictly speaking, the term “event” is used to refer to the type and not to an instance of the type. However, on occasion, where the meaning is clear from the context, the term is also used to refer to an event instance.

Event is a child of ModelElement.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::FinalState

Extends: ::Behavioral Elements::State Machines::State

A special kind of state signifying that the enclosing composite state is completed. If the enclosing state is the top state, then it means that the entire state machine has completed.

A final state cannot have any outgoing transitions. FinalState is a child of State.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::Guard

Extends: ::Foundation::Core::ModelElement

A guard is a boolean expression that is attached to a transition as a fine-grained control over its firing. The guard is evaluated when an event instance is dispatched by the statemachine. If the guard is true at that time, the transition is enabled, otherwise, it is disabled.

Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed.

Guard is a child of ModelElement.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::PseudoState

Extends: ::Behavioral Elements::State Machines::StateVertex

A pseudostate is an abstraction that encompasses different types of transient vertices in the state machine graph. They are used, typically, to connect multiple transitions into more complex state transitions paths. For example, by combining a transition entering a fork pseudostate with a set of transitions exiting the fork pseudostate, we get a compound transition that leads to a set of concurrent target states.

The following pseudostate kinds are defined:

• An initial pseudostate represents a default vertex that is the source for a single transition to the default state of a composite state. There can be at most one initial vertex in a composite state.

• deepHistory is used as a shorthand notation that represents the most recent active configuration of the composite state that directly contains this pseudostate; that is, the state configuration that was active when the composite state was last exited. A composite state can have at most one deep history vertex. A transition may originate from the history connector to the default deep history state. This transition is taken in case the composite state had never been active before.

• shallowHistory is a shorthand notation that represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. A transition coming into the shallow history vertex is equivalent to a transition coming into the most recent active substate of a state. A transition may originate from the history connector to the initial shallow history state. This transition is taken in case the composite state had never been active before.

• join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards.

• fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The egments outgoing from a fork vertex must not have guards.

• junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct compound transition paths between states. For example, a junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as an merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. This realizes a static conditional branch. (In the latter case, outgoing transitions whose guard conditions evaluate to false are disabled. A predefined guard denoted “else” may be defined for at most one outgoing transition. This transition is enabled if all the guards labeling the other transitions are false.) Static conditional branches are distinct from dynamic conditional branches that are realized by choice vertices (described below).

• choice vertices which, when reached, result in the dynamic evaluation of the guards of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step. If more than one of the guards evaluates to true, an arbitrary one is selected. 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 vertex.) Choice vertices should be distinguished from static branch points that are based on junction points (described above).

PseudoState is a child of StateVertex.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::SignalEvent

Extends: ::Behavioral Elements::State Machines::Event

A signal event represents the reception of a particular (asynchronous) signal. A signal event instance should not be confused with the action (e.g., send action) that generated it. SignalEvent is a child of Event.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::SimpleState

Extends: ::Behavioral Elements::State Machines::State

A SimpleState is a state that does not have substates. It is a child of State.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::State

Extends: ::Behavioral Elements::State Machines::StateVertex

A state is an abstract metaclass that models a situation during hich some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object aiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some activity (i.e., the model element under consideration enters the state when the activity commences and leaves it as soon as the activity is completed). State is a child of StateVertex.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::StateMachine

Extends: ::Foundation::Core::ModelElement

A state machine is a specification that describes all possible behaviors of some dynamic model element. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine. StateMachine has a composition relationship to State, which represents the top-level state, and a set of transitions. This means that a state machine owns its transitions and its top state. All remaining states are transitively owned through the state containment hierarchy rooted in the top state. The association to ModelElement provides the context of the state machine. A common case of the context relation is where a state machine is used to specify the lifecycle of a classifier.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::StateVertex

Extends: ::Foundation::Core::ModelElement

A StateVertex is an abstraction of a node in a statechart graph. In general, it can be the source or destination of any number of transitions.

StateVertex is a child of ModelElement.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::StubState

Extends: ::Behavioral Elements::State Machines::StateVertex

A stub state can appear within a submachine state and represents an actual subvertex contained within the referenced state machine. It can serve as a source or destination of transitions that connect a state vertex in the containing state machine with a subvertex in the referenced state machine.

StubState is a child of State.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::SubmachineState

Extends: ::Behavioral Elements::State Machines::CompositeState

A submachine state is a syntactical convenience that facilitates reuse and modularity. It is a shorthand that implies a macro-like expansion by another state machine and is semantically equivalent to a composite state. The state machine that is inserted is called the referenced state machine while the state machine that contains the submachine state is called the containing state machine. The same state machine may be referenced more than once in the context of a single containing state machine. In effect, a submachine state represents a “call” to a state machine “subroutine” with one or more entry and exit points.

The entry and exit points are specified by stub states. SubmachineState is a child of State.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::SynchState

Extends: ::Behavioral Elements::State Machines::StateVertex

A synch state is a vertex used for synchronizing the concurrent regions of a state machine. It is different from a state in the sense that it is not mapped to a boolean value (active, not active), but an integer. A synch sate is used in conjunction with forks and joins to insure that one region leaves a particular state or states before another region can enter a particular state or states. SynchState is a child of StateVertex.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::TimeEvent

Extends: ::Behavioral Elements::State Machines::Event

A TimeEvent models the expiration of a specific deadline. Note that the time of occurrence of a time event instance (i.e., the expiration of the deadline) is the same as the time of its reception. However, it is important to note that there may be a variable delay between the time of reception and the time of dispatching (e.g., due to queueing delays).

The expression specifying the deadline may be relative or absolute. If the time expression is relative and no explicit starting time is defined, then it is relative to the time of entry into the source state of the transition triggered by the event. In the latter case, the time event instance is generated only if the state machine is still in that state when the deadline expires.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::State Machines::Transition

Extends: ::Foundation::Core::ModelElement

A transition is a directed relationship between a source state vertex and a target state vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to a particular event instance. Transition is a child of ModelElement.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Activity Graphs

Class - ::Behavioral Elements::Activity Graphs::ActionState

Extends: ::Behavioral Elements::State Machines::SimpleState

An action state represents the execution of an atomic action, typically the invocation of an operation.

An action state is a simple state with an entry action whose only exit transition is triggered by the implicit event of completing the execution of the entry action. The state therefore corresponds to the execution of the entry action itself and the outgoing transition is activated as soon as the action has completed its execution. An ActionState may perform more than one action as part of its entry action. An action state may not have an exit action, do activity, or internal transitions.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::ActivityGraph

Extends: ::Behavioral Elements::State Machines::StateMachine

An activity graph is a special case of a state machine that defines a computational process in terms of the control-flow and object-flow among its constituent activities. It does not extend the semantics of state machines in a major way but it does define shorthand forms that are convenient for modeling control-flow and object-flow in organizational processes.

The primary purpose of activity graphs is to describe the states of an activity or process involving one or more classifiers. Activity graphs can be attached to packages, classifiers (including use cases) and behavioral features. As in any state machine, if an outgoing transition is not explicitly triggered by an event then it is implicitly triggered by the completion of the contained actions. A subactivity state represents a nested activity that has some duration and internally consists of a set of actions or more subactivities. That is, a subactivity state is a “hierarchical action” with an embedded activity subgraph that ultimately resolves to individual actions. Junctions, forks, joins, and synchs may be included to model decisions and concurrent activity.

Activity graphs include the concept of Partitions to organize states according to various criteria, such as the real-world organization responsible for their performance. Activity graphing can be applied to organizational modeling for business process engineering and workflow modeling. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call. Activity graphs can also be applied to system modeling to specify the dynamics of operations and system level processes when a full interaction model is not needed.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::CallState

Extends: ::Behavioral Elements::Activity Graphs::ActionState

A call state is an action state that calls a single operation. It is useful in object flow modeling to reduce notational ambiguity over which action is taking input or providing output.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::ClassifierInState

Extends: ::Foundation::Core::Classifier

A classifier-in-state characterizes instances of a given classifier that are in a particular state or states. In an activity graph, it may be used to specify input and/or output to an action through an object flow state.

ClassifierInState is a child of Classifier and may be used in static structural models and collaborations (e.g., it can be used to show associations that are only relevant when objects of a class are in a given state).

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::ObjectFlowState

Extends: ::Behavioral Elements::State Machines::SimpleState

An object flow state defines an object flow between actions in an activity graph. An instance of a particular classifier, possibly in a particular state, is available when an object flow state is occupied.

The generation of an object by an action in an action state may be modeled by an object flow state that is triggered by the completion of the action state. The use of the object in a subsequent action state may be modeled by connecting the output transition of the object flow state as an input transition to the action state. Generally each action places the object in a different state that is modeled as a distinct object flow state.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::Partition

Extends: ::Foundation::Core::ModelElement

A partition is a mechanism for dividing the states of an activity graph into groups. Partitions often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the states of an activity graph. It should be noted that Partitions do not impact the dynamic semantics of the model but they help to allocate properties and actions for various purposes.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::SubactivityState

Extends: ::Behavioral Elements::State Machines::StateMachine

A subactivity state represents the execution of a non-atomic equence of steps that has some duration (i.e., internally it consists of a set of actions and possibly waiting for events). That is, a subactivity state is a “hierarchical action,” where an associated subactivity graph is executed.

A subactivity state is a submachine state that executes a nested activity graph. When an input transition to the subactivity state is triggered, execution begins with the nested activity graph. The outgoing transitions of a subactivity state are enabled when the final state of the nested activity graph is reached (i.e., when it completes its execution), or when the trigger events occur on the transitions.

The semantics of a subactivity state are equivalent to the model obtained by statically substituting the contents of the nested graph as a composite state replacing the subactivity state.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Activity Graphs::Transition

Extends: ::Foundation::Core::ModelElement

Transition is inherited from state machines.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions

Package - ::Behavioral Elements::Actions::Action Foundation

Class - ::Behavioral Elements::Actions::Action Foundation::Action

Extends: ::Foundation::Core::ModelElement

An action is the fundamental unit of behavior specification. An action takes a set of input values and uses them to produce a set of output values, though either or both sets may be empty. If both inputs and outputs are missing, the action must have some kind of fixed, nonparameterized effect on the system state, or be performing some effect external to the system. Actions may access or modify accessible, mutable objects. A reference to an object to read or write is an input of the action. Composite actions may include data-transformation actions as well as object-access actions.

An action may have a set of incoming data flows as well as a set of explicit control flow dependencies on predecessor actions. An action will not begin execution until all of its input values (if any) have been produced by preceding actions and all predecessor actions have completed. The completion of the execution of an action may enable the execution of a set of successor actions and actions that take their inputs from the outputs of the action. Actions come in various kinds, each of which has its own formation rules. An action must be one of those kinds.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::ControlFlow

Extends: ::Foundation::Core::ModelElement

A control flow is a sequencing dependency between two actions. The successor action of the flow may not execute until the predecessor action has completed execution.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::DataFlow

Extends: ::Foundation::Core::ModelElement

A data flow carries values from a source output pin to a destination input pin. When a value is generated on the source pin, it is copied to the destination pin. The source pin must therefore conform in type and multiplicity to the destination pin.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::InputPin

Extends: ::Behavioral Elements::Actions::Action Foundation::Pin

An input pin holds input values to be consumed by an action. An input pin may be the destination for exactly one data flow. The input pin receives its values from the source output pin of the data flow.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::OutputPin

Extends: ::Behavioral Elements::Actions::Action Foundation::Pin

An output pin holds output values generated by an action. A single output pin may have several data-flow connections to several input pins. In this case, the output pin provides a copy of its value to each of the associated input pins.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::Pin

Extends: ::Foundation::Core::ModelElement

A pin is a connection point for delivering input values to or obtaining output values from an action. Any values passing through the pin must conform to the type of the pin and have cardinalities allowed by the multiplicity of the pin. (A pin without a type specification can hold any value.) Pin is completely specialized into input and output pins.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

A primitive action is one that does not contain any nested actions, so all available inputs and outputs of the action are pins directly owned by the action.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Action Foundation::Procedure

A procedure is a set of actions that may be attached as a unit to other parts of the user model. The behavior of the procedure is specified using an action, which is usually composite. When it is activated, a procedure execution receives a request object from the caller; during its execution it produces a reply object that is returned to the caller as the result. The procedure has a single input pin for the request object and a single result pin for the reply object. If the isList flag is set in the action, the procedure may have multiple argument and result pins; the request object is broken apart into an ordered list of arguments, one per attribute of the request object; and the reply object is composed from an ordered list of results, one per attribute of the reply object. This option presents the inputs and outputs to the procedure in the traditional fashion as a list of explicit parameters, although they are composed into a request object and a reply object for use by the invocation action.

Pins of procedures have two directions: in and out, while method and operation parameters have direction in, out, inout, and return. Since parameters and pins are ordered on methods and rocedures respectively, the parameters of methods can be matched to pins on procedures unambiguously, assuming the last output pin is matched to the return parameter. Parameters of kind in and inout match input pins, while parameters of kind out, inout, and return match output pins.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Composite Actions

Class - ::Behavioral Elements::Actions::Composite Actions::Clause

Extends: ::Foundation::Core::Element

A clause is a part of a conditional or loop action. A clause contains a test action and a body action. Both are arbitrary actions (usually group actions) subject to connectivity constraints described under the various composite actions. The execution of the body action is contingent on the corresponding test action producing a "true" value. The clause specifies one output pin of the test action, which must have type Boolean; the body action is only executed if this output produces the value "true" after execution of the test action. (Additionally, for a conditional, only one clause body is executed even if more than one of their tests is true.) The outputs of a clause are an ordered subset of the outputs of the body action. No other output of the body action may be connected outside the clause.

Clauses within a conditional action may be linked by a set of (noncyclic) predecessor/successor relationships. The test action of a clause may not execute unless all the predecessors of the clause not only have completed execution, but have also "failed." These relationships thus act, in effect, as specialized kinds of control flows. Neither the test or body actions of a clause can participate in any normal, explicit control flows.

During execution of an enclosing loop action, a test action may not execute for the first time unless all predecessors of the loop action have executed. It may not execute for a subsequent time unless the previous execution of the body action is complete, that is, there is an implicit control flow between the execution of a body action and the next iteration of the test action.

In a conditional or a loop action, a body action may not execute until its test action completes and yields "true."

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Composite Actions::ConditionalAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

A conditional action consists of a set of one or more clauses, exactly one of whose bodies is executed during any execution of the conditional action. If more than one clause has a test that yields “true,” exactly one of the corresponding body actions is selected for execution, but it is unspecified which one. (If the conditional action is declared to be determinate, this is an assertion that exactly one concurrent clause test will yield true.) The clause must have an ordered list of output pins that conform to the ordered list of output pins of the conditional. This list must be drawn from accessible outputs of the body action. The only outputs of the conditional action accessible outside it are the output pins directly owned by the conditional action.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Composite Actions::GroupAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

A group action represents a simple composition of a set of subactions. A group action does not own any pins of its own, but data-flow connections may (generally) be made from actions outside the group to pins owned by actions within the group action. The group action as a whole may participate in control flows and actions within the group action may also participate in control flows with actions outside the group action. There is an implicit control flow from the group action to each action within it; this is important only if there is a control flow to the group action. Similarly, there is an implicit control flow from each action in the group action to the group action; this is important only if there is a control flow from the group action. Finally, a set of local variables can be declared in association with a group action. The group action serves as the scope for use of the variables.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Composite Actions::LoopAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

A loop action contains a single clause whose test action and body action are executed repeatedly as long as the test action yields “true.” A list of output pins acts as "loop variables" for the loop action. The loop variables are not directly vailable outside the loop. Input pins of the overall loop action provide initial values that are copied into these loop variables before the first iteration of the loop. As output pins, the loop variables may be connected to available inputs of the test and body actions using normal data flows, to provide the "old values" of the loop variables during an iteration.

The outputs of the loop clause provide "new values" that are copied to the loop variables at the completion of an iteration. The test is executed after the initial values are copied to the loop variables, and after each execution of the body action. The body action is executed only if the test yields true. When the loop terminates, the final values of the loop variables are copied to the regular output pins of the loop action, which are the only available outputs for the loop action as a whole.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Composite Actions::Variable

Extends: ::Foundation::Core::ModelElement

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Read Write Actions

Class - ::Behavioral Elements::Actions::Read Write Actions::AddAttributeValueAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteAttributeAction

This action adds values to attributes. Attributes are potentially multi-valued. It also supports the removal of existing values of the attribute before the new value is added. If the new value already exists, then it is not removed under this option. Otherwise, adding an existing value has no effect.

The semantics is undefined for adding a value that violates the upper multiplicity of the attribute. The semantics is undefined for adding a new value for an attribute with changeability frozen after initialization of the owning object.

Adding values to ordered attributes requires an insertion point for a new value using the insertAt input pin. The pin is of type UnlimitedInteger. 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 one meaning the new value will be first in the sequence. A value of unlimited for insertAt means to insert the new value at the end of the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertAt input pin does not exist for unordered attributes. Reinserting an existing value at a new position moves the value to that position.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::AddVariableValueAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteVariableAction

This action adds values to variables. Variables are potentially multi-valued. It also supports the removal of existing values of the attribute before the new value is added. If the new value already exists, then it is not removed under this option. Otherwise, adding an existing value has no effect.

The semantics is undefined for adding a value that violates the upper multiplicity of the variable.

Adding values to ordered variables requires an insertion point for a new value using the insertAt input pin. The pin is of type UnlimitedInteger. 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 one meaning the new value will be first in the sequence. A value of unlimited for insertAt means to insert the new value at the end of the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertAt input pin does not exist for unordered variables. Reinserting an existing value at a new position moves the value to that position.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::AttributeAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

An attribute action operates on a statically specified attribute of some classifier. The action requires an object on which to act, provided at runtime through an input pin. The semantics is undefined for accessing an attribute that violates its visibility. The semantics is undefined for attributes with ownerScope or targetScope equal to classifier.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::CallProcedureAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action starts a statically-specified procedure, passing inputs, and waiting for outputs if it is synchronous.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ClearAssociationAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action destroys all the links of an association in which a particular object participates. This action has a statically- specified association end. It has an input pin for a runtime object that must be of the same type as at least one of the association ends of the association. All links of the association in which the object participates are destroyed even when that violates the minimum multiplicity of any of the association ends. If the association is a class, then link object identities are destroyed.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ClearAttributeAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::AttributeAction

This action removes all values of an attribute. All values are removed even when that violates the minimum multiplicity of the attribute. The semantics is undefined if the attribute changeability is addonly, or the attribute changeability is frozen after initialization of the object owning the attribute, unless the attribute has no values.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ClearVariableAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::VariableAction

This action removes all values of a variable. All values are removed even when that violates the minimum multiplicity of the variable.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::CreateLinkAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteLinkAction

This action creates a link or link object for an association or association class. This action has no output pin, because links are not necessarily values that can be passed to and from actions. When the action creates a link object, the object could be returned on output pin, but it is not for consistency with links. This allows actions to remain unchanged when an association is changed to an association class or vice versa. The semantics of CreateLinkObjectAction applies to creating link objects with CreateLinkAction.

This action also supports the destruction of existing links of the association that connect any of the objects of the new link. This option is available on an end-by-end basis, and causes all links of the association emanating from the specified ends to be destroyed before the new link is created. If the link already exists, then it is not destroyed under this option. Otherwise, recreating an existing link has no effect. The semantics is undefined for creating a link for an association class that is abstract. The semantics is undefined for creating a link that violates the upper multiplicity of one of its association ends. A new link violates the upper multiplicity of an end if the cardinality of that end after the link is created would be greater than the upper multiplicity of that end. The cardinality of an end is equal to the number of links with objects participating in the other ends that are the same as those participating in those other ends in the new link, and with qualifier values on all ends the same as the new link, if any.

The semantics is undefined for creating a link that has an association end with changeability frozen after initialization of the other end objects, unless the link being created already exists. Objects participating in the association across from an unfrozen end can have links created as long as the objects across from the frozen ends are still being initialized. This means that objects participating in links with two or more frozen ends cannot have links created unless all the linked objects are being initialized. Creating ordered association ends requires an insertion point for a new link using the insertAt input pin of LinkEndCreationData. The pin is of type UnlimitedInteger with multiplicity of 1..1. A pin value that is a positive integer less than or equal to the current number of links means to insert the new link at that position in the sequence of existing links, with the integer one meaning the new link will be first in the sequence. A value of unlimited for insertAt means to insert the new link at the end of the sequence. The semantics is undefined for value of zero or an integer greater than the number of existing links. The insertAt input pin does not exist for unordered association ends. Reinserting an existing end at a new position moves the end to that position.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::CreateLinkObjectAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::CreateLinkAction

This action creates a link object. It inherits the semantics of CreateLinkAction, except that it operates on association classes to create a link object. The additional semantics over CreateLinkAction is that the new or found link object is put on the output pin. If the link already exists, then the found link object is put on the output pin. The semantics of CreateObjectAction applies to creating link objects with CreateLinkObjectAction.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::CreateObjectAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action instantiates a concrete classifier. The new object is created, and the classifier of the object is set to the given classifier. The new object is returned as the value of the action. The action has no other effect. In particular, no constructors are executed, no initial expressions are evaluated, and no state machines transitions are triggered. The new object has no attributes values and participates in no links. The semantics is undefined for creating objects from abstract classifiers or from association classes.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::DestroyLinkAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteLinkAction

This action destroys a link or a link object. Link objects can also be destroyed with DestroyObjectAction.

The link is specified in the same way as link creation, even for link objects. This allows actions to remain unchanged when their associations are transformed from ordinary ones to association classes and vice versa.

Destroying a link that does not exist has no effect. The semantics of DestroyObjectAction applies to destroying a link that has a link object with DestroyLinkAction.

The semantics is undefined for destroying a link that has an association end with changeability addonly, or frozen after initialization of the other end objects, unless the link being destroyed does not exist. Objects participating in the association across from an unfrozen end can have links destroyed as long as the objects across from the frozen ends are still being initialized. This means that objects participating in links with 2 or more frozen ends cannot have links destroyed unless all the linked objects are being initialized.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::DestroyObjectAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action destroys an object. The object may be a link object, in which case the semantics of DestroyLinkAction also applies.

The classifiers of the object are removed as its classifiers, and the object is destroyed. The action has no other effect. In particular, no destructors are executed, no state machines transitions are triggered, and references to the objects are unchanged. Destroying an object that is already destroyed has no effect.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::LinkAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

A link action creates, destroys, or reads links. A link is identified by its end objects and qualifier values, if any. The semantics is undefined for links of associations that have targetScope equal to classifier on any end.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::LinkEndCreationData

Extends: ::Behavioral Elements::Actions::Read Write Actions::LinkEndData

LinkEndCreationData is not an action. It is part of the metamodel that identifies links. It comprises a set of values that identifies one end of a link to be created by CreateLinkAction or CreateLinkObjectAction. It is required for specifying ordered association ends and for replacing all links at an end. See also CreateLinkAction.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::LinkEndData

LinkEndData is not an action. It is part of the metamodel that identifies links. It identifies one end of a link to be read by a ReadLinkAction or written by the children of WriteLinkAction.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::QualifierValue

QualifierValue is not an action. It is part of the metamodel that identifies links. It gives a single qualifier within a link end data specification. See LinkEndData.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadAttributeAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::AttributeAction

This action reads the values of an attribute, in order if the attribute is ordered.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadExtentAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action reads the runtime objects of any classifier that may have instances. It reads all instances, direct and indirect.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadIsClassifiedObjectAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action tests an object’s classification against a statically specified class. It returns true if the object input to the action is classified by the specified classifier with no intervening classes between the object and the specified classifier. It returns true if the isDirect attribute is false and the object input to the action is classified by the specified classifier, either directly or with intervening classifiers. Otherwise, it returns false.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadLinkAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::LinkAction

This action navigates links of an association towards one end. For example, it navigates the link of a binary association from a source object to the objects at the other end of links of the association in which that source object participates. The end towards which navigation occurs is the one that does not have an input pin to take its object (the "open" end). The objects put on the result output pin are the ones participating in the association at the open end, conforming to the specified qualifiers, in order if the end is ordered. The semantics is undefined for reading a link that violates the navigability or visibility of the open end.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadLinkObjectAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action reads the object on an end of a link object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadLinkObjectQualifierAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action reads a qualifier value on an end of a link object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadSelfAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action reads the host object of an action. The semantics is undefined for usage in a procedure that does not have a host object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReadVariableAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::VariableAction

This action reads the values of a variable, in order if the variable is ordered.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::ReclassifyObjectAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action changes classifiers for an object. The object input to the action is classified by its existing classifiers plus the new classifiers and minus the old classifiers statically specified by the action. It also supports the removal of existing classifiers of the object before the new classifiers are added. The action has no other effect. In particular, the identity of the object is preserved, no constructors or destructors are executed and no initial expressions are evaluated. New classifiers replace existing classifiers in one action, so that attribute values and links are not lost by intermediate stages of classification when the old and new classifiers have attributes and associations in common.

Adding a classifier that duplicates one already existing, or removing a classifier that is not there, has no effect. Adding and removing the same classifiers has no effect. States are preserved for state machines that are in common before and after the action. New state machines are not started. Removed state machines behave as if the object were deleted.

The semantics is undefined if any of the new classifiers are abstract. The semantics is undefined if all classifiers are removed from a runtime object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::RemoveAttributeValueAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteAttributeAction

This action removes values from attributes. Attributes are potentially multi-valued. Removing a value succeeds even when it violates the minimum multiplicity. Removing a value that does not exist has no effect.

The semantics is undefined for removing an existing value for an attribute with changeability addonly. The semantics is undefined for removing an existing value of an attribute with changeability frozen after initialization of the owning object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::RemoveVariableValueAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::WriteVariableAction

This action removes values from attributes. Attributes are otentially multi-valued. Removing a value succeeds even when it violates the minimum multiplicity. Removing a value that does not exist has no effect.

The semantics is undefined for removing an existing value for an attribute with changeability addonly. The semantics is undefined for removing an existing value of an attribute with changeability frozen after initialization of the owning object.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::StartObjectStateMachineAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action puts the state machines of an object in their top states, if they have not been there already. This can only be used once per object. The action has no effect if the object does not have a state machine.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::VariableAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

A variable action operates on a statically specified variable.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::WriteAttributeAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::AttributeAction

A write attribute action operates on an attribute of an object to modify its values. It has an input pin on which the value that will be added or removed is put. Other aspects of write attribute actions are inherited from AttributeAction.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::WriteLinkAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::LinkAction

A write link action creates or destroys links.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Read Write Actions::WriteVariableAction

Extends: ::Behavioral Elements::Actions::Read Write Actions::VariableAction

A write variable action modifies a statically specified variable.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Computation Actions

Class - ::Behavioral Elements::Actions::Computation Actions::ApplyFunctionAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

This action computes a primitive predefined mathematical function that depends only on the input values, with no access to object memory or to any objects. The execution and results of this action depend only on the function and the input values. There are absolutely no side effects of this action and it therefore cannot conflict with anything. All it does is produce result values using a mathematical function.

New primitive functions may be defined (outside of UML) as mathematical functions of input values to output values. All usual primitive operations should be considered as primitive functions (e.g., addition, nand, square root, finding a substring, Bessel function, etc.).

A list of defined primitive functions may be supplied as part of a modeling profile. UML does not provide a mechanism to define primitive functions, as their definition is outside its scope. It is expected that users will agree on environments containing such definitions.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::ArgumentSpecification

Extends: ::Foundation::Core::ModelElement

(Not an action) Specification of an input or output argument of a primitive function.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::CodeAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

A code action performs an action that is defined outside of UML. This may involve external interactions, so it is not a mathematical transformation like a primitive function action. The action may have inputs and outputs. Code actions must not alter object memory state, although it is hard to prevent such things. The semantics of a code action that alters object memory are undefined, together with the semantics of all subsequently executed actions.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::LiteralValueAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Generates a literal value on the output pin. The value can be of any pure data type.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::MarshalAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Creates an object whose attribute values are initialized from the inputs.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::NullAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

An action that has no effect.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::PrimitiveFunction

Extends: ::Foundation::Core::ModelElement

(Not an action) Describes the signature of a primitive function, that is, a mathematical function that produces output values from input values without any internal action semantics substructure. The manner of specifying functions is outside the scope of action semantics and must be expressed in some external language.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::TestIdentifyAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Produces true if the two input values are the same identity, false if they are not. Defined only on object identities.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Computation Actions::UnmarshalAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Breaks an object of a known type into outputs, each of which is equal to the value of one of the object’s attribute values.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Collection Actions

Class - ::Behavioral Elements::Actions::Collection Actions::CollectionAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

An action that operates on a collection of values.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Collection Actions::FilterAction

Extends: ::Behavioral Elements::Actions::Collection Actions::CollectionAction

The filter action applies a subaction to every slice of inputs. The subaction must yield a boolean output whose value is used to decide whether each slice of input values is passed through to the output collections. The result of the filter action is a set of collections, whose size is equal to or less than the size of the input collections, comprising all the slices of the input collections for which the subaction yielded a true value. The gaps caused by the subaction yielding a false value are closed up. All executions of the subaction can be concurrent.

In the simplest case, the subaction takes an input (a single element from the collection input to the filter action), and produces a boolean data value on the output pin. The filter action has a collection of elements as input and an output that is a collection of a subset of the input collection, in the same order, whether the collection is ordered or not.

The subaction may also take inputs that are not inputs to the filter action, such as a constant or a 'variable' used in every execution of the subaction. For example, if the subaction tests whether an element is less than x, then the inputs to the subaction are the element and x, while the input to the filter action is the collection of elements. The output of the subaction remains a boolean scalar.

The filter action may also take multiple input collections, each of which must have the same number of elements. When each slice is presented successively as inputs to the subaction, the subaction determines whether to pass the slice through to the corresponding output collections. The number of the input and output collections must therefore be the same. The type of each output collection matches the type of its corresponding input collection. In addition, the number of elements in each output collection will be the same.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Collection Actions::IterateAction

Extends: ::Behavioral Elements::Actions::Collection Actions::CollectionAction

The iterate action applies an action repeatedly, once for each input slice. A bank of loop variables accumulates the result of the iteration and is eventually passed to the output of the iterate action. This action is a special case of a loop in which the number of iterations is equal to the number of elements in a collection and the elements of the collection are made available to the loop body on successive iterations.

The iterate action executes a subaction once for each input slice. The slices are presented from first to last in the scan order for the collection. When the order of computation does not affect the result, for example if the input collection is a set, or if the isUnordered attribute is true, then the slices are presented in an indeterminate (and not necessarily repeatable) order. Like a loop, an iterate action has loop variables that accumulate the effects of the iteration. The subaction accesses the previous values of the loop variables and computes new values for the next execution. The initial values of the loop variables are supplied by inputs to the iterate action, and the final values of the loop variables become the results of the iterate action. If there are no loop variables, the action can have an effect only by writing memory values. An iterate action has two kinds of input pins: the input collections, and scalar values used to initialize the loop variables. The iterate action has one kind of output pins, whose number and types match the loop variable input pins.

The iterate action owns internal OutputPins, matching the loop variable output pins. On the initial execution of the subaction, these pins get the values from the loop variable input pins. The iterate action also owns a bank (labeled subinput) of internal OutputPins, equal in number to the collection input pins. The type of each subinput pin matches the type of element containing in the corresponding collection input pin. During each execution of the subaction, these pins hold one slice. The iterate action also designates (as suboutput) a bank of OutputPins owned by the subaction. At the conclusion of the execution of the subaction, the values on these pins become the new values of the loop variable pins.

The subaction has access to the subinput values and the loop variable values that change during each execution of the subaction. It may also access available OutputPins in the containing scope. Such values are fixed during the executions of the subactions for any one execution of the iterate action. During one execution, the subaction computes values for the suboutput pins. The values on the suboutput pins become the new values of the loop variable pins on the next iteration of the subaction. When all slices of the collections have been processed, the final values of the loop variables become the values on the result output pins of the overall iterate action. No outputs of the subaction are available outside of it, except for the explicit suboutput pins designated by the iterate action, which are available only to the iterate action itself. The isUnordered attribute states that the order of execution of slices is irrelevant, even though the ordering of elements in each collection is still used to match corresponding elements into slices. The purpose of this attribute would be to remove overspecification of ordering and permit optimization within an implementation, especially if values are not all computed at the same time (such as lazy evaluation). If the input collection shape is a set, then the slices are processed in an indeterminate order.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Collection Actions::MapAction

Extends: ::Behavioral Elements::Actions::Collection Actions::CollectionAction

The map action applies a subaction to each input slice. If the subaction has output pins, then the map action has that same number of outputs, each of which is a collection with the same size as the input collections. Any values produced on the suboutput pins are formed into collections, each containing one value from each execution. The subaction is executed concurrently, once for each input slice. If executions of the subaction conflict (because they write shared objects), then the result is indeterminate. The map action has zero or more output pins, each of which holds a collection. The output collections from the map action have the same size as the input collections, and each output value occupies the corresponding position in its collection, but the types of the collections may differ from each other and the input collections. The number of output collections need not equal the number of input collections. The subaction may access available scalar inputs from outside the map action, but no output pin of the subaction is available outside the map action.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Collection Actions::ReduceAction

Extends: ::Behavioral Elements::Actions::Collection Actions::CollectionAction

The reduce action applies an associative binary subaction repeatedly to adjacent pairs of slices from the input collections, until the (intermediate working) collection is reduced to a single slice of scalar values, which together constitute the output values of the reduce action. The order in which the subaction is applied to pairs of values is indeterminate, and does not affect the ultimate result if the action is associative, unless the subactions are not isolated from each other, in which case the result is unpredictable.

As an example, consider a collection comprising four integers in order: 2, 7, 5 and -3. The result of applying the reduce action to this collection with the binary associative subaction Addition is the scalar 9. This can be computed by any of the following orderings: ( ( (2+7) + 5) + -3) = 11; (2 + (7 + (5 + -3))) = 11; ((2 + 7) + (5 + -3)) = 11. When the subaction is symmetric, as with addition, the order of the elements in the collection is not important. However, some associative operations are not symmetric, such as matrix multiplication, so A × B is not the same as B × A. In these cases, the concept of adjacency of the elements and the order in which they appear is critical. The reduce action requires a subaction, which must be a binary associative operator. Each of the two inputs to the subaction is a slice from the input collections to the reduce action. For example, to sum all the balances for a customer’s account, the reduce action has a single input collection of account balances, and a single scalar output, the sum of those balances, which must necessarily be of the same type. Each of the two inputs to the subaction, Addition, takes "a slice from the input collections to the reduce action", which in this case is a single account balance on each input. The output is a tuple ith the same structure: a balance. When the reduce action has several input collections, then one slice across all collections will be one input to the subaction and another slice will constitute the other input.

The reduce action executes the subaction one fewer time than the size of the input collections., because it operates on adjacent pairs of slices from the input collections. The output of the subaction conceptually replaces the two input slices in the collection of tuples, so the subaction can be applied repeatedly to pairs of slices until a single slice remains. Its value is place on the result output pins of the overall reduce action as scalars. In other words, the reduce action serves to reduce a collection of values to a single value by repeated application of a binary function.

If the subaction accesses values from outside the reduce action, uch values will be the same for all the concurrent subaction executions during a single execution of the reduce action. No output pins of the subaction may be connected outside the reduce action.

The isUnordered attribute states that the reduction can be applied to the slices in any order, even though the ordering of elements in each collection is still used to match corresponding elements into slices. This will be mathematically valid if the subaction is symmetric and the actions are isolated.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Messaging Actions

Class - ::Behavioral Elements::Actions::Messaging Actions::AsynchronousInvocationAction

Extends: ::Behavioral Elements::Actions::Messaging Actions::InvocationAction

Creates a request that is transmitted to the target object, where it causes the execution of an effect, such as a method r the triggering of a transition. The request object is available to the execution of invoked procedures. The requestor continues execution without waiting for the request to be delivered or handled. If the invocation is repliable, a subsequent reply by the invoked execution is transmitted to the requesting object as an asynchronous request. If the invocation is not repliable, any attempt by the invoked execution to issue a reply is ignored.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::BroadcastSignalAction

Extends: ::Behavioral Elements::Actions::Messaging Actions::ExplicitInvocationAction

Creates a request signal that is transmitted to all the potential target objects in the system, where it may cause the firing of state machine transitions and the execution of attached procedures. The argument values are available to the execution of attached procedures. The requestor continues execution immediately. Any attempt to issue a reply is ignored.

The definition of the set of target objects in the system requires an implementation dependent specification, as any practical implementation of this action obviously requires a finite set of objects.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::CallOperationAction

Extends: ::Behavioral Elements::Actions::Messaging Actions::ExplicitInvocationAction

Assembles the call arguments into an operation call request that is transmitted to the target object, where it causes the selection of a method and the execution of its procedure. The argument values are available to the execution of the invoked procedure as predefined OutputPin values. (They are output pins because they represent values available within the procedure.) The action execution waits until the effect invoked by the request completes and returns to the caller. When the execution of a procedure is complete, its result values are returned to the calling execution. When a return message is received, execution of the action is complete and the return values are used as the result values of the call operation action execution.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::ExplicitInvocationAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Abstract action that indicates sending a request object to a target object using an explicit argument list. Creates a request that is transmitted to the target object. The request is resolved into a behavioral effect by the target object or its class based on the type of the request. Depending on the kind of action, the requestor may or may not wait for a reply.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::InvocationAction

Extends: ::Behavioral Elements::Actions::Action Foundation::PrimitiveAction

Abstract action that indicates sending a request object to a target object. Creates a request that is transmitted to the target object. The request is resolved into a behavioral effect by the target object or its class based on the type of the request. Depending on the kind of action, the requestor may or may not wait for a reply.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::SendSignalAction

Extends: ::Behavioral Elements::Actions::Messaging Actions::ExplicitInvocationAction

Creates a request signal that is transmitted to the target object where it may cause the firing of a state machine transition and the execution of an attached procedure. The argument values are available to the execution of attached procedures. The requestor continues execution without waiting for the request to be delivered or handled. Any attempt by the state machine to issue a reply is ignored.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Messaging Actions::SynchronousInvocationAction

Extends: ::Behavioral Elements::Actions::Messaging Actions::InvocationAction

Creates a request packet that is transmitted to the target object where it causes an effect, such as the execution of a method or the triggering of a transition. The request object is available to the execution of invoked procedures. The action execution waits until the effect invoked by the request completes and returns a reply message to the caller. When a reply message is received, execution of the action is complete and the reply message is used as the output of the call action execution.

Properties:

Operations:

Invariants:

Package - ::Behavioral Elements::Actions::Jump Actions

Class - ::Behavioral Elements::Actions::Jump Actions::HandlerAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

An action may have zero or more handlers attached to it. A handler deals with jumps that occur during the execution of its underlying action. A jump handler associates actions and jump types with the handler actions that replace the actions if a jump of the given type (or a descendant of the jump type) occurs. An action used as a handler is a kind of composite action. It must have one internal output pin; the output pin receives the jump occurrence object and makes it available within the handler action. A jump handler action must have a list of output pins that matches in number, order, and types the outputs of the action for which it handles jumps. If it does not have a matching list of output pins, it may still catch the jump, but it must re-raise the same or another jump rather than completing normally (otherwise the outputs of the original action would not be defined). The handler action has a body action (often a group action) that it executes. The occurrence pin is available to the body action as an available input.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Jump Actions::JumpAction

Extends: ::Behavioral Elements::Actions::Action Foundation::Action

An action whose execution causes the occurrence of a specified jump with specified arguments. The execution of this action has the remarkable property that it cannot complete normally. Although a jump handler could (somewhat perversely) be attached to the jump action itself, usually the purpose of a jump action is to terminate a group of actions containing the raise action and escape to a jump handler at some enclosing level. The use of this action is the normal way to represent break and continue statements from programming languages.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Jump Actions::JumpHandler

(not an action) Essentially the reification of a qualified association relating an Action and a jump type to the HandlerAction that is invoked if the jump occurs during the execution of the action.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Jump Actions::BreakJump

As the type of a jump, represents a traditional break statement. It has no attributes.

Properties:

Operations:

Invariants:

Class - ::Behavioral Elements::Actions::Jump Actions::ContinueJump

As the type of a jump, represents a traditional continue statement. It has no attributes.

Properties:

Operations:

Invariants: