Issues for UML 2.2 Superstructure and Infrastructure Revision Task Force

To comment on any of these issues, send email to uml2-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3898: Specify XMI parameters for the UML / XMI interchange format
Issue 4110: Semantics of firing compound transitions still appears to be circular
Issue 4448: Does visibility apply to creating an destroying links?
Issue 4932: Starting state machine
Issue 4937: Sending a signal after a delay
Issue 5107: Starting a state machine
Issue 5593: Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )
Issue 5794: Designates a Generalization
Issue 5804: 2.5.2.27 ModelElement
Issue 5886: behaviour of the shallow history state and deep history state
Issue 5896: logic upperbound is the same as the lower bound.
Issue 5907: formal/03-03-01 : Omission of definition of Class "Action"
Issue 5977: saying {nonunique} on one end of a binary association is meaningless
Issue 6002: relationship should just be a cross-reference
Issue 6003: document appears to be inconsistent in how it handles concepts
Issue 6004: Relationship and DirectedRelationship in Core::Constructs
Issue 6005: cross-reference missing
Issue 6006: Classes diagram of the Core::Constructs package
Issue 6071: Conditional Node and Loop Node notation missing
Issue 6082: Suspension Region
Issue 6083: More examples
Issue 6086: More explanation needed on Figure 339
Issue 6088: Parameterization of lifelines
Issue 6111: Reentrancy 1
Issue 6114: State extension
Issue 6126: Target pin notation
Issue 6137: Promote local conditions to ExecutableNode
Issue 6150: Notation for method
Issue 6176: UML 2 Super/Metamodel::Constructs/owningComment
Issue 6187: UML 2 Super/Metamodel::Super/missing merge
Issue 6194: UML 2 Super/Package merge/redefinitions issue - lost association ends
Issue 6197: UML 2 Super/Metamodel::Kernel/missing merges
Issue 6200: UML 2 Super/Metamodel/redefinition and substitutability
Issue 6201: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"
Issue 6216: UML 2 Super/pg.75/kinds of changeability
Issue 6262: UML 2 Super / Templates / TemplateParameter not named
Issue 6275: raisedException
Issue 6346: Activity OCL
Issue 6353: Deployment a dependency?
Issue 6368: Join nodes that destroy tokens
Issue 6372: Notes versus curly braces
Issue 6389: Syntax of names
Issue 6395: UML 2 Super / State machines / Transition triggers cannot be redefined
Issue 6398: UML 2 Super / Kernel features / cannot exclude superclass properties
Issue 6405: UML 2 super / Dependencies / improper subsetting?
Issue 6409: UML 2 Super/Interactions/missing OCL constraints
Issue 6422: Section 9.3.3
Issue 6423: Section 9.3.4 page 161, Presentation Option
Issue 6430: UML2 super/ad-03-04-01/Derived attributes and associations
Issue 6433: 03-04-01 Chap 2 p. 112/Components: Different ways to wire components
Issue 6441: Integration between behavioral "sublanguages": Interactions and Activities
Issue 6444: Activity diagram problems
Issue 6445: Clarification of use case semantics
Issue 6446: Clarification of Information Flow semantics
Issue 6451: UML 2 Super / Dependency / ownership of dependencies
Issue 6452: UML 2 Super / Missing OCL constraints
Issue 6455: instantiations of Classifiers
Issue 6456: Use 'represent' for the relationship of a model
Issue 6460: UML 2 Issue: definition of navigability
Issue 6462: UML 2 Issue: AssociationEnd
Issue 6463: UML 2 Issue: Message notation
Issue 6464: UML 2 Issue: isUnique
Issue 6466: UML 2 Issue: Qualified pathnames
Issue 6470: Section 7.11.2 Association
Issue 6487: Conditions for parameter sets
Issue 6489: Ports in Protocol State Machines
Issue 6492: ptc-03-09-15/Non-navigable ends with no role names nor multiplicities
Issue 6493: ptc-03-09-15/Constructs::Class superClass property
Issue 6495: ptc-03-09-15/Separate classification and generalization in Core::Basic
Issue 6496: ptc-03-09-15/Relationships among Core packages
Issue 6497: ptc-03-09-15/Need for examples to include instance models
Issue 6498: ptc-03-09-15/Explain the new association modeling constructs
Issue 6500: Federated models - UML2 issue
Issue 6501: Rose Model of UML 2.0 spec
Issue 6502: Multiplicity seems to be broken - UML2 Infra & Super
Issue 6503: Why not using the UML1 activity symbol for UML2 actions?
Issue 6524: class "InfrastructureLibrary.core.constructs.Association",
Issue 6525: two classes "NamedElement
Issue 6616: UML Superstructure FTF : isRoot property disappeared
Issue 6624: freeing namespace
Issue 6630: UML 2 Super / Classes / dependencies should be unidirectional
Issue 6637: UML 2 Infra/Metamodel/missing derivation indicators
Issue 6639: remove paragraph
Issue 6640: number of the figure is wrong
Issue 6641: well-formedness rules are not numbered correctly
Issue 6645: UML 2.0 Superstructure Kernal/Packages
Issue 6659: multiplicity of the association named "type" of type DataType
Issue 6660: The multiplicity of association named subaction of type Action ill formed
Issue 6661: In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11
Issue 6662: In the last paragraph, the period after the word "collections" on the secon
Issue 6665: UML 1.5 table of contents
Issue 6681: UML2 Super/Kernel Classes
Issue 6692: Operations and derived attributes
Issue 6696: Remove one of the dots between protectedAction and availableOutput
Issue 6697: Associations section of element JumpHandler
Issue 6699: UML 2.0 infra and super Constraints Diagram of the Kernel
Issue 6700: UML 2.0 Kernel Operations Diagram and Features Diagram and mdl
Issue 6702: The numbering of the sub-sections in 2.7.2 is wrong
Issue 6703: In "2.9.3.5 Instance", numbering of different well-formedness rules wrong
Issue 6704: The section about Procedure does not contain any well-formedness rules
Issue 6724: The Composition section does not follow the usual conventions
Issue 6725: missing closing parenthesis
Issue 6726: At the bottom of the page, the characters "antics." should be removed
Issue 6727: In 2.13.3, the first sub-section about ActivityGraph is not numbered
Issue 6866: Part subtype
Issue 6878: UML 2 Infrastructure / rule for redefinition of Property
Issue 6921: Inheritance of 'Enumerations' is not detailed
Issue 6922: Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R
Issue 6923: Class InfrastructureLibrary::Core::Basic::Property
Issue 6927: UML 2 Super / Interactions / Ambiguous diagram tags
Issue 6975: missing illustrations of graphical paths for create and destroy messages
Issue 6989: UML 2 Super/Interactions/Constraints for create messages
Issue 6990: manage simultaneity of events
Issue 6991: transtion
Issue 7051: StateMachine - Constraints
Issue 7105: In normative XMI file for the metamodel, no Associations have a name.
Issue 7161: UML 2 Super/Interactions/Need constraints that cover multiple Lifelines
Issue 7166: show object flow or interactions
Issue 7223: Questions about DataTypes and generalization
Issue 7227: UML2 Super/Deployment/inheritance
Issue 7229: UML2 Super/Deployments/Manifestation
Issue 7246: Figure 78
Issue 7247: Connector - "provided Port" and "required Port" not defined Constraint 1
Issue 7248: Connector - inconsistencies in Constraint [2]
Issue 7249: Connector - inconsistencies in Constraint[3]
Issue 7250: Connector - inconsistencies in Constraint[4]
Issue 7251: Connector - inconsistencies in Constraint[5]
Issue 7254: completion transitions
Issue 7255: Priority of the joint transition
Issue 7274: UML2 Infra/11.5.1/Invalid reference to Attribute class
Issue 7303: simple time model" in CommonBehavior
Issue 7304: Notation sections for TimeObservation and DurationObservation
Issue 7329: large overlap between structural features and variables
Issue 7337: inconsistency in the action model
Issue 7338: metaattribute isReadOnly
Issue 7339: Property defines an association "datatype" which is redundant
Issue 7343: Section 11.7
Issue 7362: Clarify example in figure 133
Issue 7364: section on connectors in the component chapter
Issue 7372: surface notation for state machines
Issue 7375: useless example on p.330, Figure 247
Issue 7392: Interactions model sequences of events
Issue 7397: add an interaction fragment
Issue 7398: Provide exception handling for all behaviors.
Issue 7400: AssociationClass
Issue 7401: XMI schema
Issue 7406: TimeObservationAction and DurationObservationAction
Issue 7407: The specification is fond of using 'typically.'
Issue 7620: Coupling between StateMachines and Activities
Issue 7756: Unconsistent association extension description
Issue 7757: Unconsistent Profile extension description (02)
Issue 7782: Move Comment into Basic and add Kind
Issue 7783: Missing XMI tags in spec and XMI rendition of metamodel
Issue 7889: Inconsistent use of 'Element' between MOF and UML
Issue 7908: Design principles
Issue 7909: Problem with diagram references in Profiles section
Issue 7910: isComposite inconsistency in UML 2.0 and MOF 2.0
Issue 7938: DataType attributes UML 2 Super (ptc/04-10-02)
Issue 7939: DataType attributes UML 2 Super (ptc/04-10-02)
Issue 7942: Section: 7.3.43
Issue 7946: Section: 7.2.8
Issue 7947: Classes
Issue 7948: section 2.10.4.1 detailed semantics of collaborations
Issue 7949: Section: 7.3.44 - OCL incorrect
Issue 7950: Interactions
Issue 7951: UML 2 Super Basic Interactions
Issue 7952: Alternative entry and exit point notation is ambiguous
Issue 7956: InfrastructureLibrary defines, but should not use package merge
Issue 7958: should retain Comment and its associations to Element
Issue 7967: An observed time value must be written into a structural feature
Issue 7969: Section: 9.14.1
Issue 7970: Minor error in BNF of an message argument
Issue 7973: UML 2 Super / Incorrect statement on port visibility
Issue 7977: ReduceAction
Issue 7986: Section: 14.3.7
Issue 7987: Section: 14.3.13
Issue 7988: Section: 14.3.14
Issue 7989: Section: 14.3.16
Issue 7990: Section: Table 14
Issue 7993: Use case extension inconsistencies
Issue 7994: Presentation Options
Issue 7995: StateInvariants/Continuations
Issue 7996: Add concept "StateInvariant"
Issue 7997: Too much navigability from Generalizations
Issue 8012: Section: Classes, Behavior
Issue 8014: Disjointness should be independent of generalization
Issue 8015: Transitivity in composition
Issue 8016: Action for retrieving activity instance
Issue 8017: Pin/parameter matching constraints
Issue 8018: Section: CB/ACT
Issue 8019: Section: Classes
Issue 8020: constrainedElement direction
Issue 8021: Section: Classes
Issue 8022: Derived union notation
Issue 8023: Association specialization semantics
Issue 8024: End objects of a link In the semantics of AssociationClass
Issue 8025: Associations between interfaces
Issue 8026: Contextualized attribute values Figures 121
Issue 8027: Connector multiplicity notation
Issue 8028: create dependency Figures 103 and 121
Issue 8029: underlined association name
Issue 8030: Interactions chapter refers to ActivityInvocations
Issue 8031: Destruction semantics in StructuredClassifier
Issue 8032: Link maintenance in StructuredClassifier
Issue 8033: Figure 119 missing multiplicity
Issue 8034: Notation for classifierBehavior
Issue 8035: Notation for method
Issue 8036: Preserve order in result of read actions
Issue 8037: Optional inputs
Issue 8038: IsReadOnly constriant
Issue 8039: DestroyObjectAction semantics
Issue 8040: ObjectNode, constraint 1 In ObjectNode
Issue 8041: StructuredActivityNode specialized multiplicity
Issue 8042: Terminology Issue
Issue 8062: section 9.20.2 VisibilityKind lists two types of visibility
Issue 8063: Text references Figure 8 and the correct figure number is 6
Issue 8064: unclear statement
Issue 8065: extra word in the last sentence of the paragraph under Attributes
Issue 8066: clarify what a directed association is
Issue 8067: Section is badly worded and does not make a lot of sense
Issue 8068: typing error in the statement :unrestricted ?
Issue 8069: What happened to real numbers
Issue 8070: methods not defined under attributes
Issue 8071: ClassifierInState not supported in UML2.0 ?
Issue 8072: Figure 68
Issue 8073: Section: 11.3.1
Issue 8074: Section: 11.3.3
Issue 8075: search for referenced item -- Section: 11.3.4
Issue 8076: Section: 11.5
Issue 8077: Properties on Association for end objects
Issue 8078: Actor is a specialized Classifier and not BehavioredClassifier
Issue 8079: Section: 11.6.1
Issue 8080: Section: 11.8.3
Issue 8081: Section: 13.1.2
Issue 8082: Section: 13.1.5
Issue 8083: Section: 7.3.3
Issue 8084: Section: 7.3.6
Issue 8085: Section: 7.4.1
Issue 8086: Section: 6.5.1: Error in example
Issue 8087: All sections
Issue 8088: Section: 7.3.3
Issue 8089: Section: 7.3.8
Issue 8090: Section: 7.3.10
Issue 8091: Section: 7.3.12
Issue 8092: Section: 7.3.15
Issue 8093: Section: 7.3.20
Issue 8094: Stereotypes applying in UML 2.0
Issue 8095: Section: 7.3.22
Issue 8096: Section: 7.3.32
Issue 8097: Section: 7.3.32 Page: 96-99
Issue 8098: Section: 7.3.33
Issue 8099: Section: 7.3.34
Issue 8100: Section: 7.3.35
Issue 8101: Clarify the differences between redefining element and redefined element.
Issue 8102: Multiple typos in ptc/04-10-02
Issue 8103: Section: 8.3.1
Issue 8104: Section: 8.3.1 - typo
Issue 8105: Section: 8.3.1
Issue 8106: Section: 8.3.2
Issue 8107: Section: 9.20.2
Issue 8108: Section: 9.3.1
Issue 8109: Section: 9.3.2
Issue 8110: Section: 9.3.3
Issue 8111: Section: 9.3.4
Issue 8112: Section: 9.3.5
Issue 8113: Section: 9.3.6
Issue 8114: Section: 9.3.7
Issue 8115: Section: 9.3.9
Issue 8116: Section: 9.3.9
Issue 8117: Section: 9.3.10
Issue 8118: Section: 8.3.2
Issue 8119: Section: 8.3.2
Issue 8120: Section: 8.3.4
Issue 8126: Section: 9.3.11
Issue 8127: Section: 9.3.12
Issue 8128: Section: 9.3.13
Issue 8129: Section: 12.3.13
Issue 8130: Section: 12.3.13
Issue 8131: Section: 9.2
Issue 8132: Section: 10.3.1
Issue 8133: Section: 10.3.1
Issue 8134: Section: 10.3.3
Issue 8135: Section: 10.3.4
Issue 8136: Section: 10.3.5
Issue 8137: Section: 10.3.6
Issue 8138: Section: 10.3.8
Issue 8139: Section: 10.3.9
Issue 8140: Section: 10.3.10
Issue 8141: Section: 10.3.11
Issue 8142: Section: 10.3.11
Issue 8143: Section: 10.4
Issue 8144: Section: 11.1
Issue 8145: Section: 11.3.1
Issue 8146: Section: 11.3.2
Issue 8147: Section: 11.3.3
Issue 8148: Section: 11.3.4
Issue 8149: Section: 11.3.5
Issue 8150: Section: 11.3.6
Issue 8151: Section: 11.3.7
Issue 8152: Section: 11.3.8
Issue 8153: Section: 11.3.9
Issue 8154: Section: 11.3.10
Issue 8155: Section: 11.3.11
Issue 8156: Section: 11.3.12
Issue 8157: Section: 11.3.13
Issue 8158: Section: 11.3.14
Issue 8159: Section: 11.3.15
Issue 8160: Section: 11.3.16
Issue 8161: Section: 11.3.17
Issue 8162: Section: 11.3.18
Issue 8163: Section: 11.3.19
Issue 8164: Section: 11.3.20
Issue 8165: Section: 11.3.21
Issue 8166: Section: 11.3.22 -- significant revision?
Issue 8167: Section: 11.3.23 -- significant revision?
Issue 8168: Figure 89 on page 158 is incorrect
Issue 8169: Section: 11.3.24
Issue 8170: Section: 11.3.25
Issue 8171: Section: 11.3.26
Issue 8172: Section: 11.3.27
Issue 8173: Section: 11.3.28
Issue 8174: Section: 11.3.29
Issue 8175: Section: 11.3.30
Issue 8176: Section: 11.3.31
Issue 8177: Section: 11.3.33
Issue 8178: Section: 11.3.34
Issue 8180: Section: 11.3.35
Issue 8181: Section: 11.3.36
Issue 8182: Section: 11.3.27
Issue 8183: Section: 11.3.38
Issue 8185: Section: 11.3.40
Issue 8186: Section: 11.3.41
Issue 8187: Section: 11.3.43
Issue 8188: Section: 11.3.44
Issue 8189: Section: 11.3.45
Issue 8190: Section: 11.3.46
Issue 8191: Section: 11.3.47
Issue 8192: Section: 11.3.48
Issue 8193: Section: 11.3.49
Issue 8194: Section: 11.3.50
Issue 8195: Section: 11.3.51
Issue 8196: Section: 11.3.52
Issue 8197: Section: 11.3.42
Issue 8198: Section: 11.3.53
Issue 8199: Section: 11.3.54
Issue 8202: Section: 12.1
Issue 8203: Property string {bag} is redundant
Issue 8204: {redefined <end-name>} should be named {redefines <end-name>}
Issue 8206: Section: 12.2
Issue 8207: Section: 12.3.2
Issue 8208: Section: 12.3.4
Issue 8209: Section: 12.3.4
Issue 8210: Section: 12.3.5
Issue 8213: Section: 12.3.6
Issue 8214: Section: 12.3.7
Issue 8215: Section: 12.3.8
Issue 8216: Section: 12.1
Issue 8217: Section: 12.3.9
Issue 8218: Section: 12
Issue 8219: Section: 12.3.9
Issue 8220: Section: 12
Issue 8222: Section: 12.3.10
Issue 8223: Section: 12.3.12
Issue 8224: Section: 12.1
Issue 8225: Section: 12.3.13
Issue 8226: MultiplicityElement BNF too restrictive
Issue 8227: Incomplete BNF for Property
Issue 8228: BNF Notation for Operation is too restrictive
Issue 8229: Used of "Redefines ...from Abstractions" in descriptions is misleading
Issue 8231: Section: 12.3.14
Issue 8232: Section: 12.3.15
Issue 8233: Section: 12.3.16
Issue 8234: Section: 12.3.17
Issue 8235: Section: 12.3.18
Issue 8236: Section: 12.3.19
Issue 8237: Section: 12.3.6 & 12.3.19
Issue 8238: Section: 12.3.22
Issue 8239: Section: 12.3.24
Issue 8240: Section: 12.3.23
Issue 8241: Section: 12.3.27
Issue 8242: Section: 12.3.28
Issue 8243: Section: 12.3.30
Issue 8245: Section: 12.3.38
Issue 8246: namespace
Issue 8247: Section: 12.3.31
Issue 8248: Section: 12.3.32
Issue 8249: Section: 12.3.33
Issue 8250: Section: 12.3.33
Issue 8252: Section: 12.3.34
Issue 8253: Section: 12.3.35
Issue 8254: Section: 12.3
Issue 8255: Section: 12.3.35
Issue 8256: Profiles:Extension End
Issue 8257: Section: 12.3.37
Issue 8258: Section: 12.3.38
Issue 8260: Section: 12.3.40
Issue 8261: Section: 12.3.41
Issue 8262: Section: 12.3.43
Issue 8263: Section: 12.3.44
Issue 8264: UML 2 Super/templates/inexplicable constraint on defaults
Issue 8265: UML 2 super/templates/
Issue 8270: Section: 12.3.47
Issue 8271: Section: 12.2
Issue 8272: Section: 12.3.48
Issue 8273: Section: 11.3.48
Issue 8274: UML2/Infra section 11.6.2/ Enumerations should not have attributes
Issue 8275: Section: 12.3.50
Issue 8276: Section: 12.3.51
Issue 8277: Section: 12.3.52
Issue 8278: section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification
Issue 8279: Section: 12.4
Issue 8280: Section: 12
Issue 8292: Section: 13.1
Issue 8293: Section: 12.3.46
Issue 8294: Section: 12.3.49
Issue 8295: Section: 13.3.2
Issue 8297: Section: 13.3.3
Issue 8298: Section: 7.3.36
Issue 8301: Section: 13.3.4
Issue 8302: Section: 13.3.7
Issue 8303: Section: 13.3.8
Issue 8304: Section: 13.3.10
Issue 8305: Section: 13.3.9
Issue 8306: Section: 13.3.11
Issue 8307: Section: 13.3.12
Issue 8308: Section: 13.3.14
Issue 8309: Section: 13.3.15
Issue 8310: Section: 13.3.17
Issue 8311: Section: 13.3.19
Issue 8312: Section: 13.3.20
Issue 8313: Section: 13.3.22
Issue 8314: Section: 13.3.23
Issue 8315: Section: 13.3.24
Issue 8316: Section: 13.3.26
Issue 8317: Section: 13.3.27
Issue 8318: Section: 13.3.28
Issue 8319: Section: 13.3.29
Issue 8320: Section: 13.3.30
Issue 8322: Section: 13
Issue 8323: Section: 14.3.2
Issue 8324: Section: 14.3.3
Issue 8325: Section: 14.3.4
Issue 8326: Section: 14.3.5
Issue 8327: Section: 14.3.6
Issue 8328: Section: 14.3.8
Issue 8329: Section: 14.3.10
Issue 8330: Section: 14.3.3 & 14.3.11
Issue 8331: Section: 14.3.12
Issue 8332: inconsistent description
Issue 8335: ReadStructuralFeatureAction
Issue 8336: RemoveStructuralFeatureValueAction specification
Issue 8337: Section: 14.3.14
Issue 8338: Section: 14.3.13
Issue 8339: Section: 14.3.15
Issue 8340: Section: 14.3.16
Issue 8341: Section: 14.3.17
Issue 8342: Section: 14.3.18
Issue 8343: Section: 14.3.19
Issue 8345: Section: 14.3.20
Issue 8346: Section: 14.3.21
Issue 8347: Section: 14.3.21
Issue 8348: Section: 14.3.24
Issue 8349: Section: 14.3.25
Issue 8350: Section: 14.3.26
Issue 8351: Section: 14.3.29
Issue 8352: Section: 14.4
Issue 8353: Section: 14
Issue 8356: Section: 11.3.5
Issue 8357: Section: 12.3.4
Issue 8385: UML 2 Super / Components / realizingClassifier
Issue 8386: Section: 8.3.4
Issue 8387: Section: 8.3.1
Issue 8401: Section: 15.3.1
Issue 8402: Section: 15.3.2
Issue 8403: Section: 15.3.3
Issue 8404: Section: 15.3.5
Issue 8405: Section: 15.3.5
Issue 8406: Section: 11.3.42
Issue 8407: Section: 15.3.6
Issue 8408: Section: 15.3.7
Issue 8409: Section: 15.3.8
Issue 8410: Section: 15.3.9
Issue 8411: Section: 15.3.10
Issue 8412: Specification: Action Semantics Section: 9.5
Issue 8413: Action Semantics Section: 9.5
Issue 8414: Section: 14
Issue 8415: Section: 15.3.11
Issue 8416: Section: 15.3.11
Issue 8433: Section: 15.3.12
Issue 8439: Appendix C.1
Issue 8440: Section: Appendix A
Issue 8443: Section: 15.3.14
Issue 8444: Section: 15.3.15
Issue 8445: Section: 15.3.16
Issue 8446: Section: 15.3.7
Issue 8447: Section 15
Issue 8449: Should Profiles::Image be an Element?
Issue 8450: Default values for ValueSpecification are not specified properly
Issue 8451: OCL for Property::opposite() is incorrect:
Issue 8452: Remove redundant superclass for Element
Issue 8453: Profiles::ExtensionEnd has wrong default multiplicity
Issue 8454: Profiles::ObjectNode has wrong default multiplicity
Issue 8455: Profiles::ObjectNode has wrong default multiplicity
Issue 8456: UML 2 Super / Collaborations / improper subset
Issue 8457: UML 2 Super / General / improper subsetting
Issue 8458: UML 2 Super / General / missing merges
Issue 8459: UML 2 Super / Conformance / inconsistencies
Issue 8460: UML 2 Super / Kernel / invalid restriction in isConsistentWith()
Issue 8461: UML 2 Super / Kernel / excessive restriction on redefinition
Issue 8462: UML 2 Super / General / invalid subset rule too strict
Issue 8463: UML 2 Super / Common Behaviors / missing multiplicites
Issue 8464: Section: 16.3.1
Issue 8465: Section: 16.3.3
Issue 8466: Section: 16.3.4
Issue 8467: Section: 16.3.5
Issue 8468: Section: 16.3.6
Issue 8469: Section: 14.3.3
Issue 8470: Section: Actions
Issue 8471: Decision node
Issue 8472: Section: Activities
Issue 8473: Activities section
Issue 8474: Section: Classes
Issue 8475: Section: Interactions
Issue 8476: Section: Common Behavior
Issue 8477: Section: Actions
Issue 8478: ValueSpecificationAction, Attribute section, is missing the return pin
Issue 8479: Section: Activities - clarification
Issue 8480: Section: Activities : Why is exception type needed?
Issue 8481: Section: Activities
Issue 8482: Section: Activities, ExpansionRegion
Issue 8483: Section: Activities, ExpansionRegion (02)
Issue 8484: Section: Activities, ExpansionRegion (03)
Issue 8485: Section: Activities, ExpansionRegion (04)
Issue 8486: Section: Activities, ExpansionRegion (05)
Issue 8487: ExpansionRegioin example, Figure 261: concurrent => parallel
Issue 8488: Expansion region description
Issue 8489: ExpansionRegion (behavior in the shorthand notation)
Issue 8490: Section: Activities
Issue 8491: Add constraint in LoopNode
Issue 8492: Section: Activities, LoopNode
Issue 8493: Semantics of isAssured/isDeterminant in conditional node
Issue 8494: Add constraints on conditional, loop, sequence to rule out node contents
Issue 8495: Add constraints on ConditionalNode
Issue 8496: Add constraints on conditional and loop nodes
Issue 8497: Add constraints on conditional and loop nodes (02)
Issue 8498: Constrain conditional node to have body pins if there is a result pin.
Issue 8499: No notation
Issue 8500: mustIsolate:
Issue 8501: SequenceNode should have way to set output pins in CompleteStructured
Issue 8502: Figure 209 of Activites
Issue 8503: Clarify the semantics of minimum multiplicity > 0 for streaming parameters
Issue 8506: Section: 17.2.1
Issue 8507: Section: 17.2.2
Issue 8508: Section: 17.3.1
Issue 8509: Section: 17.4
Issue 8510: Section: 17.5.1
Issue 8511: Section: 17.5.2
Issue 8512: Section: 17.5.1
Issue 8513: Section: 17.5.3
Issue 8514: Section: 17.5.3
Issue 8515: Section: 17.5.4
Issue 8516: Section: 17.5.5
Issue 8517: Section: 17.5.6
Issue 8518: Section: 17.1
Issue 8527: Section: 17.5.7
Issue 8528: Section: 17.5.8
Issue 8529: Section: 17.5.12
Issue 8530: Section: 17.5.13
Issue 8544: Section: 12 Activities
Issue 8587: Section: 17.5.14
Issue 8588: Section: 17.5.15
Issue 8589: Section: 17.5.16
Issue 8590: Section: 17.5.17
Issue 8591: Section: 17.5.18
Issue 8592: Section: 17.5.19
Issue 8593: Section: 17.5.20
Issue 8594: Section: 17
Issue 8595: Section: 18.1.2
Issue 8596: Section: 18.3.2
Issue 8598: Section: 18.2
Issue 8599: Section: 18.3.2
Issue 8600: Section: 18.3.3
Issue 8601: Section: 18.3.6
Issue 8602: Section: 18.3.7
Issue 8603: Section: 18.3.8
Issue 8604: Section: 18.4
Issue 8605: Section: 18
Issue 8606: Section: Appendix B
Issue 8607: Section: Appendix B (02)
Issue 8608: Section: Appendix C Table 25
Issue 8609: Section: Appendix C Table 26
Issue 8610: Section: Appendix C Table 27
Issue 8611: Section: 15.3.8
Issue 8612: Section: 15.3.8 (second issue)
Issue 8613: Section: D.1
Issue 8614: Section: D.2
Issue 8615: Section: D.3
Issue 8616: Section: D.4
Issue 8617: Section: E.1
Issue 8619: Section: Appendix F
Issue 8668: UML 2 Super / Activities / missing subsets
Issue 8670: Section: 12
Issue 8671: Section 12 (02)
Issue 8672: Section 12 (03)
Issue 8673: Figure 179 (Control nodes)
Issue 8674: text p.297
Issue 8675: Output tokens
Issue 8676: output tokens (02)
Issue 8677: token movement
Issue 8678: UML 2 -- Need explanations of XMI structure and usage
Issue 8679: token
Issue 8680: Section: 12
Issue 8681: add the rule of ``natural termination''
Issue 8682: A test cannot be empty
Issue 8683: ``conditional node or conditional node'' delete one.
Issue 8684: Add a Constraint
Issue 8685: Delete sentence
Issue 8686: reword sentence
Issue 8687: rewording isuse?
Issue 8688: UML 2 Different constraints for Property in Super and Infra
Issue 8689: editorial in section 12
Issue 8690: Section: 12.2
Issue 8692: Section: 7.3.36
Issue 8693: Section: 10.3.1
Issue 8695: Key Qualifiers Missing in MOF
Issue 8696: policy to describe the Associations sub section of a meta class description
Issue 8698: CombinedFragment Loop notation
Issue 8699: UML2-rtf issue: communication diagram
Issue 8700: Meaning of relationship between iteration clause and Lifeline.selector clau
Issue 8702: Section: Actions
Issue 8705: Section: 8.3.1
Issue 8706: Profile Semantics, pag 723
Issue 8718: In Activities, Figure 176, Action should be abstract
Issue 8719: Semantics for instances applies to InstanceSpecification?
Issue 8720: String is primitive but has structure.
Issue 8721: Client/supplier on dependencies
Issue 8722: Misleading statement about multiplicity in AssociationClass
Issue 8723: Disjointness should be independent of generalization
Issue 8724: DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode
Issue 8725: Clarify multiple inputs to expansion regions
Issue 8726: Element to Constraint navigation
Issue 8727: The create stereotype on Usage dependency
Issue 8728: Solid triange notation for Association
Issue 8729: Multiple exception handlers
Issue 8730: Exceptions thrown across synchronous invocations
Issue 8731: Activities
Issue 8732: In Figure 210, put merge before Use Part to merge the incoming flows
Issue 8733: LoopNode should move rather than copy values to/from loop variables
Issue 8734: Clarify first constraint on InputPin and OutputPin, move "only" to before "
Issue 8735: The Syle Guidelines for Stereotype
Issue 8736: Actions, CallBehaviorAction, third sentence,
Issue 8737: ControlFlow
Issue 8738: StructuredActivityNode, Semantics, third paragraph, first sentence,
Issue 8739: ExpansionRegion
Issue 8740: ConditionalNode and LoopNode test and bodies should be ExecutableNodes
Issue 8741: In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec
Issue 8742: represents and occurrence keywords are switched
Issue 8743: Clarify which classifier or operation this is referring to
Issue 8744: CollaborationUse: Constraint 1,
Issue 8745: Section: Interactions
Issue 8746: Clarify caption of Figure 56
Issue 8747: Notation for connector end multiplicities.
Issue 8748: Operation calls on behavior ports
Issue 8749: ParameterSet, first line: "inputs *or* outputs".
Issue 8750: External exceptions.
Issue 8752: Last element in transition BNF
Issue 8753: Page: 591
Issue 8756: Section: Classes
Issue 8757: 1. Deployment
Issue 8758: Association in UseCase diagram
Issue 8759: OpaqueAction
Issue 8760: Events in Sequence diagram
Issue 8761: Arguments of Message
Issue 8763: Nested Nodes
Issue 8764: Section: 14.3.3
Issue 8765: Section: 14.3.3 Page: 508+
Issue 8766: Section: 12.3.37
Issue 8768: Section: Classes
Issue 8769: Can't specify mutator semantics for derived properties
Issue 8770: Section: Actions
Issue 8771: Section: Action/Activity
Issue 8772: Section: 11.3.48
Issue 8773: Page: 330
Issue 8774: Notation of Attributes and Associations subsections
Issue 8776: Section: 9.3.7
Issue 8777: Section: 8.3.1
Issue 8778: Section: 8.3.1 Page: 156 ff
Issue 8779: ConditionalNode inputs used by more than one test
Issue 8780: Input tokens to LoopNodes should be destroyed when the loop is done
Issue 8781: Actions should be able to overlap partitions, to support multiple participa
Issue 8782: ExecutableNode should be abstract in Figure 195. It is in Figure 197.
Issue 8784: MessageEnd
Issue 8785: Return message
Issue 8786: Arguments of Message
Issue 8787: Numbering
Issue 8788: Variables
Issue 8824: Obsolete term EventOccurrence still used in multiple places
Issue 8825: Incorrect Communication Domain Model
Issue 8826: Section: 12 and 13
Issue 8845: p. 721: Allow stereotypes to have properties that are typed by metaclasses
Issue 8846: p. 728: New presentation options. Replace the following paragraph
Issue 8847: p. 729: Extend the Clock example to show metaclass property
Issue 8848: Make instance model consistent with new definition of Clock
Issue 8849: p. 731: Make this example consistent with the new definition of Clock
Issue 8850: p. 731: Make example consistent with new definition of Clock.
Issue 8851: p. 732: Change example to be consistent with new definition of Clock
Issue 8852: p. 732: Show examples of new stereotype notation
Issue 8853: pp. 733-734: Add association as valid graphic path
Issue 8854: multiplicity should not be used/shown in an communicates association
Issue 8855: Issue 7368 - make Classifier::useCase navigable
Issue 8859: Section: 12.3.37 ObjectFlow
Issue 8861: Section: 12.3.2 Action
Issue 8866: Section: Classes
Issue 8867: OpaqueAction
Issue 8876: Page: 369/370
Issue 8877: Page: 129
Issue 8878: Page: 532
Issue 8880: 9.1 BehavioralFeature package
Issue 8882: Section: 10.1 Types Diagram
Issue 8883: UML 2.0 Super/Use Cases/Subject of a Use Case
Issue 8887: Section: 11.3.6 Classifiers diagram
Issue 8888: Section: 11.3.13 TypedElement (as specialized)
Issue 8889: Section: 11.5.1 DataType (as specialized)
Issue 8890: Section: 15.3.12
Issue 8891: Page: 423
Issue 8893: UseCase and Actors
Issue 8894: TimeExpression
Issue 8895: ObjectNode
Issue 8896: abstract Action in Activity diagram
Issue 8897: OutputPin
Issue 8898: Syntax of Transition
Issue 8899: reply messages in interactions
Issue 8900: Page: 157,162,163
Issue 8901: Page: 163
Issue 8903: page 97, Chapter 10.2.2. MultiplicityElement
Issue 8904: page 134, Chapter 11.4.1
Issue 8919: Section: 12.3.5
Issue 8920: Page: 62
Issue 8921: Meaning of navigability
Issue 8930: Section: 12.3.9
Issue 8932: UML Superstructure / Actions / incorrect form for subsetting
Issue 8933: UML Superstructure / Actions / Missing package heading
Issue 8935: UML2 issue: {unrestricted} described in text but not BNF
Issue 8936: event parameters
Issue 8938: Section: 15.3.14
Issue 8939: Section: 12.3.18 and 12.3.35
Issue 8945: Page: 420
Issue 8946: Section: 9.3.5
Issue 8947: Figure 430 references invalid metaclass
Issue 8951: UML 2 Super / Actions / Compliance Levels of Actions
Issue 8952: UML 2 - Invalid subsetting of composition ends
Issue 8955: connection point reference
Issue 8956: UML 2 Classes Notation for association end ownership
Issue 8957: UML 2 XMI DTD requirement
Issue 8963: UML2 Navigability Impact on Tools
Issue 8964: Interaction::lifeline should be ordered
Issue 8965: Section: 14.3.20
Issue 8966: Core::Constructs::Operation
Issue 8967: UML SuperStructure - Inconsistency re State Machine terms
Issue 8968: Page: 591,592
Issue 8970: Behavior
Issue 8972: Page: 255
Issue 8973: Page: 346-347
Issue 8974: Missing notation for association classes
Issue 8975: UML2 Super / 14.3.13 Interaction
Issue 8976: UML 2 Super / Undocumented properties
Issue 8977: Property ownership must be consistent across association redefinitions
Issue 8978: UML2 should specify default property ownership for association ends
Issue 8987: Section: 6.5
Issue 8989: UML 2 Super / Collaboration use issues (01)
Issue 8990: UML 2 Super / Collaboration use issues (02)
Issue 8993: UML 2 Super / miscellaneous figure-text discrepancies
Issue 8996: Invalid stereotype in StandardProfile
Issue 9000: Section: Activities
Issue 9001: Section: Common Behavior
Issue 9002: Section: Common Behavior (02)
Issue 9003: Section: Classes
Issue 9004: Section: Classes (02)
Issue 9005: Section: Common Behavior
Issue 9006: Section: Actions
Issue 9007: Section: Common Behaviors
Issue 9008: Section: Classes
Issue 9009: Section: Activities
Issue 9010: Section: Activities
Issue 9011: Section: Classes
Issue 9012: Section: Classes
Issue 9013: Section: Activities
Issue 9014: Section: Activities
Issue 9015: Section: Classes
Issue 9017: Section: 16.3.3
Issue 9023: 7.3.22 InstanceSpecification
Issue 9024: "ownedType" is not a valid element
Issue 9076: Page: 53-55
Issue 9077: Section: 14.4
Issue 9078: Section: Activities
Issue 9080: UML2 Superstructure Fig 2.2 Incomplete
Issue 9081: Section: 14.3.20 Message (from BasicInteractions)
Issue 9084: following imports from merged packages to unmerged packages should be remov
Issue 9085: body expression for Property::isConsistentWith(RedefinableElement)
Issue 9086: Rename Constraint::namespace
Issue 9087: Rename Package::ownedMember
Issue 9088: Rename Component::ownedMember
Issue 9089: Rename ActivityEdge::redefinedElement
Issue 9090: Rename ActivityNode::redefinedElement
Issue 9091: Replace {redefines redefinedElement}
Issue 9092: Replace {redefines redefinedElement}
Issue 9093: Replace {redefines redefinedElement}
Issue 9094: Replace {redefines redefinedElement}
Issue 9095: Rename ActivityPartition::subgroup to subpartition
Issue 9096: Change type of WriteStructuralFeatureAction::value
Issue 9097: Change type of WriteStructuralFeatureAction::value to ValueSpecification
Issue 9098: compliance levels L2 and L3
Issue 9099: Rename InformationFlow::target
Issue 9100: Rename InformationFlow::source
Issue 9101: (merged) compliance level L1
Issue 9102: (merged) compliance levels L2 and L3
Issue 9103: Rename OpaqueAction::input to inputPin
Issue 9104: Rename LinkAction::input to inputPin
Issue 9105: Make ActivityGroup::containedEdge a derived union
Issue 9106: Make ActivityGroup::containedNode a derived union
Issue 9107: Rename OpaqueAction::output to outputPin.
Issue 9108: Rename ActivityGroup::activity to containingActivity
Issue 9109: Component::realization should NOT be derived
Issue 9110: Classifier::parameter, Operation::parameter, and ConnectableElement::parame
Issue 9111: Page: 492-493
Issue 9117: UML 2 issue: redefining isComposite on association ends
Issue 9119: Realization classifier
Issue 9120: section, 12.3.27 ExpansionRegion(from ExtarStructureActivities
Issue 9122: UML 2.1 Regressions
Issue 9123: Section: Actions, Figure 156
Issue 9124: Need more flexible notation for activity partitions
Issue 9125: keyword, "buildcomponent", and a stereotype, "buildComponent"
Issue 9138: inconsistency wrt UML2 classifier behavior
Issue 9141: Section 8.3.2 sub-section "Notation" starting on page 149
Issue 9142: Section 8 Issue - Component Realization-Classifier multiplicity
Issue 9143: Section: 7.3.36 Operation
Issue 9145: Page: 107
Issue 9146: Section 7.2.1 of ptc/04-10-14
Issue 9172: Section: 15.3.15
Issue 9179: Section: Appendix A: Diagrams
Issue 9180: UML 2.0 issue: Package Primitive Types not merged
Issue 9181: UML 2.0 issue: Profile::ownedStereotype should be derived
Issue 9182: UML 2.0: invalid package merge diagrams for compliance points
Issue 9183: UML 2.0: separate profile application from profile importing
Issue 9184: UML 2.0: CMOF/UML mixup for profiles
Issue 9185: UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used
Issue 9186: UML 2.0: Inconsistencies in profile example XMI
Issue 9187: UML 2.1 XMI Issue
Issue 9188: uml::Extension::ownedEnd should not subset uml::Association::ownedEnd
Issue 9189: Artifact::fileName
Issue 9190: Parameter::effect
Issue 9191: Required attributes
Issue 9192: The following properties should not subset DirectedRelationship::source
Issue 9193: The following properties should not subset DirectedRelationship::target
Issue 9194: Compliance package L2 does not merge StructuredActions in the metamodel
Issue 9195: parameter of operation isRedefinitionContextValid() is inconistently named
Issue 9196: Transition guards cannot currently be evaluated because they have no contex
Issue 9197: Issue regarding "Action::effect : String"
Issue 9198: Behavior::context
Issue 9224: StateMachine::extendedStateMachine should have a multiplicity of 0..*.
Issue 9225: No notation for associating Exceptions with Operations
Issue 9230: choice of terminolgy for TransitionKind is non-intuitive
Issue 9232: Page: 161
Issue 9233: On page 26, Figure 7.9
Issue 9234: Operation should be a specialization of TypedElement and MultiplicityElemen
Issue 9235: Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"
Issue 9236: constraints owned by these properties have no context
Issue 9237: Section: Classes
Issue 9241: Operation::ownedParameter should be ordered in XMI?
Issue 9242: /qualifiedName attribute missing on Core::Constructs::NamedElement
Issue 9243: XMI file: Core::Constructs::Operation::bodyCondition should have upper boun
Issue 9244: Unclear relationship between the Basic and Abstractions packages
Issue 9245: Description of Element
Issue 9246: Element and Comment in Basic
Issue 9247: No ReadParameterAction or WriteParameterAction
Issue 9249: 7.3.4 Association Class
Issue 9256: Optional name attribute in NamedElement is misleading and insufficient
Issue 9330: Page: 338, 339
Issue 9337: 7.3.41 Parameter (from Kernel, AssociationClasses)"
Issue 9338: 7.3.41 Parameter (from Kernel, AssociationClasses)"
Issue 9339: consistent ordering of Association::memberEnd and ownedEnd
Issue 9340: Section: 14.4
Issue 9341: reference to Figure 12.87 missing
Issue 9351: UML 2.1/Superstructure/ call triggers vs signal triggers
Issue 9352: UML 2 Superstructure / CommonBehaviors / Incorrect types in text
Issue 9362: Page: 625
Issue 9369: Section: 7.3.9
Issue 9370: Section: Sequence diagrams
Issue 9371: All associations ends in the UML2 metamodel itself should be navigable
Issue 9372: Show an example of correct notation for the metamodel
Issue 9373: Use the new 'dot' notation in examples
Issue 9374: AssociationClass is severely underspecified
Issue 9375: Section: 7.3.7
Issue 9395: Fig 12.10
Issue 9398: UML 2/Templates -- single argument?
Issue 9400: Notation for ordering action input and output pins
Issue 9401: ControlNodes in ActivityPartitions
Issue 9402: Reception has no notation for its signal
Issue 9403: No ObjectEvent corresponding to SendObjectAction
Issue 9406: UML2: No notation for indicating Operation::raisedException
Issue 9407: UML2: No notation for BehavioredClassifier::ownedTrigger
Issue 9413: UML 2 Super / Composite Structure / ambiguous constraint
Issue 9416: Section: 12.3.48
Issue 9445: Link notation for instance diagrams does not cope with multiple classifiers
Issue 9464: UML 2 Super / Components / connectors to interfaces
Issue 9513: UML 2.2 RTF issue - line styles for profiles
Issue 9514: page 467, Section 13.3.24
Issue 9556: Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter
Issue 9576: Section: 13.3.24 Signal (from Communications)
Issue 9577: New Issue on multiple guillemot pairs for same element
Issue 9578: assembly connectors
Issue 9597: Fig 7.14
Issue 9598: ptc/06-01-02:14.3.14, Notation
Issue 9599: New issue on notation for multiple stereotypes
Issue 9605: packagedElement
Issue 9606: ptc/06-01-02:14.3.14, Notation
Issue 9617: Section: 7.3.10
Issue 9619: Section: 9.3.13 - connectors
Issue 9622: the default for a Property should not be inconsistent with its type
Issue 9700: UML's support for null values and semantics is unclear
Issue 9701: Unnecessary restriction on aggregations being binary
Issue 9702: No way of specifying element documentation
Issue 9703: Unclear usage of LiteralExpression::type
Issue 9704: "Property::lowerValue" is not a good name
Issue 9705: ValueSpecification::isComputable()
Issue 9706: Definition of stereotype placement requires a name
Issue 9710: 11.3.26 OpaqueAction
Issue 9718: UML 2/ Super / SendSignalEvent erratum
Issue 9720: Action inputs/outputs
Issue 9750: A notation for Trigger
Issue 9751: UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement
Issue 9752: Section: 11.1.3
Issue 9754: Section: 7.3.33
Issue 9760: Section: 9.14.2
Issue 9800: What exactly is a state list?
Issue 9803: Editorial bug in 2.1 Superstructure Convenience document
Issue 9805: Default value types
Issue 9806: General ordering cycles
Issue 9807: Section: 8.3.1
Issue 9808: Completion event modeling
Issue 9812: Page: 64 & 112
Issue 9813: Section: 9.2
Issue 9814: Section: 9.3.11
Issue 9817: Section: 7.2
Issue 9818: discrepancies between package dependencies and XMI file for Superstructure
Issue 9819: Section: Appendix F
Issue 9820: Section: Figure 14.5
Issue 9821: Section: 9.3.11
Issue 9822: Section: 7.3.44
Issue 9823: Section: 7
Issue 9824: Section: 15.3.14 Transition
Issue 9825: Notation (p 154, formal/05-07-04 )
Issue 9826: Section 10.2.1 "Class" (in Basic)
Issue 9827: Section 11.4.1 "Classifier" (in Constructs)
Issue 9828: Section 11.4.1 "Classifier" (in Constructs)
Issue 9829: Section: 12.3.8
Issue 9830: Stereotype attributes inherited from Class
Issue 9831: UML 2: "isLeaf"
Issue 9833: text of specs and corresponding XMI specs should be clarified
Issue 9834: Relationships
Issue 9839: Section: 15.3.12
Issue 9840: Section: 15.3.12, p 588, 589
Issue 9841: EnumerationLiteral should constrain InstanceSpecification
Issue 9842: Guidance for Representing Enumeration Values
Issue 9843: Figure 7.4 invalid redefines
Issue 9855: Section: Activities
Issue 9856: Section: Activities - Weight description
Issue 9857: Section: Activities - Weight notation
Issue 9858: Section Activities: Default weight
Issue 9859: ReadLinkAction
Issue 9860: Section: Activities - Pin ordering semantics
Issue 9861: Section: Activities - Preserving order of multiple tokens offered.
Issue 9862: Section: Actions - InputPin semantics wording
Issue 9863: Section: Actions - Output of read actions for no values
Issue 9864: Section: Activities - Semantics of fork node wording
Issue 9865: Section: Activities - Multiple activity parameters nodes for a single inout
Issue 9866: Section: Activities - Offer ordering on joins
Issue 9867: Section: Activities - Join node edge constraint
Issue 9868: Section: Activities - ForkNode semantics wording
Issue 9869: Section: Activities - Output pin semantics clarification
Issue 9870: Actions on non-unique properties with location specified
Issue 9871: Section: Activities - isSingleExecution default
Issue 9872: Section: Activities -StartClassifeirBehaviorAction and classifier behaviors
Issue 9873: Section: Common Behavior - isReentrant should default to true
Issue 9875: Section: Activities - Action semantic clarification
Issue 9877: Notation for stereotypes on Comments and other elements
Issue 9878: PrimitiveTypes access by UML (M1) models
Issue 9881: Bad cross reference for InterfaceRealization Notation
Issue 9885: text-diagram out of synch in Infrastructure 11.4.1
Issue 9886: OCL Syntax in expressions
Issue 9887: Optional values and evaluation of defaults
Issue 9888: Move Property::isId from MOF to UML
Issue 9889: Unclear which Property has aggregation
Issue 9890: Clarify isRequired
Issue 9891: ExtensionEnd description refers to old use of navigability
Issue 9923: Section: 13 & 14
Issue 9961: navigating from link to link ends
Issue 9962: Subclasses of InstanceSpecification
Issue 9963: No default value specified for Generalization::isSubstitutable
Issue 9999: Association::isDerived should be derived
Issue 10000: Missing inheritance in 9.3.12
Issue 10001: Merged Metam.:Property::class with redefinition of non-inherited property
Issue 10003: Section: 9.12.1
Issue 10004: Section: 9.13
Issue 10005: Section: 9.10.3
Issue 10006: Section: 9.19.1
Issue 10007: Section: 9.16.1
Issue 10044: Profile Structure Diagrams are missing from Annex A
Issue 10045: 11.3.47 on StructuralFeatureAction (and related sections on subclasses)
Issue 10074: Invalid mandatory compositions and associations
Issue 10076: Section: 14.3.20
Issue 10079: Invalid redefinitions introduced into metamodel
Issue 10080: Section: 11.3.5
Issue 10081: Section: 13.2
Issue 10082: Section: 15.3.8
Issue 10083: proper content for Figure 13.8
Issue 10086: Section: Annex C.1
Issue 10087: Figure 7.31
Issue 10140: Section: 7.3.3
Issue 10144: redefined properties
Issue 10145: 12.3.26 ExpansionNode
Issue 10146: 12.3.27 ExpansionRegion
Issue 10147: UML 2 state machines / entry point outgoing transitions
Issue 10151: UML 2: Semantics of isOrdered need to be clarified
Issue 10345: Section: 7
Issue 10347: Section: 17.5
Issue 10351: Section: 12.3.2 Action
Issue 10353: UML2: Parameter::isException overlaps with Operation::raisedException
Issue 10354: issue regarding required and provided interfaces
Issue 10356: Page 60 of the pdf
Issue 10376: uml.xsd schema file in ptc/2006-04-05 is not correctly generated
Issue 10379: Section: 7.3.38
Issue 10382: Meaning of Constraint visibility
Issue 10383: Section: 13.3.25
Issue 10386: Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE-
Issue 10388: Activity shape
Issue 10411: Section: Chapter: 7.3.2.4 View
Issue 10413: Constraint.context vs Constraint.constrainedElement
Issue 10441: UML2: ReadSelfAction with a context cannot access behavior owned attributes
Issue 10469: Figure 13.8 shows the wrong diagram
Issue 10474: Connector contract is inflexible
Issue 10498: Section: 15
Issue 10512: Section: 15
Issue 10513: Section: 13.2
Issue 10515: Section: 7
Issue 10521: AcceptCallAction has not operation
Issue 10526: UML 2 Superstructure/Components/overly stringent constraints
Issue 10529: Section: 14.3.14
Issue 10530: Section: 14.3.10
Issue 10536: A_end_role should not be bidirectional
Issue 10537: A_outgoing_source and A_incoming_target should not be bidirectional
Issue 10590: UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse
Issue 10591: UML 2.1 Spec, Interactions: 14.3.18
Issue 10594: Section: e. g. 12.2. page 287
Issue 10597: Behavioral port
Issue 10600: UML 2 Superstructure: Abstractions should be acyclic
Issue 10634: UML2: notation issue
Issue 10635: Presentation option for return parameter for operation type are incomplete
Issue 10636: ReplyAction::replyValue type is incorrct
Issue 10637: Section: 12.3.38
Issue 10643: Section: 13 SimpleTime
Issue 10650: Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions)
Issue 10651: Page: 155, 162
Issue 10655: UML2: Behavior without a specification should not be a classifier behavior
Issue 10656: clarification on Behavior::specification / meaning of InterfaceRealization
Issue 10731: Uses notation "Subsets Element::ownedElement" and similar
Issue 10775: section 13.3.2 – doc ptc/2006-04-02, v.2.1
Issue 10776: consistent descriptions of semantics of event consumption needed
Issue 10777: A notation for Trigger
Issue 10778: Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05
Issue 10780: UML2: Actor cannot have ownedAttributes
Issue 10781: Section: 10.3.4 of formal/2007-02-03
Issue 10783: Section: 7.3.32
Issue 10788: Ptc/06-04-02/Pg 188
Issue 10789: Port.provided:Interface
Issue 10802: Section: 17/17.5.7
Issue 10814: Section: Composite Structures
Issue 10815: Flowing data into decision input behaviors
Issue 10816: Setting structural features of a data type
Issue 10818: Section: 12.3.30
Issue 10819: Diagram metaclass shall be introduced and shall be subclass of Element
Issue 10820: ConnectorEnd shall have references to provided or required interfaces
Issue 10821: ValueSpecification that refers to some Element shall be defined
Issue 10822: Ability to define "context specific" default values for Part
Issue 10823: names and namespaces
Issue 10824: Units and types are still problematic
Issue 10826: Repr. of applied stereotypes and their properties insufficiently described
Issue 10827: Consistency in description of ends owned by associations
Issue 10828: Figure 7.14: "Type" does not show its inheritance from "PackageableElement"
Issue 10829: Usage of "Element::ownedMember"
Issue 10830: "Constraint::context" is marked as derived in the metaclass description
Issue 10831: "PackageableElement::visibility" uses "false" as default value
Issue 10832: Section: 15.3.12
Issue 10930: Section: 18.3.8
Issue 10931: State Machines
Issue 10957: UML 2.1.1 - notation for parameter sets
Issue 10959: Section: 15.3.14
Issue 10960: Section: 13.3.24
Issue 10966: drawing a frame to represent Combined Fragment or an Interaction Occurrence
Issue 10967: description of 14.3.24 MessageSort (from BasicInteractions) - typo
Issue 10974: Explanation of Observation notation
Issue 10976: Section: 15.3.11
Issue 10992: UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3
Issue 10999: 9.3.9 Invocation Action
Issue 11003: page 449 chapter 13.3.24 (Signal (from Communications)
Issue 11004: Section: 9.3.8
Issue 11007: Wrong notation description
Issue 11008: Wrong subsets
Issue 11054: Section 18.3.1
Issue 11055: Section: 16.3.2 Classifier (from UseCases)
Issue 11067: Section: 9 Composite Structures / Port notation
Issue 11068: Section: 14 Interactions: Lifeline representing an actor
Issue 11069: Section: 12.3.41 Streaming parameters for actions
Issue 11076: Behaviors Owned by State Machines
Issue 11087: Section: 9.3.11 p 182
Issue 11089: "representation"
Issue 11090: information flow source and target
Issue 11092: Section: 14.4 Timing Diagram: Continuous time axis
Issue 11109: Section: 11.4 Classifiers Diagram
Issue 11114: Section: 11.4
Issue 11115: Section: 7.3.21
Issue 11116: Section: 7.3.21 figure 7.47
Issue 11120: Property::isAttribute() query needs no argument
Issue 11152: UML 2.2 scope statement
Issue 11154: Section: Abstractions
Issue 11155: Section: Constructs
Issue 11156: Section: Abstractions (02)
Issue 11160: Namespace URI for Standard Profile(s)
Issue 11162: Section: 13.3.3
Issue 11164: Section: 9 composite structures
Issue 11200: Actor concept was indeed changed
Issue 11201: Section: 14.3.3
Issue 11234: UML 2.1.2: Path names for CMOF files
Issue 11238: composite subsets
Issue 11239: composite values
Issue 11240: defaultClassifier of ClassifierTemplateParameter
Issue 11243: constraining Classifiers
Issue 11244: RedefinableTemplateSignature
Issue 11265: Any ownedBehavior should be able to have AcceptEventAction
Issue 11268: Section: 12.3.1 AcceptEventAction
Issue 11272: Section: Annex A: Diagrams
Issue 11273: Section: Annex A: Diagrams
Issue 11286: first constraint for CombinedFragment
Issue 11287: Section: 7.3.3
Issue 11307: Section: 16.3.5
Issue 11323: UML2 Property collaborationRole should be removed
Issue 11342: Section: 7.3.37 Package (from Kernel)
Issue 11343: Section: 18.3.6 Profile (from Profiles)
Issue 11400: Change multiplicity of ClassifierTemplateParameter role
Issue 11401: Figure 14.5 - Messages.
Issue 11407: context of Constraint
Issue 11408: UML 2.1.1 - fig 7.14
Issue 11409: TimeEvent
Issue 11410: simpleTime package problems
Issue 11413: The section titled "Changes from previous UML" is not complete
Issue 11414: Incorrect word renders sentence meaningless: Chap. 12.3.41
Issue 11488: ElementImport
Issue 11489: In section 7.3.12 Figure 7.38
Issue 11503: Section: Composite Structures/Abstract syntax
Issue 11524: Figures 9.4 identical to figure 9.3
Issue 11625: Section: 7.3.7
Issue 11630: Section: 7.3.33
Issue 11646: StructuredActivityNode [UML 2.1.1]
Issue 11657: UML2 issue: ProfileApplication treated as Import
Issue 11683: UML2 Issue - 'abstract' not listed in keyword Annex
Issue 11762: Section: 8.3.2 Connector
Issue 11763: Section: 12
Issue 11807: Figure 7.48 and the accompanying discussion under 7.3.21
Issue 11815: Section: 14.4
Issue 11827: UML2 Issue: notation for Literals does not allow for name
Issue 11828: Figure 7.6
Issue 12158: The spec needs to clarify the isConsistentWith() method for transitions
Issue 12161: UML2: Missing ActionOutputPin
Issue 12162: pull semantics are only supported on Action inputs, not outputs
Issue 12166: should be able to show gates on communication diagrams
Issue 12167: inability to specify ordering of messages connected to gates is problematic
Issue 12168: TemplateSignature / TemplateParameter / StructuredClassifier
Issue 12169: Regarding the quote on p128
Issue 12170: section 15.3.14 Transition :: Constraints
Issue 12193: UML 2.1.1 Issue: Invalid association end in Figure 7.20
Issue 12195: Section 14.3.19
Issue 12197: UML 2: Need an explicit listing of all semantic variation points
Issue 12203: UML 2 has lost cability to represent operations by collaborations
Issue 12204: paragraph on "deferred events" on page 552
Issue 12218: 15.3.14: This paragraph refers to signal and change events
Issue 12224: Datatypes in UML profiles
Issue 12236: Table 8.2
Issue 12241: The semantics of an assembly connector remains unspecified
Issue 12244: association 'ownedTemplateSignature' of a Classifier
Issue 12250: formal definitions of 'isCompatibleWith' (pages 622, 647, 649)
Issue 12251: definition of 'isCompatibleWith' for ValueSpecification
Issue 12252: term 'templatedElement' not defined
Issue 12259: The list of literal described for the ennumeration MessageSort is not compl
Issue 12261: Comments owned by Packages
Issue 12262: Comments owned by Packages (02)
Issue 12263: description of MessageOccurenceSpecification
Issue 12266: PackageableElement (from Kernel), subsection: "Attribute"
Issue 12267: Section: 7.3.41
Issue 12271: section '10.3.12 Property (from Nodes)'
Issue 12272: Section 7.3.44
Issue 12273: undefined term 'Element::redefinedElement' occurs three times in standard
Issue 12274: new constraint ?
Issue 12275: UML Super 2.1.2:Feature
Issue 12278: UML 2.1.2:18.3.5 Package (from Profiles)
Issue 12279: Section: 18.3.3
Issue 12284: A final node that returns to the caller but leaves alive any parallel flow
Issue 12285: UML Super 2.1.2: section 18.3.2
Issue 12354: Section: 15.3.7 Constraint [2]
Issue 12355: UML 2.1.2 Super: Execution Specification
Issue 12356: Section: 8.3.3
Issue 12357: CMOF file for UML2 does not have derived Associations marked as such
Issue 12369: qualifiers
Issue 12379: Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten
Issue 12380: Section: 15.3.11/Notation
Issue 12381: Section: 13.3.3/ Changes from previous UML
Issue 12382: Section: 7.3.10/Associations
Issue 12383: Section: 7.3.10/Associations
Issue 12384: Section: 7.3.10/Associations - insert reference
Issue 12385: Section: 12.3.8/Generalizations
Issue 12405: Car dependency example
Issue 12406: Figure showing an AssociationClass as a ternary association
Issue 12427: interpreting InstanceSpecification
Issue 12431: Section: 15 StateMachines: doActivity and internal transitions
Issue 12432: Section: 7.3.7 and 8.3.1
Issue 12433: Section: Activities: Modifications to the approved resolution of 10815
Issue 12434: Section: Activities
Issue 12436: first paragraph of section 7.8 UML kernel
Issue 12455: Section 14 Interaction
Issue 12492: Port
Issue 12511: Callout notation for many clients/suppliers
Issue 12516: Classifiers
Issue 12528: PackageMerge relationships
Issue 12530: Behavior's parameter list
Issue 12532: definition of RedefinableElement::isLeaf
Issue 12544: role bindings of a CollaborationUse
Issue 12545: Section 10.3.10
Issue 12556: Section: 7.3.35
Issue 12557: The behavior of an OpaqueExpression should itself be opaque
Issue 12558: Section: 13.3.23
Issue 12564: Section: 13.3.3
Issue 12565: Section: 12.2
Issue 12566: 3 3.2 Behavior (CommonBehaviors/BasicBehaviors)
Issue 12567: Section: 11.3.30,12.3.23
Issue 12568: Section: 14.3.24, 14.3.20
Issue 12569: Section: 7.3.36
Issue 12570: UML2 issue regarding Redefinition
Issue 12580: UML2 issue regarding RedefinableTemplateSignature
Issue 12583: OCL 2.0 8.2 Real
Issue 12584: Keyword ambiguity for DataType Section
Issue 12586: Section 7.3.50 "substitution"
Issue 12587: UML2: Need a better mechanism for integrating UML2 Profiles
Issue 12749: Section: 7.4 figure 7.1 missing dependency
Issue 12750: Section: 2.2-2.4 compliance level clarifiction needed
Issue 12774: Regression in XMI from UML 2.1.2 to UML 2.2
Issue 12775: Section: 9.3.8
Issue 12781: Incorrect OCL expression for constraint [1] on BehavioredClassifier
Issue 12782: Unspecified constraint [1] on AcceptEventAction
Issue 12783: Unspecified constraint [1] on ActivityEdge
Issue 12784: Unspecified constraint [2] on ActivityEdge
Issue 12785: Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities)
Issue 12786: Unspecified constraint [1 on Activity
Issue 12787: Unspecified constraint [2] on Activity
Issue 12788: Unspecified constraint [3] on Activity
Issue 12789: constraint [4] on AcceptEventAction and unordered result:OutputPin property
Issue 12790: Unspecified constraint [1] on ActivityNode
Issue 12791: Unspecified constraint [1] on ActivityNode (StructuredActivities)
Issue 12792: figure 13.12
Issue 12794: Property – Additional Operations, page 127.
Issue 12833: Clarification on use of Profiles.
Issue 12834: On the communication diagram in Fig 6.2 (P12)
Issue 12835: On the communication diagram in Fig 6.2 (second issue)
Issue 12836: On the table 2.3, page 8
Issue 12837: Figure 7.65 and its explanation, P115
Issue 12838: Typo P205 10.3.4
Issue 12839: 7.3.11 DataType, P61
Issue 12840: 18.3.8 Stereotype
Issue 12841: 7.3.44 Property P128
Issue 12842: 7.3.44 additional operation P128
Issue 12843: Typo 9.3.13 p190
Issue 12844: Classifier has association end "attribute"
Issue 12845: Property 7.3.44 p125
Issue 12846: 7.3.33 p100
Issue 12847: Metaclass Property is denoted in Interfaces Package on p.36
Issue 12848: TYPO p.54 Additional Operations
Issue 12850: operation allConnections
Issue 12851: p269-p270 Constraint
Issue 12852: issue to address how problem 11240 was actually addressed in UML 2.2 spec
Issue 12855: specificMachine association should be changed to be type StateMachine
Issue 12860: InterfaceRealization
Issue 12912: InstanceSpecifications
Issue 12915: Inconsistency in Superstructure 2.2 p. 550
Issue 12942: Actors cannot own Operations - a contradiction
Issue 12985: Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"?
Issue 13058: 18.3.8 Generalization of stereotyped model elements
Issue 13080: New proposal for conjugate types for ports
Issue 13081: New proposal for conjugate types for ports
Issue 13083: UML 2.2 superstructure section 9.3.11 page 184: Port.isService
Issue 13091: Super package should import NamedElement from the Visibilities package, not Namespaces
Issue 13092: Parameter isn't package (Heading 2 level)
Issue 13093: Figure 9.20
Issue 13134: Section: 14.3.20 Actors in Interactions
Issue 13136: Section: 7.3.12 Dependency (from Dependencies)
Issue 13137: Section: 7.3.39 PackageImport (from Kernel)
Issue 13140: Semantics of Ports in Components and CompositeStructures are incompatible
Issue 13141: UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter
Issue 13142: UML2.2 Section 9.3.1 Presentation Options section
Issue 13146: UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid
Issue 13147: UML 2.2 figure 8.10 has arrows the wrong way around
Issue 13148: Section: 14.3.3 CombinedFragment (from Fragments)
Issue 13149: Section: 14.3.24 MessageSort (from BasicInteractions)
Issue 13163: transitionkind Constraints
Issue 13164: UML. Clarify relationship of Substitution and InterfaceRealization
Issue 13165: There is no way to specify the behavior of operations which are members of data types
Issue 13188: "description" section of the Behavior metaclass
Issue 13192: UML: Standard Techniques to disambiguate crossing lines needed
Issue 13193: Section: 12.3.14 Figure 12.29 on page 320
Issue 13250: Val(MyCar.Interaction [SVWB
Issue 13253: description of Interaction provided by the Semantic section inconsistent
Issue 13254: Notation for ExecutionSpecification
Issue 13255: UML2.2 RTF: EnumerationLiteral is a DeploymentTarget
Issue 13256: Section: 14.3.13 Interaction (from BasicInteraction, Fragments)
Issue 13257: ParameterableElement as a formal template parameter
Issue 13258: inconsistency with how constraints are specified in UML and OCL
Issue 13291: Instance modeling does not take into account stereotypes properties
Issue 13306: Packaging Issues with Stereotype Extension
Issue 13324: Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above)
Issue 13325: use of "internal" transition is used incorrectly in many places where "local" should be used.
Issue 13327: P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo
Issue 13330: Allowing multiple Associations in a Package with the same name
Issue 13395: UML2: Unclear how to indicate what events a classifier might send
Issue 13425: Section: 7.3.9 Comment should be NamedElement
Issue 13449: we can create an invalid active state configuration
Issue 13452: Section 9.3.4 Collaboration Use, 2nd constraint creates unneces
Issue 13466: Lack of clarity about meaning of package shapes containing elements with fully qualified names
Issue 13476: UML 2: conflicting specifications for how to calculate context for a Behavior
Issue 13477: default multiplicty of association ends are defined more than one
Issue 13478: The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression
Issue 13479: Section: 9.8.3 XMI fails to include a "lower" attribute
Issue 13480: In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element
Issue 13481: In the XMI, Ownerships::Element erroneously includes an association for ownedComment.
Issue 13482: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents
Issue 13543: UML 2.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1]
Issue 13591: Section: 7.4 Diagrams text on page 144
Issue 13592: "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144
Issue 13651: UML2.2. Contradications in 14.3.10
Issue 13653: UML2 : Lifeline identity for InteractionUse
Issue 13656: UML 2 - appearance of Association Ends as members of the related classes
Issue 13657: Section: 9.3.11 Port
Issue 13659: Figure 12.95 - "Fork node example"
Issue 13660: Table 12.1 - "Graphic nodes included in activity diagrams",
Issue 13661: Generalizations" for StructuredActivityNode on p. 417
Issue 13662: UML 2 7.3.3 : incorrect text about aggregationKind in associations
Issue 13664: UML 2.2 InteractionOperand abstract syntax
Issue 13665: Figure 2.2 contains more than four packages, description referes to four packages
Issue 13718: Section 12.3.48 on page 412
Issue 13788: Section 2.3 para 1 needs to be re-written
Issue 13789: Figure 7.1 shows no dependency
Issue 13790: Parameter is part of the BehavioralFeatures package.
Issue 13791: Paragraph 5: The text states that class Comment has no generalizations
Issue 13792: The "Generalizations" heading is missing before the "ValueSpecification" bullet.
Issue 13793: Two issues regarding Figure 10.2: 1
Issue 13794: Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?
Issue 13795: Section 13 "Core::Profiles" inconsistency
Issue 13796: Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element.
Issue 13797: Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile
Issue 13798: In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core"
Issue 13799: In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".
Issue 13800: In the Attributes section, "integer" should be capitalized
Issue 13834: "Associations" part of the "9.10.3 Slot" chapter/section
Issue 13841: Concrete specialization of the Relationship meta-class are missing
Issue 13844: Figure 18.2 (which describes the contents of the Profiles package) is currently misleading
Issue 13846: chapter 2.2, p.3 Last paragaph, second sentence
Issue 13847: Section: Chapter 2.2 Compliance levels
Issue 13848: issue within UPDM with profile diagrams
Issue 13852: Section: Fig. 7.15: subsets at wrong side
Issue 13853: 18.3.6 Typo in Profile section
Issue 13855: Section: 18.3.2
Issue 13856: Section: 18.3.6
Issue 13857: The XMI document contains <ownedMember> elements which should be <packagedElement>
Issue 13858: Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)
Issue 13859: The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading
Issue 13860: Figure 18.15 does not reflect the example before
Issue 13861: Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"
Issue 13862: Section: 18.3.8
Issue 13863: URIs do not refer to existing resources (404 errors) Annex H
Issue 13867: Description of Level 1 diagram does not make sense with respect to figure 2.2
Issue 13868: Table 2.2 Example feature support statement references Note (4) and Note (5)
Issue 13898: what's the difference > between weight=1 and weight=*?
Issue 13908: there are numerous places where associations between UML elements have only one, navigable role
Issue 13909: Figures 9.17 and 9.19 and related text
Issue 13910: Missing keyword?
Issue 13911: Clarify how the provided and required interfaces of a Port are calculated
Issue 13912: The OCL for /required interfaces of Component is using ports.provided instead of ports.required
Issue 13914: Clarify that input pins do not accept more tokens than their actions can immediately consume
Issue 13920: current definition of a 'local' transition does not allow the case to have a local transition
Issue 13926: Template Binding Question
Issue 13927: Subsets vs. Redefines
Issue 13930: Validator issues with TestCase 2
Issue 13931: Color errors on figures in UML 2.2
Issue 13933: Clarification need on circle plus notation for containment
Issue 13936: UML2: Need clarification on circle plus notation for containment
Issue 13943: Activity groups should be named
Issue 13947: Figure 7.38 needs to be revised
Issue 13948: UML2.2 chapter 16 : Actor constraint [1] has invalid OCL
Issue 13991: Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace
Issue 13992: lowerBound/upperBound constraints and derivations wrong
Issue 13993: UML 2.2 Issue - availability of PrimitiveTypes for UML models
Issue 13994: Section 9.9 should classifier be added to the diagram on p 50?
Issue 13995: confusion re diagram on p. 83
Issue 14021: UML2: error in definition of Class::nestedClassifier
Issue 14022: Visibility and Import relationships
Issue 14023: nestedClassifier
Issue 14027: Semantics of the AddVariableValueAction
Issue 14034: type mismatch
Issue 14035: Currently is it possible for a Classifier to specialize the same classifier directly more than once
Issue 14044: Should there be a constraint for extends equivalent to 16.3.6 [4]
Issue 14045: semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear
Issue 14062: UML 2 chapter 17: template model cannot represent templates parameterized by value types
Issue 14063: remove StructuredActivities::ActivityGroup
Issue 14065: UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents
Issue 14066: Properties need not be owned
Issue 14078: UML 2: notation and concepts for unbound and un-owned template parameters are not clear
Issue 14081: Package merge is missing a rule
Issue 14083: Profile::allOwningPackages
Issue 14084: Subsets vs. Redefines
Issue 14090: authorize a reference to an operation in a realized interface.
Issue 14092: Ambiguity in the names of the stereotypes in the standard profiles
Issue 14093: BNF of Constructs::Property
Issue 14114: Remove InputPint from StructuredActivities
Issue 14115: Need to copy down merged content to make constraints parse in receiving package
Issue 14116: Propagate RTF 2.3 changes to Infrastructure
Issue 14123: Remove redundantant constraint [2] in 7.3.4
Issue 14135: Difference between OCL and text in constraint [2] of 15.3.15
Issue 14183: Need notation option to show type stereotype on typed element
Issue 14186: The spec may require some clarification regarding figure 14.16
Issue 14192: The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public
Issue 14216: Documentation of merge increments in the superstructure
Issue 14220: Language unit of Usage
Issue 14227: UML: Issue with stereotype icons in a profile
Issue 14228: Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith'
Issue 14235: Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner
Issue 14258: Japan Superstructure PAS Ballot Comments - comment 1
Issue 14259: Japan Superstructure PAS Ballot Comments - comment 2
Issue 14260: Japan Superstructure PAS Ballot Comments - comment 3
Issue 14261: Japan Superstructure PAS Ballot Comments - comment 4
Issue 14262: Japan Superstructure PAS Ballot Comments - comment 5
Issue 14263: Japan Superstructure PAS Ballot Comments - comment 6
Issue 14264: Japan Superstructure PAS Ballot Comments - comment 7
Issue 14265: Japan Superstructure PAS Ballot Comments - comment 8
Issue 14266: Japan Superstructure PAS Ballot Comments - comment 9
Issue 14267: Japan Superstructure PAS Ballot Comments - comment 10
Issue 14268: Japan Superstructure PAS Ballot Comments - comment 11
Issue 14269: Japan Superstructure PAS Ballot Comments - comment 12
Issue 14270: Japan Superstructure PAS Ballot Comments - comment 13
Issue 14271: Japan Superstructure PAS Ballot Comments - comment 14
Issue 14272: Japan Superstructure PAS Ballot Comments - comment 15
Issue 14273: Japan Superstructure PAS Ballot Comments - comment 16
Issue 14274: Japan Superstructure PAS Ballot Comments - comment 17
Issue 14275: Japan Superstructure PAS Ballot Comments - comment 18
Issue 14276: Japan Superstructure PAS Ballot Comments - comment 19
Issue 14277: Japan Superstructure PAS Ballot Comments - comment 20
Issue 14278: Japan Infrastructure PAS Ballot Comments - comment 1
Issue 14279: Japan Infrastructure PAS Ballot Comments - comment 2
Issue 14280: Japan Infrastructure PAS Ballot Comments - comment 3
Issue 14281: Japan Infrastructure PAS Ballot Comments - comment 4
Issue 14282: Japan Infrastructure PAS Ballot Comments - comment 5
Issue 14283: Japan Infrastructure PAS Ballot Comments - comment 6
Issue 14284: Japan Infrastructure PAS Ballot Comments - comment 7
Issue 14285: Japan Infrastructure PAS Ballot Comments - comment 8
Issue 14286: Japan Infrastructure PAS Ballot Comments - comment 9
Issue 14287: Duplicate association in normative UML 2.3 superstructure file
Issue 14355: Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2
Issue 14356: Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics
Issue 14426: Association class notation with just class or association
Issue 14429: UML 2.3 draft, 11.3.1 - AcceptCallAction
Issue 14431: notation of objet flow <<selection>> and <<transformation>>
Issue 14439: errors in OCL statements of Additional Operations?
Issue 14448: UML 2.3: Errors in example serialization for Profiles in Chapter 18
Issue 14449: PrimitiveType has missing constraints
Issue 14536: Stereotyped Constraints in UML
Issue 14544: Stereotyped Constraints in UML
Issue 14552: Ordered derived unions
Issue 14554: Interface-redefinedInterface should subset Classifier-redefinedClassifier
Issue 14555: UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual
Issue 14560: Value of a Property
Issue 14563: Cyclick dependency
Issue 14565: typo in new attribute name
Issue 14566: CMOF missing several redefined property relationships
Issue 14569: Constraint [1] for WriteStructuralFeatureAction is incorrect
Issue 14570: Constraint [3] on TestIdentityAction is incorrect
Issue 14580: Parameter type of MultiplicityElement::includesMultiplicity()
Issue 14588: are Create messages aynch or synch, or doesn't it matter?
Issue 14613: UML2 - non-unique association names in L3.merged.cmof
Issue 14621: UML2 - derivation for DeploymentTarget.deployedElement is invalid
Issue 14626: UML2 - definition of Property.opposite is wrong
Issue 14627: UML2: Incomplete definition for Activity.structuredNode
Issue 14629: UML 2 Events referred to by OccurrenceSpecifications should be optional
Issue 14630: Some owned operations with OCL expression bodies but without their "isQuery" set to "true"
Issue 14631: All enumertion literals in the model have their "classifier" collections empty
Issue 14632: Associations with same name that live in different packages violate unique name constraint
Issue 14633: Attributes without a type
Issue 14634: Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform
Issue 14635: Errors with types of association ends not conforming to their subsetted ends
Issue 14636: Cycles in package imports
Issue 14637: Namespace collission due to package import
Issue 14638: Some associations in the normative XMI has one memberEnd
Issue 14643: AcceptEventAction notation
Issue 14862: Issue on generalization
Issue 14875: wrong Actor's constraint [1]"
Issue 14889: Wrong Spelling for "development"
Issue 14926: is composite, but does not subset ownedElement
Issue 14927: is composite and subsets not derived composite property:
Issue 14928: Property subsets other regular property, non-derived union
Issue 14929: lowered multiplicity
Issue 14930: One association end is derived, another is not
Issue 14931: remove BehavioredClassifier::ownedTrigger
Issue 14933: UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language
Issue 14934: Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling
Issue 14935: Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition
Issue 14936: UML: Need more robust value model that would enable capture of values vs time
Issue 14937: UML: Incorporate SysML Requirements Model into UML
Issue 14938: UML: Include text description field with model element
Issue 14939: UML Associate an image/icon with each model element
Issue 14940: UML: Provide unique URL/URI Reference to/from Model Elements
Issue 14941: UML: Include text description field with model element --- additional information added
Issue 14942: UML:Notational option to display inherited features in a subclass
Issue 14943: Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership
Issue 14944: UML: A strong ability to support reviewing packages
Issue 14945: UML: Support for maintaining what-if models in repository without massive duplication
Issue 14946: UML Support for multiple library levels
Issue 14947: UML: A strong ability to support generating Documents
Issue 14948: UML: Diagrams as Model Elements
Issue 14949: UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs
Issue 14950: UML: Better Definition of Compliance
Issue 14951: UML: Large Scale Model Support:Federated/Distibuted Models
Issue 14952: UML: Cross model dependencies
Issue 14953: UML: Improve Sequence Diagram Semantics (3-issues)
Issue 14954: UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments
Issue 14955: UML:Access to standardized ontologies within models
Issue 14956: UML: Better Profile Capabilitiy
Issue 14957: UML: Timing semantics for activity diagram
Issue 14958: UML: Higher-level reusable frameworks
Issue 14959: UML has no way of distinguishing Notes from Comments
Issue 14960: UML is vague about which Element should own Comments
Issue 14961: Unclear constraint on stereotype associations
Issue 14962: loopVariable ownership
Issue 14963: Context of a behavior owned as a nested classifier
Issue 14964: Definition of Behavior::context is not correct
Issue 14977: Matching subsettting across association ends
Issue 14978: NamedElements whose owners do not subset Namespace
Issue 14989: TestIdentityAction for datatypes
Issue 14991: Expansion nodes using all the tokens in them as a single collection
Issue 14993: UML 2: property redefinitions should be symmetric across associations
Issue 14994: The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting
Issue 14995: Subsetting clauses should show the subsetted property fully qualified.
Issue 15001: Incomplete resolution to 10826
Issue 15006: serialization of a profile should always include the nsURI and nsPrefix tags
Issue 15019: Package Extension
Issue 15020: Contents of Dependencies package
Issue 15046: Poor example of Dependency notation
Issue 15047: Lack of graphical example of multi-element Dependency Notation
Issue 15050: Parameter
Issue 15056: Figure 7.15
Issue 15107: Enumeration Literal
Issue 15120: Activity vs Action completion
Issue 15123: Sequence diagram and Communication diagrams should support instances as lifelines
Issue 15125: UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI
Issue 15126: UML2.3 definition of Classifier::hasVisibilityOf is circular
Issue 15128: Association owned derived union
Issue 15136: MessageEvents
Issue 15144: Detailed modeling of the Standard Profiles
Issue 15145: Modeling sent messages in State Machines
Issue 15162: UML2 - Invalid constraint for Actor
Issue 15167: composite tags
Issue 15207: Timing Diagram and interchange
Issue 15208: Invalid type for Slot.value
Issue 15209: Invalid type for NamedElement.namespace
Issue 15216: Minor bug in Namespace::importMembers() query
Issue 15221: Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf
Issue 15236: not sure it is possible to define a constraint without a context
Issue 15237: issue10087 and association-like notation
Issue 15239: Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications
Issue 15240: Owning of interaction fragments is ambiguous when InteractionOperands are present
Issue 15248: Initialization of complex fields
Issue 15251: Guard of activity edge should be optional
Issue 15259: Meaning of BodyCondition and its alignment with OCL
Issue 15263: UML 2 issue - misleadingly named associations
Issue 15264: Resolution to issue 14063
Issue 15265: UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine
Issue 15266: Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied.
Issue 15267: UML2 Issue: OCL in resolution 11114 is incorrect
Issue 15268: Term "method activation" deprecated?
Issue 15269: UML 2.3, Figure 18.1
Issue 15274: split the addition of generalization relationships among association in 14977 in two parts
Issue 15278: Auxiliary
Issue 15279: Create
Issue 15280: It seems odd to say that Service “computes a value”.
Issue 15281: 'false' is not a member of VisibilityKind
Issue 15283: issues relating to Figure 7.14 - The Packages diagram of the Kernel package
Issue 15285: Figure 7.10 shows Feature::isStatic as abstract
Issue 15288: NamedElement::clientDependency constrained to subset DirectedRelationship::source
Issue 15290: Ports
Issue 15303: How to specify actual parameters to pass to parameterized submachine StateMachine
Issue 15312: Issue on UML 2.3 - Use of isAbstract for Interfaces
Issue 15315: Aggregation missing from Property string syntax
Issue 15356: UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds
Issue 15369: UML 2.4: Add Property::isId
Issue 15370: UML 2.4: Add package:URI
Issue 15371: UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype
Issue 15372: Over-general sentence about MOF and Profiles
Issue 15378: UML 2.4: Inconsistent rendering of OCL in UML metamodel
Issue 15384: Typo: isStric => isStrict

Issue 3898: Specify XMI parameters for the UML / XMI interchange format (uml2-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:
When the UML spec standardises an XMI-generated interchange format for 
UML
models, it should include:

  * the "input" MOF meta-model for UML that was used to generate the
    interchange format, and

  * a formal statement of the other XMI "parameters" used to generate
    the interchange format.

If possible, the UML spec should include a definitive meta-model for 
UML
expressed as a MOF / XMI document.  This is a MOF alignment issue.



Resolution:
Revised Text: In appendix G of the Superstructure document (formal/05-07-04) and appendix A of the Infrastructure document (ptc/04-11-16) add the following sentence as the last sentence in The XMI specification corresponding to this specification can be found in OMG document Editor’s note: This is actually redundant and superseded by the resolution to 8678
Actions taken:
September 22, 2000: received issue
August 23, 2006: closed issue

Discussion:
alignment is strong 2.0 requirement


Issue 4110: Semantics of firing compound transitions still appears to be circular (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others. 

As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source". 

On page 2-173 of 2.12: 

*** The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered). 

If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state. 

[...] 

Once a transition is enabled and is selected to fire, the following steps are carried out in order: 

• The main source state is properly exited. 

• Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed. 

• If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected. 

• The main target state is properly entered. *** 

This is certainly much better than 1.3. But I still find it difficult to follow: 

Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA? 

The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets. 

If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source". 

With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice. 

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
December 7, 2000: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 4448: Does visibility apply to creating an destroying links? (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
  It isn't clear whether visibility of association ends applies to
     creating and destroying links.  If it does, then what if one end is
     private and the other public, can the private end create or destroy
     a link?

Resolution: see above
Revised Text: In Superstructure, Classes, and in Infrastructure, Core::Abstractions, Visibility package NamedElement Attribute, visibility entry, change description to “Determines where the NamedElement appears within different Namespaces within the overall model, and its accessibility.” Semantics, second paragraph in Superstructure, first paragraph in Infrastructure first sentence, replace “in different namespaces within a model” with “, either in namespaces or in access to the element. second sentence, replace “import and generalization” with “import, generalization, and access”. VisibilityKind, Semantics, first paragraph, replace "and Packages packages" with ", Packages, and Classes packages" in Superstructure, and with “, Packages, and Classifiers packages” in Infrastructure. In Superstructure, Classes, and in Infrastructure, Core::Basic Class, Semantics, at end, add new paragraph: "A class cannot access private features of another class, or protected features on another class that is not its supertype. When creating and deleting associations, at least one end must allow access to the class." In Superstructure, Actions WriteLinkAction, Constraints, add new constraint "The visibility of at least one end must allow access to the class using the action." CreateLinkObjectAction, Semantics, first sentence, after "semantics" add "and constraints".
Actions taken:
August 3, 2001: received issue
August 23, 2006: closed issue

Discussion:
More time is needed to consider the interaction of visibility with associations, to align it
with visibility of properties....The specification inadvertently omitted that visibility constrains access, as well as
importation and inheritance. In the particular case of classes, visibility constrains the
actions of methods of the class. Creation and destruction of links should be allowed by
methods that have access to at least one end of the association.


Issue 4932: Starting state machine (uml2-rtf)

Click
here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:
[Steve Mellor] The action semantics has an action that starts a state
machine.  The state machine starts in some known initial (pseudo-)state.

There are many cases where one wants to initialize a state
machine so that starts in a specified (non-initial) state.

Therefore the StartStateMachineAction needs to accept a state
(possibly multi-leveled) as an input.  The state machine will 
not execute any procedures or actions until after the state 
machine is in the target state and then detects an event.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
March 5, 2002: received issue
October 22, 2002: deferred issue

Discussion:
Application: restoring state.
Requires static specification of state, so complexity will be the same
  as having transitions to each state, and sending an event.
Would make a dependence of actions on state machines.
Similar problems with restoring attribute values, etc, of objects.
Requires tracking and restoring execution execution.
Too much for FTF to do consistently [Action Semantics FTF]:
Application: restoring state.
Requires static specification of state, so complexity will be the same as having transitions
to each state, and sending an event.
Would make a dependence of actions on state machines.
Similar problems with restoring attribute values, etc, of objects.
Requires tracking and restoring execution execution.
Too much for FTF to do consistently
[UML 2 FTF]
There is too much debate around this for the FTF to resolve. The use case is to bring up a
software system that is embedded in a larger physical system. The embedded system has
objects reflecting the state of the physical objects. The filer would like to start the
software system by instantiating classes, with the new instance reflecting the state of the
physical objects. Using triggers/guards on constructor inputs makes too cumbersome a
model.
There was some concern about referring to states from actions outside the object.
However, states are not always internal. There was also concern that the details of
restarting an application are not properly part of modeling. However, modeling is not
limited to a particular level of implementation. There was debate on whether entry points
could be used for the applications, but in any case, the action would need to refer to a
state.


Issue 4937: Sending a signal after a delay (uml2-rtf)

Click
here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:
 Sending a signal after a delay

Resolution: The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).
Revised Text: closed no change
Actions taken:
March 5, 2002: received issue
October 22, 2002: deferred
October 27, 2008: closed issue

Discussion:
Can't handle time the way state machines, with expressions, because
  action model needs to be more precise.
Why not on other actions besides SendSignalAction?
What is the relation to the time submission?
Too much for FTF. [Action Semantics FTF]: Can't handle time the way state machines, with expressions,
because action model needs to be more precise. Why not on other actions besides
SendSignalAction? What is the relation to the time submission? Too much for FTF.
Too much of an enhancement for FTF, as indicated in the issue report. In the meantime,
modelers can define actions for time delay.


Issue 5107: Starting a state machine (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:
Description: 
The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

Syntactically, we have the following: 

o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts. 

o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

o The definition of the stereotype <<create>> is (p. 2-149): 

"Create is a stereotyped call event denoting that the instance receiving 
that event has just been created. For state machines, it triggers the 
initial transition at the topmost level of the state machine (and is the 
only kind of trigger that may be applied to an initial transition)." 

Thus, a "creation event" MUST be a call event. 

o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

Recommendation: 

1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

  
2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

3. Change well-formedness rule [5] to exclude the top initial pseudo-state. 

4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature. 

5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.


 


Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
April 4, 2002: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 5593: Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace ) (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents) 

The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter ! 

2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of «accessable» objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by «friend» Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors («contents» instead of «acessable»). 

Resolution: Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
August 25, 2002: received issue
December 28, 2004: moved to UML2 RTF
October 27, 2008: closed issue

Issue 5794: Designates a Generalization (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The text: 

Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement. 

disagrees in plurality with the * cardinality of the generalization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

Resolution: closed no change
Revised Text:
Actions taken:
December 15, 2002: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:
This pertains to a part of the UML 1.4 spec which is completely changed in UML 2.0.


Issue 5804: 2.5.2.27 ModelElement (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The text "deploymentLocation The set of locations may differ. Often it is more restrictive on the child." has no corresponding association in any diagram. The closest match is documented in 2.5.2.12 Component on pages 2-31 and 2-32. If this is the non-inherited feature discussed on page 2-44 is it not redundant and doesn't it cloud the meaning of the feature?

Resolution: closed no change
Revised Text:
Actions taken:
December 19, 2002: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:
The referenced section 2.5.2.27 is from the UML 1.5 specification (formal/03-03-01,
page 2-43). The reference to deploymentLocation was not carried forward into UML 2.0.
In UML 2.0, “deploymentLocation” is a String attribute of DeploymentSpecification
(formal/05-07-04, section 10.3.5, page 199).


Issue 5886: behaviour of the shallow history state and deep history state (uml2-rtf)

Click
here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Significant
Summary:
In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state. 

Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
March 21, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 5896: logic upperbound is the same as the lower bound. (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) ============================================= 

according to the logic upperbound is the same as the lower bound. 

should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?

Resolution: closed no change
Revised Text:
Actions taken:
April 4, 2003: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:
This pertains to an area in previous versions of UML that has completely changed in
UML 2.0. The issue is no longer relevant.


Issue 5907: formal/03-03-01 : Omission of definition of Class "Action" (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I believe I found an omission from the UML 1.5 Specification formal/03-03-01:


  p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"


  In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".


  p. Index-1 cites "Action" p 2-103.


  p. 2-103 has no mention of "Action".


  The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.


My question is what is definition of the "Action" Class in Fig. 2-18?

Resolution: closed no change
Revised Text:
Actions taken:
April 21, 2003: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:
UML 2 Revision Task Force Disposition: Closed, no change
OMG Issue No: 5907
Document ptc/06-01-01 Page 621
OMG Issue No: 5907
Title: Formal/03-03-01: Omission of Definition of Class “Action”
Source:
Kurt Stephens, ks@kurtstephens.com
Summary:
I believe I found an omission from the UML 1.5 Specification formal/03-03-01:
• p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common
Behavior)"
•
In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class
"Action".
•
p. Index-1 cites "Action" p 2-103.
• p. 2-103 has no mention of "Action".
• The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as
would be alphabetized.
My question is what is definition of the "Action" Class in Fig. 2-18?
Discussion:
This pertains to parts of an older version of the UML spec (1.5) which has completely
changed in UML 2.0. This issue is no longer relevant.
Disposition: Closed, no change


Issue 5977: saying {nonunique} on one end of a binary association is meaningless (uml2-rtf)

Click
here for this issue's archive.
Source: Microsoft (Mr. Don Baisley, don.baisley(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:
Also, saying {nonunique} on one end of a binary association is
meaningless by the current rules, because the other end remains {unique} by
default, so no duplicate links would be allowed

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
June 19, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6002: relationship should just be a cross-reference (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:
There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical. 

It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?

Resolution: closed no change
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
It was an explicit design decision to split off the Abstractions hierarchy from the part of
the Infrastructure that supports the UML and MOF modeling languages. The general idea
behind the Abstractions concepts is to provide a potentially useful “grab-bag” of
metamodeling patterns that might prove useful some day in as yet unknown modeling
languages. On the other hand, the Basic and Constructs packages are specifically
designed to support the MOF and UML languages. The separation is intended to ensure
that MOF and UML remain unaffected by the needs of future modeling languages.


Issue 6003: document appears to be inconsistent in how it handles concepts (uml2-rtf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Critical
Summary:
This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept. 

In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell. 

I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group. 

Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This issue relates to the old version of Infrastructure. In this case, there is clearly a
misunderstanding on part of the submitter about the architecture of the Infrastructure and
the semantics of package merge. Once these are understood, the issue disappears.
However, it is definitely the case that the introductory text describing the architecture and
the role of package merge are extremely unclear and need to be fixed. These will be dealt
with as part of the resolution to issue 6002.
Disposition: Closed, no change


Issue 6004: Relationship and DirectedRelationship in Core::Constructs (uml2-rtf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Minor
Summary:
There doesn't seem to be any value in the specialization of Relationship and DirectedRelationship in Core::Constructs from their definitions in Core::Abstractions::Relationships. The documentation clearly states that the specializations don't add anything to the either concept. In fact, it appears that this can be said for everything in the Core::Constructs Root Diagram. 

If this is the case, why do these specializations exist? The UML spec is big enough - there is no point in adding things that don't need to be there. If the goal is to merely create a single diagram that includes concepts and relationships that were previously spread across multiple diagrams, then why not simply create the diagram and have every contained concept refer to the package where it was originally defined? 

If there is a compelling reason for these specializations, then that reason needs to be spelled out in the spec - because it isn't obvious to me.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
See the resolutions to issue 6002 and 6003.
Disposition: Closed, no change


Issue 6005: cross-reference missing (uml2-rtf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Significant
Summary:
The reference to TypedElement in the Expressions diagram for Core::Constructs makes no cross-reference to the definition of TypedElement in Core::Abstractions::TypedElements or Core::Basic. 

Is it a reference to either of these or is it yet another definition of a concept with the same name?

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This is intentional because Abstractions and Basic are de-coupled from each other in the
latest version of the Infrastructure. This allows the two to evolve independently.
However, this is not explained very well (and is even incorrect) in the introduction to the
Infrastructure, which needs to be rewritten substantively to clarify how these things relate
to each other. That will be handled as part of the resolution to issue 6002.
Disposition: Closed, no change


Issue 6006: Classes diagram of the Core::Constructs package (uml2-rtf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Significant
Summary:
In the Classes diagram of the Core::Constructs package, the references to StructuralFeature, Relationship, Type, and Classifier have no cross-reference to the package where they were originally defined, whereas other concepts in this diagram do. It is clear from the fact that some of these concepts are involved in derived roles or relationships, that they MUST have been defined somewhere else. 

The document needs to be fixed so that it is self consistent and so that proper cross-references are indicated.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
See the resolutions to issues 6005, 6003, and 6002.
Disposition: Closed, no change


Issue 6071: Conditional Node and Loop Node notation missing (uml2-rtf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
In 03-07-06 there was notation for conditional nodes and loop nodes for activities. These are missing in 03-08-02. Makes taking the certification difficult

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 21, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6082: Suspension Region (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Enhancement
Severity: Minor
Summary:
“Supspension region” is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call. 

This has been flagged as a potential FTF issue before. 


Resolution: Discussion: This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision. Disposition: ClosedOutOfScope
Revised Text:
Actions taken:
August 29, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
This is a concept that highlights a syntactic requirement. Often users think that
suspension is always the case between call and reply, but since lifelines may be
decomposed into independent sub-parts, this is not necessarily the case. That is why it is
needed to clarify a synchronization situation. Still it is a new concept, and cannot be
considered critical for the use of Interactions.


Issue 6083: More examples (uml2-rtf)

Click
here for this issue's archive.
Source: CSC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Clarification
Severity: Minor
Summary:
The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1) 


Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received issue

Discussion:
This is indeed a reasonable request and additional examples would indeed be helpful.
However, since it is not a critical issue or an inconsistency in the spec itself, the issue is
deferred to an RTF.


Issue 6086: More explanation needed on Figure 339 (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6088: Parameterization of lifelines (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Enhancement
Severity: Significant
Summary:
In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical. 

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received issue

Discussion:
This is a feature enhancement and, therefore, outside of the scope of an FTF,
whose purpose is to fix inconsistencies and add clarifications. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6111: Reentrancy 1 (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
How is the effect if isReentrant achieved for actions other than call
actions?  isReentrant is only on behaviors.  Perhaps it should also be
available on actions and operations

Resolution: The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default. In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.
Revised Text: In Figure 12.2, add the attribute declaration "isLocallyReentrant: Boolean = false" inside the class box for Action. In Subclause 12.3.2 Action, under Attributes, add at the beginning: Package FundamentalActivities · isLocallyReentrant: Boolean If true, the action can begin a new, concurrent execution, even if there is already another execution of the action ongoing. If false, the action cannot begin a new execution until any previous execution has completed. The default is false. Under Semantics, replace the paragraph If a behavior is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a nonreentrant behavior does not start the behavior when the behavior is already executing. In this case, control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise. An invocation of a reentrant behavior will start a new execution of the behavior with newly arrived tokens, even if the behavior is already executing from tokens arriving at the invocation earlier. with: If an action is not locally reentrant (isLocallyReentrant=false, the default), then no more than one execution of it will exist at any given time within the context of a single execution of the containing activity. Even if the action would normally begin an execution according to the rules above, it will not start a new execution if there is already one ongoing within the same activity execution. In this case, the action simply does not accept any tokens offered to it until its ongoing execution has finished. At this point, if the required tokens are still available, the action may accept the offers and begin a new execution. On the other hand, if an action is locally reentrant (isLocallyReentrant=true), then it will begin a new execution any time the rules above allow it, even if there are one or more executions already going within the same activity execution. This means that there may be, within any one execution of the containing activity, more than one concurrent execution of the action ongoing at any given time. A call action for a non-reentrant behavior will also act locally non-reentrant, whatever the value of the isLocallyReentrant property for the action. Moreover, an invocation action for a non-reentrant behavior will not execute if there is any currently running execution for the behavior, whether invoked by this action or any other (see "CallAction" (from Basic Actions) on page xxx). In Subclause 11.3.8, under Semantics, after the first paragraph, add: If the behavior invoked by a call action is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a non-reentrant behavior does not start the behavior when the behavior is already executing. An invocation of a reentrant behavior may start a new execution of the behavior when offered the required tokens, even if the behavior is already executing. However, it will not invoke the behavior if there is an ongoing behavior execution invocated by the same action within the same activity execution, and the action has isLocallyReentrant=false (see "Action" (from CompleteActivities, FundamentalActivities, StructuredActivities) on page xxx). Disposition: Resolved
Actions taken:
August 30, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
A resolution of this issue has to await further clarification of the activity view of
reentrancy. This issue should be resolved in a manner consistent with activities, if
possible. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6114: State extension (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
State should be an extension of type rather than object node.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:
This requires more discussion on what should be specifiable as a type, and
layering the state machine model (issue 7555). Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6126: Target pin notation (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
On CallOperationAction, etc, how do you tell graphically which pin is
the target?

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:
This is does not affect usage or implementability enough for the FTF to address. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6137: Promote local conditions to ExecutableNode (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Promote local precondition to ExecutableNode.  There might be other
associations on Action that should be at ExecutableNode

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:
It may be that local preconditions should apply to object nodes also. Postpone
for discussion in RTF. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6150: Notation for method (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide a notation for a behavior used as a method of an operation

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:
OMG Issue No: 6150
NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
It is probably worthwhile to define a graphical syntax representing
BehavioralFeature.method. This could take the form of either
• showing the name of the instance of Behavior which is the method along in the
compartment where the behavioral feature is exhibited
• having a graphical link between the behavioral feature and a symbol representing
the behavior instance (similar to how it is shown that a CollaborationOccurrence
represents a Classifier (see Figure 106).
The downside of either is that users typically don’t think of the behavioral feature and the
behavior as separate things and usually would not dream of naming the behavior (of
course, this is not required). In particular, if the behavior is described by a body string a
convenient way of showing that body string with the behavioral feature would be desired.
Today tools typically use the property sheet for the behavioral feature to show the
associated behavior. There are already different vendor specific solutions for some
behaviors as methods. We need to gain better experience before standardizing as solution.
Disposition: Deferred                                                                                                                                                                                                       It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either . showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited . having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don.t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. The situation has not changed from the discussion in 2003. There have been no new developments in tool specific notations for method, nor have there been further requests for such notation. However, the issue seems still relevant. Therefore, the suggestion is to defer further. Revised Text: N/A Disposition: Deferred


Issue 6176: UML 2 Super/Metamodel::Constructs/owningComment (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Constructs association owningCommet:Element[0..1] c--> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c--> ownedCommet:Comment[0..*] as defined in Kernel/Root. 

Resolution: see below
Revised Text: The issue identifies as real problem in the Rose model InfrastructureLibrary.cat file. The offending "owningComment" association end name appears only in this file (most recent version: ftp://ftp.omg.org/pub/UML_2.0_superstructure-ftf/_UML2 Super.MDL.040711.zip) and does not appear in either the UML 2.0 Superstructure FAS (ptc/03-08-02) or the UML 2.0 Infrastructure FAS (ptc/03-09-15). Proposed Resolution: In the InfrastructureLibrary.cat file, change the name of the association end InfrastructureLibrary::Core::Abstractions::Comments::owningComment to InfrastructureLibrary::Core::Abstractions::Comments::owningElement. Revised Text: Editor’s note: This was fixed in the metamodel – however, it also required a change to the diagram in figure 9.10 In the InfrastructureLibrary.cat file, change the name of the association end InfrastructureLibrary::Core::Abstractions::Comments::owningComment to InfrastructureLibrary::Core::Abstractions::Comments::owningElement.
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
The issue identifies as real problem in the Rose model InfrastructureLibrary.cat file. The
offending "owningComment" association end name appears only in this file (most recent
version: ftp://ftp.omg.org/pub/UML_2.0_superstructure-ftf/_UML2-Super.MDL.040711.zip) and does
not appear in either the UML 2.0 Superstructure FAS (ptc/03-08-02) or the UML 2.0
Infrastructure FAS (ptc/03-09-15).
Resolution: In the InfrastructureLibrary.cat file, change the name of the association end
InfrastructureLibrary::Core::Abstractions::Comments::owningComment to
InfrastructureLibrary::Core::Abstractions::Comments::owningElement.


Issue 6187: UML 2 Super/Metamodel::Super/missing merge (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
No packages from Abstractions are currently merged into any compliance level pending
reorganization of Abstractions.
Disposition: Closed, no change


Issue 6194: UML 2 Super/Package merge/redefinitions issue - lost association ends (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine {redefines ownedBehavior} <--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
Property ownedStateMachine:StateMachine has been removed as a result of other issue
resolution, so this particular problem no longer exists. Other instances of lost association
ends resulting from package merge are handled in their own specific issue.
Disposition: Closed, no change


Issue 6197: UML 2 Super/Metamodel::Kernel/missing merges (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
No packages from Abstractions are currently merged into any compliance level pending
reorganization of Abstractions.
Disposition: Closed, no change


Issue 6200: UML 2 Super/Metamodel/redefinition and substitutability (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
September 7, 2003: received issue

Discussion:
Indeed. However, this is a serious and contentious theoretical issue and it’s resolution is
beyond the scope of the FTF. Fortunately, the specific issue with state machines has been
eliminated by the resolution to issue 6185. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6201: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
opposite =
   if owningAssociation->empty() and association.memberEnd->size() = 2 then
       let otherEnd = (association.memberEnd - self)->any() in
           if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
   else Set {}
   endif 

Resolution: See issue 8451 for disposition
Revised Text:
Actions taken:
September 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 6216: UML 2 Super/pg.75/kinds of changeability (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 75: StructuralFeature::isReadOnly 
Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values: 

Changeable (unrestricted) 

readOnly (no changes after initialization) 

[Note that the meaning and semantics of  "initialization" are completely undefined, so this isn't all that useful.] 

The following additional choices were available in UML1: 

CreateOnly (add a set any time after initialization but no further changes) 

addOnly (may add members to the set but not change or remove any) 

Both of these occur in practice often enough. 


Resolution: see above
Revised Text: Infrastructure Spec: Remove section 9.2.1 ChangeabilityKind. It s not part of the UML2 metamodel and is not referenced anywhere else in the InfrastructureLibrary or Superstructure specification.
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
The only subclass of abstract metaclass StructuralFeature in UML2 is Property which
already has ownedAttribute isReadOnly: Boolean. This property comes from package
Basic and is part of the alignment with MOF2.
MOF2 also has a number of rules about initialization of read-only properties that may
make the distinctions between changeable and readOnly unnecessary. It is not clear what
the value for createOnly would be over having a default for a read-only property. And
addOnly semantics may be better handled by the containing class rather than the feature
itself.


Issue 6262: UML 2 Super / Templates / TemplateParameter not named (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
TemplateParameters do not appear to be namable.  They inherit from Element and not NamedElement.  In UML 1.5 they inherited from ModelElement (i.e. were namable).  They need to be named to be referred to in the implementation of the template. 

Resolution:
Revised Text:
Actions taken:
September 23, 2003: received issue
August 23, 2006: closed issue

Discussion:
TemplateParameters do not appear to be namable. They inherit from Element and not
NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable).
They need to be named to be referred to in the implementation of the temp late.
Discussion:
The real problem is not the one stated above. This is because there is a mistaken
assumption here that the metamodel element called TemplateParameter models the actual
parameter. Instead, it is merely a “pointer” to the parameter. A more precise name might
be to call it ParameterReference or ParameterSelector. But, such a change would require
a very careful examination of the very, very many references to the term “template
parameter” to distinguish whether it refers to the actual parameter or to the reference to
the parameter. This is a significant change that, arguably, is out of scope of this FTF,
since it is not something that is broken or inconsistent in the spec. The metamodel element called TemplateParameter is merely a “pointer” to some named
element owned by the templateable element (e.g., an attribute) that has been designated
as a template parameter. Therefore, there is no need for TemplateParamter to be a named
element, since it is never referenced.
Disposition: Closed, no change


Issue 6275: raisedException (uml2-rtf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation.  Operation inherits from BehavioralFeature as well.

 

I believe this violates a well-formedness rule that all structural features must be distinguishable.


Resolution: See issue 8461 for disposition
Revised Text:
Actions taken:
September 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
The spec explicitly states that such redefinitions need to be made explicitly. This is
related to the resolution to more general issue 8461. Any resolution to this issue will be
resolved as part of the resolution to 8461.


Issue 6346: Activity OCL (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Revision
Severity: Significant
Summary:
Not all the constraints in the Activities section have corresponding OCL
specifications. These should be added

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received issue

Discussion:
This is does not affect usage or implementability enough for the FTF to address,
and is a very large and time-consuming change. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6353: Deployment a dependency? (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
If Artifact and Node are classifiers, why is deployment a dependency?
Then runtime artifacts cannot be deployed to runtime nodes.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received issue

Discussion:
Run-time artifacts can be deployed to runtime models, but the type consistency
is not formally guaranteed (that is, if Artifact A is deployed to Node B, then
instances of A are deployed to instances of B, but there is no ‘instantiation’ of the
deployment relationship).
In order to formalize the instantiation aspect, Deployment would need to be
modeled as a subtype of Association. This solution has been touched on in the
submission process as a simplification and tightening of the model but requires
some time to work out and bed down, as it would be a non-trivial change. Hence,
it would be best tackled in an RTF process. Note (if this solution direction is
accepted) that the notation would need to be changed to not use a dependency,
but rather an association (possibly with keyword <<deploy>>).


Issue 6368: Join nodes that destroy tokens (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Would be useful if join nodes optionally destroyed tokens not accepted,
especially when using join expressions.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6372: Notes versus curly braces (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:
Why do decision input behaviors use the note notation and join
specification use curly braces?

Resolution: A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and"). Revised Text: None Disposition: Closed, no Change
Revised Text:
Actions taken:
October 20, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
This is does not affect usage or implementability enough for the FTF to address,
and requires too many changes. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6389: Syntax of names (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Issue:  The UML infrastructure specification does not specify the syntax for names.  This prevents model interchange.


Proposal:  Specify the syntax for the string in Name.  At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.


Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.


[After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job.  Or, in any event, get us started.]

Resolution:
Revised Text:
Actions taken:
October 22, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
The name of a metaclass is captured in a MOF String, which in XMI is enclosed in
quotation marks. Therefore, there is no problem with model interchange here.
The reason there are no syntax restrictions on names is that it provides latitude to support
different naming conventions used in different contexts and languages. Restricting this
could prove to be an impediment to the use of UML in situations that have their own
idiosyncratic rules for names.
Disposition: Closed, no change


Issue 6395: UML 2 Super / State machines / Transition triggers cannot be redefined (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6398: UML 2 Super / Kernel features / cannot exclude superclass properties (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled. 

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
August 23, 2006: closed issue

Discussion:
This may be the case, but modifying this aspect of UML exceeds the bounds of FTF
scope. Excluding inherited properties makes the meaning of specialization/generalization
unpredictable and violates a common invariant of object-oriented systems. Generalization
is not always the best way to model relationships between classes, and the desire to
redefine or remove inherited properties is often a good indication that delegation should
be used instead. Delegation is especially useful in situations where classes need to be
decoupled for change management or other reasons.
Disposition: Closed, no change


Issue 6405: UML 2 super / Dependencies / improper subsetting? (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty... 

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Resolution:
This is already resolved in the UML 2.2 specification.
Revised Text:
None.
Disposition:	Closed No Change


Issue 6409: UML 2 Super/Interactions/missing OCL constraints (uml2-rtf)

Click
here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:
Not all the constraints in the Interactions section (14.3). They should  be added

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 3, 2003: received issue

Discussion:
These constraints should definitely be added. This should be done in an RTF. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6422: Section 9.3.3 (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration.  I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section.  In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

Resolution: Original discussion: The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4. New comments (March 2009): This issue dates back to 2003. I propose we close it on the grounds of cost/benefit. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
November 4, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4. Disposition: Deferred


Issue 6423: Section 9.3.4 page 161, Presentation Option (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
the keyword «represents»." and the accompanying example are confusing.  Please clarify what this presentation option is trying to accomplish.

Resolution: see above
Revised Text: In Section 9.3.4., delete subsection “Presentation Option”.
Actions taken:
November 4, 2003: received issue
August 23, 2006: closed issue

Discussion:
I do agree with the submitter that this presentation option could be confusing. It has been
taken over from UML 1.4 for reasons of backwards compatibility. While I have not seen
any examples of actual use, it would be unwise to change this further in a backwards
incompatible way without being able to point to practical experience of the use of this
construct. If no practical experience can be found, it might be best to delete this
presentation option.


Issue 6430: UML2 super/ad-03-04-01/Derived attributes and associations (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue:  There are many places where the specification indicates that an
attribute or association is derived, but does not state how it is derived;
that is, the specification does not state, in English or in OCL, how to
compute the derivation.


Recommendation: Specify, in English and OCL, how to compute the derivations
of all derived attributes and associations.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 4, 2003: received issue

Discussion:
These specifications should definitely be added. This should be done in an RTF. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6433: 03-04-01 Chap 2 p. 112/Components: Different ways to wire components (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
paragraph says: “A component has a number of provided and required
Interfaces, that form the basis for wiring components together, either using
Dependencies, or by using Connectors.”   Is this really an either or choice?
What is the real semantic distinction?  And what is the semantic distinction
between wiring via connectors without ports vs. wiring via connectors with
ports?


Recommendation: Clearly specify the semantic distinctions among the three
ways of wiring components together:


1) Via Dependencies
2) Via Connectors without Ports
3) Via Connectors with Ports.


If there are no semantic distinctions--that is, if the distinctions are
purely mechanical--then the specification should probably changed such that
there is one way to wire components together.

Resolution: Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired. We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.
Revised Text: In 8.3.1 Semantics, replace: "The wiring between components in a system or other context can be structurally defined by using dependencies between component interfaces (typically on structure diagrams). Optionally, a more detailed specification of the structural collaboration can be made using parts and connectors in composite structures, to specify the role or instance level collaboration between components (See Clause Composite Structures)." By: "The wiring between components in a system or other context can be structurally defined by using dependencies between compatible simple Ports, or between Usages and matching InterfaceRealizations that are represented by sockets and lollipops on Components on component diagrams. Creating a wiring Dependency between a Usage and a matching InterfaceRealization, or between compatible simple Ports, means that there may be some additional information, such as performance requirements, transport bindings, or other policies that determine that the interface is realized in a way that is suitable for consumption by the depending Component. Such additional information could be captured in a profile by means of stereotypes." Also delete the following sentence: "The mapping between external and internal view is by means of dependencies (on structure diagrams), or delegation connectors to internal parts (on composite structure diagrams)." and replace it by "Dependencies on the external view provide a convenient overview of what may happen in the internal view; they do not prescribe what must happen." Delete the word "Again" from the following sentence that starts "Again, more …" and capitalize "More …" Insert the following text before figure 8.14: "When a Dependency is wired from a Usage to an InterfaceRealization, the dependency arrow should be shown joining the socket to the lollipop. A Dependency may be wired from a simple Port with a required interface to a simple Port to a provided interface, in which case it is a notational option to show the dependency arrow joining the socket to the lollipop. A Dependency may be shown from a simple Port to an internal realizing Classifier to indicate that the interface provided or required by the Port is in fact provided or required by the Dependency's supplier. All of these options are shown in Figure 8.14" Replace figure 8.14 with this: Delete the following paragraph below 8.15: "The wiring of components can be represented on structure diagrams by means of classifiers and dependencies between them (Note: the ball-and-socket notation from Figure 8.15 may be used as a notation option for dependency based wiring). On composite structure diagrams, detailed wiring can be performed at the role or instance level by defining parts and connectors." Disposition: Resolved
Actions taken:
November 4, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6441: Integration between behavioral "sublanguages": Interactions and Activities (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Although both Sequence Diagrams and Activity Diagrams have
added many advanced features in UML 2, these features appear to have been
added independently, so that they appear as two separate behavioral
languages. Consider improving the integration between them by supporting the
following:
a) Allow for an activity in an activity diagram to represent an invoked
operation in a message on a sequence diagram.
b) Allow for interaction diagram notations to be applied to activity
diagrams, such as the use of references, alternates, and gates.
c) Clarify that time and other constraints can be applied to an activity
diagram in a manner similar to how they are applied to sequence diagrams.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 6, 2003: received issue

Discussion:
This issue is part of a much larger discussion that cannot be handled by one working
group alone. In fact this issue has to be covered in face-to-face meetings resulting in a
commitment to unify the language even further. It is still an important topic and an
obvious desire for many of us for the future. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6444: Activity diagram problems (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: The following are some recommendations to improve Activity
diagrams for systems engineering applications:
a) Generalize pins so that they can be applied to control as well as data.
b) Clarify how activity diagrams can be used to represent continuous
behavior (e.g., streaming input).
c) Clarify how an object node to represent a role.

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
August 23, 2006: closed issue

Discussion:
This is too vaguely stated to act on. Part of item a) is covered in 6348. defer. From FTF: This is too vaguely stated to act on. Part of item a) is covered in 6348. defer
RTF: Could not obtain clarification from filer. The part of item a) referred to in the FTF
comment is that 6348 enabled pins to treat data as control (Pin.isControl) and allowing
control edges to be used with object nodes (ObjectNode.isControlType). Part of item b)
was addressed in FTF issue 6902, which added text to section 6.3 explaining that UML is
for discrete modeling, but it “does not dictate the amount of time between events, which
can be as small as needed by the application, for example, when simulating continuous
behaviors.”
Disposition: Closed, no change


Issue 6445: Clarification of use case semantics (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Use cases and associated sequence and activity diagrams are
widely used by systems engineers to specify the functionality of the system,
and describe the interaction between the system and the actors. However,
there is much confusion regarding use case semantics. Consider the following
recommendations to clarify use case semantics:
a) Establish an explicit representation to depict the relationship between a
use case and its realization as a sequence diagram, activity diagram, etc.
In addition, allow for a similar representation to show the relationship
between an included/extended use case, and the interaction fragments which
realize the included/extended use case.
b) Clarify the relationship between a use case (solid oval) and a
collaboration (dashed oval), and determine whether they can represent the
same or a similar concept.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 6, 2003: received issue

Discussion:
UML already supports this capability since it allows a classifier (in this case a use case)
to have associated a number of behaviors that are in some ways related to the classifier
(e.g., they may represent realizations of the classifier in some way, or illustrations of
specific executions related to the classifier, etc.) However, the proposed resolutions are
asking for a specialization of these general (meta)associations that would have special
realization semantics. Such semantics might prove to be tricky to define in the case of use
cases, and require some study (i.e., what does it mean for a behavior to “realize” a use
case? Is it just an illustration of one possible realization or is it more general?) These are,
in effect, requirements for new modeling features and, therefore, fall outside the scope of
an FTF or RTF. This should be the subject of a separate RFP.


Issue 6446: Clarification of Information Flow semantics (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: Consider the following recommendations to improve Information
Flow semantics:
b) Allow Information Flow to be specialized and decomposed using
aggregation.
c) Allow Information Flow between classifiers with ports and interfaces.
Make provisions for relating the information flow to a port, such that an
Information Flow can flow through a port.
d) Allow Information Flows between classifiers with object flows across
activity partitions.
e) Change the name from Information Flow to Item Flow (or something similar)
to allow for the flow of non-information, such as physical items specified
in systems engineering applications.

Resolution: see above
Revised Text: In section 17.2.1 InformationFlow – Constraints Change: 1] The sources and targets of the information flow can only be of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link). into: 1] The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link).
Actions taken:
November 6, 2003: received issue
August 23, 2006: closed issue

Discussion:
These are very good suggestions but such changes clearly qualify as new
features – since they extend the current definition of Information Flows – and are,
therefore, out of scope of the FTF.  Resolution:
b) needs an entire new specification. The combination of these new mechanisms with the
relations between targets & sources, the association Information Items is not at all
defined. That door is dangerous to open now. I suggest to reject this one.
Regarding c): Information flow are explicitly allowed between ports and interfaces. (may
be the issue is outdated)
d) OK, although I have never seen a dependency drawn between partitions. It also shows
an inconsistency in the spec that does not allow sources & target being ActivityNodes.
Regarding e) "Information" is purposely a very broad word that encompasses anything
we want to exchange between sources and targets. It does not prevent at all "physical
items": their circulation is also information.


Issue 6451: UML 2 Super / Dependency / ownership of dependencies (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted -- it makes no sense to have a dependency independently of the depending (source) element. 

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
Unfortunately, this recommended fix would not solve the problem since more than one
model element can be the source (client) of a Dependency. Since, in general, each source
element is equal to all the others, there is no basis for singling out one of them to be the
“owner”.
Disposition: Closed, no change


Issue 6452: UML 2 Super / Missing OCL constraints (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:
These constraints should definitely be added. This should be done in an RTF. defer Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6455: instantiations of Classifiers (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
7 and 14:  "An instance specification is a model element that represents an instance in a modeled system." [7.7.1]  There are no objects in a UML 2 model, but only models of objects, that is, instance specifications.  The instantiation of a UML class is not in the model, but in the modeled system.  At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution:  Abandon the idea that there are no objects in a model.  Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model.  Likewise for an association and its links, and so on.


This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.


It is consistent with the existence of power types in the language.


It is consistent with the MOF specification of meta-layers.


It removes the conflation of the type conformance and instatiation relationships with the representation relationship.  It reduces the meanings conflated into 'instance of' by one.



Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:
Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6456: Use 'represent' for the relationship of a model (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
"An instance specification is a model element that represents an instance in a modeled system." [7.7.1]  That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.


At the same time, a lifeline represents a connectable element. [14.2]


This is an example of a recurrent problem in the specification: model elements that represent other model elements.


At the same time, "attributes of a class are represented by instances of Propert[ies]..."


This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.


The theory of representation needs to be settled.  That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.


Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
August 23, 2006: closed issue

Discussion:
Indeed. It would be useful if the theory of representation was settled. However, this is a
deep issue that exceeds the scope of an F/RTF. Hence, it is better to defer this issue to a
subsequent revision of UML. The submitter is absolutely right and that more care should have been taken in the use of
this term and many others. Unfortunately, the problem is endemic in both the Infra and
Super specs (and, likely, many other OMG specs). A count reveals close to 500 uses of
the word “represent” or its derivatives scattered throughout the document. Each of these
would have to be examined and appropriate action taken. Of course, this would only
solve this particular case of loose terminology but not the overall problem. The FTF
punted this issue by deferring it. However, it is unrealistic to expect that any future RTF
will have the resources or the time to fix this particular problem, let alone the more
general problem.
What is really required is a set of OMG-wide style guidelines and, possibly, a glossary of
approved defined terms that should be used in writing all submissions related to
modeling. This is a problem that exceeds this particular specification and should be posed
as an issue to the OMG as a whole.
Furthermore, although the loose use of “represents” is confusing in certain spots, in most
cases, it is not a problem that will lead to errors in tool implementation or significant
misinterpretation by readers. Therefore, it is proposed to close this issue in the context of
this specification. Disposition: Closed, no change


Issue 6460: UML 2 Issue: definition of navigability (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
There is no definition for navigability or navigation in the Spec. Other
concepts of similar importance, such as visibility, multiplicity, etc., are
defined in the Spec, so it is not clear why it should be assumed that this
concept does not require a definition.

PROPOSED SOLUTION
Add definition in Section 4 (Terms and definitions): The navigability of a
binary association specifies the ability of an instance of the source
classifier to access the instances of the target classifier by means of the
association instances (links) that connect them. Navigability is closely
related to the possibility of sending messages through associations (a
message cannot be sent through an association instance against its
navigability, that is, navigability is required for sending messages through
associations), but they remain nonetheless different concepts.

Resolution: Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
October 27, 2008: closed issue

Issue 6462: UML 2 Issue: AssociationEnd (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
In UML 1 the navigability of an association end was specified by the
meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
meta-attribute dissapears, and AssociationEnd is substituted by Property. We
know whether an association end is navigable by the following rule: if the
property is owned by a class, it represents a navigable end; if the property
is owned by an association, it represents a non-navigable end (see
Superstructure, p. 89). However, references to old metaclass AssociationEnd
and old meta-attribute isNavigable still appear in the Spec in several
places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
245). 

PROPOSED SOLUTION
Add derived meta-attribute /isNavigable to metaclass Property.
Eliminate references to AssociationEnd.

Resolution: Resolution: As of UML 2.2, in the Superstructure (ptc/08-05-05), this has been mostly corrected. isNavigable is now an additional operation on Property. However, some OCL constraints in AssociationClass and ReadLinkAction still referemce AssociationEnd. There is also still one reference to AssociationEnd in the Infrastructure text (ptc/ 08-05-04, Subclause 8.1).
Revised Text: In the UML 2.2 Superstructure specification (ptc/08-05-05): In Subclause 7.3.4 (AssociationClass), Constraint [1] text, change "AssociationEnds" to association ends. In Subclause 11.3.33 (ReadLinkAction), in the OCL for Constraints [2] to [5], change "AssociationEnd" to "Property". In the UML 2.2 Infrastructure specification (ptc/08-05-04), Subclause 8.1, the last sentence of the last paragraph, change "AssociationEnd" to "Property".
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6463: UML 2 Issue: Message notation (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
According to Superstructure, p. 430, the notation for messages in
interaction diagrams is as follows (we put assumptions between parenthesis):

asynchronous message - (solid line) open arrowhead
synchronous message - (solid line) filled arrowhead
reply message - dashed line (filled or open arrowhead?)
object creation - dashed line open arrowhead

However, the example given in Figure 333, p. 414, shows a different
notation:

asynchronous message - solid line open arrowhead (not shown in this diagram,
but in others)
synchronous message - solid line filled arrowhead
reply message - dashed line OPEN arrowhead
object creation - SOLID line open arrowhead

Another confusing aspect of the notation is that in a reply message, which
is not a true message, the message name is the name of the operation invoked
on the callee (same as in the corresponding synchronous call), but it
suggests instead that there is an operation with this name in the caller. In
Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
operation named foo in class C1, which is wrong: foo is defined in C2, not
in C1. It would make more sense to label a reply message with the name of
the value returned.

PROPOSED SOLUTION
The simplest solution would be to fix Figure 333 using a dashed arrow to
represent object creation, although this would yield the same notation for
object creation and reply message. Therefore, beyond this simplest solution,
we propose something more advanced: First, state explicitly the notation for
all kinds of messages, leaving no place for assumptions. Second, use a
filled arrowhead for reply messages, since this emphasizes the conceptual
proximity to the synchronous message it is a reply from. Third, use the
notation for object creation also for object deletion, which currently is
not mentioned. That is:

asynchronous message - SOLID LINE open arrowhead
synchronous message - SOLID LINE filled arrowhead
reply message - dashed line FILLED ARROWHEAD
object creation OR DELETION - dashed line open arrowhead

Or better, simply drop object creation as an special kind of message. Object
creation (and deletion) was not considered a special kind of message in UML
1, and it is not at all clear why it should be in UML 2. Probably, an object
creation is either synchronous or asynchronous, but not "something else" in
the same meta-specialization row. In fact, the constraints and semantics of
Message (Superstructure, p. 429) do not consider object creation as
messages: "The signature must either refer an Operation (...) or a Signal",
"A Message reflects either an Operation call (...) or a sending and
reception of a Signal". Neither does the meta-attribute Message.messageSort,
which has the following permitted values: synchCall, synchSignal,
asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
mean? The "sorts" of message are not defined in the Spec. Although calls are
considered in other places to be either synchronous or asynchronous, signals
are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
and 395), therefore at least synchSignal is banned.

Finally, we also propose to label reply messages with the name of the value
returned by the operation call, not the operation name itself. In Figure
333, this would leave the replies foo(_) and doit(_) without label, and the
last reply would be labeled simply as "x".

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
August 23, 2006: closed issue

Discussion:
We have here 3 different problems:
1. There is an error in the illustration (partly due to Visio problems)
2. Notation needs to be fairly backward compatible
3. Notation needs to be fairly consistent with its semantics
The first problem is easily fixed.
The two latter problems are potentially in conflict. Here are the individual problems:
1. Create and reply messages use the same notation
a. This is true, but it does not seem to trouble users of these constructs  UML 2 Revision Task Force Disposition: Resolved
OMG Issue No: 6463
Document ptc/06-01-01 Page 44
b. They are distinguishable as the create message arrowhead always ends at
the head of a new lifeline. That is never the case for any other message.
2. Reply message uses open arrowhead even though it is the reply of a synchronous
call.
a. Again this does not seem to bother users, but filled arrowhead would be
preferable, but not backward compatible.
3. Textual notation for reply messages
a. The current notation does include what is needed, and the suggested
changes fail to address what is needed. In the example we have on the last
reply message “x=bar(_):15” and this means the following:
i. “x=” tells where the value of the reply should be stored. x is an
attribute of the lifeline receiving the reply.
ii. “bar” is the name of the operation and it is true that this may be
redundant if we demand always to use execution occurrences to tie
call and reply, but in fact we do not require this. It seems
reasonable to indicate the name of the operation called to obtain
the result.
iii. “(_)” means that there is one parameter and it is not a return
parameter and is therefore insignificant at the reply. There may
have been return parameters and we would have needed this
parenthesis.
iv. “:15” gives the value of the operation returned. Since sequence
diagrams describe very concrete runs, the returned value is
important.
4. The create, delete and reply messages are not properly coded in the metamodel
a. this is unfortunately the case and should be corrected.
Conclusion: We do not do any changes of the notation, mainly because confusion is not
so high and it is backwards compatible. We need to correct the figure and the coding of
the special messages.
Revised Text:
Add to the enumeration of MessageSort the following items:
• createMessage – the message designating the creation of another lifeline object
• deleteMessage – the message designating the termination of another lifeline
• reply – the message is a reply message to an operation call   


Issue 6464: UML 2 Issue: isUnique (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
"When one or more ends of the association have isUnique=false, it is
possible to have several links associating the same set of instances."
(Superstructure, p. 81)

As Pierre-Alain Muller demonstrated in an informal conversation with Bran
Selic during a lunch in San Francisco in the last UML Conference (I also was
taking part in that conversation), isUnique must have the same value for all
ends in an association. 

This has implications, for example, for the property strings that can be
placed near the association ends ({ordered}, {bag}, {seq}). According to the
table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
the opposite end must be a Set or an OrderedSet, too; and if one end is a
Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

PROPOSED SOLUTION
Explain this in the Spec.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6466: UML 2 Issue: Qualified pathnames (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
The notation for qualified names is double-colon ('::'). However, the Spec
always and everywhere uses a different notation: instead of
"Kernel::Comment", "Comment (from Kernel)". 

PROPOSED SOLUTION
Use the standard notation for qualified names.


Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6470: Section 7.11.2 Association (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
What is the sematics of an association with neither end navigable? Provide an example of when this might be used. (C to D page 85).

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6487: Conditions for parameter sets (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Selection behavior on object nodes should be changed to allow execution
at insertion time, keeping the queue

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:
This issue should be titled “Selection behavior”..
Requires more discussio n on how to express sorting procedures in the model. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6489: Ports in Protocol State Machines (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Protocol machines should not have ports in them.  It should be an
extension in the ports package.  Otherwise there is a backwards
dependency onto composite structure.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:
Statemachines already depend on ports via triggers, so the proposed change will not
remove the dependency. Furthermore, creating a dependency from composite structures
to statemachines would create a more serious layering problem. Therefore, resolving this
dependency requires a non-trivial restructuring that shall be done by an RTF at this point.


Issue 6492: ptc-03-09-15/Non-navigable ends with no role names nor multiplicities (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: It appears that associations with neither end names nor
multiplicities on non-navigable ends are used in parts of the UML Core that
are defined via CMOF.  See, for example, section 9.9, figure 35, p. 62, for
example.  I understand that for elements defined via EMOF, this signifies a
simple property.  But is it appropriate for elements defined with CMOF.


Recommendation: Either correct this by adding multiplicities and end names
or explain in the specification why it is alright to omit them in these
cases

Resolution: The meaning of this convention should be explained in the document.
Revised Text: OMG Issue No: 6492 Title: ptc-03-09-15/Non-navigable Ends with No Role Names Nor David Frankel Consulting (Mr. David S. Frankel, df@davidfrankelconsulting.com) Summary: Issue: It appears that associations with neither end names nor multiplicities on non-navigable ends are used in parts of the UML Core that are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for example. I understand that for elements defined via EMOF, this signifies a simple property. But is it appropriate for elements defined with CMOF? Recommendation: Either correct this by adding multiplicities and end names or explain in the specification why it is alright to omit them in these cases Resolution: The meaning of this convention should be explained in the document. Revised Text: In the Superstructure document, add to section 6.5.2 on page 16, as the second last bullet of the list, the following item: • If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints – although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) • Associations that are not explicitly named, are given names that are constructed according to the following production rule: “A_” <association-end-name1> “_” <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. In the Infrastructure document, add to section 6.3.1 on page 6, as the second last bullet of the list, the following item: • If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints – although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) OMG Issue No: 6492 Associations that are not explicitly named, are given names that are constructed according to the following production rule: “A_” <association-end-name1> “_” <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. Disposition: Resolved
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 6493: ptc-03-09-15/Constructs::Class superClass property (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Constructs::Class has a superClass property that redefines general,
which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
Constructs::Class also inherits from Basic::Class, which has superClass as a
property (section 10.2, 66, p. 97).  What does this mean?  Is this a bug?
Is it something correct having to do with package merge?


Recommendation: Determine whether this is intended or an oversight.  If it
is an oversight, correct it.  If not, explain the meaning of having these
both of these properties.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This is not a problem, since the rules of package merge unify these two properties as
defined in rule 2 of the general transformation rules of package merge (see page 118 of
ptc/04-10-02)
Disposition: Closed, no change


Issue 6495: ptc-03-09-15/Separate classification and generalization in Core::Basic (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: One of the main requirements for a core that can be reused by CWM
hinges on whether it is possible to reuse the abstract syntax that supports
classification and supports having properties (or features), without pulling
in generalization constructs.  U2P’s Core::Basic package, upon which EMOF is
based, does not appear to adequately separate these concerns.


The most abstract level of Core::Basic's inheritance hierarchy at which the
ability to have properties appears is in the Class metaclass.  But Class
also carries the “baggage” of a definition of superclass.


The Core::Abstractions package does appear to adequately separate these
concerns.  It does so by defining a simple Classifier in the
Core::Abstractions::Classifiers package that supports features but not
generalization.  The Core::Abstractions::Super package defines another
Classifier metaclass that subclasses
Core::Abstractions::Classifiers::Classifier and adds support for
generalization.


Presumably, then, the intent is that CWM metamodels that support
classification and properties but not generalization can reuse
Core::Abstractions::Classifiers::Classifier.  However, Core::Basic does not
reuse either of these basic definitions of Classifier from
Core::Abstractions, and EMOF is based on Core::Basic.  Thus, if a CWM
metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
share a common definition of Classifier with EMOF.  That could mean that a
metamodel expressed solely via EMOF will not be able to be the source or
target in a unified approach to transformations.  This is not a problem for
CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
are based on Core::Abstractions.


Recommendation: Solving the problem for EMOF would require some refactoring
of Core::Basic to separate concerns between classification and
generalization.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6496: ptc-03-09-15/Relationships among Core packages (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: The superficial impression that Core::Abstractions is the lowest
layer in the U2P Core does not stand up under close examination.
Core::Basic is closer to being the fundamental layer because it uses none of
the new association modeling constructs (such as derived unions and subsets)
to define itself; but is not entirely so because it imports two packages
from Abstractions.


Recommendation: It would be worth considering whether the two packages that
Basic imports from Abstractions can be placed in Basic, so that Basic is
unambiguously the lowest layer in Core.  This would also make EMOF
unambiguously the lowest-—i.e. the most fundamental—-layer of MOF, since
EMOF is based on Core::Basic while CMOF is based on Core::Constructs.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Resolved by Issue 7956. Basic (and no other UML2 or MOF2 compliance level) no
longer merges anything from Abstractions. Figure 64 on page 91 of the Infrastructure
specification is simply a schematic diagram to show that model elements in Basic were
influenced and/or derived (by copy) from elements in Abstractions. But there is no longer
any connection between Basic and Abstractions.
Disposition: Closed, no change


Issue 6497: ptc-03-09-15/Need for examples to include instance models (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue and Recommendation: In general the specification of the Core would
benefit from instance diagrams accompanying example models, especially in
cases where there is significant change from UML 1.x.  An instance diagram
accompanying an example model would show how the model instantiates the
elements of metamodel.  This will contribute to a greater level of common
understanding among readers of the specification and thus will help ensure
interoperability.


For example, consider Figure 3-23 from the submission document and which
defines the abstract syntax for the elements of the
Core::Constructs::Constraints package.  Despite the existence of
accompanying explanatory text, the distinction between the Namespace that
owns a Constraint and the Namespace that provides the context for a
Constraint may be difficult for the reader to grasp completely.  Figures
3-24, 3-25, and 3-26 from the submission document, respectively, provide
example models.  An instance diagram for at least one of the examples that
shows how the elements of the example model instantiate elements of
Core::Constructs::Constraints would go a long way toward preventing
misunderstandings.  Such misunderstandings would compromise
interoperability, since there is a high probability (in my opinion) that
different implementers would render models to XMI differently.


This example is only one of many that I could cite from the submission where
examples *plus* associated instance diagrams would be beneficial.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6498: ptc-03-09-15/Explain the new association modeling constructs (uml2-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: The Core’s abstract syntax makes heavy use of new association
modeling constructs.  Two of them in particular may be unfamiliar to many
who read the submission:
·       Subsets
·       Derived unions


The submission provides only a brief explanation of these two new
constructs, which I quote below:


"A navigable property may be marked as a subset of another, as long as the
owner of the subsetting property is the same as or a specialization of the
owner of the subsetted property. In this case, the collection associated
with an
instance of the subsetting property must be included in (or the same as) the
collection associated with the corresponding instance of the subsetted
property.


A property may be marked as being a derived union. This means that the
collection of values denoted by the property in some context is derived by
being the strict union of all of the values denoted, in the same context, by
properties defined to subset it. If the property has a multiplicity upper
bound of 1, then this means that the values of
all the subsets must be null or the same."


Recommendation: Since these constructs are so heavily used to define the
Core itself, it would be useful for the submission to provide some overall
guidance on how to use them.  Providing rationale for why specific ones are
chosen in specific places in the definition of the Core would be an
effective way of disseminating understanding of these constructs and
understanding of the Core as well.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6500: Federated models - UML2 issue (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
When creating a complete environment for agreements and BCF we need 
to 
work with ModelElements, classes, package, models etc created and 
managed by many unrelated person and organisations. This means that 
we 
need to support loosely coupled models (federated models) where an 
association starts in one model (stored in doc A) and ends in another 
model (stored in document B).


This may mean that we need to add references to an external 
modelelement 
so the assoication that references "out" to external ME need to be 
annotated with for example UUID of remote modelelement, name of model 
where the remote/external model , physicial location of remote model 
(URL) etc.
We may also want to attach constraints to the remote modelement that 
restricts "incomming" associations.


The question is how are loosely coupled model handled in UML 2 ?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6501: Rose Model of UML 2.0 spec (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Class Diagram:Constructs/Packages in the Rose file shows the
nestedPackage/package association the spec shows
nestedPackage/nestingpackage


 


I believe the spec to be in error... 


 


I am not sure where to report this and or who keeps this model up to
date. Any recommendations would be appreciated


Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This problem was detected and resolved in the FTF.
Disposition: Closed, no change


Issue 6502: Multiplicity seems to be broken - UML2 Infra & Super (uml2-rtf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
The current Infastructure document defines it at page 54 as (line 
numbers have been added by me):
(1) multiplicity ::= multiplicity_range
(2) multiplicity_range ::= [lower '..'] upper
(3) lower ::= integer
(4) upper ::= unlimited_natural | '*'


But at page 56 (also page 20 of the Superstructure document which 
copies 
the definition) it says:


(5) multiplicity ::= multiplicty_range [{order_designator}]
(6) multiplicity_range ::= [lower '..'] upper
(7) lower ::= integer | value_specification
(8) upper ::= unlimited_natural | '*' | value_specification
(9) order_designator ::= ordered | unordered
(10) uniqueness_designator ::= unique | nonunique


There are several problems arising from this definition:


(P1) (9) and (10) are never used
(P2) Defining the lower bound as "integer" (according to page 142 of 
the 
  Infrastructure document) allows it to specify multiplicities with 
lower bounds *below* 0 (e.g. [-5..7], [-42..0])
(P3) (4) and (8) include the asterisk symbol (*) to denote an 
infinite 
upper bound. Though, this is redundant since the symbol is already 
there 
as part of the lexical representation of unlimited_natural (according 
to 
page 144 of the Infrastructure document)
(P3) (4) and (8) define the upper bound using the datatype 
"unlimited_natural" which comprimises all integer numbers starting 
from 
zero. Thus multiplicities like [0..0] would be legal.
(P4) It should be mentioned that the lower part is lower or equal to 
the 
value given for the upper part (where '*' is geater than any other 
element of the set named integer). Otherwise multiplicities like 
[8..2] 
would be considered legal.
(P5) What is the role of the value_specification mentioned at (8) and 
(9) isn't it redundant there?


Or am I just misreading the spec?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed isuse

Discussion:
UML 2 Revision Task Force Disposition: Closed, no change
OMG Issue No: 6502
Document ptc/06-01-01 Page 641
Or am I just misreading the spec?
Discussion:
The response to these items is embedded below each:
• (P1) (9) and (10) are never used
This claim is simply incorrect: both of these designators can be used in specifying
a multiplicity
• (P2) Defining the lower bound as "integer" (according to page 142 of the
Infrastructure document) allows it to specify multiplicities with lower bounds
*below* 0 (e.g. [-5..7], [-42..0])
Technically, this is true, but the possibility is prevented by an OCL constraint.
The BNF is used merely to define the valid notational forms and does not deal
with semantic constraints, which are covered elsewhere. The case where a lower
bound would require an UnlimitedNatural does not seem to be required and may
confuse some readers and would likely cause a disruption in numerous
implementations.
•
(P3) (4) and (8) include the asterisk symbol (*) to denote an infinite upper bound.
Though, this is redundant since the symbol is already there as part of the lexical
representation of unlimited_natural (according to page 144 of the Infrastructure
document)
This was fixed in the FTF.
• (P4) (4) and (8) define the upper bound using the datatype "unlimited_natural"
which comprimises all integer numbers starting from zero. Thus multiplicities like
[0..0] would be legal.
Once again (see the response to (P2)), the submitter is mistakenly assuming that
the BNF is used to define the semantic constraints, whereas it merely specifies the
notation.
•
(P5) It should be mentioned that the lower part is lower or equal to the value
given for the upper part (where '*' is geater than any other element of the set
named integer). Otherwise multiplicities like [8..2] would be considered legal.
Again, there is a constraint that deals with that case.
• (P6) What is the role of the value_specification mentioned at (8) and (9) isn't it
redundant there?
Value specifications allow the use of various symbolic references. Disposition: Closed, no change


Issue 6503: Why not using the UML1 activity symbol for UML2 actions? (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I didn't recognize it before, but now I am surprised that the action 
symbol
is not the same as the UML1 activity symbol ("shape with straight top 
and bottom 
and with convex arcs on the two sides").
Actions are no activities, but the semantic is similar for 
the "normal" UML user.
In UML1 the user has to distinguish between the activity symbol and
the state symbol ("round-cornered rectangle"), especially if states 
and activities
are shown within the same diagram. 
Now you has to use the UML1 state symbol for actions. I think that 
this is confusing
for the normal UML user.
Another point is that the action symbol is the same as the state 
symbol. There will
be no chance for a misunderstanding, because both symbols are not 
allowed within the same
diagram. But it would be much clearer if the action symbol has a 
different notation and
looks like the UML1 activity symbol.


So, why not using the UML1 activity symbol for UML2 actions?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
August 23, 2006: closed issue

Discussion:
This is too large and debatable a change for the FTF to address, and does not
affect implementability. UML2 completely separates state machine and activity semantics and notation. This
eliminates the need to have different symbols to distinguish states from activities on the
same diagram. UML2 could have used the UML1.x activity notation for actions in an
activity, but rounded rectangles are somewhat easier to draw by hand, and there shape
may be simpler to manage. At this point, the cost of changing this is probably greater
than its value.
Disposition: Closed, no change


Issue 6524: class "InfrastructureLibrary.core.constructs.Association", (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
 found something strange in the specification of UML 2.0.
First of all, in the 
class "InfrastructureLibrary.core.constructs.Association", there is 
an attribute "ownedEnd" with return type 
of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it 
its direct subclass "infrastructurelibrary.profiles.Extension", there 
is an attribute "ownedEnd" which redefines ownedEnd in 
class "Association", but with return 
type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity 
of 1. It causes conflicts of generated JMI interface.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Extension is a subclass of Association, and ExtensionEnd is a subclass of Property. So
Extension::ownedEnd: ExtensionEnd is an implicit redefinition of inherited property
Association::ownedEnd: Property. Redefinitions of this sort are used throughout the
UML2 metamodel, many of them occurring as the result of package merges.
Unfortunately, there is no way to have this fixed without a major reworking of the entire
UML metamodel and a change in the definition of UML 2. This is because the concept of
property redefinition is (a) a fundamental capability of UML 2.0 and (b) very tightly
integrated into the metamodel. Removing it, which is what would be required to deal with
this issue, is far outside the scope of an RTF.
Disposition: Closed, no change


Issue 6525: two classes "NamedElement (uml2-rtf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Secondly, there are two classes "NamedElement" holding un-redefined 
attribute "name", one is in the 
package "InfrastructureLibrary.Core.Basic", and the other is in the 
package "InfrastructureLibrary.Core.Abstractions.Namespaces". The 
problem is that there are a lot of classes directly or indirectly 
inheriting both of them e.g. class "InstanceSpecification" in package 
uml.classes.kernel, and it causes problem of duplicated parameters in 
class creation in the generated JMI interfaces. e.g. 
"
public InstanceSpecification createInstanceSpecification
(java.lang.String name, 
infrastructurelibrary.core.abstractions.visibilities.VisibilityKind 
visibility, java.lang.String name, java.util.Collection classifier); 
"
Similiar cases happen to attribute "type", "isAbstract" etc.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
The submitter seems to be unfamiliar with the rules for redefinition and package merge,
which resolve such issues in general. In this particular case, due to the fact that
Abstractions and Basic have been de-coupled in the FTF work, the two are completely
distinct elements and are not intended to be used together. If someone does decide to use
them together, however, package merge would resolve any contention. See also the
resolution to issue 6003 and 6002.
Disposition: Closed, no change


Issue 6616: UML Superstructure FTF : isRoot property disappeared (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Guus Ramackers, guus.ramackers(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.


On page 399 FAS: section 13.3.4


The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.


On page 86 FAS section 7.8.3 RedefinableElement:


isLeaf: Boolean 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.


But no  mention of isRoot....

Resolution:
Revised Text:
Actions taken:
November 14, 2003: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6624: freeing namespace (uml2-rtf)

Click
here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Uncategorized Issue
Severity:
Summary:
I know ODP is <adjective>, so i'd like to add mention of a couple of other places where we will find name space standing on its own, and not conflated with package or other container.


An IETF namespace is exactly "a set of terms usable as names."


As Karl reminded me, a C++ name space is also "a set of terms usable as names," declared with the keyword 'namespace' and used with the keywords 'using namespace' (providing a naming context) or with the scope operator, '::' (converting a simple name to a name that is an identifier).


[Unlike most Java tools, there is no requirement that the things in a C++ namespace all be in any particular container.  Karl tells me that C++ programmers he works with don't like the way Java tools insist that a package-cum-namespace be identified with a directory that contains all elements of that package.  (Of course, tools that do that are following "the extremely simple example" in The Java Language Specification.  Sometimes the effect of simple examples on the future of the world.)  It can be fine to have such simplifications in a programming language, but it's good to have more flexibility in models.]


C++ also provides a form for aliases:
    namespace new_name = current_name ;


Still more flexible is that other approach, which in addition to distinguishing name space from naming context, also allows the same item to have fully qualified names from different namespaces.  If that's in MOF, let's use it.  (Is that accomplished the relaxing, which MOF 2 package import provides?  (If i import C from Pa into Pb, can i identify it with 'Pb::C'?))


If not, let's put it there.


Seems to me to be easy to accomplish, if Namespace is first class.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 17, 2003: received issue

Discussion:
This is a significant change at the core of the metamodel and requires further study. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6630: UML 2 Super / Classes / dependencies should be unidirectional (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies 


Resolution: see above
Revised Text: In figure 15 on page 32, make the association end NamedElement::supplierDependency non-navigable. (According to the convention used in the spec (section 6.5.2), this means that the supplier NamedElement does not have a property that explicitly identifies the set of dependencies that target it.) In section 7.3.33 on page 100 in the Associations subsection of NamedElement, remove the entire “supplierDependency” item.
Actions taken:
November 26, 2003: received issue
August 23, 2006: closed issue

Discussion:
This is fully consistent with the pattern used for all the other kinds of directed
relationships (Generalization, PackageMerge, ElementImport and PackageImport.)
Note that this does not prevent tools from readily determining the dependencies targeting
a particular model element if necessary, since that information can be easily computed or
cached by the tool when the dependency is constructed.


Issue 6637: UML 2 Infra/Metamodel/missing derivation indicators (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived. 

Resolution: Discussion: This was fixed in release 2.1. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 21, 2003: received issue
February 18, 2005: moved from infrastructure
October 27, 2008: closed issue

Issue 6639: remove paragraph (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.

Resolution:
Revised Text:
Actions taken:
November 25, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
The offending paragraph was removed during the finalization phase. The issue is no
longer applicable.
Disposition: Closed, no change


Issue 6640: number of the figure is wrong (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.

Resolution:
Revised Text:
Actions taken:
November 25, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This paragraph was removed in the finalization phase, so the issue is no longer relevant.
Disposition: Closed, no change


Issue 6641: well-formedness rules are not numbered correctly (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].

Resolution:
Revised Text:
Actions taken:
November 26, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6645: UML 2.0 Superstructure Kernal/Packages (uml2-rtf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
The  Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement.  But is incorrectly changed from a derived union to NON Derived.  If it is intended to be non derived the property string subsets on all the other members are in error.

 

ownedMember for a Package should be a derived union subset by the following Properties:

ownedType

nestedPackage

ownedRule

 

An OCL equivalent would be as follows:

 

ownedMember=ownedType->union(nestedPackage)->union(ownedRule)


Resolution:
Revised Text:
Actions taken:
October 1, 2003: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6659: multiplicity of the association named "type" of type DataType (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6660: The multiplicity of association named subaction of type Action ill formed (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].

Resolution:
Revised Text:
Actions taken:
December 1, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6661: In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11 (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6662: In the last paragraph, the period after the word "collections" on the secon (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
In the last paragraph, the period after the word "collections" on the second line should be removed

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6665: UML 1.5 table of contents (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company> 

Resolution:
Revised Text:
Actions taken:
December 3, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6681: UML2 Super/Kernel Classes (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
section 7.11 Does Property.aggregation have meaning for properties typed by
value types, (Data Type and subtypes)?

Resolution: The short answer is yes. This question pertains to the case where two conditions hold: 1) a Property is owned by a classifier via ownedAttribute, 2) the type of the ownedAttribute property is a kind of DataType According to the semantics of DataType (7.3.11), the instances of a data type are identified only by their value. The meaning of Property.aggregation for a datatype property owned by a classifier is subject to several factors, including: - the precise semantics of shared aggregation (AggregationKind 7.3.2) - the meaning of composition for such a property which "indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts)" (AggregationKind 7.3.2) - any restrictions on the capabilities of datatypes (DataType 7.3.11) A datatype instance may consume some storage in which case the concept of aggregation may be useful to clarify the storage management implications of a datatype property to its owning classifier in the composite aggregation case. The precise semantics of shared aggregation is explicitly acknowledged as a semantic variation point. Any restriction on the capabilities of datatypes must be compatible with the fact that two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that "The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers)" (note the "many-to-one correspondence).
Revised Text: n subclause 7.3.11 (DataType), under "Semantics", replace the first sentence of the second paragraph: All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be the same if the structure is the same and the values of the corresponding attributes are the same. With: All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be equal if the structure is the same and the values of the corresponding attributes are equal.
Actions taken:
December 8, 2003: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6692: Operations and derived attributes (uml2-rtf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
I am looking at ValueSpecification which introduces Additional Operations, such as integerValue().  My question is : What is the reasoning behind making these Operations vs. Derived attributes?

 

In MultiplicityElement we have a derived attribute lower which is equal to lowerBound().  What logic is used to determine whether an Operation has a corresponding Attribute?

 

Also the spec seems to indicate that all derived values will be implemented via some operation.  Is this a requirement or an assumption of implementation?

 

Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

 


Resolution:
Revised Text:
Actions taken:
December 10, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
It is usually a question of balance between efficiency and the need to minimize the
storage requirements for storing models (in both dynamic and persistent store). In
principle, anything that can be computed should be defined as an operation. Non-derived
attributes provide the basic input data from which such computations can be effected.
Derived attributes are typically used when the computation is judged to be inefficient in
some sense. (Clearly, there is a discretionary element in this, and such criteria are not
necessarily applied consistently in the spec.)
In the particular case of MultiplicityElement::lowerBound(), this was necessary since it is
possible that no lower bound was actually specified by the modeler.
Concerning derived values, the intent is to provide a specification of how each derived
feature is computed, whether through a formally specified formula (in OCL, for
example), or, where this is impractical or infeasible for some reason, in precise natural
language. However, because this is a lengthy undertaking requiring significant resources,
it was deemed impractical to hold up release of the specification until this task was
completed. Instead, its completion has been relegated to subsequent revision task forces.
The same applies to various constraints.
Disposition: Closed, no change


Issue 6696: Remove one of the dots between protectedAction and availableOutput (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type" 

Remove one of the dots between protectedAction and availableOutput

Resolution:
Revised Text:
Actions taken:
December 15, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed isssue

Discussion:
The issue no longer applies. UML 2 replaced JumpHandler with ExceptionHandler.
Disposition: Closed, no change


Issue 6697: Associations section of element JumpHandler (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information. 

The line should read: 

protectedAction: Action [0..*] 

Resolution:
Revised Text:
Actions taken:
December 15, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
JumpHandler (UML 1.5) is replaced by ExceptionHandler in UML 2. The type of the
protected node is correct (ExecutableNode).
Disposition: Closed, no change


Issue 6699: UML 2.0 infra and super Constraints Diagram of the Kernel (uml2-rtf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.


Resolution: see above
Revised Text: Change Figure 7 on page 24 to show Constraint::namespace to be navigable (this was already done in the Rose model). Editor’s note: This change also needed to be made in the Inrastructure document in the Constraints package of Abstractions.
Actions taken:
December 16, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Constraint::namespace redefines NamedElement::namespace so it should retain the same
name. Namespace was probably used instead of owningNamespace to keep the name
shorter and to follow the conventional meaning of the word (and its use in XML).


Issue 6700: UML 2.0 Kernel Operations Diagram and Features Diagram and mdl (uml2-rtf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
The operations diagram redefines the formalParameter Property and removes the {ordered subsets parameter subsets ownedMember}.

 

The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn’t defined in the spec.

 

I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

 

This would require the ownerformalParam be made navigable.  But I feel that this change is already required to sync the OCL and Superstructure specs.

 

An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

Resolution:
Revised Text:
Actions taken:
December 16, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6702: The numbering of the sub-sections in 2.7.2 is wrong (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6703: In "2.9.3.5 Instance", numbering of different well-formedness rules wrong (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly. 

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6704: The section about Procedure does not contain any well-formedness rules (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6724: The Composition section does not follow the usual conventions (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6725: missing closing parenthesis (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read 


Resolution: Indeed so.
Revised Text: On page 616 of ptc/04-10-02 change the last line of the second additional operation from: else (ancestor (s1, s2.container) to else (ancestor (s1, s2.container))
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:


Issue 6726: At the bottom of the page, the characters "antics." should be removed (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
At the bottom of the page, the characters "antics." should be removed

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6727: In 2.13.3, the first sub-section about ActivityGraph is not numbered (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change


Issue 6866: Part subtype (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Would be useful to be able to assign a subtype for objects that fill a
part, to add additional characteristics.  For example, a person fills
the Employee part of a company, and is reclassified under a subtype of
person that has an office.  It is not sufficient to use the subtype as
the type of the part, because the model wouldn't record what objects are
allowed to fill the parts.  The object is reclassified under the subtype
after filling the part.

Resolution: The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF. Revised Text: None. Disposition: Closed, out of scope
Revised Text:
Actions taken:
November 5, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
The issue suggests a new feature of UML. While interesting, such is considered outside
the scope of this FTF. The issue suggests a new feature of UML. While interesting, such is considered outside
the scope of this FTF.


Issue 6878: UML 2 Infrastructure / rule for redefinition of Property (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The isConsistentWith() query defined on Property implies that in order for a property redefinition to be logically consistent, the redefining property must be derived if the redefined property is derived. Are these the correct semantics for redefinition? There are cases in the metamodel where this constraint is violated (e.g. Package::ownedMember is not derived, but it redefines derived property Namespace::ownedMember). If there is to be a constraint on redefinition, perhaps it makes more sense the other way around, i.e. a redefining property must be non-derived if the redefined property is non-derived. 

Resolution:
Revised Text:
Actions taken:
January 2, 2004: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6921: Inheritance of 'Enumerations' is not detailed (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
Inheritance of 'Enumerations' is not detailed with repsect to their (ordered) owned 'EnumerationLiteral's. 

Proposed resolution: Add a constraint to restrict Enumerations to be unable to inherit from each other (at least favored in MOF) or specify how Literals are ordered. 

Resolution:
Revised Text:
Actions taken:
January 19, 2004: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6922: Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment). 

Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance) 

Resolution:
Revised Text:
Actions taken:
January 19, 2004: received issue
February 18, 2005: moved from infrastructure

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6923: Class InfrastructureLibrary::Core::Basic::Property (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Class InfrastructureLibrary::Core::Basic::Property contains an attribute named 'default' of type 'String'. If initial values should be provided for a Property instance, then there is no possibility to evaluate the string without a schema. I'm not sure about the intension of this default property, especially for MOF (it seems to be useable only for visualization in UML). 

Proposed resolution: If evaluation should be processable by tools (e.g. code generators), then the type of 'default' must be changed to class "Type" or a schema for evaluation should be provided. 

Resolution:
Revised Text:
Actions taken:
January 19, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Property defaults in Basic and Constructs (and therefore EMOF and CMOF) can only be
specified for primitive types, so only String is needed. UML2 Kernel supports more
complex default values through defaultValue:ValueSpecification. In
Kernel::Property:/default is derived from defaultValue.
Disposition: Closed, no change


Issue 6927: UML 2 Super / Interactions / Ambiguous diagram tags (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Diagrams have a frame and a tag that describes the kind of diagram. Most diagrams correspond to a portion of the metamodel, and in most cases there is a one-to-one correspondence between metamodel chapters and diagram types, although variants are allowed for special cases (such as 'package').  There are four kinds of diagrams showing interactions, each with its own unique contents and syntax: sequence diagrams, communications diagrams, interaction overview diagrams, and timing diagrams.  Unlike the difference between class diagrams and package diagrams, for example, each of these is very different in appearance and content from the others, even though they allegedly all map to the same interaction model (which might be dubious in practice, given the very different content, but that's another matter).  However, the examples all use the same tag, 'sd', for all of the kinds of interaction diagram. Clearly 'sd' is an abreviation for 'sequence diagram' and it is inappropriate for the other types.  (The fact that it is an English-language abreviation is another problem that we will let pass for now.)  It would seem that each kind of diagram should have its own tag, given that they have different syntax and usage. For example, we could use 'sd', 'cd', 'iod', and 'td' if we wish to keep the same abbreviated format. But in any case the tags  should be different and they should be descriptive of the diagram, not the underlying modeling chapter. (The official tag for interaction diagrams as a group is 'interaction', not 'sd' (page 589), so 'sd' is already descriptive of just one variant.) 

If the argument is that you can tell apart the different variants of interaction diagram by looking at them, that argument would apply with even more force to the diagrams for different kinds of models, such as class diagrams, state machine diagrams, etc., so we wouldn't need tags at all. (Which may be true, and users will probably not bother most of the time, but let's at least get it right in the standard.) 

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
January 23, 2004: received issue

Discussion:
While this is possibly a reasonable suggestion, it does not represent either a consistency
fix or a clarification and is more appropriately resolved in some future revision. This is an overall discussion and not only for Interactions. The question is about two
different aspects:
1. What should the tab keyword indicate?
a. the type of diagram
b. the object defined by the diagram
c. irrelevant, the tab is only for naming


Issue 6975: missing illustrations of graphical paths for create and destroy messages (uml2-rtf)

Click
here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:
Table 15 does not include illustrations for 
  - create message (a graphical path flowing into a Lifeline head). 
  - create message to lost
  - create message from found


More illustrations need to be added to Table 15 as the new sorts of messages are added, for example:
  - synch and async create
  - synch and async destroy

Resolution:
Revised Text:
Actions taken:
February 16, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6989: UML 2 Super/Interactions/Constraints for create messages (uml2-rtf)

Click
here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:
page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

Constraints need to be updated as new sorts of messages are added.

Resolution:
Revised Text:
Actions taken:
February 16, 2004: received issue
August 23, 2006: closed issue

Discussion:
The following constraint could be added:
“[9] No EventOccurences should occur before receiving the create message on
the corresponding Lifeline”
However this constraint does not allow modeling a situation where a create message may
be sent to an existing entity either due to error or intent (e.g., to model erroneous
behavior).
The above constraint applies to valid interactions. It is unclear how this constraint
applies to multivalued instances.
Therefore, it seems safer to not add this constraint.    Duplicate of Issue 8327 (even though this came first), see the resolution of 8327
Disposition: See issue 8327 for disposition


Issue 6990: manage simultaneity of events (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Significant
Summary:
Issue 1: to have the possibility to manage simultaneity of events, and be able to 

trigger a transition by a condition on several events. By this way, the triggering 

condition of a transition may be specified through an event formula such as: (e1 and e2) or e3 

This point we then involve to relax a constraint on the semantics of RTC and to introduce then 

the possiblity to dequeue several events of the queue at the same time. May it be just an 

additional open variation semantics point? 

Resolution: Simultaneous events and transitions triggered by a logical combination of events require a major modification or enhancement to the current Run-To-Completion semantics, where events are handled one at a time. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
February 17, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
The RTC model is currently fundamental to UML statemachines. Allowing several
events to be posted to a statemachine has a significant ramification on the current spec
beyond just adding a way to express simultaneity. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 6991: transtion (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Issue 2: In the same spirit, we would like also to specifiy that a transtion is fired 

only if an event is not available at a given instant. We need the concepts of instant 

and event absence. Note that the absence combined with "and" and "or" can express kinds of 

priorities (e.g., "a and not b"). 

Resolution: Triggering a transition with the absence of an event seems to make sense only under a synchronous semantics which defines slices of time where that event might occur or not. It require a major modification or enhancement to the current, asynchronous Run-To-Completion semantics, where events are handled one by one in a timeless sequence. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
February 17, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
This proposal is relevant in case where simultaneity of events is allowed as requested in
issues 6990. Since 6990 is deferred, this request shall be deferred as well. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 7051: StateMachine - Constraints (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"[1] The classifier context of a state machine cannot be an interface" 

should be: 

[1] The context classifier of a state machine cannot be an interface. not redefinitionContext.oclIsKindOf(Interface) 


"[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioral feature." 

should be: 

[2] The context classifier of the method state machine of a behavioral feature must be one of the classifier that features the behavioral feature 

-- note that a behavorial feature can be associated with 1..* -- classifiers if self.specification->notEmpty() then self.specification.featuringClassifier->includes(redefinitionContext) endif 

"[3] The connection points of a state machine are pseudostates of kind entry point or exit point." 

should be: 

[3] The connection points of a state machine are pseudostates of kind entry point or exit point. connectionPoint->forAll(cp | cp.kind = #entryPoint or cp.kind = #exitPoint ) 

"[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points." 

should be: 

[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points. self.specification->notEmpty() implies ( self.connectionPoint->forAll(cp | not (cp.kind = #entryPoint or cp.kind = #exitPoint) ) ) 

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
February 29, 2004: received issue

Discussion:
The OCL was left out of the final adopted specification and needs to be inserted.
However, the OCL constraints recommended above are mostly incorrect. Instead, the
following OCL expressions need to be inserted for constraints [1] through [4] of
StateMachine on page 490 respectively:
?? context->notEmpty() implies not
context.oclIsKindOf(Interface)
?? specification->notEmpty() implies
(context->notEmpty() and
specification->featuringClassifier->
exists (c | c = context))                                                                                                                                ?? connectionPoint->forAll
(c | c.kind = #entryPoint or c.kind = #exitPoint)
?? specification->notEmpty() implies
connectionPoint->isEmpty()


Issue 7105: In normative XMI file for the metamodel, no Associations have a name. (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the normative XMI file for the metamodel, no Associations have a
name.
The name is needed for generating APIs and (in some cases) XMI elements;
and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
Core has the following constraint for CMOF:
[6] Names are required for all classifiers and features (though there is
nothing to prevent these names being automatically generated by a tool).



(Association is a classifier)


We could get by with not having a name in the MDL and auto-generating a
name into the XMI. This is in fact what the Unisys XMI plug-in did when
no Association name was provided - and this was hence reflected in the
normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>). 


Resolution:
Revised Text:
Actions taken:
March 8, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This is a duplicate of issue 6492, which was resolved in earlier ballots.
Disposition: See issue 6492 for disposition


Issue 7161: UML 2 Super/Interactions/Need constraints that cover multiple Lifelines (uml2-rtf)

Click
here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:
Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.


Or  when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.


In order to achieve this, it would be desirable to use:
1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

Resolution: Discussion: Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects". Disposition: Closed Out Of Scope
Revised Text:
Actions taken:
March 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Although this is a reasonable feature to request, it is an enhancement that exceeds the
scope of the FTF. One of the main issues with it is that the semantics of defining such
constraints in a distributed environment are not simple and require some serious
consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the
restrictions on guards reflect this to prevent specifying distributed decisions that would
imply implicit synchronization. The fact is, however, that many systems are such that it is
known that the lifelines are not concurrent and checking remotely or on enclosing objects
is not really hazardous. The problem is that we do not have a good way to define this in
the specification. This is of course not dependent upon Interactions, but is a feature of all
of UML. There seems to be a need to define object groups that share the same “thread”
and are only pseudo-concurrent. If we had had such a construct, the guard could cover
any subset of such a “same-thread-set-of-objects”.


Issue 7166: show object flow or interactions (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

Resolution: This issue has already been discussed in previous F/RTFs and considered out of scope: FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address. RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them. Revised Text: None Disposition: Closed Out of Scope
Revised Text:
Actions taken:
March 19, 2004: received issue
March 22, 2004: moved from infra- to superstructure-ftf
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Activity diagrams only show task dependency, which can be achieved by multiple
implemented processes. An activity can have more than one initial node. These
are all started when the activity is. The initial nodes can be used in separate
partitions to indicate which actions are taken on the client and server. If the two
processes are completely independent, then this is a request is for a hybrid
diagram, especially when trying to show shared objects. This is too much for an
FTF to address.  FTF: Activity diagrams only show task dependency, which can be achieved by multiple
implemented processes. An activity can have more than one initial node. These are all
started when the activity is. The initial nodes can be used in separate partitions to indicate
which actions are taken on the client and server. If the two processes are completely
independent, then this is a request is for a hybrid diagram, especially when trying to show
shared objects. This is too much for an FTF to address.
RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are
many combinations and not enough experience to choose among them.


Issue 7223: Questions about DataTypes and generalization (uml2-rtf)

Click
here for this issue's archive.
Source: Red Hat (Mr. Randall M. Hauch, rhauch(at)redhat.com)
Nature: Uncategorized Issue
Severity:
Summary:
I have a few questions regarding section 7.12 entitled "Kernel - the
DataTypes Diagram" in the final adopted Superstructure spec (03-08-02).


DataType specializes Classifier, and as such it also inherits the ability to
have generalization relationships with other Classifiers.  Classifier has an
additional operation 'maySpecializeType(Classifier):boolean' that is
described/defined as follows:


"The query maySpecializeType() determines whether this classifier may have a
generalization relationship to classifiers of
the specified type. By default a classifier may specialize classifiers of
the same or a more general type. It is intended to be
redefined by classifiers that have different specialization constraints."
(p. 63)


with the OCL:


        Classifier::maySpecializeType(c : Classifier) : Boolean;
        maySpecializeType = self.oclIsKindOf(c.oclType)


DataType, nor its subtypes PrimitiveType and Enumeration, defines no
additional constraints or additional operations.  These additional
constraints are executed/applied in the UML2 metamodel (rather than in a
UML2 model), correct?  If so, then this implies that a DataType may
specialize another DataType, Classifier, Namespace, Type, etc., but that
DataType may not specialize PrimitiveType or Enumeration.  Please correct me
if I'm interpreting this incorrectly.


Consider an example with:
*       a PrimitiveType named "string"
*       a PrimitiveType named "float"
*       a DataType named "InternationalPrice" that specializes "float" and
adds a new attribute/property called "currency" of type "string"


The "InternationalPrice" DataType is conceptually a qualified type, meaning
it is a float plus a qualifier of the value.  Examples of instances would be
{426.36, "US Dollars"}, {401.23, "Euros"}, {749.42, "Yen"}.


If my interpretations of the Superstructure spec are correct, then this
example cannot be modeled using UML2.  And, in fact, the specification would
actually allow me to create a new PrimitiveType named "double" that actually
specializes my "InternationalPrice" DataType (since DataType is a supertype
of PrimitiveType).  My thought is that this is either a issue with the
'maySpecializeType' operation or it is an issue with DataType, PrimitiveType
and Enumeration not being properly constrained.


Resolution:
Revised Text:
Actions taken:
April 6, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7227: UML2 Super/Deployment/inheritance (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Deployment should not be a Dependency
Section 10.3.4, figure 126 show the Deployment subclass of Dependency
with location subsetting client and deployedArtifact subsetting
supplier.
This means in effect that a Node is deemed dependent on the Artifacts
that are deployed to it which seems to me the wrong way round if
anything.


Since it is not really true either that an Artifact is dependent on the
Node it is deployed to, it does not seem sensible for Deployment to
inherit from Dependency at all: it should inherit directly from
DirectedRelationship.


[Aside: Figure 126 shows 'subsets source' and 'subsets target' which is
not reflected in section 10.3.4. I had assumed that Dependency would
itself specify client and supplier to subset/redefine source and target
but this oddly appears not to be the case] 

Resolution:
Revised Text:
Actions taken:
April 11, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7229: UML2 Super/Deployments/Manifestation (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Manifestation should inherit from Realization


In Section 10.3.10 and Figure 124 it would make more sense for
Manifestation to inherit from Realization rather than directly from
Abstraction. The semantics of Realization are described as "A
Realization signifies that the client set of elements are an
implementation of the supplier set,.." which surely includes
manifestation. 
The spec also states that Realization may be used to model
transformations, which fits with the example given in Manifestation:
"<<tool generated>> and <<custom code>> might be two manifestations for
different classes".


BTW There is a missing word in the description of Manifestation "A
manifestation is the concrete physical of one or more model elements by
an artifact."

Resolution:
Revised Text:
Actions taken:
April 11, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7246: Figure 78 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however. 

Resolution: Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
April 15, 2004: received issue
October 27, 2008: closed issue

Discussion:
Resolution deferred for the next RTF


Issue 7247: Connector - "provided Port" and "required Port" not defined Constraint 1 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts." 

Resolution: The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue.
Revised Text: Replace 8.3.3 constraint [1] which currently says: [1] A delegation connector must only be defined between used Interfaces or Ports of the same kind (e.g., between two provided Ports or between two required Ports). By [1] Each feature of each of the required interfaces of each Port or Part at the end of a connector must have at least one compatible feature among the features of the provided interfaces of Ports or Parts at the other ends, where the required set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's provided interfaces, and the provided set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's required interfaces. Replace the whole of the section 8.3.3 Semantics by the following: "A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by one or more instances that have "compatible" capabilities. These situations are modeled through a delegation connector from a Port to compatible Ports or Parts. Delegation connectors can be used to model the hierarchical decomposition of behavior, where services provided by a component may ultimately be realized by one that is nested multiple levels deep within it. The word delegation suggests that concrete message and signal flow will occur between the connected ports, possibly over multiple levels. It should be noted that such signal flow is not always realized in all system environments or implementations (i.e., it may be design time only). A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. At execution time, signals will be delivered to the appropriate port. In cases where multiple target ports support the handling of the same signal, the signal will be delivered to all these subordinate ports. The execution time semantics for an assembly connector are that signals travel along an instance of a connector. Multiple connectors directed to and from different parts, or n-ary connectors where n> 2, indicates that the instance that will originate or handle the signal will be determined at execution time. The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services. Also, in contexts where components are used to extend a system by offering existing services, but also adding new functionality, connectors can be used to link in the new component definition." Note: I have not attempted the OCL for the constraint in this resolution. That can be a subsequent issue.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Resolution deferred for the next RTF


Issue 7248: Connector - inconsistencies in Constraint [2] (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Connector - inconsistencies in Constraint [2] Constraint [2] says: "[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an “implements” relationship to the Interface type of that Port." There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a ConnectableElement. 2. What is "the Interface type of that Port" ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one? 

Resolution: This constraint and the following two are currently incomprehensible (see 7249 and 7250). According to Internal Structures, "What makes connectable elements compatible is a semantic variation point." I see no particular reason to change this for components, and given that connectors are n-ary, it would be hard to do so. So I propose simply to delete the constraints. Profiles are free to restrict connectors to binary and to impose signature compatibility, based on type or contract compatibility, if they wish to.
Revised Text: Delete 8.3.3 constraint [2] which currently says: [2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an "implements" relationship to the Interface type of that Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Resolution deferred for the next RTF


Issue 7249: Connector - inconsistencies in Constraint[3] (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Connector - inconsistencies in Constraint[3] Constraint [3] says: "[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port." There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a ConnectableElement. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a ConnectableElement) - what is the "target Interface"? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does "signature compatible" mean for Interfaces? 

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [3] which currently says: [3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
Resolution deferred for the next RTF


Issue 7250: Connector - inconsistencies in Constraint[4] (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Connector - inconsistencies in Constraint[4] Constraint [4] says: "[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port." There are two problems with this constraint: 1. What is "the union of the Interfaces of these target Ports"? First, it is not clear, what a "union of interfaces" is. A "union of a set of interfaces" could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because "union of interfaces" is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does "signature compatible" mean? 

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [4] which currently says: [4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:


Issue 7251: Connector - inconsistencies in Constraint[5] (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Connector - inconsistencies in Constraint[5] Constraint [5] says: "[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port." There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a ConnectableElement. 2. It is not clear what a "required Port" or a "provided Port" is. 

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [5] which currently says: [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:


Issue 7254: completion transitions (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors. 

Resolution:
Revised Text:
Actions taken:
April 21, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7255: Priority of the joint transition (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The specification says that: "The priority of joined transitions is based on the priority of the transition with the most transitively nested source state". Suppose that a join transition is has two transitions with source states at the same depth, but in two different regions. How is is established which of the two transition defines the priority of the join transition?. Notice that, depending on which transition is choosen, different other transitions might be allowed or disallowed to be fired. Some possible anwers are: - Any of the two transitions can be chosen statically. (i.e. the priority of the join transition always remains the same). - Any of the two transitions can be chosen, and the choice truly, completely nondeterministic (hence possibly dynamic) I.e. the priority of the join transitions can change each time the join transition is fired.

Resolution:
Revised Text:
Actions taken:
April 21, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7274: UML2 Infra/11.5.1/Invalid reference to Attribute class (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 11.5.1 (DataType) the first association is specified as:


ownedAttribute: Attribute[*] The Attributes owned by the DataType.


This is out of date: the class Attribute has been replaced by Property,
though the association name is OK referring to 'Attribute'. This is
reflected in the diagram above that text (Fig 86).


Proposed resolution:
Replace the above text with:
ownedAttribute: Property[*] The Properties owned by the DataType.

Resolution:
Revised Text:
Actions taken:
April 28, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Fixed by resolution to issue 6596
Disposition: Closed, no change


Issue 7303: simple time model" in CommonBehavior (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: (i) It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.

Resolution: Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 5, 2004: receive dissue
October 27, 2008: closed issue

Discussion:
A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the “simple
time model” and related concepts is required.


Issue 7304: Notation sections for TimeObservation and DurationObservation (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
The Notation sections for TimeObservation and DurationObservation seem inadequate: 1. The syntax for TimeObservation only allows "now" as a TimeExpression, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for DurationObservation includes the unexplained non-terminal symbol "duration". 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated.

Resolution: This issue has already been considered by prior RTFs and deemed out of scope, per the following discussion previously recorded for this issue: A proper resolution of this issue depends on changes in progress with respect to the action and activity model. In addition, a more encompassing improvement of the "simple time model" and related concepts is required. Thus, the resolution of this issue is best considered to be strategic. Revised Text: None Disposition: Closed Out of Scope
Revised Text:
Actions taken:
May 5, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the “simple
time model” and related concepts is required.


Issue 7329: large overlap between structural features and variables (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
May 9, 2004: received issue

Discussion:
This is indeed the case but the issue needs to be addressed in greater depth since it is at
the core of the semantics of UML, and is out of scope of an FTF. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 7337: inconsistency in the action model (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Critical
Summary:
There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
May 15, 2004: received issue

Discussion:
Two comments on the issue text:
"there are other links in the model, such as those due to Connectors". The links
established due to connectors are just links any other (link = an instance of an
association).
"or one should generalize the link actions to apply to liks identified by any
StructuralFeature". Links cannot be identified by structural features that are not
association ends, because there are no links in that case.
In separate discussion with the filer, there was concern that structural feature were not
well enough defined to have actions defined on them. Structural feature inherits from
TypedElement, which provides a way to map to instances of a type, as explained in the
entry for Kernel::TypedElement. The structural feature actions provide the results of this
mapping, as explained in the semantics of StructuralFeature.
The filer would like this issue held for further discussion.


Issue 7338: metaattribute isReadOnly (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Significant
Summary:
The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

Resolution:
Revised Text:
Actions taken:
May 15, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7339: Property defines an association "datatype" which is redundant (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Significant
Summary:
Property defines an association "datatype". This association is redundant for the following reasons: (i) A DataType is a kind of classifier, so saying that a property can be owned by a DataType adds nothing new. (ii) as feature, one can navigate from the property to the featuringClassifier, and so the navigability to an owning data type is already given. Moreover, an association to a data type would be incorrect if the property would otherwise be owned by a different Classifier. Moreover, if this property is owned by a classifier, there is no guarantee that the datatype association references the same DataType. There are no consistency constraints. Anyway, this association is redundant, can possibly lead to inconsistent models, and should be deleted. The last sentence on p.92 "A property may be owned by and in the namespace of a datatype." is correct even if the association is deleted. However, this sentence adds no new information either and is best deleted also. 

Resolution:
Revised Text:
Actions taken:
May 15, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7343: Section 11.7 (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Critical
Summary:
In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure.

Resolution:
Revised Text:
Actions taken:
May 16, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
This is a fixed by the resolution to issue 7344. BehavioralFeature no longer separates
returnResult and formalParameter. It has BehavioralFeature::ownedParameter and
Parameter has direction:ParameterDirectionKind.
Disposition: Closed, no change


Issue 7362: Clarify example in figure 133 (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Could you describe in details the meaning of the example described in Figure 133, because it could very useful to understand the deployment specification concept. Moreover, is there anything lacking in figure 134? It contains no model element with the <<deployment specification>> stereotype.

Resolution: see above
Revised Text: Replace the first sentence of the Notation subsection of DeploymentSpecification description (ptc/04-10- 02, page 214; formal/05-07-04, page 199) with the following text: “A DeploymentSpecification is graphically displayed as a classifier rectangle (Figure 133) attached to a component artifact deployed on a container using a regular dependency arrow.” (Note that in formal/05-07-04 the replacement text would refer to “Figure 10.11” instead of “Figure 133”.)
Actions taken:
May 19, 2004: received issue
August 23, 2006: closed issue

Discussion:
Figure 133 (page 214, ptc/04-10-02; same as Figure 10.11, page 199, formal/05-07-04) is
not discussed in or referenced by the text, and as pointed out by the issue, the figure
caption does not provide any clue has to how the figure assists understanding of the text.
It seems to be meant merely as an example of what the specification level (left box) and
instance level (right box) look like. A simple reference to the figure from the text should
help clarify the role of the figure.
The point of Figure 134 is to show how a DeploymentSpecification instance is associated
with the Artifact(s) it describes. The figure seems to accomplish this goal without the
necessity of a “model element with the <<deployment specification>> stereotype”. The
issue text does not say why such an addition would be helpful, and the figure seems to
accomplish its goal as is. No change seems needed. Note that the first sentence of
DeploymentSpecification’s Notation subsection is poorly formed: “A
DeploymentSpecification is graphically displayed as a classifier rectangle that is attached
to a component artifact that is deployed on a container using a regular dependency
notation is used.”


Issue 7364: section on connectors in the component chapter (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Critical
Summary:
The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section.

Resolution: Moving all of BasicComponents.Connector into InternalStructures, although perhaps strategically a good idea, seems like a bridge too far for the RTF. Also Thomas is not entirely accurate when he says it adds no new functionality apart from the notation. In particular BasicComponents adds the idea of a connector contract, which is a set of Behaviors. Therefore I propose that we leave the text where it is, albeit we should fix the many bugs in it that are the topics of this and other issues. However the proposal that kind:ConnectorKind should be derived is entirely sensible, especially since the current constraints on connector kind are the topic of numerous issues (7248-7251).
Revised Text: Under 8.1, Basic Components, replace the following sentence: "In addition, the BasicComponents package defines specialized connectors for 'wiring' components together based on interface compatibility." by "In addition, the BasicComponents package allows a connector to carry one or more Behaviors that specify the valid interaction patterns across the connector." Under 8.3.3, replace the first sentence: "The connector concept is extended in the Components package to include interface based constraints and notation." by "The connector concept is extended in the Components package to include contracts and notation." In the model (figure 8.3) show /kind: connectorKind as derived. Under 8.3.3 Description, insert the word "derived" before the phrase "connector kind attribute". Under 8.3.3 Connector Attributes, Package BasicComponents, replace: · kind : ConnectorKind Indicates the kind of connector. By: · /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif
Actions taken:

Discussion:


Issue 7372: surface notation for state machines (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

Resolution:
Revised Text:
Actions taken:
May 24, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7375: useless example on p.330, Figure 247 (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
p.330, Figure 247. This example is useless, as it canot be understood without much detail on the FFT computation. It would be better to use examples that readers can readily understand.

Resolution: The issue is subjective. Some readers might find the example helpful. The example is useful as a depiction of a realistic computation. Revised Text: None Disposition: Closed, no Change
Revised Text:
Actions taken:
May 20, 2004: received issue
May 24, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
The issue is subjective. Some readers might find the example helpful. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 7392: Interactions model sequences of events (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event. 

Resolution: Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 29, 2004: received issue
October 27, 2008: closed issue

Discussion:
Resolution deferred for the next RTF


Issue 7397: add an interaction fragment (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
Sequence diagrams are often used to describe abstract system behavior in the form of the interaction of the system with its environment. Experience has shown that systems have normal behavior and exceptional behavior (in response to unusual or unexpected events). UML2 has introduced a mechanism of representing exceptions. However, interactions do not give us a vehicle of showing exceptional behavior. Recommendation: add an interaction fragment indicating exceptional handling similar to the way this is done in the activity chapter. 

Resolution:
Revised Text:
Actions taken:
May 30, 2004: received issue
August 23, 2006: closed issue

Discussion:
Indeed. However, this is a feature request that is outside the scope of an FTF. Exception handling would be good to have also in sequence diagrams. However, judging
from work done in the UML Testing Profile, and from the Master thesis of a student from
University of Oslo, it is not as simple to include as implied in this suggestion. Introducing
another operator for a combined fragment is hardly enough, but may be part of the final
solution.
Disposition: Closed, no change


Issue 7398: Provide exception handling for all behaviors. (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors. 

Resolution:
Revised Text:
Actions taken:
May 30, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7400: AssociationClass (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing. 

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7401: XMI schema (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:
"[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed. 

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue
August 23, 2006: closed issue

Discussion:
Resolution deferred for the next RTF. This is a duplicate with 3898.
Disposition: See issue 3898 for disposition


Issue 7406: TimeObservationAction and DurationObservationAction (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:
TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed. 

Resolution: Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 29, 2004: received issue
October 27, 2008: closed issue

Discussion:
A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the “simple
time model” and related concepts is required.


Issue 7407: The specification is fond of using 'typically.' (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The specification is fond of using 'typically.' The term should be use with care in a specification. Typically, 'must' or 'may' are better choices. For example, at 7.4.1 p.42: The multiplicity bounds are typically shown in the format: lower-bound..upper-bound It will be better to write: The multiplicity bounds are shown in the format: lower-bound..upper-bound simply deleting 'typically.' (In this case, the syntax specification should show the case when the two bounds are equal.)

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue
August 23, 2006: closed issue

Discussion:
This is indeed a valid issue, since the term typically (sorry!) leads to confusion and
ambiguity that should not be encountered in a spec. Unfrotunately, there are 72 uses of
this term in the current spec and each one would have to be reviewed individually. This
does not seem feasible in the short time left for the work of this FTF. Therefore, it is
work that should be picked up by a subsequent RTF.======================The discussion associated with the resolution to issue 6456 equally applies here (except
that there are 71 uses of this term and its derivatives – still a very large number).
Disposition: Closed, no change


Issue 7620: Coupling between StateMachines and Activities (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
As I was reading through the text of issue 6114 it dawned on me that there is a needless and problematic coupling between state machines and activities. Namely, in figure 187, there is an association from ObjectNode to State, presumably to deal with the old "object in state" idea. This is similar to the coupling that was attempted but rejected in the Interactions chapter. 

While it may look attractive to have a formal link to the idea of State from state machines, there are two serious problems that make this much more trouble than it's worth: 

(1) The notion of "object state" -- as seen by users/manipulators of that object -- could be completely different from the implementation state of that object. This is the old principle of hiding implementation. Viewed from the outside, an invoice object may be in the "Paid" state, but this does not necessarily mean that the object has such a state in its implementation. In fact, there is no guarantee that the implementation will be based on state machines at all. Of course, you can say that this is a reference to some kind of external state machine view of an object -- which sounds reasonable, but here is where the second problem comes in: 

(2) State in the UML 2.0 spec comes with a sh..load of baggage: in effect, the whole state machine kit and caboodle. It's not very modular, and, unless you use profiles to shear away all the stuff that you don't want (which is about 99% of state machines machinery), you will force vendors who innocently just want to support the simple idea of "object in state" to implement all of state machines. 

Like I say, the feature doesn't look worth it. Let your State concept be a simple name. My guess is that most users who want to use this feature don't even want to know what a state machine is (the concept of states is not necessarily linked to state machines!). 

So, my suggestion is that in figure 187, you simply provide a subclass of ObjectNode called ObjectInState and give it a "stateName" attribute and you will get what 95% of your users want. Tying state machines to activities for that one little feature seems overkill. 


Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 4, 2004: received issue

Discussion:
This is deferred for the same reasons as 6114. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.


Issue 7756: Unconsistent association extension description (uml2-rtf)

Click
here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:
 b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447.
---

Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles.
.


Discussion

In Profiles:Profile:semantics, change the paragraph 

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel.

Into

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.

Resolution:
Revised Text: This change needs to be made in both the Infrastructure (ptc/04-11-16) and Superstructure specs (ptc/04-10-02): >>>>> "In Profiles:Profile:semantics, replace the following text: As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. The effect of new (meta)associations within profiles can be achieved in limited ways either by: 1. adding new constraints within a profile that specialize the usage of some associations of the reference metamodel, or 2. extending the Dependency metaclass by a stereotype and defining specific constraint on this stereotype. As an illustration of the first approach, the examples in Figure 450 and Figure 451 could be extended by adding a “HomeRealization” stereotype that extends the “InterfaceRealization” UML metaclass. The “Bean” stereotype will introduce the constraint that the “interfaceRealization” association can only target “InterfaceRealization” elements extended by a “HomeRealization” stereotype and the “HomeRealization” stereotype will add the constraint that the “contract” association can only target interfaces extended by a “Home” stereotype. As an illustration of second approach, one can define a stereotype “Sclass” extending Class and a stereotype “Sstate” extending State. In order to specify the default state of an “Sclass”, a “DefaultState” stereotype extending “Dependency” can be defined, with the constraints that a DefaultState Dependency can only exist between an Sclass and an Sstate. Into Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
Actions taken:
September 3, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7757: Unconsistent Profile extension description (02) (uml2-rtf)

Click
here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:
 18.3.5 says that "A profile by definition extends a reference  metamodel or another profile."
 While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..."
---

Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile".

The reference to profile extension should be simply discarded. A profile extends a reference metamodel.
.


Discussion

In Profiles:Profile:semantics, change the first sentence 

A profile by definition extends a reference metamodel or another profile.


Into

A profile by definition extends a reference metamodel.

Resolution:
Revised Text:
Actions taken:
September 3, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
In Profiles:Profile:semantics, change the first sentence
A profile by definition extends a reference metamodel or another profile.
Into
A profile by definition extends a reference metamodel.
Here also, the suggested change has been already made. This issue is obsolete (already
solved).
Disposition: Closed, no change


Issue 7782: Move Comment into Basic and add Kind (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Move Comment into Basic and add Kind
The ability to annotate and describe elements and diagrams is pretty
fundamental so should be included in Basic.
There should also be the recognition that there are different kinds of
comment: for example most tools have a dialog allowing people to enter a
Description for an Element; and separately may allow the element to be
annotated on diagrams in a particular context. At the moment there is no
way to distinguish these.
The UML Metamodel itself is an example of the need for different kinds
of Comment: each Class has a number of distinct sections (e.g.
Description, Semantics, Notation).
Hence there should be a 'kind' attribute on Comment to reflect this.

Resolution: Disposition: Closed, no change
Revised Text: Resolved in the FTF.
Actions taken:
September 24, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:
Resolution
Changes to Infrastructure:

Remove the class Comment and the association Element::ownedComment from Figure 71 and add to Figure 65

Move Section 11.1.1 Comment to 10.1.1 and renumber the following sections in sections 11.1 and 10.1


Issue 7783: Missing XMI tags in spec and XMI rendition of metamodel (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This issue applies to Infrastructure, Superstructure and MOF


In the XMI for Superstructure for example (in OMG document ad/03-04-02),
while this does use the nsuri for MOF (using the correct form
xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
contain any XMI tags to define for UML what its nsuri and prefix should
be: which are needed in order to generate the UML xsd.
Neither does the XMI for the MOF Core itself contain an XMI tag to
define that the nsuri and prefix should be as just quoted.


In any case these important values should be included in the
specification documents as well as being buried in tags in the XMI
files.

Resolution:
Revised Text: OMG Issue No: 7783 Title: Missing XMI tags in spec and XMI rendition of metamodel In the XMI for Superstructure for example (in OMG document ad/03-04-02), while this xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not contain any XMI tags to define for UML what its nsuri and prefix should be: which are needed in order to generate the UML xsd. Neither does the XMI for the MOF Core itself contain an In any case these important values should be included in the specification documents as Add the following text to the end of Appendix A: XMI Serialization and Schema XMI allow the use of tags to tailor the schemas and documents that are produced using XMI. The following have been explicitly set for the UML2 Infrastructure Model; the others are left at their default values: • tag nsURI set to "http://schema.omg.org/spec/UML/2.0/umlL0.xml" for L0 • tag nsURI set to "http://schema.omg.org/spec/UML/2.0/umlLM.xml" for LM • tag nsPrefix set to "uml" (for both cases) Changes to MOF: Add the following text to the end of Appendix A: XSD and XMI for MOF 2.0 XMI allows the use of tags to tailor the schemas that are produced and the documents that are produced using XMI. The following have been explicitly set for EMOF; the others are left at their default values: • tag nsURI set to "http://schema.omg.org/spec/MOF/2.0/emof.xml" • tag nsPrefix set to "emof" The following have been explicitly set for CMOF; the others are left at their default values: • tag nsURI set to http://schema.omg.org/spec/MOF/2.0/cmof.xml • tag nsPrefix set to "cmof" Disposition: Resolved
Actions taken:
September 24, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7889: Inconsistent use of 'Element' between MOF and UML (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.
 
Proposed resolution:
 
MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.

Resolution:
Revised Text: Resolution: In MOF Core, Element and Object will have their names swapped as proposed. There is no effect on Infrastructure: MOF is in effect merging in Object as a new superclass to Element. Figure 2 · Replace class name "Element (from Elements)" by "Object" · Replace class name "Object" by "Element" · Replace the 7 operations for the Object (now Element) class by the following: getMetaClass() : Class container() : Element equals(object : Object) : Boolean get(property : Property) : Object set(property : Property, object: Object) isSet(property : Property) : Boolean unset(property : Property) · Replace the 3 operations for the Factory class by the following: createFromString(dataType : DataType, string : String) : Object convertToString(dataType : DataType, object: Object) : String create(metaClass : Class) : Element Section 9.1 · Change section name from Object to Element · Replace the first para by the following: Every Element has a Class which describes its properties and operations. The Element is an Instance of this Class. Element extends Abstraction::Elements::Element. All model elements that specialize Reflection::Element inherit reflective capabilities. In particular, this includes all model elements from UML2 Infrastructure. · Replace the Operations section by the following text: getMetaClass() : Class Returns the Class that describes this element. container(): Element Returns the parent container of this element if any. Return Null if there is no containing element. equals(object: Object): Boolean Determines if the object equals this Element instance. For instances of Class, returns true if the object and this Element instance are references to the same Object. For instances of DataType, returns true if the object has the same value as this Element instance. Returns false for all other cases. get(property: Property) : Object Gets the value of the given property. If the Property has multiplicity upper bound of 1, get() returns the value of the Property. If Property has multiplicity upper bound >1, get() returns a ReflectiveSequence containing the values of the Property. If there are no values, the ReflectiveSequence returned is empty. ReflectiveSequence is defined in section "MOF::Common" on page 24. Exception: throws IllegalArgumentException if Property is not a member of the Class from class(). set(property: Property, object: Object) If the Property has multiplicity upper bound = 1, set() atomically updates the value of the Property to the object parameter. If Property has multiplicity upper bound >1, the Object may be either a ReflectiveCollection or a ReflectiveSequence. The behavior is identical to the following operations performed atomically: ReflectiveSequence list = element.get(property); list.clear(); list.addAll((ReflectiveSequence) object); There is no return value. Exception: throws IllegalArgumentException if Property is not a member of the Class from getMeta-Class(). Exception: throws ClassCastException if the Property's type isInstance(object) returns false and Property has multiplicity upper bound = 1 Exception: throws ClassCastException if Object is not a ReflectiveSequence and Property has multiplicity upper bound > 1 Exception: throws IllegalArgumentException if object is null, Property is of type Class, and the multiplicity upper bound > 1. isSet(property: Property): Boolean If the Property has multiplicity upper bound of 1, isSet() returns true if the value of the Property is different than the default value of that property. If Property has multiplicity upper bound >1, isSet() returns true if the number of objects in the list is > 0. Exception: throws IllegalArgumentException if Property is not a member of the Class from class(). unset(property: Property) If the Property has multiplicity upper bound of 1, unset() atomically sets the value of the Property to its default value for DataType type properties and null for Class type properties. If Property has multiplicity upper bound >1, unset() clears the ReflectiveSequence of values of the Property. The behavior is identical to the following operations performed atomically: ReflectiveSequence list = element.get(property); list.clear(); There is no return value. After unset() is called, element.isSet(property) == false. Exception: throws IllegalArgumentException if Property is not a member of the Class from getMetaClass(). Constraints No additional constraints. Semantics Class Element is the superclass of all model elements in MOF, and is the superclass of all instances of MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Object, MOF supports any number of meta layers as described in Chapter 1, "MOF Architecture". The following describes the interaction between default values, null, isSet, and unSet. Single-valued properties: If a single-valued property has a default: o It is set to that default value when the element is created. isSet=false o If the value of that property is later explicitly set, even to the default value, isSet=true o If the property is unSet, then the value of the property returns to the default, and isSet=false If a single-valued property does not have a default: o At creation, its value is null. isSet=false o If the value of that property is later explicitly set, even to null, isSet=true o If the property is unSet, then the value of the property returns to null, and isSet=false Multi-valued properties: o When the element is created, it is an empty list. isSet=false o If the list is modified in any way (except unSet), isSet=true o If the list is unSet, it is cleared and becomes an empty list. isSet=false. The implementation of isSet is up to the implementer. In the worst case it can be implemented by having an additional boolean, but usually for a particular implementation it can be implemented more efficiently (e.g. by having an internal distinguished value used to represent "no value set"). For default values, implementations are not required to access stored metadata at runtime. It is adequate to generate a constant in the implementation class for the default. Rationale Element is introduced in package Reflection so that it can be combined with Core::Basic to produce EMOF which can then be merged into CMOF to provide reflective capability to MOF and all instances of MOF. Section 9.2 Replace Operations section by the following text Operations createFromString(dataType: DataType, string: String): Object Creates an Object initialized from the value of the String. Returns null if the creation cannot be performed. The format of the String is defined by the XML Schema SimpleType corresponding to that datatype. Exception: NullPointerException if datatype is null. Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage(). convertToString(datatype: DataType, object: Object): String Creates a String representation of the Object. Returns null if the creation cannot be performed. The format of the String is defined by the XML Schema SimpleType corresponding to that dataType. Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage(). create(metaClass: Class): Element Creates an element that is an instance of the metaClass. Element::metaClass == metaClass and metaClass.isInstance(element) == true. All properties of the element are considered unset. The values are the same as if element.unset(property) was invoked for every property. Returns null if the creation cannot be performed. Classes with abstract = true always return null. The created element's metaClass == metaClass. Exception: NullPointerException if class is null. Exception: IllegalArgumentException if class is not a member of the package returned by getPackage(). Add new section 9.3 as follows: 9.3 Object Reflection introduces Object as a supertype of Element in order to be able to have a Type that represent both elements and data values. Object represents 'any' value and is the equivalent of java.lang.object in Java. Section 10 · Replace the first sentence by: An element has an identifier in the context of an extent that distinguishes it unambiguously from other elements. Figure 3 · Replace "Element( (from Elements)" by "Object" · In class Extent, replace objects(): ReflectiveSequence by elements(): ReflectiveSequence · In class URIExtent, replace uri(object:Object): String by uri(element:Element): String · And replace object(uri:String): Object by element (uri:String): Element Section 10.1 · Replace first para by: An Extent is a context in which an Element in a set of Elements in a set can be identified. An element may be a member of zero or more extents. An Extent is not an Element, it is part of a MOF capability. · Replace Operations section by: useContainment(): Boolean When true, recursively include all elements contained by members of the element(). elements(): ReflectiveSequence Returns a ReflectiveSequence of the elements directly referenced by this extent. If exclusive()==true, these elements must have container()==null. Extent.elements() is a reflective operation, not a reference between Extent and Element. See Chapter 4, "Reflection" for a definition of ReflectiveSequence · Replace Rationale section by: Extents provide a context in which MOF Elements can be identified independent of any value in the Element. Section 10.3 · Replace first sentence by: Identity extends Basic::Property with the ability to designate a property as an identifier for the containing element. · Replace Rationale by: Objects must have identity. The Property isID formalizes this capability in the metadata describing the object.. Section 10.4 · Replace first sentence by: An extent that provides URI identity. A URIExtent can have a URI that establishes a context that may be used in determining identifiers for elements identified in the extent. Implementations may also use values of properties with isID==true in determining the identifier of the element. · Replace Operations section by contextURI(): String Specifies an identity for the extent that establishes a URI context for identifying elements in the extent. An extent has an identity if a URI is assigned. URI is defined in IETF RFC-2396 available at http://www.ietf.org/rfc/rfc2396.txt. uri(element: Element): String Returns the URI of the given element in the extent. Returns Null if the element is not in the extent. element(uri: String): Element Returns the Element identified by the given URI in the extent. Returns Null if there is no element in the extent with the given URI. Note the Object does not (necessarily) contain a property corresponding to the URI. The URI identifies the element in the context of the extent. The same element may have a different identifier in another extent. · Replace Rationale by URIs are the defacto standard identity mechanism for the Web and are therefore useful for identifying MOF elements and navigating links between them. Figure 5 · Replace operations in ReflectiveCollection with: add(object : Object) : Boolean addAll(elements : ReflectiveSequence) : Boolean clear() remove(object : Object) : Boolean size() : Integer · Replace operations in ReflectiveSequence with: add(index : Integer, object : Object) get(index : Integer) : Object remove(index : Integer) : Object set(index : Integer, object : Object) : Object Section 10.5.1 · Replace entire section with the following: 10.5.1 ReflectiveCollection RefelectiveCollection is a reflective class for accessing properties with more than one possible value. It is defined in package MOF::Common in order to facilitate reuse in many other MOF capabilities. For ordered properties, ReflectiveSequence (see below) must be returned. Modifications made to the ReflectiveCollection update the Element's values for that property atomically. Exception: throws ClassCastException if the Property's type isInstance(Element) returns false. add(object : Object): Boolean Adds object to the last position in the collection. Returns true if the object was added. addAll(objects: ReflectiveSequence): Boolean Adds the objects to the end of the collection. Returns true if any objects were added. clear() Removes all objects from the collection. remove(object : Object): Object Removes the specified object from the collection. Returns true if the object was removed. size(): Integer Returns the number of objects in the colleciton. Section 10.5.2 · Replace entire section with the following: 10.5.2 ReflectiveSequence ReflectiveSequence is a subclass of ReflectiveCollection that is used for accessing ordered properties with more than one possible value. Modifications made to ReflectiveSequence update the Element's values for that property atomically. Modifications made to the ReflectiveSequence update the Element's values for that property atomically. Exception: throws IllegalArgumentException if a duplicate would be added to the collection and Property.isUnique()==true. Exception: throws IndexOutOfBoundsException if an index out of the range of 0 <= index < size() is used. Exception: throws IllegalArgumentException if a duplicate would be added to the list and Property is of type Class or Property.isUnique()==true. add(index: Integer, object : Object) Adds object to the specified index in the sequence, shifting later objects. get(index: Integer): Object Returns the object at the given index in the sequence. remove(index: Integer): Object Removes the object at the specified index from the sequence. Returns the object removed. set(index: Integer, object: Object): Object Replaces the object at the specified index with the new object. The removed object is returned. Behavior of particular operations defined in ReflectiveCollection is the following when applied to a ReflectiveSequence: add(object: Object): Boolean Adds object to the end of the sequence. Returns true if the object was added. addAll(objects: ReflectiveSequence): Boolean Adds the objects to the end of the sequence. Returns true if any objects were added. remove(,object: Object): Boolean Removes the first occurence of the specified object from the sequence. Figure 5 · Replace the Object superclass with Element Figure 13 · Replace the Element (from Elements) superclass with Object · Replace the class Object with Element · Replace the following operation on Object (now Element): invoke(op : Operation, arguments : Argument) : Element with: invoke(op : Operation, arguments : Argument) : Object · Replace the 3 operations on Factory with: name : String createElement (class : Class, arguments : Argument) : Element createLink(association : Association, firstElement : Element, secondElement: Element) : Link · Replace the 4 operations on Extent with: elementsOfType(type : Class, includeSubtypes : Boolean) : Element linksOfType(type : Association) : Link linkedElements(association : Association, endObject : Element, end1ToEnd2Direction : Boolean) : Element linkExists(association : Association, firstElement : Element, secondElement : Element) : Boolean · Replace the 2nd property of Argument with: value: Object · Replace the association ends firstObject and secondObject with firstElement and secondElement. Section 13.1 · Replace entire section with the following text: 13.1 Link This is a new class that represents an instance of an Association, in the same way that Element represents an instance of a Class. Properties association: Association This is the Association of which the Link is an instance. firstElement: Element This is the Element associated with the first end of the Association. secondElement: Element This is the Element associated with the second end of the Association. Operations equals(otherLink:Link): Boolean Returns True iff the otherLink has association, firstElement, secondElement all equal to those on this Link. delete() Deletes the Link. This may leave the same elements associated by other links for this Association. Constraints The firstElement must conform to the type of the first memberEnd of the association. The secondElement must conform to the type of the second memberEnd of the association. The set of Links as a whole must not break the multiplicity constraints of the association member ends. Semantics When the link is created, it is not assigned to any Extent. Rationale Since MOF 2.0 allows the same pair of elements to be linked more than once in the same Association (if isUnique=false for the association ends), then Link needs to be more a simple tuple value, though not as heavyweight as a first class Element. Changes from MOF 1.4 None. The MOF 1.4 navigation capabilities are retained. Section 13.2, Argument · Replace entire section with the following: 13.2 Argument This is a new datatype that is used to represent named arguments to open-ended reflective operations. It is open-ended and allows both Elements and data values to be supplied. Properties name: String The name of the argument. value: Object The value of the argument. Constraints None: constrains will be dependent on the context of where the Argument is supplied. Semantics None. Rationale Since MOF 2.0 allows Operation parameters and Properties to have defaults, it is necessary to explicitly identify the values supplied. Changes from MOF 1.4 Values supplied to constructors are now identified rather than being deduced through the ordering. Section 13.3 · Introduce new section for Element that was previously called Element and not given a section number but 'lost' in 13.2 13.3 Element CMOF Reflection adds the following extra operations. Operations delete() Deletes the Element. invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] Calls the supplied Operation on the element, passing the supplied Arguments and returning the result. The Operation must be defined on the Class of the Element, and the arguments must refer to Parameters of the Operation. If an Argument is not supplied for a Parameter its default value, if any, will be used. isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean Returns true if this element is an instance of the supplied Class, or if includeSubtypes is true, any of its subclasses. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Parameters to operations are now identified by name. Section 13.3, Factory Renumber to 13.4 (due to reinstatement of Object - see previous change) and replace test with the following: 13.4 Factory CMOF Reflection adds two extra operations. Operations createElement(class:Class, arguments : Argument[0..*]) : Element Unlike the simple create() operation this allows arguments to be provided for use as the initial values of properties. The arguments must refer to DataType Properties of the Class. If an Argument is not supplied for a Property its default value, if any, will be used. createLink(association : Association, firstElement : Element, secondElement : Element) : Link This creates a Link from 2 supplied Elements that is an instance of the supplied Association. The first Element is associated with the first end (the properties comprising the association ends are ordered) and must conform to its type. And correspondingly for the second Element. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Names have changed. Section 13.4, Factory Renumber to 13.5 (due to reinstatement of Object - see previous change) and replace test with the following: 13.5 Extent CMOF Reflection adds four extra operations. Operations elementsOfType(type : Class, includeSubtypes : Boolean) : Element [0..*] This returns those elements in the extent that are instances of the supplied Class. If includeSubtypes is true, then instances of any subclasses are also returned. linksOfType(type : Association) : Link[0..*] This returns those links in the extent that are instances of the supplied Association. linkedElements(association : Association, endElement : Element, end1ToEnd2Direction : Boolean) : Element [0..*] This navigates the supplied Association from the supplied Element. The direction of navigation is given by the end1ToEnd2Direction parameter: if true, then the supplied Element is treated as the first end of the Association. linkExists(association : Association, firstElement : Element, second Element : Element): Boolean This returns true if there exists at least one link for the association between the supplied elements at their respective ends. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Names have changed. Disposition: Resolved
Actions taken:
November 1, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7908: Design principles (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:
 have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is

Resolution:
Revised Text:
Actions taken:
November 10, 2004: received issue
August 23, 2006: closed issue

Discussion:
One can argue for and against the thesis in this issue. However, it is, in essence, a critique
that does not really indicate how the problem is to be fixed other than to redo all of UML
2.0 from the beginning. Since that falls outside the scope of an RTF and also of reality,
this issue will be closed with no changes made.
Disposition: Closed, no change


Issue 7909: Problem with diagram references in Profiles section (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").

But the 2 references should be to Figure 456 and Figure 461 respectively.


Resolution:
Revised Text: The following change needs to be made in both the Infrastructure (ptc/04-11-16) and Superstructure specs (ptc/04-10-02) – with the appropriate figure numbers for each document. In the 2nd paragraph in Profile:Stereotype Semantics Change the text An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C"). Into An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 456). At the model level (such as in Figure 461) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").
Actions taken:
November 14, 2004: received issue
August 23, 2006: closed issue

Discussion:


Issue 7910: isComposite inconsistency in UML 2.0 and MOF 2.0 (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: -- isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. -- However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()->isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

Resolution:
Revised Text:
Actions taken:
November 15, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7938: DataType attributes UML 2 Super (ptc/04-10-02) (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.

Resolution: See issue 7939 for disposition
Revised Text:
Actions taken:
November 19, 2004: received issue
August 23, 2006: closed issue

Issue 7939: DataType attributes UML 2 Super (ptc/04-10-02) (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.

Resolution:
Revised Text: Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedAttribute on page 59. Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedOperation on page 59. Infrastructure (ptc/04-11-16) Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedAttribute on page 140. Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedOperation on page 140.
Actions taken:
November 19, 2004: received issue
August 23, 2006: closed issue

Issue 7942: Section: 7.3.43 (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
Notation for a primitive type should be <<primitiveType>> instead of <<primitive>>. That's more consistent to the general usage of keywords that they are identical to the metaclass name

Resolution:
Revised Text:
Actions taken:
November 22, 2004: received issue
August 23, 2006: closed issue

Discussion:
This argument may be valid, but the impact of making this change at this point when
tools have been released and books have been published based on the old notation, it
simply does not seem to be worth the disruption that it would cause.
Disposition: Closed, no change


Issue 7946: Section: 7.2.8 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel. 

Resolution: see above
Revised Text: In the Infrastructure spec in section 7.2.8 on page 29, replace the following text: When a language is reflective, there is no need to define another language to specify its semantics. MOF is reflective since it is based on the InfrastructureLibrary, and there is thus no need to have additional meta-layers above MOF. by the following text: MOF is reflective since it is based on the InfrastructureLibrary. This allows it to be used to define itself. For this reason, no additional meta-layers above MOF are defined.
Actions taken:
November 23, 2004: received issue
August 23, 2006: closed issue

Discussion:
The submitter raises a philosophical point that may be valid and is certainly debatable.
However, the quoted statement was in the specific context of the explanation of the 4-
layer model, where it was used to justify why the architecture stops the potentially
infinite succession of metalevels at M3.
However, the text itself can be modified to avoid making a statement that can be
misunderstood as being a general statement.


Issue 7947: Classes (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that. 

Resolution: See issue 8069 for disposition
Revised Text:
Actions taken:
November 24, 2004: received issue
August 23, 2006: closed issue

Discussion:


Issue 7948: section 2.10.4.1 detailed semantics of collaborations (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:


"However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."


Allow me to illustrate my interpretation of this section by means of an example.


Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?


Then, the spec goes on:


"Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."


So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.


Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.


Resolution:
Revised Text:
Actions taken:
November 24, 2004: received issue
August 23, 2006: closed issue

Discussion:
This issue appears to be against UML 1.x, as the semantics of collaboration does not
contain the cited passages and it relies on concepts that have been removed in UML 2.0.
Collaborations have been clarified significantly in UML 2.0; the author of this issue is
invited to check whether his concern still exists.
Disposition: Closed, no change


Issue 7949: Section: 7.3.44 - OCL incorrect (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [1] If this property is owned by a class, associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif 

Resolution: See issue 6201 for disposition
Revised Text:
Actions taken:
November 26, 2004: received issue
August 23, 2006: closed issue

Issue 7950: Interactions (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
In the description of the Graphic Paths for a Communication Diagram I can
find no mention of what the lines between the Lifelines correspond to -
although I did find this in the description of Message: "On Communication
Diagrams, the Messages are decorated by a small arrow along the connector
close to the Message
name and sequence number in the direction of the Message." I assume this
means that the lines correspond to a Connector model element.


The Graphic Paths section should be updated to include this information and
justification added as to why a Connector is needed in order for Messages to
be shown between two lifelines on a Communication Diagram (this seems an
overly tight constraint to me).

Resolution: see above
Revised Text: Before (14.3.20 page 540): On Communication Diagrams, the Messages are decorated by a small arrow along the connector close to the Message name and sequence number in the direction of the Message. Revised text: On Communication Diagrams, the Messages are decorated by a small arrow in the direction of the Message close to the Message name and sequence number along the line between the lifelines (See Table 17 and Figure 351).
Actions taken:
November 26, 2004: reeived issue
August 23, 2006: closed issue

Discussion:
The line between two lifelines of a Communication Diagram is merely a placeholder for
the set of message identifiers (including sequence numbers) for messages between these
lifelines. Messages are also in sequence diagrams associated with connectors (optionally),
and there is no difference for Communication Diagrams.
On your resolution; I understand that this graphic path is not associated to a connector
but I found the use of the term "connector" in the description confusing and I think it
should be replaced. I also think that the graphic paths section for any diagram should
include all graphic paths, even if they don't represent abstract syntax elements.


Issue 7951: UML 2 Super Basic Interactions (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Basic Interactions includes SendOperationEvent whose superclass is
MessageEvent, which is in CommonBehaviors::Communications.


The problem is that the Basic Interactions package is in Level 1, but
CommonBehaviors::Communications is in Level 2.


The same is true for SendSignalEvent. In fact Event itself is also in
Communications so there's a problem with the whole set of Event subtypes
defined in BasicInteractions.

Also BasicActions::SendSignalAction references Communications::Signal

Resolution: Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 26, 2004: received issue
October 27, 2008: closed issue

Issue 7952: Alternative entry and exit point notation is ambiguous (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

Resolution:
Revised Text:
Actions taken:
November 29, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7956: InfrastructureLibrary defines, but should not use package merge (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2. 

Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level. 

Resolution: closed no change
Revised Text: Add the following to the end of the first paragraph in section 10, just before Figure 64: Figure 64 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Basic. Package Basic imports model elements from package PrimitiveTypes. Basic also contains metaclasses derived from shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Basic by copy. Add the following to the end of the paragraph just before figure 70. Figure 70 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Constructs. Package Constructs imports model elements from package PrimitiveTypes. Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy. Figure 70 uses PackageMerge to illustrate the packages that contribute to the definition of Constructs and how. The InfrastructureLibrary metamodel does not actually include these packages merges as Constructs is a complete metamodel that already includes all the metaclasses in the referenced packages. This allows Constructs to be understood and used without requiring the use of PackageMerge. Disposition: Resolved
Actions taken:
December 1, 2004: received issue
August 23, 2006: closed issue

Discussion:
Before 7623, InfrastructureLibrary defined, but did not use package merge. Packages in Abstractions were only imported into Basic and Constructs. And because neither Basic nor Constructs actually referred to anything in Abstractions, these imports had no consequence one way or the other. They had no effect on the merge, and no effect on XMI and/or XSD generation for either MOF2 or UML2.
However, changing them to merges, and modifying Constructs so a merge is required to make it complete changes things. In order to actually do the package merges resulting from 7623, and to generate the XMI and XSD for EMOF, CMOF, and all of the UML2 compliance levels, Abstractions must be cleaned up.  That is, all of the extraneous superclasses have to be removed, the proper superclasses from dependent packages have to be added in order for all references to be resolved before the merge, and any other errors that may be in Abstractions will need to be corrected. The full extent of the required changes cannot be known until the merges are actually attempted.
Both the Superstructure and MOF/Infra FTFs have agreed to defer Abstractions issues. Therefore, the resolution to issue 7623 should be amended so that Abstractions is not merged into Constructs, and therefore any issues resulting from these merges can be deferred. As a result, Abstractions will remain more decoupled from the rest of MOF2 and UML2 making it easier to address the deferred issues in an RTF. 
The "import"s that were in Figure 70 are not actually necessary. These are left over from the old definition of package merge which required the imports in order to make the imported metaclasses visible for subclassing by their corresponding merging classes. The new definition of package merge eliminates this subclassing and therefore the need to retain imports to merged packages. As a result, there are actually no dependencies between the Abstractions packages, Basic, and/or Constructs. 
However, it is still useful to indicate how Basic and Constructs were derived, and how they relate to Abstractions packages that contributed to their definition. This issue was resolved on a previous ballot. Changes are already in the Infra spec.
Disposition: Closed, no change


Issue 7958: should retain Comment and its associations to Element (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

Resolution: This is resolved in the UML 2.2 specification. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
December 1, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:


Issue 7967: An observed time value must be written into a structural feature (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:
TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily

Resolution: Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
December 3, 2004: received issue
October 27, 2008: closed issue

Issue 7969: Section: 9.14.1 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The allOwnedElements query (defined in Core::Abstractions::Ownerships) operates by recursing downward through the ownership hierarchy. Its OCL implementation looks like this: Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) In the absence of sophisticated optimization, this query is only guaranteed to terminate if the ownership hierarchy is non-circular. The ownership hierarchy is guaranteed to be circular by constraint [1] (An element may not directly or indirectly own itself). But the OCL description of constraint [1] is written in terms of the allOwnedElements() query: not self.allOwnedElements()->includes(self) If a modeling tool were to be written based on these rules in a straightforward way, it would never be able to detect a violation of constraint [1]. Instead it would go into infinite recursion while trying to check the constraint. Proposed solution: Add the following operation to 9.14.1: [3] The query isCircularlyOwned walks the chain of direct and indirect owners of an element, checking whether the chain contains any circularities, or any of the elements in the set prohibitedElements. Element::isCircularlyOwned(prohibitedElements: Set(Element)): Boolean; isCircularlyOwned = if owner->isEmpty() then false else if prohibitedElements->including(self)->includes(owner) then true else owner.isCircularlyOwned(prohibitedElements->including(self)) And change constraint [1] to: [1] An element may not be directly or indirectly owned by itself. not self.isCircularlyOwned(Set{}) 

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
December 5, 2004: received issue

Discussion:


Issue 7970: Minor error in BNF of an message argument (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
Minor error in BNF of an message argument: Instead <argument> ::= (<[parameter-name> ‘=’] write <argument> ::= ([<parameter-name> ‘=’] 

Resolution:
Revised Text: Before (in Section 14.3.20 page 540): <argument> ::= (<[parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter- name> [‘:’ <argument-value>] | ‘ -’ Revised: <argument> ::= ([<parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter- name> [‘:’ <argument-value>] ) | ‘ -’
Actions taken:
December 7, 2004: received issue
August 23, 2006: closed issue

Issue 7973: UML 2 Super / Incorrect statement on port visibility (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The updated UML spec p162 states: 

"UML Superstructure 2.0 Draft Adopted Specification 

A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port 
symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its 
visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it 
is protected by default)." 

This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility.  Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). 

Resolution:
Revised Text: Replace the first paragraph of the Notation section on p.177, section 9.3.11 (Port) by "A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. The port symbol may be placed either operlapping the boundary of the rectangle symbol denoting that classifier or it may be shown inside the rectangle symbol."
Actions taken:
December 10, 2004: received issue
August 23, 2006: closed issue

Issue 7977: ReduceAction (uml2-rtf)

Click
here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:
It has come to my attention that the removal of the ReduceAction (fair
enough) requires the use of a variable (a very bad idea) to construct an
alternative specification.
 
To do something like Reduce(<data expression>, Add) in UML 1.5, you
would have to say:


- An activity/structure node with variable Sum.
- The expansion region takes the collection as input and has no
output. In this case, the output collection will have only one
element in it.
- In the region, edges coming from/going to the inputs/outputs take
elements from the input collections and put elements in the output
collections.
- The region uses CallOperationAction with operation timeofLastCall to
get the time and CallBehaviorAction on the (primitive)
FunctionBehavior for addition and updates the variable.
- After the region is complete, the variable has the sum in it.


The 1.5 Action Model included variables so that those who "needed" them
could have them.  However, the introduction of variables changes the
static-single-assignemnt nature of the language and would now require
data-flow analysis of a developer model to work out what is happening.
Before all we had to do was scan for Variable Actions and reject the
developer model so proposed.


In other words, those of us in the translation business did not need
variables, and we could ignore those models that used them.  Now we're
stuck.

Topic: ReduceAction


UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
to elements of a collection until only only element is left.  It did not
constrain order or concurrency of application.  It was replaced with
ExpansionRegion UML 2, which requires commitment to order and
concurrency.

Resolution: Corrections to issue description:
Revised Text: UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 64 ƒ The filer is explaining how to achieve the effect of UML 1.5 ReduceAction with UML 2 ExpansionRegion. It does not actually work, because each input collection must provide at least two values for each cycle on the contents of the region, whereas ExpansionRegion currently only provides one value per input per cycle. ƒ The last paragraph of the discussion is incorrect. The concurrent mode of ExpansionRegion only allows concurrency, it does not require concurrency. In addition, the outputs of ExpansionRegion are collections, whereas the output of ReduceAction is a single element, calculated from the elements of the input collections. Even if a regular output pin is used instead of an ExpansionNode, the output of the contents of the region (the reducing action) must be returned to the input collection for further processing by the action. ReduceAction was inadvertently omitted from the U2P submission. For backwards compatibility with UML 1.5 it is added below, based on the UML 1.5 ReduceAction. Revised Text: In Actions: At end of Abstract syntax section, after Figure 156, add new figure as follows (adds ReduceAction to CompleteActions): Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 65 In Class Descriptions, add entry for ReduceAction, as follows: ReduceAction (from CompleteActions) (CompleteActions) ReduceAction is an action that reduces a collection to a single value by combining the elements of the collection. Generalizations Action (from BasicActions) Description This action takes a collection as input and produces an output by applying a behavior with two inputs pairwise to the elements of the collection. Attributes ƒ isOrdered : Boolean = false Tells whether the order of the input collection should determine the order in which the behavior is applied to its elements. Associations ƒ collection : InputPin [1] The collection to be reduced (subsets Action::input) ƒ reducer : Behavior [1] Behavior that is applied to two elements of the input collection to produce a value that is the same type as elements of the collection. ƒ result : OutputPin [1] Gives the output pin on which the result is put (subsets Action::output). Constraints [1] The type of the input must be a collection. [2] The type of the output must be compatible with the type of the output of the reducer behavior. [3] The reducer behavior must have two input parameters and one output parameter, of types compatible with the types of elements of the input collection. Semantics The behavior is invoked repeatedly on pairs of elements in the input collection. Each time it is invoked, it produces one output that is put back in an intermediate version of the collection. This repeats until the collection is reduced to a single value, which is the output of the action. If isOrdered is false, the order in which the behavior is applied to pairs of values is indeterminate. This will not affect the result of the action if the behavior is commutative and associative, see below. If separate invocations of the behavior affect each other, for example, through side-effects, the result of the actions may be unpredictable, however. If the reducing behavior is not commutative and associative, as with matrix multiplication, the order of the elements in the collection will affect the result of the behavior and the action. In this case, isOrdered should be set to true, so the behavior will be applied to adjacent pairs according to the collection order. The result of each invocation of the behavior replaces the two values taken as input in the same position in the order as the two values. If isOrdered = false, the reducer behavior should be commutative and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is commutative because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Commutativity and associativity are not required, but the result will be indeterminate if isOrdered = false. Notation None. Examples ReduceAction can be used to reduce a list of numbers to the sum of the numbers. It would have one input pin for a collection of numbers, one result pin for a number, and an addition function as the reducer behavior. For example, suppose the input collection has four integers: (2, 7, 5, -3). The result of applying the reduce action to this collection with an addition function is 11. This can be computed in a number of ways, for example, ( ( (2+7) + 5) + -3), (2 + (7 + (5 + -3))), ((2 + 7) + (5 + -3)). Rationale The purpose of ReduceAction is to specify the transformation of a collection to a single value by pairwise application of a behavior, without necessarily committing to the order in which the pairs are chosen. Changes from UML 1.5 ReduceAction replaces ReduceAction in UML 1.5. It has the same functionality, except it takes one collection instead of multiple as input, and produces one result instead of multiple. The effect of multiple input collections can be achieved in UML 2 with an input that is a collection of collections, where the nested collections are created by taking one element from each of the multiple collection inputs to the UML 1.5 ReduceAction.
Actions taken:
December 14, 2004: received issue
August 23, 2006: closed issue

Issue 7986: Section: 14.3.7 (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:
... of an object. (missing period) ... destruction of the instance -> of the object ... that this instanceowns -> instance owns


Resolution: see above
Revised Text: Before (in section 14.3.7 page 519): A DestructionEvent models the destruction of an object New text: A DestructionEvent models the destruction of an object. Editor’s note: The above was already fixed in the copy edit of the formal spec Before: A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. It may result in the subsequent destruction of other instances that this instanceowns by composition (see “Common Behaviors” on page 453). New text: A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. It may result in the subsequent destruction of other objects that this object owns by composition (see “Common Behaviors” on page 453).
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Discussion:
The issue is in principle trivial as the suggestions are meant to be editorial. However,
implicitly the question of using “instance” or “object” sneaks in here. Neither in the
Interactions chapter nor in other chapters is the distinction well established. I have
decided here to propose an editorial change that use “object” whenever we are talking
about an instance of a class, and that is what we are doing here.


Issue 7987: Section: 14.3.13 (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:
... needs not be the whole -> need not be

Resolution:
Revised Text:
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Discussion:
The suggested editorial change is incorrect English.
Disposition: Closed, no change


Issue 7988: Section: 14.3.14 (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:
... <interactionconstraint> -> <InteractionConstraint> ... in Figure 335 -> Figure 335 or 352


Resolution:
Revised Text: Before in section 14.3.14 page 529: Please refer to an example of InteractionConstraints in Figure 335. New text [the editor needs to use cross-references]: Please refer to examples of InteractionConstraints in Figure 335 and Figure 352.
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 7989: Section: 14.3.16 (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:
... and InteractionOperand represent -> represents


Resolution:
Revised Text: Before in Section 14.3.16 pa