deprecated/plugins/org.eclipse.uml2/model/UML2XMI.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xmi="http://www.omg.org/XMI" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/1.0.0/UML" targetNamespace="http://www.eclipse.org/uml2/1.0.0/UML">
  <xsd:import schemaLocation="ecore.xsd" namespace="http://www.eclipse.org/emf/2002/Ecore"/>
  <xsd:import schemaLocation="XMI.xsd" namespace="http://www.omg.org/XMI"/>
  <xsd:simpleType name="VisibilityKind">
    <xsd:annotation>
      <xsd:documentation>VisibilityKind is an enumeration of the following literal values: • public • private • protected • package </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="public"/>
      <xsd:enumeration value="private"/>
      <xsd:enumeration value="protected"/>
      <xsd:enumeration value="package"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ParameterDirectionKind">
    <xsd:annotation>
      <xsd:documentation>ParameterDirectionKind is an enumeration of the following literal values: • in Indicates that parameter values are passed into the behavioral element by the caller. • inout Indicates that parameter values are passed into a behavioral element by the caller and then back out to the caller from the behavioral element. • out Indicates that parameter values are passed from a behavioral element out to the caller. • return Indicates that parameter values are passed as return values from a behavioral element back to the caller. </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="in"/>
      <xsd:enumeration value="inout"/>
      <xsd:enumeration value="out"/>
      <xsd:enumeration value="return"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="AggregationKind">
    <xsd:annotation>
      <xsd:documentation>AggregationKind is an enumeration of the following literal values: • none Indicates that the property has no aggregation. • shared Indicates that the property has a shared aggregation. • composite Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts). </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="none"/>
      <xsd:enumeration value="shared"/>
      <xsd:enumeration value="composite"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="CallConcurrencyKind">
    <xsd:annotation>
      <xsd:documentation>CallConcurrencyKind is an enumeration with the following literals: • sequential No concurrency management mechanism is associated with the operation and, therefore, concurrency conflicts may occur. Instances that invoke a behavioral feature need to coordinate so that only one invocation to a target on any behavioral feature occurs at once. • guarded Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks. • concurrent Multiple invocations of a behavioral feature may occur simultaneously to one instance and all of them may proceed concurrently. </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="sequential"/>
      <xsd:enumeration value="guarded"/>
      <xsd:enumeration value="concurrent"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="MessageKind">
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="complete"/>
      <xsd:enumeration value="lost"/>
      <xsd:enumeration value="found"/>
      <xsd:enumeration value="unknown"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="MessageSort">
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="synchCall"/>
      <xsd:enumeration value="synchSignal"/>
      <xsd:enumeration value="asynchCall"/>
      <xsd:enumeration value="asynchSignal"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ExpansionKind">
    <xsd:annotation>
      <xsd:documentation> (ExtraStructuredActivities) ExpansionKind is an enumeration type used to specify how multiple executions of an expansion region interact. </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="parallel"/>
      <xsd:enumeration value="iterative"/>
      <xsd:enumeration value="stream"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="InteractionOperator">
    <xsd:annotation>
      <xsd:documentation>Interaction Operator is an enumeration designating the different kinds of operators of CombinedFragments. The InteractionOperand defines the type of operator of a CombinedFragment. </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="seq"/>
      <xsd:enumeration value="alt"/>
      <xsd:enumeration value="opt"/>
      <xsd:enumeration value="break"/>
      <xsd:enumeration value="par"/>
      <xsd:enumeration value="strict"/>
      <xsd:enumeration value="loop"/>
      <xsd:enumeration value="critical"/>
      <xsd:enumeration value="neg"/>
      <xsd:enumeration value="assert"/>
      <xsd:enumeration value="ignore"/>
      <xsd:enumeration value="consider"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="TransitionKind">
    <xsd:annotation>
      <xsd:documentation>TransitionKind is an enumeration of the following literal values: • external • internal • local </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="internal"/>
      <xsd:enumeration value="local"/>
      <xsd:enumeration value="external"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="PseudostateKind">
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="initial"/>
      <xsd:enumeration value="deepHistory"/>
      <xsd:enumeration value="shallowHistory"/>
      <xsd:enumeration value="join"/>
      <xsd:enumeration value="fork"/>
      <xsd:enumeration value="junction"/>
      <xsd:enumeration value="choice"/>
      <xsd:enumeration value="entryPoint"/>
      <xsd:enumeration value="exitPoint"/>
      <xsd:enumeration value="terminate"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ParameterEffectKind">
    <xsd:annotation>
      <xsd:documentation>The datatype ParameterEffectKind is an enumeration that indicates the effect of a behavior on values passed in or out of its parameters (see “Parameter (as specialized)” on page 354). </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="create"/>
      <xsd:enumeration value="read"/>
      <xsd:enumeration value="update"/>
      <xsd:enumeration value="delete"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ObjectNodeOrderingKind">
    <xsd:annotation>
      <xsd:documentation>ObjectNodeOrderingKind is an enumeration indicating queuing order within a node. </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="unordered"/>
      <xsd:enumeration value="ordered"/>
      <xsd:enumeration value="LIFO"/>
      <xsd:enumeration value="FIFO"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ConnectorKind">
    <xsd:restriction base="xsd:NCName">
      <xsd:enumeration value="assembly"/>
      <xsd:enumeration value="delegation"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:complexType name="Element">
    <xsd:annotation>
      <xsd:documentation>Element is an abstract metaclass with no superclass. It is used as the common superclass for all metaclasses in the infrastructure library. Element has a derived composition association to itself to support the general capability for elements to own other elements. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="ecore:EModelElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedComment" type="uml:Comment">
            <xsd:annotation>
              <xsd:documentation>The Comments owned by this element. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Element" type="uml:Element">
    <xsd:annotation>
      <xsd:documentation>Element is an abstract metaclass with no superclass. It is used as the common superclass for all metaclasses in the infrastructure library. Element has a derived composition association to itself to support the general capability for elements to own other elements. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="MultiplicityElement">
    <xsd:annotation>
      <xsd:documentation>A MultiplicityElement is an abstract metaclass which includes optional attributes for defining the bounds of a multiplicity. A MultiplicityElement also includes specifications of whether the values in an instantiation of this element must be unique or ordered. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="MultiplicityElement" type="uml:MultiplicityElement">
    <xsd:annotation>
      <xsd:documentation>A MultiplicityElement is an abstract metaclass which includes optional attributes for defining the bounds of a multiplicity. A MultiplicityElement also includes specifications of whether the values in an instantiation of this element must be unique or ordered. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="NamedElement">
    <xsd:annotation>
      <xsd:documentation>A named element represents elements that may have a name. The name is used for identification of the named element within the namespace in which it is defined. A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces. NamedElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="clientDependency" type="uml:Dependency"/>
          <xsd:element name="nameExpression" type="uml:StringExpression">
            <xsd:annotation>
              <xsd:documentation>The expression used to define the name of this named element.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="name" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The name of the NamedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Determines the visibility of the NamedElement within different Namespaces within the overall model. Package Dependencies (“Dependencies” on page 94)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="clientDependency" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="NamedElement" type="uml:NamedElement">
    <xsd:annotation>
      <xsd:documentation>A named element represents elements that may have a name. The name is used for identification of the named element within the namespace in which it is defined. A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces. NamedElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Namespace">
    <xsd:annotation>
      <xsd:documentation>A namespace is a named element that can own other named elements. Each named element may be owned by at most one namespace. A namespace provides a means for identifying named elements by name. Named elements can be identified by name in a namespace either by being directly owned by the namespace or by being introduced into the namespace by other means e.g. importing or inheriting. Namespace is an abstract metaclass. A namespace can own constraints. The constraint does not necessarily apply to the namespace itself, but may also apply to elements in the namespace. A namespace has the ability to import either individial members or all members of a package, thereby making it possible to refer to those named elements without qualification in the importing namespace. In the case of conflicts, it is necessary to use qualified names or aliases to disambiguate the referenced elements. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedRule" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Specifies a set of Constraints owned by this Namespace. Subsets Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="elementImport" type="uml:ElementImport">
            <xsd:annotation>
              <xsd:documentation>References the ElementImports owned by the Namespace. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="packageImport" type="uml:PackageImport">
            <xsd:annotation>
              <xsd:documentation>References the PackageImports owned by the Namespace. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Namespace" type="uml:Namespace">
    <xsd:annotation>
      <xsd:documentation>A namespace is a named element that can own other named elements. Each named element may be owned by at most one namespace. A namespace provides a means for identifying named elements by name. Named elements can be identified by name in a namespace either by being directly owned by the namespace or by being introduced into the namespace by other means e.g. importing or inheriting. Namespace is an abstract metaclass. A namespace can own constraints. The constraint does not necessarily apply to the namespace itself, but may also apply to elements in the namespace. A namespace has the ability to import either individial members or all members of a package, thereby making it possible to refer to those named elements without qualification in the importing namespace. In the case of conflicts, it is necessary to use qualified names or aliases to disambiguate the referenced elements. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="OpaqueExpression">
    <xsd:annotation>
      <xsd:documentation>An expression contains a language-specific text string used to describe a value or values, and an optional specification of the language. One predefined language for specifying expressions is OCL. Natural language or programming languages may also be used. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="behavior" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>Specifies the behavior of the opaque expression.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="body" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The text of the expression.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="language" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the language in which the expression is stated. The interpretation of the expression body depends on the language. If language is unspecified, it might be implicit from the expression body or the context.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="behavior" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the behavior of the opaque expression.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="OpaqueExpression" type="uml:OpaqueExpression">
    <xsd:annotation>
      <xsd:documentation>An expression contains a language-specific text string used to describe a value or values, and an optional specification of the language. One predefined language for specifying expressions is OCL. Natural language or programming languages may also be used. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ValueSpecification">
    <xsd:annotation>
      <xsd:documentation>ValueSpecification is an abstract metaclass used to identify a value or values in a model. It may reference an instance or it may be an expression denoting an instance or instances when evaluated. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TypedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ValueSpecification" type="uml:ValueSpecification">
    <xsd:annotation>
      <xsd:documentation>ValueSpecification is an abstract metaclass used to identify a value or values in a model. It may reference an instance or it may be an expression denoting an instance or instances when evaluated. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Expression">
    <xsd:annotation>
      <xsd:documentation>An expression represents a node in an expression tree, which may be non-terminal or terminal. It defines a symbol, and has a possibly empty sequence of operands which are value specifications. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:OpaqueExpression">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="operand" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Specifies a sequence of operands. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="symbol" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The symbol associated with the node in the expression tree.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Expression" type="uml:Expression">
    <xsd:annotation>
      <xsd:documentation>An expression represents a node in an expression tree, which may be non-terminal or terminal. It defines a symbol, and has a possibly empty sequence of operands which are value specifications. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Comment">
    <xsd:annotation>
      <xsd:documentation>A comment gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler. A comment can be owned by any element. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="annotatedElement" type="uml:Element">
            <xsd:annotation>
              <xsd:documentation>References the Element(s) being commented.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="bodyExpression" type="uml:StringExpression"/>
        </xsd:choice>
        <xsd:attribute name="body" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies a string that is the comment.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="annotatedElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Element(s) being commented.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Comment" type="uml:Comment">
    <xsd:annotation>
      <xsd:documentation>A comment gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler. A comment can be owned by any element. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DirectedRelationship">
    <xsd:annotation>
      <xsd:documentation>A directed relationship references one or more source elements and one or more target elements. Directed relationship is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Relationship"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DirectedRelationship" type="uml:DirectedRelationship">
    <xsd:annotation>
      <xsd:documentation>A directed relationship references one or more source elements and one or more target elements. Directed relationship is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Relationship">
    <xsd:annotation>
      <xsd:documentation>A relationship references one or more related elements. Relationship is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Relationship" type="uml:Relationship">
    <xsd:annotation>
      <xsd:documentation>A relationship references one or more related elements. Relationship is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Class">
    <xsd:annotation>
      <xsd:documentation>Class is a kind of classifier whose features are attributes and operations. Attributes of a class are represented by instances of Property that are owned by the class. Some of these attributes may represent the navigable ends of binary associations. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:BehavioredClassifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>References the properties owned by the classifier. (Subsets StructuredClassifier.role, Classifier. attribute,and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedConnector" type="uml:Connector">
            <xsd:annotation>
              <xsd:documentation>References the connectors owned by the classifier. (Subsets Classifier.feature and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedPort" type="uml:Port">
            <xsd:annotation>
              <xsd:documentation>References a set of ports that an encapsulated classifier owns. (Subsets Classifier.feature and Namespace.ownedMember.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedOperation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>The operations owned by the class. The association is ordered. Subsets Classifier::feature and Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="nestedClassifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>References all the Classifiers that are defined (nested) within the Class. Subsets Element:: ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedReception" type="uml:Reception">
            <xsd:annotation>
              <xsd:documentation>Receptions that objects of this class are willing to accept. (Specializes Namespace.owned- Member and Classifier.feature.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isActive" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Determines whether an object specified by this class is active or not. If true, then the owning class is referred to as an active class. If false, then such a class is referred to as a passive class.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Class" type="uml:Class">
    <xsd:annotation>
      <xsd:documentation>Class is a kind of classifier whose features are attributes and operations. Attributes of a class are represented by instances of Property that are owned by the class. Some of these attributes may represent the navigable ends of binary associations. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Type">
    <xsd:annotation>
      <xsd:documentation>A type serves as a constraint on the range of values represented by a typed element. Type is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Type" type="uml:Type">
    <xsd:annotation>
      <xsd:documentation>A type serves as a constraint on the range of values represented by a typed element. Type is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Property">
    <xsd:annotation>
      <xsd:documentation>Property represents a declared state of one or more instances in terms of a named relationship to a value or values. When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance. When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association (see semantics of Association). Property is indirectly a subclass of Constructs::TypedElement. The range of valid values represented by the property can be controlled by setting the property’s type. Package AssociationClasses (“AssociationClasses” on page 107) A property may have other properties (attributes) that serve as qualifiers. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuralFeature">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
          <xsd:element name="end" type="uml:ConnectorEnd">
            <xsd:annotation>
              <xsd:documentation>Denotes a connector that attaches to this connectable element.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="deployment" type="uml:Deployment"/>
          <xsd:element name="redefinedProperty" type="uml:Property"/>
          <xsd:element name="subsettedProperty" type="uml:Property"/>
          <xsd:element name="association" type="uml:Association">
            <xsd:annotation>
              <xsd:documentation>References the association of which this property is a member, if any.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="defaultValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>A ValueSpecification that is evaluated to give a default value for the Property when an object of the owning Classifier is is instantiated. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="qualifier" type="uml:Property"/>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="end" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Denotes a connector that attaches to this connectable element.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isDerived" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the Property is derived, i.e., whether its value or values can be computed from other information. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isDerivedUnion" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="aggregation" type="uml:AggregationKind">
          <xsd:annotation>
            <xsd:documentation>Specifies the kind of aggregation that applies to the Property. The default value is none.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedProperty" type="xsd:string"/>
        <xsd:attribute name="subsettedProperty" type="xsd:string"/>
        <xsd:attribute name="association" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the association of which this property is a member, if any.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Property" type="uml:Property">
    <xsd:annotation>
      <xsd:documentation>Property represents a declared state of one or more instances in terms of a named relationship to a value or values. When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance. When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association (see semantics of Association). Property is indirectly a subclass of Constructs::TypedElement. The range of valid values represented by the property can be controlled by setting the property’s type. Package AssociationClasses (“AssociationClasses” on page 107) A property may have other properties (attributes) that serve as qualifiers. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Operation">
    <xsd:annotation>
      <xsd:documentation>An operation is a behavioral feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behavior. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:BehavioralFeature">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
          <xsd:element name="ownedParameter" type="uml:Parameter"/>
          <xsd:element name="precondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>An optional set of Constraints on the state of the system when the Operation is invoked. Subsets Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="postcondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>An optional set of Constraints specifying the state of the system when the Operation is completed. Subsets Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="redefinedOperation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>the Operations that are redefined by this Operation. Subsets RedefinableElement. redefinedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="bodyCondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="isQuery" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false). The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="precondition" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An optional set of Constraints on the state of the system when the Operation is invoked. Subsets Namespace::ownedMember.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="postcondition" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An optional set of Constraints specifying the state of the system when the Operation is completed. Subsets Namespace::ownedMember.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedOperation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the Operations that are redefined by this Operation. Subsets RedefinableElement. redefinedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="bodyCondition" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedMember.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Operation" type="uml:Operation">
    <xsd:annotation>
      <xsd:documentation>An operation is a behavioral feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behavior. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TypedElement">
    <xsd:annotation>
      <xsd:documentation>A typed element is an element that has a type that serves as a constraint on the range of values the element can represent. Typed element is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TypedElement" type="uml:TypedElement">
    <xsd:annotation>
      <xsd:documentation>A typed element is an element that has a type that serves as a constraint on the range of values the element can represent. Typed element is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Parameter">
    <xsd:annotation>
      <xsd:documentation>A parameter is a specification of an argument used to pass information into or out of an invocation of a behavioral feature. It has a type, and may have a multiplicity and an optional default value. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ConnectableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="defaultValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Specifies a ValueSpecification that represents a value to be used when no argument is supplied for the Parameter. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="parameterSet" type="uml:ParameterSet"/>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="direction" type="uml:ParameterDirectionKind">
          <xsd:annotation>
            <xsd:documentation>Indicates whether a parameter is being sent into or out of a behavioral element. The default value is in.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isException" type="xsd:string"/>
        <xsd:attribute name="isStream" type="xsd:string"/>
        <xsd:attribute name="effect" type="uml:ParameterEffectKind"/>
        <xsd:attribute name="parameterSet" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Parameter" type="uml:Parameter">
    <xsd:annotation>
      <xsd:documentation>A parameter is a specification of an argument used to pass information into or out of an invocation of a behavioral feature. It has a type, and may have a multiplicity and an optional default value. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Package">
    <xsd:annotation>
      <xsd:documentation>A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages, or all the members of other packages. In addition a package can be merged with other packages. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
          <xsd:element name="ownedMember" type="uml:PackageableElement">
            <xsd:annotation>
              <xsd:documentation>Specifies the members that are owned by this Package. Redefines Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="packageMerge" type="uml:PackageMerge"/>
          <xsd:element name="appliedProfile" type="uml:ProfileApplication"/>
          <xsd:element name="packageExtension" type="uml:PackageMerge"/>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="packageableElement_visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Indicates that packageable elements must always have a visibility, i.e., visibility is not optional. Redefines NamedElement::visibility.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="appliedProfile" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Package" type="uml:Package">
    <xsd:annotation>
      <xsd:documentation>A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages, or all the members of other packages. In addition a package can be merged with other packages. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Enumeration">
    <xsd:annotation>
      <xsd:documentation>Enumeration is a kind of data type, whose instances may be any of a number of user-defined enumeration literals. It is possible to extend the set of applicable enumeration literals in other packages or profiles. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DataType">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedLiteral" type="uml:EnumerationLiteral">
            <xsd:annotation>
              <xsd:documentation>ordered set of literals for this Enumeration. Subsets Element::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Enumeration" type="uml:Enumeration">
    <xsd:annotation>
      <xsd:documentation>Enumeration is a kind of data type, whose instances may be any of a number of user-defined enumeration literals. It is possible to extend the set of applicable enumeration literals in other packages or profiles. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DataType">
    <xsd:annotation>
      <xsd:documentation>DataType defines a kind of classifier in which operations are all pure functions (i.e., they can return data values but they cannot change data values, 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. A DataType may also contain attributes to support the modeling of structured data types. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>The Attributes owned by the DataType. Subsets Classifier::attribute and Element:: ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedOperation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>The Operations owned by the DataType. Subsets Classifier::feature and Element:: ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DataType" type="uml:DataType">
    <xsd:annotation>
      <xsd:documentation>DataType defines a kind of classifier in which operations are all pure functions (i.e., they can return data values but they cannot change data values, 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. A DataType may also contain attributes to support the modeling of structured data types. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="EnumerationLiteral">
    <xsd:annotation>
      <xsd:documentation>An enumeration literal is a user-defined data value for an enumeration. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InstanceSpecification"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="EnumerationLiteral" type="uml:EnumerationLiteral">
    <xsd:annotation>
      <xsd:documentation>An enumeration literal is a user-defined data value for an enumeration. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PrimitiveType">
    <xsd:annotation>
      <xsd:documentation>The instances of primitive type used in UML itself include Boolean, Integer, UnlimitedNatural, and String. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DataType"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PrimitiveType" type="uml:PrimitiveType">
    <xsd:annotation>
      <xsd:documentation>The instances of primitive type used in UML itself include Boolean, Integer, UnlimitedNatural, and String. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Classifier">
    <xsd:annotation>
      <xsd:documentation>A classifier is a namespace whose members can include features. Classifier is an abstract metaclass. A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers. A classifier can specify a generalization hierarchy by referencing its general classifiers. A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
          <xsd:element name="generalization" type="uml:Generalization"/>
          <xsd:element name="redefinedClassifier" type="uml:Classifier"/>
          <xsd:element name="substitution" type="uml:Substitution"/>
          <xsd:element name="powertypeExtent" type="uml:GeneralizationSet"/>
          <xsd:element name="ownedUseCase" type="uml:UseCase"/>
          <xsd:element name="useCase" type="uml:UseCase"/>
          <xsd:element name="representation" type="uml:CollaborationOccurrence">
            <xsd:annotation>
              <xsd:documentation>References a collaboration occurrence which indicates the collaboration that represents this classifier. (Subsets Classifier.occurrence.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="occurrence" type="uml:CollaborationOccurrence">
            <xsd:annotation>
              <xsd:documentation>References the collaboration occurrences owned by the classifier. (Subsets Element. ownedElement.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="packageableElement_visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Indicates that packageable elements must always have a visibility, i.e., visibility is not optional. Redefines NamedElement::visibility.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isLeaf" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isAbstract" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>If true, the Classifier does not provide a complete declaration and can typically not be instantiated. An abstract classifier is intended to be used by other classifiers e.g. as the target of general metarelationships or generalization relationships. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedClassifier" type="xsd:string"/>
        <xsd:attribute name="powertypeExtent" type="xsd:string"/>
        <xsd:attribute name="useCase" type="xsd:string"/>
        <xsd:attribute name="representation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References a collaboration occurrence which indicates the collaboration that represents this classifier. (Subsets Classifier.occurrence.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Classifier" type="uml:Classifier">
    <xsd:annotation>
      <xsd:documentation>A classifier is a namespace whose members can include features. Classifier is an abstract metaclass. A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers. A classifier can specify a generalization hierarchy by referencing its general classifiers. A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Feature">
    <xsd:annotation>
      <xsd:documentation>A feature declares a behavioral or structural characteristic of instances of classifiers. Feature is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement">
        <xsd:attribute name="isStatic" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the feature is applied at the classifier-level (true) or the instance-level (false). Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Feature" type="uml:Feature">
    <xsd:annotation>
      <xsd:documentation>A feature declares a behavioral or structural characteristic of instances of classifiers. Feature is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Constraint">
    <xsd:annotation>
      <xsd:documentation>Constraint contains a ValueSpecification that specifies additional semantics for one or more elements. Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML, others may be user-defined. A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility. One predefined language for writing constraints is OCL. In some situations, a programming language such as Java may be appropriate for expressing a constraint. In other situations natural language may be used. Constraint is a condition (a Boolean expression) that restricts the extension of the associated element beyond what is imposed by the other language constructs applied to that element. Constraint contains an optional name, although they are commonly unnamed. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="specification" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>A condition that must be true when evaluated in order for the constraint to be satisfied. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="constrainedElement" type="uml:Element">
            <xsd:annotation>
              <xsd:documentation>ordered set of Elements referenced by this Constraint.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="constrainedElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>ordered set of Elements referenced by this Constraint.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Constraint" type="uml:Constraint">
    <xsd:annotation>
      <xsd:documentation>Constraint contains a ValueSpecification that specifies additional semantics for one or more elements. Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML, others may be user-defined. A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility. One predefined language for writing constraints is OCL. In some situations, a programming language such as Java may be appropriate for expressing a constraint. In other situations natural language may be used. Constraint is a condition (a Boolean expression) that restricts the extension of the associated element beyond what is imposed by the other language constructs applied to that element. Constraint contains an optional name, although they are commonly unnamed. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralBoolean">
    <xsd:annotation>
      <xsd:documentation>A literal boolean contains a Boolean-valued attribute. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LiteralSpecification">
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The specified Boolean value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralBoolean" type="uml:LiteralBoolean">
    <xsd:annotation>
      <xsd:documentation>A literal boolean contains a Boolean-valued attribute. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralSpecification">
    <xsd:annotation>
      <xsd:documentation>A literal specification is an abstract specialization of ValueSpecification that identifies a literal constant being modeled. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralSpecification" type="uml:LiteralSpecification">
    <xsd:annotation>
      <xsd:documentation>A literal specification is an abstract specialization of ValueSpecification that identifies a literal constant being modeled. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralString">
    <xsd:annotation>
      <xsd:documentation>A literal string contains a String-valued attribute. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LiteralSpecification">
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The specified String value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralString" type="uml:LiteralString">
    <xsd:annotation>
      <xsd:documentation>A literal string contains a String-valued attribute. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralNull">
    <xsd:annotation>
      <xsd:documentation>A literal null is used to represent null, i.e., the absence of a value. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LiteralSpecification"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralNull" type="uml:LiteralNull">
    <xsd:annotation>
      <xsd:documentation>A literal null is used to represent null, i.e., the absence of a value. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralInteger">
    <xsd:annotation>
      <xsd:documentation>A literal integer contains an Integer-valued attribute. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LiteralSpecification">
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The specified Integer value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralInteger" type="uml:LiteralInteger">
    <xsd:annotation>
      <xsd:documentation>A literal integer contains an Integer-valued attribute. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LiteralUnlimitedNatural">
    <xsd:annotation>
      <xsd:documentation>A literal unlimited natural contains a UnlimitedNatural-valued attribute. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LiteralSpecification">
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The specified UnlimitedNatural value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LiteralUnlimitedNatural" type="uml:LiteralUnlimitedNatural">
    <xsd:annotation>
      <xsd:documentation>A literal unlimited natural contains a UnlimitedNatural-valued attribute. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="BehavioralFeature">
    <xsd:annotation>
      <xsd:documentation>A behavioral feature specifies that an instance of a classifier will respond to a designated request by invoking a behavior. BehavioralFeature is an abstract metaclass specializing Feature and Namespace. Kinds of behavioral aspects are modeled by subclasses of BehavioralFeature. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="formalParameter" type="uml:Parameter">
            <xsd:annotation>
              <xsd:documentation>Specifies the ordered set of formal parameters of this BehavioralFeature. Subsets BehavioralFeature::parameter and Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="returnResult" type="uml:Parameter">
            <xsd:annotation>
              <xsd:documentation>Specifies the ordered set of return results of this BehavioralFeature. Subsets Behavioral- Feature::parameter and Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="raisedException" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>References the Types representing exceptions that may be raised during an invocation of this operation.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="method" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>A behavioral description that implements the behavioral feature. There may be at most one behavior for a particular pairing of a classifier (as owner of the behavior) and a behavioral feature (as specification of the behavior).</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isLeaf" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isStatic" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the feature is applied at the classifier-level (true) or the instance-level (false). Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isAbstract" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>If true, then the behavioral feature does not have an implementation, and one must be supplied by a more specific element. If false, the behavioral feature must have an implementation in the classifier or one must be inherited from a more general element. Communications</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="concurrency" type="uml:CallConcurrencyKind"/>
        <xsd:attribute name="raisedException" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Types representing exceptions that may be raised during an invocation of this operation.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="method" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A behavioral description that implements the behavioral feature. There may be at most one behavior for a particular pairing of a classifier (as owner of the behavior) and a behavioral feature (as specification of the behavior).</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="BehavioralFeature" type="uml:BehavioralFeature">
    <xsd:annotation>
      <xsd:documentation>A behavioral feature specifies that an instance of a classifier will respond to a designated request by invoking a behavior. BehavioralFeature is an abstract metaclass specializing Feature and Namespace. Kinds of behavioral aspects are modeled by subclasses of BehavioralFeature. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StructuralFeature">
    <xsd:annotation>
      <xsd:documentation>A structural feature is a typed feature of a classifier that specify the structure of instances of the classifier. Structural feature is an abstract metaclass. By specializing multiplicity element, it supports a multiplicity that specifies valid cardinalities for the set of values associated with an instantiation of the structural feature. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Feature">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isReadOnly" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>States whether the feature’s value may be modified by a client. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StructuralFeature" type="uml:StructuralFeature">
    <xsd:annotation>
      <xsd:documentation>A structural feature is a typed feature of a classifier that specify the structure of instances of the classifier. Structural feature is an abstract metaclass. By specializing multiplicity element, it supports a multiplicity that specifies valid cardinalities for the set of values associated with an instantiation of the structural feature. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InstanceSpecification">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, InstanceSpecification is a specialization of DeploymentTarget and DeployedArtifact. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="deployment" type="uml:Deployment"/>
          <xsd:element name="slot" type="uml:Slot">
            <xsd:annotation>
              <xsd:documentation>A slot giving the value or values of a structural feature of the instance. An instance specification can have one slot per structural feature of its classifiers, including inherited features. It is not necessary to model a slot for each structural feature, in which case the instance specification is a partial description. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="classifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>The classifier or classifiers of the represented instance. If multiple classifiers are specified, the instance is classified by all of them.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="specification" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>A specification of how to compute, derive, or construct the instance. Subsets Element:: ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="classifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The classifier or classifiers of the represented instance. If multiple classifiers are specified, the instance is classified by all of them.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InstanceSpecification" type="uml:InstanceSpecification">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, InstanceSpecification is a specialization of DeploymentTarget and DeployedArtifact. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Slot">
    <xsd:annotation>
      <xsd:documentation>A slot is owned by an instance specification. It specifies the value or values for its defining feature, which must be a structural feature of a classifier of the instance specification owning the slot. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="value" type="uml:ValueSpecification"/>
          <xsd:element name="definingFeature" type="uml:StructuralFeature">
            <xsd:annotation>
              <xsd:documentation>The structural feature that specifies the values that may be held by the slot.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="definingFeature" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The structural feature that specifies the values that may be held by the slot.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Slot" type="uml:Slot">
    <xsd:annotation>
      <xsd:documentation>A slot is owned by an instance specification. It specifies the value or values for its defining feature, which must be a structural feature of a classifier of the instance specification owning the slot. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InstanceValue">
    <xsd:annotation>
      <xsd:documentation>An instance value specifies the value modeled by an instance specification. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="instance" type="uml:InstanceSpecification">
            <xsd:annotation>
              <xsd:documentation>The instance that is the specified value.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="instance" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The instance that is the specified value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InstanceValue" type="uml:InstanceValue">
    <xsd:annotation>
      <xsd:documentation>An instance value specifies the value modeled by an instance specification. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="RedefinableElement">
    <xsd:annotation>
      <xsd:documentation>A redefinable element is a named element that can be redefined in the context of a generalization. RedefinableElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:attribute name="isLeaf" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="RedefinableElement" type="uml:RedefinableElement">
    <xsd:annotation>
      <xsd:documentation>A redefinable element is a named element that can be redefined in the context of a generalization. RedefinableElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Generalization">
    <xsd:annotation>
      <xsd:documentation>A generalization relates a specific classifier to a more general classifier, and is owned by the specific classifier. Package PowerTypes (“PowerTypes” on page 109) A generalization can be designated as being a member of a particular generalization set. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="general" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>References the general classifier in the Generalization relationship. Subsets DirectedRelationship::target.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="generalizationSet" type="uml:GeneralizationSet"/>
        </xsd:choice>
        <xsd:attribute name="isSubstitutable" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether the specific classifier can be used whereever the general classifier can be used. If true, the execution traces of the specific classifier will be a superset of the execution traces of the general classifier.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="general" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the general classifier in the Generalization relationship. Subsets DirectedRelationship::target.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="generalizationSet" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Generalization" type="uml:Generalization">
    <xsd:annotation>
      <xsd:documentation>A generalization relates a specific classifier to a more general classifier, and is owned by the specific classifier. Package PowerTypes (“PowerTypes” on page 109) A generalization can be designated as being a member of a particular generalization set. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PackageableElement">
    <xsd:annotation>
      <xsd:documentation>A packageable element indicates a named element that may be owned directly by a package. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="packageableElement_visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Indicates that packageable elements must always have a visibility, i.e., visibility is not optional. Redefines NamedElement::visibility.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PackageableElement" type="uml:PackageableElement">
    <xsd:annotation>
      <xsd:documentation>A packageable element indicates a named element that may be owned directly by a package. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ElementImport">
    <xsd:annotation>
      <xsd:documentation>An element import is defined as a directed relationship between an importing namespace and a packageable element. The name of the packageable element or its alias is to be added to the namespace of the importing namespace. It is also possible to control whether the imported element can be further imported. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="importedElement" type="uml:PackageableElement">
            <xsd:annotation>
              <xsd:documentation>Specifies the PackageableElement whose name is to be added to a Namespace. Subsets DirectedRelationship::target.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Specifies the visibility of the imported PackageableElement within the importing Package. The default visibility is the same as that of the imported element. If the imported element does not have a visibility, it is possible to add visibility to the element import.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="alias" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the name that should be added to the namespace of the importing Pack-age in lieu of the name of the imported PackagableElement. The aliased name must not clash with any other member name in the importing Package. By default, no alias is used.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="importedElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the PackageableElement whose name is to be added to a Namespace. Subsets DirectedRelationship::target.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ElementImport" type="uml:ElementImport">
    <xsd:annotation>
      <xsd:documentation>An element import is defined as a directed relationship between an importing namespace and a packageable element. The name of the packageable element or its alias is to be added to the namespace of the importing namespace. It is also possible to control whether the imported element can be further imported. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PackageImport">
    <xsd:annotation>
      <xsd:documentation>A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="importedPackage" type="uml:Package">
            <xsd:annotation>
              <xsd:documentation>Specifies the Package whose members are imported into a Namespace. Subsets DirectedRelationship::target.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="visibility" type="uml:VisibilityKind">
          <xsd:annotation>
            <xsd:documentation>Specifies the visibility of the imported PackageableElements within the import-ing Namespace, i.e., whether imported elements will in turn be visible to other packages that use that importingPackage as an importedPackage. If the PackageImport is public, the imported elements will be visible outside the package, while if it is private they will not. By default, the value of visibility is public.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="importedPackage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the Package whose members are imported into a Namespace. Subsets DirectedRelationship::target.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PackageImport" type="uml:PackageImport">
    <xsd:annotation>
      <xsd:documentation>A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Association">
    <xsd:annotation>
      <xsd:documentation>An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type. When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedEnd" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>The non-navigable ends that are owned by the association itself. This is an ordered association. Subsets Association::memberEnd, Classifier::feature, and Namespace::owned- Member.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="memberEnd" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDerived" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the association is derived from other model elements such as other associations or constraints. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="memberEnd" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Association" type="uml:Association">
    <xsd:annotation>
      <xsd:documentation>An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type. When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PackageMerge">
    <xsd:annotation>
      <xsd:documentation>A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified. From an XMI point of view, it is either possible to exchange a model with all PackageMerges retained or a model where all PackageMerges have been transformed away (in which case package imports, generalizations, and redefinitions are used instead). </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="mergedPackage" type="uml:Package">
            <xsd:annotation>
              <xsd:documentation>References the Package that is to be merged with the source of the PackageMerge. Subsets DirectedRelationship;;target.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="mergedPackage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Package that is to be merged with the source of the PackageMerge. Subsets DirectedRelationship;;target.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PackageMerge" type="uml:PackageMerge">
    <xsd:annotation>
      <xsd:documentation>A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified. From an XMI point of view, it is either possible to exchange a model with all PackageMerges retained or a model where all PackageMerges have been transformed away (in which case package imports, generalizations, and redefinitions are used instead). </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Stereotype">
    <xsd:complexContent>
      <xsd:extension base="uml:Class"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Stereotype" type="uml:Stereotype"/>
  <xsd:complexType name="Profile">
    <xsd:complexContent>
      <xsd:extension base="uml:Package">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="metaclassReference" type="uml:ElementImport"/>
          <xsd:element name="metamodelReference" type="uml:PackageImport"/>
        </xsd:choice>
        <xsd:attribute name="metaclassReference" type="xsd:string"/>
        <xsd:attribute name="metamodelReference" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Profile" type="uml:Profile"/>
  <xsd:complexType name="ProfileApplication">
    <xsd:complexContent>
      <xsd:extension base="uml:PackageImport">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="importedProfile" type="uml:Profile"/>
        </xsd:choice>
        <xsd:attribute name="importedProfile" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ProfileApplication" type="uml:ProfileApplication"/>
  <xsd:complexType name="Extension">
    <xsd:complexContent>
      <xsd:extension base="uml:Association"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Extension" type="uml:Extension"/>
  <xsd:complexType name="ExtensionEnd">
    <xsd:complexContent>
      <xsd:extension base="uml:Property"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExtensionEnd" type="uml:ExtensionEnd"/>
  <xsd:complexType name="Behavior">
    <xsd:annotation>
      <xsd:documentation>Behavior is a specification of how its context classifier changes state over time. This specification may be either a definition of possible behavior execution or emergent behavior, or a selective illustration of an interesting subset of possible executions. The latter form is typically used for capturing examples, such as a trace of a particular execution. A classifier behavior is always a definition of behavior and not an illustration. It describes the sequence of state changes an instance of a classifier may undergo in the course of its lifetime. Its precise semantics depends on the kind of classifier. For example, the classifier behavior of a collaboration represents emergent behavior of all the parts, whereas the classifier behavior of a class is just the behavior of instances of the class separated from the behaviors of any of its parts. When a behavior is associated as the method of a behavioral feature, it defines the implementation of that feature; i.e., the computation that generates the effects of the behavioral feature. As a classifier, a behavior can be specialized. Instantiating a behavior is referred to as “invocating” the behavior, an instantiated behavior is also called a behavior “execution.” A behavior may be invoked directly or its invocation may be the result of invoking the behavioral feature that specifies this behavior. A behavior can also be instantiated as an object in virtue of it being a class. The specification of a behavior can take a number of forms, as described in the subclasses of Behavior. Behavior is an abstract metaclass factoring out the commonalities of these different specification mechanisms. When a behavior is invoked, its execution receives a set of input values that are used to affect the course of execution and as a result of its execution it produces a set of output values which are returned, as specified by its parameters. The observable effects of a behavior execution may include changes of values of various objects involved in the execution, the creation and destruction of objects, generation of communications between objects, as well as an explicit set of output values. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Class">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="redefinedBehavior" type="uml:Behavior"/>
          <xsd:element name="specification" type="uml:BehavioralFeature">
            <xsd:annotation>
              <xsd:documentation>Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole).</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="parameter" type="uml:Parameter">
            <xsd:annotation>
              <xsd:documentation>References a list of parameters to the behavior which describes the order and type of arguments that can be given when the behavior is invoked and of the values which will be returned when the behavior completes its execution. (Specializes Namespace.owned- Member.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="precondition" type="uml:Constraint"/>
          <xsd:element name="postcondition" type="uml:Constraint"/>
          <xsd:element name="ownedParameterSet" type="uml:ParameterSet"/>
        </xsd:choice>
        <xsd:attribute name="isReentrant" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Tells whether the behavior can be invoked while it is still executing from a previous invocation.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedBehavior" type="xsd:string"/>
        <xsd:attribute name="specification" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole).</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="precondition" type="xsd:string"/>
        <xsd:attribute name="postcondition" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Behavior" type="uml:Behavior">
    <xsd:annotation>
      <xsd:documentation>Behavior is a specification of how its context classifier changes state over time. This specification may be either a definition of possible behavior execution or emergent behavior, or a selective illustration of an interesting subset of possible executions. The latter form is typically used for capturing examples, such as a trace of a particular execution. A classifier behavior is always a definition of behavior and not an illustration. It describes the sequence of state changes an instance of a classifier may undergo in the course of its lifetime. Its precise semantics depends on the kind of classifier. For example, the classifier behavior of a collaboration represents emergent behavior of all the parts, whereas the classifier behavior of a class is just the behavior of instances of the class separated from the behaviors of any of its parts. When a behavior is associated as the method of a behavioral feature, it defines the implementation of that feature; i.e., the computation that generates the effects of the behavioral feature. As a classifier, a behavior can be specialized. Instantiating a behavior is referred to as “invocating” the behavior, an instantiated behavior is also called a behavior “execution.” A behavior may be invoked directly or its invocation may be the result of invoking the behavioral feature that specifies this behavior. A behavior can also be instantiated as an object in virtue of it being a class. The specification of a behavior can take a number of forms, as described in the subclasses of Behavior. Behavior is an abstract metaclass factoring out the commonalities of these different specification mechanisms. When a behavior is invoked, its execution receives a set of input values that are used to affect the course of execution and as a result of its execution it produces a set of output values which are returned, as specified by its parameters. The observable effects of a behavior execution may include changes of values of various objects involved in the execution, the creation and destruction of objects, generation of communications between objects, as well as an explicit set of output values. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="BehavioredClassifier">
    <xsd:annotation>
      <xsd:documentation>A classifier can have behavior specifications defined in its namespace. One of these may specify the behavior of the classifier itself. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedBehavior" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>References behavior specifications owned by a classifier. (Specializes Namespace.owned- Member.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="classifierBehavior" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>A behavior specification that specifies the behavior of the classifier itself. (Specializes BehavioredClassifier.ownedBehavior.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="implementation" type="uml:Implementation">
            <xsd:annotation>
              <xsd:documentation>(Specializes Element.ownedElement and Realization.clientDependency.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedTrigger" type="uml:Trigger"/>
          <xsd:element name="ownedStateMachine" type="uml:StateMachine"/>
        </xsd:choice>
        <xsd:attribute name="classifierBehavior" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A behavior specification that specifies the behavior of the classifier itself. (Specializes BehavioredClassifier.ownedBehavior.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="BehavioredClassifier" type="uml:BehavioredClassifier">
    <xsd:annotation>
      <xsd:documentation>A classifier can have behavior specifications defined in its namespace. One of these may specify the behavior of the classifier itself. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Activity">
    <xsd:annotation>
      <xsd:documentation>An activity contains a language-specific text string used to describe a computation, and an optional specification of the language. OCL, natural language, or programming languages may be used to specify an activity. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Behavior">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="edge" type="uml:ActivityEdge"/>
          <xsd:element name="group" type="uml:ActivityGroup"/>
          <xsd:element name="node" type="uml:ActivityNode"/>
          <xsd:element name="action" type="uml:Action"/>
        </xsd:choice>
        <xsd:attribute name="body" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A textual representation of the computation in the surface language determined by the language attribute.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="language" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the language in which the body of the activity is stated. The interpretation of the expression body depends on the language.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isSingleExecution" type="xsd:string"/>
        <xsd:attribute name="isReadOnly" type="xsd:string"/>
        <xsd:attribute name="action" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Activity" type="uml:Activity">
    <xsd:annotation>
      <xsd:documentation>An activity contains a language-specific text string used to describe a computation, and an optional specification of the language. OCL, natural language, or programming languages may be used to specify an activity. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Permission">
    <xsd:annotation>
      <xsd:documentation>A Permission signifies granting of access rights from the supplier model element to a client model element. Or to put it another way, it signifies that the client requires access to some or all of the constituent elements of the supplier. The supplier element gives the client permission to access some or all of its constituents elements. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Dependency"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Permission" type="uml:Permission">
    <xsd:annotation>
      <xsd:documentation>A Permission signifies granting of access rights from the supplier model element to a client model element. Or to put it another way, it signifies that the client requires access to some or all of the constituent elements of the supplier. The supplier element gives the client permission to access some or all of its constituents elements. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Dependency">
    <xsd:annotation>
      <xsd:documentation>A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s). </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="client" type="uml:NamedElement">
            <xsd:annotation>
              <xsd:documentation>The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="supplier" type="uml:NamedElement">
            <xsd:annotation>
              <xsd:documentation>Designates the element that is unaffected by a change. In a two-way relationship (such as some Refinement Abstractions) this would be the more general element. In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="client" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="supplier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Designates the element that is unaffected by a change. In a two-way relationship (such as some Refinement Abstractions) this would be the more general element. In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Dependency" type="uml:Dependency">
    <xsd:annotation>
      <xsd:documentation>A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s). </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Usage">
    <xsd:annotation>
      <xsd:documentation>A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Dependency"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Usage" type="uml:Usage">
    <xsd:annotation>
      <xsd:documentation>A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Abstraction">
    <xsd:annotation>
      <xsd:documentation>An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Dependency">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="mapping" type="uml:OpaqueExpression">
            <xsd:annotation>
              <xsd:documentation>An composition of an Expression 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 expression is optional and may be omitted if the precise relationship between the elements is not specified.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Abstraction" type="uml:Abstraction">
    <xsd:annotation>
      <xsd:documentation>An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Realization">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Realization is a subtype of Dependencies::Realization. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Abstraction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="realizingClassifier" type="uml:Classifier"/>
        </xsd:choice>
        <xsd:attribute name="realizingClassifier" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Realization" type="uml:Realization">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Realization is a subtype of Dependencies::Realization. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Substitution">
    <xsd:annotation>
      <xsd:documentation>A substitution is a relationship between two classifiers signifies that the substitutingClassifier complies with the contract specified by the contract classifier. This implies that instances of the substitutingClassifier are runtime substitutable where instances of the contract classifier are expected. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Realization">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="contract" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>(Specializes Dependency.target.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="contract" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>(Specializes Dependency.target.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Substitution" type="uml:Substitution">
    <xsd:annotation>
      <xsd:documentation>A substitution is a relationship between two classifiers signifies that the substitutingClassifier complies with the contract specified by the contract classifier. This implies that instances of the substitutingClassifier are runtime substitutable where instances of the contract classifier are expected. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="GeneralizationSet">
    <xsd:annotation>
      <xsd:documentation>Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="powertype" type="uml:Classifier"/>
          <xsd:element name="generalization" type="uml:Generalization"/>
        </xsd:choice>
        <xsd:attribute name="isCovering" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates (via the associated Generalizations) whether or not the set of specific Classifiers are covering for a particular general classifier. When isCovering is true, every instance of a particular general Classifier is also an instance of at least one of its specific Classifiers for the GeneralizationSet. When isCovering is false, there are one or more instances of the particular general Classifier that are not instances of at least one of its specific Classifiers defined for the GeneralizationSet. For example, Person could have two Generalization relationships each with a different specific Classifier: Male Person and Female Person. This GeneralizationSet would be covering because every instance of Person would be an instance of Male Person or Female Person. In contrast, Person could have a three Generalization relationships involving three specific Classifiers: North AmericanPerson, Asian Person, and European Person. This GeneralizationSet would not be covering because there are instances of Person for which these three specific Classifiers do not apply. The first example, then, could be read: any Person would be specialized as either being a Male Person or a Female Person—and nothing else; the second could be read: any Person would be specialized as being North American Person, Asian Person, European Person, or something else.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isDisjoint" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no members in common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular GeneralizationSet have one or more members in common; that is, their intersection is not empty. For example, Person could have two Generalization relationships, each with the different specific Classifier: Manager or Staff. This would be disjoint because every instance of Person must either be a Manager or Staff. In contrast, Person could have two Generalization relationships involving two specific (and non-covering) Classifiers: Sales Person and Manager. This Generalization- Set would not be disjoint because there are instances of Person which can be a Sales Person and a Manager.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="powertype" type="xsd:string"/>
        <xsd:attribute name="generalization" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="GeneralizationSet" type="uml:GeneralizationSet">
    <xsd:annotation>
      <xsd:documentation>Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="AssociationClass">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, an AssociationClass is a declaration of a semantic relationship between Classifiers, which has a set of features of its own. AssociationClass is both an Association and a Class. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Class">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedEnd" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>The non-navigable ends that are owned by the association itself. This is an ordered association. Subsets Association::memberEnd, Classifier::feature, and Namespace::owned- Member.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="memberEnd" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDerived" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether the association is derived from other model elements such as other associations or constraints. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="memberEnd" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AssociationClass" type="uml:AssociationClass">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, an AssociationClass is a declaration of a semantic relationship between Classifiers, which has a set of features of its own. AssociationClass is both an Association and a Class. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InformationItem">
    <xsd:annotation>
      <xsd:documentation>An information Item is an abstraction of all kinds of information that can be exchanged between objects. It is a kind of classifier intended for representing information at a very abstract way, which is cannot be instanciated. One purpose of Information Items is to be able to define preliminary models, before having taken detailed modeling decisions on types or stuctures. One other purpose of information items and information flows is to abstract complex models by a less precise but more general representation of the information exchanged betwen entities of a system. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="represented" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>: Determines the classifiers that will specify the structure and nature of the information. An information item represents all its represented classifiers. Customer Company Employee product wage &lt;&lt;flow&gt;&gt; &lt;&lt;flow&gt;&gt;</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="represented" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>: Determines the classifiers that will specify the structure and nature of the information. An information item represents all its represented classifiers. Customer Company Employee product wage &lt;&lt;flow&gt;&gt; &lt;&lt;flow&gt;&gt;</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InformationItem" type="uml:InformationItem">
    <xsd:annotation>
      <xsd:documentation>An information Item is an abstraction of all kinds of information that can be exchanged between objects. It is a kind of classifier intended for representing information at a very abstract way, which is cannot be instanciated. One purpose of Information Items is to be able to define preliminary models, before having taken detailed modeling decisions on types or stuctures. One other purpose of information items and information flows is to abstract complex models by a less precise but more general representation of the information exchanged betwen entities of a system. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InformationFlow">
    <xsd:annotation>
      <xsd:documentation>An Information Flow specifies that one or more information items circulate from its sources to its targets. Information flows require some kind of “information channel” for transmitting information items from the source to the destination. An information channel is repersented in various ways depending on the nature of its sources and targets. It may be represented by connectors, links, associations, or even dependencies. For example, if the source and destination are parts in some composite structure such as a collaboration, then the information channel is likely to be represented by a connector between them. Or, if the source and target are objects (which are a kind of InstanceSpecification), they may be represented by a link that joins the two, and so on. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="realization" type="uml:Relationship">
            <xsd:annotation>
              <xsd:documentation>: Determines which Relationship will realize the specified flow</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="conveyed" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>: Specifies the information items that may circulate on this information flow.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="realization" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>: Determines which Relationship will realize the specified flow</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="conveyed" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>: Specifies the information items that may circulate on this information flow.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InformationFlow" type="uml:InformationFlow">
    <xsd:annotation>
      <xsd:documentation>An Information Flow specifies that one or more information items circulate from its sources to its targets. Information flows require some kind of “information channel” for transmitting information items from the source to the destination. An information channel is repersented in various ways depending on the nature of its sources and targets. It may be represented by connectors, links, associations, or even dependencies. For example, if the source and destination are parts in some composite structure such as a collaboration, then the information channel is likely to be represented by a connector between them. Or, if the source and target are objects (which are a kind of InstanceSpecification), they may be represented by a link that joins the two, and so on. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Model">
    <xsd:annotation>
      <xsd:documentation>The Model construct is defined as a Package. It contains a (hierarchical) set of elements that together describe the physical system being modeled. A Model may also contain a set of elements that represents the environment of the system, typically Actors, together with their interrelationships, such as Associations and Dependencies </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Package">
        <xsd:attribute name="viewpoint" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The name of the viewpoint that is expressed by a model (This name may refer to a profile definition).</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Model" type="uml:Model">
    <xsd:annotation>
      <xsd:documentation>The Model construct is defined as a Package. It contains a (hierarchical) set of elements that together describe the physical system being modeled. A Model may also contain a set of elements that represents the environment of the system, typically Actors, together with their interrelationships, such as Associations and Dependencies </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ConnectorEnd">
    <xsd:annotation>
      <xsd:documentation>A connector end is an endpoint of a connector, which attaches the connector to a connectable element. Each connector end is part of one connector. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:MultiplicityElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="role" type="uml:ConnectableElement">
            <xsd:annotation>
              <xsd:documentation>The connectable element attached at this connector end. When an instance of the containing classifier is created, a link may (depending on the multiplicities) be created to an instance of the classifier that types this connectable element.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="partWithPort" type="uml:Property"/>
        </xsd:choice>
        <xsd:attribute name="role" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The connectable element attached at this connector end. When an instance of the containing classifier is created, a link may (depending on the multiplicities) be created to an instance of the classifier that types this connectable element.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="partWithPort" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ConnectorEnd" type="uml:ConnectorEnd">
    <xsd:annotation>
      <xsd:documentation>A connector end is an endpoint of a connector, which attaches the connector to a connectable element. Each connector end is part of one connector. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ConnectableElement">
    <xsd:annotation>
      <xsd:documentation>A ConnectableElement is an abstract metaclass representing a set of instances that are owned by a containing classifier instance. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
          <xsd:element name="end" type="uml:ConnectorEnd">
            <xsd:annotation>
              <xsd:documentation>Denotes a connector that attaches to this connectable element.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
        <xsd:attribute name="end" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Denotes a connector that attaches to this connectable element.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ConnectableElement" type="uml:ConnectableElement">
    <xsd:annotation>
      <xsd:documentation>A ConnectableElement is an abstract metaclass representing a set of instances that are owned by a containing classifier instance. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Connector">
    <xsd:annotation>
      <xsd:documentation>Each connector may be attached to two or more connectable elements, each representing a set of instances. Each connector end </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Feature">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Association">
            <xsd:annotation>
              <xsd:documentation>An optional association that specifies the link corresponding to this connector.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="redefinedConnector" type="uml:Connector">
            <xsd:annotation>
              <xsd:documentation>connector may be redefined when its containing classifier is specialized. The redefining connector may have a type that specializes the type of the redefined connector. The types of the connector ends of the redefining connector may specialize the types of the connector ends of the redefined connector. The properties of the connector ends of the redefining connector may be replaced. (Subsets Element.redefinedElement.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="end" type="uml:ConnectorEnd">
            <xsd:annotation>
              <xsd:documentation>A connector consists of at two connector ends, each of which represents the participation of instances of the classifiers typing the connectable elements attached to this end. The set of connector ends is ordered. (Subsets Element.ownedElement.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="contract" type="uml:Behavior"/>
        </xsd:choice>
        <xsd:attribute name="kind" type="uml:ConnectorKind"/>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An optional association that specifies the link corresponding to this connector.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedConnector" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>connector may be redefined when its containing classifier is specialized. The redefining connector may have a type that specializes the type of the redefined connector. The types of the connector ends of the redefining connector may specialize the types of the connector ends of the redefined connector. The properties of the connector ends of the redefining connector may be replaced. (Subsets Element.redefinedElement.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="contract" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Connector" type="uml:Connector">
    <xsd:annotation>
      <xsd:documentation>Each connector may be attached to two or more connectable elements, each representing a set of instances. Each connector end </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StructuredClassifier">
    <xsd:annotation>
      <xsd:documentation>A structured classifier is an abstract metaclass that represents any classifier whose behavior can be fully or partly described by the collaboration of owned or referenced instances. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>References the properties owned by the classifier. (Subsets StructuredClassifier.role, Classifier. attribute,and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedConnector" type="uml:Connector">
            <xsd:annotation>
              <xsd:documentation>References the connectors owned by the classifier. (Subsets Classifier.feature and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StructuredClassifier" type="uml:StructuredClassifier">
    <xsd:annotation>
      <xsd:documentation>A structured classifier is an abstract metaclass that represents any classifier whose behavior can be fully or partly described by the collaboration of owned or referenced instances. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ActivityEdge">
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="source" type="uml:ActivityNode"/>
          <xsd:element name="target" type="uml:ActivityNode"/>
          <xsd:element name="guard" type="uml:ValueSpecification"/>
          <xsd:element name="redefinedElement" type="uml:ActivityEdge"/>
          <xsd:element name="inPartition" type="uml:ActivityPartition"/>
          <xsd:element name="weight" type="uml:ValueSpecification"/>
          <xsd:element name="interrupts" type="uml:InterruptibleActivityRegion"/>
        </xsd:choice>
        <xsd:attribute name="source" type="xsd:string"/>
        <xsd:attribute name="target" type="xsd:string"/>
        <xsd:attribute name="redefinedElement" type="xsd:string"/>
        <xsd:attribute name="inPartition" type="xsd:string"/>
        <xsd:attribute name="interrupts" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityEdge" type="uml:ActivityEdge"/>
  <xsd:complexType name="ActivityGroup">
    <xsd:annotation>
      <xsd:documentation>Activity groups are a generic grouping construct for nodes and edges. Nodes and edges can belong to more than group. They have no inherent semantics and can be used for various purposes. Subclasses of ActivityGroup may add semantics. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityGroup" type="uml:ActivityGroup">
    <xsd:annotation>
      <xsd:documentation>Activity groups are a generic grouping construct for nodes and edges. Nodes and edges can belong to more than group. They have no inherent semantics and can be used for various purposes. Subclasses of ActivityGroup may add semantics. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ActivityNode">
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="outgoing" type="uml:ActivityEdge"/>
          <xsd:element name="incoming" type="uml:ActivityEdge"/>
          <xsd:element name="redefinedElement" type="uml:ActivityNode"/>
          <xsd:element name="inPartition" type="uml:ActivityPartition"/>
          <xsd:element name="inInterruptibleRegion" type="uml:InterruptibleActivityRegion"/>
        </xsd:choice>
        <xsd:attribute name="outgoing" type="xsd:string"/>
        <xsd:attribute name="incoming" type="xsd:string"/>
        <xsd:attribute name="redefinedElement" type="xsd:string"/>
        <xsd:attribute name="inPartition" type="xsd:string"/>
        <xsd:attribute name="inInterruptibleRegion" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityNode" type="uml:ActivityNode"/>
  <xsd:complexType name="Action">
    <xsd:complexContent>
      <xsd:extension base="uml:ExecutableNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="localPrecondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Constraint that must be satisfied when execution is started.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="localPostcondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Constraint that must be satisfied when executed is completed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="effect" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Action" type="uml:Action"/>
  <xsd:complexType name="ObjectNode">
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="upperBound" type="uml:ValueSpecification"/>
          <xsd:element name="inState" type="uml:State">
            <xsd:annotation>
              <xsd:documentation>The required states of the object available at this point in the activity.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="selection" type="uml:Behavior"/>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="ordering" type="uml:ObjectNodeOrderingKind">
          <xsd:annotation>
            <xsd:documentation>= FIFO Tells whether and how the tokens in the object node are ordered for selection to traverse edges outgoing from the object node.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="inState" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The required states of the object available at this point in the activity.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="selection" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ObjectNode" type="uml:ObjectNode"/>
  <xsd:complexType name="ControlNode">
    <xsd:annotation>
      <xsd:documentation>A control node is an activity node used to coordinate the flows between other nodes. It covers initial node, final node and its children, fork node, join node, decision node, and merge node. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ControlNode" type="uml:ControlNode">
    <xsd:annotation>
      <xsd:documentation>A control node is an activity node used to coordinate the flows between other nodes. It covers initial node, final node and its children, fork node, join node, decision node, and merge node. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ControlFlow">
    <xsd:annotation>
      <xsd:documentation>Objects and data cannot pass along a control flow edge. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityEdge"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ControlFlow" type="uml:ControlFlow">
    <xsd:annotation>
      <xsd:documentation>Objects and data cannot pass along a control flow edge. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ObjectFlow">
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityEdge">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="transformation" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>Changes or replaces data tokens flowing along edge.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="selection" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>Selects tokens from a source object node.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isMulticast" type="xsd:string"/>
        <xsd:attribute name="isMultireceive" type="xsd:string"/>
        <xsd:attribute name="transformation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Changes or replaces data tokens flowing along edge.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="selection" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Selects tokens from a source object node.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ObjectFlow" type="uml:ObjectFlow"/>
  <xsd:complexType name="InitialNode">
    <xsd:annotation>
      <xsd:documentation>An activity may have more than one initial node. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InitialNode" type="uml:InitialNode">
    <xsd:annotation>
      <xsd:documentation>An activity may have more than one initial node. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="FinalNode">
    <xsd:annotation>
      <xsd:documentation>See descriptions at children of final node. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="FinalNode" type="uml:FinalNode">
    <xsd:annotation>
      <xsd:documentation>See descriptions at children of final node. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ActivityFinalNode">
    <xsd:annotation>
      <xsd:documentation>An activity may have more than one activity final node. The first one reached stops all flows in the activity. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:FinalNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityFinalNode" type="uml:ActivityFinalNode">
    <xsd:annotation>
      <xsd:documentation>An activity may have more than one activity final node. The first one reached stops all flows in the activity. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DecisionNode">
    <xsd:annotation>
      <xsd:documentation>A decision node has one incoming edge and multiple outgoing activity edges. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="decisionInput" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>Provides input to guard specifications on edges outgoing from the decision node.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="decisionInput" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Provides input to guard specifications on edges outgoing from the decision node.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DecisionNode" type="uml:DecisionNode">
    <xsd:annotation>
      <xsd:documentation>A decision node has one incoming edge and multiple outgoing activity edges. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="MergeNode">
    <xsd:annotation>
      <xsd:documentation>A merge node has multiple incoming edges and a single outgoing edge. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="MergeNode" type="uml:MergeNode">
    <xsd:annotation>
      <xsd:documentation>A merge node has multiple incoming edges and a single outgoing edge. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExecutableNode">
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="handler" type="uml:ExceptionHandler">
            <xsd:annotation>
              <xsd:documentation>A set of exception handlers that are examined if an uncaught exception propagates to the outer level of the executable node.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExecutableNode" type="uml:ExecutableNode"/>
  <xsd:complexType name="OutputPin">
    <xsd:annotation>
      <xsd:documentation>An output pin is a pin that holds output values produced by an action. Output pins are object nodes and deliver values to other actions through object flows. See Pin, Action, and ObjectNode for more details. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Pin"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="OutputPin" type="uml:OutputPin">
    <xsd:annotation>
      <xsd:documentation>An output pin is a pin that holds output values produced by an action. Output pins are object nodes and deliver values to other actions through object flows. See Pin, Action, and ObjectNode for more details. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InputPin">
    <xsd:annotation>
      <xsd:documentation>An input pin is a pin that holds input values to be consumed by an action. They are object nodes and receive values from other actions through object flows. See Pin, Action, and ObjectNode for more details. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Pin"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InputPin" type="uml:InputPin">
    <xsd:annotation>
      <xsd:documentation>An input pin is a pin that holds input values to be consumed by an action. They are object nodes and receive values from other actions through object flows. See Pin, Action, and ObjectNode for more details. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Pin">
    <xsd:annotation>
      <xsd:documentation>Pins are connected as inputs and outputs to actions. They provide values to actions and accept result values from them. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ObjectNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Pin" type="uml:Pin">
    <xsd:annotation>
      <xsd:documentation>Pins are connected as inputs and outputs to actions. They provide values to actions and accept result values from them. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ActivityParameterNode">
    <xsd:annotation>
      <xsd:documentation>Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an activity and provide outputs from it. (CompleteActivities) Activity parameters inherit support for streaming and exceptions from Parameter. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ObjectNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="parameter" type="uml:Parameter">
            <xsd:annotation>
              <xsd:documentation>The parameter the object node will be accepting and providing values for.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="parameter" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The parameter the object node will be accepting and providing values for.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityParameterNode" type="uml:ActivityParameterNode">
    <xsd:annotation>
      <xsd:documentation>Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an activity and provide outputs from it. (CompleteActivities) Activity parameters inherit support for streaming and exceptions from Parameter. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ValuePin">
    <xsd:annotation>
      <xsd:documentation>A value pin is an input pin that provides a value to an action that does not come from an incoming object flow edge. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InputPin">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="value" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Value that the pin will provide.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ValuePin" type="uml:ValuePin">
    <xsd:annotation>
      <xsd:documentation>A value pin is an input pin that provides a value to an action that does not come from an incoming object flow edge. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Interface">
    <xsd:annotation>
      <xsd:documentation>An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>References the properties owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedOperation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>References the operations owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="redefinedInterface" type="uml:Interface">
            <xsd:annotation>
              <xsd:documentation>(Subsets Element.redefinedElement.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="nestedClassifier" type="uml:Classifier"/>
          <xsd:element name="ownedReception" type="uml:Reception">
            <xsd:annotation>
              <xsd:documentation>Receptions that objects providing this interface are willing to accept. (Subsets Namespace.ownedMember and Classifier.feature.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="protocol" type="uml:ProtocolStateMachine">
            <xsd:annotation>
              <xsd:documentation>References a protocol state machine specifying the legal sequences of the invocation of the behavioral features described in the interface.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="redefinedInterface" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>(Subsets Element.redefinedElement.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Interface" type="uml:Interface">
    <xsd:annotation>
      <xsd:documentation>An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Implementation">
    <xsd:annotation>
      <xsd:documentation>An Implementation is a specialized Realization relationship between a Classifier and an Interface. The implementation relationship signifies that the realizing classifier conforms to the contract specified by the interface. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Realization">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="contract" type="uml:Interface">
            <xsd:annotation>
              <xsd:documentation>References the Interface specifying the conformance contract. (Specializes Dependency. supplier and Relationship.target)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="contract" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Interface specifying the conformance contract. (Specializes Dependency. supplier and Relationship.target)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Implementation" type="uml:Implementation">
    <xsd:annotation>
      <xsd:documentation>An Implementation is a specialized Realization relationship between a Classifier and an Interface. The implementation relationship signifies that the realizing classifier conforms to the contract specified by the interface. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Artifact">
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="nestedArtifact" type="uml:Artifact"/>
          <xsd:element name="manifestation" type="uml:Manifestation"/>
          <xsd:element name="ownedOperation" type="uml:Operation"/>
          <xsd:element name="ownedAttribute" type="uml:Property"/>
        </xsd:choice>
        <xsd:attribute name="fileName" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Artifact" type="uml:Artifact"/>
  <xsd:complexType name="Manifestation">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Manifestation is a subtype of Abstraction. A Manifestation is owned by an Artifact. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Abstraction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="utilizedElement" type="uml:PackageableElement">
            <xsd:annotation>
              <xsd:documentation>The model element that is utilized in the manifestation in an Artifact. This association specializes the supplier association.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="utilizedElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The model element that is utilized in the manifestation in an Artifact. This association specializes the supplier association.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Manifestation" type="uml:Manifestation">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Manifestation is a subtype of Abstraction. A Manifestation is owned by an Artifact. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Actor">
    <xsd:annotation>
      <xsd:documentation>An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances. Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates the subject classifier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Actor" type="uml:Actor">
    <xsd:annotation>
      <xsd:documentation>An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances. Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates the subject classifier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Extend">
    <xsd:annotation>
      <xsd:documentation>This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions. Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended. It is a kind of DirectedRelationship, such that the source is the extending use case and the destination is the extended use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The extend relationship itself is owned by the extending use case. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="extendedCase" type="uml:UseCase">
            <xsd:annotation>
              <xsd:documentation>References the use case that is being extended. (Specializes DirectedRelationship.target.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="condition" type="uml:Constraint"/>
          <xsd:element name="extensionLocation" type="uml:ExtensionPoint"/>
        </xsd:choice>
        <xsd:attribute name="extendedCase" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the use case that is being extended. (Specializes DirectedRelationship.target.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="extensionLocation" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Extend" type="uml:Extend">
    <xsd:annotation>
      <xsd:documentation>This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions. Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended. It is a kind of DirectedRelationship, such that the source is the extending use case and the destination is the extended use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The extend relationship itself is owned by the extending use case. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="UseCase">
    <xsd:annotation>
      <xsd:documentation>A UseCase is a kind of behaviored classifier that represents a declaration of an offered behavior. Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure. These behaviors, involving interactions between the actor and the subject, may result in changes to the state of the subject and communications with its environment. A use case can include possible variations of its basic behavior, including exceptional behavior and error handling. The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem or class. Each use case specifies a unit of useful functionality that the subject provides to its users, i.e., a specific way of interacting with the subject. This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the use case can be initiated again or in an error state. Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services. The behavior of a use case can be described by a specification that is some kind of Behavior (through its ownedBehavior relationship), such as interactions, activities, and state machines, or by pre-conditions and post-conditions as well as by natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the use case and its actors as the classifiers that type its parts. Which of these techniques to use depends on the nature of the use case behavior as well as on the intended reader. These descriptions can be combined. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:BehavioredClassifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="include" type="uml:Include"/>
          <xsd:element name="extend" type="uml:Extend"/>
          <xsd:element name="extensionPoint" type="uml:ExtensionPoint"/>
          <xsd:element name="subject" type="uml:Classifier"/>
        </xsd:choice>
        <xsd:attribute name="subject" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="UseCase" type="uml:UseCase">
    <xsd:annotation>
      <xsd:documentation>A UseCase is a kind of behaviored classifier that represents a declaration of an offered behavior. Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure. These behaviors, involving interactions between the actor and the subject, may result in changes to the state of the subject and communications with its environment. A use case can include possible variations of its basic behavior, including exceptional behavior and error handling. The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem or class. Each use case specifies a unit of useful functionality that the subject provides to its users, i.e., a specific way of interacting with the subject. This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the use case can be initiated again or in an error state. Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services. The behavior of a use case can be described by a specification that is some kind of Behavior (through its ownedBehavior relationship), such as interactions, activities, and state machines, or by pre-conditions and post-conditions as well as by natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the use case and its actors as the classifiers that type its parts. Which of these techniques to use depends on the nature of the use case behavior as well as on the intended reader. These descriptions can be combined. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExtensionPoint">
    <xsd:annotation>
      <xsd:documentation>An ExtensionPoint is a feature of a use case that identifies a point where the behavior of a use case can be augmented with elements of another (extending) use case. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExtensionPoint" type="uml:ExtensionPoint">
    <xsd:annotation>
      <xsd:documentation>An ExtensionPoint is a feature of a use case that identifies a point where the behavior of a use case can be augmented with elements of another (extending) use case. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Include">
    <xsd:annotation>
      <xsd:documentation>Include is a DirectedRelationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case. Note that the included use case is not optional, and is always required for the including use case to execute correctly. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="addition" type="uml:UseCase">
            <xsd:annotation>
              <xsd:documentation>References the use case that is to be included. (Specializes DirectedRelationship.target.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="addition" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the use case that is to be included. (Specializes DirectedRelationship.target.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Include" type="uml:Include">
    <xsd:annotation>
      <xsd:documentation>Include is a DirectedRelationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case. Note that the included use case is not optional, and is always required for the including use case to execute correctly. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CollaborationOccurrence">
    <xsd:annotation>
      <xsd:documentation>A collaboration occurrence represents one particular use of a collaboration to explain the relationships between the properties of a classifier. A collaboration occurrence indicates a set of roles and connectors that cooperate within the classifier according to a given collaboration, indicated by the type of the collaboration occurrence. There may be multiple occurrences of a given collaboration within a classifier, each involving a different set of roles and connectors. A given role or connector may be involved in multiple occurrences of the same or different collaborations. Associated dependencies map features of the collaboration type to features in the classifier. These dependencies indicate which role in the classifier plays which role in the collaboration. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Collaboration">
            <xsd:annotation>
              <xsd:documentation>The collaboration which is used in this occurrence. The collaboration defines the cooperation between its roles which are mapped to properties of the classifier owning the collaboration occurrence.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="roleBinding" type="uml:Dependency"/>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The collaboration which is used in this occurrence. The collaboration defines the cooperation between its roles which are mapped to properties of the classifier owning the collaboration occurrence.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CollaborationOccurrence" type="uml:CollaborationOccurrence">
    <xsd:annotation>
      <xsd:documentation>A collaboration occurrence represents one particular use of a collaboration to explain the relationships between the properties of a classifier. A collaboration occurrence indicates a set of roles and connectors that cooperate within the classifier according to a given collaboration, indicated by the type of the collaboration occurrence. There may be multiple occurrences of a given collaboration within a classifier, each involving a different set of roles and connectors. A given role or connector may be involved in multiple occurrences of the same or different collaborations. Associated dependencies map features of the collaboration type to features in the classifier. These dependencies indicate which role in the classifier plays which role in the collaboration. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Collaboration">
    <xsd:annotation>
      <xsd:documentation>A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances (its roles), as well as a set of connectors that define communication paths between the participating instances. The cooperating entities are the properties of the collaboration. A collaboration specifies a view (or projection) of a set of cooperating classifiers. It describes the required links between instances that play the roles of the collaboration, as well as the features required of the classifiers that specify the participating instances. Several collaborations may describe different projections of the same set of classifiers. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:BehavioredClassifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>References the properties owned by the classifier. (Subsets StructuredClassifier.role, Classifier. attribute,and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedConnector" type="uml:Connector">
            <xsd:annotation>
              <xsd:documentation>References the connectors owned by the classifier. (Subsets Classifier.feature and Namespace.ownedMember)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="collaborationRole" type="uml:ConnectableElement"/>
        </xsd:choice>
        <xsd:attribute name="collaborationRole" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Collaboration" type="uml:Collaboration">
    <xsd:annotation>
      <xsd:documentation>A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances (its roles), as well as a set of connectors that define communication paths between the participating instances. The cooperating entities are the properties of the collaboration. A collaboration specifies a view (or projection) of a set of cooperating classifiers. It describes the required links between instances that play the roles of the collaboration, as well as the features required of the classifiers that specify the participating instances. Several collaborations may describe different projections of the same set of classifiers. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Port">
    <xsd:annotation>
      <xsd:documentation>Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port. A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Property">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="redefinedPort" type="uml:Port">
            <xsd:annotation>
              <xsd:documentation>A port may be redefined when its containing classifier is specialized. The redefining port may have additional interfaces to those that are associated with the redefined port or it may replace an interface by one of its subtypes. (Subsets Element.redefinedElement.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="protocol" type="uml:ProtocolStateMachine">
            <xsd:annotation>
              <xsd:documentation>References an optional protocol state machine which describes valid interactions at this interaction point.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isBehavior" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see “BehavioredClassifier (from BasicBehaviors)” on page 387). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isService" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>If true indicates that this port is used to provide the published functionality of a classifier; if false, this port is used to implement the classifier but is not part of the essential externally- visible functionality of the classifier and can, therefore, be altered or deleted along with the internal implementation of the classifier and other properties that are considered part of its implementation. The default value for this attribute is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedPort" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A port may be redefined when its containing classifier is specialized. The redefining port may have additional interfaces to those that are associated with the redefined port or it may replace an interface by one of its subtypes. (Subsets Element.redefinedElement.)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="protocol" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References an optional protocol state machine which describes valid interactions at this interaction point.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Port" type="uml:Port">
    <xsd:annotation>
      <xsd:documentation>Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port. A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="EncapsulatedClassifier">
    <xsd:annotation>
      <xsd:documentation>Extends a classifier with the ability to own ports as specific and type checked interaction points. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuredClassifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedPort" type="uml:Port">
            <xsd:annotation>
              <xsd:documentation>References a set of ports that an encapsulated classifier owns. (Subsets Classifier.feature and Namespace.ownedMember.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="EncapsulatedClassifier" type="uml:EncapsulatedClassifier">
    <xsd:annotation>
      <xsd:documentation>Extends a classifier with the ability to own ports as specific and type checked interaction points. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CallTrigger">
    <xsd:annotation>
      <xsd:documentation>A call trigger represents the reception of a request to invoke a specific operation and specifies a call event. A call event is distinct from the call action that caused it. A call event may cause the invocation of a behavior that is the method of the operation referenced by the call request, if that operation is owned or inherited by the classifier that specified the receiver object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:MessageTrigger">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="operation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>Designates the operation whose invocation raised the call event that is specified by the call trigger.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="operation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Designates the operation whose invocation raised the call event that is specified by the call trigger.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CallTrigger" type="uml:CallTrigger">
    <xsd:annotation>
      <xsd:documentation>A call trigger represents the reception of a request to invoke a specific operation and specifies a call event. A call event is distinct from the call action that caused it. A call event may cause the invocation of a behavior that is the method of the operation referenced by the call request, if that operation is owned or inherited by the classifier that specified the receiver object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="MessageTrigger">
    <xsd:annotation>
      <xsd:documentation>A message trigger specifies the an observable event caused by a either a call or a signal. MessageTrigger is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Trigger"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="MessageTrigger" type="uml:MessageTrigger">
    <xsd:annotation>
      <xsd:documentation>A message trigger specifies the an observable event caused by a either a call or a signal. MessageTrigger is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ChangeTrigger">
    <xsd:annotation>
      <xsd:documentation>A change trigger specifies an event that occurs when a Boolean-valued 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 an explicit action. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Trigger">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="changeExpression" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>A Boolean-valued expression that will result in a change event whenever its value changes from false to true.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ChangeTrigger" type="uml:ChangeTrigger">
    <xsd:annotation>
      <xsd:documentation>A change trigger specifies an event that occurs when a Boolean-valued 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 an explicit action. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Trigger">
    <xsd:annotation>
      <xsd:documentation>A trigger specifies the an event that may cause the execution of an associated behavior. An event is often ultimately caused by the execution of an action, but need not be. Trigger is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="port" type="uml:Port">
            <xsd:annotation>
              <xsd:documentation>Specifies the ports at which a communication that caused an event may have arrived.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="port" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the ports at which a communication that caused an event may have arrived.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Trigger" type="uml:Trigger">
    <xsd:annotation>
      <xsd:documentation>A trigger specifies the an event that may cause the execution of an associated behavior. An event is often ultimately caused by the execution of an action, but need not be. Trigger is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Reception">
    <xsd:annotation>
      <xsd:documentation>A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. The details of handling a signal are specified by the behavior associated with the reception or the classifier itself. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:BehavioralFeature">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="signal" type="uml:Signal">
            <xsd:annotation>
              <xsd:documentation>The signal that this reception handles.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="signal" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The signal that this reception handles.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Reception" type="uml:Reception">
    <xsd:annotation>
      <xsd:documentation>A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. The details of handling a signal are specified by the behavior associated with the reception or the classifier itself. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Signal">
    <xsd:annotation>
      <xsd:documentation>A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedAttribute" type="uml:Property"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Signal" type="uml:Signal">
    <xsd:annotation>
      <xsd:documentation>A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="SignalTrigger">
    <xsd:annotation>
      <xsd:documentation>A signal event represents the receipt of an asynchronous signal. A signal event may cause a response, such as a state machine transition as specified in the classifier behavior of the classifier that specified the receiver object, if the signal referenced by the send request is mentioned in a reception owned or inherited by the classifier that specified the receiver object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:MessageTrigger">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="signal" type="uml:Signal"/>
        </xsd:choice>
        <xsd:attribute name="signal" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SignalTrigger" type="uml:SignalTrigger">
    <xsd:annotation>
      <xsd:documentation>A signal event represents the receipt of an asynchronous signal. A signal event may cause a response, such as a state machine transition as specified in the classifier behavior of the classifier that specified the receiver object, if the signal referenced by the send request is mentioned in a reception owned or inherited by the classifier that specified the receiver object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TimeTrigger">
    <xsd:annotation>
      <xsd:documentation>A time trigger specifies a time event, which models the expiration of a specific deadline. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Trigger">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="when" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Specifies the corresponding time deadline.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isRelative" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether it is relative or absolute time.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TimeTrigger" type="uml:TimeTrigger">
    <xsd:annotation>
      <xsd:documentation>A time trigger specifies a time event, which models the expiration of a specific deadline. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="AnyTrigger">
    <xsd:annotation>
      <xsd:documentation>An AnyTrigger for a given state specifies that the transition is triggered for all applicable message triggers except for those specified explicitly on other transitions for this state. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:MessageTrigger"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AnyTrigger" type="uml:AnyTrigger">
    <xsd:annotation>
      <xsd:documentation>An AnyTrigger for a given state specifies that the transition is triggered for all applicable message triggers except for those specified explicitly on other transitions for this state. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Variable">
    <xsd:annotation>
      <xsd:documentation>A variable is considered a connectable element. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ConnectableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="type" type="uml:Type">
            <xsd:annotation>
              <xsd:documentation>The type of the TypedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="upperValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the upper bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="lowerValue" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>The specification of the lower bound for this multiplicity. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="type" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of the TypedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isOrdered" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isUnique" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this element are unique. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Variable" type="uml:Variable">
    <xsd:annotation>
      <xsd:documentation>A variable is considered a connectable element. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StructuredActivityNode">
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="ownedRule" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Specifies a set of Constraints owned by this Namespace. Subsets Namespace::ownedMember.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="elementImport" type="uml:ElementImport">
            <xsd:annotation>
              <xsd:documentation>References the ElementImports owned by the Namespace. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="packageImport" type="uml:PackageImport">
            <xsd:annotation>
              <xsd:documentation>References the PackageImports owned by the Namespace. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="variable" type="uml:Variable"/>
          <xsd:element name="containedNode" type="uml:ActivityNode"/>
          <xsd:element name="containedEdge" type="uml:ActivityEdge"/>
        </xsd:choice>
        <xsd:attribute name="mustIsolate" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StructuredActivityNode" type="uml:StructuredActivityNode"/>
  <xsd:complexType name="ConditionalNode">
    <xsd:complexContent>
      <xsd:extension base="uml:StructuredActivityNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="clause" type="uml:Clause"/>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins that constitute the data flow outputs of the conditional.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDeterminate" type="xsd:string"/>
        <xsd:attribute name="isAssured" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ConditionalNode" type="uml:ConditionalNode"/>
  <xsd:complexType name="Clause">
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="test" type="uml:ActivityNode"/>
          <xsd:element name="body" type="uml:ActivityNode"/>
          <xsd:element name="predecessorClause" type="uml:Clause"/>
          <xsd:element name="successorClause" type="uml:Clause"/>
          <xsd:element name="decider" type="uml:OutputPin"/>
          <xsd:element name="bodyOutput" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins within the body fragment whose values are copied to the result pins of the containing conditional node or conditional node after execution of the clause body.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="test" type="xsd:string"/>
        <xsd:attribute name="body" type="xsd:string"/>
        <xsd:attribute name="predecessorClause" type="xsd:string"/>
        <xsd:attribute name="successorClause" type="xsd:string"/>
        <xsd:attribute name="decider" type="xsd:string"/>
        <xsd:attribute name="bodyOutput" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A list of output pins within the body fragment whose values are copied to the result pins of the containing conditional node or conditional node after execution of the clause body.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Clause" type="uml:Clause"/>
  <xsd:complexType name="LoopNode">
    <xsd:complexContent>
      <xsd:extension base="uml:StructuredActivityNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="bodyPart" type="uml:ActivityNode"/>
          <xsd:element name="setupPart" type="uml:ActivityNode"/>
          <xsd:element name="decider" type="uml:OutputPin"/>
          <xsd:element name="test" type="uml:ActivityNode"/>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins that constitute the data flow output of the entire loop.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="loopVariable" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins owned by the loop that hold the values of the loop variables during an execution of the loop. When the test fails, the values are copied to the result pins of the loop.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="bodyOutput" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins within the body fragment the values of which are copied to the loop variable pins after completion of execution of the body, before the next iteration of the loop begins or before the loop exits.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="loopVariableInput" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>A list of values that are copied into the loop variable pins before the first iteration of the loop.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isTestedFirst" type="xsd:string"/>
        <xsd:attribute name="bodyPart" type="xsd:string"/>
        <xsd:attribute name="setupPart" type="xsd:string"/>
        <xsd:attribute name="decider" type="xsd:string"/>
        <xsd:attribute name="test" type="xsd:string"/>
        <xsd:attribute name="bodyOutput" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A list of output pins within the body fragment the values of which are copied to the loop variable pins after completion of execution of the body, before the next iteration of the loop begins or before the loop exits.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LoopNode" type="uml:LoopNode"/>
  <xsd:complexType name="Interaction">
    <xsd:annotation>
      <xsd:documentation>The point is that the InteractionConstraint "received" from StructuralArchitecture will consist of a set of such units described by sequence diagrams (or collaboration diagrams).</xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Behavior">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="covered" type="uml:Lifeline"/>
          <xsd:element name="generalOrdering" type="uml:GeneralOrdering"/>
          <xsd:element name="lifeline" type="uml:Lifeline"/>
          <xsd:element name="message" type="uml:Message"/>
          <xsd:element name="fragment" type="uml:InteractionFragment"/>
          <xsd:element name="formalGate" type="uml:Gate">
            <xsd:annotation>
              <xsd:documentation>Specifies the gates that form the message interface between this Interaction and any InteractionOccurrences which reference it.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="covered" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Interaction" type="uml:Interaction">
    <xsd:annotation>
      <xsd:documentation>The point is that the InteractionConstraint "received" from StructuralArchitecture will consist of a set of such units described by sequence diagrams (or collaboration diagrams).</xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InteractionFragment">
    <xsd:annotation>
      <xsd:documentation>An InteractionFragment is a general class that holds the common parts of CompositeFragment, AtomicFragment and InteractionExpressionOperand.
Conceptually it is very much the same as a full sequence diagram, but a fragment is not named and must be referred then through structure.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="covered" type="uml:Lifeline"/>
          <xsd:element name="generalOrdering" type="uml:GeneralOrdering"/>
        </xsd:choice>
        <xsd:attribute name="covered" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InteractionFragment" type="uml:InteractionFragment">
    <xsd:annotation>
      <xsd:documentation>An InteractionFragment is a general class that holds the common parts of CompositeFragment, AtomicFragment and InteractionExpressionOperand.
Conceptually it is very much the same as a full sequence diagram, but a fragment is not named and must be referred then through structure.</xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Lifeline">
    <xsd:annotation>
      <xsd:documentation>A lifeline represents an individual participant in the Interaction. While Parts and StructuralFeatures may have multiplicity greater than 1, Lifelines represent only one interacting entity. Lifeline is a specialization of NamedElement. If the referenced ConnectableElement is multivalued (i.e. has a multiplicity &gt; 1), then the Lifeline may have an expression (the ‘selector’) that specifies which particular part is represented by this Lifeline. If the selector is omitted this means that an arbitrary representative of the multivalued ConnectableElement is chosen. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="coveredBy" type="uml:InteractionFragment"/>
          <xsd:element name="represents" type="uml:ConnectableElement">
            <xsd:annotation>
              <xsd:documentation>the ConnectableElement within the classifier that contains the enclosing interaction.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="selector" type="uml:OpaqueExpression">
            <xsd:annotation>
              <xsd:documentation>If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="decomposedAs" type="uml:PartDecomposition"/>
        </xsd:choice>
        <xsd:attribute name="coveredBy" type="xsd:string"/>
        <xsd:attribute name="represents" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the ConnectableElement within the classifier that contains the enclosing interaction.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="decomposedAs" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Lifeline" type="uml:Lifeline">
    <xsd:annotation>
      <xsd:documentation>A lifeline represents an individual participant in the Interaction. While Parts and StructuralFeatures may have multiplicity greater than 1, Lifelines represent only one interacting entity. Lifeline is a specialization of NamedElement. If the referenced ConnectableElement is multivalued (i.e. has a multiplicity &gt; 1), then the Lifeline may have an expression (the ‘selector’) that specifies which particular part is represented by this Lifeline. If the selector is omitted this means that an arbitrary representative of the multivalued ConnectableElement is chosen. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Message">
    <xsd:annotation>
      <xsd:documentation>A Message defines a particular communication between Lifelines of an Interaction. A Message is a NamedElement that defines one specific kind of communication in an Interaction. A communication can be e.g. raising a signal, invoking an Operation, creating or destroying an Instance. The Message specifies not only the kind of communication given by the dispatching ExecutionOccurrence, but also the sender and the receiver. A Message associates normally two EventOccurrences - one sending EventOccurrence and one receiving EventOccurrence. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="receiveEvent" type="uml:MessageEnd">
            <xsd:annotation>
              <xsd:documentation>the Receiving of the Message</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="sendEvent" type="uml:MessageEnd">
            <xsd:annotation>
              <xsd:documentation>References the Sending of the Message.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="connector" type="uml:Connector">
            <xsd:annotation>
              <xsd:documentation>The Connector on which this Message is sent.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="signature" type="uml:NamedElement">
            <xsd:annotation>
              <xsd:documentation>The definition of the type or signature of the Message (depending on its kind)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="argument" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>arguments of the Message</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="messageSort" type="uml:MessageSort"/>
        <xsd:attribute name="receiveEvent" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the Receiving of the Message</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="sendEvent" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Sending of the Message.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="connector" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The Connector on which this Message is sent.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="signature" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The definition of the type or signature of the Message (depending on its kind)</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Message" type="uml:Message">
    <xsd:annotation>
      <xsd:documentation>A Message defines a particular communication between Lifelines of an Interaction. A Message is a NamedElement that defines one specific kind of communication in an Interaction. A communication can be e.g. raising a signal, invoking an Operation, creating or destroying an Instance. The Message specifies not only the kind of communication given by the dispatching ExecutionOccurrence, but also the sender and the receiver. A Message associates normally two EventOccurrences - one sending EventOccurrence and one receiving EventOccurrence. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="GeneralOrdering">
    <xsd:annotation>
      <xsd:documentation>A GeneralOrdering represents a binary relation between two Eventoccurrences, to describe that one Eventoccurrence must occur before the other in a valid trace. This mechanism provides the ability to define partial orders of EventOccurrences that may otherwise not have a specified order. A GeneralOrdering is a specialization of NamedElement. A GeneralOrdering may appear anywhere in an Interaction, but only between Eventoccurrences. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="before" type="uml:EventOccurrence">
            <xsd:annotation>
              <xsd:documentation>The Eventoccurrence referred comes before the Eventoccurrence referred by after</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="after" type="uml:EventOccurrence">
            <xsd:annotation>
              <xsd:documentation>The Eventoccurrence referred comes after the Eventoccurrence referred by before</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="before" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The Eventoccurrence referred comes before the Eventoccurrence referred by after</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="after" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The Eventoccurrence referred comes after the Eventoccurrence referred by before</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="GeneralOrdering" type="uml:GeneralOrdering">
    <xsd:annotation>
      <xsd:documentation>A GeneralOrdering represents a binary relation between two Eventoccurrences, to describe that one Eventoccurrence must occur before the other in a valid trace. This mechanism provides the ability to define partial orders of EventOccurrences that may otherwise not have a specified order. A GeneralOrdering is a specialization of NamedElement. A GeneralOrdering may appear anywhere in an Interaction, but only between Eventoccurrences. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="MessageEnd">
    <xsd:annotation>
      <xsd:documentation>A MessageEnd is an abstract NamedElement that represents what can occur at the end of a Message. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="receiveMessage" type="uml:Message">
            <xsd:annotation>
              <xsd:documentation>the Message that contains the information of a receiveEvent</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="sendMessage" type="uml:Message">
            <xsd:annotation>
              <xsd:documentation>References the Message that contains the information of a sendEvent</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="receiveMessage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the Message that contains the information of a receiveEvent</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="sendMessage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Message that contains the information of a sendEvent</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="MessageEnd" type="uml:MessageEnd">
    <xsd:annotation>
      <xsd:documentation>A MessageEnd is an abstract NamedElement that represents what can occur at the end of a Message. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="EventOccurrence">
    <xsd:annotation>
      <xsd:documentation>EventOccurrences represents moments in time to which Actions are associated. An EventOccurrence is the basic semantic unit of Interactions. The sequences of Eventoccurrences are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption. EventOccurrence is a specialization of InteractionFragment and of MessageEnd. EventOccurrences are ordered along a Lifeline. The namespace of an EventOccurrence is the Interaction in which it is contained. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="receiveMessage" type="uml:Message">
            <xsd:annotation>
              <xsd:documentation>the Message that contains the information of a receiveEvent</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="sendMessage" type="uml:Message">
            <xsd:annotation>
              <xsd:documentation>References the Message that contains the information of a sendEvent</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="startExec" type="uml:ExecutionOccurrence"/>
          <xsd:element name="finishExec" type="uml:ExecutionOccurrence"/>
          <xsd:element name="toAfter" type="uml:GeneralOrdering"/>
          <xsd:element name="toBefore" type="uml:GeneralOrdering"/>
        </xsd:choice>
        <xsd:attribute name="receiveMessage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the Message that contains the information of a receiveEvent</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="sendMessage" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Message that contains the information of a sendEvent</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="startExec" type="xsd:string"/>
        <xsd:attribute name="finishExec" type="xsd:string"/>
        <xsd:attribute name="toAfter" type="xsd:string"/>
        <xsd:attribute name="toBefore" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="EventOccurrence" type="uml:EventOccurrence">
    <xsd:annotation>
      <xsd:documentation>EventOccurrences represents moments in time to which Actions are associated. An EventOccurrence is the basic semantic unit of Interactions. The sequences of Eventoccurrences are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption. EventOccurrence is a specialization of InteractionFragment and of MessageEnd. EventOccurrences are ordered along a Lifeline. The namespace of an EventOccurrence is the Interaction in which it is contained. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExecutionOccurrence">
    <xsd:annotation>
      <xsd:documentation>An ExecutionOccurrence is an instantiation of a unit of behavior within the Lifeline. Since the ExecutionOccurrence will have some duration, it is represented by two Eventoccurrences, the start EventOccurrence and the finish EventOccurrence. An ExecutionOccurrence is an InteractionFragment. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="start" type="uml:EventOccurrence">
            <xsd:annotation>
              <xsd:documentation>References the Eventoccurrence that designates the start of the Action</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="finish" type="uml:EventOccurrence">
            <xsd:annotation>
              <xsd:documentation>References the Eventoccurrence that designates the finish of the Action.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="behavior" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>References the associated behavior</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="start" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Eventoccurrence that designates the start of the Action</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="finish" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the Eventoccurrence that designates the finish of the Action.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="behavior" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>References the associated behavior</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExecutionOccurrence" type="uml:ExecutionOccurrence">
    <xsd:annotation>
      <xsd:documentation>An ExecutionOccurrence is an instantiation of a unit of behavior within the Lifeline. Since the ExecutionOccurrence will have some duration, it is represented by two Eventoccurrences, the start EventOccurrence and the finish EventOccurrence. An ExecutionOccurrence is an InteractionFragment. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StateInvariant">
    <xsd:annotation>
      <xsd:documentation>A StateInvariant is a runtime constraint on the participants of the interaction. It may be used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on. A StateInvariant is an InteractionFragment and it is placed on a Lifeline. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="invariant" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>A Constraint that should hold at runtime for this StateInvariant</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StateInvariant" type="uml:StateInvariant">
    <xsd:annotation>
      <xsd:documentation>A StateInvariant is a runtime constraint on the participants of the interaction. It may be used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on. A StateInvariant is an InteractionFragment and it is placed on a Lifeline. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Stop">
    <xsd:annotation>
      <xsd:documentation>A Stop is an EventOccurrence that defines the termination of the instance specified by the Lifeline on which the Stop occurs. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:EventOccurrence"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Stop" type="uml:Stop">
    <xsd:annotation>
      <xsd:documentation>A Stop is an EventOccurrence that defines the termination of the instance specified by the Lifeline on which the Stop occurs. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateSignature">
    <xsd:annotation>
      <xsd:documentation>A TemplateSignature is owned by a TemplateableElement and has one or more TemplateParameters that define the signature for binding this template. A TemplateSignature may reference a set of nested template signatures to reflect the hierarchical nature of a template. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="parameter" type="uml:TemplateParameter">
            <xsd:annotation>
              <xsd:documentation>The complete set of formal template parameters for this template signature.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedParameter" type="uml:TemplateParameter">
            <xsd:annotation>
              <xsd:documentation>The formal template parameters that are owned by this template signature. Subsets parameter and Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="nestedSignature" type="uml:TemplateSignature"/>
          <xsd:element name="nestingSignature" type="uml:TemplateSignature"/>
        </xsd:choice>
        <xsd:attribute name="parameter" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The complete set of formal template parameters for this template signature.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="nestedSignature" type="xsd:string"/>
        <xsd:attribute name="nestingSignature" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateSignature" type="uml:TemplateSignature">
    <xsd:annotation>
      <xsd:documentation>A TemplateSignature is owned by a TemplateableElement and has one or more TemplateParameters that define the signature for binding this template. A TemplateSignature may reference a set of nested template signatures to reflect the hierarchical nature of a template. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateParameter">
    <xsd:annotation>
      <xsd:documentation>TemplateParameter references a ParameterableElement which is exposed as a formal template parameter in the containing template. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="parameteredElement" type="uml:ParameterableElement"/>
          <xsd:element name="ownedParameteredElement" type="uml:ParameterableElement"/>
          <xsd:element name="default" type="uml:ParameterableElement">
            <xsd:annotation>
              <xsd:documentation>element that is the default for this formal template parameter.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedDefault" type="uml:ParameterableElement"/>
        </xsd:choice>
        <xsd:attribute name="parameteredElement" type="xsd:string"/>
        <xsd:attribute name="default" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>element that is the default for this formal template parameter.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateParameter" type="uml:TemplateParameter">
    <xsd:annotation>
      <xsd:documentation>TemplateParameter references a ParameterableElement which is exposed as a formal template parameter in the containing template. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateableElement">
    <xsd:annotation>
      <xsd:documentation>TemplateableElement may contain a template signature which specifies the formal template parameters. A TemplateableElement that contains a template signature is often referred to as a template. TemplateableElement may contain bindings to templates that describe how the templateable element is constructed by replacing the formal template parameters with actual parameters. A TemplateableElement containing bindings is often referred to as a bound element. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateBinding" type="uml:TemplateBinding">
            <xsd:annotation>
              <xsd:documentation>optional bindings from this element to templates.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedTemplateSignature" type="uml:TemplateSignature"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateableElement" type="uml:TemplateableElement">
    <xsd:annotation>
      <xsd:documentation>TemplateableElement may contain a template signature which specifies the formal template parameters. A TemplateableElement that contains a template signature is often referred to as a template. TemplateableElement may contain bindings to templates that describe how the templateable element is constructed by replacing the formal template parameters with actual parameters. A TemplateableElement containing bindings is often referred to as a bound element. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StringExpression">
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="subExpression" type="uml:StringExpression"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StringExpression" type="uml:StringExpression"/>
  <xsd:complexType name="ParameterableElement">
    <xsd:annotation>
      <xsd:documentation>A ParameterableElement can be referenced by a TemplateParameter when defining a formal template parameter for a template. A ParameterableElement can be referenced by a TemplateParameterSubstitution when used as an actual parameter in a binding of a template. ParameterableElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="templateParameter" type="uml:TemplateParameter"/>
        </xsd:choice>
        <xsd:attribute name="templateParameter" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ParameterableElement" type="uml:ParameterableElement">
    <xsd:annotation>
      <xsd:documentation>A ParameterableElement can be referenced by a TemplateParameter when defining a formal template parameter for a template. A ParameterableElement can be referenced by a TemplateParameterSubstitution when used as an actual parameter in a binding of a template. ParameterableElement is an abstract metaclass. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateBinding">
    <xsd:annotation>
      <xsd:documentation>TemplateBinding is a directed relationship from a bound templateable element to the template signature of the target template. A TemplateBinding owns a set of template parameter substitutions. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="signature" type="uml:TemplateSignature"/>
          <xsd:element name="parameterSubstitution" type="uml:TemplateParameterSubstitution">
            <xsd:annotation>
              <xsd:documentation>parameter substitutions owned by this template binding. Subsets Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="signature" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateBinding" type="uml:TemplateBinding">
    <xsd:annotation>
      <xsd:documentation>TemplateBinding is a directed relationship from a bound templateable element to the template signature of the target template. A TemplateBinding owns a set of template parameter substitutions. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateParameterSubstitution">
    <xsd:annotation>
      <xsd:documentation>TemplateParameterSubstitution associates one or more actual parameters with a formal template parameter within the context of a TemplateBinding. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="formal" type="uml:TemplateParameter">
            <xsd:annotation>
              <xsd:documentation>The formal template parameter that is associated with this substitution.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="actual" type="uml:ParameterableElement">
            <xsd:annotation>
              <xsd:documentation>elements that are the actual parameters for this substitution.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedActual" type="uml:ParameterableElement">
            <xsd:annotation>
              <xsd:documentation>The actual parameters that are owned by this substitution. Subsets Element:: ownedElement and actual.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="formal" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The formal template parameter that is associated with this substitution.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="actual" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>elements that are the actual parameters for this substitution.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateParameterSubstitution" type="uml:TemplateParameterSubstitution">
    <xsd:annotation>
      <xsd:documentation>TemplateParameterSubstitution associates one or more actual parameters with a formal template parameter within the context of a TemplateBinding. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="OperationTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>OperationTemplateParameter is a template parameter where the parametered element is an Operation. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateParameter"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="OperationTemplateParameter" type="uml:OperationTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>OperationTemplateParameter is a template parameter where the parametered element is an Operation. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ClassifierTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>ClassifierTemplateParameter is a template parameter where the parametered element is a Classifier in its capacity of being a kind of ParameterableElement. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateParameter">
        <xsd:attribute name="allowSubstitutable" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>the required relationship between an actual parameter and the parameteredElement for this formal parameter. Default is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ClassifierTemplateParameter" type="uml:ClassifierTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>ClassifierTemplateParameter is a template parameter where the parametered element is a Classifier in its capacity of being a kind of ParameterableElement. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ParameterableClassifier">
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ParameterableClassifier" type="uml:ParameterableClassifier"/>
  <xsd:complexType name="RedefinableTemplateSignature">
    <xsd:annotation>
      <xsd:documentation>RedefinableTemplateSignature specializes both TemplateSignature and RedefinableElement in order to allow the addition of new formal template parameters in the context of a specializing template Classifier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="parameter" type="uml:TemplateParameter">
            <xsd:annotation>
              <xsd:documentation>The complete set of formal template parameters for this template signature.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="ownedParameter" type="uml:TemplateParameter">
            <xsd:annotation>
              <xsd:documentation>The formal template parameters that are owned by this template signature. Subsets parameter and Element::ownedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="nestedSignature" type="uml:TemplateSignature"/>
          <xsd:element name="nestingSignature" type="uml:TemplateSignature"/>
        </xsd:choice>
        <xsd:attribute name="parameter" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The complete set of formal template parameters for this template signature.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="nestedSignature" type="xsd:string"/>
        <xsd:attribute name="nestingSignature" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="RedefinableTemplateSignature" type="uml:RedefinableTemplateSignature">
    <xsd:annotation>
      <xsd:documentation>RedefinableTemplateSignature specializes both TemplateSignature and RedefinableElement in order to allow the addition of new formal template parameters in the context of a specializing template Classifier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TemplateableClassifier">
    <xsd:complexContent>
      <xsd:extension base="uml:Classifier"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TemplateableClassifier" type="uml:TemplateableClassifier"/>
  <xsd:complexType name="ConnectableElementTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>ConnectableElementTemplateParameter is a template parameter where the parametered element is a ConnectableElement. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:TemplateParameter"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ConnectableElementTemplateParameter" type="uml:ConnectableElementTemplateParameter">
    <xsd:annotation>
      <xsd:documentation>ConnectableElementTemplateParameter is a template parameter where the parametered element is a ConnectableElement. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ForkNode">
    <xsd:annotation>
      <xsd:documentation>A fork node has one incoming edge and multiple outgoing edges. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ForkNode" type="uml:ForkNode">
    <xsd:annotation>
      <xsd:documentation>A fork node has one incoming edge and multiple outgoing edges. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="JoinNode">
    <xsd:complexContent>
      <xsd:extension base="uml:ControlNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="joinSpec" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>A specification giving the conditions under which the join will emit a token. Default is “and”.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isCombineDuplicate" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Tells whether tokens having objects with the same identity are combined into one by the join. Default value is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="JoinNode" type="uml:JoinNode"/>
  <xsd:complexType name="FlowFinalNode">
    <xsd:annotation>
      <xsd:documentation>A flow final destroys all tokens that arrive at it. It has no effect on other flows in the activity. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:FinalNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="FlowFinalNode" type="uml:FlowFinalNode">
    <xsd:annotation>
      <xsd:documentation>A flow final destroys all tokens that arrive at it. It has no effect on other flows in the activity. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CentralBufferNode">
    <xsd:annotation>
      <xsd:documentation>A central buffer node accepts tokens from upstream objects nodes and passes them along to downstream object nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly to actions. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ObjectNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CentralBufferNode" type="uml:CentralBufferNode">
    <xsd:annotation>
      <xsd:documentation>A central buffer node accepts tokens from upstream objects nodes and passes them along to downstream object nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly to actions. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ActivityPartition">
    <xsd:annotation>
      <xsd:documentation>Partitions divide the nodes and edges to constrain and show a view of the contained nodes. Partitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an activity. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="containedEdge" type="uml:ActivityEdge"/>
          <xsd:element name="containedNode" type="uml:ActivityNode"/>
          <xsd:element name="subgroup" type="uml:ActivityPartition"/>
          <xsd:element name="represents" type="uml:Element">
            <xsd:annotation>
              <xsd:documentation>An element constraining behaviors invoked by nodes in the partition.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDimension" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Tells whether the partition groups other partitions along a dimension.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="isExternal" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Tells whether the partition represents an entity to which the partitioning structure does not apply.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="containedEdge" type="xsd:string"/>
        <xsd:attribute name="containedNode" type="xsd:string"/>
        <xsd:attribute name="represents" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An element constraining behaviors invoked by nodes in the partition.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ActivityPartition" type="uml:ActivityPartition">
    <xsd:annotation>
      <xsd:documentation>Partitions divide the nodes and edges to constrain and show a view of the contained nodes. Partitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an activity. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExpansionNode">
    <xsd:annotation>
      <xsd:documentation>(ExtraStructuredActivities) An expansion node is an object node used to indicate a flow across the boundary of an expansion region. A flow into a region contains a collection that is broken into its individual elements inside the region, which is executed once per element. A flow out of a region combines individual elements into a collection for use outside the region. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ObjectNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="regionAsOutput" type="uml:ExpansionRegion">
            <xsd:annotation>
              <xsd:documentation>expansion region for which the node is an output.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="regionAsInput" type="uml:ExpansionRegion">
            <xsd:annotation>
              <xsd:documentation>expansion region for which the node is an input.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="regionAsOutput" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>expansion region for which the node is an output.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="regionAsInput" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>expansion region for which the node is an input.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExpansionNode" type="uml:ExpansionNode">
    <xsd:annotation>
      <xsd:documentation>(ExtraStructuredActivities) An expansion node is an object node used to indicate a flow across the boundary of an expansion region. A flow into a region contains a collection that is broken into its individual elements inside the region, which is executed once per element. A flow out of a region combines individual elements into a collection for use outside the region. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExpansionRegion">
    <xsd:annotation>
      <xsd:documentation>An expansion region is a strictly nested region of an activity with explicit input and outputs (modeled as ExpansionNodes). Each input is a collection of values. If there are multiple input pins, each of them must hold the same kind of collection, although the types of the elements in the different collections may vary. The expansion region is executed once for each element (or position) in the input collection. If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs. The number of output collections at runtime can differ from the number of input collections. On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements. If the region execution ends with no output, then nothing is added to the output collection. If all the executions provide an output to the collection, then the output collections will have the same number of elements as the input collections. The inputs and outputs to an expansion region are modeled as ExpansionNodes. From “outside” of the region, the values on these nodes appear as collections. From “inside” the region the values appear as elements of the collections. Object flow edges connect pins outside the region to input and output expansion nodes as collections. Object flow edges connect pins inside the region to input and output expansion nodes as individual elements. From the inside of the region, these nodes are visible as individual values. If an expansion node has a name, it is the name of the individual element within the region. Any object flow edges that cross the boundary of the region, without passing through expansion nodes, provide values that are fixed within the different executions of the region. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuredActivityNode">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="outputElement" type="uml:ExpansionNode">
            <xsd:annotation>
              <xsd:documentation>An object node that accepts a separate element of the output collection during each of the multiple executions of the region. The values are formed into a collection that is available when the execution of the region is complete.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="inputElement" type="uml:ExpansionNode">
            <xsd:annotation>
              <xsd:documentation>An object node that holds a separate element of the input collection during each of the multiple executions of the region.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="mode" type="uml:ExpansionKind">
          <xsd:annotation>
            <xsd:documentation>The way in which the executions interact: parallel — all interactions are independent iterative — the interactions occur in order of the elements stream — a stream of values flows into a single execution</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="outputElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An object node that accepts a separate element of the output collection during each of the multiple executions of the region. The values are formed into a collection that is available when the execution of the region is complete.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="inputElement" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An object node that holds a separate element of the input collection during each of the multiple executions of the region.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExpansionRegion" type="uml:ExpansionRegion">
    <xsd:annotation>
      <xsd:documentation>An expansion region is a strictly nested region of an activity with explicit input and outputs (modeled as ExpansionNodes). Each input is a collection of values. If there are multiple input pins, each of them must hold the same kind of collection, although the types of the elements in the different collections may vary. The expansion region is executed once for each element (or position) in the input collection. If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs. The number of output collections at runtime can differ from the number of input collections. On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements. If the region execution ends with no output, then nothing is added to the output collection. If all the executions provide an output to the collection, then the output collections will have the same number of elements as the input collections. The inputs and outputs to an expansion region are modeled as ExpansionNodes. From “outside” of the region, the values on these nodes appear as collections. From “inside” the region the values appear as elements of the collections. Object flow edges connect pins outside the region to input and output expansion nodes as collections. Object flow edges connect pins inside the region to input and output expansion nodes as individual elements. From the inside of the region, these nodes are visible as individual values. If an expansion node has a name, it is the name of the individual element within the region. Any object flow edges that cross the boundary of the region, without passing through expansion nodes, provide values that are fixed within the different executions of the region. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExceptionHandler">
    <xsd:annotation>
      <xsd:documentation>(ExtraStructuredActivities) An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="handlerBody" type="uml:ExecutableNode">
            <xsd:annotation>
              <xsd:documentation>A node that is executed if the handler satisfies an uncaught exception.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="exceptionInput" type="uml:ObjectNode"/>
          <xsd:element name="exceptionType" type="uml:Classifier"/>
        </xsd:choice>
        <xsd:attribute name="handlerBody" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A node that is executed if the handler satisfies an uncaught exception.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="exceptionInput" type="xsd:string"/>
        <xsd:attribute name="exceptionType" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExceptionHandler" type="uml:ExceptionHandler">
    <xsd:annotation>
      <xsd:documentation>(ExtraStructuredActivities) An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InteractionOccurrence">
    <xsd:annotation>
      <xsd:documentation>InteractionOccurrence is a specialization of InteractionFragment. An InteractionOccurrence has a set of actual gates that must match the formal gates of the referenced Interaction. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="refersTo" type="uml:Interaction">
            <xsd:annotation>
              <xsd:documentation>Refers to the Interaction that defines its meaning</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="actualGate" type="uml:Gate">
            <xsd:annotation>
              <xsd:documentation>The actual gates of the InteractionOccurrence</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="argument" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>The actual arguments of the Interaction</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="refersTo" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Refers to the Interaction that defines its meaning</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InteractionOccurrence" type="uml:InteractionOccurrence">
    <xsd:annotation>
      <xsd:documentation>InteractionOccurrence is a specialization of InteractionFragment. An InteractionOccurrence has a set of actual gates that must match the formal gates of the referenced Interaction. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Gate">
    <xsd:annotation>
      <xsd:documentation>A Gate is a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment. Gate is a specialization of MessageEnd. Gates are connected through Messages. A Gate is actually a representative of an EventOccurrence that is not in the same scope as the Gate. Gates play different roles: we have formal gates on Interactions, actual gates on InteractionOccurrences, expression gates on CombinedFragments. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:MessageEnd"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Gate" type="uml:Gate">
    <xsd:annotation>
      <xsd:documentation>A Gate is a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment. Gate is a specialization of MessageEnd. Gates are connected through Messages. A Gate is actually a representative of an EventOccurrence that is not in the same scope as the Gate. Gates play different roles: we have formal gates on Interactions, actual gates on InteractionOccurrences, expression gates on CombinedFragments. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PartDecomposition">
    <xsd:annotation>
      <xsd:documentation>PartDecomposition is a description of the internal interactions of one Lifeline relative to an Interaction. A Lifeline has a class associated as the type of the ConnectableElement that the Lifeline represents. That class may have an internal structure and the PartDecomposition is an Interaction that describes the behavior of that internal structure relative to the Interaction where the decomposition is referenced. A PartDecomposition is a specialization of InteractionOccurrence. It associates with the ConnectableElement that it decomposes. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionOccurrence"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PartDecomposition" type="uml:PartDecomposition">
    <xsd:annotation>
      <xsd:documentation>PartDecomposition is a description of the internal interactions of one Lifeline relative to an Interaction. A Lifeline has a class associated as the type of the ConnectableElement that the Lifeline represents. That class may have an internal structure and the PartDecomposition is an Interaction that describes the behavior of that internal structure relative to the Interaction where the decomposition is referenced. A PartDecomposition is a specialization of InteractionOccurrence. It associates with the ConnectableElement that it decomposes. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InteractionOperand">
    <xsd:annotation>
      <xsd:documentation>An InteractionOperand is contained in a CombinedFragment. An InteractionOperand represent one operand of the expression given by the enclosing CombinedFragment. An InteractionOperand is an InteractionFragment with an optional guard expression. An InteractionOperand may be guarded by a InteractionConstraint. Only InteractionOperands with a guard that evaluates to true at this point in the interaction will be considered for the production of the traces for the enclosing CombinedFragment. InteractionOperand contains an ordered set of InteractionFragments. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="covered" type="uml:Lifeline"/>
          <xsd:element name="generalOrdering" type="uml:GeneralOrdering"/>
          <xsd:element name="guard" type="uml:InteractionConstraint">
            <xsd:annotation>
              <xsd:documentation>of the operand</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="fragment" type="uml:InteractionFragment">
            <xsd:annotation>
              <xsd:documentation>fragments of the operand.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="covered" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InteractionOperand" type="uml:InteractionOperand">
    <xsd:annotation>
      <xsd:documentation>An InteractionOperand is contained in a CombinedFragment. An InteractionOperand represent one operand of the expression given by the enclosing CombinedFragment. An InteractionOperand is an InteractionFragment with an optional guard expression. An InteractionOperand may be guarded by a InteractionConstraint. Only InteractionOperands with a guard that evaluates to true at this point in the interaction will be considered for the production of the traces for the enclosing CombinedFragment. InteractionOperand contains an ordered set of InteractionFragments. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InteractionConstraint">
    <xsd:annotation>
      <xsd:documentation>An InteractionConstraint is a boolean expression that guards an operand in a CombinedFragment. InteractionConstraint is a specialization of Constraint. Furthermore the InteractionConstraint contains two expressions designating the minimum and maximum number of times a loop CombinedFragment should execute. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Constraint">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="minint" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>minimum number of iterations of a loop</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="maxint" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>maximum number of iterations of a loop</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InteractionConstraint" type="uml:InteractionConstraint">
    <xsd:annotation>
      <xsd:documentation>An InteractionConstraint is a boolean expression that guards an operand in a CombinedFragment. InteractionConstraint is a specialization of Constraint. Furthermore the InteractionConstraint contains two expressions designating the minimum and maximum number of times a loop CombinedFragment should execute. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CombinedFragment">
    <xsd:annotation>
      <xsd:documentation>A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of CombinedFragments the user will be able to describe a number of traces in a compact and concise manner. CombinedFragment is a specialization of InteractionFragment. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="operand" type="uml:InteractionOperand">
            <xsd:annotation>
              <xsd:documentation>set of operands of the combined fragment.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="cfragmentGate" type="uml:Gate">
            <xsd:annotation>
              <xsd:documentation>Specifies the gates that form the interface between this CombinedFragment and its surroundings</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="interactionOperator" type="uml:InteractionOperator">
          <xsd:annotation>
            <xsd:documentation>Specifies the operation which defines the semantics of this combination of InteractionFragments.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CombinedFragment" type="uml:CombinedFragment">
    <xsd:annotation>
      <xsd:documentation>A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of CombinedFragments the user will be able to describe a number of traces in a compact and concise manner. CombinedFragment is a specialization of InteractionFragment. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Continuation">
    <xsd:annotation>
      <xsd:documentation>A Continuation is a syntactic way to define continuations of different branches of an Alternative CombinedFragment. Continuations is intuitively similar to labels representing intermediate points in a flow of control. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InteractionFragment">
        <xsd:attribute name="setting" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>True: when the Continuation is at the end of the enclosing InteractionFragment and False when it is in the beginning.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Continuation" type="uml:Continuation">
    <xsd:annotation>
      <xsd:documentation>A Continuation is a syntactic way to define continuations of different branches of an Alternative CombinedFragment. Continuations is intuitively similar to labels representing intermediate points in a flow of control. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StateMachine">
    <xsd:complexContent>
      <xsd:extension base="uml:Behavior">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="region" type="uml:Region"/>
          <xsd:element name="connectionPoint" type="uml:Pseudostate"/>
          <xsd:element name="extendedStateMachine" type="uml:StateMachine"/>
        </xsd:choice>
        <xsd:attribute name="extendedStateMachine" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StateMachine" type="uml:StateMachine"/>
  <xsd:complexType name="Region">
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="subvertex" type="uml:Vertex"/>
          <xsd:element name="transition" type="uml:Transition"/>
          <xsd:element name="extendedRegion" type="uml:Region"/>
        </xsd:choice>
        <xsd:attribute name="isLeaf" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="extendedRegion" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Region" type="uml:Region"/>
  <xsd:complexType name="Pseudostate">
    <xsd:complexContent>
      <xsd:extension base="uml:Vertex">
        <xsd:attribute name="kind" type="uml:PseudostateKind"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Pseudostate" type="uml:Pseudostate"/>
  <xsd:complexType name="State">
    <xsd:complexContent>
      <xsd:extension base="uml:Namespace">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="outgoing" type="uml:Transition">
            <xsd:annotation>
              <xsd:documentation>Specifies the transitions departing from this vertex.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="incoming" type="uml:Transition">
            <xsd:annotation>
              <xsd:documentation>Specifies the transitions entering this vertex.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="submachine" type="uml:StateMachine"/>
          <xsd:element name="connection" type="uml:ConnectionPointReference"/>
          <xsd:element name="redefinedState" type="uml:State"/>
          <xsd:element name="deferrableTrigger" type="uml:Trigger"/>
          <xsd:element name="region" type="uml:Region"/>
          <xsd:element name="entry" type="uml:Activity"/>
          <xsd:element name="exit" type="uml:Activity"/>
          <xsd:element name="doActivity" type="uml:Activity"/>
          <xsd:element name="stateInvariant" type="uml:Constraint"/>
        </xsd:choice>
        <xsd:attribute name="isLeaf" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="outgoing" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the transitions departing from this vertex.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="incoming" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the transitions entering this vertex.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="submachine" type="xsd:string"/>
        <xsd:attribute name="redefinedState" type="xsd:string"/>
        <xsd:attribute name="deferrableTrigger" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="State" type="uml:State"/>
  <xsd:complexType name="Vertex">
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="outgoing" type="uml:Transition">
            <xsd:annotation>
              <xsd:documentation>Specifies the transitions departing from this vertex.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="incoming" type="uml:Transition">
            <xsd:annotation>
              <xsd:documentation>Specifies the transitions entering this vertex.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="outgoing" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the transitions departing from this vertex.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="incoming" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the transitions entering this vertex.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Vertex" type="uml:Vertex"/>
  <xsd:complexType name="ConnectionPointReference">
    <xsd:annotation>
      <xsd:documentation>Connection point references of a submachine state can be used as sources/targets of transitions. They represent entries into or exits out of the submachine state machine referenced by the submachine state. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Vertex">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="entry" type="uml:Pseudostate">
            <xsd:annotation>
              <xsd:documentation>The entryPoint kind pseudo states corresponding to this connection point.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="exit" type="uml:Pseudostate">
            <xsd:annotation>
              <xsd:documentation>The exitPoints kind pseudo states corresponding to this connection point.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="entry" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The entryPoint kind pseudo states corresponding to this connection point.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="exit" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The exitPoints kind pseudo states corresponding to this connection point.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ConnectionPointReference" type="uml:ConnectionPointReference">
    <xsd:annotation>
      <xsd:documentation>Connection point references of a submachine state can be used as sources/targets of transitions. They represent entries into or exits out of the submachine state machine referenced by the submachine state. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Transition">
    <xsd:complexContent>
      <xsd:extension base="uml:RedefinableElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="source" type="uml:Vertex">
            <xsd:annotation>
              <xsd:documentation>Designates the originating vertex (state or pseudostate) of the transition.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="target" type="uml:Vertex">
            <xsd:annotation>
              <xsd:documentation>Designates the target vertex that is reached when the transition is taken.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="redefinedTransition" type="uml:Transition"/>
          <xsd:element name="trigger" type="uml:Trigger">
            <xsd:annotation>
              <xsd:documentation>Specifies the triggers that may fire the transition.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="guard" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event is dispatched by the state machine. If the guard is true at that time, the transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="effect" type="uml:Activity">
            <xsd:annotation>
              <xsd:documentation>Specifies an optional activity to be performed when the transition fires.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="kind" type="uml:TransitionKind">
          <xsd:annotation>
            <xsd:documentation>See definition of TransitionKind.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="source" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Designates the originating vertex (state or pseudostate) of the transition.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="target" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Designates the target vertex that is reached when the transition is taken.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="redefinedTransition" type="xsd:string"/>
        <xsd:attribute name="trigger" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the triggers that may fire the transition.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Transition" type="uml:Transition"/>
  <xsd:complexType name="FinalState">
    <xsd:complexContent>
      <xsd:extension base="uml:State"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="FinalState" type="uml:FinalState"/>
  <xsd:complexType name="CreateObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action instantiates a classifier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="classifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>Classifier to be instantiated.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) Gives the output pin on which the result is put.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="classifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Classifier to be instantiated.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CreateObjectAction" type="uml:CreateObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action instantiates a classifier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DestroyObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action destroys the object on its input pin at runtime. The object may be a link object, in which case the semantics of DestroyLinkAction also applies. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="target" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) The input pin providing the object to be destroyed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDestroyLinks" type="xsd:string"/>
        <xsd:attribute name="isDestroyOwnedObjects" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DestroyObjectAction" type="uml:DestroyObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action destroys the object on its input pin at runtime. The object may be a link object, in which case the semantics of DestroyLinkAction also applies. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TestIdentityAction">
    <xsd:annotation>
      <xsd:documentation>This action returns true if the two input values are the same identity, false if they are not. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="first" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>. (Specialized from Action:input) Gives the pin on which an object is placed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="second" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the pin on which an object is placed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) Tells whether the two input objects are identical.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TestIdentityAction" type="uml:TestIdentityAction">
    <xsd:annotation>
      <xsd:documentation>This action returns true if the two input values are the same identity, false if they are not. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadSelfAction">
    <xsd:annotation>
      <xsd:documentation>Every action is ultimately a part of some activity, which is in turn optionally attached in some way to the specification of a classifier—for example as the body of a method or as part of a state machine. When the activity executes, it does so in the context of some specific host instance of that classifier. This action produces this host instance, if any, on its output pin. The type of the output pin is the classifier to which the activity is associated in the user model. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) Gives the output pin on which the hosting object is placed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadSelfAction" type="uml:ReadSelfAction">
    <xsd:annotation>
      <xsd:documentation>Every action is ultimately a part of some activity, which is in turn optionally attached in some way to the specification of a classifier—for example as the body of a method or as part of a state machine. When the activity executes, it does so in the context of some specific host instance of that classifier. This action produces this host instance, if any, on its output pin. The type of the output pin is the classifier to which the activity is associated in the user model. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This abstract action class statically specifies the structural feature being accessed. The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="structuralFeature" type="uml:StructuralFeature">
            <xsd:annotation>
              <xsd:documentation>Structural feature to be read.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the input pin from which the object whose structural feature is to be read or written is obtained.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="structuralFeature" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Structural feature to be read.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StructuralFeatureAction" type="uml:StructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This abstract action class statically specifies the structural feature being accessed. The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the values of a structural feature, in order if the structural feature is ordered. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuralFeatureAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) Gives the output pin on which the result is put.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadStructuralFeatureAction" type="uml:ReadStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the values of a structural feature, in order if the structural feature is ordered. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="WriteStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>A write structural feature action operates on a structural feature 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 structural feature actions are inherited from StructuralFeatureAction. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuralFeatureAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="value" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Value to be added or removed from the structural feature.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="WriteStructuralFeatureAction" type="uml:WriteStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>A write structural feature action operates on a structural feature 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 structural feature actions are inherited from StructuralFeatureAction. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ClearStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This action removes all values of a structural feature. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:StructuralFeatureAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ClearStructuralFeatureAction" type="uml:ClearStructuralFeatureAction">
    <xsd:annotation>
      <xsd:documentation>This action removes all values of a structural feature. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="RemoveStructuralFeatureValueAction">
    <xsd:annotation>
      <xsd:documentation>The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteStructuralFeatureAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="RemoveStructuralFeatureValueAction" type="uml:RemoveStructuralFeatureValueAction">
    <xsd:annotation>
      <xsd:documentation>The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="AddStructuralFeatureValueAction">
    <xsd:annotation>
      <xsd:documentation>Structural Features are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the structural feature before the new value is added. The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteStructuralFeatureAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="insertAt" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the position at which to insert a new value or move an existing value in ordered structural features. The type of the pin is UnlimitedNatural, but the value cannot be zero. This pin is omitted for unordered structural features.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isReplaceAll" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether existing values of the structural feature of the object should be removed before adding the new value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AddStructuralFeatureValueAction" type="uml:AddStructuralFeatureValueAction">
    <xsd:annotation>
      <xsd:documentation>Structural Features are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the structural feature before the new value is added. The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value’s multiplicity is 1..1. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LinkAction">
    <xsd:annotation>
      <xsd:documentation>A link action creates, destroys, or reads links, identifying a link by its end objects and qualifier values, if any. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="endData" type="uml:LinkEndData">
            <xsd:annotation>
              <xsd:documentation>Data identifying one end of a link by the objects on its ends and qualifiers.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LinkAction" type="uml:LinkAction">
    <xsd:annotation>
      <xsd:documentation>A link action creates, destroys, or reads links, identifying a link by its end objects and qualifier values, if any. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LinkEndData">
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="value" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Input pin that provides the specified object for the given end. This pin is omitted if the link-end data specifies an “open” end for reading.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="end" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>Association end for which this link-end data specifies values.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="qualifier" type="uml:QualifierValue">
            <xsd:annotation>
              <xsd:documentation>Attribute representing the qualifier for which the value is to be specified.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Input pin that provides the specified object for the given end. This pin is omitted if the link-end data specifies an “open” end for reading.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="end" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Association end for which this link-end data specifies values.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LinkEndData" type="uml:LinkEndData"/>
  <xsd:complexType name="ReadLinkAction">
    <xsd:annotation>
      <xsd:documentation>This action navigates an association towards one end, which is the end 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. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LinkAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) The pin on which are put the objects participating in the association at the end not specified by the inputs.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadLinkAction" type="uml:ReadLinkAction">
    <xsd:annotation>
      <xsd:documentation>This action navigates an association towards one end, which is the end 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. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="LinkEndCreationData">
    <xsd:complexContent>
      <xsd:extension base="uml:LinkEndData">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="insertAt" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Specifies where the new link should be inserted for ordered association ends, or where an existing link should be moved to. The type of the input is UnlimitedNatural, but the input cannot be zero. This pin is omitted for association ends that are not ordered.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isReplaceAll" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>= falseSpecifies whether the existing links emanating from the object on this end should be destroyed before creating a new link.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="insertAt" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies where the new link should be inserted for ordered association ends, or where an existing link should be moved to. The type of the input is UnlimitedNatural, but the input cannot be zero. This pin is omitted for association ends that are not ordered.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LinkEndCreationData" type="uml:LinkEndCreationData"/>
  <xsd:complexType name="CreateLinkAction">
    <xsd:annotation>
      <xsd:documentation>This action can be used to create links and link objects. There is no return value in either case. This is so that no change of the action is required if the association is changed to an association class or vice versa. CreateLinkAction uses a specialization of LinkEndData called LinkEndCreationData, to support ordered associations. The insertion point is specified at runtime by an additional input pin, which is required for ordered association ends and omitted for unordered ends. The insertion point is a positive integer giving the position to insert the link, or infinity, to insert at the end. Reinserting an existing end at a new position moves the end to that position. CreateLinkAction also uses LinkEndCreationData to support the destruction of existing links of the association that connect any of the objects of the new link. When the link is created, 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. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteLinkAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CreateLinkAction" type="uml:CreateLinkAction">
    <xsd:annotation>
      <xsd:documentation>This action can be used to create links and link objects. There is no return value in either case. This is so that no change of the action is required if the association is changed to an association class or vice versa. CreateLinkAction uses a specialization of LinkEndData called LinkEndCreationData, to support ordered associations. The insertion point is specified at runtime by an additional input pin, which is required for ordered association ends and omitted for unordered ends. The insertion point is a positive integer giving the position to insert the link, or infinity, to insert at the end. Reinserting an existing end at a new position moves the end to that position. CreateLinkAction also uses LinkEndCreationData to support the destruction of existing links of the association that connect any of the objects of the new link. When the link is created, 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. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="WriteLinkAction">
    <xsd:annotation>
      <xsd:documentation>A write link action takes a complete identification of a link and creates or destroys it. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:LinkAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="WriteLinkAction" type="uml:WriteLinkAction">
    <xsd:annotation>
      <xsd:documentation>A write link action takes a complete identification of a link and creates or destroys it. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DestroyLinkAction">
    <xsd:annotation>
      <xsd:documentation>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. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteLinkAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DestroyLinkAction" type="uml:DestroyLinkAction">
    <xsd:annotation>
      <xsd:documentation>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. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ClearAssociationAction">
    <xsd:annotation>
      <xsd:documentation>This action destroys all links of an association that have a particular object at one end. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the input pin from which is obtained the object whose participation in the association is to be cleared.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="association" type="uml:Association">
            <xsd:annotation>
              <xsd:documentation>Association to be cleared.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="association" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Association to be cleared.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ClearAssociationAction" type="uml:ClearAssociationAction">
    <xsd:annotation>
      <xsd:documentation>This action destroys all links of an association that have a particular object at one end. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="VariableAction">
    <xsd:annotation>
      <xsd:documentation>VariableAction is an abstract class for actions that operate on a statically specified variable. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="variable" type="uml:Variable">
            <xsd:annotation>
              <xsd:documentation>Variable to be read.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="variable" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Variable to be read.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="VariableAction" type="uml:VariableAction">
    <xsd:annotation>
      <xsd:documentation>VariableAction is an abstract class for actions that operate on a statically specified variable. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadVariableAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the values of a variables, in order if the variable is ordered. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:VariableAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:output) Gives the output pin on which the result is put.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadVariableAction" type="uml:ReadVariableAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the values of a variables, in order if the variable is ordered. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="WriteVariableAction">
    <xsd:annotation>
      <xsd:documentation>A write variable action operates on a variable 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 variable actions are inherited from VariableAction. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:VariableAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="value" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Value to be added or removed from the variable.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="WriteVariableAction" type="uml:WriteVariableAction">
    <xsd:annotation>
      <xsd:documentation>A write variable action operates on a variable 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 variable actions are inherited from VariableAction. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ClearVariableAction">
    <xsd:annotation>
      <xsd:documentation>This action removes all values of an variable. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:VariableAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ClearVariableAction" type="uml:ClearVariableAction">
    <xsd:annotation>
      <xsd:documentation>This action removes all values of an variable. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="AddVariableValueAction">
    <xsd:annotation>
      <xsd:documentation>Variables are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the variable before the new value is added. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteVariableAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="insertAt" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the position at which to insert a new value or move an existing value in ordered variables. The types is UnlimitedINatural, but the value cannot be zero. This pin is omitted for unordered variables.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isReplaceAll" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether existing values of the variable should be removed before adding the new value.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AddVariableValueAction" type="uml:AddVariableValueAction">
    <xsd:annotation>
      <xsd:documentation>Variables are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the variable before the new value is added. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="RemoveVariableValueAction">
    <xsd:annotation>
      <xsd:documentation>One value is removed from the set of possible variable values. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteVariableAction"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="RemoveVariableValueAction" type="uml:RemoveVariableValueAction">
    <xsd:annotation>
      <xsd:documentation>One value is removed from the set of possible variable values. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ApplyFunctionAction">
    <xsd:annotation>
      <xsd:documentation>ApplyFunctionAction is an action that invokes a primitive predefined function that computes output values based only on the input values and the function. The execution does not have access to object memory or to any objects. The execution of a primitive function has no side effects on any other object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="function" type="uml:PrimitiveFunction">
            <xsd:annotation>
              <xsd:documentation>The primitive function to be invoked.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="argument" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>The pins that provide inputs to the function. (Specializes Action.input.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>The pins on which the results of invoking the function are returned. (Specializes Action.output.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="function" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The primitive function to be invoked.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ApplyFunctionAction" type="uml:ApplyFunctionAction">
    <xsd:annotation>
      <xsd:documentation>ApplyFunctionAction is an action that invokes a primitive predefined function that computes output values based only on the input values and the function. The execution does not have access to object memory or to any objects. The execution of a primitive function has no side effects on any other object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="PrimitiveFunction">
    <xsd:annotation>
      <xsd:documentation>PrimitiveFunction is not an action. It is the signature of a function that produces output values from input values for use with ApplyFunctionAction. The behavior is described using the body and language attributes. The specification of the detailed behavior is expressed in an external language and is not further specified within UML. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:PackageableElement">
        <xsd:attribute name="body" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A textual representation of the function in the named surface language.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="language" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the language in which the body of the primitive function is stated. The interpretation of the body depends on the language. If the language is unspecified, it might be implicit from the body or the context.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="PrimitiveFunction" type="uml:PrimitiveFunction">
    <xsd:annotation>
      <xsd:documentation>PrimitiveFunction is not an action. It is the signature of a function that produces output values from input values for use with ApplyFunctionAction. The behavior is described using the body and language attributes. The specification of the detailed behavior is expressed in an external language and is not further specified within UML. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CallAction">
    <xsd:annotation>
      <xsd:documentation>CallAction is an abstract class for actions that invoke behavior and receive return values. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InvocationAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>A list of output pins where the results of performing the invocation are placed.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isSynchronous" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>If true, the call is synchronous and the caller waits for completion of the invoked behavior. If false, the call is asynchronous and the caller proceeds immediately and does not expect a return values.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CallAction" type="uml:CallAction">
    <xsd:annotation>
      <xsd:documentation>CallAction is an abstract class for actions that invoke behavior and receive return values. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InvocationAction">
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="argument" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Specification of an argument value that appears during execution.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="onPort" type="uml:Port"/>
        </xsd:choice>
        <xsd:attribute name="onPort" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InvocationAction" type="uml:InvocationAction"/>
  <xsd:complexType name="SendSignalAction">
    <xsd:annotation>
      <xsd:documentation>SendSignalAction is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may cause the firing of a state machine transition or the execution of an activity. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor. If the input is already a signal instance, use SendObjectAction. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InvocationAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="target" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>The target object to which the signal is sent.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="signal" type="uml:Signal">
            <xsd:annotation>
              <xsd:documentation>The type of signal transmitted to the target object.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="signal" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of signal transmitted to the target object.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SendSignalAction" type="uml:SendSignalAction">
    <xsd:annotation>
      <xsd:documentation>SendSignalAction is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may cause the firing of a state machine transition or the execution of an activity. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor. If the input is already a signal instance, use SendObjectAction. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="BroadcastSignalAction">
    <xsd:annotation>
      <xsd:documentation>BroadcastSignalAction is an action that transmits a signal instance to all the potential target objects in the system, which may cause the firing of a state machine transitions or the execution of associated activities of a target object. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately after the signals are sent out. It does not wait for receipt. Any reply messages are ignored and are not transmitted to the requestor. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InvocationAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="signal" type="uml:Signal">
            <xsd:annotation>
              <xsd:documentation>The specification of signal object transmitted to the target objects.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="signal" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The specification of signal object transmitted to the target objects.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="BroadcastSignalAction" type="uml:BroadcastSignalAction">
    <xsd:annotation>
      <xsd:documentation>BroadcastSignalAction is an action that transmits a signal instance to all the potential target objects in the system, which may cause the firing of a state machine transitions or the execution of associated activities of a target object. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately after the signals are sent out. It does not wait for receipt. Any reply messages are ignored and are not transmitted to the requestor. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="SendObjectAction">
    <xsd:annotation>
      <xsd:documentation>SendObjectAction is an action that transmits an object to the target object, where it may invoke behavior such as the firing of state machine transitions or the execution of an activity. The value of the object is available to the execution of invoked behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:InvocationAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="target" type="uml:InputPin"/>
          <xsd:element name="request" type="uml:InputPin"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SendObjectAction" type="uml:SendObjectAction">
    <xsd:annotation>
      <xsd:documentation>SendObjectAction is an action that transmits an object to the target object, where it may invoke behavior such as the firing of state machine transitions or the execution of an activity. The value of the object is available to the execution of invoked behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CallOperationAction">
    <xsd:annotation>
      <xsd:documentation>CallOperationAction is an action that transmits an operation call request to the target object, where it may cause the invocation of associated behavior. The argument values of the action are available to the execution of the invoked behavior. If the action is marked synchronous, the execution of the call operation action waits until the execution of the invoked behavior completes and a reply transmission is returned to the caller; otherwise execution of the action is complete when the invocation of the operation is established and the execution of the invoked operation proceeds concurrently with the execution of the calling activity. Any values returned as part of the reply transmission are put on the result output pins of the call operation action. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:CallAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="operation" type="uml:Operation">
            <xsd:annotation>
              <xsd:documentation>The operation to be invoked by the action execution</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="target" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>The target object to which the request is sent. The classifier of the target object is used to dynamically determine a behavior to invoke. This object constitutes the context of the execution of the operation.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="operation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The operation to be invoked by the action execution</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CallOperationAction" type="uml:CallOperationAction">
    <xsd:annotation>
      <xsd:documentation>CallOperationAction is an action that transmits an operation call request to the target object, where it may cause the invocation of associated behavior. The argument values of the action are available to the execution of the invoked behavior. If the action is marked synchronous, the execution of the call operation action waits until the execution of the invoked behavior completes and a reply transmission is returned to the caller; otherwise execution of the action is complete when the invocation of the operation is established and the execution of the invoked operation proceeds concurrently with the execution of the calling activity. Any values returned as part of the reply transmission are put on the result output pins of the call operation action. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CallBehaviorAction">
    <xsd:annotation>
      <xsd:documentation>CallBehaviorAction is a call action that invokes a behavior directly rather than invoking a behavioral feature that, in turn, results in the invocation of that behavior. The argument values of the action are available to the execution of the invoked behavior. The execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. In particular, the invoked behavior may be an activity. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:CallAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="behavior" type="uml:Behavior">
            <xsd:annotation>
              <xsd:documentation>The invoked behavior. It must be capable of accepting and returning control.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="behavior" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The invoked behavior. It must be capable of accepting and returning control.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CallBehaviorAction" type="uml:CallBehaviorAction">
    <xsd:annotation>
      <xsd:documentation>CallBehaviorAction is a call action that invokes a behavior directly rather than invoking a behavioral feature that, in turn, results in the invocation of that behavior. The argument values of the action are available to the execution of the invoked behavior. The execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. In particular, the invoked behavior may be an activity. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TimeExpression">
    <xsd:annotation>
      <xsd:documentation>A TimeExpression defines a value specification that represent a time value. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="event" type="uml:NamedElement">
            <xsd:annotation>
              <xsd:documentation>Refers to the specification of the event occurrence that the TimeExpression describes</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="firstTime" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>True if the TimeExpression describes the first point in time of the NamedElement referenced by event, in cases where the NamedElement describes something which extends in time. False if the TimeExpression describes the last point in time for the referenced NamedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="event" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Refers to the specification of the event occurrence that the TimeExpression describes</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TimeExpression" type="uml:TimeExpression">
    <xsd:annotation>
      <xsd:documentation>A TimeExpression defines a value specification that represent a time value. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Duration">
    <xsd:annotation>
      <xsd:documentation>A duration defines a value specification that specifies the temporal distance between two time expressions that specify time instants. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="event" type="uml:NamedElement">
            <xsd:annotation>
              <xsd:documentation>Refers to the specification(s) that describes the starting TimeExpression and the ending TimeExpression of the Duration. If only one NamedElement is referenced, the duration is from the first point in time of that NamedElement until the last point in time of that NamedElement.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="firstTime" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>If the duration is between times of two NamedElements, there are two Boolean attributes, one for the start of the duration and one for the end of the duration. For each of these it holds that firstTime is true if the time information is associated with the first point in time of the NamedElement referenced by event, and false if it represents the last point in time of the NamedElement. If there is only one NamedElement referenced by event, then this attribute is irrelevant. The default value is true.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="event" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Refers to the specification(s) that describes the starting TimeExpression and the ending TimeExpression of the Duration. If only one NamedElement is referenced, the duration is from the first point in time of that NamedElement until the last point in time of that NamedElement.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Duration" type="uml:Duration">
    <xsd:annotation>
      <xsd:documentation>A duration defines a value specification that specifies the temporal distance between two time expressions that specify time instants. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TimeObservationAction">
    <xsd:annotation>
      <xsd:documentation>A TimeObservationAction defines an action that observes the current point in time. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteStructuralFeatureAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="now" type="uml:TimeExpression">
            <xsd:annotation>
              <xsd:documentation>Represents the current point in time.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TimeObservationAction" type="uml:TimeObservationAction">
    <xsd:annotation>
      <xsd:documentation>A TimeObservationAction defines an action that observes the current point in time. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DurationInterval">
    <xsd:annotation>
      <xsd:documentation>A DurationInterval defines the range between two Durations. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Interval"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DurationInterval" type="uml:DurationInterval">
    <xsd:annotation>
      <xsd:documentation>A DurationInterval defines the range between two Durations. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Interval">
    <xsd:annotation>
      <xsd:documentation>An Interval defines the range between two value specifications. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ValueSpecification">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="min" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Refers to the ValueSpecification denoting the minimum value of the range.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="max" type="uml:ValueSpecification">
            <xsd:annotation>
              <xsd:documentation>Refers to the ValueSpecification denoting the maximum value of the range.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="min" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Refers to the ValueSpecification denoting the minimum value of the range.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="max" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Refers to the ValueSpecification denoting the maximum value of the range.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Interval" type="uml:Interval">
    <xsd:annotation>
      <xsd:documentation>An Interval defines the range between two value specifications. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TimeConstraint">
    <xsd:annotation>
      <xsd:documentation>A TimeConstraint defines a Constraint that refers to a TimeInterval. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:IntervalConstraint"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TimeConstraint" type="uml:TimeConstraint">
    <xsd:annotation>
      <xsd:documentation>A TimeConstraint defines a Constraint that refers to a TimeInterval. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="IntervalConstraint">
    <xsd:annotation>
      <xsd:documentation>A IntervalConstraint defines a Constraint that refers to an Interval. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Constraint"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="IntervalConstraint" type="uml:IntervalConstraint">
    <xsd:annotation>
      <xsd:documentation>A IntervalConstraint defines a Constraint that refers to an Interval. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="TimeInterval">
    <xsd:annotation>
      <xsd:documentation>A TimeInterval defines the range between two TimeExpressions. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Interval"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TimeInterval" type="uml:TimeInterval">
    <xsd:annotation>
      <xsd:documentation>A TimeInterval defines the range between two TimeExpressions. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DurationObservationAction">
    <xsd:annotation>
      <xsd:documentation>A DurationObservationAction defines an action that observes duration in time. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:WriteStructuralFeatureAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="duration" type="uml:Duration">
            <xsd:annotation>
              <xsd:documentation>represent the measured Duration</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DurationObservationAction" type="uml:DurationObservationAction">
    <xsd:annotation>
      <xsd:documentation>A DurationObservationAction defines an action that observes duration in time. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DurationConstraint">
    <xsd:annotation>
      <xsd:documentation>A DurationConstraint defines a Constraint that refers to a DurationInterval. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:IntervalConstraint"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DurationConstraint" type="uml:DurationConstraint">
    <xsd:annotation>
      <xsd:documentation>A DurationConstraint defines a Constraint that refers to a DurationInterval. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DataStoreNode">
    <xsd:annotation>
      <xsd:documentation>A data store keeps all tokens that enter it, copying them when they are chosen to move downstream. Incoming tokens containing a particular object replace any tokens in the object node containing that object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:CentralBufferNode"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DataStoreNode" type="uml:DataStoreNode">
    <xsd:annotation>
      <xsd:documentation>A data store keeps all tokens that enter it, copying them when they are chosen to move downstream. Incoming tokens containing a particular object replace any tokens in the object node containing that object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="InterruptibleActivityRegion">
    <xsd:annotation>
      <xsd:documentation>An interruptible region contains activity nodes. When a token leaves an interruptible region via edges designated by the region as interrupting edges, all tokens and behaviors in the region are terminated. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:ActivityGroup">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="interruptingEdge" type="uml:ActivityEdge">
            <xsd:annotation>
              <xsd:documentation>.The edges leaving the region that will abort other tokens flowing in the region.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="containedNode" type="uml:ActivityNode"/>
        </xsd:choice>
        <xsd:attribute name="interruptingEdge" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>.The edges leaving the region that will abort other tokens flowing in the region.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="containedNode" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="InterruptibleActivityRegion" type="uml:InterruptibleActivityRegion">
    <xsd:annotation>
      <xsd:documentation>An interruptible region contains activity nodes. When a token leaves an interruptible region via edges designated by the region as interrupting edges, all tokens and behaviors in the region are terminated. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ParameterSet">
    <xsd:annotation>
      <xsd:documentation>An parameter set acts as a complete set of inputs and outputs to a behavior, exclusive of other parameter sets on the behavior. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="parameter" type="uml:Parameter"/>
          <xsd:element name="condition" type="uml:Constraint"/>
        </xsd:choice>
        <xsd:attribute name="parameter" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ParameterSet" type="uml:ParameterSet">
    <xsd:annotation>
      <xsd:documentation>An parameter set acts as a complete set of inputs and outputs to a behavior, exclusive of other parameter sets on the behavior. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Component">
    <xsd:complexContent>
      <xsd:extension base="uml:Class">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="realization" type="uml:Realization"/>
          <xsd:element name="ownedMember" type="uml:PackageableElement"/>
        </xsd:choice>
        <xsd:attribute name="isIndirectlyInstantiated" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>{default = true} The kind of instantiation that applies to a Component. If false, the component is instantiated as an addressable object. If true, the Component is defined at design-time, but at runtime (or execution-time) an object specified by the Component does not exist, that is, the component is instantiated indirectly, through the instantiation of its realizing classifiers or parts. Several standard stereotypes use this meta attribute, e.g. «specification, «focus», «subsystem ».</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Component" type="uml:Component"/>
  <xsd:complexType name="Deployment">
    <xsd:complexContent>
      <xsd:extension base="uml:Dependency">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="deployedArtifact" type="uml:DeployedArtifact"/>
          <xsd:element name="configuration" type="uml:DeploymentSpecification"/>
        </xsd:choice>
        <xsd:attribute name="deployedArtifact" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Deployment" type="uml:Deployment"/>
  <xsd:complexType name="DeployedArtifact">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, DeployedArtifact is an abstract metaclass that is a specialization of NamedElement. A DeployedArtifact is involved in one or more Deployments to a DeploymentTarget. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DeployedArtifact" type="uml:DeployedArtifact">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, DeployedArtifact is an abstract metaclass that is a specialization of NamedElement. A DeployedArtifact is involved in one or more Deployments to a DeploymentTarget. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DeploymentTarget">
    <xsd:annotation>
      <xsd:documentation>A deployment target is the location for a deployed artifact. In the metamodel, DeploymentTarget is an abstract metaclass that is a specialization of NamedElement. A DeploymentTarget owns a set of Deployments. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:NamedElement">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="deployment" type="uml:Deployment"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DeploymentTarget" type="uml:DeploymentTarget">
    <xsd:annotation>
      <xsd:documentation>A deployment target is the location for a deployed artifact. In the metamodel, DeploymentTarget is an abstract metaclass that is a specialization of NamedElement. A DeploymentTarget owns a set of Deployments. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Node">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Node is a subclass of Class. It is associated with a Deployment of an Artifact. It is also associated with a set of Elements that are deployed on it. This is a derived association in that these PackageableElements are involved in a Manifestation of an Artifact that is deployed on the Node. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Class">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="deployment" type="uml:Deployment"/>
          <xsd:element name="nestedNode" type="uml:Node"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Node" type="uml:Node">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a Node is a subclass of Class. It is associated with a Deployment of an Artifact. It is also associated with a set of Elements that are deployed on it. This is a derived association in that these PackageableElements are involved in a Manifestation of an Artifact that is deployed on the Node. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="Device">
    <xsd:annotation>
      <xsd:documentation>A Device is a physical computational resource with processing capability upon which artifacts may be deployed for execution. Devices may be complex, i.e. they may consist of other devices. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Node"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="Device" type="uml:Device">
    <xsd:annotation>
      <xsd:documentation>A Device is a physical computational resource with processing capability upon which artifacts may be deployed for execution. Devices may be complex, i.e. they may consist of other devices. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ExecutionEnvironment">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a ExecutionEnvironment is a subclass of Node. It is usually part of a general Node, representing the physical hardware environment on which the ExecutionEnvironment resides. In that environment, the ExecutionEnvironment implements a standard set of services that Components require at execution time (at the modeling level these services are usually implicit). For each component Deployment, aspects of these services may be determined by properties in a DeploymentSpecification for a particular kind of ExecutionEnvironment. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Node"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ExecutionEnvironment" type="uml:ExecutionEnvironment">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a ExecutionEnvironment is a subclass of Node. It is usually part of a general Node, representing the physical hardware environment on which the ExecutionEnvironment resides. In that environment, the ExecutionEnvironment implements a standard set of services that Components require at execution time (at the modeling level these services are usually implicit). For each component Deployment, aspects of these services may be determined by properties in a DeploymentSpecification for a particular kind of ExecutionEnvironment. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CommunicationPath">
    <xsd:annotation>
      <xsd:documentation>A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages. In the metamodel, CommunicationPath is a subclass of Association. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Association"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CommunicationPath" type="uml:CommunicationPath">
    <xsd:annotation>
      <xsd:documentation>A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages. In the metamodel, CommunicationPath is a subclass of Association. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ProtocolConformance">
    <xsd:complexContent>
      <xsd:extension base="uml:DirectedRelationship">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="generalMachine" type="uml:ProtocolStateMachine">
            <xsd:annotation>
              <xsd:documentation>: Specifies the protocol state machine to which the specific state machine conforms.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="generalMachine" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>: Specifies the protocol state machine to which the specific state machine conforms.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ProtocolConformance" type="uml:ProtocolConformance"/>
  <xsd:complexType name="ProtocolStateMachine">
    <xsd:complexContent>
      <xsd:extension base="uml:StateMachine">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="conformance" type="uml:ProtocolConformance">
            <xsd:annotation>
              <xsd:documentation>: Conformance between protocol state machines.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ProtocolStateMachine" type="uml:ProtocolStateMachine"/>
  <xsd:complexType name="ProtocolTransition">
    <xsd:annotation>
      <xsd:documentation>A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol state machine. The protocol transition specifies that the associated (referred) operation can be called for an instance in the origin state under the initial condition (guard), and that at the end of the transition, the destination state will be reached under the final condition (post). </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Transition">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="postCondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Specifies the post condition of the transition which is the condition that should be obtained once the transition is triggered. This post condition is part of the post condition of the operation connected to the transition.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="preCondition" type="uml:Constraint">
            <xsd:annotation>
              <xsd:documentation>Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation refered by the transition if any.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="preCondition" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation refered by the transition if any.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ProtocolTransition" type="uml:ProtocolTransition">
    <xsd:annotation>
      <xsd:documentation>A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol state machine. The protocol transition specifies that the associated (referred) operation can be called for an instance in the origin state under the initial condition (guard), and that at the end of the transition, the destination state will be reached under the final condition (post). </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadExtentAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) ReadExtentAction is an action that retrieves the current instances of a classifier. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>The runtime instances of the classifier.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="classifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>The classifier whose instances are to be retrieved.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="classifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The classifier whose instances are to be retrieved.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadExtentAction" type="uml:ReadExtentAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) ReadExtentAction is an action that retrieves the current instances of a classifier. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReclassifyObjectAction">
    <xsd:annotation>
      <xsd:documentation>ReclassifyObjectAction adds given classifier to an object and removes given classifiers from that object. Multiple classifiers may be added and removed at a time. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="oldClassifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>A set of classifiers to be removed from the classifiers of the object.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="newClassifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>A set of classifiers to be added to the classifiers of the object.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Holds the object to be reclassified. (Specializes Action.input.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isReplaceAll" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Specifies whether existing classifiers should be removed before adding the new classifiers. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="oldClassifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A set of classifiers to be removed from the classifiers of the object.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="newClassifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A set of classifiers to be added to the classifiers of the object.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReclassifyObjectAction" type="uml:ReclassifyObjectAction">
    <xsd:annotation>
      <xsd:documentation>ReclassifyObjectAction adds given classifier to an object and removes given classifiers from that object. Multiple classifiers may be added and removed at a time. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadIsClassifiedObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action tests the classification of an object against a given class. It can be restricted to testing direct instances. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="classifier" type="uml:Classifier">
            <xsd:annotation>
              <xsd:documentation>The classifier against which the classification of the input object is tested.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>After termination of the action, will hold the result of the test. (Specializes Action.output.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Holds the object whose classification is to be tested. (Specializes Action.input.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="isDirect" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Indicates whether the classifier must directly classify the input object. The default value is false.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="classifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The classifier against which the classification of the input object is tested.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadIsClassifiedObjectAction" type="uml:ReadIsClassifiedObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action tests the classification of an object against a given class. It can be restricted to testing direct instances. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="StartOwnedBehaviorAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) StartOwnedBehaviorAction is an action that starts the owned behavior of the input. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Holds the object on which to start the owned behavior. (Specializes Action.input.)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="StartOwnedBehaviorAction" type="uml:StartOwnedBehaviorAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) StartOwnedBehaviorAction is an action that starts the owned behavior of the input. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="QualifierValue">
    <xsd:annotation>
      <xsd:documentation>A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, as required. This requires more than one piece of data, namely, the end in the user model, the object on the end, and the qualifier values for that end. These pieces are brought together around LinkEndData. Each association end is identified separately with an instance of the LinkEndData class. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Element">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="qualifier" type="uml:Property"/>
          <xsd:element name="value" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>Input pin from which the specified value for the qualifier is taken.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="qualifier" type="xsd:string"/>
        <xsd:attribute name="value" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Input pin from which the specified value for the qualifier is taken.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="QualifierValue" type="uml:QualifierValue">
    <xsd:annotation>
      <xsd:documentation>A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, as required. This requires more than one piece of data, namely, the end in the user model, the object on the end, and the qualifier values for that end. These pieces are brought together around LinkEndData. Each association end is identified separately with an instance of the LinkEndData class. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadLinkObjectEndAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the object on an end of a link object. The association end to retrieve the object from is specified statically, and the link object to read is provided on the input pin at run time. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="object" type="uml:InputPin"/>
          <xsd:element name="end" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>Link end to be read.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin"/>
        </xsd:choice>
        <xsd:attribute name="end" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Link end to be read.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadLinkObjectEndAction" type="uml:ReadLinkObjectEndAction">
    <xsd:annotation>
      <xsd:documentation>This action reads the object on an end of a link object. The association end to retrieve the object from is specified statically, and the link object to read is provided on the input pin at run time. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReadLinkObjectEndQualifierAction">
    <xsd:annotation>
      <xsd:documentation>This action reads a qualifier value or values on an end of a link object. The association end to retrieve the qualifier from is specified statically, and the link object to read is provided on the input pin at run time. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="object" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>(Specialized from Action:input) Gives the input pin from which the link object is obtained.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>Pin where the result value is placed</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="qualifier" type="uml:Property">
            <xsd:annotation>
              <xsd:documentation>The attribute representing the qualifier to be read.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="qualifier" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The attribute representing the qualifier to be read.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReadLinkObjectEndQualifierAction" type="uml:ReadLinkObjectEndQualifierAction">
    <xsd:annotation>
      <xsd:documentation>This action reads a qualifier value or values on an end of a link object. The association end to retrieve the qualifier from is specified statically, and the link object to read is provided on the input pin at run time. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="CreateLinkObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action is exclusively for creating links of association classes. It returns the created link object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:CreateLinkAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="result" type="uml:OutputPin"/>
        </xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CreateLinkObjectAction" type="uml:CreateLinkObjectAction">
    <xsd:annotation>
      <xsd:documentation>This action is exclusively for creating links of association classes. It returns the created link object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="AcceptEventAction">
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="trigger" type="uml:Trigger">
            <xsd:annotation>
              <xsd:documentation>The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="result" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>Pin holding the event object that has been received. Event objects may be copied in transmission, so identity might not be preserved.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="trigger" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="result" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Pin holding the event object that has been received. Event objects may be copied in transmission, so identity might not be preserved.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AcceptEventAction" type="uml:AcceptEventAction"/>
  <xsd:complexType name="AcceptCallAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) AcceptCallAction is an accept event action representing the receipt of a synchronous call request. In addition to the normal operation parameters, the action produces a output token that is needed later to supply the information to the ReplyAction necessary to return control to the caller. This action is for synchronous calls. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:AcceptEventAction">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="returnInformation" type="uml:OutputPin">
            <xsd:annotation>
              <xsd:documentation>Pin where a token is placed containing sufficient information to perform a subsequent reply and return control to the caller. The value in this token is opaque. It can be passed and copied but it cannot be manipulated by the model.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="returnInformation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>Pin where a token is placed containing sufficient information to perform a subsequent reply and return control to the caller. The value in this token is opaque. It can be passed and copied but it cannot be manipulated by the model.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="AcceptCallAction" type="uml:AcceptCallAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) AcceptCallAction is an accept event action representing the receipt of a synchronous call request. In addition to the normal operation parameters, the action produces a output token that is needed later to supply the information to the ReplyAction necessary to return control to the caller. This action is for synchronous calls. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="ReplyAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) ReplyAction is an action that accepts a set of return values and a token containing return information produced by a previous accept call action. The reply action returns the values to the caller of the previous call, completing execution of the call. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="replyToCall" type="uml:CallTrigger">
            <xsd:annotation>
              <xsd:documentation>The operation call trigger being replied to.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="replyValue" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>A list of pins containing the reply values of the operation. These values are returned to the caller.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="returnInformation" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>A pin containing the return information token produced by an earlier AcceptCallAction.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="replyToCall" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>The operation call trigger being replied to.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="replyValue" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A list of pins containing the reply values of the operation. These values are returned to the caller.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="returnInformation" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A pin containing the return information token produced by an earlier AcceptCallAction.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="ReplyAction" type="uml:ReplyAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) ReplyAction is an action that accepts a set of return values and a token containing return information produced by a previous accept call action. The reply action returns the values to the caller of the previous call, completing execution of the call. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="RaiseExceptionAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) RaiseExceptionAction is an action that causes an exception to occur. The input value becomes the exception object. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Action">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element name="exception" type="uml:InputPin">
            <xsd:annotation>
              <xsd:documentation>An input pin whose value becomes an exception object.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
        <xsd:attribute name="exception" type="xsd:string">
          <xsd:annotation>
            <xsd:documentation>An input pin whose value becomes an exception object.</xsd:documentation>
          </xsd:annotation>
        </xsd:attribute>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="RaiseExceptionAction" type="uml:RaiseExceptionAction">
    <xsd:annotation>
      <xsd:documentation>(CompleteActions) RaiseExceptionAction is an action that causes an exception to occur. The input value becomes the exception object. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="DeploymentSpecification">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a DeploymentSpecification is a subtype of Artifact. It defines a set of deployment properties that are specific to a certain Container type. An instance of a DeploymentSpecification with specific values for these properties may be contained in a complex Artifact. </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="uml:Artifact">
        <xsd:attribute name="deploymentLocation" type="xsd:string"/>
        <xsd:attribute name="executionLocation" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="DeploymentSpecification" type="uml:DeploymentSpecification">
    <xsd:annotation>
      <xsd:documentation>In the metamodel, a DeploymentSpecification is a subtype of Artifact. It defines a set of deployment properties that are specific to a certain Container type. An instance of a DeploymentSpecification with specific values for these properties may be contained in a complex Artifact. </xsd:documentation>
    </xsd:annotation>
  </xsd:element>
</xsd:schema>