Issues for UML 2.4 Superstructure and Infrastructure Revision Task Force

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

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

Issue 4110: Semantics of firing compound transitions still appears to be circular
Issue 4932: Starting state machine
Issue 5107: Starting a state machine
Issue 5886: behaviour of the shallow history state and deep history state
Issue 5977: saying {nonunique} on one end of a binary association is meaningless
Issue 6071: Conditional Node and Loop Node notation missing
Issue 6083: More examples
Issue 6086: More explanation needed on Figure 339
Issue 6088: Parameterization of lifelines
Issue 6114: State extension
Issue 6126: Target pin notation
Issue 6137: Promote local conditions to ExecutableNode
Issue 6150: Notation for method
Issue 6200: UML 2 Super/Metamodel/redefinition and substitutability
Issue 6346: Activity OCL
Issue 6353: Deployment a dependency?
Issue 6368: Join nodes that destroy tokens
Issue 6395: UML 2 Super / State machines / Transition triggers cannot be redefined
Issue 6409: UML 2 Super/Interactions/missing OCL constraints
Issue 6430: UML2 super/ad-03-04-01/Derived attributes and associations
Issue 6441: Integration between behavioral "sublanguages": Interactions and Activities
Issue 6445: Clarification of use case semantics
Issue 6452: UML 2 Super / Missing OCL constraints
Issue 6455: instantiations of Classifiers
Issue 6462: UML 2 Issue: AssociationEnd
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 6495: ptc-03-09-15/Separate classification and generalization in Core::Basic
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 6616: UML Superstructure FTF : isRoot property disappeared
Issue 6624: freeing namespace
Issue 6645: UML 2.0 Superstructure Kernal/Packages
Issue 6681: UML2 Super/Kernel Classes
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 6927: UML 2 Super / Interactions / Ambiguous diagram tags
Issue 6975: missing illustrations of graphical paths for create and destroy messages
Issue 7051: StateMachine - Constraints
Issue 7223: Questions about DataTypes and generalization
Issue 7227: UML2 Super/Deployment/inheritance
Issue 7229: UML2 Super/Deployments/Manifestation
Issue 7254: completion transitions
Issue 7255: Priority of the joint transition
Issue 7329: large overlap between structural features and variables
Issue 7337: inconsistency in the action model
Issue 7338: metaattribute isReadOnly
Issue 7372: surface notation for state machines
Issue 7398: Provide exception handling for all behaviors.
Issue 7400: AssociationClass
Issue 7620: Coupling between StateMachines and Activities
Issue 7910: isComposite inconsistency in UML 2.0 and MOF 2.0
Issue 7952: Alternative entry and exit point notation is ambiguous
Issue 7969: Section: 9.14.1
Issue 7993: Use case extension inconsistencies
Issue 7997: Too much navigability from Generalizations
Issue 8012: Section: Classes, Behavior
Issue 8014: Disjointness should be independent of generalization
Issue 8016: Action for retrieving activity instance
Issue 8020: constrainedElement direction
Issue 8022: Derived union notation
Issue 8023: Association specialization semantics
Issue 8024: End objects of a link In the semantics of AssociationClass
Issue 8026: Contextualized attribute values Figures 121
Issue 8034: Notation for classifierBehavior
Issue 8071: ClassifierInState not supported in UML2.0 ?
Issue 8077: Properties on Association for end objects
Issue 8087: All sections
Issue 8101: Clarify the differences between redefining element and redefined element.
Issue 8102: Multiple typos in ptc/04-10-02
Issue 8111: Section: 9.3.4
Issue 8113: Section: 9.3.6
Issue 8114: Section: 9.3.7
Issue 8126: Section: 9.3.11
Issue 8142: Section: 10.3.11
Issue 8246: namespace
Issue 8249: Section: 12.3.33
Issue 8260: Section: 12.3.40
Issue 8274: UML2/Infra section 11.6.2/ Enumerations should not have attributes
Issue 8278: section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification
Issue 8332: inconsistent description
Issue 8335: ReadStructuralFeatureAction
Issue 8342: Section: 14.3.18
Issue 8353: Section: 14
Issue 8414: Section: 14
Issue 8447: Section 15
Issue 8450: Default values for ValueSpecification are not specified properly
Issue 8464: Section: 16.3.1
Issue 8473: Activities section
Issue 8474: Section: Classes
Issue 8475: Section: Interactions
Issue 8479: Section: Activities - clarification
Issue 8480: Section: Activities : Why is exception type needed?
Issue 8489: ExpansionRegion (behavior in the shorthand notation)
Issue 8492: Section: Activities, LoopNode
Issue 8495: Add constraints on ConditionalNode
Issue 8501: SequenceNode should have way to set output pins in CompleteStructured
Issue 8594: Section: 17
Issue 8616: Section: D.4
Issue 8682: A test cannot be empty
Issue 8684: Add a Constraint
Issue 8686: reword sentence
Issue 8692: Section: 7.3.36
Issue 8693: Section: 10.3.1
Issue 8699: UML2-rtf issue: communication diagram
Issue 8700: Meaning of relationship between iteration clause and Lifeline.selector clau
Issue 8702: Section: Actions
Issue 8722: Misleading statement about multiplicity in AssociationClass
Issue 8725: Clarify multiple inputs to expansion regions
Issue 8748: Operation calls on behavior ports
Issue 8756: Section: Classes
Issue 8757: 1. Deployment
Issue 8758: Association in UseCase 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 8779: ConditionalNode inputs used by more than one test
Issue 8780: Input tokens to LoopNodes should be destroyed when the loop is done
Issue 8786: Arguments of Message
Issue 8787: Numbering
Issue 8788: Variables
Issue 8854: multiplicity should not be used/shown in an communicates association
Issue 8855: Issue 7368 - make Classifier::useCase navigable
Issue 8861: Section: 12.3.2 Action
Issue 8877: Page: 129
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 8893: UseCase and Actors
Issue 8897: OutputPin
Issue 8898: Syntax of Transition
Issue 8899: reply messages in interactions
Issue 8903: page 97, Chapter 10.2.2. MultiplicityElement
Issue 8904: page 134, Chapter 11.4.1
Issue 8920: Page: 62
Issue 8921: Meaning of navigability
Issue 8936: event parameters
Issue 8951: UML 2 Super / Actions / Compliance Levels of Actions
Issue 8952: UML 2 - Invalid subsetting of composition ends
Issue 8965: Section: 14.3.20
Issue 8967: UML SuperStructure - Inconsistency re State Machine terms
Issue 8974: Missing notation for association classes
Issue 8975: UML2 Super / 14.3.13 Interaction
Issue 8977: Property ownership must be consistent across association redefinitions
Issue 9002: Section: Common Behavior (02)
Issue 9008: Section: Classes
Issue 9009: Section: Activities
Issue 9011: Section: Classes
Issue 9012: Section: Classes
Issue 9013: Section: Activities
Issue 9015: Section: Classes
Issue 9017: Section: 16.3.3
Issue 9024: "ownedType" is not a valid element
Issue 9076: Page: 53-55
Issue 9101: (merged) compliance level L1
Issue 9102: (merged) compliance levels L2 and L3
Issue 9111: Page: 492-493
Issue 9120: section, 12.3.27 ExpansionRegion(from ExtarStructureActivities
Issue 9124: Need more flexible notation for activity partitions
Issue 9125: keyword, "buildcomponent", and a stereotype, "buildComponent"
Issue 9145: Page: 107
Issue 9225: No notation for associating Exceptions with Operations
Issue 9230: choice of terminolgy for TransitionKind is non-intuitive
Issue 9234: Operation should be a specialization of TypedElement and MultiplicityElemen
Issue 9236: constraints owned by these properties have no context
Issue 9237: Section: Classes
Issue 9242: /qualifiedName attribute missing on Core::Constructs::NamedElement
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 9256: Optional name attribute in NamedElement is misleading and insufficient
Issue 9330: Page: 338, 339
Issue 9339: consistent ordering of Association::memberEnd and ownedEnd
Issue 9340: Section: 14.4
Issue 9351: UML 2.1/Superstructure/ call triggers vs signal triggers
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 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 9445: Link notation for instance diagrams does not cope with multiple classifiers
Issue 9556: Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter
Issue 9597: Fig 7.14
Issue 9599: New issue on notation for multiple stereotypes
Issue 9605: packagedElement
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 9718: UML 2/ Super / SendSignalEvent erratum
Issue 9720: Action inputs/outputs
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 9812: Page: 64 & 112
Issue 9817: Section: 7.2
Issue 9818: discrepancies between package dependencies and XMI file for Superstructure
Issue 9819: Section: Appendix F
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 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 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 9923: Section: 13 & 14
Issue 9961: navigating from link to link ends
Issue 9962: Subclasses of InstanceSpecification
Issue 9999: Association::isDerived should be derived
Issue 10001: Merged Metam.:Property::class with redefinition of non-inherited property
Issue 10003: Section: 9.12.1
Issue 10074: Invalid mandatory compositions and associations
Issue 10079: Invalid redefinitions introduced into metamodel
Issue 10086: Section: Annex C.1
Issue 10140: Section: 7.3.3
Issue 10345: Section: 7
Issue 10353: UML2: Parameter::isException overlaps with Operation::raisedException
Issue 10376: uml.xsd schema file in ptc/2006-04-05 is not correctly generated
Issue 10382: Meaning of Constraint visibility
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 10474: Connector contract is inflexible
Issue 10512: Section: 15
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 10637: Section: 12.3.38
Issue 10656: clarification on Behavior::specification / meaning of InterfaceRealization
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 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 10827: Consistency in description of ends owned by associations
Issue 10931: State Machines
Issue 10957: UML 2.1.1 - notation for parameter sets
Issue 10974: Explanation of Observation notation
Issue 10976: Section: 15.3.11
Issue 10999: 9.3.9 Invocation Action
Issue 11055: Section: 16.3.2 Classifier (from UseCases)
Issue 11068: Section: 14 Interactions: Lifeline representing an actor
Issue 11092: Section: 14.4 Timing Diagram: Continuous time axis
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 11200: Actor concept was indeed changed
Issue 11234: UML 2.1.2: Path names for CMOF files
Issue 11238: composite subsets
Issue 11272: Section: Annex A: Diagrams
Issue 11273: Section: Annex A: Diagrams
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 11408: UML 2.1.1 - fig 7.14
Issue 11410: simpleTime package problems
Issue 11413: The section titled "Changes from previous UML" is not complete
Issue 11488: ElementImport
Issue 11489: In section 7.3.12 Figure 7.38
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 12158: The spec needs to clarify the isConsistentWith() method for transitions
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 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 12235: Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."
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 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 12279: Section: 18.3.3
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 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 12434: Section: Activities
Issue 12436: first paragraph of section 7.8 UML kernel
Issue 12455: Section 14 Interaction
Issue 12511: Callout notation for many clients/suppliers
Issue 12516: Classifiers
Issue 12528: PackageMerge relationships
Issue 12530: Behavior's parameter list
Issue 12544: role bindings of a CollaborationUse
Issue 12545: Section 10.3.10
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 12584: Keyword ambiguity for DataType Section
Issue 12586: Section 7.3.50 "substitution"
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 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 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 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 12850: operation allConnections
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 13058: 18.3.8 Generalization of stereotyped model elements
Issue 13088: MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug
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 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 13148: Section: 14.3.3 CombinedFragment (from Fragments)
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 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 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 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 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 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 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 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 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 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 13947: Figure 7.38 needs to be revised
Issue 13948: UML2.2 chapter 16 : Actor constraint [1] has invalid OCL
Issue 13992: lowerBound/upperBound constraints and derivations wrong
Issue 13994: Section 9.9 should classifier be added to the diagram on p 50?
Issue 13995: confusion re diagram on p. 83
Issue 14022: Visibility and Import relationships
Issue 14023: nestedClassifier
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 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 14093: BNF of Constructs::Property
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 14263: Japan Superstructure PAS Ballot Comments - comment 6
Issue 14264: Japan Superstructure PAS Ballot Comments - comment 7
Issue 14283: Japan Infrastructure PAS Ballot Comments - comment 6
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 14431: notation of objet flow <<selection>> and <<transformation>>
Issue 14439: errors in OCL statements of Additional Operations?
Issue 14449: PrimitiveType has missing constraints
Issue 14536: Stereotyped Constraints in UML
Issue 14544: Stereotyped Constraints in UML
Issue 14552: Ordered derived unions
Issue 14555: UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual
Issue 14560: Value of a Property
Issue 14563: Cyclick dependency
Issue 14566: CMOF missing several redefined property relationships
Issue 14580: Parameter type of MultiplicityElement::includesMultiplicity()
Issue 14588: are Create messages aynch or synch, or doesn't it matter?
Issue 14621: UML2 - derivation for DeploymentTarget.deployedElement is invalid
Issue 14626: UML2 - definition of Property.opposite is wrong
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 14643: AcceptEventAction notation
Issue 14862: Issue on generalization
Issue 14875: wrong Actor's constraint [1]"
Issue 14889: Wrong Spelling for "development"
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 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 14962: loopVariable ownership
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 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 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 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 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 15268: Term "method activation" deprecated?
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 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 15371: UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype
Issue 15372: Over-general sentence about MOF and Profiles
Issue 15384: Typo: isStric => isStrict
Issue 15394: Ambiguous constraints for transitions
Issue 15399: "unique" annotation
Issue 15400: Nasty UML 2.x Issue - /qualifiedName is not unambiguous
Issue 15401: Qualified name is incorrectly claimed to be unambiguous
Issue 15413: Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency
Issue 15419: The stereotype «Create» and keyword «create» are both defined in the UML 4 document
Issue 15421: UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling
Issue 15427: coveredBy : InteractionFragment [0..1] should be [*]
Issue 15440: Issue on UML 2.4 - notation for Component::provided
Issue 15449: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations
Issue 15451: Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex
Issue 15485: UML 2 issue: connectors typed by Association Class
Issue 15499: Operation::isConsistentWith
Issue 15500: isConsistentWith
Issue 15501: bodyCondition and isQuery
Issue 15525: redefinitionContext of Property
Issue 15622: UML 2.4 - Interaction
Issue 15668: isDerived with DefaultValue
Issue 15708: DecisionNode at all guards evaluated to false
Issue 15711: UML 2.4 - ConditionalNode - Semantics
Issue 15763: No Constraint for multiple associations
Issue 15765: stereotype <<bind>> for defining parameterized classes is nowhere defined
Issue 15766: navigation only possible to generalization but not to specializations of elements
Issue 15768: Wrong constraint on Operation::bodyCondition
Issue 15769: Operation with multiple return parameter
Issue 15774: Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)?
Issue 15781: Property.isReadOnly is redundant with StructuralFeature.isReadOnly
Issue 15787: Parameter semantics related to Behavior and BehavioralFeature
Issue 15788: UML 2.3 Infra 12 Incomplete conformance for infinity
Issue 15791: Deep history for orthogonal states
Issue 15804: Big UML 2.4 problem: missing defaults in XMI
Issue 15822: Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions
Issue 15823: Part document structures in Superstructure need to conform to ISO standard Document Template Conventions
Issue 15849: Creation of an expansion node under an activity is allowed by UML and SysML specifications
Issue 15850: Restrictions on decision nodes
Issue 15870: UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified
Issue 15880: Wrong Classifier Name
Issue 15881: Constraint is Wrong
Issue 15889: Retationships and composite structures
Issue 15890: New notation for attribute
Issue 15898: Statement mistake
Issue 15899: Figure 7.31 propose an “association-like” notation for attributes
Issue 15903: XMI representation of stereotype application
Issue 15930: Tags typed by classes/blocks
Issue 15991: Notation of Lifelines
Issue 15993: Can a Generalization really be in multiple GeneralizationSets?
Issue 16002: Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong
Issue 16043: Section numbering
Issue 16110: typo on page 46
Issue 16111: Figure 15.32
Issue 16115: No Rules for Element Names
Issue 16116: Package URI Attribute Uses Obsolete RFC 2396
Issue 16117: Profile URI Attribute - Mingled URI Definition and Use in XMI
Issue 16118: Metaclass stereotype notion
Issue 16119: Metaclass stereotype notion (02)
Issue 16120: Wrong package name on several Figures
Issue 16164: Typo: "joint" should say "join"
Issue 16169: Figure 15.32
Issue 16210: Property::isID
Issue 16249: State::stateInvariant multiplicity too restrictive
Issue 16267: Missing Namespace in Dependencies package definition?
Issue 16268: Interface element - associations multiplicity not defined
Issue 16292: Use cases specifying the same subject cannot be associated: exception
Issue 16301: UML type Real specification
Issue 16307: A deferrable trigger may have a guard
Issue 16342: Ambiguous stereotype notation
Issue 16350: Navigability orthogonal to end ownership or not?
Issue 16357: UML: unification of OCL declarations
Issue 16359: Number of Compliance Levels
Issue 16360: XML Metadata Interchange (XMI)
Issue 16361: XML Metadata Interchange (XMI) - p9
Issue 16362: Core Package versus Construct Package
Issue 16363: XMI in small caps
Issue 16400: ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile"
Issue 16412: property.opposite
Issue 16483: UML Appendix A : Figure A.3 Two Diagrams of Packages”
Issue 16484: UML Appendix A: After Figure A.4
Issue 16493: UML 2.4: NamedElement.ownedRule could be ordered
Issue 16494: Irritating occurrence of subsystem stereotype in use case example diagrams
Issue 16567: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model
Issue 16569: Relation of message arguments to signature parameters ambiguous
Issue 16570: Message arguments for a Signal signature too restrictive
Issue 16571: Message arguments should not be contained in a message
Issue 16572: OccurrenceSpecification should have at least an optional notation
Issue 16581: UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers
Issue 16582: No XML-Schema for UML-XMI
Issue 16584: EnumerationLiterals in the XMI
Issue 16590: ChangeEvent association mismatch
Issue 16595: MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity
Issue 16596: UML Superstructure Specification
Issue 16634: Subpart I and II are missing in Bookmarks
Issue 16635: "A_realization_abstraction_component" is useless
Issue 16638: RedefinableElement (from Kernel) is preferable
Issue 16639: poor figure resolution and a misspelling: fal...( false )
Issue 16642: {ordered} is rather far from +bodyOutput
Issue 16643: OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."
Issue 16644: role "interval" appears "interva"
Issue 16645: OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."
Issue 16646: misspelling: io-oargument
Issue 16647: Figure 15.2 does not include TransitionKind
Issue 16648: Implicit parameter assignment may cause name clashes
Issue 16649: Validity duration of implicitly assigned parameters in SignalEvent/CallEvent
Issue 16650: default value of ClassifierTemplateParameter#allowSubstitutable is "..."
Issue 16651: V2.4.1 from 11-08-05 on page 14 in Figure 7.3
Issue 16656: default is wrong
Issue 16658: The included use case is always required for the including use case to execute correctly
Issue 16723: Suggestions for editorial changes
Issue 16724: Error in UML diagrams?
Issue 16725: Reference in index to item that does not exist in contents
Issue 16875: V2.4.1 from 11-08-05 on page 14 in Figure 7.3
Issue 16896: ChangeEvent::changeExpression should be of type ValueSpecification
Issue 16897: Abstraction::mapping should be of type ValueSpecification or OpaqueExpression
Issue 16946: Use of term "locus of control"
Issue 16999: UML 2.4/2.5 Aliases
Issue 17096: Concerning Transition and its owned elements
Issue 17127: incorrect upper value of coveredBy of Lifeline
Issue 17131: Core package caption wrong
Issue 17160: how to instantiate associations between stereotypes
Issue 17172: Opposite ends of derived unions should be derived unions
Issue 17202: The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/"
Issue 17226: Message Signature in Interactions and Reception.ownedParameter
Issue 17266: color of the notation is specified
Issue 17268: Add an example for the lifeline head shape
Issue 17283: Package merge on Class metatype causes semantic issues - particularly with state machine context
Issue 17289: Behavior should be derived from Classifier, not Class
Issue 17315: Interaction.action should subset ownedMember in lieu of ownedElement
Issue 17328: LifeLine instead of Lifeline
Issue 17333: Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15
Issue 17366: Constraint [1] uses undefined attribute "ownedAttribute
Issue 17370: What is "top-tier packages of the UML metamodel"?
Issue 17390: Migrate UML::Component's ability to own UML::PackageableElements to UML::Class
Issue 17393: Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier
Issue 17398: Question About Arrows In Communication Diagramms
Issue 17461: missing words in section 14.1
Issue 17464: Link notation for stereotype property value
Issue 17466: DurationObservation#event should be ordered
Issue 17507: Surplus classifier field serialized in Superstructure.xmi
Issue 17530: A comment is a specialization of Element
Issue 17536: Specifying the multiplicity of a part with an attribute
Issue 17547: Operation "isConsistentWith" is not overridden for any RedefinableElement
Issue 17550: Attribute is represented by Property
Issue 17564: applying and associating stereotypes and explanation of all aspects of their serialization
Issue 17565: an instance spec should be a legitimate value of a property typed by a classifier
Issue 18239: test

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

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. 

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.

[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.

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.

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.


 

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.

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.

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.

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

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.

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

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.

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) 

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.

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.

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.

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. 

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.

State should be an extension of type rather than object node.

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.

On CallOperationAction, etc, how do you tell graphically which pin is
the target?

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.

Promote local precondition to ExecutableNode.  There might be other
associations on Action that should be at ExecutableNode

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.

Provide a notation for a behavior used as a method of an operation

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

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.

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.

Not all the constraints in the Activities section have corresponding OCL
specifications. These should be added

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.

If Artifact and Node are classifiers, why is deployment a dependency?
Then runtime artifacts cannot be deployed to runtime nodes.

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>>).

Would be useful if join nodes optionally destroyed tokens not accepted,
especially when using join expressions.

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.

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

Disposition:	Deferred to UML 2.4 RTF

Not all the constraints in the Interactions section (14.3). They should  be added

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

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

Disposition:	Deferred to UML 2.4 RTF

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.

Disposition:	Deferred to UML 2.4 RTF

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.

Disposition:	Deferred to UML 2.4 RTF

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).

Disposition:	Deferred to UML 2.4 RTF

Selection behavior on object nodes should be changed to allow execution
at insertion time, keeping the queue

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.

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.

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

Disposition:	Deferred to UML 2.4 RTF

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.

Disposition:	Deferred to UML 2.4 RTF

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.

Disposition:	Deferred to UML 2.4 RTF

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....

Disposition:	Deferred to UML 2.4 RTF

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.

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.

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)

Disposition:	Deferred to UML 2.4 RTF

section 7.11 Does Property.aggregation have meaning for properties typed by
value types, (Data Type and subtypes)?

Disposition:	Deferred to UML 2.4 RTF

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. 

Disposition:	Deferred to UML 2.4 RTF

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. 

Disposition:	Deferred to UML 2.4 RTF

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) 

Disposition:	Deferred to UML 2.4 RTF

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.) 

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

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

Disposition:	Deferred to UML 2.4 RTF

"[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) ) ) 

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()

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.

Disposition:	Deferred to UML 2.4 RTF

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] 

Disposition:	Deferred to UML 2.4 RTF

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."

Disposition:	Deferred to UML 2.4 RTF

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. 

Disposition:	Deferred to UML 2.4 RTF

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.

Disposition:	Deferred to UML 2.4 RTF

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.

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.

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.)

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.

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.

Disposition:	Deferred to UML 2.4 RTF

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

Disposition:	Deferred to UML 2.4 RTF

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. 

Disposition:	Deferred to UML 2.4 RTF

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. 

Disposition:	Deferred to UML 2.4 RTF

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. 

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.

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.

Disposition:	Deferred to UML 2.4 RTF

Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

Disposition:	Deferred to UML 2.4 RTF

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{}) 

According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
Therefore it seems that the Extend.extendedCase property is redundant and should be derived.
 
Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}.
 
 
Proposed resolution
-----------------------------
 
1) Update Figure 401 to replace +extendedCase by +/extendedCase
 
2) Update Figure 401 to replace +useCase by +useCase {subsets owner}.
 
3) Section 16.3.3 Extend: update the Associations section to replace:
extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

by

/extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
No additional associations
 
by
 
useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)
 

Disposition:	Deferred to UML 2.4 RTF

This is a significant issue with the Superstructure, Classes chapter, PowerTypes package, impacting implementability and consistency between products at different levels of conformance to UML 2.
 
I propose to simplify the abstract syntax to specify a one way arrow navigating a one-many metassociation from GeneralizationSet to Generalizations that belong to that set.  The problem here is very much the same as the problem with dependency, but in a different part of the metamodel.
 
Figure 18, The contents of PowerTypes package shows a many-many navigable association between GeneralizationSet.generalization and Generalization.generalizationSet.  
 
Problems with this:
 
1.  only 1-way navigation is desired. As toolvendor I don't want to update the Generalization to have any info wrt what if any GeneralizationSets it belongs to.  As a user, I do not want the generalization relationship itself, which is very simple in a UML Level 1 product, to be muddied with extra info in a UML product that goes beyond Level 1 by adding support for PowerSets.

2.  only 1-many cardinality is desired. Although not navigable,  a mapping from generalization to the generalization set is still provided in the metamodel, in a conceptual sense. 
 
Point 2 is consistent with thinking of the specialization classifier in the generalization as being an instance of more than one powertype, because this classifier is just a participant in the generalization, it is the generalization that we want to have a mapping to at most one powertype.  The scope of the required change is limited to the text and diagram specifying this metasssociation of GeneralizationSet.

Disposition:	Deferred to UML 2.4 RTF

There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

Disposition:	Deferred to UML 2.4 RTF

Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

Disposition:	Deferred to UML 2.4 RTF

Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications. 

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.

constrainedElement direction The association between Constraint and Element named "constrainedElement" is unidirectional from Constraint to Element. This means implementations are not required to provide efficient navigation from an element to the constraints on it. Since the constraints of a model element are part of the definition of that element, the required navigation should at least be from the element to the constraint. 

Disposition:	Deferred to UML 2.4 RTF

Derived union notation Why is the semantics and notation for subsetting/redefinition in Association, while derived union is in Property? 

Disposition:	Deferred to UML 2.4 RTF

Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean? 

Disposition:	Deferred to UML 2.4 RTF

End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity. 

Disposition:	Deferred to UML 2.4 RTF

Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 

Disposition:	Deferred to UML 2.4 RTF

Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

Disposition:	Deferred to UML 2.4 RTF

In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.
 
Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

Disposition:	Deferred to UML 2.4 RTF

The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

Disposition:	Deferred to UML 2.4 RTF

With the new format of putting all of the diagrams at the beginning of the chapters, I am finding it very difficult to determine which diagram goes with what sub-section. Add references in the text to the diagram most applicable to the descriptions/definitions

Disposition:	Deferred to UML 2.4 RTF

Clarify the differences between redefining element and redefined element.

Disposition:	Deferred to UML 2.4 RTF

Multiple typos (If you don't want them submitted this way, I'll complete an issue for each.) section 6.34 page 11 Delete word “to” in “The read/write actions can also be used to by one…” section 7.3.3 page 38 Delete word “If’ in the Note “If the lower multiplicity for an end of…” Section 7.3.5 page 46 Correct typo “pr” to “or” in ownedParameter:Parameter[*] Section 7.3.11 page 60 Change “has” to “have” in 2nd para 2nd sentence “Instances of a data type that “has”…” Instances is the subject of the sentence Section 7.3.11 page 61 Add word “to” to Notation sentence 6 “In this case, cone or more arrows with their tails on the clients are connected “to” the tails…” Section 7.3.20 page 71 Change “is” to are in generalizationSet “Designates a set in which instances of Generalization “are” considered members.” The verb refers to the subject of the which clause (instances). Section 7.3.21 page 83 Change “is” to “if” in last sentence of section “Or, “if” a new subclass…” Section 7.3.32 page 97 Change “These constraint” to “These constraints” Section 7.3.32 page 98 Delete word “is” in 2nd sentence of Notation “In general, the notation will include a multiplicity specification shown as…” Section 7.3.37 page 111 Change “is” to “are” in 4th paragraph of Semantics “The public contents of a package are…” Subject of the sentence is contents not package. Section 7.3.49 page 135 and page 136 (Description) Change verb “specify” to “specifies” in “A structureal feature is a typed feature of a classifier that specifies the structure…” Section 7.3.49 page 137 Change verb from “signifies” to signifying” in 1st sentence of Decsription Section 7.3.53 page 139 Delete word “of” in 1st sentence of Semantics 

Disposition:	Deferred to UML 2.4 RTF

OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints

Disposition:	Deferred to UML 2.4 RTF

Need OCL notation for Constraints. Correct page reference number for StructuredClassifier

Disposition:	Deferred to UML 2.4 RTF

Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added.

Disposition:	Deferred to UML 2.4 RTF

According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints

Disposition:	Deferred to UML 2.4 RTF

Need to write the info for the Changes from previous UML section or remove it

Disposition:	Deferred to UML 2.4 RTF

The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

Disposition:	Deferred to UML 2.4 RTF

Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two.

Disposition:	Deferred to UML 2.4 RTF

Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation

Disposition:	Deferred to UML 2.4 RTF

11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).
 
Proposed resolution:
Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

Disposition:	Deferred to UML 2.4 RTF

In Super (but not Infra) EnumerationLiteral inherits from InstanceSpecification.
This allows a single Enumeration value e.g. 'private' or 'red' to have many slots (InstanceSpecification.slot).
Moreover it allows the value to have many classifiers (InstanceSpecification.classifier) independently of the Enumeration that owns the EnumerationLiteral - it does not make any sense to have this redundant property.
 
All that is needed surely is a value: so if anything EnumerationLiteral should inherit from ValueSpecification. However this still inherits too much: for example an EnumerationLiteral should be owned only by its Enumeration and so should not inherit from PackageableElement as does ValueSpecification. Furthermore inheriting from TypedElement seems to introduce capability that is not catered for in the notation etc: if anything the underlying type for an Enumeration should be specified at the Enumeration not the EnumerationLiteral level (which would allow the different alternatives for an Enumeration to have different types).
 
The only useful capability on EnumerationLiteral is that it should have a name (which is all that Infrastructure allows), and optionally a value. The latter should be specified in the same way as the default value of a Property.
 
Proposed resolution:
EnumerationLiteral should inherit only from NamedElement.
It should have an optional property:
 value:ValueSpecification [0..1]
 
The Notation section should describe how to indicate the value, which should be the same as for the default value of a Property

Disposition:	Deferred to UML 2.4 RTF

There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

Disposition:	Deferred to UML 2.4 RTF

This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well. 

Disposition:	Deferred to UML 2.4 RTF

Second sentence in sub-section Description is missing a word. "...the contents of the referred Interaction xxx [from?? to??] where the InteractionUse is." Change the class name of the association argument:InputPin[*] either on fig 333 to InputPin or to Action in the text. Class name in fig. 333 is Action. This association is also shown in the figure as ordered. Association actualGate:Gate[*] subsets ownedElement. Mention specialization in definition of the association. I'm confused between the BNF use of io-argument and your use of argument. If the name of the association is "io-argument" as indicated by BNF and Issue 1751, should the name on the diagram and in the sub-section Associations be changed to io-argument? Also, para 2 on og 534 italizes argument instead of io-argument. Typo - Second sent. on pg. 534 needs a space between "explained" and "in."

Disposition:	Deferred to UML 2.4 RTF

Add Ocl notation to constraints where possible or note that OCL notation is not possible. Page numbers of odd numbered pages are not in the same place as the are for other chapters. Move them to the lower right corner. Delete sub-section headings where the sub-section contains no information or state "None." If a concept is not "(as specialized)" and there are no atttributes, associations, etc. write "None" instead of "No additional xxx." Not all of the figures contain package names for the generalized parents. Add as many of these as possible or use the ellipses as appropriate.

Disposition:	Deferred to UML 2.4 RTF

How to show class operation calls in interaction diagrams? A discussion in the umlforum list came to the conclusion that the name in the lifeline header should be the class name. In that case it is not possible to differentiate between "ClassName" only and "RoleName" only. Besides the notational problem I can't see how a class operation call could fit into the interaction meta-model. However it is necessary to show such a call. It's a typical part of an interaction.

The issue here is to be able to describe calls on static methods. Sequence diagrams in
UML 2 do not cover this. It is possible to suggest that the lifeline header text be
augmented by the possibility to write class as a keyword before the class name. This
would indicate that the lifeline represents the imaginary object performing static methods
of that class. There will, however, be cascading effects on static requirements since this
lifeline does not have any counterpart in the composite structure of the enclosing
classifier. For reasons of time pressure, we suggest to defer.

General comments - Delete sub-sections tat are empty or state "None." If class is not "as specialized' do not say "No additional xxxx" but rather "None" or delete the sub-section. Add OCL notation or a note that OCL notation is not available for constraints and/or additional operations and/or derived attributes where appropriate.

Disposition:	Deferred to UML 2.4 RTF

There are a few cases when the default is documented as a ValueExpression, as follows: 
-        JoinNode.joinSpec = {default value is" and"} 
-        ActivityEdge.guard= {default value is "true"} 

These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification. 

They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be: 

        +guard = LiteralBoolean(true) 

The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true. 

Recommendation: 

Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends. 

Disposition:	Deferred to UML 2.4 RTF

Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

Disposition:	Deferred to UML 2.4 RTF

Add presentation option for multiple object flows between two actions, shown as one line. 

Disposition:	Deferred to UML 2.4 RTF

Enumeration should have a constraint that the classifier of its literals is the enumeration

Disposition:	Deferred to UML 2.4 RTF

Interactions: What object receives SendEvent, etc? Affects how AcceptEventAction is used

Disposition:	Deferred to UML 2.4 RTF

Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities. 

Disposition:	Deferred to UML 2.4 RTF

Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

Disposition:	Deferred to UML 2.4 RTF

In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

Disposition:	Deferred to UML 2.4 RTF

In LoopNode, setup, test, and body parts should be owned by the loop node (they were owned by clauses of loop node, which were owned by the loop node). 

Disposition:	Deferred to UML 2.4 RTF

Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.). 

Disposition:	Deferred to UML 2.4 RTF

SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do. 

Disposition:	Deferred to UML 2.4 RTF

Add OCL notation to constraints or a note that OCL notation is not available for this constraint. In the figures show all sub-package names or ellipses associated with the direct generalizations. Use of the words subclass and subclasses is often confusing and inappropriate as these are not shown in associated figures or mentioned in text. Whenever subclasses are mentioned, please clarify by giving examples as was done on page 690. Orgainzation of this Part is confusing after becomming accustomed to the organization used in parts I and II. Placement of all abstract syntax figures in one place helps clarify relationships of figures to each other and makes it easier to see/verify consistency. Names of classifiers and packages in the text often don't agree with the names shown on associated figure.

Disposition:	Deferred to UML 2.4 RTF

In Description for CCMService, either add the ending or remove the opening quotation mark for the last word. The stereotype name for CCMProcess is not the same as that within the guillemets. Complete the Tag cell in CCMHome. Complete the Tag cell in CCMManages. Capitalize and correct spelling of "Always in the Constraints cell of CCMManages. The Description for CCMFactory really doesn't make a lot of sense to me but I'm not at all familiar with CCM Components. However the stereotype name doesn't relate to a create function for me.

Disposition:	Deferred to UML 2.4 RTF

A test cannot be empty since it has at least a decider: 0..* should be changed to 1..*.

Disposition:	Deferred to UML 2.4 RTF

No consistency condition is put between predecessor clauses, for instance two clauses can be the predecessor of each other. Add a Constraint: The transitive closure of predecessorClause must be a strict partial order. 

Disposition:	Deferred to UML 2.4 RTF

" Any test section with a predecessorClause " Should be: " Any test section whose parent clause has a predecessorClause "

Disposition:	Deferred to UML 2.4 RTF

According to fig. 13 an operation is associated with a Datatype. That's not shown in the association section of the class description.

Disposition:	Deferred to UML 2.4 RTF

Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

Disposition:	Deferred to UML 2.4 RTF

UML2-rtf issue related to communication diagrams: 

Section 14.4 describes the sequence expression tied to messages on a communications diagram. However, the abstract syntax does not (as far as I can trace the diagram) model the sequence expression. This leaves the sequence expression semantics wide open.

Some tools implement the sequence express but the concept of threads and nesting implicit in the expression syntax are undefined in the meta model.

Recommendation: Add a SequenceExpresion element into the model associate it with message, and define it explicitly. Describe the semantics of nesting messages.

Disposition:	Deferred to UML 2.4 RTF

UML2-rtf issue: Meaning of the relationship between the iteration clause and the Lifeline.selector clause. 

Interactions often involve the invocation of multiple instances of the same class. For example I may want and instance of my Portfolio class to invoke the currentValue method on instances of associated Asset classes that belong to an asset category (Asset.assetCategory = Stock). This way a portfolio may assess its own value by summing up the current value of all its stock assets. To model this I want to show the same message - currentValue() being sent to the selection of assets that have the assetCategory equal to "Stock."

Does the current UML2 communications diagram notation support the following: 

A portfolio Lifeline labeled theFund : Portfolio 
An asset Lifeline labeled myAssets [assetCategory = Stock] : Asset 
This would have to represent not one but all the asset instances that had an assetCategory of Stock 
A line connecting the two Lifelines 
A message with a sequence expression that looks like: 
1 *[holding := 1..n] : assetValue = currentValue() 

Lifelines are defined to represent only one interacting entity in an interaction. However the interaction syntax for communication diagrams would indicate that the lifeline can be "multivalued."

The need for a Lifeline to represent multiple instances for the purpose of sending a single message to all of them at some nesting level is very common.

Suggestion: Allow the Lifeline to have a multiplicity shown within brackets as with parts. Constrain the lifeline to have multiplicity one or greater. Constrain the lifeline with a multiplicity greater than one to have a selector that can, upon applying the selector, result in a single particpant.

Disposition:	Deferred to UML 2.4 RTF

Add OCL to constraints in Actions chapter

Disposition:	Deferred to UML 2.4 RTF

Misleading statement about multiplicity in AssociationClass. In the semantics of AssociationClass, the following is misleading: " Note: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e. from the instance point of view, the multiplicity of the associations ends are 1." The part after "i,e." is confusing, since it refers to multiplicity of association ends, which has a different meaning that intended above. I'd say just delete it. 

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.

Clarify multiple inputs to expansion regions. Clarify whether expansion regions with multiple input expansion nodes require all values to be present to start execution. If not, how is it indicated which are optional? ExpansionNodes do not have multiplicity. 

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.

Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

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.

Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections. 

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.

1. Deployment 
> What is client and what is supplier for this relationship? 
> Why DeploymentTARGET has word "target" in name but subsets "source" 
> for Dependency? 

The meaning of "client" and "supplier" in Dependency is pretty arbitrary and depends on one's point of view. I don't recall the reasoning behind this particular choice, but it may have to do with the direction of the arrow more than anything else. Guus probably wanted the arrow to go from the artifact to the node because it looked more natural to him. Perhaps Guus can explain -- I've copied him on this reply. 

However, there is definitely a bug here since "client" and "supplier" are not derived unions, hence, they cannot be subset as shown in figure 126. This may have already been raised as an issue. I'll have to check. I suggest that you raise a formal issue in any case. 

> And why notation examples are from Artifact to Node (arrow near 
> Node, but Node is "client" in model). 

Ostensibly, this is explained by what I wrote above. However, there seems to be a deeper problem here: note that Dependency::supplier and Dependency::client are not specializations of DirectedRelationship::target and DirectedRelationship::source respectively, as I would have expected (otherwise it does not seem to make sense to subclass DirectedRelationship at all). I do not understand why this is so, it does not seem to make sense. It may have to do with the constraints that Dependency did not want to impose on supplier and client, but I am not sure. This needs further study and, likely, an issue to be raised. 
  
> "Location" attribute of Deployment should be DeploymentTarget, not Node. 

You are correct. Please raise an official issue on this through issues@omg.org 

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.

Actor and UseCase can't own Properties, this means that associations
> in UseCase diagram are always non-navigable at both ends. 
> Is this correct? 

??? I don't have the time at the moment to check whether such a constraint exists, but, if it does, it is certainly an error. For example, in the case of Actors there is an explicit constraint that assumes that actors have properties. Can you tell me where your assumption that Actors and UseCases cannot own Properties comes from?

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.

arguments of call actions or arguments of message (for example 
> setName(name) where "name" is variable defined in Interaction), but 
> now arguments are simple ValueSpecification, so can't have 
> refference to "real" argument (variable, member, parameter of behavior etc.) 
> Maybe Argument should be in metamodel as in UML 1.4, or at least 
> ValueSpecification should be subclassed in Interactions package and 
> introduce reference to Element that value it represents? 

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.

 Node has nestedNodes collection that redefines "nestedClassifier", 
> but Node have Generalizations to Class from StructuredClasses that 
> has no Generalization to Class from Core package, so Nodes don't 
> inherits "nestedClassifier". 

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.

In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator. 

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.

Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

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.

ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

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.

Input tokens to LoopNodes should be destroyed when the loop is done

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.

3. Arguments of Message 
Variables, members and other "value holders" can be used as arguments of call actions or arguments of message (for example setName(name) where "name" is variable defined in Interaction), but now arguments are simple ValueSpecification, so can't have reference to "real" argument (variable, member, parameter of behavior etc.)
Maybe Argument should be in metamodel as in UML 1.4, or at least ValueSpecification should be subclassed in Interactions package and introduce reference to Element that value it represents?

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.

Messages in UML 2.0 can't have numbers in the model, but all examples of sequence and communication diagrams are with numbers. How numbers should be mapped into model? How to migrate with old activator, successors, predecessors?

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.

What namespace should be owner of variables used in sequence diagram?
If variables are added into Interaction, they conflict, because every execution (method for example, or even loop) can introduce variables with some names, that should be not accessible outside.
Maybe ExecutionSpecification or InteractionFragment should be NameSpaces and declare collection for storing variables?

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.

Figure 404 - Example of the use cases and actors for an ATM system
(The ATM example is repeated in Figure 410.)

If you think multiplicity gives value to this diagram, please add additional text and explain the usage of multiplicity (1, 0..1, 0..*) in this diagram.

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.

To indicate _which actor_ initiates the interaction a communicates association may optionally be adorned with an _arrow head_ to represent navigability.
(No arrowhead indicates either actor can initiate the interaction.)

Constraints:
[1] Only one arrowhead can point towards the use case.
[2] All other communicates associations have arrow heads pointing towards the other actors.

Figure 409, page 660 could be modified and used as an example.

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.

Object token flow semantics with input pins seems to be incompletely defined. In section Semantics on page 337 you write: "... an action can only begin execution when all incoming control edges have tokens, and all input pins have object tokens." You didn't explain how and when the object tokens come to the input pins. Further, for step [2], you write: "An action consumes the input control and object tokens and removes them from the sources of control edges and from input pins." Again, you didn't explain how and when the object tokens came to the input pins, from source object nodes. 

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.

BNF for property notation states that the name of the property is mandatory. There is no appropriate constraint for that. If it is mandatory there are some wrong diagrams in the specification, e.g. Fig 334.

The element "Parameter" is shown to generalize both, TypedElement and NamedElement. However, TypedElement is already a generalization of NamedElement (see chapter 9.19). Thus, the second generalization is redundant and can be removed.

The Elements Type, NamedElement and TypedElement of the package Core::Basic are (ambiguous and redundant) redefinitions of the types Type, TypedElement (Core::Abstractions::TypedElements), and NamedElement (Core::Abstractions::Namespaces). Why is that? 

Section 16.3.2 allows "classifiers in general to own use cases". Section 16.3.6 however states that the "subject of a use case could be (...) any other element that may have behavior". These elements are called "BehavioredClassifier" by Section 13 and are a specialization of Classifier.
Please clarify the consequences of these statements:
- may all Classifiers be owners of UseCases, but only BehavioredClassifiers be the subject of a UseCase?
- what is the semantics of Non-BehavioredClassifiers, e.g. an Interaction or OpaqueBehavior, owning a UseCase or being a subject of it? A UseCase "represents a declaration of an offered behavior" (16.3.6), so how can Non-BehavioredClassifiers ever offer a behavior?

Issue for: UML 2.0 Infrastructure Specification Section: 11.3.6 Classifiers diagram Document: ptc/03-09-15 URL: http://www.omg.org/cgi-bin/doc?ptc/2003-09-15 Pages: 90,91,95,96,127,130 With this submission I report an serious error in your specification. On Page 127, Section 11.3.6 Classifiers diagram, you show that the type InfrastructureLibrary::Core::Constructs::TypedElement is a generalization of both, InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement (section 9.19.2, page 91) and InfrastructureLibrary::Core::Basic::TypedElement (section 10.1.3, page 96). This leads to a collission of properties, since both of these defined a property called "type", where the one is of the sort InfrastructureLibrary::Core::Abstractions::TypedElements::Type (section 9.19.1, page 90) and the other is of the sort InfrastructureLibrary::Core::Basic::Type (section 10.1.1, page 95). Both Type-types are incompatible, since none is a generalization of the other. Please help and clarify, because I want to implement your standard for a project and cannot proceed correctly. Thanks, Thomas Weise. tweise@gmx.de University of Kassel Germany

In section 11.3.13 TypedElement (as specialized) you write: Attributes • type: Classifier[1] Redefines the corresponding attributes in both Basic and Abstractions. Neither has InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement such a property, nor does InfrastructureLibrary::Core::Basic::Type::TypedElement, even through inheritance.

In section 11.5.1 DataType (as specialized) you write "• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember." The type "Attribute" does not exist. You mean Property, which is also shown correctly in the diagramm at page 133

The UML 2.0 Specification states at 15.1 that "The state machine formalism described in this section is an object-based variant of Harel statecharts." However, there is a big semantical discrepancy between the Harel statecharts as described in D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, (with M. Politi), McGraw-Hill, 1998 and the UML 2.0 specification. The major difference is in the priority of transitions when multiple transitions are enabled in case of a nested (hierarchical) state machine. Harel states (6.3.1 (pages 99-100)): "The criterion for priority of transitions prefers the transition whose source and target have a higher common ancestor state, if possible. If the common ancestors of both transitions are identical, then non-determinism indeed occurs." (i.e. it prefers global, higher-level transitions over local ones) UML 2.0 (15.3.12 page 618) imposes almost a reveres-ed order on the priority of the transitions, by looking up from the current nested leaf state and taking the first enabled transition. The impact of the UML definition is that the author can not only "refine" a high-level state in its descendants, he/she can override the global transitions thus violating the global (high-level) contract of the state machine. This becomes even more dangerous when using submachine state, i.e. the nested state is actually drawn in a separate diagram. Example: imagine an electrical device, which can be in one of 2 top-level states: ON, OFF and having two transitions power_on, power_off. The ON state can have multiple sub-states describing a particular state of the operation. Using the UML 2.0 semantics, one can effectively override the global power_off transition locally in on of the ON's children, forcing the electrical device to keep working, even if the power has been shut down - ignoring the signal using e.g. a self-transition.

UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association.

OutputPin should hold output value, but there is no way to store it. Should be introduced similar metaclass like ValuePin for InputPin

Syntax of Transition is described as:
" <transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

The behavior expression may be an action sequence comprising a number of distinct actions including actions that explicitly

generate events, such as sending signals or invoking operations."

Information from this expression (operation call for example) can't be mapped and saved into model.

Similar situation with reply messages in interactions.

<messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’

Message can display return values and variable assignments, but there is no way to store this information in the model, because Message has no attributes for these properties.

On page 97, Chapter 10.2.2. MultiplicityElement, you write


"Constructs::Relationship reuses the definition of Relationship from
Abstractions::Relationships. It adds a specialization to
Constructs::Element."


which seems to be a little mislead copy-paste-action.

on page 134, Chapter 11.4.1, you write:


"Constructs::Classifier merges the definitions of Classifier from Basic and
Abstractions. It adds specializations from Constructs::Namespace and
Constructs::Type."


In Basic there is no definition for "Classifier".

Description


Figure 36 was not changed to conform to example description.  Here, the example indicates that “the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class.  However, Fig. 36 illustrates that Car class is an instance of the CarFactory class

The page indicates issue 6159 addressed this same problem, but apparently it went unchanged.

The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean. 

It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient. 

I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability.

Event was able to own set of parameters in UML 1.4 .
 
"Any parameter values associated with the current event are available to all actions directly caused by that event
 (transition actions, entry actions, etc.)."
 
In UML 2.0 Parameters are removed from Event metaclass, but in chapter "Changes from UML 1.x" there is no comment about that ("None").
 
Could you please comment how Parameters from UML 1.4 Event should be mapped into UML 2.0 model?
 
I see a big problem, because some MDA tools (like AndroMDA) are based on information stored in Event parameters, hundreds of users have lot of projects, they can't be lost on migration.

Actions for sending events and for calling operations and behavior are part of the "BasicActions" package which is part of Compliance Level 1. Their 'partner' actions for accepting a call or an event, however, are part of the "CompleteActions" package which is part of Compliance Level 3.
Since there is not much sense in creating events without ever accepting them later, I recommend one of the following:
a) Accept the first item of Issue 8459 from Mr. Amsden and move "AcceptEventAction" and "AcceptCallAction", too, to a package of L1, preferrably "BasicActions"
b) Otherwise (if "Communications" remains an L2 package) move these two Actions together with all "InvocationAction" specializations, too, to a package of L2. In this case, maybe a new L2 package like "CommunicationActions" could be created.

In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association: 

"   • An association with neither end marked by navigability arrows means that: 
         • the association is navigable in both directions 
         • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)" 

Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2: 

"   • An association with one end marked by a navigability arrow means that: 
         • the association is navigable in the direction of that end, 
         • the marked association end is owned by the classifier, and 
         • the opposite (unmarked) association end is owned by the association" 

this means that such non-navigable association ends are owned by the association and not by the class. 

Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute. 

Recommendation: 

(1) Define Element::owner such that it  is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid. 

(2) Do this for all other cases of invalid subsets of this type in the spec, if they exist. 

(3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2 

In the UML 1.5 you could specifiy on messages in the collaboration diagram the predesessor. This was very convenient for modeling threads. this has been removed from the UML 2.0. It should be added to the communication diagram message specification.

 think there is some inconsistency in your usage of terms
in chapter 15 State Machines.


It isn't really clear (I think) what you mean sometimes when
you use the terms "state machine" "behavioral state machines"
and "protocol state machines".


In my (humble) opinion you should never use only the term
"state machine" when you do not mean both "behavioral state
machine" and "protocol state machine".


15.3.12 is a perfect example where I think there is confusion,
or at least lack of clarity, since you talk about "state machines" executing "activities". Clearly(?), not all state machines do--
more precisely--protocol state machines don't.

The notation for Associations allows them to be depicted as a diamond (even binary associations).
However the Notation for AssociationClasses assumes the Association is depicted as a line only, and does not describe an option for attaching an AssociationClass to an Association shown as a diamond. This should be fairly obvious - just have the dotted line attached to the diamond instead of the Association's line.

Chapter 14.3.13 states on p. 526 that "Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with
Messages between the ConnectableElements of the Classifier." From chapter 9.3.13, it is obvious that only StructuredClassifiers can have such ConnectableElements. Additionally, chapter 13.3.2 states that the context of a Behavior is a BehavioredClassifier. When looking at the Classifier Hierarchy in Appendix F of the Spec, you will find a single Element which is a BehavioredClassifier, but not a StructuredClassifier: the UseCase.
This is where the problems start.
A UseCase is not allowed to have properties at all, but may be the owner of an Interaction. Consequently, with the current version of the Spec, an Interaction owned by a UseCase may never have any Lifeline at all!


Proposed Resolution:
Redefine the Association Behavior::context: BehavioredClassifier[0..1] to Interaction::context: StructuredClassifier, replace all occurrences of 'BehavioredClassifier' in the description by 'StructuredClassifier'
It should still be possible that a UseCase is the owner of the Interation, but the determination of the Interaction's context would be much clearer.

When an association generalizes another association and redefines its ends, the redefined end must be accessible through the generalization. This means redefining and redefined properties must be ownedEnds of the association or ownedAttributes of the participating classes. Redefining ownership (either directly or indirectly by changing navigability with default ownership) resulting in the redefined property no longer being a member of the general class  should not be allowed. UML2 needs to include a constraint capturing this rule

The semantics of TimeEvent uses undefined term "active". State machines uses the term for states, not triggers. Need definition independent of state machines in any case.

The semantics of TimeEvent is not really given in terms of state machines, but either way, the semantics for relative time events is completely unclear. I am not even sure as of the intuition here: Apparently the intention is that a trigger is caused (the wording of section “Trigger”), but delayed from that point until the relative time interval expires. However, there is nothing in the semantics of Trigger which would allow for a trigger just to happen without an event. So maybe the intuition is that there are two events associated with such a trigger: a spontaneous event occurring when the behavior that is triggered is enabled and that would normally cause the trigger, and the delay asserted by the time event. Moreover, the notation section uses the term “time trigger” where this should be specifying time events. I propose to defer this until somebody can explain the intuition and semantics of a relative time event. Disposition: Deferred

In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends. 

In LoopNode, the frontend, backend node description is redundant with the semantics of StructuredActivityNode

Figure 13, what is the classifier of EnumerationLiteral (inherited from InstanceSpecification)? Presumably it should be the enumeration, with the enumeration end of the association to Enumeration redefining the classifier end from InstanceSpecification in Figure 8. Programs accessing classifiers in the repository should find the enumeration literals as instances of their enumerations. 

Associations can have static ends, but this violates the semantics of static (that they are properties of the class or subclasses, not instances). If we are following programming languages, the semantics of isStatic should be that it is properties of instances, but is the same on all instances. The current semantics would be the right one if isStatic identifies "metaproperties". 

What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not? 

Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

Fig 16.3. uses note symbol notation of the Hruby Vision template. That's not conform to UML 2.0 at this point. The end of the note anchor line doesn't have a circle in UML 2.0. 

Having implemented a UML 2 L0 addin for Rational Rose, I exported a sample model to XMI.  When this XMI file was imported into another UML2 tool, the tool failed, indicating that "ownedType" is not a valid element.  Examination of the Infrastructure Library reveals why this is so.  In the InfrastructureLibrary's Basic package (the basis for UML2 L0), the sole means by which a Package owns items is the "ownedType" reference.  However, in The Constructs package (the basis for UML 2 L1 and beyond), this reference is now indicated as derived, meaning that it will not be handled by most UML 2 tools.  It has been replaced by the "ownedMember" reference, which is unknown to UML 2 L0.

This is a showstopper issue with respect to UML2 XMI interoperability, since it means that a UML2 tool operating at Level 0 cannot interchange models with UML2 tools operating at any other level.

In UML v. 2.0, formal/05-07-04: IF 7.3.9 Comment -> Semantics -> "A Comment adds no semantics to the annotated elements,..." AND 7.3.10 Constraint -> "A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element." AND 7.3.10 Constraint -> Semantics -> "A Constraint represents additional semantic information attached to the constrained elements." AND 7.3.10 Constraint -> Presentation Options -> "The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements by a dashed line." THEN Either the constrained element is the "note symbol", the "note symbol" represents a Comment and so a Comment adds semantics to another element or I missed something. 

In (merged) compliance level L1, derived union properties ActivityNode::inGroup, ActivityEdge::inGroup, ActivityGroup::subgroup, ActivityGroup::superGroup and  have no subsets. Note that ActivityGroup, an abstract metaclass, has no concrete subclasses. 

-> Should ActivityGroup not be originally defined in BasicActivities (nor in Fundamental Activities), but perhaps in IntermediateActivities? 

In (merged) compliance levels L2 and L3, derived union property ActivityGroup::subgroup has no subsets. 

-> Rename ActivityPartition::subgroup to subpartition, replace {redefines subgroup} with {subsets subgroup}. Also add properties to StructuredActivityNode and InterruptibleActivityRegion that subset ActivityGroup::subgroup? 

Hello, it is not clear to me whether it is still possible in UML2.0 to specify in interaction diagram (either sequence or communication) broadcast actions and lifeline representing multi-object. Figures Fig.14.22 and 14.23 (Superstructure 05-07-04), actually show the possibility of representing instances of the same type (class B) each one represented by a different lifeline: the selectors in that case are used to identify one specific instance and not a set of instances. Regards, Simona Bernardi 

Under the section, "12.3.27 ExpansionRegion(from ExtarStructureActivities)", it states as



Attributes


• mode : ExpansionKind - The way in which the executions interact:


parallel - all interactions are independent.


iterative - the interactions occur in order of the elements.


stream - a stream of values flows into a single execution.


Notation


An expansion region is shown as a dashed rounded box with one of the keywords parallel, iterative, or streaming in the


upper left corner.



However, in "Figure 12.87 Expansion region" the keyword used is <<concurrent>>. Could you
please verify this and let me know. Thank you.

Activity diagrams currently support two notation styles for denoting membership in a partition: horizontal or vertical, and possibly nested "swimlanes" and a parenthesized list of partition names displayed above an activity node. These notation styles are adequate in many cases, but can result in diagrams that are either difficult to layout or don't sufficiently display relationships between nodes that are in the same partition. In addition, control nodes often shouldn't belong to any partition at all, but may need to be displayed in a partition with adjoining nodes for diagram layout purposes. In this case, apparent inclusion in the partition on the diagram should not necessarily imply membership in the partition. 

One way to address these issues would be to include additional notation styles for partitions. For example, a partitions could be displayed as in concentric, overlapping circles, ovals, or rounded rectangles with activity nodes in the partitions displayed inside the partition shape. The same partition could be displayed many times on the same diagram allowing separation of members in the partition for diagram layout purposes. 

Control nodes often connect activity nodes across partitions and can have a strong influence on diagram layout. Having control nodes treated like other activity nodes in partitions can result in overly restrictive layout constraints, or accidental modification of the activity model for diagram layout purposes. For control nodes, perhaps the default should be that they are not placed in partitions unless explicitly stated by some tool action, and they could have a more restricted notation, such as requiring the parenthesized list only. This would allow control nodes to be freely interspersed between elements in a partition without necessarily belonging to that partition and keep diagram layout concerns from accidentally modifying the underlying activity model. 

A keyword, "buildcomponent", and a stereotype, "buildComponent", are
listed in Annex B, "UML Keywords" and Annex C, "Standard Stereotypes",
but not consistent. The letters, 'c' of the "buildcomponent" keyword and
'C' of the "buildComponent."


Also, there are stereotypes mentioned throughout the document such as:


o decisionInput
o multireceive
o parallel
o iterative
o stream


but not listed in the Annex C, Standard Stereotypes. The stereotypes
mentioned above may not reflect the entire document.

I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

In UML2, exceptions are represented as Types associated with an Operation via the multivalued raisedException property. The types have names and possibly structure (e.g. holding details of an error) and may use inheritance. However  there is no notation defined for actually modeling Types associated with Operations as raisedExceptions.

The choice of terminolgy for TransitionKind is non-intuitive for many of us, and therefore leads to misuse. Specifically, one would expect the antonym pair "Internal" and "External" be applied to a conceptual pair such as "Exits the composite state" and "Does not exit the composite state". Instead the terms "External" and "Local" refer to these behaviors, respectively. Further, the term "Internal" is then used to describe a concept that has nothing to do with state transitions, but rather, is a reaction to a trigger. It appears to us that the transition and reaction concepts were generalized based on their members (trigger, guard, effect) and not on their behavior. We have found this approach to be a bad practice. Behavioral generalization is more intuitive, and therefore more appropriate. We suggest the following changes: "Internal implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered." "External implies that the transition, if triggered, will exit the composite (source) state." Move what is currently described as an "Internal Transition" to a separate concept named "Reaction".

Operation should be a specialization of TypedElement and MultiplicityElement. Currently it is in InfrastructureLibrary::Core::Basic (L0), but isn't in other packages (LM - L3). 

A similar issue exists with ParameterSet::condition, State::stateInvariant, Extend::condition, Action::localPrecondition, Action::localPostcondition, StateInvariant::invariant, i.e. constraints owned by these properties have no context. This raises the question of whether a constraint must always have a context (note that some of these owners are not namespaces)... 

Can an instance specification for a classifier specify instances of subtypes of the classifier? For example, if Fido is an instance specification for Class Dog, can the runtime object it specifies be an instance of Terrier? 

In the Infrastructure.cmof file distributed as part of ballot 12, the  
Core::Constructs::NamedElement class is missing the qualifiedName  
derived property.  The operation qualifiedName() exists, but the  
corresponding derived attribute is missing.


Core::Abstractions::Namespaces::NamedElement does correctly include  
the qualifiedName derived property and all of the OCL constraints in  
Constructs correctly references a qualifiedName attribute (rather  
than the operation).


Presumably this is an error in the metamodel.

1) According to the infrastructure specification [1] the Basic package is using metaclasses from the
Abstractions package, as indicated by the following text.
“Basic also contains metaclasses derived from shared metaclasses defined in packages contained in
Abstractions. These shared metaclasses are included in Basic by copy.”[1 page 91]
First, the mentioned copy construction is not defined in the infrastructure. Second, in contrary to the copy
definition, the Rose Model [2] of the infrastructure defines the deriving of metaclasses as import on the
package Abstractions::Elements and Abstractions::Multiplicity. (see Figure 1)
2) Furthermore, the infrastructure specification described the reuse of the package Abstractions::Comments
as followes.
“Basic::Comment reuses the definition of Comment from Abstractions::Comments.” [1 page 92]
The Rose Model [2] does not contain this import.
Abstractions
Elements
Comments
Ownerships
<<import>>
<<import>>
Multiplicities
<<import>>
Basic
<<import>>
<<import>>
Figure 1
3) The infrastructure specification described the Basic::MultiplicityElement as the reuse of
Abstractions::MultiplicityElement:
“Basic::MultiplicityElement reuses the definition from Abstractions::MultiplicityElement”[1 page 97]
The Abstractions package does not contain an Abstractions::MultiplicityElement. Instead of, the
Abstractions package does contain an Abstractions::Multiplicities::MultiplicityElement and an
Abstractions::MultiplicityExpressions::MultiplicityElement. Owing to the import of
Abstractions::Multiplicities the Abstractions::MultiplicityElement

The infrastructure specification [1] described the metaclass Element as followes:
“Element is an abstract metaclass with no superclass. It is used as the common superclass for all
metaclasses in the infrastructure library.” [1, page 45 and page 93]
Both packages, Abstraction and Basic, are using the same definition for Element. Therefore, it is logical to
assume that both packages will contain their own class Element, as shown in Figure 2.
InfrastructureLibrary
Abstractions Basic
Element Element
Figure 2
The Rose Model [2] specifies one single class Element, a metaclass that is part of Abstractions. The exact
name is Abstractions::Elements::Element. The Basic package imports this metaclass. (see Figure 3). We
assume this is the correct interpretation, therefore the text on page 93 should be changed accordingly.
InfrastructureLibrary
Basic
Abstractions
Element
(from Elements)
<<import>>
Figure 3

The definition of the classes Element and Comment in the Basic package is ambiguous. The Basic package
imports Abstractions::Elements::Element and Abstractions::Comments::Comment. An inheritance
relationship and an Association called ownedComment is introduced between Element and Comment in the
package Basic. However, these relationships were already defined for these classes in the package
Abstractions (see the top two diagrams in Figure 4). Therefore, the complete model of Element and
Comment in the Basic package is the model shown in Figure 4, clearly showing a redundant association
called ownedComment, and a redundant inheritance relationship between Abstractions::Elements::Element
and Comment.
Abstractions
Element
(from Elements)
Element
(from Comments)
Comment
(from Comments)
Element
(from Ownerships)
+owningElement
0..1
{subsets owner}
ownedComment
*
{subsets ownedElement}
annotatedElement
*
Basic (after import abstractions)
Element
(from Comments)
Element
(from Ownerships)
Element
(from Elements)
Comment
(from Comments)
+owningElement
0..1
{subsets owner}
annotatedElement
*
0..1
ownedComment
*
{subsets ownedElement}
+ownedComment
0..n
Basic
Comment
(from Comments)
Element
(from Elements)
+ownedComment
0..n
0..1
<<import>>
<<import>>
Figure 4

One difference between UML activity and BPEL process is that all
data flows in UML must be explicit through connections between
activity parameter nodes, pins, central buffer nodes, and/or data
store nodes. UML activities can also have structural features and
variables which allow data to be passed between actions without
object flows, corresponding more like BPEL variable references.

However, input and output parameters have no such indirect access.
All actions that need information from parameters have to be
connected through object flows. This is inconsistent and can lead to
complex activity models because of the need for a large number of 
ForkNodes and ObjectFlows in order to access Activity parameters. 

UML2 should support actions to read and write parameters similar to 
reading and writing variables. The ActinInputPins can be used to 
simplify parameters in activities. 

 find it very unintuitive that the name attribute of a NamedElement  is optional and If specified may be any valid string, including the empty string.  A more accurate name for an element that has the capacity to have a name but does not necessarily have one would be, NameableElement instead of the misleading NamedElement.
However, elements that do not have a name (or that have a name comprising solely of the empty string or white space characters)  have no means through which a human can precisely reference them other than through their physical location on a diagram. This leaves open an opportunity for ambiguity in referencing elements and possible mis-communication. For this reason, the name attribute of NamedElement should be required, should not be allowed to contain just the empty string or just white space characters and should be unique within the element's package. In practise, even an artificially generated name for an element is preferable to no name at all. 

The question of whether the name of an element should be displayed on a particular diagram is a completely different subject and should, in general, be a decision made on a case-by-case basis by the modeller. However, even when the name is not displayed on a diagram, requiring elements to have a readable name provides tool-makers with opportunities to show the name of the element in tool tips, status bars, model navigation panes, etc so that the element can still be readily identified and precisely distinguished from others by human users of the model.

It is very common in many organizations to have both a short name for an element and a longer more descriptive name for an element. For example, a use case may have the short name UC-OP0001 and a longer name 'Place Order'. The current NamedElement has no provision for such a scheme. In practise, it would be frequently very useful NamedElements had an optional longer name as well as a required short name attribute. Whether the short or long name (when provided) are used on a particular diagram or in any other context is again a matter for the modeller and tool-makers.

The fork node does not provide tokens to outgoing edges with a guard that evaluates to false. Actions with more than one outgoing edge have a implicit fork semantic. It is unclear if a token is provided to edges with false-guards. The specification defines on page 339: "The guard must evaluate to true for every token that is offered to pass along the edge." Does the token exist if the guard evaluates to false? Does the token wait until it evaluates to true? The evaluation is done at runtime. At which time exactly? While offering tokens or all the time during activity runtime? 

Given that these are both {ordered}, indicating that ordering is important, then it seems only sensible that the ordering should be consistent, i.e. if Property p appears before Property q in memberEnd then that should also be the case for ownedEnd.
There should therefore be a constraint added to this effect.
 
There should probably also be a review of other cases where an ordered Property subsets another ordered property.
Or should there be a more general constraint defined at the meta-level?
 

The comment in figure 14.2 in the top right cell identifies the last message as a reply, but it is in fact a creation message. See 14.3.20 Message, Notation, pg. 478: Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line. Object creation Message has a dashed line with an open arrow.

P. 603 makes reference to "CallTriggers" and "SignalTriggers".   I believe the wording on that whole paragraph under "Example" should be changed slightly.   
P. 246 makes reference to "SignalTrigger" 
P. 453 makes reference to "call trigger"   ( I believe the wording should be modified slightly. ) 

Extend (with condition) entry in diagram table: The comment anchor line has a small circle at the end. That's not UML notation, but Pavel Hruby notation

I propose an optional enhancement of the comment symbol: It is possible to draw a small circle at the end of the anchor line. That way it is easier to read a diagram if the anchor line crosses other dependency lines. The small circle is already used in several diagrams. It is part of the famous Visio stencil of Pavel Hruby.

A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

A) All associations ends in the UML2 metamodel itself should be navigable
The top of section 6.5.2 states that "An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,"
 
This does not make sense now that navigability has nothing to do with property ownership and is used in effect to indicate a requirement for efficient access.
However there is no justification for non-navigability in the context of the UML metamodel itself (which is in effect an application model/specification of a UML tool). Given that most users of UML tools would reasonably expect to do 'where used' navigations/queries with reasonable efficiency then there seems to be no reason for having ends owned by Associations being non-navigable. Furthermore OCL and QVT engines would also expect efficient traversal.
An important case in point is that currently the association end from an Element to its applied Stereotypes is marked 'non-navigable' using the old notation. While there is an argument for not having a property on the Element itself, navigating the association from Element to its applied Stereotypes is an important access that any tool would require to be very efficient (e.g. to allow the tool to display the stereotype name/icon on diagrams where the element appears).
When UML2 was designed, the arrows were used to mean property ownership only. We should honor that design intent.
 
Proposed resolution:
At top of section 6.5.2 replace:
 "An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is owned by the association.
With:
 "An association with one end marked by a navigability arrow means that:
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is an owned navigable end of the association.
 
Alternative resolution:
Redraw all diagrams to not show the deprecated notation of using navigability arrows to indicate ownership.

Though section 6.5.2 explains and justifies the convention (in the UML2 spec only) for use of navigability arrows to represent property ownership, it would be worth showing a non-normative example of one of the metamodel diagrams with the correct 'dot at line end' notation used. This depends on the resolution to issue A) above.
 
C) Use the new 'dot' notation in examples
 Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter. 

Ordering is sufficient for correlating pins with parameters, but it is difficult to visualize on a diagram. An action may have many input and output pins oriented around the action, and there is no way to visually determine which pin is associated with which parameter. In many cases, the pin name may correspond directly to the parameter name providing a visual connection. However, this is not possible for ActionInputPins or ValuePins where the pin name refers to some structural feature or value specification. 

UML2 should consider a presentation option that shows pins ordered starting from the bottom right corner of the action and following clockwise around the action ending at the right bottom side. The first pin is always the target input pin for a CallOperationAction. The last pin corresponds to the return parameter if any. 

This makes pin ordering visible in the diagrams, and establishes an unambiguous correlation between pins and parameters in call actions. However, it may result in some layout restrictions and extra object flow crossings in diagrams. This should not be much of an issue in practice because the pins can be moved around the edge of the action, just not reordered. And ActionInputPins allow reference to inputs without requiring explicit object flows. 

ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name. 

This is generally fine, but can result in significant layout problems when swimlanes are used to designate activity partitions. UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. When swimlanes are used, the nodes that do not belong in any partition have to be displayed someplace. One convention is to create a default swimlane for these nodes that for example could appear as a partition with the same name as the activity. This results in extreme layout issues as all the control nodes end up being in the same partition resulting in very ugly diagrams with flow lines crossing partitions everywhere. If a user attempts to layout the diagram by moving the control nodes, this results in edits to the underlying model, something that the user may not have intended, or many not have permission to do. Some tools allow editing diagrams on read only models as long as the edits don't result in any changes to the model. This is especially common for diagrams that include views of other models in order to establish a context and show referenced elements. 

Another problem is activity edges which cross many swimlanes  while connecting their source and target. It is unclear from the notation in which of these partitions the edge should be included: none of them, all of them, or only the partitions at their connection points. 

UML2 should consider a presentation option or notation convention that ControlNodes and ActivityEdges do not belong to ActivityPartitions unless explicitly shown using the partition name in parenthesis above the node or edge name. Putting a control node or edge in a swimlane should not imply that the node or edge is in the corresponding partitions. The notation should require that  these element explicitly state the partitions they belong to. 

There doesn't appear to be any notation of indicating the signal of a Reception. Reception may also be missing a constaint similar to SendSignalAction where the parameters of the BehavioralFeature have to match the ownedAttributes of the Signal in number, order, and type.

SendObjectAction sends the object on its request InputPin the object at its target InputPin. 

AcceptEventAction can have a trigger that is a SignalEvent or CallEvent, but there is no Event type for ObjectEvent to represent the receipt of an object from a SendObjectAction. SignalEvent cannot be the trigger because it is not a Class and is not general enough.

Section 7.3.36 specifies the notation for Operation, but there is no notation for denoting raisedExceptions.  Section 12.3.41 introduces Parameter::isException and suggests exception parameters are indicated out parameters with {exception} after the parameter type to indicate Parameter::isException=true. 

However, Operation::raisedException is not a Parameter, it is a reference to a Type. So a raisedException is not a TypedElement like parameter, has no multiplicity or ordering, etc. Raised exceptions are quite different than parameters and even in activities, RaiseExceptionAction and ExceptionHandlers do not exchange exception data through parameters. 

Consider adding <oper-property> ::= 'throws' '('<type-list>')' in section 7.3.36 for denoting exceptions that could be raised by an operation. This is a significant part of the specification of an operation indicating information clients must know in order to use the operation and should be clearly visible in the operation's signature. 

Figure 7.54 of ptc/06-01-02 shows an Instance Diagram notation for a
Link.
With the accompanying text:
"An instance specification whose classifier is an association represents
a link and is shown using the same notation as for
an association, but the solid path or paths connect instance
specifications rather than classifiers. It is not necessary to
show an underlined name where it is clear from its connection to
instance specifications that it represents a link and not
an association. End names can adorn the ends. Navigation arrows can be
shown, but if shown, they must agree with the
navigation of the association ends."


However this does not cater for the fact that the metamodel allows an
InstanceSpecification to be associated with many Classifiers.


Proposed resolution:
Extend the metamodel for Instances to explicitly model Links. For a good
start see the instances model in the MOF2 Core Abstract Semantics
chapter (it is not part of MOF - it is only there to explain the
semantics of MOF in terms of metamodel instances).

In Infrastructures, since TypedElements::TypedElement is subclassed from Namespaces::NamedElement, is it necessary that BehavioralFeatures::Parameter be subclassed from both TypedElements::TypedElement and Namespaces::NamedElement?  

In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

Description of Problem


Section 18.3.8 has the following paragraph:
“
Presentation Options If multiple stereotypes are applied to an element,
it is possible to show this by enclosing each stereotype name within a
pair of guillemets and listing them after each other. A tool can choose whether it
will display stereotypes or not. In particular, some tools can choose not to
display “required stereotypes,” but to display only their attributes (tagged
values) if any.
“


Annex B has the following paragraph:
“
If multiple keywords and/or stereotype names apply to the same model element,
they all appear between the same pair of guillemets, separated by commas:
“«” <label> [“,” <label>]* “»”
“


These two paragraphs seem to contradict each other, since the annex B does
not allow multiple guillemet pairs for the same element, while 18.3.8 does.


Proposed Solution:
Add clarification that Both presentation options should be allowed.

In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

UML's support for null values and semantics is unclear. 
For example if a Property is defined [1..1] then is a value of null (represented by LiteralNull) permitted? (LiteralNull is defined as "LiteralNull is intended to be used to explicitly model the lack of a value.")
Can null values be used to create a sparse array? If not how is a fixed length sparse array to be modeled?
Can a unique multivalued property contain multiple nulls?
How do the StructuralFeatureActions react in the presence of null?
[Note that the issue is NOT related to the "null token"]

There seems to be no reason why n-ary Associations are required to have aggregation=none: there should be a restriction that this is allowed for at most one End but it could reasonably be allowed

There is no equivalent in UML 2.x of the 'documentation' tag at UML 1.x: a standard way of distinguishing the description of an element.
Comment is generic and has no property to distinguish the 'inherent' description of an element from annotations on specific diagrams, and there is no standard stereotype which could be applied (though use of a stereotype is arguably heavyweight for what is a fairly pervasive requirement).
 

 LiteralExpression inherits a type property but its use, semantics and notation are not documented. There should at least be appropriate constraints e.g. that LiteralString.type is a subtype of PrimitiveTypes::String.
 

It could easily be taken to mean a constraint on the value not the multiplicity, e.g. for an 'temperature' property, that its value is not allowed to be below -273.  Would be better named "lowerBoundValue" or similar.

ValueSpecification::isComputable() introduces conformance requirements not captured in compliance points.
Section 7.3.54, Additional Operations states : "A conforming implementation is expected to deliver true for this operation for all value specifications that it can compute, and to compute all of those for which the operation is true. A conforming implementation is expected to be able to compute the value of all literals."
 

A minor issue I stumbled over in UML Superstructure ptc/06-04-02.

SendSignalEvent [14.3.28] specialises MessageEvent [13.3.18], which
"specifies the RECEIPT ..."  Perhaps that should be reworded?

Seeing as Action::input and Action::output are derived compositions that subset Element::ownedElement, all subsets of them should be compositions (I thought Karl had added a constraint to this effect?). In particular, OpaqueAction::inputValue, OpaqueAction::outputValue, AcceptEventAction::result, AcceptCallAction::returnInformation, UnmarshallAction::result should be composite

There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics.
The UML superstructure doc 05-07-04, chapter 7.3.10 states,
that Constraint has context and constrainedElement associations(properties).


The Semantic section of the paragraph states, that the context property of
the constraint is used in OCL constraint evaluation as a "self".


However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different
rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that
the self (a.k.a. contextual classifier) should be derived from the constrainedElement property.


In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that
the contextual classifier should be the classifier, specified by the constrainedElement property:


contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier)


The other conditions are irrelevant for the issue at hand:
        constraint should have <<invariant>> stereotype (self.constraint.stereotype.name = ?invariant?)
        constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1)
        constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier))
        expression result should be boolean (self.bodyExpression.type.name = ?Boolean?)



So we have a conflicting specs here. Which one of these is correct?



I am inclined to believe, that the OCL spec, being more concrete, is correct - 
UML spec mentions the usage of "self" only casually, in one sentence.
However if this true, what is the meaning of the context property of the constraint in the UML?
It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere...



Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context
property of the constraint. Context is now changed to subset namespace.
However the issue, described above, is not mitigated and is still present in 2.1.

Element reads "Constructs::Element reuses the definition of Element from Abstractions::Comments." Since this element has been removed should this read "Constructs::Element reuses the definition of Element from Abstractions::Ownerships." as reflected in the merge?

I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement

The definition of Namespace lists as a generalization, Namespace. This appears to be an error: it appears this is intented to refer to NamedElement.

The UML2.1 specification defines a state list:


The special case of the transition from the junction having a history as
target may optionally be presented as the target
being the state list state symbol. See Figure 15.27 and Figure 15.28 for
examples.


I couldn't map that definition to the example. There is no junction and
no history state. Can someone 
provide fig. 15.27 in another notation without state list?


I'm not the first one who's asking this. Probably we should provide such
an example in the spec.

The Convenience document is inconsistent with the resolution with 9087 and itself: the spec shows Package::packagedElement as derived in the Associations section of 7.3.37 whereas it's clearly not in the resolution. Figure 7.14 is actually OK as is the metamodel. 

The type of a default value should conform to the type of the property/parameter that owns it. Constraints to that effect should be added to the UML specification. 

The section 7 contains two concepts, ElementImport and PackageImport, that seems to quite redundant. I believe that the semantics of ElementImport covers the semantics of PackageImport. SO, either clarify the difference (if there are?), or delete the PackageImport or make PackageImport a specialization of ElementImport.

In paragraph 7.2 it says: "Figure 7.2 shows the package dependencies of the Kernel packages". However, this should read "...dependencies of the Classes packages." The caption of figure 7.2 is correct.

I verified the alignment between the package dependencies (packageImport and packageMerge) in the XMI file Superstructure.cmof (contained in ptc-06-01-04) and the package dependency diagrams in the convenience document, and noticed some discrepancies. Assuming the XMI file is correct, these discrepancies are: - Part I, Figure 1 (p.19): the packageImports from Classes to CommonBehaviors and AuxiliaryConstructs are missing. - Figure 7.2 (p.22): the packageImport from Dependencies to Kernel is missing. - Figure 9.1 (p.168): the packageImports from Ports to Kernel and Interfaces are missing. - Figure 10.1 (p.202): the packageImport from Nodes to Kernel is missing. - Part II, Figure 1 (p.225): the packageImports from StatesMachines, Activities and Interactions to CompositeStructures are missing. - Part II, Figure 1 (p.225): the packageImport from Activities to StateMachines is missing. - Part II, Figure 1 (p.225): the packageImport from CommonBehaviors to Actions is missing. - Part II, Figure 1 (p.225): the packageImport from UseCases to CommonBehaviors is not correct: it is not present in the XMI file. There only exists a packageMerge relation from UseCases to BasicBehaviors. - Figure 11.1 (p.230): the packageImports from CompleteActions to Kernel and BasicBehaviors are missing. - Figure 11.1 (p.230): the packageImport from IntermediateActions to Kernel is missing. - Figure 11.1 (p.230): the packageMerge from IntermediateActions to BasicBehaviors is missing. - Figure 12.1 (p.309): the packageImports from CompleteActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageImports from IntermediateActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageMerge from BasicActivities to BasicBehaviors is missing. - Figure 15.1 (p.546): the packageMerge from BehaviorStateMachines to Communications is missing. - Part III, Figure 1 (p.631): the packageImport from AuxiliaryConstructs to Classes is missing.

The Classifier taxonomy in Appendix F shows a Generalization from Collaborations::Collaboration (child) to Collaborations::Classifier (parent). This Generalization is not present in the metamodel in Figure 9.6 (p. 172), and I therefore believe it to be in error.

In the defintion of the Property concept, the type of the default attribute is a String. I believe it would be more powerful to type default with ValueSpecification

In UML2, it is possible to describe user defined datatypes and propertis may typed by this typed. But, nothing has been defined in the UML2 specifcation to be abble to describe values (of slots for example) which has to be conform to a datatype. One could add a new metaclass (for example, DataTypeValueSpecification inheriting from ValueSpecification) in the Expression package to be abble to denote datatype values. And to define the underlying notation.

In section 15.3.14, Transition, subsection Constraints you will find the following constraint: [6] An initial transition at the topmost level (region of a statemachine) either has no trigger or it has a trigger with the stereotype “create”. ... OCL body for constraint ... The element to be stereotyped in this constraint is a Trigger. If you look in Appendix C: Standard Stereotypes you will not find this stereotype. It appears that this constraint is left over from UML1.4/1.5. In UML 1.4 the corresponding stereotyped element in this constraint was an Event. In particular it was a CallEvent. The corresponding <<create>> stereotype is listed in Appendix C as a retired stereotype. So, either the constraint should be deleted or the stereotype must be brought out of retirement.

I observed some minor errors on Document formal/05-07-04 while reading it, but
there is an aparent inconsistence that must be checked. I will explain it
below.


On page 154 we can read:
"Notation
A component realization is notated in the same way as the realization dependency
(i.e., as a general dashed line with an open arrow-head)."


But on page 125 we can read:
"A Realization dependency is shown as a dashed line with a triangular arrowhead
at the end that corresponds to the realized element."


It's clear that the error is on page 154 definition

"ownedAttribute", "ownedOperation" and "superClass" are listed as attributes, but they probably should be listed as associations

The association "feature" is not marked as a derived element, but probably should be. 

The description says: "Constructs::Classifier merges the definitions of Classifier from Basic and Abstractions." 
a) The "Abstractions"package is not supposed to be merged by Constructs. 
b) There is no Basic::Classifier, so this reference is probably in error. There is Basic::Class, though. 

The relationship between the text of the specs and the corresponding XMI specifications should be clarified to explicitly state that, in cases of disagreement between the text and the XMI, the latter takes precedence.