Issues for UML 2.0 Superstructure Finalization Task Force

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

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

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

Issue 1209: Parametrizable model elements not shown
Issue 1512: Need for notation for dealing with evolution of UML models
Issue 2020: Guard in current metamodel can be replaced by Constraint with stereotype
Issue 2083: AssociationEnd needs ownerScope
Issue 2208: Figure 7 p. 43 of the UML semantics guide
Issue 2276: UML 1.1.section 4.2:editorial
Issue 2277: Page 19 semantic doc. name
Issue 2278: OCL needs to be added
Issue 2289: Missing OCL
Issue 2290: ElementOwnership
Issue 2291: User-defined symbols for tagged values and properties
Issue 2336: extension to the notation for a transition
Issue 2337: Associate a predicate with a state
Issue 2361: Inheritance violation in "Auxiliary Elements"
Issue 2362: Incomplete Inheritance Specification
Issue 2541: Datatypes: Expression
Issue 2582: class EnumerationLiteral issue
Issue 2613: Interfaces on Nodes
Issue 3123: "Physical" Metamodel Package Structure (uml-rtf)
Issue 3126: Operations and Constraints Missing from "Physical" Metamodels
Issue 3127: Data Types Misplaced in the "Physical" Metamodel (uml-rtf)
Issue 3202: Another State machine issue
Issue 3276: UML RTF 1.4 Issue: Dynamic concurrency arguments
Issue 3285: UML RTF 1.4 Issue: Parallel action iteration
Issue 3291: UML RTF 1.4 Issue: Missing notation mapping for association in composite
Issue 3341: Statemachine/state as Namespace
Issue 3368: Efficient diagrammatic notation for Collaboration Specifications
Issue 3376: ClassifierRoles should be independent of specific underlying base Classifi
Issue 3382: UML 1.4 issue: Top state in activity graphs
Issue 3391: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings
Issue 3569: Why is a StateMachine's top a State instead of a CompositeState?
Issue 3632: Document 99-06-08 - UML Spec
Issue 3682: Notation for inherited associations
Issue 3735: MOF rules should disallow certain composition relationships
Issue 3783: Interface of an object
Issue 3999: Attributes obsolete in UML 1.3
Issue 4083: Conflicting constraint between ActivityGraph and StateMachine.
Issue 4123: Clarify the origin of an Action in a Collaboration.
Issue 4218: Appendix A, UML Standard Elements
Issue 4219: Profile Notation
Issue 4263: Events, signals, stimuli, etc.
Issue 4292: Add Multiplicity to Parameter.
Issue 4298: Issue: Conflicting WFRs on Transition
Issue 4446: Ambiguous semantics of classifier ownerscope
Issue 4447: Ambiguous semantics of classifier targetscope
Issue 4449: The definition of Multiplicity in Datatypes does not list the range associa
Issue 4452: Predefined datatypes
Issue 4455: The text and OCL of rule #5 for Method do not say the same thing.
Issue 4456: Event => Event Specification
Issue 4457: Exceptions do not correspond to common usage
Issue 4464: Component notation: logical compartments
Issue 4465: Component notation: showing delegation of messages
Issue 4504: Optimize Instance data values
Issue 4617: XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD
Issue 4619: Using or implementing an interface of a Subsystem
Issue 4626: Using OCL at the meta-model level
Issue 4645: Nameclash in UML 1.4
Issue 4662: Compliance to the UML" pp xxxi -- Editorial?
Issue 4726: TaggedValue in TaggedValue
Issue 4727: UML 1.4: Action containment error
Issue 4728: UML 1.4: Action problem in Collaborations
Issue 4729: UML 1.4: State containment problem
Issue 4730: UML 1.4: ExtensionPoint containment problem
Issue 4731: UML 1.4: Transition containment problem
Issue 4732: UML 1.4: Feature containment problem
Issue 4733: UML 1.4: Stimulus containment
Issue 4734: UML 1.4: Event containment problem
Issue 4735: UML 1.4: Node, Artifact, Package and Model contents problem
Issue 4736: UML 1.4: ClassifierRole contents problem
Issue 4738: UML 1.4: AttributeLink containment error
Issue 4739: UML 1.4: Wrong target for StateMachine.top association
Issue 4740: Adding events to the class definition
Issue 4746: Composite relationship between Event and StateMachine
Issue 4800: Definitions in glossary don't conform to any standard for definitions
Issue 4810: Invalid XMI.link.atts in UML 1.4 DTD
Issue 4816: Suggest that alternate syntax used in section 6.5.5 be adopted thoughout
Issue 4848: Namespace.contents
Issue 4917: match/correspond clarfication
Issue 4927: Simplify inputs/outputs of procedures
Issue 4936: StartStateMachine clarification
Issue 4940: Add action for invoking an activity
Issue 4946: UML 1.4.1 should use MOF 1.4
Issue 5005: A_context_raisedSignal
Issue 5267: Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState
Issue 5268: Well-formedness rules for 2.12.3.8
Issue 5269: UML 1.4 - Partition relates to nothing
Issue 5273: Initial state for composite states - OCL example and missing constraint
Issue 5525: UML Issue - Inconsistency between UML 1.3 XMI and DTD
Issue 5655: How does one indicate the target object for a CallState
Issue 5656: Section 2.13.4.3
Issue 5657: In v1.4, section 3.84.1 the paragraph on semantics
Issue 5658: parameters of object flow states
Issue 5659: Section 3.90.2.2
Issue 5685: Section number duplicated
Issue 5730: Swap rule 2 and rule 3 of the Binding element
Issue 5731: Rule 6 of the Method element isn't formulated well
Issue 5732: There is an unnecessary condition in rule 1 of the Namespace element
Issue 5734: Add rule to Namespace element
Issue 5735: there is something wrong with rule 3 of the Trace element
Issue 5736: Wrong alphabetical order: DataValue section should be before DestroyAction
Issue 5737: There are misprints with numeration of rules of the Instance element
Issue 5738: There is a misprint in rule 2 of the Object element: “Stimuli” instead of “
Issue 5739: There is a misprint in rule 1 of the SubsystemInstance element
Issue 5740: font sizes
Issue 5744: spelling of the word Use Case
Issue 5745: Inconsistency regarding guards on forks
Issue 5763: The first sentence is not consistent with figure 2-9 on page 2-17
Issue 5795: Designates a Generalization (02)
Issue 5796: Section: 2.5.2.10 Classifier
Issue 5797: 2.5.2 Abstract Syntax
Issue 5798: 2.5.2.16 Element
Issue 5799: 2.5.2.27 ModelElement
Issue 5800: 2.5.2.10 Classifier
Issue 5801: 2.5.2 Abstract Syntax
Issue 5802: 2.5.2.15 Dependency
Issue 5803: 2.5.2 Abstract Syntax
Issue 5805: 2.5.2.29 Node
Issue 5922: Feature;ModelElement
Issue 5924: representation of arrays of values in an action language
Issue 5951: UML 2.0 Superstructure: Operation vs. Attribute notation
Issue 5976: UML's use of the word "unique" for multiplicity is ambiguous
Issue 5978: notation for shared aggregation
Issue 5979: The description of DataType is plainly wrong in the specification
Issue 5980: Description of GeneralizationSet
Issue 5982: Well-Formedness Rules for Procedure on Common Behavior Package
Issue 5992: There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState
Issue 5995: Question on Connectors - fig 2-17
Issue 6014: OpaqueExpression in CommonBehaviors
Issue 6015: inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337.
Issue 6016: CommonBehaviors
Issue 6017: CommonBehaviors describes "Operation (from Communications, as specialized)
Issue 6018: figure 8-137 and 8-139
Issue 6019: Missing sections for for enumeration MessageKind or MessageSor
Issue 6020: duration observation" vs DurationObservationAction etc
Issue 6021: labels for ExecutionOccurrence
Issue 6022: The title of the Property description on page 144
Issue 6023: On page 140, the title for Parameter is "Parameter (Collaboration, as speci
Issue 6049: PackageableElement
Issue 6066: An error in Figure 464
Issue 6067: Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01
Issue 6068: Obsolete notation used in state machine - transition examples
Issue 6069: Interface Figure 62 uses wrong notation
Issue 6070: Figure 63 missing notation
Issue 6072: Strange notation in Figure
Issue 6073: No Glossary in 03-08-02
Issue 6074: Multiplicities diagram in section 7.4
Issue 6075: UML2 super/pg.470/entry and exit points for composite states
Issue 6076: UML2 super/pg. 580/Stereotype typo
Issue 6077: Message notation. Incorrect notation in Figure 333 p.414
Issue 6078: Strict ordering in Inline Part Decomposition
Issue 6079: Message End association to Interaction should be removed
Issue 6080: EventOccurrence, multiplicities incorrect in metamodel diagram
Issue 6081: Incorrect mentioning of General Order On p 412
Issue 6084: Remove occurrences of “TBD”
Issue 6085: Omission of non-terminal ‘arguments’ (p. 424)
Issue 6087: Figure 346 needs updating
Issue 6089: running a “Check Model” in Rose you get the following errors
Issue 6090: Variable and Pin multiplicity
Issue 6091: Outgoing edges from input pins
Issue 6092: Clarify wording on executable activity nodes
Issue 6093: Edge constraint for control nodes
Issue 6094: Action should be concrete
Issue 6095: Provide notations for Loop and Conditional
Issue 6096: Weight=all
Issue 6097: Tokens at fork
Issue 6098: ActivityFinalNode
Issue 6099: ExpansionRegions keywords
Issue 6100: Keywords or properties
Issue 6101: Multiple outputs of object flow transformations
Issue 6102: Pins owned twice
Issue 6103: Pin/parameter matching 1
Issue 6104: Pin/parameter matching 2
Issue 6105: Pin/parameter matching 3
Issue 6106: Pin/parameter matching 4
Issue 6107: Pin multiplicity
Issue 6108: Optional parameters
Issue 6109: ObjectFlowEffect
Issue 6110: ExecutableNode, ControlNode should be abstract
Issue 6112: Reentrancy 3
Issue 6113: ObjectNode.isUnique
Issue 6115: Parameter set corrections 1
Issue 6116: Parameter set corrections 2
Issue 6117: Parameter set corrections 3
Issue 6118: Parameter set corrections 4
Issue 6119: Parameter set corrections 5
Issue 6120: Parameter set corrections 6
Issue 6121: Streaming
Issue 6122: Parameter semantics clarification
Issue 6123: Behavior execution instances
Issue 6124: Local pre/postcondition example
Issue 6125: Colon notation for pins
Issue 6127: Value Pin notation
Issue 6128: Notation for for global pre/postconditions actions
Issue 6129: Notation for isSynchronous
Issue 6130: No-token activity termination clarification
Issue 6131: Clarification of insert
Issue 6132: SendObjectAction
Issue 6133: ExceptionHandler 1
Issue 6134: ExpansionRegion
Issue 6135: Pins on structured nodes 1
Issue 6136: Pins on structured nodes 2
Issue 6138: Time spec text
Issue 6139: Partition semantics
Issue 6140: Activity frame and parameter nodes 1
Issue 6141: Activity frame and parameter nodes 2
Issue 6142: Update actions for isUnique
Issue 6143: actions on properties that are association ends
Issue 6144: BroadcastSignalAction
Issue 6145: Action packaging
Issue 6146: Composite structure dependent on Behavior
Issue 6147: Complex port
Issue 6148: Concrete Behavior
Issue 6149: Activity attributes on Behavior
Issue 6151: Diamond notation for merge junctions
Issue 6152: Protocol state machines are not pre/postconditions
Issue 6153: Interactions view of state machines/activities
Issue 6154: TimeObservationAction can't return values
Issue 6155: Replace "initial value" with "default value".
Issue 6156: Kernel::Classifier missing "attribute"
Issue 6157: Property string undefined
Issue 6158: Notation for attributes
Issue 6159: Instantiates stereotype
Issue 6160: Notation for anonymous instance
Issue 6161: Clarify that profiles can contain model libraries
Issue 6162: Typos
Issue 6164: UML Superstructure: 03-08-02 -- typos
Issue 6165: UML Superstructure 03-08-02: Loop node notation missing
Issue 6166: Notation mismatch for the realization dependency
Issue 6167: No notation defined for suppressing attributes or operations
Issue 6168: 7.3.1 ElementImport
Issue 6169: 7.4.1 Multiplicity
Issue 6170: InstanceSpecification
Issue 6171: 7.10.1 Operation
Issue 6172: 7.11.2 Association
Issue 6173: 7.14.1 Abstraction
Issue 6174: 7.14.6 Realization
Issue 6175: 7.15.3 Interface
Issue 6177: UML 2 Super/Metamodel::BasicBehaviors/package merge issue
Issue 6178: BehaviorStateMachines/missing owningState end name
Issue 6179: UML 2 Super/Metamodel::IntermediateActivities/redundant merge error
Issue 6180: UML 2 Super/Metamodel::Communications/redundant merge error
Issue 6181: UML 2 Super/Metamodel::Nodes/redundant merge error
Issue 6182: AuxiliaryConstructs::Templates::Operation/extra space
Issue 6183: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames
Issue 6184: UML 2 Super/Metamodel::Kernel::Packages/missing redefinition
Issue 6185: UML 2 Super/Metamodel::BasicBehaviors/missing redefinition
Issue 6186: UML 2 Super/Metamodel::Constructs/inconsistency with Kernel
Issue 6188: UML 2 Super/Metamodel/merging of non-redefinable model elements
Issue 6189: UML 2 Super/Metamodel/package merge and visibility
Issue 6190: UML 2 Infra/Section 5.9/missing merge rules
Issue 6191: UML 2 Super/Package Merge/redefinition rules and standard OO languages
Issue 6192: UML 2 Super/Metamodel::StructuredClasses/erroneous association
Issue 6193: UML 2 Super/Metamodel::BasicActivities/inGroup problem
Issue 6195: UML 2 Super/Metamodel::StructuredActivities/double redefinition
Issue 6196: UML 2 Super/Metamodel::Compliance::L3/Missing merges
Issue 6198: UML 2 Super/Package Merge/missing rule for operations
Issue 6199: Profile/inability to attach a stereotype to an element
Issue 6202: UML 2 Super/Metamodel::CommonBehaviors/redundant class?
Issue 6203: UML 2 Super/Metamodel::Templates/missing return type
Issue 6204: UML 2 Super/Metamodel/Mis-named Manifestation class
Issue 6205: UML 2 Super/Metamodel/mis-spelled implementingClassifier"
Issue 6206: UML 2 Super/Metamodel/missing owners for metaclasses
Issue 6207: UML 2 Super/Metamodel/missing namespaces for metaclasses
Issue 6208: UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements
Issue 6209: ProtocolStateMachines/ProtocolStateMachine not a type of Feature
Issue 6210: UML 2 Super/Metamodel/missing source and target for InformationFlow
Issue 6211: UML 2 Super/Spec/completing mandatory sections
Issue 6212: UML 2 Super/pg.78/operation redefinition
Issue 6213: UML 2 Super/pg.78/missing return types syntax
Issue 6214: UML 2 Super/pg.79/underlined operation syntax missing
Issue 6215: UML 2 Super/pg.64/Classifier redefinition notation
Issue 6217: UML 2 Super/pg.95/attributes in data types clarification
Issue 6218: UML 2 Super/pg.109/Permission redundant
Issue 6219: UML 2 Super/pg.99/misnamed "packageMerge" attribute
Issue 6220: UML 2 Super/pg.130/missing notation explanation
Issue 6221: UML 2 Super/pg.130/incorrect stereotype name
Issue 6222: UML 2 Super/pg.235/missing semantics of destroy action
Issue 6223: UML 2 Super/pg.395/multiple meaning of exception
Issue 6224: UML 2 Super/pg.416/incorrect multiplicities for event occurrence
Issue 6225: UML 2 Super/pg.429/incorrect constraint for Message
Issue 6226: UML 2 Super/pg.427/missing notation description for lifelines
Issue 6227: UML 2 Super/pg.519/multiplicity semantics of use case associations
Issue 6228: UML 2 Super/pg.471/unclear terminate state semantics
Issue 6229: UML 2 Super/pg. 471/choice pseudostate notation
Issue 6230: UML 2 Super/pg. 556/notation for template binding inconsistency
Issue 6231: UML 2 Super/pg.379/anyTrigger clarifications
Issue 6232: UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition
Issue 6233: UML 2 Super/Compliance points/confusing and redundant
Issue 6234: UML Superstructure: 03-08-02 / Typos
Issue 6235: Stereotypes for Actions
Issue 6236: UML 2.0 serious layout problems with activity diagrams
Issue 6237: State list
Issue 6238: Multiplicity of Regions owning Transitions
Issue 6239: Actor
Issue 6240: UML2 super/pgs.17 + 598/"topLevel"
Issue 6241: Actors that are outside and inside the system
Issue 6242: Confusion regarding XMI for use of stereotypes
Issue 6243: Association not affecting ends
Issue 6244: Metamodel for applying a stereotype
Issue 6246: fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <<merge>
Issue 6247: Question about InterruptibleActivityRegion
Issue 6248: UML super/Section 2/Compliance points
Issue 6249: UML 2 Super/p125 and p126/typos
Issue 6250: fig236 Datastore example/Datastore should not directly linked with actions
Issue 6251: UML 2 super/Composite Classes/Connecting parts of parts
Issue 6252: Defenition of redefines?????
Issue 6253: What does redefines mean in package extensibility?
Issue 6255: UML2 Super / Classes/ Incorrect reference to "access"
Issue 6256: UML2 Super / association end naming convention
Issue 6257: UML2 Super / SimpleTime package / missing multiplicities
Issue 6258: UML 2 Super / State machines-CommonBehavior / undefined owner of triggers
Issue 6259: UML2 Super / Primitive Types / implementation issue
Issue 6260: UML 2 Super / Interactions / no create message
Issue 6261: UML Superstructur 03-08-02: Notation for ConditionalNode is missing
Issue 6263: UML 2 Super / Interactions / No way to model reply messages
Issue 6264: Recommendation for InteractionOccurrences
Issue 6277: On templateableElment - additonal features
Issue 6278: Sequence diagram conditions on Message arrows
Issue 6279: PackageMerge (from Kernel)
Issue 6280: UML2.super (or infra)/Profiles-Stereotype (18.3.7)
Issue 6281: UML2 Super/Composite Structures
Issue 6308: super AND infra / Section 11.8.3 of Infra, 7.13.2 of Super / PackageMerge
Issue 6309: UML2 Super/Kernel::Classifier
Issue 6310: UML2 Super/Profiles
Issue 6315: UML 2 Super/Components & Deployment chapters missing OCL constraints
Issue 6316: UML2 Super/Ports
Issue 6317: UML2 Super/Instances
Issue 6337: Figure 61
Issue 6338: description of Component on page 137
Issue 6347: Profiles in fixed repositories
Issue 6348: Control pins
Issue 6349: Control at joins
Issue 6350: Dependency multiplicity to CollaborationOccurrence
Issue 6351: InformationFlow realization
Issue 6352: Deployment location
Issue 6354: Association end names and part types
Issue 6355: partWithPort without ports
Issue 6356: Ports as properties
Issue 6357: Port is a Property in XMI
Issue 6358: Outgoing edges of initial nodes
Issue 6359: Guards on initial nodes
Issue 6360: Caption typo
Issue 6361: Activity final clarification
Issue 6362: Side effects of value specifications
Issue 6363: Guard evaluation
Issue 6364: Decision behaviors on control tokens
Issue 6365: ReadSelfAction with no host
Issue 6366: Clarify ReadSelfAction in activity behaviors
Issue 6367: Combining joined tokens
Issue 6369: Clarify join specs referencing control flow edges
Issue 6370: Clarify join rules
Issue 6371: Join example
Issue 6373: Parameters in Features and Common Behavior
Issue 6374: Initial nodes in structured actions
Issue 6375: Flows across SAN boundaries
Issue 6376: Terminating a SAN
Issue 6377: AcceptCallAction in SAN
Issue 6378: Questions about CentralBufferNode semantic
Issue 6379: Visibility of a Package
Issue 6380: Typo on Notation for CombinedFragment?
Issue 6381: Figure 395 requires a lot more explanation
Issue 6396: UML 2 super / state machines / entry and exit actions cannot be redefined
Issue 6397: UML 2 Super / state machines / restriction on redefining transitions
Issue 6399: UML 2 Super / Interfaces / Cannot nest classes in interfaces
Issue 6400: UML 2 super / Activities / structured activity node contradiction
Issue 6401: UML 2 Super / Interface / missing owner of operation
Issue 6402: UML 2 Super / Simple Time / incorrect multiplicities
Issue 6403: UML 2 Super / Activities / inconsistent naming
Issue 6404: UML 2 Super / Package Templates / StringExpression inconsistency
Issue 6406: UML 2 Super / Deployments / node composition
Issue 6407: UML 2 super / Templates / parameters cannot have names
Issue 6425: UML 2 Infras./Interactions/ execution occurrence should not be abstract
Issue 6426: ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation
Issue 6427: ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2
Issue 6428: ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics
Issue 6429: Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity
Issue 6431: ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint
Issue 6432: ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort
Issue 6434: UML Superstructure: 03-08-02 / <<instantiate>>
Issue 6437: targetScope on StructuralFeature and AssociationEnd
Issue 6439: UML 2.0 significant typo - collaboration diagram
Issue 6440: Excessive syntactic and semantic overlap between structured Classifiers
Issue 6442: Specification of parametric models
Issue 6443: The name "required interface" is misleading
Issue 6447: Corrections and improvements to glossary definitions
Issue 6448: Inconsistent use of terms "implement" and "realize"
Issue 6449: Diagram Taxonomy corrections
Issue 6450: Removal of gratuitous restrictions to software applications
Issue 6453: UML 2.0 Superstructure FTF issue - Profiles
Issue 6454: 14.3: StateInvariant and ExecutionOccurrence
Issue 6457: Abandon the OMGS4LMMA
Issue 6458: Change 'Part' to 'Role.
Issue 6459: glossary
Issue 6461: UML 2 Issue: Connector types
Issue 6465: UML 2 Issue: Include(s) and Extend(s)
Issue 6468: Section 7.3.1 ElementImport
Issue 6469: Section 7.3.5 PackageImport
Issue 6471: Section 7.13.2 Package Merge
Issue 6472: Section 7.15.3 Interfaces
Issue 6473: Section 7.18 Diagrams
Issue 6474: Section 8.1 Overview
Issue 6475: Section 8.3.1 Component
Issue 6476: Section 8.3.1 Component
Issue 6477: Section 8.3.3 Realization
Issue 6478: Section 9.4 Diagrams
Issue 6479: Section 10 Deployments
Issue 6480: Section 14.3.14 Message
Issue 6481: Section 14.4 Diagrams
Issue 6482: Section 14.4 Diagrams
Issue 6483: Section 14.4 Diagrams (02)
Issue 6484: Section 17
Issue 6485: Appendix A Diagrams
Issue 6486: Clarify termination of asynchronous invocations
Issue 6488: Conditions for parameter sets (02)
Issue 6490: Protocol machines do not subset state invariant
Issue 6491: Outputting constants
Issue 6499: Multiobject in UML2
Issue 6504: ActivityFinalNode and running actions - UML2 Superstructure issue
Issue 6505: Use Case Metamodel - UML2 Superstructure issue
Issue 6506: concurrent vs. parallel ExpansionRegions
Issue 6507: Binary associations decorated with large diamonds legal?
Issue 6508: Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue
Issue 6509: Large diamond for binary associations legal? - UML2 Superstructure issue
Issue 6510: AcitivityEdge: weight=all vs weight=null - UML2 Superstructure
Issue 6511: Token flow semantics: Implicit fork and join - UML2 Superstructure
Issue 6512: Guard conditions at fork nodes - UML2 Superstructure issue
Issue 6513: Components and artifacts: Dependency problem - UML2 Superstructure
Issue 6514: Operation without - UML2 Superstructure
Issue 6515: Inconsistency concerning VisibilityKind - UML2 Superstructure
Issue 6516: Dependency notation for interfaces - UML2 Superstructure
Issue 6517: Package Extensibility <<merge>> - UML2 Superstructure issue
Issue 6518: does "is not instantiable" imply "isAbstract"? - UML2 Superstructure
Issue 6519: Activity nodes and Stereotypes - UML2 Superstructure issue
Issue 6520: GeneralizationSet Description clarification - UML2 Superstructure
Issue 6521: The node "Order cancel request" that appears in figure 6-86
Issue 6522: Order cancel request
Issue 6523: Typos
Issue 6526: /pages 485,487,495/mixed names for state machine diagram
Issue 6527: Incorrect usage/definition of "emergence" in Common Behavior Chapter
Issue 6596: page 95 diagram
Issue 6605: Missing actual arguments in submachines states
Issue 6606: No way to represent "uninterpreted" actions
Issue 6607: Time trigger notation in state machines
Issue 6608: Notation when guards are used in conjunction with triggers in transitions
Issue 6625: UML 2 Super/Actions/PrimitiveFunction missing properties
Issue 6626: section 9 (State Machines) of 3rd revision
Issue 6627: UML 2 Super/Actions/non-existent feature "multiplicity"
Issue 6628: UML 2 Super/Action/featuringClassifier misinterpreted
Issue 6629: UML 2.0 Superstructure 3rd revision - Owner of triggers?
Issue 6642: Error in definition of PackageMergeKind
Issue 6643: UML 2 Super / use cases / incorrect comments in notation section
Issue 6644: UML 2.0 Superstructure reccomendation (derived unions)
Issue 6646: UML 2.0 Superstructure Derived Union vs. derivationExpression?
Issue 6647: UML2 Super/Composite Classes
Issue 6648: UML2 Super/parts
Issue 6666: UML2 Super/Structured Classes
Issue 6667: Page 164 - there are two constraints sections for Connector
Issue 6668: UML2 Super/Connector
Issue 6669: UML2 Super/Ports
Issue 6670: UML2 Super/Connector End
Issue 6674: subsettedProperty->forAll(sp | isDerivedUnion) ?
Issue 6675: UML 2 Super/Activities/end naming consistency
Issue 6676: UML 2 Super/Activities/assocition end specialization consistency
Issue 6677: UML 2 Super/Activities/invalid multiplicity 0
Issue 6678: UML 2 Super / Activities / inconsistency in representing subsetting
Issue 6679: UML 2 Super / Activities / association end naming
Issue 6680: UML 2 Super / Activities / subsetting two properties
Issue 6682: See CommonBehavior for a description of Event specifications
Issue 6690: UML2 Super/Signal
Issue 6691: Consistent Naming
Issue 6728: page 136, "BasicComponents",
Issue 6865: Ambuiguity in value pin evaluation
Issue 6868: UML 2 Super/State machines/pseudostate name consistency
Issue 6869: UML 2 Super / state machines / oclIsKindOf arguments error
Issue 6870: UML 2 Super / state machines / non-existent property reference
Issue 6871: UML 2 Super / state machines / incorrect property redefinition
Issue 6872: UML 2 Super / state machines / misplaced operation definition
Issue 6873: UML 2 Super / state machines / non-existent return type
Issue 6874: UML 2 Super / use cases / invalid subsetting
Issue 6875: Components / provided and required interfaces -- derived or subsets
Issue 6876: Appendix B/Standard Stereotypes too heavyweight and incompletely defined
Issue 6877: UML2 super/notation/Keywords
Issue 6896: "• value : InstanceSpecification
Issue 6897: importedMember property
Issue 6898: missing closing bracket
Issue 6900: UML 2 Super / Interactions / Two typos
Issue 6901: UML 2 Super / Classes /
Issue 6902: UML 2 Super / General / Idenitfy sections specifying run-time semantics
Issue 6911: UML 2 Super / Templates / subsetting templateParameter
Issue 6913: The contents of the Interfaces package is shown in Figure 51
Issue 6914: The query 'hostElement' has some errors
Issue 6915: The section "Associations (BasicActivities)" is not complete
Issue 6917: • /context : Classifier [0..1]
Issue 6918: Inconsistencies between Figure 3 and the detailled description of package
Issue 6919: Inconsistencies between Figure 43 and the detailled description of Package
Issue 6924: UML-2 deployment diagram notation
Issue 6925: UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition
Issue 6926: UML 2 Super / Dependencies / Abstraction should have an optional mapping
Issue 6928: UML 2 Super / Interactions / navigability of enclosingOperation
Issue 6929: UML 2 Super / Classes / Properties owned by properties
Issue 6930: UML 2 Super / Realize keyword-stereotype
Issue 6931: typo p 403
Issue 6932: typo p 420
Issue 6933: typo p 421
Issue 6934: graphic nodes
Issue 6935: typo p 240
Issue 6936: typo p 356
Issue 6937: object edges" sould be replaced by "object flows
Issue 6938: object edges" should be replaced by "object flows
Issue 6940: typo p 340
Issue 6941: Inconsistency between section "Associations" and Figure 327
Issue 6942: Constraint [2] - Missing parenthesis in OCL
Issue 6943: Wrong association name
Issue 6944: type p 419
Issue 6945: UML 2 Super / Classes / Dependency should not be abstract
Issue 6946: UML 2 Super / Deployments / Invalid cross-references
Issue 6947: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365
Issue 6948: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366
Issue 6949: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367
Issue 6950: Typo in Collaboration Diagram figure
Issue 6958: UML 2 Super / General / specialization labeling convention
Issue 6959: What level of MOF 2.0 is the metamodel for UML 2.0?
Issue 6960: Inconsistency betw. Figure 328 and associations listed in s. Associations
Issue 6961: Inconsistent multiplicity
Issue 6962: UseCase - Extend is not a Namespace
Issue 6963: UseCase - Inconsistencies with Figure 401
Issue 6964: Second row of table 22, column "Notation", labels switched
Issue 6965: UseCase - Constraint for non-circular include relation
Issue 6966: Typo in OCL
Issue 6967: UseCase - Include - Constraint for irreflexivity
Issue 6968: typo
Issue 6969: UML 2 Super / use cases / incorrect table title
Issue 6970: UML2 superstructur: actor
Issue 6972: self-activation notation in Sequence diagrams missing
Issue 6974: Ambiguous semantics of isStatic
Issue 6976: UML 2 Super/Interactions/incorrect text before Table 14
Issue 6977: UML 2 Super/Interactions/incorrect text and table title for Table 19
Issue 6978: graphic nodes for state invariant and continuation are not always distingui
Issue 6979: Ambiguous sentence and typo in description of EventOccurence
Issue 6980: UML 2 Super/Interactions/incorrect spelling of EventOccurence
Issue 6981: UML 2 Super/Interactions/incorrect grammar for <state-info>
Issue 6982: UML 2 Super/Interactions/rationale subsections not informative
Issue 6983: UML 2 Super/Interactions/Ambiguous description of state invariants
Issue 6984: word "execute" in definition of alternative CombinedFragment is ambiguous
Issue 6985: text differs from metamodel for critical region InteractionOperator
Issue 6986: UML 2 Super/Interactions/inconsistent spelling for InteractionOperator
Issue 6987: ambiguous definition of the scope of a break CombinedFragment
Issue 6988: Ambiguous example of a local action on a Lifeline in Figures 334, 335
Issue 6997: Additional Operations specification of NamedElement::allNamespaces()
Issue 6998: Typo p. 595, Table 25, row 6, column 3
Issue 6999: Missing multiplicities
Issue 7000: Typo p 137
Issue 7001: Connector - default value für "kind"
Issue 7002: Figure 103 at the wrong place
Issue 7003: Inconsistency with Figure 100
Issue 7004: Another Inconsistency with Figure 100
Issue 7005: Typo p 161
Issue 7006: Inconsistency between constraint of ControlNode and Semantics of JoinNode
Issue 7007: Multiple activity edges between a given pair of activity nodes possible ?
Issue 7008: Typo p 320
Issue 7009: Constraint not precise enough
Issue 7010: No Activity Edges from with equal source and target
Issue 7011: Typo - Missing colon p 302
Issue 7012: Typo p 339
Issue 7013: "Joining of tokens" not clear
Issue 7014: Unnecessary sentence p 339
Issue 7015: Constraint not precise enough
Issue 7016: Imprecise sentence p 334
Issue 7017: Multiplicity of extensionLocation should be 1..1 instead of 1..*
Issue 7018: ExtensionPoint should be a specialization of Feature (from Kernel)
Issue 7019: Typo p 587
Issue 7020: Typo p 589
Issue 7021: Stereotype «buildComponent» defined twice, description not clear
Issue 7039: Association - endType should be of type Classifier
Issue 7040: AssociationClass Constraint [1] should be reformulated
Issue 7041: AssociationClass - Additional Operation [1] should be deleted
Issue 7042: Constraints of ConnectionPointReference - OCL not correct
Issue 7043: p.461, first sentence:
Issue 7044: State - Inconsistency
Issue 7045: Define containingStateMachine() for Vertex
Issue 7046: State - Constraints - errors in OCL and inconsistencies
Issue 7047: Non-existent property isFinal referenced
Issue 7048: Change Constraint [1] to
Issue 7049: ownedStateMachine not described correctly
Issue 7050: Typo p 497
Issue 7052: Figure 355 - ownedStateMachine should subset ownedBehavior
Issue 7053: Figure 355 - mulitplicities of redefinitionContext should be 0..1
Issue 7054: Constraint [2], p.70
Issue 7055: Region - Additional structural constraints necessary
Issue 7056: Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition
Issue 7068: UML 2 Super / Classes / makesVisible () operation incorrect
Issue 7069: UML 2 Super / Interactions / Invalid subsetting for enclosingOperand
Issue 7070: GeneralizationSet - outdated description
Issue 7071: GeneralizationSet description conf. about meaning of "specific" + "general
Issue 7072: GeneralizationSet - Incorrect Mulitiplicities of associations
Issue 7073: GeneralizationSet - constraints expressed in OCL
Issue 7074: GeneralizationSet - example in section "Semantics" is not clear
Issue 7075: Collaboration - inconsistency with Figure 99
Issue 7098: Ambiguous semantics of isStatic - resubmission of issue 4446
Issue 7099: UML 2 Super / Activities / Fig.192 constraint duplicated
Issue 7106: StructuredClassifier - Regular expression for namestring too complicated
Issue 7107: Typo in Figure 124 on page 182
Issue 7108: Typo
Issue 7109: Sentence not finished in section "Changes from previous UML"
Issue 7110: Delete the following sentence in section "Notation":
Issue 7111: SendSignalAction
Issue 7112: Typo
Issue 7113: CreateObjectAction - delete constraint [4]
Issue 7114: DeleteObjectAction - delete constraint [1]
Issue 7115: Typo
Issue 7116: TestIdentityAction- delete constraint [2]
Issue 7117: TestIdentityAction - additional constraint
Issue 7118: Typo
Issue 7119: Typo
Issue 7120: ReadSelfAction - delete constraint [4]
Issue 7121: ReadSelfAction - Typos in OCL constraints
Issue 7122: Connector - Constraint [2] is inprecise
Issue 7123: Connector - Constraint [3] not necessary ?
Issue 7124: Figure 95
Issue 7125: Appendix A of the superstructure spec
Issue 7135: adopt a single notation to specify text strings used in the notation
Issue 7151: InteractionOccurrence - Syntax rules for name not clear
Issue 7152: Deployment - keyword <<deploy>> not introduced
Issue 7153: DeploymentTarget - Missing OCL expression
Issue 7155: Manifestation - visual representation should be dashed arrow
Issue 7156: UML 2 Super / General / Dcoument conventions
Issue 7157: UML 2 Super / General / consistent formatting conventions
Issue 7158: UML 2 Super / State machines / incorrect navigation specifications
Issue 7159: UML 2 Super / General / Classes chapter organization
Issue 7160: UML 2 Super/Interactions/Alternative with all false guards
Issue 7162: UML 2 Super / Appendix A / Typos
Issue 7178: Component - problem with provided interfaces (see also Issue 6875, 6338)
Issue 7179: DestroyObjectAction - inconsistency in constraints
Issue 7180: Typo - section Description, first sentence
Issue 7181: AddStructuralFeatureValueAction - Settability removeOnly does not exist
Issue 7182: LinkEndData - Inconsistency with Figure 146
Issue 7183: LinkEndData - Typo in OCL
Issue 7184: LinkEndData - Additional operation not correct
Issue 7185: MultiplicityElement - section is obsolete
Issue 7186: ReadLinkAction - inconsistency with Figure 147
Issue 7187: ReadLinkAction - Constraints use deprecated UML elements
Issue 7188: DestroyLinkAction - Semantics based on non existing "settability addOnly"
Issue 7189: Variable - Typo in Attributes
Issue 7190: VariableAction - undefined query
Issue 7191: AddVariableValueAction - OCL in constraint [1] not correct
Issue 7196: Typo, section "Description", paragraph 1
Issue 7213: use of stereotypes
Issue 7219: Operations and derived attributes
Issue 7220: Composite Structures, 03-08-02.pdf
Issue 7221: Activity Diagrams: Relax Traverse-to-Completion semantics
Issue 7222: Activity Diagrams: Relax Traverse-to-Completion semantics
Issue 7226: State machines / name of transitions association end
Issue 7228: UML2 super/Deployments/CommunicationPath
Issue 7230: UML 1 activities
Issue 7231: UML2 Super/Composite Structure
Issue 7232: Stereotype
Issue 7233: Stereotype - typo in OCL
Issue 7234: Stereotype - Inconsistency in notation Section "Notation", last sentence
Issue 7235: Typo In section "Description"
Issue 7236: ActivityPartition - inconsistencies
Issue 7237: Typo Section: 12.3.8
Issue 7238: Typo in ptc/03-08-02 p. 178
Issue 7239: Connector - inconsistency
Issue 7240: Connector - typo and inconsistency
Issue 7241: Connector - inconsistency
Issue 7243: ConnectorEnd - multipliciy of role
Issue 7244: Interface - Typos in Figure 63
Issue 7245: Figure 77
Issue 7253: UML Sequence diagram
Issue 7256: transition is simply never enabled
Issue 7276: UML 2 Super / Profiles / problem with name collisions
Issue 7277: UML 2 Super / Templates / invalid multiplicity
Issue 7287: Message - inconsistency
Issue 7288: Message - inconsistency (02)
Issue 7289: Message - inconsistency "Messageident equalling ‘*’
Issue 7290: AcceptEventAction - inconsistent multiplicities
Issue 7291: AcceptEventAction - inconsistency
Issue 7292: AcceptEventAction - inconsistencies in Semantics and typos
Issue 7293: AcceptCallEvent - inconsistent multiplicity "• trigger
Issue 7294: ReplyAction - Inconsistency with Figure 150
Issue 7295: ReplyAction - Typo
Issue 7296: ReadIsClassifiedObjectAction - OCL errors in constraints
Issue 7297: StartOwnedBehaviorAction - OCL error in constraint
Issue 7298: ReadLinkObjectEndAction - errors in OCL
Issue 7299: ReadLinkObjectEndQualifierAction - errors in OCL
Issue 7300: InformationItem - Typo
Issue 7301: UML2 super/interactions
Issue 7319: behavior packages (Interactions, Statemachines
Issue 7320: notation for statemachine transitions omitted from spec
Issue 7321: UML 2 Super/Connector
Issue 7322: "Implementation" is ommitted
Issue 7323: UML 2 Super / state machines / state should be a namespace
Issue 7324: introductory text for Property states
Issue 7325: Section: 15.3.12
Issue 7326: Notation of ExecutionOccurrence
Issue 7327: heading of table 19
Issue 7328: enumerated type MessageSort
Issue 7330: Section: 12.3.20
Issue 7331: Page: 589
Issue 7333: There is no redefinitionContext established
Issue 7335: behaviors
Issue 7336: UML 2 Super / missing owners of concepts
Issue 7342: association "context"
Issue 7344: formal parameter or a return result
Issue 7345: typo p. 149
Issue 7346: ActivityEdge - Section Semantics - Typo
Issue 7347: ActivityEdge - Typo
Issue 7348: ObjectNode
Issue 7349: ParameterSet - Typo
Issue 7350: Figure 273 - Arrow direction Figure 273
Issue 7355: Q re Parameter
Issue 7357: association between two Nodes
Issue 7358: signal
Issue 7359: component deployment
Issue 7360: typo
Issue 7361: typo
Issue 7365: UML2 Super / ordering of association ends
Issue 7366: UML2 Super / Classes / Operation constraints
Issue 7367: UML 2 Super / General / superclass pointers
Issue 7368: UML2 Super / Use cases / navigation from subject to use case
Issue 7369: UML2 Super / Common Behavior / Trigger should be a named element
Issue 7370: Section 9.3.1
Issue 7371: Section 9.3.5. (ConnectableElement)
Issue 7373: attribute Activity.isSingleExecution
Issue 7374: Inappropriate to reference RFP documents
Issue 7376: p.328, Figure 245, and p.331, Figure 249
Issue 7377: empty sections in activities chapter
Issue 7378: p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate
Issue 7379: Question about Enumeration and EnumerationLiteral
Issue 7380: UML 2 issue, Common Behaviors
Issue 7393: Activities
Issue 7394: Variable pins Extend input and output pins to get and set variables
Issue 7395: SAN semantics for starting and stopping
Issue 7396: Constraint 2 of AcceptEventAction - typo
Issue 7399: MarshallAction and UnmarshallAction
Issue 7402: XMI schema (02)
Issue 7403: change trigger
Issue 7404: property strings on association ends
Issue 7405: PrimitiveFunction
Issue 7408: Section: 7.11.2
Issue 7409: three possibilities for aggregation kind at 7.11.2, but only two notations
Issue 7410: It is not clear what 'related to' means
Issue 7411: At «implementation Class», what does "a child of instance" mean?!
Issue 7412: What is a mapping that is not computable?
Issue 7413: association "implementingClassifier
Issue 7414:
Issue 7415: Section: 9.3.3
Issue 7416: Association collaborationRole
Issue 7417: Removed text in 9.3.3
Issue 7418: Can connectors co-operate?
Issue 7419: Editrial error in Section: 9.3.4 ?
Issue 7420: Description text for CollaborationOccurrence unclear
Issue 7421: TemplateSignature - inconsistency
Issue 7422: TemplateSignature - Typo
Issue 7423: TemplateableElement - inconsistency
Issue 7424: ParameterableElement - constraint [2] - error in OCL
Issue 7425: ProtocolConformance - inconsistency with Figure 356
Issue 7426: Notation of enumeration literals
Issue 7427: Templates, Classifier
Issue 7428: Section: 12.3.16 -- Typo
Issue 7429: ExceptionHandler
Issue 7430: Composite structures/Unspecified connector features
Issue 7431: Composite structures/contradictory constraint on connector
Issue 7432: Figure 51, p106
Issue 7433: Figure 52, p107: shouldn't the <<refine>> relationship be reversed ?
Issue 7434: Figure 109, p162
Issue 7435: Concept of 'port side' not to be found in metamodel
Issue 7436: figure 175
Issue 7437: Figure 205, p292:
Issue 7438: Section: 12.3.3
Issue 7439: What are the "edges" we're talking about?
Issue 7440: Section: 12.3.16
Issue 7441: UML 2 Super/Interfaces
Issue 7442: Components
Issue 7443: Issue in UML 2 Interaction package
Issue 7444: Issue on UML 2 Interaction class
Issue 7445: Issue in UML 2 Interaction class : Local attributes
Issue 7446: Issue in UML 2 Interaction class: Lifeline ordering
Issue 7447: Issue in UML 2 Lifeline class
Issue 7448: Issue in UML 2 Message class
Issue 7449: Issue in UML 2 Message class
Issue 7450: Issue in UML 2 CombinedFragment class
Issue 7451: Issue in UML 2 Continuation
Issue 7452: Issue in UML 2 Gate class
Issue 7549: actions
Issue 7550: All single query operations in the spec defined in OCL invalid ?
Issue 7552: Actions need to be independent from Activities
Issue 7553: UML 2 Super/Interactions/Need unattached lifelines
Issue 7554: Attribute scope is of type StructuredActivityNode instead of StructuredActi
Issue 7555: State Machine Package--Compliance
Issue 7558: Semantics section of StructuralFeature
Issue 7559: There is no "precise mapping
Issue 7560: Issue 6094 correction.
Issue 7561: Issue 6090 correction
Issue 7562: ReadSelfAction
Issue 7567: Port should specialize featuringClassifier
Issue 7574: StartOwnedBehaviorAction
Issue 7575: Notation for property has gone missing
Issue 7576: UML 2 Super/state machines/Maximum one region
Issue 7577: Remove Package Templates? Feedback requested
Issue 7590: Loop notation
Issue 7593: Wrong metamodel for internal transitions
Issue 7598: UML2 super&infra/Profiles/ownership of Image
Issue 7606: Need to documetn diagramming conventions for association ends
Issue 7607: UML 2 Super/Activities/Class-Activity association missing
Issue 7608: Profiles
Issue 7612: Section: 7.11.4
Issue 7613: Section: 9.3.12
Issue 7614: Section: 9.3.12
Issue 7615: UML 2 Super/Infra: return type of an operation
Issue 7616: UML 2 Super/Infra: no notation for "isQuery" characteristic of Operations
Issue 7617: UML 2 Super/Interactions/ LOOP construct specifications
Issue 7618: UML 2 Super/Templates/Template substitution symbol problematic
Issue 7621: UML 2 Super/Interactions/notation for accessing a static feature
Issue 7622: UML 2 Super/Components/missing description of Connector::contract
Issue 7623: UML 2/ Inconsistencies in usage of package merge
Issue 7624: Name without a colon for Property in Composite Structures
Issue 7625: Missing notation for Behaviors in a BehavioredClassifier
Issue 7626: Redundant parameter specifications for Operation and Behavior
Issue 7627: Profiles in Compliance Level 1?
Issue 7630: resolution to issue 6093 removed too much constraint
Issue 7631: Incorrect constraints on Pin and ObjectFlow On Pin
Issue 7637: Additional events for Interactions
Issue 7638: Events
Issue 7642: Property.association
Issue 7643: presentation option for transitions
Issue 7644: . <<create>> on Usage
Issue 7645: Figures 103 and 121 use <<create>> dependencies
Issue 7646: Figures 120 and 121
Issue 7649: UML 2 Super Issue re: DI compliance
Issue 7650: Bidirectional messages to a port object
Issue 7651: Compliance points - Diagram Interchange
Issue 7652: "required interface"
Issue 7654: Messages to ports with only one connector
Issue 7664: UML2 super/Profile/Unconsistent Profile extension description
Issue 7665: UML2 super/Profile/Unconsistent association extension description
Issue 7668: P.35 Typo in OCL definition of isDistinguishableFrom query
Issue 7669: P.58 Missing closing bracket in second constraint
Issue 7670: Dependency errors
Issue 7671: Correction to 7336
Issue 7673: Active and passive
Issue 7675: UML 2 does not permit use of a state machine
Issue 7676: check the BNF example given in the text
Issue 7683: included use case wrongly referred to as the including use case
Issue 7747: multiplicity of the "role:ConnectableElement"
Issue 7748: "role binding"
Issue 7758: UML 2 Super and Infra/ defualt property of Parameter::effect
Issue 7777: Associations between interfaces
Issue 7778: CollaborationOccurence
Issue 7779: UML 2.0 Issue: Semantics of Provided and Required Interfaces
Issue 7780: UML2 Superstructure - profiles
Issue 7784: UML 2 Superstructure - cross-hair notation for nested classes
Issue 7825: UML 2 Superstructure -Incompatible use of term link
Issue 7831: UML 2 Super/Templates/Inconsistent organization
Issue 7847: Dependency associations
Issue 7848: Deployment (from ComponentDeployments, Nodes)
Issue 7850: UML2 super/CommonBehavior/Opaque behavior : bad OO modelling
Issue 7851: section 8.3.2, a "Connector"
Issue 7854: 7.3.24 Interface (from Interfaces)
Issue 7855: 9.3.6 Connector (from InternalStructures)
Issue 7856: 8.3.1 Component (from BasicComponents, PackagingComponents)
Issue 7857: .3.44 Property (from Kernel)
Issue 7858: 9.3.11 Port (from Ports)
Issue 7859: Artifact (from Artifacts)
Issue 7860: 15.3.16 Vertex (from BehaviorStateMachines)
Issue 7861: 15.3.8 Pseudostate (from BehaviorStateMachines)
Issue 7862: 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)
Issue 7863: 15.3.10 Region (from BehaviorStateMachines)
Issue 7864: 15.3.14 Transition (from BehaviorStateMachines)
Issue 7865: notational standard for {subsets x} in textual contexts
Issue 7866: inadequate definition of 'constructor'
Issue 7875: inconsistent Generalization subsections in spec format
Issue 7876: "Class" should read "Classifier" in Generalization subsection for Behaviore
Issue 7879: Associations section of InteractionUse
Issue 7881: UML 2 Super/ Classes / issue with Property::isComposite
Issue 7882: UML2 Super / Templates / ordering of subExpressions
Issue 7884: Figure 307 and Figure 308 are exactly the same

Issue 1209: Parametrizable model elements not shown (uml2-superstructure-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Summary:  Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
 ModelElements". Implicitly not to all ModelElements. Which ModelElements
 can
 and which cannot be templates? 
  Some clarifications would be welcome, in what concerns the
 parametrisation of other kind of model elements, such as packages,
 operations and methods.
 

Resolution:
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: Deferred:UML 1.4/2.0
March 9, 2005: closed issue

Discussion:
The definition of templates was significantly tightened up in UML 2: Only operations,
classifiers, and packages can be templates.


Issue 1512: Need for notation for dealing with evolution of UML models (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:
 

Resolution:
Revised Text: This issue will be addressed by the MOF versioning specification. Hence, it is outside the scope of UML
Actions taken:
June 8, 1998: received issue
July 22, 1999: Deferred:UML 1.4/2.0
March 9, 2005: closed issue

Discussion:
 Deferred to UML 1.4/2.0. This issue will be addressed by the MOF versioning specification. Hence, it is
outside the scope of UML.


Issue 2020: Guard in current metamodel can be replaced by Constraint with stereotype (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:
Summary: The Guard metatype in the current metamodel contains only one attribute
     of type BooleanExpression.   Since a guard is semantically equivalent to
     a Constraint on the transition, we can remove the Guard metaclass and
     add e standard stereotype <<guard>> for Constraints, with the same
     semantics.
 
     It simplifies the metamodel by unifying the Guard and Constraint concepts.
     It also allows OCL as the optional language to write the guard expression.
 
     Within the OCL specification, it should be checked if there are any
     additions that need to be made to support everything neded to express
     udseful guards.
 
 

Resolution:
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: Deferred:UML 1.4/2.0
March 9, 2005: closed issue

Discussion:
This is merely a metamodel optimization transparent to a UML user and not a bug or inconsistency in the spec. Hence, it is out of scope for 1.5. It should be considered for UML 2.0. Resolved in UML 2.0, where a guard is now modeled as a Contraint (association
from Transition to Constraint in the metamodel).


Issue 2083: AssociationEnd needs ownerScope (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
 model a static (as in Java) relationship? Currently, it appears to only be
 possible using an Attribute of Classifier.
 

Resolution:
Revised Text:
Actions taken:
October 15, 1998: received issue
March 9, 2005: closed issue

Discussion:
This issue is resolved in UML 2.0 where association end is represented as a
Property, which is a kind of StructuralFeature, which is a kind of Feature. Feature
has an isStatic attribute which allows the modeling of static attributes, including
association ends.


Issue 2208: Figure 7 p. 43 of the UML semantics guide (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Summary: On Figure 7 p. 43  of the UML semantics guide,
 Template is described as a shared aggregate of its templateParameters,
 while Binding (representing an instantiation of a Template) is described
 as a composite aggregate of the actual arguments.
 
 

Resolution:
Revised Text:
Actions taken:
November 13, 1998: received issue
March 9, 2005: closed issue

Discussion:
The modeling of templates in UML 2.0 has completely changed, so this issue is
no longer applicable.


Issue 2276: UML 1.1.section 4.2:editorial (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: Aggregation: "when on target end, specifies whether target end
 with respect to source end". I think target and source are the wrong
 way round here. 
 

Resolution:
Revised Text:
Actions taken:
December 22, 1998: received issue
March 9, 2005: closed issue

Discussion:
This text has been changed for UML 2.0 according to the new metamodel, so
that this issue is no longer applicable.


Issue 2277: Page 19 semantic doc. name (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: Page 19 semantic doc. name is described here but is not shown as
 a metalevel attribute on Figure 6. It should be.
 

Resolution: see above
Revised Text:
Actions taken:
December 22, 1998: received issue
March 9, 2005: closed issue

Discussion:
This part of the metamodel has completely changed in UML 2.0, so this issue is
no longer applicable.


Issue 2278: OCL needs to be added (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: Only binary associations may be aggregates. There needs to
 be OCL added to do this.
 

Resolution: Add the missing OCL
Revised Text: In Infrastructure section 11.3.1 Association add the following to the end of the Constraints section: [4] Only binary associations can be aggregations self.memberEnd->exists(isComposite) implies self.memb erEnd->size() = 2 In Superstructure section 7.11.2 Association add the following to the end of the Constraints section: [4] Only binary associations can be aggregations self.memberEnd->exists(aggregation <> AggregationKind::none) implies self.memberEnd->size() = 2
Actions taken:
December 22, 1998: received issue
March 8, 2005: closed issue

Discussion:
 received issue


Issue 2289: Missing OCL (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: I would like to note that in the UML Semantics specification (versions 1.1
 and 1.2) the third well-formedness rule for Association does not have an
 OCL expression.  It has only the natural language expression.
 

Resolution:
Revised Text:
Actions taken:
January 5, 1999: received issue
March 9, 2005: closed issue

Discussion:
No longer applies - even at UML 1.3 all the well-formedness rules for
Associations had OCL


Issue 2290: ElementOwnership (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
 declares ElementOwnership as an AssociationClass.  This appears to be a
 violation of MOF compliance, since the MOF meta-meta-model does not support
 the notion of an AssociationClass.  
 
 Of course one could extrapolate AssociationClass from the MOF
 meta-meta-model since it does support both Association and Class, and one
 could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
 extrapolated MOF AssociationClass.  However, two architects might
 extrapolate these mappings in perfectly valid but different manners, since
 there is no standard mapping for a MOF AssociationClass.  Apparently such
 an extrapolation has been performed in order to derive the IDL for the UML
 meta-model that concerns ElementOwnership, but doing this without a
 standard mapping seems dangerous.
 

Resolution:
Revised Text:
Actions taken:
January 5, 1999: received issue
March 9, 2005: closed issue

Discussion:
UML 2 does not use AssociationClasses in the metamodel itself so this
issue no longer applies.


Issue 2291: User-defined symbols for tagged values and properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity:
Summary:
Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties {ordered}, {frozen} and {add only} may define they own user-defined icons for those properties, because UML does not define them. 
 
 Suggested Solution:  
 UML users should be allowed to define specific symbols and icons for tagged values and properties. 
 

Resolution:
Revised Text:
Actions taken:
January 6, 1999: received issue
March 9, 2005: closed issue

Discussion:
The purpose was (UML1.4) that Stereotypes do change notation, and tagged values do
not. In the above examples, stereotypes could have been adopted instead of tagged values
(ex : <<ordered>>).
In addition, tagged values frequently can have a value, and therefore need a syntaxical
representation.
(Pete’s comment) {ordered} is not a tagged value but one of the many varied and random
uses of text within {} to represent all sorts of diverse things in the metamodel. This is
probably a separate issue in its own right (unrelated to profiles) – since UML has no
specific notion of reserved words it seems intractable to determine, from {text} on a
diagram what it represents in the metamodel..
See 6280 for introducing notation customization to the Profile.


Issue 2336: extension to the notation for a transition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Summary: I would like to make an appeal for an extension to the notation for a transition 
 to allow its effect to be specified declaratively rather than only imperatively by 
 means of an action sequence, e.g. 
 
 e() / [p] 
 
 While I realize there are ways to work around this (e.g. by writing "e() / pTrue()" 
 where the query pTrue() has the postcondition "result = p and in targetState"), I
 think the issues are readability and ease of use. 
 
 

Resolution:
Revised Text: This is an issues (enhancement) submitted to UML 1.4 RTF, which is addressed to a large extent by protocol state machines syntax in UML 2.0. Therefore the recommendation is to close the issue.
Actions taken:
January 22, 1999: received issue
March 9, 2005: closed issue

Discussion:
This is a minor modeling enhancement to UML that would result in a significant change to the metamodel of state machine in the standard. However, it may be useful to consider it for UML 2.0.


Issue 2337: Associate a predicate with a state (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Summary: Related to the previously submitted issue regarding the declarative specification of
 the effects of transitions, I would like to suggest that it be possible to associate
 a predicate with a state.
 
 Such a predicate (e.g. written in OCL) would appear within the state box in the
 notation, just below the name of the state.
 
 Rather than extend the notation directly, I suggest this be a predefined property,
 e.g. {predicate = boolean-expression}.
 

Resolution:
Revised Text:
Actions taken:
January 22, 1999: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, there is now an association between State and Constraint with a role
name of “stateInvariant” that models this feature. The invariant can be expressed
in any language that is used for constraints, including OCL. The notation is to
include the predicate in an expression between square brackets following the
state name (see Figure 391 in the FAS).


Issue 2361: Inheritance violation in "Auxiliary Elements" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France
 
 Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
 1999 and the associated Rational Rose model files
 
 Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
 Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
 2.5.3, pp.2-49
 
 Nature: Clarification
 
 Severity: Medium
 Summary: In the 1.1 model file, there is an inheritance relationship
 between
 "Presentation" (in "Auxiliary Element") and "Element" (in "Core"). 
 "Presentation" is an association class and "Element" is a normal class. 
 The two types are not the same, this this brings up the following
 constraint in the semantic document:
 
 	self.subtype.oclType = self.supertype.oclType
 
 Question:
 1) Is "Presentation" suppose to inherit from "Element"?  The other
 association classes "ElementOwnership" and "ElementReference" do no
 appear to do so.
 
 2) If the answer to (1) is yes, then isn"t it a violation of the UML
 semantics" well-formedness rule.
 

Resolution:
Revised Text:
Actions taken:
February 1, 1999: received issue
March 9, 2005: closed issue

Discussion:
UML 2 no longer contains the class ‘Presentation’ so this issue no
longer applies.


Issue 2362: Incomplete Inheritance Specification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France
 
 Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta
 
 Specification section reference: None
 
 Nature: Clarification
 
 Severity: Minor
 
 Summary: There is an oddity in the inheritance relationship of
 "Classifier" in "Core".  Is "Classifier" suppose to inherit from
 "Taxon-Datatype", but the specification is incomplete.  Rational Rose
 and Rose98 raises an error for this association during a "Check Model".
 
 

Resolution:
Revised Text:
Actions taken:
February 1, 1999: received issue
March 9, 2005: closed issue

Discussion:
UML 2 no longer contains the class ‘Taxon-Datatype’ so this issue no
longer applies.


Issue 2541: Datatypes: Expression (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: the metaclass Expression includes an attribute called "language" of type
 Name. To enable tools to check OCL expressions, it is neccesary to
 define a standard value for this attribute, which denotes the fact that the
 expressions is an OCL expression.
 Without such a standard defined value tools cannot distinguish OCL
 expresions and cannot interpret them (for purposes of typechecking,
 code generation, etc....)
 
 I propose to add the value "OCL" as a standard value for the attribute
 "language" of metaclass "Expression" to the chapter on datatypes.
 

Resolution:
Revised Text:
Actions taken:
March 15, 1999: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0 Infrastructure section 9.7.2, OpaqueExpresion, does state
that the form ‘OCL’ should be used, though no specific values are
defined for other languages: it is deferred to the source specification
for that language.


Issue 2582: class EnumerationLiteral issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Summary: I think that the class EnumerationLiteral should be an heir of DataValue
 (this inheritance relationship is currently missing).
 
 Once this is fixed, the association between EnumerationLiteral and Enumeration
 should be seen as a refinement of the association between DataValue and DataType
 (itself implicitly inherited from the association between Instance and classifier),
 with a supplementary OCL constraint in the case of EnumerationLiteral,
 namely that   self.classifier.oclIsKindOf(Enumeration)
 (to ensure covariance, as is done for DataValue wrt DataType).
 
 BTW, shouldn"t there be a symetric OCL constraint in DataType
 specifying that its Instances are all DataValues,
 and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?
 

Resolution:
Revised Text:
Actions taken:
April 12, 1999: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0 EnumerationLiteral has been made a subclass of InstanceSpecification.
Hence, some of the arguments above do not apply. Of course, it could be argued that
EnumerationLiteral should be made a kind of ValueSpecification (like other literals) but
that would probably require more overhead, since, in most realizations, the definition of
an EnumerationLiteral typically occupies more resources than a pointer to that definition
(i.e., an InstanceValue).
Unfortunately, there does not seem to be a specialization of ValueSpecification that
distinguishes a “pure” value specification from an object instance. Therefore, it is not
possible to write a constraint to the effect that only pure values can be stored in
InstanceSpecifications that correspond to DataTypes.


Issue 2613: Interfaces on Nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:
Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot 
 determine if interfaces are allowed on Nodes.  Since a Node is a kind
 of classifier, it seems possible that a Node can realize an interface.
 However, since this relationship is not explicitly mentioned as allowed
 or not, I am unclear as to the intention.
 

Resolution:
Revised Text:
Actions taken:
April 19, 1999: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired.


Issue 3123: "Physical" Metamodel Package Structure (uml-rtf) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The package structure of UML 1.3 makes it difficult to deploy small parts of
the "physical" metamodel separately.  For example, a MOF-based facility that
supports classes from Behavioral_Elements.Common_Behavior must support all
of Behavioral_Elements.  A facility that supports Exceptions must also
support Use Cases and State Machines.  This has been a problem in the
formation of the CWM metamodel which extends UML.  Its interfaces and DTDs
are made to be much too large.

The result of UML currently having three metamodels (two of which are large)
rather than many smaller metamodels is that the IDL modules are very large
and so are the DTDs.  Breaking the metamodels into several smaller ones will
allow smaller interface sets and DTDs that can be mixed and matched to
provide necessary functionality without a huge overhead.  

Resolution:
Revised Text:
Actions taken:
December 15, 1999: received issue
March 9, 2005: closed issue

Discussion:
The package structure of the UML 2.0 is radically different from UML 1.x, so that
this issue is no longer applicable.


Issue 3126: Operations and Constraints Missing from "Physical" Metamodels (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The "physical" metamodel should include the OCL constraints and operations
defined in the UML Specification.  This has been done in the MOF 1.3
specification.  The operations provide valuable capabilities and should be
part of the standard UML facility interfaces.  Making the operations part of
the "physical" metamodel allows them to be used when defining new
constraints in extension metamodels, such as in CWM.

Recommendation:  Add the specification's constraints and operations to the
"physical" metamodel.

Note that adding constraints and operations will affect IDL, but it will not
affect XMI DTDs.

Resolution:
Revised Text:
Actions taken:
December 15, 1999: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0 the adopted XMI representation of the metamodel does contain
the operations used in defining the abstract semantics.


Issue 3127: Data Types Misplaced in the "Physical" Metamodel (uml-rtf) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
All data types used in the UML metamodels are clumped together in a
Data_Types package in the Foundation metamodel.  When a new type is needed
by some other metamodel, such as for Activity Graphs, the type is added into
Foundation.  This breaks the whole concept of extensibility.  Data types,
like other model elements, should be defined in the specific packages where
they are needed.  A new package that requires new types should include those
types itself and not impose a change on UML Foundation.

Recommendation:  In the "physical" metamodel, put data types into the
packages where they are first used.  For example, PseudostateKind should be
defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

Resolution:
Revised Text:
Actions taken:
December 15, 1999: received issue
March 9, 2005: closed issue

Discussion:
This has already been done at UML 2.0 (e.g. AggregationKind is
contained in Kernel::Classes).


Issue 3202: Another State machine issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:
State Machines

    The metaclass StateVertext, including its subclasses PseudoState,
    StubState and SyncState is not owned by a StateMachine.

    The associations from StateVertext to
     - container : CompositeState
     - outgoing  : Transition
     - incoming  : Tranision
    can all be empty.  
    If they are all empty in a model, we do not know to which statemachine
    this StateVertex belongs.  IS this the intention ?

Resolution: see above
Revised Text:
Actions taken:
January 10, 2000: received issue
March 9, 2005: closed issue

Discussion:
The issue described here is partially obsolete relative to the UML2.0 metamodel. The
StateVertex is properly owned and can navigate back to its owning region.


Issue 3276: UML RTF 1.4 Issue: Dynamic concurrency arguments (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Actions in dynamically concurreny states in activity graphs need
some way to access the arguments provided by the concurrency
expression.  The Reference manual suggests the "implicit" event,
but does not define what that is (p 437).  Perhaps it is an the
action language issue.

Resolution:
Revised Text:
Actions taken:
February 5, 2000: received issue
March 5, 2002: moved from UML RTF to Action Semantics FTF
December 28, 2004: resolved by the UML 2 Superstructure FTF
March 9, 2005: closed issue

Discussion:
[Action Semantics FTF]:
The dynamic concurrency model is being fixed in UML 2.0.
[UML 2 Superstructure FTF]:
Resolved in UML 2 by ExpansionRegion.


Issue 3285: UML RTF 1.4 Issue: Parallel action iteration (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Actions should have a isParallel attribute to specify if the iteration
is sequential or parallel.

Resolution:
Revised Text:
Actions taken:
February 5, 2000: received issue
February 27, 2001: Deferred:Action Semantics
March 5, 2002: moved from UML RTF to Action Semantics FTF
December 28, 2004: resolved by the UML 2 Superstructure FTRF
March 9, 2005: closed issue

Discussion:
The interaction is being updated significantly in UML 2.0.
[UML 2.0 Super FTF]
Closed, no change
This is resolved in UML 2 by options on ExpansionRegion.


Issue 3291: UML RTF 1.4 Issue: Missing notation mapping for association in composite (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
No mapping for this in mapping section, p 3-77:

  [p 3-75, Notation section for Composition] An association drawn
  entirely within a border of the composite is considered to be
  part of the composition.

Resolution:
Revised Text:
Actions taken:
February 5, 2000: received issue
March 9, 2005: closed issue

Discussion:
The notation part of the spec has been merged with the semantics part of the
spec in UML 2.0, so that this issue is no longer applicable.


Issue 3341: Statemachine/state as Namespace (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no)
Nature: Uncategorized Issue
Severity:
Summary:
I am not sure if this qualify as an Issue, but I what just wondering 
why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the  context model element? 

Resolution:
Revised Text:
Actions taken:
February 28, 2000: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, state machines are kinds of namespace, and states can be made
into namespaces via the submachine state mechanism.


Issue 3368: Efficient diagrammatic notation for Collaboration Specifications (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling :-)) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

Resolution:
Revised Text:
Actions taken:
February 26, 2000: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 resolves this problem with the introduction of CollaborationOccurrence (sorry
for the strange name). A collaboration occurrence represents one particular use of a
collaboration to explain the relationships between the properties of a classifier.
Associated dependencies map features of the collaboration type to features of the
classifier. These dependencies indicate which role in the classifier plays which role in the
collaboration.


Issue 3376: ClassifierRoles should be independent of specific underlying base Classifi (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
 ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example. 

Collaboration Templates don't do the trick; templates serve a different purpose. 

Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

Resolution:
Revised Text:
Actions taken:
February 26, 2000: received issue
March 9, 2005: closed issue

Discussion:
Collaborations have been rewritten in UML 2.0, and as a consequence, this issue has
already been addressed. Roles in a collaboration now are not any more related to a base
classifier. Instead, they represent a set of properties that an instance must possess that
plays that role. These properties are described by the classifier typing that role. This
classifier can have as many or as little properties as needed, even none (which would
correspond to the “free” classifier requested).


Issue 3382: UML 1.4 issue: Top state in activity graphs (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Top state in activity graphs

The state machine meta-model currently requires a top state, whereas
activity graphs should not.  Composite states are not required for
activity graphs (wf [2] for PseudoState, p 2-166).

Resolution:
Revised Text:
Actions taken:
February 29, 2000: received issue
March 9, 2005: closed issue

Discussion:
The metamodel for activities is no longer dependent on state machines in UML
2.0, so this issue is no longer applicable.


Issue 3391: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock(at)objectswitch.com)
Nature: Uncategorized Issue
Severity:
Summary:
Multiple languages for uninterpreted strings

The various places that uninterpreted strings are used in UML should
support multiple languages.  For example, the Expression metaclass has
an metaattribute for language and another for the uninterpreted string.
This should be a set of such pairs.  Then code generators can target
multiple languages from the same model.

Resolution: resolved, see above
Revised Text:
Actions taken:
March 1, 2000: received issue
March 8, 2005: closed issue

Discussion:
In Figure 13 and the entry for OpaqueExpression in Classes, change the
multiplicities of the attributes of OpaqueExpression as follows:
body : String [1..*] {ordered}
language : String * {ordered}
In OpaqueExpression in Classes:
Description,
Replace "a language-specific text string" with "language-specific
text strings"
Replace "of the language" with "of the languages".
Attributes
Entry for body attribute, at end of text, add ", possibly in multiple
languages".
Entry for language attribute, replace "language" with "languages",
and "is unspecified" with "are unspecified". At end of text add new
sentence "Languages are matched to body strings by order.".
Semantics,
Throughout, replace "language" with "languages", "body" with
"bodies", "is unspecified" with "are unspecified".
UML 2.0 Superstrucure FTF Final Report
Document {Report document number} Page 57
At end of first sentence add new sentence, "Languages are
matched to body strings by order.".
Notation,
First paragraph
First sentence, replace first "a text string in a particular
language" with "text strings in particular languages".
Second sentence, replace "syntax of the string is" with
"syntax of the strings are", and "linguistic analyzer for the
language" with "linguistic analyzers for the languages".
Third paragraph
First sentence, replace "language" with "languages".
Last sentence, at end, add "to which it corresponds.".
Disposition: Resolved


Issue 3569: Why is a StateMachine's top a State instead of a CompositeState? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Every StateMachine must have one top State. However, there is an
OCL constraint that says that the top State must be a CompositeState
(Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
2-141). So, why not make the top relationship from StateMachine to
CompositeState instead of from StateMachine to State. The constraint can
then be eliminated.

Resolution:
Revised Text:
Actions taken:
April 18, 2000: received issue
March 9, 2005: closed issue

Discussion:
This is a minor modeling enhancement to UML that would result in a significant change to the metamodel of state machine in the standard. However, it may be useful to consider it for UML 2.0. The metamodel for state machines has changed significantly in UML 2.0, so that
this issue is no longer applicable.


Issue 3632: Document 99-06-08 - UML Spec (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I'd find the document easier to digest if Chap 2 had some pictures in it.
>>
>>I know that the semantics is supposed to be independent of the
>>representation. However, Chap 3 *does* contain some semantics in it for
>>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
>>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
>>picture of the diamond shaped association end for aggregations, it would be
>>easier to follow what the document is talking about.
>>
>>At least sections 3.55.1 and  2.11.4 for instance might have links, even if
>>only footnotes, to connect actor notation and semantics.

Resolution:
Revised Text:
Actions taken:
May 19, 2000: received issue
March 9, 2005: closed issue

Discussion:
longstanding issue regarding separtion of notation and semanti8cs. 2.0 submissions expected to address this. The document for UML 2.0 has been completely rewritten, so this issues is no longer applicable.


Issue 3682: Notation for inherited associations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
The CWM submitters needed to display inherited associations on some class
diagrams to enhance understandability.  These were not intended to be
derived associations; that is, there was no intention to specify additional
computational machinery when showing these inherited associations.
Unfortunately, the MOF and UML have no succint way to display inherited
associations.  The CWM submitters placed the "/" derived prefix on the
association end names in the class diagrams.  At the same time, in order to
prevent the generation of additional computational machinery, they omitted
the inherited association from the normative XMI rendition of the metamodel.
This was probably a reasonable choice under the circumstances.  However, it
means that the class diagrams and the XMI representation of the metamodel
conflict with one another.

It is very common to need to show inherited associations on a class diagram.
We ran into this when we specified the CORBA metamodel for the CORBA
Component Model submission.  We used derived associations in the class
diagrams as well.   However, we retained the derived associations in the XMI
rendition of the metamodel.  In order to prevent additional computational
machinery from being generated, we stereotyped the associations as
<<implicit>>.  This stereotype is defined in the UML specification but not
in the MOF specification and says that an association is only conceptual and
not manifest.  We then made sure that the generator producing the IDL and
XML DTDs was sensitive to the <<implicit>> stereotype.  This had the
advantage of maintaining consistency between the class diagrams and the XMI
rendition of the metamodel.  Of course this is also a non-standard
approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
generators to understand it.

The lack of a standard means for representing inherited associations in
class diagrams is thus resulting in a proliferation of non-standard
approaches in adopted OMG metamodels.  This could become unmanageable as the
number of metamodels grows.  A standard means should be specified.

Resolution:
Revised Text:
Actions taken:
July 3, 2000: received issue
August 30, 2000: transferred to UML RTF
March 9, 2005: closed issue

Discussion:
In UML 2.0 it is possible to draw a standard generalization arrow between two
associations. Additional adornments can be included to specify the kind of
specialization that has taken place (see pg. 83 of the FAS).


Issue 3735: MOF rules should disallow certain composition relationships (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
MOF rules should disallow composition relationships in instance metamodels
where the container is in one MOF Package and the contained item is in
another MOF Package and a dependency of the first package on the second is
not allowed by the physical version of the metamodel due to MOF-imposed IDL
generation rules.

Reason for the issue: 

In the process of implementing an XMI-based interchange for UML 1.3, I have
encountered a serious problem.

This problem has to do with a divergence between the "Logical" and
"Physical" model for UML 1.3 caused by rules imposed by MOF.

In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
version), "Preconditions for IDL Generation", requires that there be no
cyclical dependencies between ModelElements in a meta-model.

However, the UML 1.3 specification (June 1999) has a cyclical dependency
between the Core and the Extension Mechanisms packages in the metamodel (See
Figure 2-4).  This cyclical dependency is explicitly disallowed by the
precondition cited above.

This circular dependency was removed from the "Physical Model" for UML 1.3
in order to allow CORBA IDL and XMI DTD declarations in conformance with the
precondition.  As a result of the removal of this dependency, there are
tremendous difficulties expressing the composition relationship between the
UML ModelElement and the UML Tagged Value (see figure 2-10).  In fact, the
TaggedValue XML elements cannot even be in the exported UML Package element
-- they must be placed outside of it.  This greatly complicates the export
and import of UML 1.3 model files.

Resolution:
Revised Text: This is a UML 1.3-only issue and was resolved at UML 1.4.
Actions taken:
June 30, 2000: received issue
March 9, 2005: closed issue

Discussion:
Better UML/MOF alignment is explicit goal of the UML 2.0 RFP.


Issue 3783: Interface of an object (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Uncategorized Issue
Severity:
Summary:
This is a request for an interpretation of UML 1.3.

The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

--------  Background  -------

Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

The UML submission said:

"... An interface is only a collection of operations with a name; it cannot be directly instantiated.  Instantiable classifiers, such as class or use case, ..."

"UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."


UML 1.3 says:

"2.5.4 Semantics

"Interface

"... An interface is only a collection of operations with a name.  It cannot be directly instantiated.  Instantiable classifiers, such as class or use case, ..."


In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association.  Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject.  SubsystemInstance has been proposed for UML 1.4.  There is not any model element that is a subtype of Instance and corresponds to Interface.  (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

[It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

--------

I am hoping this is easy to interpret and can be resolved quickly.

Resolution: see below
Revised Text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not instantiable. Instead, an interface may be implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers. (see “Implementation (from Interfaces)”).
Actions taken:
August 15, 2000: received issue
March 8, 2005: closed issue

Discussion:
The answer is to the question at the beginning of the issue descripion is that there is no such model element, as objects in the UML do not have interfaces. Instead, interfaces are realized by classifiers which implies that the instances specified by that classifier will provide the services described by the interface.                 The issue originally asked for an interpretation of UML 1.3. Our answer will
make no claim regarding UML 1.3. Our resolution will settle the issue in UML 2
by providing a clarified text on the subject.
The UML 2 metamodel is clear in showing 1. Behaviored Classifiers are optionally related to Interfaces as the
implementing classifier, where the implementation relationship is a
specialization of realization.
2. Classes and Objects do not “have” Interfaces.
Six ambiguous, misleading, and inappropriate usages on this topic remain in the
UML 2 specification text, as identified in email discussion. Our resolution of this
issue proposes some wordsmithing improvement.
Interface is defined in the Classes chapter, Section 7.15 The Description
subsection includes this text:
An interface is a kind of classifier that represents a declaration of a set of coherent public features and
obligations. In a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a
classifier that realizes the interface. The obligations that may be associated with an interface are in the form
of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may
impose ordering restrictions on interactions through the interface.
Since interfaces are declarations, they are not directly instantiable. Instead, an interface specification is
realized by an instance of a classifier, such as a class, which means that it presents a public facade that
conforms to the interface specification. Note that a given classifier may realize more than one interface and
that an interface may be realized by a number of different classifiers.
There are six problems with this.
1. “In a sense is inappropriate language for a spec. We remove it.
2. The scope of the modal “must” is ambiguous in the statement “an interface
specifies a kind of contract which must be fulfilled by any instance of a classifier
that realizes the interface” The author did not mean that the contract must be
fulfilled, but that if a classifier realizes the interface, then all instances of that
classifier must fulfill the contract.
3. The phrase “a kind of” in the above is inappropriate.
A revision that fixes these was agreed after discussion, would read as follows:
An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill
that contract.
4. The term “specification” is redundant in the phrase “an interface specification”.
5. Another inadequacy is “an interface specification is realized by an instance of
a classifier, such as a class…” The problem with this is that an interface is itself
a classifier. The qualifier “instantiable” should be inserted.
6 In the abstract syntax, the relationship of an interface to the insta ntiable
classifier is not realization, but implementation. Which specializes realization.
The most specific applicable characterization is always the right one to use in a
specification. Other examples of this misuse of realization have also been
reported – here we only address those that are local to the Interfaces section of
Chapter 7.   Resolution
Modify the text of the description subsection, for Interface in the Classes chapter
to improve the 3 points discussed above.


Issue 3999: Attributes obsolete in UML 1.3 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
the association between StructuralFeature and Classifier should be
removed. Attributes can not describe more information than
Associations/AssociationEnds can. Therefore it is obsolete and confuses
the user of UML, which to choose when modeling.

On page 3-40 in the UML 1.3 specification it says: "Note that an
attribute is semantically equivalent to a composition association;
however, the intent and usage is normally different." 

If the semantics are equivalent, then it is impossible to distinguish
between them. There is no extra layer of meaning above the semantics
layer that can distinguish between two things with equal semantics.
Semantics is meaning. I think this sentence is contradictory. I have not
been able to find out what the difference in "intent and usage" is. If
this is defined, it will obviously make the semantics of the two
different.

To improve the readability of class diagrams when everything is
associations, I propose that associations should be possible to
represent as text in the compartment where attributes are written today.

Resolution: see above
Revised Text:
Actions taken:
October 25, 2000: received issue
March 9, 2005: closed issue

Discussion:
The modeling of attributes and association ends has been unified in UML 2.0, so
that this issue is no longer applicable.


Issue 4083: Conflicting constraint between ActivityGraph and StateMachine. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Revision
Severity: Minor
Summary:
Since an ActivityGraph is derived from a StateMachine its
constraints must be consistent with that of a StateMachine. If an
ActivityGraph has a Package as its context it violates the constraint
inherited from StateMachine.

ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
(self.context.oclIsTypeOf(Package) xor
self.context.oclIsKindOf(Classifier) xor
self.context.oclIsKindOf(BehavioralFeature))

StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
self.context.oclIsKindOf(BehavioralFeature) or
self.context.oclIsKindOf(Classifier)

One way to avoid this problem is to change the StateMachine constraint to be
applicable when self is  oclIsTypeOf(StateMachine) so the constraint is not
applied to it children. 

A general mechanism to disable inherited constraints could also solve the
problem.


Resolution:
Revised Text: The metamodel for activities is no longer dependent on the metamodel of state machines in UML 2.0, so this issue is no longer relevant.
Actions taken:
November 29, 2000: received issue
March 9, 2005: closed issue

Discussion:
This is an AWG problem: it does not seem meaningful for a Package, an M1 entity with no M0 manifestation, to have behavior. Identified UML 2.0 RFP issue: SM and AG will be based on separate metamodels


Issue 4123: Clarify the origin of an Action in a Collaboration. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Actions seem to be owned by the Message in the following paragraph.

Section 2.10 page 2-130. "In the metamodel a Message defines one specific
kind of communication in an Interaction. A
communication can be e.g. raising a Signal, invoking an Operation, creating
or destroying an
Instance. The Message specifies not only the kind of communication, but also
the roles of the
sender and the receiver, the dispatching Action, and the role played by the
communication
Link. Furthermore, the Message defines the relative sequencing of Messages
within the
Interaction."

Is the Action a reference to a Action in the Sender, as the meta-model
suggests, or is it owned by the Message as the above suggests?

Please clarify.

Resolution:
Revised Text: The metamodel for Interactions has completely changed in UML 2.0, so this issue is no longer relevant.
Actions taken:
December 18, 2000: received issue
March 9, 2005: closed issue

Discussion:
Clarify, although the action is not owned by the message in the same way as the sender and the receiver roles are not owned by the message.


Issue 4218: Appendix A, UML Standard Elements (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

Resolution:
Revised Text:
Actions taken:
March 8, 2001: received issue
March 9, 2005: closed issue

Discussion:
This text has been completely changed in UML 2.0, so this issue is no longer
applicable.


Issue 4219: Profile Notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
I raised this issue at the AB level.  I didn't recommend holding up approval
of UML 1.4 over this but we agreed that the new RTF would take this matter
up with dispatch.

Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
issue.  I can speak to this as a practical matter based on the profiling
work I've done.  When I define a Stereotype on a UML metamodel element, as
in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
of the UML metamodel element.  I don't want to have to define it again
before defining the relationship between my new Stereotype and that UML
metamodel element.  Thus, requiring the <<metaclass>> Stereotype on the UML
metamodel element means that, in the UML metamodel itself, I would have to
Stereotype all the metaclasses this way so that, if I need to, I can reuse
them in VMMs.  True, I could opt *not to* display the <<metaclass>>
Stereotype in a pure UML metamodel diagram and opt *to* display it a VMM
diagram, but all the UML metamodel elements would be carrying the
<<metaclass>> Stereotype.

The best solution I can think of to this problem is to to drop the
requirement to use the <<metaclass>> Stereotype in VMM diagrams.  As long as
the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
is adhered to, it should be pretty clear in a VMM diagram what is a
Stereotype and what is a UML metamodel element.  Also, the the standard
metamodel Stereotype of Package indicates that the elements in the
Package are elements of a metamodel.

I am open to other suggestions as to how to resolve this issue.

Resolution: resolved, close issue
Revised Text:
Actions taken:
March 9, 2001: received issue
March 8, 2005: closed issue

Discussion:
Uml 2.0 RFP issue. 1 Introduce a discussion for the usage of the <<metaclass>> stereotype. <<Metaclass>>
is of an optional usage for modeling stereotypes. Therefore, modeler can directly base
their extension definition on a MOF based reference metamodel.
This mention does already exist (see “Class” in the profile spec ) :
The spec says :
“Presentation Option
A Class that is extended by a Stereotype may have the optional keyword «metaclass»
shown above or before its name.”
The error here is that “metaclass” is a stereotype (not a keyword). It must be changed to:
“A Class that is extended by a Stereotype may be extended by the optional stereotype
«metaclass» (see appendix B : standard stereotypes, basic) shown above or before its
name.”
Disposition: Resolved


Issue 4263: Events, signals, stimuli, etc. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, nobody)
Nature: Clarification
Severity:
Summary:
Here is my understanding of communication between instances on an
example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
An instance i1 performs a SendAction, according to the spec: "A send
action is an action that results in the (asynchronous) sending of a
signal". Then, the signal is delivered to say instance i2, and as a
consequence of the receipt, a SignalEvent is generated (according to the
spec, "A signal event represents the RECEPTION of a particular
(asynchronous) signal")
Now the problems:
1) the spec goes on further to say about the signal event that "A signal
event
instance should not be confused with the action (e.g., send action) that
generated it". The problem I have with my above understanding is that
the send action should not be the one generating the send event but
rather the reception of the signal should be the one generating it.
2)According to the spec: "A signal is a specification of an asynchronous
stimulus communicated between instances" where a stimulus is more
general "In the metamodel Stimulus is a communication, i.e. a Signal
sent to an Instance, or an invocation of an Operation". Thus, I conclude
that the things sent between instances are stimuli.
However, I'm a little confused of the relationship between events and
stimuli with the following sentence taken from the spec "Event instances
are generated as a result of some action either within the system or in
the environment surrounding the system. An event is then conveyed to one
or more targets. The means by which event instances are transported to
their destination depend on the type of action, the target,..."
Furthermore, how are stimuli and signals related in the metamodel?

Resolution:
Revised Text: This issue refers to the event model of UML 1.x. UML 2.0 has largely revised this model and the issue is no longer applicable. A further reformulation of the event model is forthcoming in the resolution to issue 4456.
Actions taken:
April 10, 2001: received issue
March 9, 2005: closed issue

Discussion:
This is a complex area that is expected to be rationalized by the 2.0 submissions.


Issue 4292: Add Multiplicity to Parameter. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Enhancement
Severity: Significant
Summary:
Adding multiplicity to Parameter would enable modeling of arrays,
collections, sequences etc. I would like to model BehavioralFeatures that
can return an array and take an array as an argument.
The notation would simply add the [multiplicity] after the Parameter type.
The initial value syntax would be { initial-value, initial-value..}

Resolution:
Revised Text: Resolved in UML 2.0, where Parameter is a kind of MultiplicityElement.
Actions taken:
May 1, 2001: received issue
May 17, 2001: moved to the UML RTF
March 9, 2005: closed issue

Discussion:
The document reference is wrong. Te referenced document does not have a
section 3.26.1, and the entire document has only 26 pages. As a matter
of fact it is Core Chapter 9, so it has sections numbers of the form
9.??????

This issue is not a core issue. It seems like it might have something to
do with UML. Please ask the submitter for clarification, and remove from
the Core list.


Issue 4298: Issue: Conflicting WFRs on Transition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML 1.4 Specification, Section 2.12.3, p. 2-165

Description:
WFR 5 for the class Transition states that "Transitions outgoing
pseudostates may not have a trigger" and the OCL supports this absolute
statement. However, WFR 6 is intended to allow transitions out of initial
states, which are a kind of pseudostate, to have "a trigger with the
stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
legal.

Recommendation:
Change WFR 5 as follows.

[5] Transitions outgoing pseudostates other than initial states may not have
a trigger.

self.source.oclIsKindOf(Pseudostate) implies
    self.source.oclAsType(Pseudostate).kind<>#initial implies
        (self.trigger->isEmpty())

Resolution: see below
Revised Text: following text: [5] Only junctions, joins, and initial pseudostates can have triggers (source.oclIsKindOf(Pseudostate) and (source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()
Actions taken:
May 10, 2001: received issue
March 8, 2005: closed issue

Discussion:
Modify the WF rule [5] so that it reads:Transitions outgoing from pseudostates other than initial states may not have a strigger.  self.source.oclIsKindOf(Pseudostate) and self.source.kind <> #initial implies (self.trigger->isEmpty()).     the body of this function should read: result = if ancestor (s1, s2) then s2 else if ancestor (s2, s1) then s1 else (LCA(s1.container, s2.container))      context StateVertex: (self.container.size = 0) implies ((self.oclIsKindOf(State) and (self.stateMachine.size = 1))


Issue 4446: Ambiguous semantics of classifier ownerscope (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
The semantics of classifier ownerscope is ambiguous for structural
     features declared on classifiers that have children. It is not
     defined whether this gives value for the classifier and all its
     descendents, or values for the classifier and each descendant
     separately.

Resolution: see above
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
Ownerscope is no longer in UML 2.0 so the issue does not apply.


Issue 4447: Ambiguous semantics of classifier targetscope (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The semantics of classifier targetscope is ambiguous for
     associations with participating classifiers that have children.  It
     is not defined whether this specifies links for the classifier and
     all its descendants, or links for the classifier and each
     descendant separately.


Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
Targetscope is no longer in UML 2.0 so the issue does not apply.


Issue 4449: The definition of Multiplicity in Datatypes does not list the range associa (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity: Minor
Summary:
The definition of Multiplicity in Datatypes does not list the range association

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
The model is different at UML 2.0 and MultiplicityElement is fully documented.


Issue 4452: Predefined datatypes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The various datatypes that are the result of expressions are not
     defined in UML.  For example, there is no subtype of Datatype
     called Boolean. This means users will all define their own Boolean,
     Integer, etc., breaking interchangeability.

     The datatypes defined in the Datatypes packages are not model
     elements, so theoretically cannot be used in M1 models.  However,
     the interchange model for UML includes these types, making them
     available for user models.  If this is the case, it should be made
     clear in the UML spec.  The overview of the Datatypes package
     (section 2.7.1) says it contains types used in defining UML, so
     they formally belong to the MOF.

Resolution:
Revised Text: UML 2.0 now defines Boolean etc - in the PrimitiveTypes package.
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
The meta architecture of UML will be re-defined for UML 2.0 when UML and MOF will be properly aligned (RFP requirement). In this new context, this issue should beaddressed.


Issue 4455: The text and OCL of rule #5 for Method do not say the same thing. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The text and OCL of rule #5 for Method do not say the same thing.

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
The concept of Method no longer exists as a metaclass in UML 2.0, so this issue
is no longer applicable.


Issue 4456: Event => Event Specification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
The event metaclass would better called "event specification".  Or
     at least the runtime event should be called "occurences" rather
     than instances.

Resolution: This issue is resolved by the resolution to issue 6682.
Revised Text:
Actions taken:
August 3, 2001: received issue
March 8, 2005: closed issue

Issue 4457: Exceptions do not correspond to common usage (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
 Exceptions in UML are signals, but the normal usage of the term is
     for non-local flow of control that is trapped in procdural code.
     No signal is normally sent with exceptions.

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
Closed, no change
The Exception metaclass no longer exists in UML 2.


Issue 4464: Component notation: logical compartments (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity: Minor
Summary:
The current component notation does not provide for separate
logical compartments when nesting implementation classes and artifacts in a
component, as shown in Notation, Figure 3-95. It would be useful to provide
separate logical compartments for this, as we do for subsystems and classes.

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
Subsystems and components have been harmonized in UML 2.0 (with logical
compartments removed from both due to scalability issues), so this issue is no
longer applicable.


Issue 4465: Component notation: showing delegation of messages (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity: Minor
Summary:
The current notation does not provide for showing how method calls
or messages to a component interface are delegated (or propagated) to the
interfaces in components or implementation classes that reside in the
component. This is sometimes referred to as the "wiring problem."

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
March 9, 2005: closed issue

Discussion:
The introduction of delegation connectors in the UML 2.0 metamodel for
structured classes allows explicit modeling of delegation for components.


Issue 4504: Optimize Instance data values (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity: Significant
Summary:
Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations. 

There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances. 

Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode. 

NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost). 


Resolution: see above
Revised Text:
Actions taken:
August 16, 2001: received issue
March 9, 2005: closed issue

Discussion:
Instances are expected to be revised for UML 2.0 as a result of aligning UML and MOF
UML 2.0 has quite a different Instances metamodel and AttributeLink is not used: instead
there is Slot which links to ValueSpecification. Unlike UML 1.x this has a proper
mechanism for representing the data value (not just DataValue.name which the issue was
complaining about): indded DataValues do not have the overhead of a name at all.
UML 2.0 also avoid the problem of Packages having to own DataValues directly – since
in 2.0 the ValueSpecifications are contained by the Slot. And the problem of the
redundant link from DataValue to Classifier.
Finally the suggestion of having the data value as a string on AttributeLink (Slot at 2.0) is
no longer appropriate due to the more sophisticated modeling possibilities through
ValueSpecification.


Issue 4617: XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The cited sections refer to the property "isPolymorphic" for operations of a class (2.5.4.3), operations in an interface (2.5.4.6), and receptions (2.9.2.17). Issue 1165 indicates that "Operation:isPolymorphic" was renamed to "Operation:isLeaf" in UML 1.3. The XML attribute "isPolymorphic" does not exist in either the UML 1.3 or UML 1.4 XMI DTD. The cited sections should be changed to accurately describe the means by which polymorphism is indicated.

Resolution:
Revised Text:
Actions taken:
October 11, 2001: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 has no mention of ‘isPolymorphic’.


Issue 4619: Using or implementing an interface of a Subsystem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem. 

Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen. 

Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications. 

Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility. 

Resolution:
Revised Text:
Actions taken:
October 15, 2001: received issue
March 9, 2005: closed issue

Discussion:
The new structural modeling capabilities of structured classifiers (which include
components and subsystems as specializations), such as delegation connectors,
address this issue more effectively.


Issue 4626: Using OCL at the meta-model level (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Colorado State Univ, Dept of Computer Science (Dr. Robert France, france(at)cs.colostate.edu)
Nature: Uncategorized Issue
Severity:
Summary:
A. page 2-55; 2.5.3.6 Binding 
constraint [1]

self.client.oclIsKindOf(self.supplier)

Using my current understanding of OCL this seems wrong for the following
reason:
1. self.client returns an element at the M1 level (a UML model construct)
2. the oclIsKindOf predicate compares the type of self.client
(I assume the type of self.client is a metaclass at the M2 level) with the 
argument (which I assume from the definition of the predicate
is a type and is thus an M2 element).
3. self.supplier is not an M2 element.

B. page 2-61 constraint [5] (similar comments as above)

Am I misinterpreting self, OclIsKindOf, ...?

Resolution:
Revised Text:
Actions taken:
October 17, 2001: received issue
March 9, 2005: closed issue

Discussion:
These constraints have been removed in UML 2.0, so this issue is no longer
applicable.


Issue 4645: Nameclash in UML 1.4 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Technology, Sydney (Brian Henderson-Sellers, brian.henderson-sellers(at)uts.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:
As far as I can see there is a name clash in UML 1.4.
<<implementation>> is used as both 
(1) a stereotype of Generalization to mean implementation (or private)
inheritance 
and
(2) a stereotype of Class to mean the coding or implementation details of
a Class

Resolution: see above
Revised Text:
Actions taken:
October 27, 2001: received issue
March 9, 2005: closed issue

Discussion:
No change.
The issue is valid with respect to UML 1.4, but does not require any change in the UML
2 specification.
In UML 2, the stereotype of a Class in sense (2) of the issue summary has become
<<Implementation Class>>.
In UML 2 there is a model element Implementation to handle sense (1) of the issue. In
UML 1.4 there was no such model element. See the Interfaces package of the Kernel,
Section 7.15 and Figure 58.
The UML 2 Implementation model element is a subtype of Realization, which itself is a
dependency relationship, and as such cannot clash with any use of <<implementation>>
as a stereotype. There remains a stylistic problem in that the word "implementation" is
used to define the semantics of Realization, and then the model element Implementation
is introduced as a specialization of Realization. Defining the semantics of Realization by
means of the concept of implementation does raise some doubts about the need for
specializing Realization as Implementation, but the name clash cited in this issue no
longer exists in the UML 2 metamodel.


Issue 4662: Compliance to the UML" pp xxxi -- Editorial? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I was just reading the intro to UML 1.4, and may have found a typo. In the
"Compliance to the UML" pp xxxi, it shows a table of package dependencies
and states that complying with a package requires compliance with it's
dependent packages.

Core is shown as dependent on Data Types and Extension Mechanisms, and
Extension Mechanisms is shown as dependent on Data Types and Core, leading
to a circular relationship.

Resolution: see above
Revised Text:
Actions taken:
October 21, 2001: received issue
March 9, 2005: closed issue

Discussion:
This structure of packages was changed in UML 2.0, so that these package s and
dependencies no longer exist.


Issue 4726: TaggedValue in TaggedValue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 metamodel, a ModelElement can contain any number of
taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
it can itself contain taggedValues.

The question is: is this really intended? And if so: please explain the
semantics of such a construction.

If not, at simple well-formedness rule 

	self.taggedValue = { }

attached to TaggedValue would do the trick.

Resolution: see above, resolved
Revised Text:
Actions taken:
December 5, 2001: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
Stereotypes can extend any class of a metamodel. Stereotypes or tagged values
(attributes) can thus be extended themselves by stereotypes. As an example, stereotypes
and tagged values could be marked to express the author of the stereotype. By the Author
(Name, Date).
Add explanations to the current semantics text for Stereotypes :
(current text)
A stereotype is a limited kind of metaclass that cannot be used by itself, but must always
be used in conjunction with one of the metaclasses it extends. Each stereotype may
extend one or more classes through extensions as part of a profile.
Similarly, a class may be extended by one or more stereotypes. An instance of a
stereotype is linked to an instance of an extended metaclass (or stereotype) by virtue of
the extension between their types.
(Add)
Any metaclass from the reference metamodel can be extended with stereotypes. This
includes, in the case of the UML, metaclasses such as “Class”, “State”, “Activity”,
“Transition” but also metaclasses from the profile package such as “Profile” or
“Stereotype”.


Issue 4727: UML 1.4: Action containment error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Because Action is a ModelElement, it may be contained as an ownedElement
[UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
Node or Collaboration (all other concrete subclasses of Namespace restrict
their owned elements to exclude Action).

Because Actions are only used in the context of either a StateMachine or a
CollaborationInstanceSet, this containment does not seem to make sense.

In order to exclude these containments, the wellformedness rules for Action
could include the following statement:

self.namespace = null

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
This has changed since UML 1.x. Actions are owned by Activity or StructuredNode.


Issue 4728: UML 1.4: Action problem in Collaborations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
n UML 1.4, an Action is only used in the context of a StateMachine or a
CollaborationInstanceSet.

In a CollaborationInstanceSet, an Action is required as the cause of a
Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
a Namespace (or in the context of a StateMachine, which is irrelevant here),
it cannot be contained in the Stimulus, nor in the Instances the Stimulus
connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
are part of. The "nearest" possible container is the Package that happens to
contain the CollaborationInstanceSet.

Intuitively, this makes no sense - used in this context, the Action is
clearly part of the InteractionInstanceSet, or the participating Instances
or Stimuli.

If this error report is rejected, please elaborate on the intended
containment structures for Collaboration instances.

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
Collaboration modeling in UML 2.0 is completely different in UML 2.0 (there are
no CollaborationInstanceSets), so this issue is no longer applicable.


Issue 4729: UML 1.4: State containment problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 metamodel, a State can either be contained as a
"subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
concrete subclasses of Namespace restrict their owned elements to exclude
State). The latter containment does not seem to make a lot of sense.

Fortunately, the description of a StateMachine states that "This means that
a state machine owns its transitions and its top state. All remaining states
are transitively owned through the state containment hierarchy rooted in the
top state." [UML 1.4, pp. 2-153].

The question is: does this mean that a State is restricted to being
contained in a CompositeState or a StateMachine? If not, please explain the
meaning of e.g. a State contained directly in an otherwise empty Package?

If the mentioned restriction *is* intended, it should be stated
unambiguously so in the wellformedness rules for State:

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
The state machine metamodel has been changed radically in UML 2.0 (e.g.,
CompositeState no longer exists as a separate metaclass), so this issue is no
longer applicable.


Issue 4730: UML 1.4: ExtensionPoint containment problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
Artifact, Node or ClassifierRole (other containers excluded because of
restrictions they make on the "ownedElement" containment in their
wellformedness rules).

The questions are: what is the intended meaning of an ExtensionPoint in eg.
an otherwise empty Package? Why isn't the ExtensionPoint contained in the
UseCase it extends, as would appear more logical to the uninitiated?

Suggestion: change the association between ExtensionPoint and UseCase [UML
1.4, pp. 2-135] to an unconditional composite containment (with
ExtensionPoint as the part).

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
The use case model has changed in UML 2.0, mainly due to changes in the supporting
abstract classes. In the new metamodel (see figure 401 in the final adopted spec),
ExtensionPoints are indeed contained in the corresponding use case, as was suggested in
the issue text. Hence, no change to the final adopted spec is required for this issue.


Issue 4731: UML 1.4: Transition containment problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
contained either as an "internalTransition" in a State, as a "transition" in
a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
Package, Artifact, Node or ClassifierRole (other containers excluded because
of restrictions they make on the "ownedElement" containment in their
wellformedness rules). The latter containment does not seem to make a lot of
sense.

The question is: is the containment of a Transition as an "ownedElement"
intended? If so, please explain the meaning of e.g. a Transition contained
directly in an otherwise empty Package.

If not, it should be stated unambiguously so in the wellformedness rules for
Transition, e.g.:

	self.namespace = null

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
This issue is resolved in UML2.0. All the containment structure is explicit, transitions are
owned explicitly by regions. Therefore the containment issue mentioned above is no
longer relevant.
Disposition: Closed, no change


Issue 4732: UML 1.4: Feature containment problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
contained either as an "feature" in a Classifier, or as an "ownedElement"
[UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
(other containers excluded because of restrictions they make on the
"ownedElement" containment in their wellformedness rules). In addition an
Attribute (subclass of Feature) may be contained as a "qualifier" in an
AssociationEnd [UML 1.4, pp. 2-14].

The question is: is the containment as an "ownedElement" intended? If so,
please explain the meaning of e.g. an Operation contained directly in an
otherwise empty Package.

If not, it should be stated unambiguously so in the wellformedness rules for
Feature:

	self.namespace = null

Remarks:
========
It should be noted that the standard does make a number of partly
contradictory statements which seem to indicate that Features can not be
used as ownedElements:

Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
Classifier."
Page 2-36: "A feature [...] is encapsulated within a Classifier."
[contradicts with the statement below].
Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
case it is a feature) or an AssociationEnd (in which case it is a qualifier)
but not both."
Page 2-42: "Method is a declaration of a named piece of behavior in a
Classifier"
Page 2-45: "Operation is a BehavioralFeature that can be applied to the
Instances of the Classifier that contains the Operation.".

These statements could however be made unambiguous by adding the mentioned
wellformedness rule.


Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 separates feature membership from feature ownership, and uses association
redefinition to avoid issues of ambiguity over whether an inherited ‘ownership’
association should be used.
Disposition: Closed, no change


Issue 4733: UML 1.4: Stimulus containment (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 standard, a Stimulus is a ModelElement representing
a communication between two instances [UML 1.4, pp. 2-106]. It is used
exclusively in the context of collaborations, as part of an
InteractionInstanceSet [UML 1.4, pp. 2-120].

Because Stimulus is a direct subclass of ModelElement - and because no other
composite containments are specified for Stimulus - it must be compositely
contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
or Node (all other concrete subclasses of Namespace have restricted their
owned elements to exclude Stimulus).

Having the Stimulus be part of any of these classes makes no sense, as it is
intuitively part of the InteractionInstanceSet.

Proposed remedy: change the association between InteractionInstanceSet and
Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
containment (with Stimulus as the part).

Alternatively, please clarify the intended semantics of each of the
currently allowed containments listed above

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
The metaclass Stimulus has been deleted.
Disposition: Closed, no change


Issue 4734: UML 1.4: Event containment problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 standard, an Event is defined as "...a
specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
is used exclusively in the context of state machines, as triggers of state
transitions [UML 1.4, pp. 2-147, fig. 2-24].

Because Event is a direct subclass of ModelElement - and because no other
composite containments are specified for Event or any of its subclasses - it
must be compositely contained as an ownedElement in a ClassifierRole, Model.
Package, Artifact or Node (all other concrete subclasses of Namespace have
restricted their owned elements to exclude Event).

The question is: is this containment intended, or should an Event be
contained in e.g. the StateMachine in which it is used? If the currently
allowed containment IS intended, please explain the semantics of e.g. an
Event contained in an otherwise empty Package (or even Model).

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
The Event metaclass is no longer defined in UML 2.0.
Disposition: Closed, no change


Issue 4735: UML 1.4: Node, Artifact, Package and Model contents problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
According to the UML 1.4 standard, the abstract metaclass Namespace
compositely contains any type of ModelElement, but does however state that
subclasses may restrict this containment [UML 1.4, pp. 2-45].

The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
however.

This means that Node, Artifact, Package and Model can compositely contain
the following concrete metaclasses as ownedElements:

  Method   
  Attribute   
  Operation   
  Reception   

  State   
  ActionState   
  ObjectFlowState   
  Transition   
  CallState   
  Pseudostate   
  SimpleState   
  SubactivityState   
  SynchState   
  CompositeState   
  SubmachineState   
  SubState   
  FinalState   

  CallAction   
  TerminateAction   
  CreateAction   
  DestroyAction   
  SendAction   
  ActionSequence   
  UninterpretedAction   
  ReturnAction   

  ExtensionPoint   
  Stimulus   
  Parameter   

  Permission   
  UseCase   
  ProgrammingLanguageDataType   
  StateMachine   
  Comment   
  LinkObject   
  Enumeration   
  Association   
  Dependency   
  ClassifierInState   
  SignalEvent     
  Constraint   
  NodeInstance   
  Usage   
  Signal   
  Actor   
  Interface   
  Component   
  Link   
  Primitive   
  Collaboration   
  SubsystemInstance   
  ChangeEvent   
  Generalization   
  Stereotype   
  Subsystem   
  TagDefinition   
  Abstraction   
  Extend   
  ActivityGraph   
  Flow   
  UseCaseInstance   
  DataType   
  Object   
  Class   
  TimeEvent   
  ComponentInstance   
  Exception   
  Include   
  CollaborationInstanceSet   
  AssociationClass   
  CallEvent   
  Binding   
  Package   
  Node   
  Artifact   
  Model   
  DataValue   
  TaggedValue

The question is: are all these ownedElement types intended for all the
mentioned containers? Especially the first 28 in the list appear out of
place.

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, Node and Artifact no longer subtype NameSpace but instead subtype Class
and Classifier respectively.
The general problem of NameSpace containment has been tightened in UML 2.0 for
Packages and Models by means of PackageableElements: only those meta classes that
subtype PackageableElement can be contained in a package (eliminating things like e.g.
SimpleState to be contained in a Package on its own).
Disposition: Closed, no change.


Issue 4736: UML 1.4: ClassifierRole contents problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
"...specifies a restricted view of a [base] classifier.." and defines "...a
set of Features, which is a subset of those available in the base
classifier, as well as a subset of ModelElements contained in the base
classifier...".

The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
"feature" association inherited from Classifier must be empty - instead the
ClassifierRole must select features from the base classifier using the
"availableFeature" association [UML 1.4, pp. 2-121].

The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
2-121] indicating "the subset of ModelElements contained in the base
Classifier, which is used in the Collaboration". There is however *no*
restriction in the wellformedness rules restricting the ownedElements
contents of the ClassifierRole itself, meaning that a ClassifierRole can
contain the following meta-elements:

  Method   
  Attribute   
  Operation   
  Reception   
  State   
  ActionState   
  ObjectFlowState   
  Transition   
  CallState   
  Pseudostate   
  SimpleState   
  SubactivityState   
  SynchState   
  CompositeState   
  SubmachineState   
  SubState   
  FinalState   
  CallAction   
  TerminateAction   
  CreateAction   
  DestroyAction   
  SendAction   
  ActionSequence   
  UninterpretedAction   
  ReturnAction   
  ExtensionPoint   
  Stimulus   
  Parameter   
  Permission   
  UseCase   
  ProgrammingLanguageDataType   
  StateMachine   
  Comment   
  LinkObject   
  Enumeration   
  Association   
  Dependency   
  ClassifierInState   
  SignalEvent     
  Constraint   
  NodeInstance   
  Usage   
  Signal   
  Actor   
  Interface   
  Component   
  Link   
  Primitive   
  Collaboration   
  SubsystemInstance   
  ChangeEvent   
  Generalization   
  Stereotype   
  Subsystem   
  TagDefinition   
  Abstraction   
  Extend   
  ActivityGraph   
  Flow   
  UseCaseInstance   
  DataType   
  Object   
  Class   
  TimeEvent   
  ComponentInstance   
  Exception   
  Include   
  CollaborationInstanceSet   
  AssociationClass   
  CallEvent   
  Binding   
  Package   
  Node   
  Artifact   
  Model   
  DataValue   
  TaggedValue

So the question is: is this lack of restriction intentional? And if so, why
are ownedElements handled differently from features? And what is the
semantic difference between entities selected using the "availableContents"
association and those contained directly?

Resolution:
Revised Text:
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue

Discussion:
The modeling of collaborations has changed substantially in UML 2.0. In particular,
classifier roles are now represented as parts of the internal structure of a collaboration.
Their “contents” is specified by their type, which is an ordinary classifier, and all
restrictions are inherited from classifier. The instance playing the role must possess the
properties specified by the classifier typing the role. Disposition: Closed, no change


Issue 4738: UML 1.4: AttributeLink containment error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
fig.2-17].

The former containment obviously prevents the latter from ever being
realized.

Note: If changing the former containment from mandatory to optional, please
remember to exclude AttributeLink from other composite containments
implicitly enabled by such a change - such as being an ownedElement of a
Namespace, or a parameter of a template.

Resolution:
Revised Text:
Actions taken:
December 6, 2001: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 does not have AttributeLink so the issue no longer applies.
Disposition: Closed, no change


Issue 4739: UML 1.4: Wrong target for StateMachine.top association (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
A StateMachine compositely contains a State through the "top" association
[UML 1.4, pp. 2-147, fig. 2-24].

However, the wellformedness rules for StateMachine state that "A top state
is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
2-158].

If that is the case, the top association should target a CompositeState, not
the more general State.

Note: of course this is not an error as such, but if a wellformedness rule
can be expressed just as easily in UML, there is no reason to complicate
matters

Resolution:
Revised Text:
Actions taken:
December 6, 2001: received issue
March 9, 2005: closed issue

Discussion:
The metamodel for state machines has completely changed in this area in UML
2.0, so this issue is no longer relevant.
Disposition: Closed, no change


Issue 4740: Adding events to the class definition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:
The proposal is to add an optional fourth compartment to the 
class artifact that lists events that are accepted by that 
class.

If a class is 'Active', it will have an associated 
state/activity model. This state/activity model will respond to 
events sent to that class. At the moment the only way to 
determine what events can be accepted by a class is to observe 
its state/activity model. Very clumsy!

A workaround is to list events in the operations compartment 
and label them with an appropriate stereotype <<event>> for 
example. This should only be a temporary solution, since events 
are no more operations than they are attributes.

Events need to be part of the class definition.

Resolution:
Revised Text:
Actions taken:
December 7, 2001: received issue
March 9, 2005: closed issue

Discussion:
The UML provides a mechanism to specify that a class will respond to the receipt of an
operation call (Operation) or a signal (Reception). These are explicitly listed in the
appropriate compartment. In addition to these, a class may respond to events such as
change events and time events, but these are not part of the external interface of the class
and are, therefore, not shown in a compartment.
Disposition: Closed, no change


Issue 4746: Composite relationship between Event and StateMachine (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
As previously mentioned in issues 3558 (Who owns an Event?) and
4734 (Event containment problem). 
Based upon issue 3558 response I believe that an Event should be owned by a
StateMachine. 
A composite relationship should be added between Event and StateMachine in
the UML Meta-Model.

Resolution:
Revised Text:
Actions taken:
December 12, 2001: received issue
March 9, 2005: closed issue

Discussion:
This issue was addressed by the resolution to issue 6206, which proposed that an Event
(i.e., Trigger) is owned by a BehavioredClassifier.
Disposition: Closed, no change


Issue 4800: Definitions in glossary don't conform to any standard for definitions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:
The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS. 

For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words. 

Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right. 

People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it. 

Resolution:
Revised Text:
Actions taken:
January 2, 2002: received issue
March 9, 2005: closed issue

Discussion:
This appears to be a discretionary issue and not very concrete or precise. For
example, it does not say which elements of the glossary are problematic. There
is, therefore, no reasonable way of resolving this issue. Furthermore, the
glossary has changed significantly for UML 2.0 and the issue may no longer be
applicable.
Disposition: Closed, no change


Issue 4810: Invalid XMI.link.atts in UML 1.4 DTD (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
XMI.link.att declaration as follows:

<!-- _______________________________________________________________ -->
<!--                                                                 -->
<!-- XMI.link.att defines the attributes that each XML element that  -->
<!-- corresponds to a metamodel class must have to enable it to      -->
<!-- function as a simple XLink as well as refer to model            -->
<!-- constructs within the same XMI file.                            -->
<!-- _______________________________________________________________ -->

<!ENTITY % XMI.link.att
               'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
                CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
                xlink:actuate (show|user) #IMPLIED xlink:content-role
                CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
                (embed|replace|new) #IMPLIED xlink:behavior CDATA
                #IMPLIED'>

The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
these (p4-81 of formal/00-11-02).

The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
(this appendix was removed at XMI 1.2 since it was wrong and misleading).

Many of the above link attributes seem actually to be invalid:
 - xml:link is invalid since this is not part of the xml namespace
 - xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
namespace
 - xlink:actuate has invalid values - the standard values are
(onLoad|onRequest|other|none)
 - xlink:show is missing values - the full set is
(new|replace|embed|other|none) [I guess it is not so much of a problem to
exclude certain values]


Resolution:
Revised Text:
Actions taken:
January 21, 2002: received issue
March 9, 2005: closed issue

Discussion:
MOF 2.0 XMI does not have linkatts so the issue does not apply.
Disposition: Closed, no change


Issue 4816: Suggest that alternate syntax used in section 6.5.5 be adopted thoughout (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification. 

This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away. 

Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

Resolution:
Revised Text:
Actions taken:
January 29, 2002: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0 association ends are modeled as features of classifiers, which means that
they can use the standard qualified name syntax. In the UML spec, two forms are used:
<classifier-name>’.’<assoc-end-name>
or
<classifier-name>’::’<assoc-end-name>
This is more than enough and the re is no reason to add yet another form. In fact, only the
latter form should be used.
Disposition: Closed, no change


Issue 4848: Namespace.contents (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The current definition of the operation Namespace.contents is:

The operation "contents" results in a Set containing all ModelElements
contained by the Namespace.
	contents : Set(ModelElement)
	contents = self.ownedElement -> union(self.namespace, contents)

(UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

The last line of this definition seems wrong, since the "union" operation
must have a single parameter.


The former definition of this operation did not present any contradiction
between text and OCL expression:

The operation "contents" results in a Set containing all ModelElements
contained by the Namespace.
	contents : Set(ModelElement)
	contents = self.ownedElement

(UML Semantics, version 1.1 page 32)

Resolution:
Revised Text:
Actions taken:
February 26, 2002: received issue
March 9, 2005: closed issue

Discussion:
MOF 2.0 XMI does not have Namespace.contents so the issue does not apply. The
nearest equivalent Namespace.allOwnedElements() does use OCL ‘union’ operation with
a single parameter.
Disposition: Closed, no change


Issue 4917: match/correspond clarfication (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Sridhar Iyengar, siyengar(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
[Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes.  The
specification text does not clearly explain how 'match' and 'correspond'
- dependencies are to be used. See figure 2-57, page 2-307 are used in
the spec.  Are these intended to be illustrative? Are they constraints
on the values passing thru input and output pins.  What is the
difference between 'match' and 'correspond'?

Resolution:
Revised Text: [Action Semantics FTF]: Replace correspond and match dependencies with constraints, and write well formedness rules. See Dataflow rule #1 for OCL example. [UML 2 Super FTF]: These no longer exist in UML 2. Disposition: Closed, no change
Actions taken:
March 5, 2002: received issue
October 22, 2002: Deferred
March 21, 2004: received issue
December 28, 2004: resolved by the UML 2 Superstructure FTF
March 9, 2005: closed issue
March 9, 2005: closed issue

Discussion:
Replace correspond and match dependencies with constraints, and write
well formedness rules.  See Dataflow rule #1 for OCL example.


Issue 4927: Simplify inputs/outputs of procedures (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
[Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
they point at inputs/outputs of contained actions.  Groups referred
input pins together that receive the value from the same parameter.

Resolution:
Revised Text:
Actions taken:
March 5, 2002: received issue
December 28, 2004: resolved by the UML 2 Superstructure FTF
March 9, 2005: closed issue

Discussion:
Resolved in UML 2 by ActivityParameterNode.
Disposition: Closed, no change


Issue 4936: StartStateMachine clarification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
[Conrad Bock] Does StartStateMachine cause the intial state to be
entered and its outgoing transition taken?  Ie, what is the semantics in
relation to the RTC step.

Resolution:
Revised Text: [Action Semantics FTF]: The 1.4 is contradictory is a couple places: - State machine can't rest in pseudostate, but transition wf 5 says transitions from initial states may not have trigger event. - and wf 6 says it may have a call event stereotyped as «create». Defer the above to UML RTF. Reword StartObjectStateMachine semantics to say it starts the executions of the object's state machines. Discussion for UML 2.0: ??The resolution to issue 4298 has removed wf 5, so the contradiction noted above is no longer an impediment ??The action StartObjectStateMachine has been generalized to StartOwnedBehaviorAction. The semantics of starting state machines are fully described in section 15.3.11 on page 499 (the case of Composite state). Disposition: Closed, no change
Actions taken:
March 5, 2002: received issue
October 22, 2002: Deferred
December 28, 2004: resolved by the UML 2.0 Superstructure FTF
March 9, 2005: closed issue

Discussion:
The 1.4 is contradictory is a couple places:

  - State machine can't rest in pseudostate, but transition wf 5 says
    transitions from initial states may not have trigger event.

  - and wf 6 says it may have a call event stereotyped as «create».

Defer the above to UML RTF.

Reword StartObjectStateMachine semantics to say it starts the executions
of the object's state machines.



Issue 4940: Add action for invoking an activity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Add action for invoking an activity

Resolution:
Revised Text:
Actions taken:
March 5, 2002: received issue
October 22, 2002: Deferred
December 28, 2004: resolved by the UML 2.0 Superstructure FTF
March 9, 2005: closed issue

Discussion:
[Action Semantics FTF]: Activities will probably be a kind of behavior in UML 2, so the
action for invoking behaviors will work on activities then.
[UML 2 Super FTF]:
Resolved in UML 2 by CallBehaviorAction.
Disposition: Closed, no change


Issue 4946: UML 1.4.1 should use MOF 1.4 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the case of MOF 1.4 there are far more important reasons for moving to
it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
opposed to CORBA datatypes hidden away in typeCodes. Because of this:
 a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
Java APIs to metamodels and is being adopted by a number of repository and
UML tool vendors. Without an official version of UML expressed in MOF 1.4
people will have to do their own conversion with subsequent interoperability
problems

 b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
Without being expressed in MOF 1.4, the UML interchange definition cannot be
expressed as an XML Schema.

 c) the proper datatype model provides the opportunity to 'clean up' a
number of datatype-related issues in UML (e.g. issue 4452). And represent
UML's datatypes such as Multiplicity and MultiplicityRange as MOF
(structure) datatypes rather than MOF classes.

I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
be willing to draft a proposal for this. Is there a version of this with
already-agreed 1.4.1 changes incorporated?

Resolution:
Revised Text:
Actions taken:
March 7, 2002: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 is now aligned with MOF 2 so this issue does not apply.
Disposition: Closed, no change


Issue 5005: A_context_raisedSignal (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The
association in question is not named in the UML 1.4 interchange model.  The
name "A_context_raisedSignal", is an artificial one that was created by the
program that created the DTD.  It was using an algorithm recommended by the
MOF RTF for naming unnamed associations.  However, it would seem to be wise
policy for this association to have a name.  This would remove any
dependency on the vagaries of various MOF tools.

Resolution:
Revised Text:
Actions taken:
March 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
The XMI for UML 2.0 is different from 1.x and fully automatically generated, so
this issue is no longer applicable.
Disposition: Closed, no change


Issue 5267: Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
oclIsKindOf, which should only take a single argument.

Resolution:
Revised Text:
Actions taken:
May 7, 2002: received issue
March 9, 2005: closed issue

Discussion:
These constraints have been removed in UML 2.0, so this issue is no longer
applicable.
Disposition: Closed, no change


Issue 5268: Well-formedness rules for 2.12.3.8 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
incorrect use of oclIsKindOf, which only takes one argument.

Resolution:
Revised Text:
Actions taken:
May 7, 2002: received issue
March 9, 2005: closed issue

Discussion:
This rule has been removed in UML 2.0 as this part of the metamodel has
changed, so the issue is no longer applicable.
Disposition: Closed, no change


Issue 5269: UML 1.4 - Partition relates to nothing (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML 1.4 has no association for showing what a Partition relates to.
Typically this would be something representing a role in a process.

Resolution:
Revised Text:
Actions taken:
May 7, 2002: received issue
March 9, 2005: closed issue

Discussion:
Partition related to Element in UML 1.x and still does in UML 2.
Disposition: Closed, no change


Issue 5273: Initial state for composite states - OCL example and missing constraint (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This issue was triggered by what seemed to be an ill-formed state machine
example which revealed a deeper lack of rigor in the spec.


The example state machine in section 6.5.10 (illustrating oclInState) does
not have an initial pseudostate within the 'Off' state. Section 3.80.2
indicates that this is mandatory:
"A transition drawn to a composite state boundary indicates a transition to
the
composite state. This is equivalent to a transition to the initial
pseudostate within the
composite state region. The initial pseudostate must be present."


[Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
object.oclInState(Off:NoPower) should have a double colon:
object.oclInState(Off::NoPower)].


If indeed it is mandatory to have an initial state where there is a
transition to a composite state (this does seem sensible for
predictability), this should be reflected in a constraint within the
abstract Syntax (section 2.12) to the effect that a CompositeState with
'incoming' Transitions must contain an initial PseudoState.


For example 2.12.4.3 contains the following which implies an initial
pseudostate, though uses the ill-defined 'default transition' as well as
'initial transition':
"Entering a non-concurrent composite state
Upon entering a composite state, the following cases are differentiated:
• Default entry: Graphically, this is indicated by an incoming transition
that
terminates on the outside edge of the composite state. In this case, the
default
transition is taken. If there is a guard on the transition it must be
enabled (true). (A
disabled initial transition is an ill-defined execution state and its
handling is not
defined.) The entry action of the state is executed before the action
associated with
the initial transition."


Proposed Resolution
-------------------


1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
composite with a transition to 'Standby'.


2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
should have a double colon:  object.oclInState(Off::NoPower)


3. Add the following constraint to section 2.12.3.1
 [7] A composite state with an incoming transition must have an initial
state.
   self.incoming->notEmpty() implies
     self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
Pseudostate | p.kind = #initial)->size = 1


4. Alter the section in 2.12.4.3 to read as follows:
"Entering a non-concurrent composite state
Upon entering a composite state, the following cases are differentiated:
• Default entry: Graphically, this is indicated by an incoming transition
that
terminates on the outside edge of the composite state. In this case, there
must be an initial state and the initial
transition is taken. If there is a guard on the transition it must be
enabled (true). (A
disabled initial transition is an ill-defined execution state and its
handling is not
defined.) The entry action of the state is executed before the action
associated with
the initial transition."

Resolution: see above, resolved
Revised Text:
Actions taken:
May 9, 2002: received issue
March 8, 2005: closed issue

Discussion:
 It is not always necessary for a composite state to have an initial pseudostate – this is
implied in several places in the spec (e.g., pg. 470 and 478). However, what has not been
clarified well in the spec is what happens when a transition terminates on the border of a
composite state that does not have an initial pseudostate. So, the following changes need
to be made:
?? On page 478, 5th paragraph (not counting titles), after the following sentence:
Each region of a composite state may have an initial pseudostate and a final state. A transition to the
enclosing state represents a transition to the initial pseudostate in each region.
Add the following subsection: Semantic variation point (default entry rule)
If a transition terminates on an enclosing state and the enclosed regions do not have an initial
pseudostate, the interpretation of this situation is a semantic variation point. In some
interpretations, this is considered an ill-formed model. That is, in those cases, the initial
pseudostate is mandatory.
An alternative interpretation allows this situation and it means that, when such a transition is taken,
the state machine stays in the composite state without entering any of the regions or their
substates.
?? On page 481, replace the phrase:
the current active “state” is actually represented by a set of trees of states starting with the top-most
states of the root regions down to individual simple states at the leaves.
With the following phrase:
the current active “state” is actually represented by a set of trees of states starting with the top-most
states of the root regions down to innermost active state. ?? On page 481, replace the following sentence:
In this case the default transition is taken.
with the following sentence:
In this case the default entry rule is applied (see “Semantic variation point (default entry)” on page
478)


Issue 5525: UML Issue - Inconsistency between UML 1.3 XMI and DTD (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Clarification
Severity: Minor
Summary:
The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
exist in the UML metamodel XMI file. This causes problems for my product
which is metamodel-driven so reports an error when an import attempts to
supply a value for the non-existent reference. This is strictly speaking a
bug in the DTD (since it's not generated according to the XMI rules):
however changing the DTD might cause inconvenience for vendors who are
making use of it, and because not having the reference would make processing
the tags much harder.


At UML 1.4 the reference has been added to the metamodel, which suggests
that the metamodel rather than the DTD be fixed. However this could require
a restructuring to avoid circular package dependencies [see UML issue 3735].


The same issue applies to the 'stereotype' reference on ModelElement - again
it should ideally be added to the metamodel.


The reason I'm raising the issue on UML 1.3 is that this is the chosen
version for interoperability work. A decision is needed as to which way to
resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
1.4.

Resolution:
Revised Text:
Actions taken:
July 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
The metamodel and XMI for UML 2.0 are different so this issue is no longer
applicable.
Disposition: Closed, no change


Issue 5655: How does one indicate the target object for a CallState (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Texas Department of Human Services (Mr. Srinivas Nedunuri, )
Nature: Uncategorized Issue
Severity:
Summary:
 How does one indicate the target object for a CallState (i.e. the actual
object that executes the stated action/method)? If the target action takes
no parameters then it may be possible to say that the target object is just
the object flowing into the CallState. But what if it does take parameters?
(e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
more than one object to be flowing into the CallState and leads to an
ambiguity about which constitutes the target and which the parameter.


P.S. The actual object may be passed around by the activity diagram, so it
is not possible to show it statically on a swimlane (even if that is the
recommended way)

Resolution:
Revised Text:
Actions taken:
September 27, 2002: received issue
March 9, 2005: closed issue

Discussion:
Resolved in UML 2 by CallOperationAction
Disposition: Closed, no change


Issue 5656: Section 2.13.4.3 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Texas Department of Human Services (Mr. Srinivas Nedunuri, )
Nature: Uncategorized Issue
Severity:
Summary:
2) Section 2.13.4.3 says


         "Unless there is an explicit "fork" that creates orthogonal obect
states only one of an object flow state's outgoing transitions will fire as
determined by the guards of the transitions", 


which seems to require that if you want to "feed" the object to multiple
actions, you will need a "fork" bar. But then 3.90.2.2 says:


        "The same object may be (and usually is) the output of one action
and the input of one or more subsequent actions". 


This would seem to suggest that a "fork" bar is not required. Please
clarify.


Resolution:
Revised Text:
Actions taken:
September 27, 2002: received issue
March 9, 2005: closed issue

Discussion:
The text referred to no longer exists in UML 2
Disposition: Closed, no change


Issue 5657: In v1.4, section 3.84.1 the paragraph on semantics (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Texas Department of Human Services (Mr. Srinivas Nedunuri, )
Nature: Uncategorized Issue
Severity:
Summary:
"An Activity Diagram is a special case of a state machine in which the
states represent performance of actions or subactivitities and the
transitions are triggered by the completion of actions or subactivities. It
represents the state machine of a procedure itself."


But in Section 2.13.1 it says:


"An activity graph is a special case of a state machine that is used to
model processes involving one or more classifiers. Its primary focus is on
the sequence and conditions for the actions that are taken, rather than on
which classifiers perform those actions. Most of the states in such a graph
are action states that represent atomic actions; that is, states that invoke
actions and then wait for their completion. Transitions into action states
are triggered by events, which can be
* the completion of a previous action state (completion events),
* the availability of an object in a certain state,
* the occurrence of a signal, or
* the satisfaction of some condition.
"


The latter statement implies that (a) events other than completion of prev
activity can be triggers and (b) entire processes, not just procedures can
be modeled in ADs. 


Which one is it?

Resolution:
Revised Text:
Actions taken:
September 27, 2002: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, activities are no longer a specialization of state machines, so this
issue is no longer applicable.
Disposition: Closed, no change


Issue 5658: parameters of object flow states (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Texas Department of Human Services (Mr. Srinivas Nedunuri, )
Nature: Uncategorized Issue
Severity:
Summary:
 parameters of object flow states -- The Notation section of the UML 1.4
Spec does not discuss it, nor is an example provided. I am still in the dark
about how parameters are supposed to be used in the context of object flow
states. Are output parameters supposed to be like reference parameters in
the Algol style languages?

Resolution:
Revised Text:
Actions taken:
September 27, 2002: received issue
March 9, 2005: closed issue

Discussion:
UML 1.x object flow states have been replaced in UML 2 by pins, which specify how
parameters get their runtime values. The UML 1.x object flow state notation is supported
by pins.
Disposition: Closed, no change


Issue 5659: Section 3.90.2.2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Texas Department of Human Services (Mr. Srinivas Nedunuri, )
Nature: Clarification
Severity:
Summary:
Section 3.90.2.2 says 


"In other words when a state prodices an outpout that is input to the
subsequent state, that object flow relationship implies a control
constraint." 


I take it that this is not the same as isSynch being true? That is isSynch
means that an object in an object flow is rather like a token in a Petri
net. ie once it flows out to the consuming state, its gone from its place.
Is that correct?

Resolution:
Revised Text:
Actions taken:
September 27, 2002: received issue
March 9, 2005: closed issue

Discussion:
Object flow states and isSynch no longer exist in UML 2
Disposition: Closed, no change


Issue 5685: Section number duplicated (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Alcatel-Lucent (Dr. Julien Maisonneuve, Ph.D., julien.maisonneuve(at)alcatel-lucent.com)
Nature: Uncategorized Issue
Severity:
Summary:
Probably an Action Semantics RTF Issue, but one that may be addressed
in an UML RTF.


In the UML 1.5 spec in the action semantics chapter, sections numbers
2.16 and 2.17 are duplicated. The section content appears all right
but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.


The document simply needs consistent renumbering of that chapter.

Resolution:
Revised Text:
Actions taken:
October 14, 2002: received issue
March 9, 2005: closed issue

Discussion:
New document produced for UML 2.0, so this issue is no longer applicable.
Disposition: Closed, no change


Issue 5730: Swap rule 2 and rule 3 of the Binding element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Swap rule 2 and rule 3 of the Binding element. It improves readability

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
The modeling of templates has completely changed in UML 2.0, so this issue is
no longer relevant.
Disposition: Closed, no change


Issue 5731: Rule 6 of the Method element isn't formulated well (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
In UML 2.0, Method is modeled differently than in 1.x, so this issue is no longer
applicable.
Disposition: Closed, no change


Issue 5732: There is an unnecessary condition in rule 1 of the Namespace element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 does not have special cases for Generalization and
Associations; more generally isDistinguishableFrom() is used to enforce
uniqueness.
Disposition: Closed, no change


Issue 5734: Add rule to Namespace element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
At UML 2.0 this is expressed in constraint [1] of section 9.14.1
related to Element.ownedElement from which Namespace inherits.
Disposition: Closed, no change


Issue 5735: there is something wrong with rule 3 of the Trace element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:
 think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
No change
This issue is no longer relevant.
There is no rule 3 of the Trace element. Indeed, there is no longer any Trace element.
There is no "model" additional operation of the ModelElement (indeed, there is no
metaclass ModelElement, it has replaced altogether).
In UML 2, there is a predefined <<trace>> stereotype as a notation to signify a subtype of
Abstraction.
Disposition: Closed, no change


Issue 5736: Wrong alphabetical order: DataValue section should be before DestroyAction (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Wrong alphabetical order: DataValue section should be before DestroyAction section.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
New document for UML 2.0, so this issue is no longer applicable.
Disposition: Closed, no change


Issue 5737: There are misprints with numeration of rules of the Instance element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There are misprints with numeration of rules of the Instance element

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 was rewritten from scratch and does not have this particular
mis-numbering issue
Disposition: Closed, no change


Issue 5738: There is a misprint in rule 2 of the Object element: “Stimuli” instead of “ (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
The concept of stimulus has been removed in UML 2.0 and with it any associated rules.
Disposition: Closed, no change


Issue 5739: There is a misprint in rule 1 of the SubsystemInstance element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
SubsystemInstance is no longer a concept supported in UML 2.0, so this issue is
no longer applicable.
Disposition: Closed, no change


Issue 5740: font sizes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
“self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size. 

Resolution:
Revised Text:
Actions taken:
October 31, 2002: received issue
March 9, 2005: closed issue

Discussion:
This text has been removed in UML 2.0, so the issue is no longer applicable.
Disposition: Closed, no change


Issue 5744: spelling of the word Use Case (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:
I have a question about the spelling of the word Use Case. The different
>spellings used everywhere are a little bit irritating to me (but this may
>not be the case for other people). I think that it should be one fixed
>spelling of the word defined i UML. But even in the UML specification I
>found three different spellings on the same side: Use Case, use case and
>UseCase. In a book I'm reading they use the following spelling: Use Case
>and, when used with other words, Use-Case (Realization for example).

Resolution: see above, resolved
Revised Text:
Actions taken:
October 25, 2002: received issue
March 8, 2005: closed issue

Discussion:
The spelling used in the spec depends on the context and which specific thing is being
addressed. Thus, the form “UseCase” is used when referring to the metaclass in the
metamodel. The form “use case”, with no capitalization and separate words, is used to
discuss the concept. The form “Use Case” is incorrect and should not be used in the
document except where normal capitalization rules dictate it (e.g., in titles).
Hence, the following changes need to be made to support the latter rule (the changes in
text are indicated by underlining):
?? Pg. 136 last sentence should read:
This may include e.g. UseCases and Dependencies (e.g. mappings), Packages,
Components, and Artifacts.
?? Pg. 517:
Extension points are indicated by a text string within in the use case oval symbol
or use case rectangle according to the syntax below
?? Pg. 525 table entry:
UseCase
?? Pg. 526 figure caption:
Use case diagram with a rectangle representing the boundary of the subject.
?? Pg. 532:
[1] The sources and targets of the information flow can only be of the following
kind : Actor, Node, UseCase, Artifact, Class, Component, Port, Property,
Interface, Package, and InstanceSpecification except when its classifier is a
relationship (i.e. it represents a link).
?? Pg. 552: By virtue of Classifier being defined here, all subclasses of Classifier (such as
Class, Collaboration, Component, Datatype, Interface, Signal and UseCase) can
be parameterized, bound and used as template parameters.


Issue 5745: Inconsistency regarding guards on forks (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards. 
The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines? 

Resolution:
Revised Text:
Actions taken:
November 1, 2002: received issue
March 9, 2005: closed issue

Discussion:
Since activities are no longer a specialization of state machines in UML 2.0, this
issue is no longer relevant.
Disposition: Closed, no change


Issue 5763: The first sentence is not consistent with figure 2-9 on page 2-17 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1..*" and not "*".

Resolution:
Revised Text:
Actions taken:
November 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
PresentationElement, one of the participants in the problematic
association, is not in UML 2.0 so the issue no longer applies.
Disposition: Closed, no change


Issue 5795: Designates a Generalization (02) (uml2-superstructure-ftf)

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

Designates a Generalization whose child GeneralizableElement is the immediate descendant of the current GeneralizableElement. 

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

Resolution:
Revised Text:
Actions taken:
December 15, 2002: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 was rewritten from scratch and does not have this particular
inconsistency: the text always refers to multiple superclasses.
Disposition: Closed, no change


Issue 5796: Section: 2.5.2.10 Classifier (uml2-superstructure-ftf)

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

specifiedEnd Indicates an AssociationEnd 

does not agree with the cardinality * on the association end specifiedEnd between Classifier and AssociationEnd in Figure 2-6 Core Package - Relationships on page 70.

Resolution:
Revised Text:
Actions taken:
December 16, 2002: received issue
March 9, 2005: closed issue

Discussion:
At UML 2.0 the metamodel in this area is not the same and the text has
been rewritten so the issue does not apply.
Disposition: Closed, no change


Issue 5797: 2.5.2 Abstract Syntax (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The binary association between ModelElement and Flow is undocumented both in the ModelElement and Flow documentation.

Resolution:
Revised Text:
Actions taken:
December 16, 2002: received issue
March 9, 2005: closed issue

Discussion:
Flow no longer exists as a separate concept in UML 2.0.
Disposition: Closed, no change


Issue 5798: 2.5.2.16 Element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
Element cannot have tagged values. There is no tagged values attribute or association for class Element. Should the taggedValue feature be moved from ModelElement to Element?

Resolution:
Revised Text:
Actions taken:
December 16, 2002: received issue
March 9, 2005: closed issue

Discussion:
The modeling of Profiles is completely changed in UML 2.0, so this issue is no
longer relevant.
Disposition: Closed, no change


Issue 5799: 2.5.2.27 ModelElement (uml2-superstructure-ftf)

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

implementationLocation The component that an implemented model element resides in. 

disagrees with the * cardinality of the implementationLocation association end of the ModelElement - Component association in Figure 2-8 Core Package - Classifiers on page 2-16.

Resolution:
Revised Text:
Actions taken:
December 16, 2002: received issue
March 9, 2005: closed issue

Discussion:
The issue refers to a draft version of the specification. In the FAS specification, this area
has been remodeled and the association end “implementationLocation” no longer exists.
This is now modeled through Manifestation, which has consistent cardinalities.
Disposition: Closed, no change


Issue 5800: 2.5.2.10 Classifier (uml2-superstructure-ftf)

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

"specifiedEnd Indicates an AssociationEnd..." 

disagrees with the cardinality * on the association end labeled specifiedEnd of the association between Classifier and AssociationEnd. (Figure 2-6 on page 2-14)

Resolution:
Revised Text:
Actions taken:
December 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
At UML 2.0 the metamodel in this area is not the same and the text has
been rewritten so the issue does not apply.
Disposition: Closed, no change


Issue 5801: 2.5.2 Abstract Syntax (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The association end named typedParameter that belongs to the association between Classifier and Parameter is not documented in the Classifier section (2.5.2.10 Classifier on page 2-28).

Resolution:
Revised Text:
Actions taken:
December 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
At UML 2.0 the metamodel in this area is not the same: Parameter now
inherits from TypedElement to get its type; this is not navigable in
the opposite direction so the issue does not apply.
Disposition: Closed, no change


Issue 5802: 2.5.2.15 Dependency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). 

The same issue applies to the supplier association end and its documentation.

Resolution: see above and below - resolved
Revised Text: Associations • client: NamedElement [1..*] The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. • supplier: NamedElement [1..*] The element(s) independent of the client element(s), in the same respect and in the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML 2 may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.
Actions taken:
December 19, 2002: received issue
March 8, 2005: closed issue

Discussion:
In the FAS, the relevant figure was renumbered as 51, and the section from which the
quoted text comes is 7.14.3, page 108 as printed, 122 in pdf electronic form . The full
text in context from page 108(122) is:
Associations
• client: NamedElement [1..*] The element that is affected by the supplier element. In some cases
(such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two
elements.
• supplier: NamedElement [1..*] Designates the element that is unaffected by a change. In a twoway
relationship (such as some Refinement Abstractions) this would be the more general element.
In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not
relevant.
There is indeed a disagreement between the text and the multiplicity. The text for both
client and supplier must be in the plural, since the same dependency may have many
clients and/or many suppliers.
An alternative solution would be to decide that the multiplicity in the diagram is at fault,
and that every Dependency Relationship is binary, with exactly one client and exactly
one supplier, but this does not seem to be the intent of the metamodel, so we propose
changing the nouns to allow a plural form.
This one change is sufficient to address the issue, but examination of the text quoted
above reveals other significant defects.
Another defect in the text is the unexplained switch in terminology between the texts
defining client and the text defining supplier. In one case, the other element is what does
or does not affect, and in the other case it is a “change”, with no indication of what the
change is. Since there is no “change” identified in the context, this second definition is
the defective one.
A third defect is the affront to logic involved in three asseritions that contradict the
premise that directed dependency relationships are being defined. These confused and
inconsistent assertions are: 1) that “… undirected situations” can arise in a directed
dependency relationship, and 2) that “… the choice of client does not matter” in a
relationship In which the client is the role of the element(s) that are affected by the other,
and the supplier(s) are the element(s) that are not affected. There is also confusion of the text in its 3) assertion that directed dependency relationships include “two-way”
relationships.
Assertions such as these, if allowed to stand, may bring the specification into disrepute. It
has been many centuries since the logic of relations differentiated symmetric
relationships. No Directed Dependency is symmetric, and all are transitive, which the
assertion that some are “two-way” appears to contradict. Two way relationships are
symmetric, and directed dependency is most certainly not symmetric. Two one-way
relationships do not automatically make one two-way.
Obviously, a client who is dependent on a supplier in one respect, may also be a supplier
with respect to that other in some other respect, but this does not make a directed
dependency relationship symmetric. In such cases there are two dependency
relationships, based on different semantic criteria, not one “two-way” symmetric
dependency.
The resolution is to rewrite the quoted text (see above, from page 108/122) as shown
below


Issue 5803: 2.5.2 Abstract Syntax (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The association end named container that belongs to the aggregation association between Component and ModelElement (Figure 2-8) is not documented in Section 2.5.2.27 ModelElement. 

2.5.2.27 ModelElement DOES document implementationLocation as "The component that an implemented model element resides in." This association is not on any of the Class Diagrams in Section 2.5.2. 

Should the implementationLocation association be renamed to container in Section 2.5.2.27 ModelElement?

Resolution:
Revised Text:
Actions taken:
December 19, 2002: received issue
March 9, 2005: closed issue

Discussion:
This part of the UML 2.0 metamodel has completely changed, so this issue is no
longer applicable.
Disposition: Closed, no change


Issue 5805: 2.5.2.29 Node (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The text "resident The set of resident elements may differ. Often it is more restrictive on the child." has no corresponding association or attribute in any diagram. 

Resolution:
Revised Text:
Actions taken:
December 20, 2002: received issue
March 9, 2005: closed issue

Discussion:
This text completely rewritten in UML 2.0, so this issue is no longer applicable.
Disposition: Closed, no change


Issue 5922: Feature;ModelElement (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:
Why there are two different Backbone Diagrams in the UML 1.5 Specification. The one on Page 71 shows that a Feature has a visibility and a ModelElement has just a name, nothing more. On Page 596 an Feature has the visibility not anymore, but ModelElement has one, how this should be interpreted, which one is the right visibility

Resolution:
Revised Text:
Actions taken:
April 29, 2003: received issue
March 9, 2005: closed issue

Discussion:
This was a confusion on the part of the individual who raised the issue: the two
representations represent different views of the same element with different
attributes shown in each of the two views. (The visibility on ModelElement is
actually a reference to the visibility that is attached in an ElementImport).
Disposition: Closed, no change


Issue 5924: representation of arrays of values in an action language (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; 

However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? 

Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics.

Resolution: see above - resolved
Revised Text:
Actions taken:
April 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
It is indeed the case that arrays are represented using the feature multiplicity property.
Whether values are sets or not is determined by the setting of the “isUnique” property of
the feature, so that both bags and sets are supported. However, the phrase “set of values”
is not meant to imply set characteristics but was meant to convey the notion of a
collection. For this reason, the phrase “set of values” needs to be replaced by the phrase
“collection of values” in the following places:
Superstructure
?? Page 42 in the Semantics section of MultiplicityElement (4 occurrences)
?? In the second sentence of the second paragraph of Property (section 7.11.4) on page
89
?? In the first sentence of the second paragraph of the Description subsection of
StructuralFeature (7.9.5) on page 75.
Infrastructure
?? Page 73 in the Semantics section of MultiplicityElement (4 occurrences)
?? In the second sentence of the second paragraph of Property (section 11.3.5) on page
123 ?? In the first sentence of the second paragraph of the Description subsection of
StructuralFeature (11.3.11) on page 129.


Issue 5951: UML 2.0 Superstructure: Operation vs. Attribute notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature:
Severity:
Summary:
For reference, my copy here is ad/03-04-01.


I wonder about an inconsistency between the notations for attributes
(section 1.8, page 41, in "Classifier (from Kernel, Dependencies,
PowerTypes)") and operations (section 1.10, page 55, in "Operation
(from Kernel)").


For attributes, the notation is (slightly simplified)


visibility name : type [multiplicity] {property-string}


and for operations, it is


visibility name (parameter-list) : property-string


So in the case of attributes, a colon separates the name from the
type, and the property-string is in curly braces, whereas for
operations, the colon separates the name and signature from the
property-string, which is not in braces.


I think this discrepancy is counter-intuitive, I would expect the
same atoms to be used in both blaces. I realize that the syntax for
operations changed from UML 1.5 because of promoting the "return
value" to a parameter.


My suggestion is to change the notation for operations to


visibility name (parameter-list) {property-string}


i.e. to remove the colon, and to add braces around the property-
string. This would be more consistent with both the attribute
notation and the old UML 1.x notation.

Resolution: see above - resolved
Revised Text:
Actions taken:
June 13, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issuer was using an outdated version of the spec. In fact, in the final adopted spec,
the notation for operations is exactly as specified above. However, there are a number of
issues raised against eliminating the “: <return-type>” capability, which is both familiar
and much used, and is also referred to by many books and supported in many tools. In
fact, there are examples in the spec itself (e.g., pg. 79). Therefore, in conjunction with the
fix to issue 7135, the following notation is proposed for operation:
[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’
[‘:’ [<return-type>] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}’]
where <return-type> is the type of the return result parameter if the operation has one
defined.
Further details of where this text is to be inserted are provided in the resolution to issue
7135.


Issue 5976: UML's use of the word "unique" for multiplicity is ambiguous (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML's use of  the word "unique" for multiplicity is ambiguous.  It means
"distinct", but it could be mistaken to mean "unique across all instances".
For example, if someone says that the employee-number attribute of employee
is unique, it would likely be understood to mean that each employee has an
employee-number that is different from every other employee.  But that's not
what UML defines "unique" to mean.  I recommend that the FTF change
"{unique}" to "{distinct}" or "{set}".

Resolution:
Revised Text:
Actions taken:
June 19, 2003: received issue
March 9, 2005: closed issue

Discussion:
The meaning of “unique” is that a feature that represents a collection has no two elements
that have the same value. Therefore, it can be argued that this is a perfectly suitable term
for the informed user. Naïve readers of UML models may indeed get confused in the way
stated in the issue, but this is true of a large variety of other features of UML at this level
of detail. As the experience with COBOL has shown, it is pretty futile to attempt to
design a computer language that a naïve reader will understand. Furthermore, this
particular capability is one that is intended for very expert users.
I am not convinced that “distinct” is any less ambiguous than “unique” while “set” would
require a mathematical understanding of the term that is equally unlikely in a naïve reader
(“set” is distinguished as the English word with the largest number of different
interpretations).
Disposition: Closed, no change


Issue 5978: notation for shared aggregation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
3.  The notation for shared aggregation appears to be missing from the
association notation section

Resolution: Add text to explain the so-called “white diamond” notation for shared aggregation.
Revised Text: In place of the paragraph quoted above, use the following text: A shared aggregation is shown as a solid line between the associated classes with an open diamond at the aggregate end. The diamond shall be noticeably smaller than the diamond notation for associations. A composite aggregation is shown using the same notation as a shared aggregation, but with a solid, filled diamond at the aggregate end.
Actions taken:
June 19, 2003: received issue
March 8, 2005: closed issue

Discussion:
A careful check shows the notation for shared aggregations is indeed missing from final
adopted spec, a mistake. The relevant part of the text is the Notation subsection under
7.11.2 Association (from Kernel). The last paragraph of that subsection currently reads
as follows:
A composite aggregation is shown using the same notation as a binary association, but with a solid, filled
diamond at the aggregate end.
Another relevant text is concerns AggregationKind.
AggregationKind is an enumeration of the following literal values:
• none Indicates that the property has no aggregation.
• shared Indicates that the property has a shared aggregation.
• composite Indicates that the property is aggregated compositely, i.e., the composite object has
responsibility for the existence and storage of the composed objects (parts).


Issue 5979: The description of DataType is plainly wrong in the specification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The description of DataType is plainly wrong in the specification.  A
data type is a classification of data values.  The identity of a data value
is based on the value itself.  And the identity definitely exists.
Otherwise you would not be able to know when you had two occurrences of the
same value.  If a value has no identity, it would not be possible to
distinguish different values of the same data type.  Someone has confused
the concept of having identity with the concept of having a memory address.
Note also that an instance specification is capable, according to the
specification, of identifying a data value, so it is a contradiction to say
a data value has no identity.  Perhaps the specification is using the word
"identity" in a way that is completely different from anything in my
dictionary.  The key point to make is that a data value is not to be
confused with a data variable or a slot in an object that can hold a data
value.

Resolution: see above - resolved
Revised Text:
Actions taken:
June 19, 2003: received issue
March 8, 2005: closed issue

Discussion:
Superstructure Resolution
The following changes need to be made to the Superstructure document:
?? Replace 7.12.1 with:
7.12.1 DataType (from Kernel)
Description
A data type is a type whose instances are identified only by their value. A
DataType may contain attributes to support the modeling of structured data types.
A typical use of data types would be to represent programming language primitive
types or CORBA basic types. For example, integer and string types are often
treated as data types.
Attributes
No additional attributes.
Associations
• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets
Classifier::attribute and Element::ownedMember.
• ownedOperation: Operation[*] The Operations owned by the DataType. Subsets
Classifier::feature and Element::ownedMember. Constraints
No additional constraints.
Semantics
A data type is a special kind of classifier, similar to a class. It differs from a class
in that instances of a data type are identified only by their value.
All copies of an instance of a data type and any instances of that data type with
the same value are considered to be the same instance. Instances of a data type
that has attributes (i.e. is a structured data type) are considered the be the same if
the structure is the same and the values of the corresponding attributes are the
same.
If a data type has attributes, then instances of that data type will contain attribute
values matching the attributes.
Semantic Variation Points
Any restrictions on the capabilities of data types, such as constraining the types of
their attributes, is a semantic variation point.
Notation
A data type is shown using the classifier symbol with keyword «dataType» or,
when it is referenced by e.g. an attribute, shown as a string containing the name of
the data type.
Examples
Figure 41 - Notation of data type: to the left is an icon denoting a data type
and to the right is a reference to a data type which is used in an attribute.
?? Move all the Style Guidelines for DataType including the heading from page 96 and
insert in place of the current heading for StyleGuidelines of Classifier (on top of page
65)
Infrastructure Resolution
The following changes need to be made to the Infrastructure document:
?? Replace entire section 11.5.1 with:
11.5.1 DataType (as specialized)
Description
A data type is a type whose instances are identified only by their value. A
DataType may contain attributes to support the modeling of structured data types. A typical use of data types would be to represent programming language primitive
types or CORBA basic types. For example, integer and string types are often
treated as data types.
Attributes
No additional attributes.
Associations
• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets
Classifier::attribute and Element::ownedMember.
• ownedOperation: Operation[*] The Operations owned by the DataType. Subsets
Classifier::feature and Element::ownedMember.
Constraints
No additional constraints.
Semantics
A data type is a special kind of classifier, similar to a class. It differs from a class
in that instances of a data type are identified only by their value.
All copies of an instance of a data type and any instances of that data type with
the same value are considered to be the same instance. Instances of a data type
that has attributes (i.e. is a structured data type) are considered the be the same if
the structure is the same and the values of the corresponding attributes are the
same.
If a data type has attributes, then instances of that data type will contain attribute
values matching the attributes.
Semantic Variation Points
Any restrictions on the capabilities of data types, such as constraining the types of
their attributes, is a semantic variation point.
Notation
A data type is shown using the classifier symbol with keyword «dataType» or,
when it is referenced by e.g. an attribute, shown as a string containing the name of
the data type.
Examples
Figure 41 - Notation of data type: to the left is an icon denoting a data type
and to the right is a reference to a data type which is used in an attribute. ?? Move all the Style Guidelines for DataType including the heading from the bottom of
page 134 and insert in place of the current heading for StyleGuidelines of “Classifier
(additional properties)” (section 11.3.3) at the bottom of page 121


Issue 5980: Description of GeneralizationSet (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The description of GeneralizationSet uses the words "general" and
"specific" to mean "specific" and "general" respectively.  The description
also uses unclear terms like "maps to classifier" without identifying which
association.  Also, the semantics has: "All of the Generalization links that
share a given general Classifier are divided into disjoint sets (that is,
partitions) using the generalizationSet association."  This statement is
nonsense.  First, the metamodel does not require all generalizations to be
put into partitions using "the generalizationSet association".  Second,
partitions are not required by the metamodel to be disjoint - the same
generalization can be in multiple generalization sets (as should be the
case).

Resolution: see above, resolved
Revised Text:
Actions taken:
June 19, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issue is resolved in the following manner:
1) In the “Semantics” section of 7.8.1 Classifier, change the last sentence under the
Package PowerTypes subheading from:
“The powertypeExtent association relates a Classifier with a set of generalizations
which a) have a common specific Classifier, and b) represent a subclass
partitioning of that class. “
to:
“The powertypeExtent association relates a Classifier with a set of generalizations
which a) have a common specific Classifier, and b) represent a collection of
subsets for that class. “
2) In the “Semantics” section of 7.8.2 Generalization, under the Package
PowerTypes subheading, change the second sentences from:
“Each GeneralizationSet contains a particular set of Generalization relationships
that collectively describe the way in which a specific Classifier (or class) may be
partitioned.“
to:
“Each GeneralizationSet contains a particular set of Generalization relationships
that collectively describe the way in which a specific Classifier (or class) may be
divided into subclasses. “ 3) The caption for Fig. 27 should be changed from:
“Multiple subtype partitions (GeneralizationSets) example.”:
to:
“Multiple collections of subsets (GeneralizationSets) example.“
4) The first sentence and the entire “Description” section of 7.17.3
GeneralizationSet, should be changed from:
“A GeneralizationSet is an AutonomousElement (from Foundation :: Kernel ::
PackagingNamespaces) whose instances define partitioned sets of Generalization
relationships.
Description
Each Generalization is a binary relationship that relates a specific Classifier to a
more general Classifier (i.e., a subclass). Each GeneralizationSet defines a
particular set of Generalization relationships that describe the way in which a
specific Classifier (or superclass) may be partitioned. For example, a
GeneralizationSet could define a partitioning of the class Person into two
subclasses: Male Person and Female Person. Here, the GeneralizationSet would
associate two instances of Generalization. Both instances would have Person as
the specific classifier, however one Generalization would involve Male Person as
the general Classifier and the other would involve Female Person as the general
classifier. In other words, the class Person can here be said to be partitioned into
two subclasses: Male Person and Female Person. Person could also be partitioned
into North American Person, Asian Person, European Person, or something else.
This partitioning would define a different GeneralizationSet that would associate
with three other Generalization relationships. All three would have Person as the
specific Classifier; only the general classifiers would differ: i.e., North
AmericanPerson, Asian Person, and European Person.“
to:
“A GeneralizationSet is a PackageableElement (from Kernel) whose instances
define collections of subsets of Generalization relationships.
Description
Each Generalization is a binary relationship that relates a specific Classifier to a
more general Classifier (i.e., from a class to its superclass). Each
GeneralizationSet defines a particular set of Generalization relationships that
describe the way in which a general Classifier (or superclass) may be divided
using specific subtypes. For example, a GeneralizationSet could define a
partitioning of the class Person into two subclasses: Male Person and Female
Person. Here, the GeneralizationSet would associate two instances of
Generalization. Both instances would have Person as the general classifier,
however one Generalization would involve Male Person as the specific Classifier
and the other would involve Female Person as the specific classifier. In other
words, the class Person can here be said to be partitioned into two subclasses:
Male Person and Female Person. Person could also be divided into North American Person, Asian Person, European Person, or something else. This
collection of subsets would define a different GeneralizationSet that would
associate with three other Generalization relationships. All three would have
Person as the general Classifier; only the general classifiers would differ: i.e.,
North AmericanPerson, Asian Person, and European Person.“
5) In the “Semantics” section of 7.17.3 GeneralizationSet, change the first two
sentences from:
“The generalizationSet association designates the partition to which the
Generalization link belongs. All of the Generalization links that share a given
general Classifier are divided into disjoint sets (that is, partitions) using the
generalizationSet association. Each partition represents an orthogonal dimension
of specialization of the general Classifier.“
to:
“The generalizationSet association designates the collection of subsets to which
the Generalization link belongs. All of the Generalization links that share a given
general Classifier are divided into subsets (e.g., partitions or overlapping subset
groups) using the generalizationSet association. Each collection of subsets
represents an orthogonal dimension of specialization of the general Classifier.“
6) In the “Examples” section of 7.17.3 GeneralizationSet, change the first paragraph
from:
“In the illustration below, the Person class can be specialized as either a Female
Person or a Male Person. Because this partitioning, or GeneralizationSet, is
constrained to be complete and disjoint, each instance of Person must either be a
Female Person or a Male Person; that is, it must be one or the other and not both.
(Therefore, Person is an abstract class because a Person object may not exist
without being either a Female Person or a Male Person.) Furthermore, Person’s
can be specialized as an Employee. The generalization set here is expressed as
{incomplete, disjoint}, which means that instances of Persons can be partitioned
as Employees or some other unnamed collection that consists of all non-
Employee instances. In other words, Persons can either be an Employee or in the
complement of Employee, and not both. Taken together, the diagram indicates
that a Person may be 1) either a Male Person or Female Person, and 2) an
Employee or not. When expressed in this manner, it is possible to partition the
instances of a classifier using a disjunctive normal form (DNF).“
to:
“In the illustration below, the Person class can be specialized as either a Female
Person or a Male Person. Because this GeneralizationSet is partitioned (i.e., is
constrained to be complete and disjoint), each instance of Person must either be a
Female Person or a Male Person; that is, it must be one or the other and not both.
(Therefore, Person is an abstract class because a Person object may not exist
without being either a Female Person or a Male Person.) Furthermore, Person’s
can be specialized as an Employee. The generalization set here is expressed as
{incomplete, disjoint}, which means that instances of Persons can be subset as Employees or some other unnamed collection that consists of all non-Employee
instances. In other words, Persons can either be an Employee or in the
complement of Employee, and not both. Taken together, the diagram indicates
that a Person may be 1) either a Male Person or Female Person, and 2) an
Employee or not. When expressed in this manner, it is possible to subset the
instances of a classifier using a disjunctive normal form (DNF).“
7) The caption for Fig. 72 should be changed from:
“Multiple subtype partitions (generalization sets) and constraint examples.”
to:
“Multiple ways of dividing subtypes (generalization sets) and constraint
examples.“
8) In the “Examples” section of 7.17.3 GeneralizationSet, change the last four
sentences in the fourth paragraph from:
“While Tree may be partitioned in various ways (based on size or age, for
example), in this example it is partitioned on the basis of species. Therefore, the
integrity issue mentioned above is not really an issue here. Deleting the American
Elm subtype from the Tree partition does not require also deleting the
corresponding Tree Species instance, because the American Elm subtype and the
corresponding Tree Species instance are the same object. Figures 23.4 and 23.5
depict another way of thinking about this. .”
to:
“While Tree may be divided into various collections of subsets (based on size or
age, for example), in this example it is divided on the basis of species. Therefore,
the integrity issue mentioned above is not really an issue here. Deleting the
American Elm subtype from the collection of Tree subtypes does not require also
deleting the corresponding Tree Species instance, because the American Elm
subtype and the corresponding Tree Species instance are the same object. Figures
23.4 and 23.5 depict another way of thinking about this. .“
9) In the “Examples” section of 7.17.3 GeneralizationSet, change the last paragraph
from:
“Labeling partitions with the power type becomes increasingly important when a
type has more than one power type. The figure below is one such example.
Without knowing which partition contains Policy Coverage Types and which
Insurance Lines, clarity is compromised. This figure depicts an even more
complex situation. Here, a power type is expressed with multiple partitions. For
instance, a Policy can be subtyped as either a Life, Health, Property/Casualty, or
some other Insurance Line. Furthermore, a Property/Casualty policy can be
further subtyped as Automobile, Equipment, Inland Marine, or some other
Property/Casualty line of insurance. In other words, the subtypes in the partitions
labeled Insurance Line are all instances of the Insurance Line power type.” to:
“Labeling collections of subtypes with the power type becomes increasingly
important when a type has more than one power type. The figure below is one
such example. Without knowing which subtype collection contains Policy
Coverage Types and which Insurance Lines, clarity is compromised. This figure
depicts an even more complex situation. Here, a power type is expressed with
multiple collections of subtypes. For instance, a Policy can be subtyped as either a
Life, Health, Property/Casualty, or some other Insurance Line. Furthermore, a
Property/Casualty policy can be further subtyped as Automobile, Equipment,
Inland Marine, or some other Property/Casualty line of insurance. In other words,
the subtypes in the collection labeled Insurance Line are all instances of the
Insurance Line power type.“


Issue 5982: Well-Formedness Rules for Procedure on Common Behavior Package (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Well-Formedness Rules for Procedure on Common Behavior Package are wrong, document is actually showing same content as Abstract Sintax for Procedure on Common Behavior Package.

Resolution:
Revised Text:
Actions taken:
June 24, 2003: received issue
March 9, 2005: closed issue

Discussion:
The Procedure metaclass has been removed and is replaced by Activity. There are no
well- formedness rules for Activity.
Disposition: Closed, no change


Issue 5992: There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Uncategorized Issue
Severity:
Summary:
There appears to be a typo on page 2-148, in section 2.12.2.13 on StubStates. In this section it states that StubState is a child of State. However, in Figure 2-24 on page 2-141 it shows StubState as derived from StateVertex

Resolution:
Revised Text:
Actions taken:
July 8, 2003: received issue
March 9, 2005: closed issue

Discussion:
Stubstates are no longer exist in UML 2.0, therefore, this issue is obsolete in the UML2.0
context.
Disposition: Closed, no change


Issue 5995: Question on Connectors - fig 2-17 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
On fig 2-17, the left-hand of the diagram shows Order with two interfaces,
OrderableItem and OrderEntry. On the right hand, the assembly connector
lists only OrderableItem. Yet, the text above - 


"When this notation is used to connect "complex" ports that are typed by
multiple provided and/or required inter-faces,
the various interfaces are listed as an ordered set, designated with
{provided} or {required} if needed."


 might be interpreted as indicating that on the Order side of the assembly
connector, the adornment should read "OrderableItem,OrderEntry" (as an
aside, the text above seems to indicate that this list is ordered, but I
don't know what the order should be). There are a number of possible
explanations for the current figure:
*       It's a mistake and both interfaces should be listed;
*       Only interfaces supported by both sides of the connector need to be
listed, (but how about compatible interfaces that are not related by
classification?)
*       The text above does not apply to parts, but that seems unlikely -
they are connectable elements after all and can implement and use multiple
interfaces
*       Something I haven't though of


Can someone please enlighten me?


Resolution: see above, resolved
Revised Text:
Actions taken:
July 11, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issue refers to figure 92 in the FAS. In this figure the label “OrderEntry” should be
added to the unlabeled lollipop on Order.


Issue 6014: OpaqueExpression in CommonBehaviors (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Significant
Summary:
OpaqueExpression in CommonBehaviors is titled "OpaqueExpression (from BasicBehaviors, specialized)". What does "specialized" mean in this context? There is no indication of inheritance from any other definition of OpaqueExpression. 

NOTE: the word "specialized" is used in the title of a number of concepts - in some cases the concepts are derived from other concepts of the same name from other package. This isn't always the case though.

Resolution:
Revised Text:
Actions taken:
July 24, 2003: received issue
March 9, 2005: closed issue

Discussion:
In this context, “specialized” means that the metaclass BasicBehaviors::OpaqueExpression
is specialized from an inherited metaclass OpaqueExpression, in this case, Kernel::
OpaqueExpression. While the text gives no indication from where a metaclass is
specialized, this is done so throughout the document.
Disposition: Closed, no change


Issue 6015: inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There appears to be an inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337. 

In figure 5.1, the IntermediateActions pacakge is dependent on the Communications package. 

In figure 7.122 IntermediateActions depends only on BasicBehaviors. Although Communications is present in the diagram, there is no indication of a dependency.

Resolution:
Revised Text:
Actions taken:
July 24, 2003: received issue
March 9, 2005: closed issue

Discussion:
Can't find the second reference. The inconsistency must have been removed by
the FAS.
Disposition: Closed no change


Issue 6016: CommonBehaviors (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
CommonBehaviors has a package named "Time" that is referenced in numerous parts of the document. 

The class diagram on page 342 is labelled "SimpleTime". it appears that this should be labelled "Time" to be consistent with the package name.

Resolution: see above,. resolved
Revised Text:
Actions taken:
July 24, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change all references to the sub-package “Time” in the CommonBehavior package to
“SimpleTime”.


Issue 6017: CommonBehaviors describes "Operation (from Communications, as specialized) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
CommonBehaviors describes "Operation (from Communications, as specialized)" on page 354. However, the only other reference to "Operation" in the CommonBehaviors section appears on p 339, where the reference is to "Operation (from Kernel)". 

There's something wrong here.

Resolution:
Revised Text:
Actions taken:
July 24, 2003: received issue
March 9, 2005: closed issue

Discussion:
In this context, “specialized” means that the metaclass BasicBehaviors::Operation is
specialized from an inherited metaclass Operation, in this case, Kernel::Operation. While
the text gives no indication from where a metaclass is specialized, this is done so
throughout the document.
Disposition: Closed, no change


Issue 6018: figure 8-137 and 8-139 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In figure 8-137, EventOccurrence inherits from InteractionFragment which inherits from NamedElement. In figure 8-139, EventOccurrence inherits directly from NamedElement. 

The two figures should be consistent with each other (yes, I know that inheritance is transitive, but it does raise unnecessary questions)

Resolution:
Revised Text:
Actions taken:
July 24, 2003: received issue
March 9, 2005: closed issue

Discussion:
These figures correspond to figures 326 and 327 in the final adopted spec.
However, in these later figures, there is no inconsistency, in both diagrams,
EventOccurrence inherits from InteractionFragment and never from
NamedElement. It may be that the Mr. Hickman either referred to an older
internal version of the spec or that he simply misread the figures.
Disposition: Closed, no change


Issue 6019: Missing sections for for enumeration MessageKind or MessageSor (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In Chapter 8, you have a section in 8.3 describing the enumeration InteractionOperator. You do not have similar sections for enumeration MessageKind or MessageSort.

Resolution: duplicate
Revised Text:
Actions taken:
July 24, 2003: received issue
December 2, 2004: closed issue

Discussion:
Complete descriptions for MessageKind and MessageSort is the subject of issue 6077 and
will be solved in the context of that issue’s resolution.


Issue 6020: duration observation" vs DurationObservationAction etc (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
There is some inconsistency in the use of the terms "duration observation" vs. DurationObservationAction and "time observation" vs. TimeObservationAction in the diagrams on the above listed pages. In particular, figure 8-158 states that the visual elements in a Sequence Diagram are "DurationObservation" and "TimeObservation", when in fact they should be "DurationObservationAction" and "DurationObservationAction". The observations only occur when the action is taken - but the representation on the sequence diagram must be the action to be taken, not the effect of it. Compare this to figures on pp 351 & 360.

Resolution: see above, resolved
Revised Text:
Actions taken:
July 25, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
Page 438, Table 14, Column Node Type:
change “Duration Constraint” to “DurationConstraint”.
change “Duration Observation” to “DurationObservation”
change “Time Constraint” to “TimeConstraint”
change “Time Observation” to “TimeObservation”


Issue 6021: labels for ExecutionOccurrence (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The labels for ExecutionOccurrence in the diagrams on p 367 & 368 are both in italics, implying that this is an abstract class. However, the description of EventOccurrence on p. 378 doesn't mention anything about being abstract nor are there any classes derived from it anywhere in the spec.

Resolution: resolved, see above
Revised Text:
Actions taken:
July 27, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the mdl file, the metaclass ExecutionOccurrence should be made concrete.
Consequentially, in Figures 326 and 328, ExecutionOccurrence should be shown in
normal (not italic) font.


Issue 6022: The title of the Property description on page 144 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The title of the Property description on page 144 says: "Property (from InternalStructures, as specialized)". I believe this should say: "Property (from Kernel, as specialized)". 

Here's why: there is as yet no indication of any kind of relationship between Property as defined as part of the Superstructure Kernel and Property as described in InternalStructures. There are some hints that such a relationship exists, but it isn't clear. Either the relationship should be explicitly stated (ir a relationship exists), or it should be explicitly stated that no such relationship exists.

Resolution:
Revised Text:
Actions taken:
July 27, 2003: received issue
March 9, 2005: closed issue

Discussion:
In this context, “specialized” means that the metaclass InternalStructures::Property is
specialized from an inherited metaclass Properety, in this case, Kernel::Property. While
the text gives no indication from where a metaclass is specialized, this is done so
throughout the document. A glance at the mdl file would also reveal the superclass.
Disposition: Closed, no change


Issue 6023: On page 140, the title for Parameter is "Parameter (Collaboration, as speci (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
On page 140, the title for Parameter is "Parameter (Collaboration, as specialized)". This doesn't seem correct. The only prior definition of Parameter is on p 50, which is in the Kernel. The only way to "specialize" something appears to be when you want to add relationships to a concept that has been defined in a different package. I believe the more correct label should be "Parameter (from Kernel, as specialized)". Further, the abstract syntax diagram on page 128 should indicate that Parameter comes from the definition in the the Kernel. This may require deriving a new Parameter metaclass from the Kernel Parameter metaclass just so it can also be derived from ConnectableElement. 

Resolution:
Revised Text:
Actions taken:
July 27, 2003: received issue
March 9, 2005: closed issue

Discussion:
In this context, “specialized” means that the metaclass Collaboration::Parameter is
specialized from an inherited metaclass Parameter, in this case, Kernel::Parameter. While
the text gives no indication from where a metaclass is specialized, this is done so
throughout the document. A glance at the mdl file would also reveal the superclass.
Disposition: Closed, no change


Issue 6049: PackageableElement (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
there was declared and inheritance relationship between NamedElement and
PackageableElement defining in both cases an attribute "visibility". I
suggest to suppress the declaration in PackageableElement because it is
inherited from NamedElement

Resolution:
Revised Text:
Actions taken:
July 31, 2003: received issue
March 9, 2005: closed issue

Discussion:
No revision, the reviewer did not read the spec carefully.
This issue overlooks the difference in multiplicity between visibility for NamedElement
and visibility for Packageable Element. For NamedElement it is optional that there is a
VisibilityKind, and for PackageableElement it is mandatory. Therefore the inheritance is
not redundant, the inherited attribute is redefined by a change in multiplicity.
Examining this reported issue turned up a defect in 7.3.1 ElementImport.
The defect is as follows: Under Attributes, section 7.3.1 lists Visibility, but
fails to specify any multiplicity. The absence of the multiplicity is one defect.
A second defect comes in with the following confused note: “If the imported
element does not have a visibility it is possible to add a visisbility to the
element import.” This is confused in two respects: 1. A value for visibility
is mandatory for PackageableElement, and only PackageableElements can
be imported, therefor the imported element will always have a visibility.
Second, visibility should be mandatory for an ElementImport, and so, if the
imported element were not to have one, it would be necessary, not merely
“possible”, to add one.
Disposition: Closed, no change


Issue 6066: An error in Figure 464 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I found there still is an error in Figure 464 from ptc/03-07-06 to 03/08/02 of UML 2.0 Superstructure Specification, ie. Collaboration Diagram should be replaced with Communication Diagram

Resolution: see above, resolved
Revised Text:
Actions taken:
August 15, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 464, rename the box “Collaboration Diagram” (shown as a subclass of
“Interaction Diagram” to “Communication Diagram”.


Issue 6067: Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
In this section the following statement appears:
 
"An imported element can be further imported by other namespaces using either element or member imports."
 
This is the first and only reference I have found to "member import."  Please provide a definition of member import and include an example if it may be required to complete the understanding of the concept.

Resolution: duplicate
Revised Text:
Actions taken:
August 18, 2003: received issue
December 2, 2004: closed issue

Discussion:
The referenced section 1.3, page 10, of ad/2003-04-01 corresponds to section 7.3.1, page
31, of ptc/03-08-02 (UML2 Superstructure spec) and section 11.6.1, page 140, of ptc/03-
09-15 (UML2 Infrastructure spec). Correspondingly, the issue is a duplicate of a portion
of issue 6168, which see for resolution.


Issue 6068: Obsolete notation used in state machine - transition examples (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
 Section 15.3.14 Transition 

Figures 395 and 396 use lozenge shapes (a rectangle with rounded ends - the notation for an activity in UML 1.4). However, these are state machine examples and this notation is meaningless in this context.


Resolution: see above, resolved
Revised Text:
Actions taken:
August 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The states in figure 395 (idle, busy) and in figure 396 (turn on machine, brew coffee, get
cups, pour coffee) must be changed from the “lozenge” shapes into rounded rectangles.
Example: before (in current text):
After the change it should look as follows:
Disposition: Resolved
idle
idle


Issue 6069: Interface Figure 62 uses wrong notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
Figure 62 uses the wrong notation. The text says that it is using dependcy arrows - they are solid - one of them has a generalization arrow head. Also the interface 'ISensor' rectangle does not include <<interface>> with the name

Resolution: see above, resolved
Revised Text:
Actions taken:
August 21, 2003: received issue
March 8, 2005: closed issue

Discussion:
Indeed Figure 62 did use the wrong notation by failing to have dashed lines and by failing
to stereotype the Isensor as <<interface>>. The text description of the alternative
notation is correct, and the resolution is to change the diagram, and only the diagram, so
that it shows what the text description describes.
In particular, in Figure 62, the arrow from TheftAlarm to Isensor is to be drawn with a
dashed line with open arrowhead, the dependency arrow, and the arrow from
ProximitySensor to Isensor is to be drawn with a dashed line with triangular arrowhead,
which is the iimplements arrow. The stereotype <<interface>> is to be inserted at the
head of the class name compartment of the Isensor no tation.
Correct the grammar of the Figure 62 title by changing "depict" to "depicted".


Issue 6070: Figure 63 missing notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:
Also Figure 63 is missing "<<" from in front of Interface>> IAlarm

Resolution:
Revised Text:
Actions taken:
August 21, 2003: received issue
March 8, 2005: closed issue

Discussion:
Indeed the opening guillemet is missing from the diagram as the Issue states, so the
closing one is unmatched.
Fix by Inserting the opening guillemet for the stereotype notation <<interface>> in the
Ialarm in Figure 63.see above


Issue 6072: Strange notation in Figure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity:
Summary:
The figure showing a use case with an associated state machine behaviour use lozenges (rectangles with rounded ends). This notation is obsolete

Resolution:
Revised Text:
Actions taken:
August 21, 2003: received issue
March 9, 2005: closed issue

Discussion:
This seems to be a reference to figure 405. There is nothing wrong with this figure – the
state use the valid state machine symbol (a lozenge). There has been no change to this
notation in UML 2.0.
Disposition: Closed, no change


Issue 6073: No Glossary in 03-08-02 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
The certification includes the glossary. However, it is missing from 03-08-02, it was there in in 03-07-06.

Resolution:
Revised Text:
Actions taken:
August 21, 2003: received issue
March 9, 2005: closed issue

Discussion:
The glossary is in the document, it has just been moved to the front of the document and
renamed to fit the ISO format (Chapter 4: Terms and definitions). Of course, the glossary
in 03-80-02 needs to be updated, but there is a separate issue for that problem (issue
6447).
Disposition: Closed, no change


Issue 6074: Multiplicities diagram in section 7.4 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The Multiplicities diagram in section 7.4 defines two associations with ValueSpecification, namely upperValue and lowerValue. However, the constraints stated in section 7.4.1 for MultiplicityElement, are defined in terms of upperBound() and lowerBound()

Resolution:
Revised Text:
Actions taken:
August 19, 2003: received issue
March 9, 2005: closed issue

Discussion:
Discussion:
However, the terms upperBound() and lowerBound() represent auxiliary
operations that reference upperValue and lowerValue respectively. These
functions were necessary to deal with the case where these multiplicities may not
be specified explicitly. There is no problem here.
Disposition: Closed, no change


Issue 6075: UML2 super/pg.470/entry and exit points for composite states (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Two OCL constraints for entry and exit pseudostates of state machines (numbered [9] and [10]) only allow these psuedostates to be defined for the topmost regions of a state machine. This restriction is completely unnecessary and precludes common design patterns and should be removed. (In fact, from discussions with the authors of the spec, it seems that they were included due to a misunderstanding between two of the authors.)   

Resolution: see above
Revised Text:
Actions taken:
August 22, 2003: received issue
March 8, 2005: closed issue

Discussion:
The proposed resolution for this is described in the attached PDF file, with the changes
indicated by the vertical change bars in the margin. Note that there are a few spurious
change bars that were automatically generated when the new figure was inserted and the
figure numbers changes – this forced some cross-references to automatically change.
Specifically, the following changes are proposed (NB: the page numbers cited refer to
the FAS document page and indicate where the change is to be made; the page numbers
in parentheses match the page number in the attached PDF file – these were included for
easy reference):
??Fig. 354: add a composition from State to Pseudostate to model ownership of entry and
exit connectionPoints by a state. (These are further restricted by OCL constraints
described below.) Note that there is no need for State to reference any
ConnectionPointReferences, since the composite state is a part of the state machine.
??Page 461 (481) create a new subheading “Presentation Options” at the end of the
section describing the ConnectionPointReferenceClass
??Page 461 (481): Move figure 360 and the entire paragraph preceding it and figure 362
and the entire paragraph preceding it into the new Presentation Options subsection in
that order.
??Pg. 471 (491): extend the definition of entry and exit points to allow composite states
to have entry and exit points, not just state machines (submachines)
??Pg. 472 (492): for notation (figures 371 and 372), add references to composite states in
addition to state machine s.
??Pg. 473 (493): add a figure that shows the notation of entry and exit points for
composite states just before the paragraph that precedes figure 373 ??Pg. 478 (499): add a paragraph at the end explaining the meaning of entry and exit
points for composite states.
??Pg. 479 (500): add the new association end entry for ‘State::connectionPoint’
??Pg. 480 (501): add two new constraints that identify that only composite states can
have connection points and that these have to be entry and/or exit pseudostates and no
other kinds.
??Pg. 482 (503): describe the semantics of entering and exiting a composite state through
an entry/exit point respectively.
??Pg. 485 (506): add note just before fig. 506, explaining the notation of entry and exit
points for composite states.
??Pg. 487 (508): clarify that the notation in figure 388 can also be used for composite
states (but without the reference to a state machine)
??Pg. 489 (510): provide a reference to the example that shows the notation for entry and
exit points for composite states in the Notation section.
??Pg. 493 (515): explain that entry and exit points on composite states can be added
when specializing (extending) a state machine.
??Table 20: there were some incorrect references to pseudostates in this table that were
fixed (somewhat peripherally related to this issue)
9_StateMachines.isssue-6075.pdf


Issue 6076: UML2 super/pg. 580/Stereotype typo (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
The second paragraph of subsection "Notation" reads "When a stereotype
is applied to a model element (an instance of a stereotype is linked to
an instance of a metaclass), the name of the stereotype is shown within
a pair of guillemets above the name of the Stereotype."


I think the sentence should end with "... name of the model element".
Otherwise the stereotype's name would be mentioned twice.

Resolution: End the sentence with “name of the model element”.
Revised Text:
Actions taken:
August 27, 2003: received issue
March 8, 2005: closed issue

Issue 6077: Message notation. Incorrect notation in Figure 333 p.414 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Significant
Summary:
Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). 

The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. 

Originally reported by David Fado through Jim Odell. 

Resolution: This is a subset of the issue described in 6463. - duplicate
Revised Text:
Actions taken:
August 28, 2003: received issue
December 2, 2004: closed issue

Issue 6078: Strict ordering in Inline Part Decomposition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak. 

There should be a way to denote that the ordering within an inline part decomposition should be strict. 

Originally reported by Ericsson engineer Peter Cigehn. 

Resolution: see above
Revised Text:
Actions taken:
August 28, 2003: received issue
March 8, 2005: closed issue

Discussion:
The simplest solution is to append the lifeline text with an optional strict
keyword. This would mean that the events of the inline decomposition are strictly
ordered from top to bottom.
(When the decomposition is explicit reference, then the strict property would be
associated with the referenced diagram.)
Concrete changes to the Final Adopted document:
In the paragraph on Notation for Lifelines (p 427)
decomposition ::= ref interactionident
should be augmented to:
decomposition ::= ref interactionident [strict]
In the paragraph on Notation for PartDecomposition (p 432)
A new second paragraph should be inserted:
If the part decomposition is denoted inline under the decomposed lifeline
and the decomposition clause is the keyword strict, this indicates that the
constructs on all sub-lifelines within the inline decomposition is ordered in
strict sequence. See CombinedFragment on strict operator.


Issue 6079: Message End association to Interaction should be removed (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
There is an association in MessageEnd to Interaction (p. 431). This association should have been removed long time ago. It is a reminiscence of an earlier version. 


Resolution: see above
Revised Text:
Actions taken:
August 28, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 431 remove the following item in Associations for MessageEnd:
Interaction:Interaction[1] The enclosing Interaction owning the MessageEnd
Note: the owning Interaction is described for the associated Message


Issue 6080: EventOccurrence, multiplicities incorrect in metamodel diagram (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Clarification
Severity: Minor
Summary:
The metamodel shown in Figure 328, p. 407 presents the associations from EventOccurrence to ExecutionOccurrence with multiplicity ‘*’. This should be [0..1] as given in the text. 


Resolution:
Revised Text:
Actions taken:
August 28, 2003: received issue
March 9, 2005: closed issue

Discussion:
This issue was addressed as part of the resolution to issue 6224. Note that the
solution there was to retain the 0..* multiplicity, because it is possible that a given
event can cause multiple execution occurrences. So, the recommendation in this
issue is rejected.
Disposition: Closed, no change


Issue 6081: Incorrect mentioning of General Order On p 412 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
Incorrect mentioning of General Order On p 412: The only purpose of gates is to define the source and the target of Messages or General Order relations. 

" or General Order relations” should be removed. This is a reminiscence of an earlier version

Resolution: see above
Revised Text:
Actions taken:
August 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
Remove the phrase “or General Order relations” from the sentence
“The only purpose of gates is to define the source and target of Messages or General
Order relations ”.


Issue 6084: Remove occurrences of “TBD” (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
There are a couple of places where the flag “TBD” is still in the document. They should be removed. 

pp. 423, 427, 


Resolution: see above
Revised Text:
Actions taken:
August 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
Page 423 Remove word “TBD”
Page 427 Remove word “TBD”
More detailed constraints will be done in OCL according to the resolution of issue 6409


Issue 6085: Omission of non-terminal ‘arguments’ (p. 424) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
In top of p. 424 there is a small textual grammar for a name in an interaction occurrence. There should be one more production defining the non-terminal ‘arguments’ as shown below here: arguments ::= argument [ , arguments] 




Resolution: see above
Revised Text:
Actions taken:
August 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 424 in the Notation section add the following line between the line
giving the BNF for ‘name’ and the line giving the BNF for ‘argument’:
arguments ::= argument [, arguments]


Issue 6087: Figure 346 needs updating (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:
The Figure 346 on page 443 needs some updating: 1. The collaboration W should be shown as an oval 2. The text inside the right lifeline of sd Q should read “y:superB” (the colon is missing) 

Resolution: see above
Revised Text:
Actions taken:
August 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change the solid ellipse with name “w1:W” in the bottom part of the class diagram for
“E” into a dashed ellipse (page 161, chapter 9, notation for CollaborationOccurences: “A
collaboration occurrence is shown by a dashed ellipse”).
Change the solid line representing binding of “:B” as role “y” into a dashed line
(page 161, chapter 9, “for every role binding, there is a dashed line from the ellipse to the
client element”)
Leave the definition of the collaboration as a generic classifier symbol with a
stereotype <<collaboration>> so that the reusable seque nce diagram is nicely placed into
the middle (attributes) compartment. Do not use the special collaboration symbol (a
dashed ellipse, page161), since no examples in chapter 9 illustrate the notation for
placing reusable classifiers into these symbols. The generic composite structure notation
is fine.
Change the text “ysuperB” into “y:superB” (however, this part is a duplicate of
the issue 6950, already resolved)


Issue 6089: running a “Check Model” in Rose you get the following errors (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
When running a “Check  Model” in Rose you get the following errors. Of which I am sure you are aware of.   But do these errors indicate the absence of the parent element in the particular package or should the Specialize relation be deleted?

 

12:52:41|  [Check Model]

12:52:42|  Error: Unresolved reference from Package "Profiles"

12:52:42|         to Item with name ::Constructs::Packages

12:52:42|         by Dependency "<unnamed>".

12:52:42|  Error: Unresolved reference from Package "Profiles"

12:52:42|         to Item with name ::Constructs::Classes

12:52:42|         by Dependency "<unnamed>".

12:52:42|  Error: Unresolved reference from Package "Collaborations"

12:52:42|         to Item with name ::Deleted::Infrastructure_v069 (old)::Core

12:52:42|         by Dependency "<unnamed>".

12:52:42|  Error: Unresolved reference from Package "InternalStructures"

12:52:42|         to Item with name ::Deleted::Infrastructure_v069 (old)::Core

12:52:42|         by Dependency "<unnamed>".

12:52:42|  Error: Unresolved reference from Package "CompositeStructures"

12:52:42|         to Item with name ::Deleted::Infrastructure_v069 (old)::Core

12:52:42|         by Dependency "<unnamed>".

12:52:42|  Error: Unresolved reference from Class "ActivityEdge"

12:52:42|         to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

12:52:42|         by Generalize "<unnamed>".

12:52:42|  Error: Unresolved reference from Class "OutputPin"

12:52:42|         to Item with name Logical View::UML::Infrastructure::Core::Foundation::Classifiers::TypedElement

12:52:42|         by Generalize "<unnamed>".

12:52:42|  Error: Unresolved reference from Class "Message"

12:52:42|         to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

12:52:42|         by Generalize "<unnamed>".

12:52:42|  Error: Unresolved reference from Class "Type"

12:52:42|         to Item with name Logical View::InfrastructureLibrary::Core::Constructs::Type

12:52:42|         by Generalize "<unnamed>".

12:52:42|  Error: Unresolved reference from Class "State"

12:52:42|         to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

12:52:42|         by Generalize "<unnamed>".

 

Resolution:
Revised Text:
Actions taken:
August 9, 2003: received issue
March 9, 2005: closed issue

Discussion:
I verfied each of these errors . It turns out that these are all references – whether they are
dependencies or generalizations -- to model elements that no longer exist in the
metamodel (although each of them existed at some point in the evolution of the
metamodel). They are due to bugs in the tool used to generate the metamodel which did
not do a proper clean-up when the reference elements were eliminated. They do not affect
the generated XMI and, hence, no change is required.
Disposition: Closed, no change


Issue 6090: Variable and Pin multiplicity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The text refers to multiplicity of Variable and Pin, but they do not
inherit from MultiplicityElement

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
The text refers to multiplicity of Variable and Pin, but they do not inherit from
MultiplicityElement
Discussion:
Variables should have multiplicity, this was inadvertantly removed when Multiplicity
was separated from TypedElement during the submission process.
Answering issue 6107, lower multiplicity on pins tells how many values are needed as
input to start the action, and how many are needed as output to complete the action.
Upper multiplicity tells how many values are consumed from the input at the start of an
execution, and how many will be produced on output. This is similar to parameter
multiplicity on behaviors when called with invocation actions. It is not the same as
upperBound on object nodes, which is a maximum buffer size. isUnique is false for pins,
because because multiple tokens can have the same value in an object node.
Changes listed below.
?? In Figure 192, add MultiplicityEle ment (from Kernel) as a parent of Variable.
?? In Figure 176, add MultiplicityElement (from Kernel) as a parent of Pin.
?? In Pin class,
Constraints, add new constraint: “isUnique = false”
In Semantics, at the end in its own paragraph, add:
"Pin multiplicity controls action execution, not the number of tokens in the pin (see upperBound on
ObjectNode). See InputPin and OutputPin for semantics of multiplicity.
?? In the InputPin class, add Semantics section and insert:
"An action cannot start execution if an input pin has fewer values than the lower
multiplicity. The upper multiplicity determines how many values are consumed
by a single execution of the action."
?? In the OutputPin class, add Semantics section and insert:
"An action cannot terminate itself if an output pin has fewer values than the lower
multiplicity. An action may not put more values than the upper multiplicity in a
single execution."
Disposition: Resolved


Issue 6091: Outgoing edges from input pins (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
(Quote from Semantics of CompleteStructuredActivities) "An object
node attached to a structured activity node is accessible within the
node. The same rules apply as for control flow. An input pin on a
structured activity node implies that no action in the node may begin
execution until all input pins have received tokens. An output pin on
a structured activity node will make tokens available outside the
node only after no tokens left in the node or its contained nodes
recursively."


So input pins on structured activity nodes are "accessible within the
node" (as one would expect), but a constraint on InputPin says "input
pins have incoming edges only". So how are they accessed from within
the structured activity node? Analogous question for output pins of
structured activity nodes, which can have outgoing edges only.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In InputPin class, Constraints, change first constraint to: "Input pins may only have
outgoing edges when they are on actions that are structured nodes, and these edges must
target a node contained by the structured node.
In Outpin class, Constraints, change first constraint to: "Output pins may only have
incoming edges when they are on actions that are structured nodes, and these edges may
not target a node contained by the structured node.


Issue 6092: Clarify wording on executable activity nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Name: Jim Frank
Company: IBM
mailFrom: joachim_frank@us.ibm.com
Nature: Clarification
Severity: Significant
Subject: Clarify wording on executable activity nodes


In the Activities chapter, an action "is an executable activity node
that is the fundamental unit of executable functionality in an activity,
as opposed to control and data flow among actions."  Aren't control and
data flow required to execute an action?  The clause after the comma
should be removed, and perhaps replaced with a sentence saying actions
are used with control/data flow.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Description section of Action, p 280, clarify the first sentence by replacing it with:
"An action is an executable activity node that is the fundamental unit of
executable functionality in an an activity. Actions are coordinated by control and
data flow."


Issue 6093: Edge constraint for control nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The constraint for ControlNode ("The edges coming into and out of a
control node must be either all object flows or all control flows.")  is
inconsistent with the semantics for JoinNode, which permit mixed types
of incoming edges.  Likewise a merge node can merge control and data
flows.  What type of edge should be outgoing in this case?

Resolution: Remove constraint [1] for Control Node, p 317.
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Issue 6094: Action should be concrete (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Action should be concrete.  The description of the "effect" attribute
says: "An optional text specification of the effect of the action. This
may be used to indicate the behavior of an action without specialization
into a subclass, ... " We think this is a good concept, and would like
to instantiate Action for activity nodes whose behavior is only verbally
described.  Behavior, too.


Resolution: In Figure 176, make Action concrete.
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Issue 6095: Provide notations for Loop and Conditional (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide notations for Loop and Conditional

Resolution: Same as Issue 6071 (Conditional Node and Loop Node notation missing)
Revised Text:
Actions taken:
August 30, 2003: received issue
December 2, 2004: closed issue

Issue 6096: Weight=all (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The weight attribute on activity edges says:
"A null weight means that all the tokens at the source are
offerd to the target."


But a figure specifies {weight=all} for the same purpose.


Which one is the correct one?


I think {weight=all} is the better alternative to express the
semantic.


Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Figure 213 with the activity edge bearing “weight=all” is correct.
Recommended action:
Figure 209: replace “weight=null” with “weight=all”.
The sentence about weight above Figure 209 should be changed to “The weight is a value
specification that is a positive integer or null, which may be a constant. A weight of null
is notated as “all”.”


Issue 6097: Tokens at fork (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Fork won't let tokens pass on all outgoing edge unless all outgoing
edges accept the copied token.  Guards or backed up flows may prevent a
token from being accepted on an outgoing edge.  This causes a dependency
between the outgoing edges.

Resolution: This is duplicate with 6512.
Revised Text:
Actions taken:
August 30, 2003: received issue
December 2, 2004: closed issue

Issue 6098: ActivityFinalNode (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
What happens to running actions within the activity when a token reaches
an ActivityFinalNode?  Are the actions terminated immediately or do they
run to completion.  Would prefer that they are terminated immediately

Resolution: This is a duplicate of 6504.
Revised Text:
Actions taken:
August 30, 2003: received issue
December 2, 2004: closed issue

Issue 6099: ExpansionRegions keywords (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Revision
Severity: Significant
Summary:
The keywords "parallel", "iterative", and "stream" are defined for
ExpansionRegions, but the example figures use "concurrent" instead of
"parallel".  The metamodel type ExpansionKind solely defines parallel"
and the other two keywords mentioned above, not "concurrent".

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Notation section of ExpansionNode, p 326, first sentence, replace "concurrent"
with "parallel".
In the Example section of ExpansionNode, p 330, Figure 247, replace "concurrent" with
"parallel".


Issue 6100: Keywords or properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: ThoughtWorks (Mr. Martin Fowler, fowler(at)acm.org)
Nature: Revision
Severity: Minor
Summary:
Should the keywords "parallel", "iterative", and "stream" for
ExpansionRegions be in guillemets like localPrecondition?  Or is it a a
property that should be in curly braces, like streaming parameters.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
The text says it is a keyword. The figures should be aligned as follows:
In Figure 246, add guillemets around "parallel".
In Figure 247, add guillemets around "concurrent".


Issue 6101: Multiple outputs of object flow transformations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: ThoughtWorks (Mr. Martin Fowler, fowler(at)acm.org)
Nature: Revision
Severity: Significant
Summary:
It would be useful to allow object flow transformations to produce
multiple tokens from one token.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Transformation behaviors can already have an output parameter with maximum
multiplicity of "*", so can transform one token into many. Clarify as specified
below.
Under the ObjectFlow class, in Semantics (CompleteActivities) section, first
paragraph, add the following sentence to the end:
Transformation behaviors with an output parameter with multiplicity
greater than 1 may replace one token with many.
In the same paragraph, first sentence, append the following clause to the end:
", instead of the token that was input to the transformation behavior."


Issue 6102: Pins owned twice (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Pins are owned twice: by activities and actions

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
Pins are owned only by actions, not activities, per figures 176 and 178. Strongly
composed objects can only be owned once.
Disposition: Closed no change


Issue 6103: Pin/parameter matching 1 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
How are pins matched to parameters for invocation actions when there is
only one parameter list for behaviors and two for actions?  There should
be a general action-pin association specialized for inputs and outputs.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Insert the following text as the first paragraph in the Semantics section of CallAction,
p224:
Parameters on behaviors and operations are totally ordered lists. To match
parameters to pins on call actions, select the sublist of that list that corresponds to
in and inout parameters (i.e., Behavior.formalParameter). The input pins on
Action.input are matched in order against these parameters in the sublist order.
Then take the sublist of the parameter list that corresponds to out, inout, and
return parameters (i.e., Behavior.returnResult). The output pins on Action.output
are matched in order against these parameters in sublist order.
Delete the derivation indicator in figure 178 on p. 270 and in the metaclass entry for
Action, Associations section, p 280, under “input” and “output".
In the metaclass entry for Action, Associations section, p 280, under “input”, delete the
sentence “These are among the total set of inputs (other inputs represent constant
values).” It is left over from when value pins were not input pins.


Issue 6104: Pin/parameter matching 2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
What kind of pin is used for inout parameters?  If two pins are used,
how are they matched to the same parameter?


Resolution: Duplicate of 6103.
Revised Text:
Actions taken:
August 30, 2003: received issue
December 2, 2004: closed issue

Issue 6105: Pin/parameter matching 3 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
If the multiplicity of a parameter has zero lower bound, how does that
affect the execution semantics of an invocation action on the
behavior/operation?  If the pin value is optional in this case, then it
violates the current semantics.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Behavior parameters with minimum multiplicity of zero are optional, by the definition of
multiplicity. There is no violation of activity semantics.
To clarify, in the Semantics section of Parameter (as specialized), p 353, add this
sentence at the end of the section, in the same paragraph as "See semantics of Action and
ActivityParameterNode.":
"Also see MultiplicityElement, which inherits to Parameter. It defines a lower
and upper bound on the values passed to parameter at runtime. A lower bound of
zero means the parameter is optional. Actions using the parameter may execute
without having a value for optional parameters. A lower bound greater than zero
means values for the parameter are required to arrive sometime during the
execution of the action."
In the Semantics section of Action, p 281, replace the sentence just after the numbered
list "See ValuePin for exception to rule for starting action execution." with:
"See ValuePin and Parameter for exceptions to rule for starting action execution."


Issue 6106: Pin/parameter matching 4 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Clarify in CallBehaviorAction and CallOperationAction that the operation
and behavior may have out or results and still be called asynchronously.
The constraints on these actions regarding pin/parameter matching only
applies in the synchronous case.


Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Semantics section of CallBehaviorAction, p 225, in the paragraph labelled [3],
after the second sentence, add:
"Any return or out values from the invoked behavior are not passed back to the
containing activity."
In the Semantics section of CallOperationAction, p 228, in paragraph labelled [4], after
the first sentence, add:
"Any return or out values from the invoked operation are not passed back to the
containing activity."


Issue 6107: Pin multiplicity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
What is the semantics of pin multiplicity?  If it has no execution
effect, then remove it.  If it is the same as the multiplicity inherited
from TypedElement, then use that.  If multiplicity has the same
semantics as bound, then multiplicity should be used instead of bound

Resolution: See discussion and resolution to Issue 6090.
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Issue 6108: Optional parameters (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
What is the semantics for invocation actions on behaviors that have
parameters with multiplicity with lower bound of zero?  Currently, the
execution semantics requires all data inputs to arrive.

Resolution: Duplicate with 6105.
Revised Text:
Actions taken:
August 30, 2003: received issue
December 2, 2004: closed issue

Issue 6109: ObjectFlowEffect (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
ObjectFlowEffect requires edges from pins to actions.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Rather than reintroduce edges from pins to actions, move effect to parameters,
as specified below.
In Figure 186:
move the effect attribute on ObjectFlow to Parameter in Figure 189.
move ObjectFlowEffectKind to Figure 189 and rename it
ParameterEffectKind.
Updated Figure 186 shown below.   Updated Figure 189 shown below, with changes from Issue 6115
included.    In ObjectFlow class:
In Description section, after (CompleteActivities), change the first
sentence to: "Object flows add support for multicast/receive, token
selection from object nodes, and transformation of tokens."
In Attributes (CompleteActivities) section, delete the entry for effect.
In Constraints section: delete constraint [6].
In Notation section:
delete the paragraph above Figure 269.
move Figure 269 to the Notation section for Pin, above the last
sentence.
In Example section:
in the paragraph above Figure 273, delete the last sentence.
move the lower part of Figure 273 to a new figure at the end of the
Example section fo r Pin. In the ObjectFlowEffectKind class:
Rename the class to ParameterEffectKind and realphabetize with the
other classes.
Change the description to
"The datatype ParameterEffectKind is an enumeration that
indicates the effect of a behavior on values passed in or out of its
parameters. See Parameter."
In Parameter class:
In Attributes section, add this entry in alphabetical order with the others:
effect : ParameterEffectKind [0..*] Specifies the effect that the
owner of the parameter has on values passed in or out of the
parameter.
In Constraints section, add this constraint:
“Only in and inout parameters may have a delete effect. Only out, inout,
and return parameters may have create effect.”
In Semantics section, in a new paragraph before the last one, add:
“The effect of a parameter is a declaration of the modeler's intent, and
does not have execution semantics. The modeler must ensure that the
owner of the parameter has the stated effect.”
In the Pin class,
In the Notation section
before the last sentence, put Figure 269 from the Notation section
for ObjectFlow, and remove it from ObjectFlow.
above the figure just inserted, add this paragraph:
“(CompleteActivities) Specifying the effect that the behavior
of actions have on the objects passed in and out of their
parameters can be represented by placing the effect in
braces near the edge leading to or from the pin for the
parameter.” In the Examples section:
at the end, insert a new figure by moving in the lower part of Figure
273 to here.
above the figure just inserted, add this paragraph:
“In the figure below, an example depicts a Place Order
activity which creates orders and Fill Order activity which
reads these placed orders for the purpose of filling them.”


Issue 6110: ExecutableNode, ControlNode should be abstract (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
ExecutableNode, ControlNode should be abstract

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 176, p 268, make ExecutableNode and ControNode abstract. The class
descriptions already reflects this.


Issue 6112: Reentrancy 3 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide a notation for isReentrant.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
This attribute is of marginal importance at the abstract level of UML. It can be set using
the standard notation. Profiles for domains where the difference between reentrant and
non-reentrant behavior is important can invent a suitable notation.
Disposition: Closed, no change


Issue 6113: ObjectNode.isUnique (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Add constraint that ObjectNode.isUnique = false

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
ObjectNode does not inherit isUnique.
Disposition: Closed no change


Issue 6115: Parameter set corrections 1 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The end names on the association between Parameter and ParameterSet
are reversed.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 189, p 275, reverse the end names of the association between Parameter and
ParameterSet. Rename "parameterInSet" to "parameter".
In the Associations (CompleteActivities) section of ParameterSet, change the entry for
parameterInSet to:
"parameter : Parameter [1..*] Parameters in the parameter set."


Issue 6116: Parameter set corrections 2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Add constraint that two parameter sets should not have exactly the
same parameters in them

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Constraint section of ParameterSet, p 354, add this constraint:
"[3] Two parameters sets cannot have exactly the same set of parameters."


Issue 6117: Parameter set corrections 3 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Examples are incorrect in implying that parameter sets can replace
merges.  They are separate parameters, not a single input as would come
from a merge.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
This example is is inconsistent with the earlier TroubleTicket example and with the
original one from the workflow spec. It should be removed as described below:
In ParameterSet class, Examples section:
?? Remove the second and third sentences.
?? Remove the lower part of Figure 279, underneath the caption "Using
parameter sets to express "or" invocation".


Issue 6118: Parameter set corrections 4 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
How are parameter sets notated in classes?  Parameter sets can be
referred to by their names.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The usual property list notation can used for this.
Disposition: Closed, no change


Issue 6119: Parameter set corrections 5 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Rule 2 for parameter sets conflicts with nonoptional inputs: "If a
behavior has input parameters that are in a parameter set, then any
inputs that are not in a parameter set must be streaming. Same for
output parameters."  Just disallow parameters not in parameter sets in
the presence of parameter sets.  Since parameters be in more than one
set, there is no need for parameters out of a set in this case

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
Parameters can be optional. See issue 6105.
Disposition: Closed, no change


Issue 6120: Parameter set corrections 6 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Clarify that semantics for paramater sets on operations is the same as
for behaviors.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Semantics section ParameterSet, p 354, add this after the second sentence:
"The same is true for operation with parameter sets."


Issue 6121: Streaming (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Separate streaming from optionality and multiple tokens being input or
output during action execution.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Clarify the bullets in the Semantics section of Parameter, p 353, by replacing them with:
?? All required non-stream inputs must arrive for the behavior to be invoked. If
there are only required stream inputs, then at least one must arrive for the
behavior to be invoked.
?? All required inputs must arrive for the behavior to finish.
?? Either all required non-exception outputs must be posted by the time the activity
is finished, or one of the exception outputs must be.


Issue 6122: Parameter semantics clarification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
The semantics of parameters "Either all non-stream outputs must be
posted when an activity is finished, or one of the exception outputs
must be."  Reword and clarify that exception outputs are non-streaming.
Also state that exception outputs cannot be streaming.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The requested constraint is already there. The semantics text is consistent with that.
Disposition: Closed, no change


Issue 6123: Behavior execution instances (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Executing behavior creates an instance of the behavior class.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
It is not clear what the issue here is, as the above summary is merely a statement. In the
UML 2.0, Behavior (the abstract metaclass that is the superclass of all concrete behavior
descriptions) is a kind of Class. As such, instantiations of concrete subclasses will
generate instances. The informal model of the dynamic semantics of behaviors describes
these as BehaviorOccurrence, and differentiates two kinds of occurrences: executing
behavior and emergent behavior.
Closed until a better description of the issue is put forward.
Disposition: Closed, no change


Issue 6124: Local pre/postcondition example (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity: Significant
Summary:
Provide a local pre/postcondition example that is really local

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Modify the localPre/Postconditions for Figure 200 to read:
«localPrecondition» A drink is selected that the vending machine contains and the correct
payment is made
«localPostcondition» The vending machine dispensed the drink that is selected and
correct change is provided.
Modify the text above Figure 200.
-From: “The example below illustrates local pre and postcondition for the action of a
drink dispensing machine.”
-To: The example below illustrates local pre and postcondition for the action of a drink
dispensing machine. This is considered “local” because a drink-dispensing machine is
constrained to operate under these conditions for this particular action. For a machine
technician scenario, the situation would be different. Here, a machine technician would
have a key to open up the machine, and therefore no money need be inserted to dispense
the drink, nor change need be given. In such a situation, the global pre and
postconditions would be all that is required. (Global conditions are described in Activity
specification, in the next subsection.) For example, a global precondition for a Dispense
Drink activity could be “A drink is selected that the vending machine dispenses”; the
postcondition, then, would be “The vending machine dispensed the drink that is
selected.” In other words, there is no global requirement for money and correct change.


Issue 6125: Colon notation for pins (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clarify that parameter notation can be used for pins even when they
aren't invocation actions.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Under Pin class, Notation section, first paragraph, before the last
sentence, add another sentence:
"Pins that do not correspond to parameters can be labelled as "name :
type"."
Under ObjectNode class, Notation section, second sentence, add to the
end of the sentence:
", or the name and type of the node in the format "name : type"."
Under Parameter Node class, Notation section, add as first sentence:
"The label for parameter nodes can be a full specification of the
corresponding parameter."


Issue 6127: Value Pin notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide notation for value pins.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
A notation is given in the specification, see p. 363.
Disposition: Closed, no change


Issue 6128: Notation for for global pre/postconditions actions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide  notation for actions invoking beahviors with global
pre/postconditions

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Under CallBehaviorAction, Notation section, first paragraph, add sentence to the
end:
“Pre and postconditions on the behavior can be shown similary to Figure
197, using the keywords «precondition» and «postcondition»."
Under CallOperationAction, Notation section, first paragraph, add sentence to the
end:
“Pre and postconditions on the operation can be shown similary to Figure
197, using the keywords «precondition» and «postcondition».”


Issue 6129: Notation for isSynchronous (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Provide notation for isSynchronous on CallAction.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The usual property list notation can used for this.
Disposition: Closed no change


Issue 6130: No-token activity termination clarification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clarify that activities terminate if there are no tokens in it,
including tokens inside actions.  The semantics of Parameter only states
the necessary conditions now.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Parameter class, Semantics section, in the last bullet (modified per resolution
of issue 6121), at the end, add:
"An activity finishes when all its tokens are in its output parameter nodes.
If some output parameter nodes are empty at that time, they are assigned
the null token (see Activity), and the activity terminates."


Issue 6131: Clarification of insert (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
Clarify in AddStructuralFeatureAction, etc, that insert is not needed
when isReplaceAll = true.


Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In semantics of AddStructuralF eatureValueAction, p 220, at end of second paragraph,
add the following sentence:
The insertion point is ignored when replacing all values.


Issue 6132: SendObjectAction (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clean up SendObjectAction so it doesn't refer to signals.  It can send
any object, including a signal.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Association section of SendObjectAction, p 255, cha nge the description of request
to:
"The request object, which is transmitted to the target object. The object may be
copied in transmission, so identity might not be preserved. (Specialized from
InvocationActon.argument)"
Just below that, change the description of target to:
"The target object to which the signal is sent."
In the Rationale section of SendObjectAction, p 255, change the sentence to:
"Sends any object to a specified target object."


Issue 6133: ExceptionHandler 1 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Add a constraint to ExceptionHandler that the input of the exception
handler body must be one value of same type as the exception input
object node, and constraint that the input object node must be a pin
on/part of the protected node.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Under the ExpectionHandler class,
In Associations section, in the entry for exceptionInput, put the multiplicity
"[1..1]" after "ObjectNode".
In Constraint section:
Number the constriants.
In the second constraint, removed the string "(str-adv)" from the
beginning.
Add this constraint:
[3] The handler body has one input, and that input is the
same as the exception input.


Issue 6134: ExpansionRegion (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Why does ExpansionRegion have its own input/output metaassociations,
rather than the ones on actions?  (BTW, these associations are
misnomers, they are not just elements).  ExpansionRegion inherites pins
from StructuredActivityNode in complete activities

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The input/output associations on ExpansionRegion are the ones with the collections used
in the iteration. The values on input/output pins are constant over the iteration.
Disposition: Closed no change


Issue 6135: Pins on structured nodes 1 (uml2-superstructure-ftf)

Source: NIST (Mr. Conrad Bock,
conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Figure 193 - Structured nodes (CompleteStructuredActivities) shows
StructuredActivityNode, LoopNode, and ConditionalNode inheriting from
Action, but LoopNode and ConditionalNode already inherit from
StructuredActivityNode (Figure 192 - Structured nodes).

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 193, p 278, remove generalizations from ConditionalNode and LoopNode to
Action. The figure makes StructuredActivityNode an Action, and ConditionalNode and
LoopNode are already subtypes of StructuredActivityNode from Figure 192.


Issue 6136: Pins on structured nodes 2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Is it really intended that all StructuredActivityNode's have pins, such
as ExpansionRegions?


Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
Yes, see discussion at 6134.
Disposition: Closed no change


Issue 6138: Time spec text (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
The overview of Activity says: "The UML does not provide for the
specification of a time metric, but only describes sequences of
executions.", but UML does have a time model that can be applied to
activities.  Remove sentence.


It also says: "Execution is not instantaneous, but takes place over a
period of time." Seems like activities should be agnostic on this.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Recommended action: First, remove the following sentence from the first paragraph of
Actions and Activities in Section 12.1 Overview: "The UML does not provide for the
specification of a time metric, but only describes sequences of executions."
Second, in the same paragraph, remove the sentence: “Execution is not instantaneous, but
takes place over a period of time.”
Lastly, merge the paragraph with the one after it.


Issue 6139: Partition semantics (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clarify that behaviors outside of actions, such as on decision nodes,
guards, etc, that are contained in a partition, have the same semantics
as behaviors invoked by actions.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Semantics section of ActivityPartition, p 308, before the next-to- last paragraph, add a
new paragraph saying:
"Elements other than actions that have behaviors or value specifications, such as
transformation behaviors on edges, adhere to the same partition rules above for
actions."


Issue 6140: Activity frame and parameter nodes 1 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
An object node with no input or no output notation should map to an
ActivityParameterNode, so that frame isn't required.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Activity class, in Presentation Option section (separated from the Examples
heading by issue 6141), add this sentence after the sentence added by the
resolution of issue 6141, in the same paragraph:
“The round-cornered border or frame may be omitted completely. See
presentation option for ActivityParameterNode.”
In the ActivityParameterNode class, in Presentation Option section, add this
sentence at the beginning as its own paragraph:
“If the round -cornered border of Figure 220 is replaced with the frame
notation described in Appendix A, then activity parameter nodes overlap
the frame instead. If the round-cornered border or frame is omitted
completely, then the activity parameter nodes can be placed anywhere,
but it is clearer if they are placed in the same locations they would be if the
frame or border was shown.”


Issue 6141: Activity frame and parameter nodes 2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clarify that parameter nodes can overlap frame as defined in the
diagram appendix.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Presentation Option section of Activity, p 280, seperate the title of the section from
the title of the example section. Then add the following sentence to the Presentation
Option section:
"The round-cornered border of Figure 201 may be replaced with the frame
notation described in Appendix A. Activity parameter nodes are displayed on the
frame."


Issue 6142: Update actions for isUnique (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Update structural feature and associations actions for isUnique.  For
example, the semantics description of the class
AddStructuralFeatureValueAction says: "Reinserting an existing value at
a new position moves the value to that position (this works because
structural feature values are sets)".

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Update actions for nonunique structural features, association ends, and variables, as
follows.
In Figure 145:
Add attribute to RemoveStructuralFeatureAction:
isRemoveDuplicates : Boolean = false
Add association removeAt between RemoveStructuralFeatureAction and
InputPin.
as shown below:    In AddStructuralFeatureValueAction class:
In Semantics:
First paragraph, second sentence, after "If isReplaceAll is false" add "and
the structural feature is nonordered and nonunique".
Second paragraph:
Replace "infinity" with "unlimited" (two occurrences).
Next to last sentence, after "new position" insert "in an ordered,
unique structural feature".
In RemoveStructuralFeatureValueAction class:
In Description, add new paragraph a t end:
"Structural Features are potentially multi-valued and ordered, and may support duplicates, so the action
supports specification of removal points for new values. It also supports the removal of all duplicate
values."
In Attributes add:
isRemoveDuplicates : Boolean = false [1..1] Specifies whether to removes duplicates of the value in
nonunique structural features. In Associations add:
removeAt : InputPin [0..1] Specifies the position of an existing value to remove in ordered, nonunique
structural features. The type of the pin is UnlimitedNatural, but the value cannot be zero or
unlimited.
In Constraints add new constraint:
“Actions removing a value from ordered, nonunique structural features must have a single removeAt
inputPin if isRemoveDuplicates is false. It must be of type UnlimitedNatural with multiplicity of
1..1. Otherwise the action has no removeAt input pin.”
In Semantics, add new paragraph after first:
"Values of a structural feature may be duplicate in nonunique structural features. The
isRemoveDuplicates attribute indicates whether to remove all duplicates of the specified value. The
removeAt input pin is required if isRemoveDuplicates is false in ordered, nonunique structural
features. It indicates the position of an existing value to remove. It must be a positive integer less
than or equal to the current number of values. The semantics is undefined for zero, an integer
greater than the number of existing values, and unlimited."
In Figure 148:
Add LinkEndDestructionData as a kind of LinkEndData with attribute:
isRemoveDuplicates : Boolean = false
and with association removeAt to InputPin.
Add association from DestroyLinkAction to LinkEndDestructionData redefining
endData.
as shown below:    In CreateLinkAction class:
In Description, first paragraph:
last sentence, after "new position" insert "in an ordered, unique
structural feature".
replace "infinity" with "unlimited".
In Semantics:
WriteLinkAction
LinkEndData
LinkAction
Action
(from BasicActivities)
CreateLinkAction
Association
(from Kernel)
InputPin
(from BasicActivities)
ClearAssociationAction
1
0..1
+association 1
0..1
+object
{subsets input}
LinkEndCreationData
isReplaceAll : Boolean = false
2..*
1
+endData
{redefines endData}
InputPin
(from BasicActivities)
0..1
0..1
+insertAt
LinkEndDestructionData
isRemoveDuplicates : Boolean = false
0..1
0..1
+destroyAt
DestroyLinkAction
2..*
1
+endData
{redefines endData} Second paragraph, last sentence, add at end: "if the structural
feature is nonordered and nonunique".
Last paragraph:
Replace "infinity" with "unlimited".
Last sentence, after "new position" insert "in an ordered,
unique structural feature".
In LinkEndCreationData class:
Delete the Associations (CompleteActions) section and the qualifier entry
in it..
Move Constraints (CompleteActions) section and the constraints in it to
LinkEndData.
Add new class LinkEndDestructionData alphabetically in class list:
LinkEndDestructionData
LinkEndDestructionData is not an action. It is an element that identifies
links. It identifies one end of a link to be destroyed by DestroyLinkAction.
Description
This class is required when using DestroyLinkAction, to specify links to
destroy for nonunique, ordered ends. A link cannot be passed as a
runtime value to or from an action. See description of LinkData.
Qualifier values are used in CompleteActions.
Attributes
isDestroyDuplicates : Boolean = false Specifies whether to destroy
duplicates of the value in nonunique association ends.
Associations
destroyAt : InputPin [0..1] Specifies the position of an existing link
to be destroyed in ordered, nonunique association ends. The type
of the pin is UnlimitedNatural, but the value cannot be zero or
unlimited.
Constraints
[1] LinkEndDestructionData can only be end data for
DestroyLinkAction or one of its specializations. [2] Link end destruction data for ordered, nonunique association
ends must have a single destroyAt input pin if isDestroyDuplicates
is false. It must be of type UnlimitedNatural and multiplicity of 1..1.
Otherwise the action has no input pin for removal position.
Semantics
See DestroyLinkAction, also see LinkAction and all its children.
Notation
None.
Examples
Rationale
LinkEndDestructionData is introduced to indicate which links to destroy for
ordered, nonunique ends.
In DestroyLinkAction class:
In Description, add two new paragraphs at end:
"DestroyLinkAction uses a specialization of LinkEndData called
LinkEndDestructionData, to support ordered, nonunique
associations. The position of the link to be destroyed is specified at
runtime by an additional input pin, which is required for ordered,
nonunique association ends and omitted for other kinds of ends.
This is a positive integer giving the position of the link to destroy."
"DestroyLinkAction also uses LinkEndDestructionData to support
the destruction of duplicate links of the association on ends that are
nonunique. This option is available on an end-by-end basis, and
causes all duplicate links of the association emanating from the
specified ends to be destroyed."
In Associations add:
endData : LinkEndCreationData [2..*] (Redefined from
LinkAction:endData) Specifies ends of association and inputs.
In Semantics, add new paragraph after first:
"Destroying links for nonunique, ordered association ends requires
identifying the position of the link using the input pin of
LinkEndDestructionData. The pin is of type UnlimitedNatural with
multiplicity of 1..1. A pin value that is a positive integer less than or
equal to the current number of links means to destroy the at that position in the sequence of existing links, with the integer one
meaning the first link in the sequence. The semantics is undefined
for value of zero, an integer greater than the number of existing
links, and unlimited. The destroyAt input pin only exists for
ordered, nonunique association ends."
In Figure 149:
Add attribute to RemoveVariableValueAction
isRemoveDuplicates : Boolean = false
and association removeAt to InputPin.
as shown below:
In AddVariableValueAction: In Semantics:   First paragraph, second sentence, after "If isReplaceAll is false"
add "and the variable is nonordered and nonunique".
Second paragraph:
Replace "infinity" with "unlimited" (two occurrences).
Last sentence, after "new position" insert "in an ordered,
unique variable".
In RemoveVariableValueAction:
In Description, add new paragraph at end:
"Variables are potentially multi-valued and ordered, and may
support duplicates, so the action supports specification of removal
points for new values. It also supports the removal of all duplicate
values."
In Attributes add:
isRemoveDuplicates : Boolean = false [1..1] Specifies whether to
removes duplicates of the value in nonunique variables.
In Associations add:
removeAt : InputPin [0..1] Specifies the position of an existing value
to remove in ordered, nonunique variables. The type of the pin is
UnlimitedNatural, but the value cannot be zero or unlimited.
In Constraints add:
Actions removing a value from ordered, nonunique variables must
have a single removeAt inputPin if isRemoveDuplicates is false. It
must be of type UnlimitedNatural with multiplicity of 1..1, otherwise
the action has no removeAt input pin.
In Semantics, add new paragraph after first:
"Values of a variable may be duplicate in nonunique variables. The
isRemoveDuplicates attribute indicates whether to remove all
duplicates of the specified value. The removeAt input pin is
required if isRemoveDuplicates is false in ordered, nonunique
variables. It indicates the position of an existing value to remove. It
must be a positive integer less than or equal to the current number
of values. The semantics is undefined for zero, an integer greater
than the number of existing values, and unlimited."


Issue 6143: actions on properties that are association ends (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Revision
Severity: Significant
Summary:
Clarify semantics for (or lack thereof) for modifying properties that
are association ends

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Actions on a structural feature that is also an association end has the same semantics as
the actions on links. Clarify as below.
In StructuralFeatureAction, Semantics, first paragraph after second sentence, add:
"If the structural feature is an association end, then actions on the feature have
the same semantics as actions on the links that have the feature as an end. See
specializations of StructuralFeatureAction."
In ReadStructuralFeatureAction, Semantics, after first sentence add:
"If the feature is an association end, the semantics is the same as reading links
of the association with the feature as the open end."
In AddStructuralFeatureAction, Semantics, at end of first paragraph, add:
"If the feature is an association end, the semantics is the same as creating a link,
the participants of which are the object owning the structural feature and the new
value".
In RemoveStructuralFeatureAction, Semantics, at end of first paragraph, add:
"If the feature is an association end, the semantics is the same as destroying
links, the participants of which are the object owning the structural feature and
the value being removed."
In ClearStructuralFeatureAction,
"If the feature is an association end, the semantics is the same as
ClearAssociationAction on the object owning the structural feature."
Disposition: Resolved


Issue 6144: BroadcastSignalAction (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Clarify whether BroadcastSignalAction returns after the signals are sent
or after they are received.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Under BroadcastSignalAction class, Description section, next to last sentence,
add to the end of the sentence:
"after the signals are sent out. It does not wait for receipt."


Issue 6145: Action packaging (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Structured actions should depend on structured activities for
variables.  In general, actions should be in smaller packages to

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
See resolution of 7319. It introduces a separate package for actions requiring
structured activities, and a basic actions package.


Issue 6146: Composite structure dependent on Behavior (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Composite structure uses Classifier from Communications, but composite
structure should be usable without behavior.

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
Actually, none of the packages in the composite structure chapter rely on
Communications::Classifier directly. But if by “Composite structure” the issue is
referring to the whole chapter on Composite structure, then it is difficult to understand
what the concern is. Various subpackages described in this chapter necessarily rely on the
Communications package, such as InvocationActions or Ports, so these packages cannot
be used without Behaviors (they inherently involve behavior).
Communications
(from CommonBehaviors)
InternalStructures
Ports
Interfaces
(from Classes)
<<merge>> <<merge>>
<<merge>>
InvocationActions
<<merge>>
<<merge>>
<<merge>>
StructuredClasses
<<merge>>
<<merge>>
As can be seen above, StructuredClasses depends on Communications in two ways:
Through Ports and directly. The issue suggests that by deleting the dependency between
StructuredClass and Communications due to Communications::Class, one does not depend on Communications. However, one will still have the dependency through Ports.
This is for good reasons, as Ports require Communications (they reference Receptions,
which are introduced in Communications).
I assume that the issue, however, is referring to StructuredClasses::Class. This class is a
subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the
Behavior package, but by design. The reason why Class from communciations is taken is
that StructuredClasses::Class should be (i) be able to have ports, i.e., be an encapsulated
classifier, and (ii) be able to have behavior, i.e., be a behaviored classifier. Only due to
the latter do the additions of ports by inheriting from EncapsulatedClassifier make sense.
This allows, for example, to associate interactions as behaviors with the class.
The issue states that “composite structure should be usable without behavior.” If
“composite structure” refers to the internal structure of a classifier, this is already the
case. If “composite structure” refers to a classifier that also has ports, this is not possible,
as the definition of ports already refers to behavior.
Profiles that want to introduce a new kind of class that can have ports, but no behavior
(somewhat nonsensical, but be that as it may), can easily do so.
Disposition: Closed, no change


Issue 6147: Complex port (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
ComplexPort is referred to in Diagrams section of composite structures,
but it is not in the metamodel.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Delete the last sentence of cell Port/Reference in Table 6 “Graphic nodes included in
composite structure diagrams”. This sentence was inadvertently left in the document.


Issue 6148: Concrete Behavior (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Behavior should be a concrete class so behaviors can be defined without
committing to which model will be used to specify them later

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The solution to issue 6149 introduces a metaclass for behavior that is specified only
textually, without committing to a particular behavior model (OpaqueBehavior). This is
mirrored on ValueSpecification, where OpaqueExpression defines an abstract value, and
Expression, the subtypes of LiteralSpecification, and InstanceValue give concrete
models, while OpaqueExpression describes a value textually only, without committing on
how it is finally described. The solution 6149 makes this issue obsolete.
Disposition: Closed, no change


Issue 6149: Activity attributes on Behavior (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The attributes of Activity defined in CommonBehavior look like they
belong on Behavior.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
See resolution of 7319. It introduces OpaqueBehavior for these attributes and
removes Activity from Common Behavior.


Issue 6151: Diamond notation for merge junctions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Merge junctions should have a diamond notation option, for readability
and backward compatibility

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
Merge junctions have been introduced in UML1.5 in the context of activity-graphs. There
is no reason to include this notation for statemachines as the concept of merge junctions
as such does not exist there nor it is used in that context.
Disposition: Closed, no change.


Issue 6152: Protocol state machines are not pre/postconditions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The text in the semantics of ProtocolStateMachine says:


    The protocol transition can always be translated into pre and post
    conditions of the associated operation. For example, the transition
    in Figure 9-13 specifies that:


        1. the operation "m1" can be called on an instance when it is in
           the state S1 under the condition C1,


        2. when m1 is called in the state S1 under the condition C1,
          then the final state S2 must be reached under the condition
          C2.


The above translation is not possible by the definition of protocol
machines.  Protocol machines are a client-side view, independent of the
the internal behavior machine of the instance.  This means the protocol
states are not necessarily the same as the internal states of the
intance.  The protocol machine is keeping track of the operations that
have been called to enforce and order, but the internal behavior machine
may or may not be the same.  If they are the same, there would be no
purpose to the protocol machine.


The spec actually makes the same point at the beginning of the semantics of
PSM:


    Using pre and post conditions on operations is a technique well
    suited for expressing such specifications. However, pre and post
    conditions are expressed at the operation level, and therefore do
    not provide a synthetic overview at the classifier level. Protocol
    state machines provide a global overview of the classifier protocol
    usage, in a simple formal representation.


That is, If PSM's were easiy mappable to operation pre/postcondtions,
there would be no point to having PSMs.


Suggested change to the text:


  A protocol state machine could in theory be translated to pre- and
  postconditions on operations, but the conditions would need to account
  for the operation call history on the instance, which may or may not
  be straightforwardly represented by its internal states.  A protocol
  machine provides a direct model of the state of interaction with the
  instance, so that constraints on interaction are more easily
  expressed.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

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


Issue 6153: Interactions view of state machines/activities (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Revision
Severity: Critical
Summary:
Interactions should be able to show a message passing view on a state
machine or activity, by referring directly to the invocation actions in
those models.  UML 1.4 worked this way.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
See resolution of 7319. It introduces a link between interactions and actions that
can be used for interactions to refer to actions contained in activities or state
machines.


Issue 6154: TimeObservationAction can't return values (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
TimeObservationAction says it returns a value, but it is a kind of
WriteStructuralFeatureAction, which doesn't return values.  Does it
write the value to a structural feature?  I assume the semantics should
be more like DurationObservationAction

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
The explanatory text could be improved. It is correct that it is a
WriteStructuralFeatureAction and it does not itself return a value, but writes the
value to a given structural feature. This is at least shown in the example.
The same should hold for DurationObservationAction.
Replace the text for TimeObservationAction up to, but not including the example,
by the following (i.e., don’t change Fig. 324 or the text below the figure):
13.3.26 TimeObservationAction (from Time)
Description
A TimeObservationAction defines an action that observes the current point in time and writes this
value to a structural feature.
Attributes
No additional attributes.
Associations
• now: TimeExpression [1] Represents the current point in time and the value which is observed,
given by the keyword now.
Constraints
No additional constraints.
Semantics
A TimeObservationAction is an action that, when executed, obtains the current value of time in
the context in which it is executing and writes this value to the given structural feature.
Notation
A TimeExpression is depicted by text in the expression language used to denote a time value. It
may be possible that a time value contains arithmetic operators. The time expression is associated
with a NamedElement with a line. A time observation action assigns a time expression to an
structural feature.
timeobservation ::= write-once-attribute “=” “now”
Replace the text for DurationObservationAction up to, but not including the
examples section:
13.3.13 DurationObservationAction (from Time)
Description
A DurationObservationAction defines an action that observes a duration in time and writes this
value to a structural feature.
Attributes No additional attributes.
Associations
• duration: Duration[1] represent the measured Duration
Constraints
No additional constraints.
Semantics
A DurationObservationAction is an action that, when executed, measures an identified duration in
the context in which it is executing and writes the obtained value to the given structural feature.
Notation
A Duration is depicted by text in the expression language used to denote a duration value. It may
be possible that a duration contains arithmetic operators. A duration observation occurs when a
duration is assigned to a sructural feature. The duration observation is associated with two
NamedElements with lines.
durationobservation ::= write-once-attribute “=” “duration”


Issue 6155: Replace "initial value" with "default value". (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
"Default values" should be called "initial values", for example in
property values.  Defaults are values that are assumed if no value is
available on the instance.  This can be at any time during the life of
the object.  An instance may have a value for a property at one time and
when the value is removed, the default takes over until another value is
given.


The current semantics is that the "default" value is put in the property
only when the object is created.  If the value is later removed, the
"default" value does not return.  This is normally called an "initial
value".

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
In the spec ‘initial value’ is used for values supplied on instantiation (e.g. para 3 of p87
which states: When an object is instantiated in a class, for every attribute of the class that
has a specified default, if an initial value of the attribute is not specified explicitly for the
instantiation, then the default value specification is evaluated to set the initial value of the
attribute for the object.”
In the UML spec it states that ‘default’ is indeed used in initialization, however it does
not state that it is only used then. For example MOF provides the ability to ‘unset’ a
Property in which case the default is used (see MOF 2 Core section 9.1): so this does tie
in with ‘normal’ usage of ‘default’.
Disposition: Closed, no change


Issue 6156: Kernel::Classifier missing "attribute" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Kernel::Classifier lists the feature "attribute", and gives semantics
and notation, that isn't shown in the abstract syntax for
Kernel::Classifier.  There isn't an "attribute" in the MDL file.


Kernel::Classes abstract syntax refers to "attribute" in the subsetting
of ownedAttribute.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Superstructure, the notation section for Classifiers will be re-written to
indicate that the standard allows the use of notation of the rectangle for any kind
of Classifier, at the discretion of the users. Ommissions from the text and the
diagram will be corrected.
In the Infrastructure, to keep it in line with the superstructure, the Associations
subsection will be corrected by the addition of the slash to properly indicate the
derived status of Classifier.attribute.
Background
For reference:: Section 7.8.1 of the FAS, on page 62 (as printed) lists attribute
as the first association of Classifier. Note that a slash is missing.
The diagram Figure 22 for the abstract syntax for Kernell::Classifier is shown
next, and the issue is correct, the Association to Property, a metaassociation in
which the Property has the rolename ‘attribute’ is missing. Changes to the Superstructure metamodel and figures:
UML 2.0 Superstructure FTF
Disposition: Resolved
OMG Issue No: 6156
Document {Report document number} Page 159
Add a directed association from Classifier to Property, rolenamed ‘attribute’ prefixed
with ‘/’ to indicate derived, in Figure 22, so it matches in this respect, with Figure 33. .
Changes to the text of both Superstructure and Infrastructure:
Prefix the slash character to ‘attribute’ to indicate derived status in the following text
from the Associations heading under Classifier sections
/attribute : Property [*]
The current FAS Superstructure text concerning Attribute notation begins as follows:
Changes to the Notation section of Superstructure
This paragraph shall have the following inserted at the very beginning:
Classifier is an abstract model element, and so properly speaking has no notation. It is
nevertheless convenient to define in one place a default notation available for any
concrete subclass of Classifier for which this notation is suitable.


Issue 6157: Property string undefined (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The BNF for property-string is missing in Property and Operation. Eg,
how are the properties delimited (a comma?)?  How are property values
shown (property-name property-value)?

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is in part a duplication of the problem reported in issue 7135, that the syntax
for property strings is not given in a correct and consistent BNF. It is a shared
superstructure/infrastructure issue.
Section 7.10.1 Operation lacking proper BNF has been corrected with Issue 7135
This leaves us with the issue wrt Property.
We propose a resolution that re-writes the text and syntax regarding propertystrings
for Properties. The syntax as it is given in the FAS for both Infra and
Super is defective, not only because it does not use BNF, but because it
confuses the property-string, which includes the curly braces and delimiting
commas, with the property expressions, which themselves are not always
terminal literals, as they include such as
'redefines' <property-name>
If the definition as it stands now in the FAS were taken literally, we would have a
curly braces nested inside curly braces, because property strings are defined as
if they were a composition of property strings!
In addition, we
a) correct an error in respect to the name 'redefines' which is mistakenly given as
'redefined' on page 83;
// Note this next, b and c, is the part that may be going beyond what is
desirable here:
b) correct redundancy and omissions in property-string names for
association ends, 'ordered' , 'bag' and 'sequence' a correction which brings
the properties of association end collections in line with the properties of
Collections. c) in cleaning up the syntax under Notation on page 83, we must move the
semantics that are now mixed in with the syntax, back to page 81 in the
semantics section.
Discussion of (b): The property expression names for are defective in
respect to definition and naming of bag, ordered, and sequence. For
example, the current text says: "If the end is marked as unique, this
collection is a set. This is at the very least misleading, in that a
sequenced collection is not called a set, and an end marked as unique
may also be marked in the property string for the end, as ordered.
These 3 names for use as property expressions are intended to describe
the collection denoted by an association end in respect of whether that
collection is permits or prevents duplicates among the members of the
collection, and whether the members are mapped to ordinal numbers to
indicate a sequence. These two features of a collection are orthogonal, so
that it is possible for there to be collections which allow duplicates, and are
ordered, that prevent dupllicates, and are ordered, that allow duplicates
and are not ordered, and that prevent duplicates and are not ordered.
The defective set of three - ordered, sequence, bag - also leaves out one
possibility.
By making the property expressions 'ordered' and 'distinct' orthogonal, it is
redundant to have the property expression 'sequence' as defined now.
A collection that permits the same element to appear more than once
need not be a bag, it could be an array with the same element in many
positions. A set, in the usual sense, is not the same as an ordered
sequence of non-recurring values, so it is wrong to say, "If the end is
marked as unique, this collection is a set". You also need to mark it as not
ordered.
To correct these problems replace the following sentences from the
Superstructure and Infrastructure FAS:
Old Text: Semantics section on p. 82 Superstructure, p. 113 Infra
An end of one association may be marked as redefining an end of another …
New Text:
An end of one association may be marked to show it redefines an end of
another…
Old Text: mid page 93 under "Notation" for Property Superstructure Only
See "Classifer (from Kernel, Dependencies, PowerTypes)" on page 61. See
"Association (from Kernel)" on page 81. New Text: avoid hard-coded page numbers, replace with:
See Classifier (from Kernel, Dependencies, PowerTypes). See Association (from
Kernel).
Old Text: bottom of 81 continuing to top of 82, Superstructure Only
If the end is marked as ordered, this collection will be ordered, If the end is marked as
unique, this collection is a set; otherwise it allows duplicate elements.
New Text: replace with:
If an end is marked as ordered, its collection is organized as a sequence. If an
end is marked as unique, no duplicates are permitted within its collection.
Examples of usage: to specify the collection as a set, do not mark it as ordered but
do mark it as unique; to specify a bag, do not mark the end as ordered, and do not
mark it as unique.
Old Text: beginning bottom of 83 Super, midpage 114, Infra
A property string may be placed near the association symbol, but far enough from
any end to not be confused with a property string on an end.
New Text: add a sentence, so the result is as follows:
A property string may be placed near the association symbol, but far enough from
any end to not be confused with a property string on an end. A property string is a
comma-delimited list of property expressions enclosed in curly braces. A property
expression is, in the simplest case, a name such as 'redefines' or 'subsets'.
Old Text: under Notation on page 83 Superstructure and page 114 Infra.
New Text:
The BNF for property strings on association ends is:
<property-string> ::= '{' <end-property> [ ',' <end-property> ]* '}'
<end-property> ::=
(
'subsets' <property-name> | 'redefines' <end-name>
)
where <property-name> and <end-name> are names of user-provided properties and
association ends found in the model context. If an association end is navigable, attribute-properties defined for attributes are legal as
end-properties in the property string for that association end.


Issue 6158: Notation for attributes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The notation for attributes is given in Kernel::Classifier, but the
abstract syntax for classifiers have no features

Resolution:
Revised Text:
Actions taken:
August 30, 2003: received issue
March 9, 2005: closed issue

Discussion:
The abstract syntax for classifiers does have attributes, subsetting features, as is
made clear in the resolution to 6156.
This issue was submitted when the syntax diagram for classifier did not show
/attribute, a defect fixed by the resolution to 6156.
Disposition: Closed, no change


Issue 6159: Instantiates stereotype (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Figure 54 (An example of a instantiatedependency) shows the instantiates
stereotype/keyword being used as an instance-of relation, whereas the
entry for the instantiates stereotype in the standard stereotypes table
says "A usage dependency among classifiers indicating that the
operations on the client create instances of the supplier".

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Figure 54 indeed misinterprets the meaning of the ‘instantiates’ variant of Dependency.
The fix is quite straightforward:
In figure 54, replace the label “Car” by the label “CarFactory” and the label
“VehicleType” by the lable “Car”


Issue 6160: Notation for anonymous instance (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Clarify the notation for anonymous instance

Resolution: see below
Revised Text: Revised Text: (the new text in blue. “if any” removed because optionality is specified in new text) An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name, a colon (‘:’) and the classifier name or names. The convention for showing multiple classifiers is to separate their names by commas. Names are optional for UML 2 classifiers and instance specifications. The absence of a name in a diagram may reflect its absence in the underlying model. The standard notation for an anonymous instance specification of an unamed classifier is an underlined colon (‘ :’).
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Issue 6170 (an issue reported later and so classified as a duplicate of this) gives the
following review of why the Notation subsection of 7.7.1 InstanceSpecification requires
clarification:
The first paragraph indicates that both the instance name and the
classifier can be omitted from an instance specification. This informal
description leads open the possibility of specifying [sic] just the
colon with neither the instance name nor the classifier.
This strikes folks as odd or bad, but it is a known consequence of making names optional
for packageableElement (the superclass which generalizes both
InstanceSpecification and classifier) in UML 2. Furthermore, the
metamodel, in addition to making name optional for Classifiers, makes the multiplicity of
the associated Classifier for an instance specification be [0..*]. The classifier itself being
optional makes it even more clear that it is legal to have a diagram in which there is no
classifier name to follow the colon in the standard notation. If users find this ugly, they
can simply always have names and/or classifiers.
The query isDistinguishableFrom() for named elements will assist in preventing the
confusion that would result from having many anonymous instance specifications in the
same package without being differentiated by their Classifier(s).
Discussion:
Revise the text in the Notation subsection of 7.7.1 to clarify this intention. A few extra
words here will save us from future duplicate issues on this topic.
The current text reads:
An instance specification is depicted using the same notation as its classifier, but in place of the
classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and
the classifier name or names. If there are multiple classifiers, the names are all shown separated by
commas. Classifier names can be omitted from a diagram.


Issue 6161: Clarify that profiles can contain model libraries (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
The definition of <<modelLibrary>> says it is:


    A package that contains model elements which are intended
    to be reused by other packages. A model library differs from
    a profile in that a model library does not extend the
    metamodel using stereotypes and tagged definitions. A
    model library is analogous to a class library in some
    programming languages.


However, profiles can contain model libraries.  UML 1.x has an explicit
dependency to model this (called <<modelLibrary>> also).  It should be
clarified that in 2.0 this is done by including model library pacakages
in profile packages.  The above text should be clarified.  Suggestion:


    A package that contains model elements which are intended to be
    reused by other packages. A model library can be contained in a
    profile package, but the classes in a model library are not
    stereotypes stereotypes and tagged definitions extending the
    metamodel. A model library is analogous to a class library in some
    programming languages.

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
(Pete)
- If a Profile contains a ModelLibrary what is the effect of applying and removing the
profile? Is it just like creating/deleting the elements? If a Profile is applied, removed and
then re-applied then do the elements have the same identity?
- Does this differ if the ModeLibrary is imported as opposed to contained? And what if 2
applied Profiles both import the same ModelLibrary?
- Can the elements within the ModelLibrary itself be stereotyped by the Stereotypes in
that Profile?
(Philippe)
Replace the text for in the glossary entry Model library (pg. 11):
A package that contains model elements which are intended to be reused by other
packages. Model libraries are frequently used in conjunction with applied profiles. This is
expressed by defining a dependency between a profile and a model library package, or by
defining a model library as contained in a profile package. The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is
analogous to a class library in some programming languages.
When a model library is defined as a part of a profile, it is imported or deleted with the
application or removal of the profile. The profile is implicitly applied to its model library.
In the other case, when the model library is defined as an external package imported by a
profile, the profile requires that the model library be there in the model at the stage of the
profile application. The application or the removal of the profile does not affect the
presence of the model library elements.
Replace the text for in the appendix B table entry for Model library (pg. 595):
A package that contains model elements which are intended to be reused by other
packages. Model libraries are frequently used in conjunction with applied profiles. This is
expressed by defining a dependency between a profile and a model library package, or by
defining a model library as contained in a profile package. The classes in a model library
are not stereotypes and tagged definitions extending the metamodel. A model library is
analogous to a class library in some programming languages.
When a model library is defined as a part of a profile, it is imported or deleted with the
application or removal of the profile. The profile is implicitly applied to its model library.
In the other case, when the model library is defined as an external package imported by a
profile, the profile requires that the model library be there in the model at the stage of the
profile application. The application or the removal of the profile does not affect the
presence of the model library elements


Issue 6162: Typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
On the Description of complete activities: :Edges support controlling
token flow and be contained in interruptible regions."


"It covers invocation nodes, control nodes (...)". I believe it should
read "It covers executable nodes, control nodes (...)"


"A control flow is an edge starts an activity node after the previous
one is finished."


"The input parameter must be the same as or a supertype the type of
object token coming along the incoming edge."


"This is equivalent interposing a CentralBufferNode between the initial
node and its outgoing edges."


"A loop node is a costructured activity node that represents a loop with
setup, test, and body sections." page 331, Table 2 caption should be
"Graphic paths (...)" instead of "Graphic nodes (...)". Table 3 caption
should also be made more specific.


Add constraint numbers to ExceptionHandler.


In ActivityNode, the entry for interuptibleRegion should be under a
heading Associations (CompleteActivities).


In semantics of ActivityEdge move sentence about guards from
(IntermediateActivities) to basic.


"in invoked" => "is invoked"


Constraint 5 for ActivityParameterNode should read: "Activity parameter
object nodes with no outgoing edges and one or more incoming edges must
have a parameter with out, inout, or return direction."


Text should list mustIsoloate under StructuredActivityNode, not
ActivtyNode.


Local pre/postcondition semantics: "must" => should.


Local pre/postcondition semantics: "locaprecondition" =>
"localPrecondition".


Semantics of streaming parameter, third bullet/execution rule: replace
"activity" with "behavior".  Also in second bullet, remove "for" from
"that is, for all".  Also add analogous sentence after "not just at the
beginning" for outputs.


Search on "wil exist", replace with "will exist".


Search on "(str-adv)" and remove.


In ConditionalNode: "the modeler asserts that at least one true section
will yield a true value."  Should be "test section".


IsReadOnly is in basic activities in the metamodel diagrams, but should
be in complete, according to the attribute list on Activities.


In ReclassifyObjectAction and elsewhere, replace "error" with "undefined
semantics".

Resolution: see above
Revised Text:
Actions taken:
August 30, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Description (CompleteActivities) of edges in 12.3.3 ActivityEdge, change text
-from: “Edges support controlling token flow and be contained in interruptible regions."
-to: “Complete activity edges can be contained in interruptible regions.
In the Description of edges 12.3.3 ActivityEdge, add sentence.
“Activity edges can control token flow.”
In the Description of 12.3.6 ActivityNode , change text
-from: "It covers invocation nodes, control nodes (...)"
-to "It covers executable nodes, control nodes (...)"
In the first sentence of 12.3.12 ControlFlow, change text
-from: "A control flow is an edge starts an activity node after the previous one is
finished."
-to "A control flow is an edge that starts an activity node after the previous one is
finished."
In the Constraints [2] of 12.3.15 DecisionNode, and Constraints [2] and [4] of 12.3.30
ObjectFlow, change text
-from: " (...) the same as or a supertype the type of object token (...)"
-to: " (...) the same as or a supertype of the type of object token (...)"
In the Semantics of 12.3.24 InitialNode , change text
-from: "This is equivalent interposing a CentralBufferNode between the initial node and
its outgoing edges."
-to: "This is equivalent to interposing a CentralBufferNode between the initial node and
its outgoing edges."
In the first sentence of 12.3.28 LoopNode, change text -from: "A loop node is a costructured activity node that represents a loop with setup, test,
and body sections."
-to: "A loop node is a structured activity node that represents a loop with setup, test, and
body sections."
In label of Table 12, change text
-from: "Graphic nodes (...)"
-to: "Graphic paths (...)"
In label of Table 13, change text
-from: "Graphic nodes (...)"
-to: "Other graphic notations (...)"
Add [1] and [2] to Constraints in 12.3.16 ExceptionHandler.
In 12.3.6 ActivityNode , change the heading for interruptibleRegion
-from: "Associations”
-to: "Associations (CompleteActivities)”
In 12.3.3 ActivityEdge, move contents of Semantics (IntermediateActivities) to basic
Semantics, and remove the Semantics (IntermediateActivities) section.
In the Semantics of 12.3.7 ActivityParameterNode , change text
-from: "in invoked"
-to: "is invoked"
In the Semantics of 12.3.7 ActivityParameterNode, change Constraint [5]
-to: "Activity parameter object nodes with no outgoing edges and one or more incoming
edges must have a parameter with out, inout, or return direction."
The mustIsoloate attribute should be moved from the Attributes
(CompleteStructuredActivities) area in 12.3.6 ActivityNode to the corresponding area
in 12.3.38 StructuredActivityNode
The description of the mustIsoloate semantics should be moved from the Semantics
(CompleteStructuredActivities) area in 12.3.6 ActivityNode to the corresponding area
in 12.3.38 StructuredActivityNode
In the CompleteActivities portion of Semantics in 12.3.1 Action, change text
-from: “Local preconditions and postconditions are constraints that must hold …”
-to: “Local preconditions and postconditions are constraints that should hold …”
In the Figure 200, change text
-from: "locaprecondition"
-to: "localprecondition" In the Semantics of 12.3.35 Parameter, second bullet, change text:
-from: “All inputs must arrive for the behavior to finish, that is, for all inputs ….”
-to: “All inputs must arrive for the behavior to finish; that is, all inputs ….”
In the Semantics of 12.3.35 Parameter, third bullet, change text:
-from: “Either all non-stream outputs must be posted when an activity is finished, ….”
-to: “Either all non-stream outputs must be posted when a behavior is finished, ….”
In the Semantics of 12.3.1 Action, change text:
-from: “wil exist"
-to: "will exist".
In the Contraints of 12.3.16 ExceptionHandler, remove "(str-adv)".
In the Semantics of 12.3.11 ConditionalNode , change text:
-from: “ at least one true section will yield a true value."
-to: “ at least one test section will yield a test value."
And:
-from: “ at most one true section will yield a true value."
-to: “ at most one test section will yield a test value."
IsReadOnly is in basic activities in the metamodel diagrams (Figure 176), but should be
moved to the complete activities metamodel (Figure 184) (according to the attribute list
on Activities).


Issue 6164: UML Superstructure: 03-08-02 -- typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
p. 32, 2nd/3rd semantics paragraph
"element" instead of "ele-ment" (twice)
"qualified" instead of "qual-ified"


p.38, presentation options:
"identifies" instead of "identi-fies"


p. 108, fig. 53:
"<<dependencyName>>" instead of "<<dependecyName>>"


p. 109, fig. 54:
"An example of a instantiate dependency" instead of "An example of a instantiatedependency"


p. 110, Description:
First and second paragraph are the same.


p. 114, 3rd line:
"...mapping to a property of..." instead of "...mapping to a propertyof..."


p. 117, fig. 65:
Class name is "DoorBell" instead of "oorBell"


p. 137, last paragraph, first line:
"...by a component that offers equivalent..." instead of "...by a component that offers that offers equivalent..."


p. 170, first line:
"...while the figure on the right..." instead of "...while the figure onj the right..."


p. 172, semantics paragraph:
Reference to ""StructuredClassifier" on page 171" seems to be wrong (twice)


p. 325, stream description:
"..., in order of..." instead of "..., in oprder of..."


p. 403, last but one paragraph:
"...UML language..." instead of "...UML languatge..."


p. 537, PrimitiveTypes, first paragraph:
"These include primitive types..." instead of "These includes prmitive types..."


p. 587, paragraph below fig. 460, last line:
"..., the heading is..." instead of "..., the headning is..."


Resolution: see above
Revised Text:
Actions taken:
September 2, 2003: received issue
March 8, 2005: closed issue

Discussion:
I have verified each of these items, and they are indeed valid recommendations.
The proposed resolution is to make the text changes exactly as cited in the issue
text with the exception of the item identified as:
p. 110, Description:
First and second paragraph are the same.
The problem is not that the two paragraphs are the same since they are slightly
different, but that the first of the two paragraphs is clearly a corrected version of
the second, which contains several typing and spelling errors. Therefore, the
recommended action on this item is to remove the second paragraph.


Issue 6165: UML Superstructure 03-08-02: Loop node notation missing (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
The notation for the loop node on page 341 is missing.
I saw the notation in an older version of the specification

Resolution: Same as Issue 6071
Revised Text:
Actions taken:
September 2, 2003: received issue
December 2, 2004: closed issue

Issue 6166: Notation mismatch for the realization dependency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
The notation for the realization dependency is described on p. 110:
"A Realization dependency is shown as a dependency with the keyword <<realize>>
attached to it."


On p. 130 the Realization dependency is shown as a dashed line with
a hollow triangle as an arrowhead.

Resolution: see above
Revised Text:
Actions taken:
September 2, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is another view of the same problem as 6174
Rectify this by changing the notation section, which currently reads as follows:
Notation
A Realization dependency is shown as a dependency with the keyword «realize» attached to it.
Revise this text so it shall read:
Notation
A Realization dependency is shown as a dependency with the keyword «realize» attached to it, or
alternatively with a dashed line with an open triangular arrowhead at the supplier end of the relationship.


Issue 6167: No notation defined for suppressing attributes or operations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity:
Summary:
There is a mention that attributes and operations may be supressed for clarity, but no mention as to how. In UML 1.4 this was shown by including '...' in the compartment, to indicate that there was more information. Is this still viable?


Resolution: see above
Revised Text:
Actions taken:
September 2, 2003: received issue
March 8, 2005: closed issue

Discussion:
The ellipses notation for suppression has a long-standing tradition in the UML notation
and should not be eliminated. However, there are numerous tools and textbooks that have
not supported this convention, so the best solution is to make it a presentation option.
Superstructure resolution:
?? In the PresentationsOption section of the Feature metaclass on page 73, add the
following text at the end:
An ellipsis (…) as the final element of a list of features indicates that additional features exist but are
not shown in that list.
Infrastructure resolution:
The Infrastructure does not have a defined notation for Feature. This may be an issue
with the Infrastructure, but tha t should be raised as a separate Infrastructure issue


Issue 6168: 7.3.1 ElementImport (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The next to last sentence states: "A member may be further imported by other namespaces using element or member imports." What are member imports? Should this be package imports?

Notation

The difference between public import using <<import>> and private import using <<access>> is not explicitly stated, nor is an example of <<access>> given in the Examples part. My understanding is that <<import>> adds an element to importing namespace using public visibility, i.e., the imported element can be accessed without qualification within the importing namespace and any namespace the importing namespace encloses. My understanding of <<access>> is that it adds an element to the importing namespace using private visibility which does not allow the imported element to be further imported. Does the last sentence of the Description, "It is also possible to control whether the imported element can be further imported", refer to <<access>> element import?


Resolution: see above
Revised Text:
Actions taken:
September 3, 2003: received issue
March 8, 2005: closed issue

Discussion:
There is some residual confusion regarding "member import" between the UML2
Superstructure FAS (ptc/03-08-02) and Infrastructure FAS (ptc/03-09-15). The only
definition of "member import" I can find is in the first paragraph of the Notation
subsection of PackageImport (section 11.6.5) on page 145 of the InfraFAS. This suspect
paragraph appears to say the same thing as the immediately following paragraph and has
no corresponding paragraph in the SuperFAS. The following paragraph and its
corresponding paragraph in the SuperFAS refer to "package import" rather than "member
import". Consequently, the following changes are suggested to replace uses of "member
import" with "package import":
1. Delete the first paragraph of the Notation subsection appearing on page 145 of the
UML2 Infrastructure FAS (ptc/03-09-15).
2. Replace the word "member" with "package" in the sentence "An imported
element can be further imported by other namespaces using either or member
imports." appearing in the following locations:
?? Semantics subsection, ElementImport (section 7.3.1), page 32, UML2
Superstructure FAS (ptc/03-08-02).
?? Semantics subsection, ElementImport (section 11.6.1), page 140, UML2
Infrastructure FAS (ptc/03-09-15). The meaning of <<access>> is not explicitly stated in the ElementImport section of either
document (although it is described in the PackageImport section of both documents).
The following changes are proposed to fix this oversight:
1. Replace the phrase "otherwise the key-word <<access>> is shown" with
"otherwise the key-word <<access>> is shown to indicate private visibility" in
the following locations:
?? First paragraph, Notation subsection, ElementImport (section 7.3.1),
page 32, UML2 Superstructure FAS (ptc/03-08-02).
?? First paragraph, Notation subsection, ElementImport (section 11.6.1),
page 141, UML2 Infrastructure FAS (ptc/03-09-15).
As for adding <<access>> to the Examples section, a straightforward solution is
encapsulated in the following changes:
2. Add an element named "<<datatype>> String" to the Types package and a
dashed, open-headed arrow from Program to the new String element labelled
"<<access>>" in Figure 7, page 33, of the UML2 Superstructure FAS (ptc/03-
08-02).
3. Append the following sentence to the end of the first paragraph of the
Examples subsection on page 33 of the UML2 Superstructure FAS (ptc/03-08-
02): "Type String can be used in the Program package but cannot be further
imported from Program to other packages."
4. Add an element named "<<datatype>> String" to the Types package and a
dashed, open-headed arrow from Program to the new String element labelled
"<<access>>" in Figure 90, page 141, of the UML2 Superstructure FAS
(ptc/03-08-02).
5. Append the following sentence to the end of the first paragraph of the
Examples subsection on page 141 of the UML2 Infrastructure FAS (ptc/03-
09-15): "Type String can be used in the Program package but cannot be
further imported from Program to other packages."
Finally, to answer the question regarding the last sentence of the Description subsection -
- Yes, it does refer to <<access>>.
However, it seems unreasonable to explicitly say so in the Description subsection text
because the <<access>> label is properly addressed in the Notation subsection. The
Description subsection is merely referencing the capability, not the syntax.


Issue 6169: 7.4.1 Multiplicity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Presentation Options

The BNF for the syntax for the multiplicity string seems to have a couple of things wrong. First, the 'lower' is specified as an 'integer' whereas it is specified to be unlimited natural from Notation part. Second, it does not allow for multiplicities to include a uniqueness designation. The first sentence defining the 'multiplicity' non-terminal only contains <order_designator> and does not include <uniqueness-designator>.  Also, if both a uniqueness designation and order designation are specified the BNF should probably specify a delimiter (as in Figure 11). Perhaps the following:

multiplicity ::= <multiplicity_range> [ '{' <order_designator> | <uniqueness_designator> | {<order_designator> ',' <uniqueness_designator>} '}' ]

In addition, the multiplicity specification for Purchase is different between Figure 11 and 12, the former uses a comma to separate ordered and unique and the latter seems to be missing the comma.


Resolution: see above
Revised Text:
Actions taken:
September 3, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issue of the correct BNF for Multiplicity is addressed by the resolution to issue 7135.
The issuer is incorrect in saying that the Notation part says that lower is specified as an
unlimited integer (see text at the bottom of page 42, which explicitly says that lower is an
integer).
There is indeed an error in Figure 12 that should be corrected as follows:
Superstructure resolution:
?? In figure 12 on page 43 add a comma to the constraint on Customer::purchase right
after the “ordered” keyword.
Infrastructure re solution:
?? In figure 44 on page 74 add a comma to the constraint on Customer::purchase right
after the “ordered” keyword.


Issue 6170: InstanceSpecification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Notation

The first paragraph indicates that both the instance name and the classifier can be omitted from an instance specification. This informal description leads open the possibility of specifying just the colon with neither the instance name nor the classifier. Is this what is intended? BNF should be used to clarify.
 

Resolution: This is a more detailed version of Issue 6160.
Revised Text:
Actions taken:
September 3, 2003: received issue
December 2, 2004: closed issue

Issue 6171: 7.10.1 Operation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Semantics

The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added).

Notation

BNF should be used for specifying the syntax of an operation string.


Resolution: see above
Revised Text:
Actions taken:
September 3, 2003: received issue
March 8, 2005: closed issue

Discussion:
The point is well taken that in jobs like specifying a C++ program, the parameter types
and preconditions must not change at random as one goes down a hierarchy of userdefined
types, so some language is in order to acknowlege the issue. An insertion of two
sentences is proposed. The UML spec does not provide instruction on how to specify a
well-designed hierarchy for any particular programming language, nor take sides in
discussions regarding covariance and contravariance and design-by-contract, but notes
this as a semantic variation point.
The Notation -- BNF part of this issue is a duplicate.
insert new text in at the end of Section 7.10.1 Operation after:
Inserted Text:
When operations are redefined in a specialization, rules regarding invariance, covariance, or
contravariance of types and preconditions determine whether the specialized classifier is
substitutable for its more general parent. Such rules constitute semantic variation points with
respect to redefinition of operations.


Issue 6172: 7.11.2 Association (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Notation

I cannot find where the hollow diamond notation for aggregation is specified. It is shown in Table 5 but specified in the body. Is this now called 'shared' aggregation?

The second to last sentence states;" The notation for an attribute can be applied to a navigable association end name." By full notation is it meant the full attribute syntax specified in section 7.81. Classifier under Notation part can be used? This would allow redundant specification of multiplicity. Should it be stated that if attribute notation is used, then other types of association end adornments cannot be used?


Resolution: see above
Revised Text:
Actions taken:
September 3, 2003: received issue
March 8, 2005: closed issue

Discussion:
A careful search confirms that not only could Mr. Culbertson "not find" it, there is in fact
no mention of the open diamond for shared aggregation.
Fix this in section 7.11.2, in the subsection on Notation (which begins at pagenum 82 as
printed at the bottom of the page and continues through page 83).
Find the following text in the current document, and change it as explained next
Text currently:
A composite aggregation is shown using the same notation as a binary association, but
with a solid, filled diamond at the aggregate end.
Text with correction applied
An association with aggregationKind = shared differs in notation from binary
associations in adding a hollow diamond as a terminal adornment at the aggregate
end of the association line. An association with aggregationKind = composite
likewise has a diamond at the aggregate end, but differs in having the diamond
filled in.


Issue 6173: 7.14.1 Abstraction (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Examples

The dependency arrow should be reversed in Figure 52.  The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation.


Resolution: see above
Revised Text:
Actions taken:
September 3, 2003: received issue
March 8, 2005: closed issue

Discussion:
The Figure 52 in question is on page 108 of the FAS as printed, page 123 in the
electronic pdf pagination, at the end of section 7.14.1 Abstraction. This figure shows a
dashed arrow with a stereotype <<refine>> pointing from the Employee, stereotyped as
<<type>> as client to the Employee Record, stereotyped as <<implemention class>> as
supplier.
Remove the example figure 52. Do not replace, reposition it or fix it.
The context for this resolution includes the definition of the client and supplier roles in a
directed dependency. That definition states that the choice of client and supplier can be
stipulated by the modeler, and is not predetermined by a standard semantic for
dependency. In fact, the FAS goes so far as to say that the choice of direction “doesn’t
matter”.
We (various members of the FTF) have tried to come up with a better example, and
found that it is difficult to agree on a good one, because in fact clever people can think of
some respects in which A is dependent on B, and also other respects in which B is
dependent on A, for the same A and B.
The authors of this proposed resolution agree (in part) with Mr. Arthur Culbertson about
this figure. We too would have put the EmployeeRecord in the role of that which refines
and depends upon the type Employee. The fact that the original author of this example
had it the other way around proves the point that the choice of direction can be an
arbitrary stipulation of the modeler, and in that case there is NOTHING to be gained by
putting in an example.


Issue 6174: 7.14.6 Realization (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The notation of a dashed arrow with hollow arrow head at the supplier is not mentioned. However, Table 5 shows this notation.


Resolution: duplicate
Revised Text:
Actions taken:
September 3, 2003: received issue
December 2, 2004: closed issue

Discussion:
This is another view of the same problem as 6166.
It is likely the authors of the spec sometimes interpret realization as being essentially the
Java "implements" many-to-one relationship of concrete classes to a Java interface,
which is in UML 1 was annotated with the dashed line and open triangle arrowhead, and
at other times are thinking more generally in terms of sets of elements being realizations
of other sets of elements as suppliers.
Disposition: Duplicate


Issue 6175: 7.15.3 Interface (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: SSA (Mr. Arthur Culbertson, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Presentation Option

In Figure 62 the relationship between TheftAlarm and ISensor should be a dependency relationship (dashed arrow) with the <<use>> stereotype rather than a unidirectional association. The relationship between ProximitySensor and ISensor should be an implementation relationship (probably same as realization consisting of dashed arrow with open arrowhead) rather than a generalization relationship (Table 5).

Figure 63 shows attribute visibility notation for non-navigable association ends. The second from last sentence in section 7.11.2 Association under the Notation part indicates that attribute notation can only be applied to a navigable association end name.

Resolution:
Revised Text:
Actions taken:
September 3, 2003: received issue
March 9, 2005: closed issue

Discussion:
Wirh respect to Figure 62, this Duplicates Issues 6069
With respect to Figure 63, this is a misunderstanding. The diagram shows visibility
adornments on association ends and on operation features. This is a valid use of this
notation; in fact, the referenced statement in section 7.11.2 actually states that it is legal
to use the attribute notation (including visibility adornments) on association end names.
Disposition: Closed, no change


Issue 6177: UML 2 Super/Metamodel::BasicBehaviors/package merge issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of  :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
According to the instructions of defining packages, when a metaclass C was used in a
package P but not modified in P, where C was defined in Q and P merges Q, the class
Q::C is used. This style is used throughout the specification.
Disposition: Closed, no change


Issue 6178: BehaviorStateMachines/missing owningState end name (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package BehaviorStateMachines has association :State[0..1] c-> stateInvariant: Kernel::Constraint[0..1] is missing the owningState end name as defined in ProtocolStateMachines owningState:State[0..1] c-> stateInvariant: Kernel::Constraint[0..1] 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is an error in the metamodel, it does not appear in the actual spec. The fix
requires that the role name Constraint::owningState : State be removed in the
XMI (i.e., in the metamodel).


Issue 6179: UML 2 Super/Metamodel::IntermediateActivities/redundant merge error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 175: Remove dependency between IntermediateActivities and
StructuredActivities.


Issue 6180: UML 2 Super/Metamodel::Communications/redundant merge error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Redundant merge error: IntermediateActivities should not merge both StructuredActivities and BasicActivities as StructuredActivities already merges BasicActivities. IntermediateActivities both merges BasicActivities and explicitly references types in it (:Clause[0..1] -> decider:BasicActivities::OutputPin[0..1]). This makes resolving the type reference for association end named decider ambiguous

Resolution: Duplicate of 7436
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Issue 6181: UML 2 Super/Metamodel::Nodes/redundant merge error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the FAS, the package dependency picture (Fig 123) shows two redundant
packages named Kernel and Dependencies. These should be removed (in the
specification in figure 123, and in the MDL).


Issue 6182: AuxiliaryConstructs::Templates::Operation/extra space (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML::AuxiliaryConstructs::Templates::Operation had a space at the end of the class name. This causes some matching algorithms to fail

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
 This is a problem with the Rose mdl file rather than the spec itself, but it leads to an XMI
problem. The Rose mdl will be modified so that there are no extraneous spaces at the end
of the name for the Operation class.


Issue 6183: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The syntax diagram that shows the association and rolenames that are the
subject of this issue is Figure 40 on page 94 as printed, which is page 108 in the
electronic pdf. The text definition of the association roles is on page 96 as
printed, page 110 in the electronic pdf. Here is the text of the definition
Associations
• ownedLiteral: EnumerationLiteral[*]The ordered set of literals for this Enumeration. Subsets
Element::ownedMember.
Indeed the rolename of the EnumerationLiteral is given in the diagram as “literal”,
it is not documented as a renaming of “ownedLiteral”, yet elsewhere in the model
and the text of the spec, the rolename is “ownedLiteral”.
Note that it subsets “ownedMember”. The point is that there is evidence of a
naming convention such that there should be a prefix “owned”.
There are two ways of fixing this, either we change the name “literal” as it
appears in this diagram 40, to read “ownedLiteral”, or we change the name
“ownedLiteral” as it appears elsewhere to agree with what is in Diagram 40.
There is a convention evident in other names, such as “ownedOperation” which
make it clear that changing the name “literal” to read “ownedLiteral” is the better
choice, since it maintains a consistency in the structure of such rolenames.
The resolution is to change the rolename of EnumerationLiteral, with respect to
the referenced association, in the abstract syntax model.
We shall fix the name in the model so the it reads “ownedLiteral” on the diagram,
so it matches the text and follows the implied naming convention.


Issue 6184: UML 2 Super/Metamodel::Kernel::Packages/missing redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Kernel/Packages has association package:Package <--> ownedClassifier:Type without a redefinition while its ownedType in Basic and Constructs

Resolution: This issue was resolved by the resolution to issue 6918.
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Discussion:


Issue 6185: UML 2 Super/Metamodel::BasicBehaviors/missing redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
BasicBehaviors has association context:BehavioredClassifier[0..1] c-->ownedBehavior:Behavior[0..*]. BehaviorStateMachines has :BehavioredClassifier[0..1] {subsets redefinitionContext} c--> ownedStateMachine: StateMachine[0..*] {redefines ownedBehavior}. StateMachine specializes Behavior thereby inheriting context:BehavioredClassifier. Property redefinitionContext comes from RedefiningElement, but the inherited property context is skipped. Is the role name missing? Should context:Behavior subset redefinitionContext? 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issue correctly points to an omission in the specification. One either (i) could
specialize redefinitionContext as the context of a behavior, or (ii) specialize both context
and redefinitionContext in every concrete behavior. The former is chosen, as this holds
for every classifier and thus, this change fixes a problem that existed also for any of the
other concrete behaviors.
On p.380 of ptc/03-08-02, in Associations for Behavior, add to the association context the
sentence “Specializes RedefinableElement.redefinitionContext.” and update Figure 312
on p. 375 accordingly.
On p.458, Figure 355, delete the association between StateMachine and
BehavioredClassifier, and the symbol for Behaviored classifier. This association is
inherited from Behavior.
On p.490, associations for StateMachine, delete the association redefinitionContext as
this is inherited from Behavior.


Issue 6186: UML 2 Super/Metamodel::Constructs/inconsistency with Kernel (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Constructs has association mergingPackage:Package[1..1] c--> packageMerge:PackageMerge[0..*] while Kernel has mergingPackage:Package[1..1] c--> packageExtension:PackageMerge[0..*] without a renames. Should this be changed to packageMerge to be consistent with Constructs? 

Resolution: Resolved as part of the resolution to issue 6918.
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Issue 6188: UML 2 Super/Metamodel/merging of non-redefinable model elements (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Model elements, like Constraint, that are not RedefinableElements are always copied from the merged model element to the merging model element. When a package like Kernel is merged into many packages which are then in turn merged into another common package, these non-redefinable elements are copied down multiple times in the leaf merging package. For example, L3::Classifier has a large number of ownedRules named general_equals_parent which it gets from Dependencies::Classifier. Dependencies is merged into Kernel which is merged into many packages in Superstructure. Perhaps a Constraint should be a RedefinableElement, or package merge should only copy down these elements once

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The new package merge rules as specified in the resolution to issue 6279 handle this case
by specifying that two elements that are equal are (in effect) not merged, thereby
avoiding multiple copies of an element that is merged more than once.


Issue 6189: UML 2 Super/Metamodel/package merge and visibility (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The package merge rules say that private elements from the merged package are not merged into the merging package. However, this can result in inconsistencies if for example, an association is public but its ends are private. And it would not work at all for define merge since the merged types are not retained. The merge implementation currently ignores visibility

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issue is resolved by the resolution to issue 6279, which removes the restriction on
merging of private elements.


Issue 6190: UML 2 Infra/Section 5.9/missing merge rules (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML2 Infrastructure specification says in section 5.9 Packages Diagram, under Package Merge Semantics: "If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve conflicts." These rules don't appear to be defined anywhere. RedefinableElement indicates one redefining element may redefine multiple inherited redefinable elements.

Clean Model Rule 8 says "An attrubute must be explicitly redefined in any cases where more than one attribute of the same name would be inherited from different superclasses, unless one of them already redefines the other." Rule 7 says "Attribute redefinition will be done by redeclaring an attribute in the subclass with the same name." This means that a redefinition in a subclass redefines all the inherited properties of the same name in all superclasses, and hides those inherited properties in the subclass. However, no common OO language supportes these semantics.

As a result, performing the transformation specified by package merge semantics on UML2 Superstructure results in many name collisions caused by multiple inheritance of merged classes. This causes problems for XMI Schema and Java API generation. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The new package merge rules defined in the resolution of 6279 avoid this problem by
explicitly specifying the pre-conditions for valid package merge operations and the merge
transformation rules for the valid combinations of feature characteristics.
The more general issue of dealing with redefinition in the case of OO languages that do
not support it will not change, since redefinition is here to stay in UML. However, it can
be easily disallowed when working with such languages by defining appropriate profiles.


Issue 6191: UML 2 Super/Package Merge/redefinition rules and standard OO languages (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around.

A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute."

This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The appropriate constraints and transformation rules for this case are now spelled out in
the resolution to issue 6279. The result of merging a derived and a non-derived feature is
always a derived feature, which deals with the case above. Similarly, the result of
merging two matching features with different visibilities is always public visibility.
However, although this solves the immediate problem of providing a way of dealing with
this situation, the more general issue of dealing with redefinition in the case of OO
languages that do not support it will not change, since redefinition is here to stay in UML.
However, it can be easily disallowed when working with such languages by defining
appropriate profiles.


Issue 6192: UML 2 Super/Metamodel::StructuredClasses/erroneous association (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package StructuredClasses contains class Class and an association +:Class -->+ownedAttribute:InternalStructures::Property which does not appear on any diagram. This association does not match the similar one in Constructs:  +class:Class <-->+ownedAttribute:Property  because it is missing an end name and navigability in both directions. It is not clear if this was intended to constrain the Constructs association so that a property does not know the class that contains it, or if the association was meant to be deleted. It cannot simply be corrected by adding the missing end and making it navigable in both directions as this would result in Property having two properties called class. Either the association should be removed, or StructuredClasses needs to redefine Property instead of referencing it directly from InternalStructures

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Delete the association from the mdl file. Note that this association is not shown in the
specification text.


Issue 6193: UML 2 Super/Metamodel::BasicActivities/inGroup problem (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
BasicActivities has edgeContents:ActivityEdge <--> inGroup:ActivityGroup. CompleteActivities has edgeContents:ActivityEdge {redefines edgeContents} <--> inGroup:InterruptibleActivityRegion {subsets inGroup}.  inGroup ends up redefining and subsetting the inherited inGroup Should this have been interruptingEdge:ActivityEdge {redefines edgeContents} <--> interruptibleRegion:InterruptibleActivityRegion {redefines inGroup} and the other association removed? Or does inGroup need a new name?

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The interrupting edge does not need to be in the interruptible region. It has one end
inside the region and one outside.
Disposition: Closed no change


Issue 6195: UML 2 Super/Metamodel::StructuredActivities/double redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
StructuredActivities has association activity:Activity {redefines activity, redefines activity} <--> structuredNode:StructuredActivityNode. It should only redefine activity once. 


Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The activity end named "activity" is inherited from two parents, so appears twice
in the redefinition.
Disposition: Closed no change


Issue 6196: UML 2 Super/Metamodel::Compliance::L3/Missing merges (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML::Compliance::L3 doesn't merge: InfrastructureLibrary::Profiles, UML::AuxiliaryConstructs.Templates, UML::CompositeStructures.StructuredActivities, UML::Profiles, UML::StateMachines::MaximumOneRegion 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issues is resolved by the resolution to issue 6248, which explicitly merges these
packages, with the exception of MaximumOneRegion, which is removed as a result of
the resolution to issue 7576.


Issue 6198: UML 2 Super/Package Merge/missing rule for operations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Package merge rules do not specify how operations match when being merged, or how they are merged if they do match

Resolution: The appropriate rules for this case are now spelled out in the resolution to issue 6279.
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Issue 6199: Profile/inability to attach a stereotype to an element (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Clarification
Severity:
Summary:
Package Profile does not specify any way to attach a Stereotype to an Element. 

Resolution: This issue is resolved by the solution to issue 6347.
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:


Issue 6202: UML 2 Super/Metamodel::CommonBehaviors/redundant class? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Class UML::CommonBehaviors::Communications::Call is in the model, but does not participate in any associations, is not referenced, and does not appear in any diagrams

Resolution: Delete the above-mentioned class from the mdl file.
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Issue 6203: UML 2 Super/Metamodel::Templates/missing return type (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
OCL operation UML::AuxiliaryConstructs::Templates::TemplateableElement::parameterableElements() is missing a return type

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is a problem in the current metamodel (i.e., in the generated XMI), where the
operation is defined without a return type. However, the operation is also named
differently in the spec as opposed to the metamodel. In the spec, the operation is called
“getParameterableElements” instead of “parameterableElements”. However, it is
generally recommended to avoid using the “get” prefix for operation names, since that
often leads to conflicts with standard naming conventions for accessors. Hence, the
recommended resolution is to:
1. Change the name of the operation in the spec to “parameterableElements” which
implies the following change to the text. Replace the text on page 545 (the first
item in the Additional Operations subsection for TemplateableElement) from:
[1] The query getParameterableElements() returns the set of elements that may be used as the parametered
element for a template parameter if this templateable element. By default this set includes all the owned
elements. Subclasses may override this operation if they choose to restrict the set of parameterable
elements.
TemplateableElement::getParameterableElements() : Set(ParameterableElement);
getParameterableElements = allOwnedElements ->select(oclIsKindOf(ParameterableElement))
to
[1] The query parameterableElements() returns the set of elements that may be used as the parametered
elements for a template parameter of this templateable element. By default, this set includes all the owned
elements. Subclasses may override this operation if they choose to restrict the set of parameterable
elements.
TemplateableElement::parameterableElements() : Set(ParameterableElement);
parameterableElements = allOwnedElements ->select(oclIsKindOf(ParameterableElement))
2. In the metamodel, for the class TempateableElement add a
“Set(Parameterable Element)” return type to the operation
“parameterableElement()”.


Issue 6204: UML 2 Super/Metamodel/Mis-named Manifestation class (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The name of class Manisfestation is misspelled; it should be "Manifestation"

Resolution: Correct the typo in figure 124 FAS.
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Issue 6205: UML 2 Super/Metamodel/mis-spelled implementingClassifier" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The name of property Implementation::implementatingClassifier is misspelled; it should be "implementingClassifier".

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Rename Implementation::implementatingClassifier to ‘implementingClassifier’
and replace figure 58 with the following figure:


Issue 6206: UML 2 Super/Metamodel/missing owners for metaclasses (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The following types don't have obvious owners: 

AnyTrigger 
CallTrigger 
ChangeTrigger 
InformationFlow 
PrimitiveFunction 
SignalTrigger 
TimeTrigger

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
On the diagram in Fig. 317 “Triggers” add a metaclass BehavioredClassifier, and
an ownership association from BehavioredClassifier to Trigger. Multiplicities are
0..1 at the diamond, and * at the arrow end (pointing at Trigger). The label at the
arrow is ownedTrigger (this subsets ownedMember).
In the association section of BehavioredClassifier (p. 383 of ad/03-08-02) add
ownedTrigger: Trigger References trigger descriptions owned by a
clasifier. (Specializes Namespace.ownedMember.)


Issue 6207: UML 2 Super/Metamodel/missing namespaces for metaclasses (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The following types don't have obvious namespaces: 

ActivityPartition 
ConnectionPointReference 
Duration 
InstanceValue 
Interval 
LiteralBoolean 
LiteralInteger 
LiteralNull 
LiteralString 
LiteralUnlimitedNatural 
OpaqueExpression 
Pesudostate 
State 
TimeExpression 
Transition 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The following of these are kinds of ValueSpecification:
??Duration
??InstanceValue
??Interval
??LiteralBoolean
??LiteralInteger
??LiteralNull
??LiteralString   ??LiteralUnlimitednatural
??OpaqueExpression
??TimeExpression
By making ValueSpecification a kind of PackageableElement, they will automatically
become ownedMembers of a package, which is a kind of namespace. Therefore, the
resolution for these elements is based simply on making ValueSpecification inherit from
PackageableElement.
For the following elements:
??State (a kind of Vertex owned by a Region)
??Transition
??Pseudostate (a kind of Vertex owned by a Region)
it is sufficient to make Region a kind of namespace. However, for entry and exit points
owned by a state, it is necessary to make State also a kind of Namespace.
For ConnectionPointReference, no change is necessary, since they already belong to a
StateMachine, which is a kind of Behavior, which is a namespace. The same logic applies
to ActivityPartition, which is a kind of ActivityGroup, which, in turn, is owned by an
Activity that represents their namespace (Activity is also a kind of Behavior).
Therefore, the following changes need to be made:
Resolution for Infrastructure (ptc/03-09-15)
In figure 72 on page 109, add PackageableElement as a superclass of ValueSpecification.
Resolution for Superstructure (ptc/03-08-02)
??In figure 13 on page 45, add PackageableElement as a superclass of
ValueSpecification.
??In Figure 354 on page 457:
?? replace the generalization from Region to NamedElement by a
generalization from Region to Namespace
?? add a generalization from State to Namespace
?? change the constraint on Region::subvertex from “subsets ownedElement”
to “subsets ownedMember”
?? change the constraint on Transition::container from “redefines owner” to
“subsets namespace”
?? change the constraint on Vertex::container from “redefines owner” to
“subsets namespace”
?? change the constraint on State::connection from “subsets ownedElement”
to “subsets ownedMember” ?? add an association end name “state” on composition from State to
ConnectionPointreference on State end with a constraint of {subsets
namespace}
?? add a constraint on State::region: {subsets ownedMember}
?? add an association end name “state” on composition from State to Region
on State end with a constraint of {subsets namespace}
Note that the latter also provides a solution to issue 7323.


Issue 6208: UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Properties UseCase::extend and UseCase::include subset property Namespace::ownedMember, but classes Extend and Include are not types of NamedElement

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is an oversight. Both Extend and Include should also be made subclasses of
NamedElement as shown in the new version of Figure 401 below. The following changes
need to be made:
?? Figure 401 (changes indicated using a red pen): ?? Pg. 515 (added text indicated by underlining):  It is a kind of DirectedRelationship, such that the source is the extending use case and the
destination is the extended use case. It is also a kind of NamedElement so that it can have a name
in the context of its owning use case.
?? Pg. 518 (added text indicated by underlining):
Include is a kind of DirectedRelationship between two use cases, implying that
the behavior of the included use case is inserted into the behavior of the including
use case. It is also a kind of NamedElement so that it can have a name in the
context of its owning use case.


Issue 6209: ProtocolStateMachines/ProtocolStateMachine not a type of Feature (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Property Interface::protocol subsets property Classifier::feature, but class ProtocolStateMachine is not a type of Feature

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The abstract syntax in figure 356 on page 458 must be modified such that
Interface::protocol does not subset feature but only ownedMember


Issue 6210: UML 2 Super/Metamodel/missing source and target for InformationFlow (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Class InformationFlow specifies neither its source(s) nor its target(s). 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Fixed in the metamodel proposed for issue 6351, by adding the specifications of the
source and target associations.


Issue 6211: UML 2 Super/Spec/completing mandatory sections (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The new OMG document structure requires certain mandatory sections (Scope, Confromance, Normative References, Terms and Definitions, and Symbols). Since these sections were not in the original submissions spec (or at least not in the form expected by the new OMG document structure), they need to be completed by the FTF. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
?? On page 1, in section 1 remove the entire paragraph titled “Editorial Comment” in
section 1 (last paragraph)
?? On page 1, in section 2 remove the entire paragraph titled “Editorial Comment”
(first paragraph)
?? On page 3, in section 3 remove the entire paragraph titled “Editorial Comment”
(last paragraph)
?? On page 4, in section 4, replace the paragraph titled “Editorial Comment” with the
following paragraph:
There are no formal definitions in this specification that are taken from other
documents.
?? Remove the entire glossary from section 4.
?? On page 18, in section 5, replace the paragraph titled “Editorial Comment” with
the following paragraph:
There are no symbols defined in this specification.


Issue 6212: UML 2 Super/pg.78/operation redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 78 Operation/Constraints:  Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The text quoted in the issue report is misquoted. The actual text is part of a condition,
not a categorical assertion of what “must” conform, the complete context is as follows:
The problem is with the query name “isConsistentWith” it is too strong, it implies this
query provides all the consistency one might need in constructing a properly substitutable
hierarchy of behaviored classifiers, and the issue is correct in observing that there are
different views on consistency: there is a lot more to it than covariant type conformance.
Two solutions seem available. 1. Rename the query to “isCovariantWith” 2. A
disclaimer in the text to block this misreading of the query name. We propose taking the
second solution.
Original Text:
The query isConsistentWith() specifies, for any two Operations in a context in which
redefinition is possible, whether redefinition would be logically consistent.
Revised Text:
The query isConsistentWith() specifies, for any two Operations in a context in which redefinition
is possible, whether redefinition would be consistent in the sense of maintaining type covariance.
Other senses of consistency may be required, for example to determine consistency in the sense of
contravariance. Users may define alternative queries under names different from
‘isConsistentWith()’, as for example, users may define a query named ‘isContravariantWith()’.


Issue 6213: UML 2 Super/pg.78/missing return types syntax (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
78 Operation/Notation:  Syntax for operation omits the return types 


Resolution: This is the same as issue 5951 and has been solved by the resolution to issue 7315.
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Issue 6214: UML 2 Super/pg.79/underlined operation syntax missing (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 79 Operation/Notation:   Syntax for operation does not show underlining but example does show it.

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The notational rule for underlining class- level features is described on page 73 in the
Notation section of Feature, the parent of Operation.
Disposition: Closed, no change


Issue 6215: UML 2 Super/pg.64/Classifier redefinition notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a <redefines> statement 


Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Agreed. Replace the text on page 64 and also in the Infrastructure. There is
another problem here also, the point is not specific to attributes alone, but to any
redefinable element that is redefined in the context of a generalization hierarchy.
Therefore generalize the verbiage beyond "attribute" to redefinable element
The relevant text on page 64 of Superstructure and 121 of Infrastructure is:
New Text: in both Super and Infra
All redefinitions shall be made explicit with the use of a {redefines <x> } property string.
Redefinition prevents inheritance of a redefined element into the redefinition context, thereby
making the name of the redefined element available for reuse, either for the redefining element, or
for some other.


Issue 6217: UML 2 Super/pg.95/attributes in data types clarification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Clarification
Severity:
Summary:
pg. 95: DataType::ownedAttribute – is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The UML2 Superstructure (ptc/03-08-02, section 7.12.1, page 95) and UML2
Infrastructure (ptc/03-09-15, section 11.5.1, page 133-134) specifications already indicate
that Datatypes may optionally be record types, but do not explicitly call them such. The
text reads “A DataType may also contain attributes to support modeling of structured
data types” and “If a data type has attributes, then instances of that data type will contain
attribute values matching the attributes.”
Disposition: Closed, no change


Issue 6218: UML 2 Super/pg.109/Permission redundant (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 109: Permission – this used to be a superclass of access and import. Doesn't serve a useful purpose otherwise. It now seems to be a useless relict. Get rid of it. There is no need to give "permission" to access another element—the fact of the access itself means that you meant to do it. Giving "permission" is more of a tool thing to prevent errors, not a modeling thing.  In any case, it now seems obsolete. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Agreed. For reference, here is the summary from the current spec.
7.14.5 Permission (from Dependencies)
Description
A Permission signifies granting of access rights from the supplier model element to a client model
element. Or to put it another way, it signifies that the client requires access to some or all of the
constituent elements of the supplier. The supplier element gives the client permission to access
some or all of its constituents elements.
A search for <<permit>> as a stereotype indicates that although stipulated in 7.14.5, it
never made it into the standard stereotype appendix. The standard stereotypes of UML
1.4 and 1.5 for permission were <<access>> and <<friend>>, and these are already in the
spec cited as obsolete (see page 598 as printed, Table 28 - Retired standard elements which is
a further indication that Permission was left in the metamodel by mistake.
Resolution:
Remove the entire section 7.14.5 Permission including all its subsections, and renumber
the subsequent 7.14 sections, . Also remove the Permission metaclass from the
metamodel. Permission appears in Figure 51 of the FAS, so that Figure must be revised.
Disposition: Resolved


Issue 6219: UML 2 Super/pg.99/misnamed "packageMerge" attribute (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 99: Packages Diagram – association to PackageMerge should be called packageMerge, not packageExtension (as in text on pg. 100) 

Resolution: This is addressed by the proposed resolution to Issue 6190
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Issue 6220: UML 2 Super/pg.130/missing notation explanation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 130: Realization/Notation –dashed generalization notation is not mentioned, but it is shown in the chart on pg. 130. Add it to the text

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Actually, the problem is slightly different than stated. The problem is that in UML 2.0,
the concept of Realization – which was always denoted by a dashed line with a triangular
arrowhead – has been refined for the special case when a BehavioredClassifier realizes an
Interface.
However, on page 110, it is stated that a Realization is now denoted by a regular dashed
line with an open (stick) arrowhead and the keyword “realize” attached to it. This is a
gratuitous change that is likely to cause confusion and has no justification. Hence, this
resolution proposes to retain the existing dashed-line-triangular-arrowhead notation for
Realization.
What should the notation for Implementation be then? One possibility is to retain the
currently proposed notation but simply add the “implements” keyword. However, this
adds yet another keyword that is likely to be confused with other situations. Hence, the
proposal here is to retain the same notation for Realization and Implementation: the
dashed line with the triangular arrowhead. (Tools can automatically decide which one to
use depending on the source and target elements., or it could leave the choice to the
user.)
The following changes need to be made to support this:
?? On page 110 in the Notation section of Realization replace the existing sentence by
the following sentence and figure:
“A Realization dependency is shown as a dashed line with a triangular arrowhead at
the end that corresponds to the realized element. Figure 52, illustrates an example in
which a Business class is realized by a combination of an Owner and Employee
classes.” Figure 52 – Notation for a realization dependency
?? On page 130 in Table 4, add another entry to the table for Implementation between
the entry for Generalization and the entry for Realization. This entry will have the
Path Type equal to “Implementation”, the Notation that is the same as the notation for
Realization, and the Reference:
“See “Implementation (from Interfaces)” on page 113.


Issue 6221: UML 2 Super/pg.130/incorrect stereotype name (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 130: – private package import shown as «use» in chart, but should be «access» according to previous text for private import 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Table 4, page 130, section 7.18, of the UML2 Superstructure FAS (ptc/03-08-
02), change the text “<<use>>” to “<<access>” in the Notation column of the row
with Path Type column value of “PackageImport (private)”.
The UML2 Infrastructure FAS (ptc/03-09-15) does not contain a corresponding
table and consequently requires no change.


Issue 6222: UML 2 Super/pg.235/missing semantics of destroy action (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 235: DestroyAction: Must destroy links involving the object, at least, as they no longer have valid referents after the destruction. This is needed even if parts are not destroyed automatically. It is part of the essential semantics of links and objects, not an optional semantic variation point (as automatic part destruction is).

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 144, add the following attributes to DestroyObjectAction:
isDestroyLinks : Boolean = false
isDestroyOwned : Boolean = false
as shown (with change from 6491, and consolidated layout):  Under the DestroyObjectAction class,
In Attributes section, add:
isDestroyLinks : Boolean = false Specifies whether links in which
the object participates are destroyed along with the object. Default
value is false.
isDestroyOwnedObjects : Boolean = false Specifies whether object
owned by the object are destroyed along with the object. Default
value is false.
In Semantics section:
In the second sentence, add the word "default" before "action".
In the first paragraph, add a new sentence at the end:
"If isDestroyLinks is true, links in which the object participates are
destroyed along with the object according to the semantics of
DestroyLinkAction, except for link objects, which are destroyed
according to the semantics of DestroyObjectAction with the same
attribute values as the original DestroyObjectAction. If
isDestroyOwnedObjects is true, objects owned by the object are
destroyed according to the semantics of DestroyObjectAction with
the same attribute values as the original DestroyObjectAction."



Issue 6223: UML 2 Super/pg.395/multiple meaning of exception (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages.  Eliminate all references to it as a kind of signal, otherwise much confusion will ensue. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The submitter is correct in pointing out that UML 2.0 added a powerful exception
handling mechanism. In general, an exception is any object, not necessarily a signal
instance. However, if there are still remnants of the original mechanisms left in the text
accidentally, these should be adjusted appropriately:
In the glossary, p.8, change the first sentence to: “An object typically used to indicate
fault situations.”
On p.376, Figure 316 “Extensions to behavioral features and signal”, delete the symbol
for Signal. Have the association BehavioralFeature.raisedException go to Classifier.
Move Signal.ownedAttribute and the attached Property to Figure 315.
On p.376, Figure 315 “Reception”, add Signal.ownedAttribute, as currently shown in
Figure 316.
On p.382, class BehavioralFeature, change type of association raisedException to
Classifier. Change the text to “The classifier that the behavioral feature…”.
On p.395, delete the last sentence in the Semantics section for class Signal.


Issue 6224: UML 2 Super/pg.416/incorrect multiplicities for event occurrence (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 416: Associations EventOccurrence::startExec and finishExec should have multiplicity * as in figure 328 on pg.407

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change the multiplicity of EventOccurrence::startExec and of EventOccurrence::
finishExec to “*”.


Issue 6225: UML 2 Super/pg.429/incorrect constraint for Message (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 429: Message/Constraint 5: It says that relations sendEvent and receiveEvent are mutually exclusive.  The rest of the entry suggests that they are normally both present. The constraint appears erroneous

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Remove Message/Constraint 5 on page 429:
[5] Relations sendEvent and receiveEvent are mutually exclusive.


Issue 6226: UML 2 Super/pg.427/missing notation description for lifelines (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 427: Lifeline/Notation—need to add text stating that multiple activation rectangles (overlapped and offset) may be used to represent recursion. This shows in some examples but not in the text. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Actually, this should be part of the Notation subsection for ExecutionOccurrence (instead
of Lifeline). The following changes need to be made:
1. Include the following diagram in the Notation subection of ExecutionOccurrence on
page 418.
sd overlap
cc:C aa:A
oper1()
callback()
Figure 337. Overlapping execution occurrences
2. Add the following sentence as the last paragraph of the Notation subsection of
ExecutionOccurrence on page 418, just before the figure above:
Overlapping execution occurrences on the same lifeline are represented by overlapping rectangles as
shown in Figure 337.


Issue 6227: UML 2 Super/pg.519/multiplicity semantics of use case associations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 519: UseCase – semantics of multiplicity on Actor-UseCase association not explained. State what the multiplicity means and show an example

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
?? On page 520 add the following paragraph at the end of the Semantics section for
the UseCase metaclass:
When a use case has an association to an actor with a multiplicity that is greater than one at the actor
end, it means that more than one actor instance is involved in initiating the use case. The manner
in which multiple actors participate in the use case depends on the specific situation on hand and
is not defined in this specification. For instance, a particular use case might require simultaneous
(concurrent) action by two separate actors (e.g., in launching a nuclear missile) or it might require
complementary and successive actions by the actors (e.g., one actor starting some activity and the
other one stopping it).
?? On page 513 add the following paragraph at the end of the Semantic s section for
the Actor metaclass:
When an actor has an association to a use case with a multiplicity that is greater than one at the use
case end, it means that a given actor can be involved in multiple use cases of that type. The
specific nature of this multiple involvement depends on the case on hand and is not defined in
this specification. Thus, an actor may initiate multiple use cases in parallel (concurrently) or they
may be mutually exclusive in time. For example, a computer user may activate a given software
application multiple times concurrently or at different points in time.


Issue 6228: UML 2 Super/pg.471/unclear terminate state semantics (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 471: PseudoStatel/Semancis terminate – What are the semantics of terminate? Are exit actions performed (to return to the root state) or is the object just killed outright with no clear up? Probably need a SVP. In any case, the wording is too spare. It isn't very useful as it stands with vague semantics.

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The text on pg. 471 for terminate shall be:
Entering a terminate pseudostate implies that the execution of this state machine by
means of its context object is terminated. The state machine does not exit any states or
perform any exit actions other than those explicitly implied by the transition leading to
the terminate state. Entering a terminate pseudostate is equivalent to invoking a
DestroyObjectAction.


Issue 6229: UML 2 Super/pg. 471/choice pseudostate notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 471: PseudoState/Semanctics Choice – The text says the symbol is a diamond but the figure 374 on pg. 473 shows a circle. Probably an error in the figure  but make them consistent. In UML1 it is a diamond so a circle would be a bad idea 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Figure will be modified to show a diamond and not a circle as follows:
id
[<10] [>=10]
[id <10] [id >=10]
Figure 374 - Choice Pseudo State


Issue 6230: UML 2 Super/pg. 556/notation for template binding inconsistency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 556: Classifier (in templates):   Bound collaboration (Fig. 435): Separator should be arrow (->) not backslash (\) to be consistent with text on TemplateBinding on pg. 548 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Replace the contents of the current figure 435 with the following figure (which
replaces the backslashes by a ‘->’ combination) :
Observer
ObserverPattern<SubjectType -> CallQueue, ObserverType -> SlidingBarIcon>


Issue 6231: UML 2 Super/pg.379/anyTrigger clarifications (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 379: AnyTrigger:  It is obviously illegal to have 2 anyTriggers in the same state (but the specification should say that, which it doesn't).  What about multiple anyTriggers in nested states? The specification is silent on this point.  It should probably be allowed with the most specific state taking precedence.  This is a useful situation. Need to define it in any case. 

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The text on AnyTrigger quoted above is incorrect in that it implies that the AnyTrigger is
on a state. In fact, the trigger is on a transition, and the scenario of multiple triggers does
not arise.
Change the Semantics section for AnyTrigger on p.379, ptc/03-08-02 to:
An AnyTrigger on a transition specifies that this transition is triggered for all
applicable message triggers except for those specified explicitly on other
transitions having the same vertex as a source.
Further, the text in the Description section duplicates the text in the semantics. Change
the Description section for AnyTrigger to:
An AnyTrigger causes a transition to be triggered by any message trigger which
is not explicitly referenced in another transition from the same vertex.


Issue 6232: UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
pg. 81: Association: subsetting, generalization, redefining: Just what is the precise difference among subsetting, specialization, and redefining? The explanations are vague and don't offer distinctions or examples showing the difference. They seem to do the same thing. If there is no semantic difference, why do we have them all? This is an important thing to clarify, preferably with examples for each of the possibilities. Other people are confused about this too.

Resolution: see above
Revised Text:
Actions taken:
September 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The relevant text quoted from page 82 Super and 113 Infra
Add new text to follow after the text quoted above in both p 82 and 113.
New text:
Subsetting represents the familiar set-theoretic concept. It is applicable to the
collections represented by association ends, not the association itself. It may
additionally apply to the extents of classifiers generally. The collection
represented by one association end may be a subset of the collection
represented by another association end without being a proper subset. That is to
say, for A to be a subset of B, it is not required that collection B has a member
NOT in A. Proper subsetting implies that the superset is not empty and that the
subset has fewer members; subsetting does not have this implication. Subsetting
is a relationship in the domain of extensional semantics.
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 naïve 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.
Redefinition Redefinition is a relationship between features of classifiers within
a specialization heirarchy. Redefinition may be used to change the definition of a
feature, and thereby introduce a specialized classifier in place of the original
featuring classifier, but this usage is incidental. The difference in domain (that
redefinition applies to features) differentiates redefinition from specialization.


Issue 6233: UML 2 Super/Compliance points/confusing and redundant (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain: 

There is no facility provided to indicate which particular compliance points are assumed in a given model -- hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard. 
The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java. 
Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant. 

This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?). 

Resolution: This is a duplicate of issue 6248.
Revised Text:
Actions taken:
September 7, 2003: received issue
December 2, 2004: closed issue

Issue 6234: UML Superstructure: 03-08-02 / Typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
Some more typos:


p. 191, figure 134
Figure 134 does not show a deployment specification.


p. 194, Manifestation
"A manifestation is the concrete physical unit of one..." instead of "A manifestation is the concrete physical of one..."


p. 200, table 9
The manifestation relationship is shown with a solid line. Notation definition on p. 195 specifies a dashed line.


p. 228, Presentation Option, last line
"...than the operation name,..." instead of "...than the operaiton name,..."


p. 233, CreateObjectAction
The definition is not quite clear. The first constraint says "The classifier cannot be abstract". But
the description says "The semantics is undefined for creating objects from abstract classifiers."
The last one means that abstract classifiers are allowed, but the semantic is undefined. So the constraint
is wrong. On the other hand if the constraint is correct, the sentence about the abstract classifier
is suerfluous.


p. 259, TestIdentifyAction, first line
"...are identical objects." instead of "...are identical objects.t"


p.286, 3rd paragraph from bottom
"An activity with a classifier context..." instead of "An activity with a a classifier context..."


p. 304, Semantics, first line
"When an activity is invoked,.." instead of "When an activity in invoked,..."


p. 355, Examples
"The diagram on the left uses a decision diamond; the one on the left uses parameter sets 
to express the same notion".
Text refers twice to the diagram on the left. The figure 279 does not show what the text describes.


p. 473, below figure 373
"A choice pseudostate is shown as a diamond-shape symbol as exemplified by Figure 374".
Fig. 374 does not show a diamond-shape symbol, but the circle notation.


p. 497, Rationale below figure 394
"The rationale for statemachine extension..." instead of "The rationale for statemachie extension..."

Resolution: see above
Revised Text:
Actions taken:
September 8, 2003: received issue
March 8, 2005: closed issue

Discussion:
?? Pg. 191 figure 134: replace figure 134 with the following diagram:
:AppServer
Order.jar
«artifact»
Orderdesc.xml
«deployment spec»
«deploy»
?? Pg. 190 last sentence on the page, replace the incorrect figure reference:
“…(as in Figure 132)…”
with the correct one:
“…(as in Figure 134)..”
?? Pg. 194 replace the definition of Manifestation (1st sentence in sectin 10.3.10) by
the following sentence:
“A manifestation is the concrete physical rendering of one or more model elements by an artifact.”
?? Table 9 (pages 199 and 200)
o The solid lines seem to happen because of the incorrect mapping from
Visio graphics to Adobe, since the lines are actually drawn as dashed. The
recommendation is to redraw both the Deployment and Manifestation
notation entries in this table using FrameMaker graphics.
o Also, along the way, fix all the invalid page cross-references in the
“References” fields for the Association, Dependency, and Generalization
entries in the table
?? Pg. 228, last sentence of the Presentation Options section of CallOperationAction,
change the word “operaiton” to “operation”.
?? Pg. 233 Description: remove the sentence: “The semantics is undefined for
creating objects from abstract classifiers or from association classes”.
?? Pg. 259, 1st sentence of section 11.3.42: remove the superfluous “t” following the
period at the end of this sentence.
?? Pg. 286 3rd paragraph from the bottom, 1st sentence, replace the phrase:
“…with a a classifier…” with:
“…with a classifier…”
?? Pg. 304 Semantics section of ActivityParameterNode, replace the phrase in the
first line:
“When an activity in invoked…”
with
“When an activity is invoked…”
?? Pg. 355 Examples section:
o remove the second sentence of the first paragraph of this section: “The
diagram on the left uses a decision diamond; the one one the left uses
parameter sets to express the same notion”
o label the currently unlabeled box at the right of the top diagram in figure
279 “Ship Item”.
?? The item flagged on pg. 473 (below figure 373) is resolved by the solution to
issue 6229.
?? Pg. 497 Rationale section of StateMachine first sentence: replace the word
“statemachie” by the word “statemachine”.


Issue 6235: Stereotypes for Actions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I just recognized a change in UML 2.0 from UML 1.x. 
Stereotypes can only be attached to elements derived
from Class. In UML 1.x a stereotype can be attached to
elements based on ModelElement.


Does that mean that I cannot define a stereotype for Actions?

Resolution: This is the same issue as issue 6199
Revised Text:
Actions taken:
September 8, 2003: received issue
December 2, 2004: closed issue

Issue 6236: UML 2.0 serious layout problems with activity diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
In UML 1.x you can draw several outgoing transitions from an action state
with guard conditions. That's semantically equivalent to a decision.
The semantic changes in UML 2.0. Several outgoing edges from an action node
are semantically equivalent to a fork. The new semantic is absolutely ok,
but I have problems with the notation.


Especially in business process modelling it is common that a decision 
follows each action. Now I have to draw a decision node after each action
node. That blows up the diagrams and makes them hard to read. With UML 2 I
need two pages for a diagram that fits on half a page with UML 1.x. 


Is it possible to use a notational shortcut to keep the diagrams small and
readable?
I heard from several people that they think about workarounds for that problem.
But I think that's the wrong way.


Any solutions?

Resolution:
Revised Text:
Actions taken:
September 8, 2003: received issue
March 9, 2005: closed issue

Discussion:
Guards can be used with control edges coming out from an action and the user
can ensure they are mutually exclusive. Object flows edges coming out of pins
are inherently mutually exclusive by competing for tokens, and can also have
guards. However, AcceptEventAction should support multiple triggers to avoid
using decisions with multiple accept event actions, see 7339.
Disposition: Closed, no change


Issue 6237: State list (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no)
Nature: Revision
Severity: Significant
Summary:
Statelist has to be done differently, as transitions outgoing from a junction point cannot have triggers

Resolution: see above
Revised Text:
Actions taken:
September 8, 2003: received issue
March 8, 2005: closed issue

Discussion:
Currently there is a constraint that over-constrains all transitions outgoing pseudostates
not to have triggers. This disables using junctions to factor common paths containing
triggers. This factoring is useful for explicit usage or representing the semantics for the
statelist notation.
In addition, join pseudostates are also commonly followed by transitions with triggers.
Therefore, the proposed resolution is to relax constraint [5] for transitions to exclude
junction and join pseudostates:
[5] Transitions outgoing pseudostates may not have a trigger.
self.source.oclIsKindOf(Pseudostate) implies (self.trigger->isEmpty))
To:
[5] Transitions outgoing pseudostates other than junction and join may not have a trigger.
self.source.oclIsKindOf(Pseudostate) and
((self.source.kind <> #junction) and (self.source.kind <> #join))
implies (self.trigger->isEmpty))


Issue 6238: Multiplicity of Regions owning Transitions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no)
Nature: Revision
Severity: Significant
Summary:
The multiplicity of Regions owning Transitions shall be changed from 0..1 to 1, as Transitions can only be owned by Regions

Resolution: see above
Revised Text:
Actions taken:
September 8, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change this multiplicity in the metamodel to 1
Also, in the list of associations descriptions of Transition (section 15.3.14) add the
following text at the end of the list:
?? container[1] Designates the region that owns this transition. This redefines the
“owner” role.


Issue 6239: Actor (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no)
Nature: Revision
Severity: Significant
Summary:
Three sentences define actor differently. One of these (or a fourth) shold be chosen.

Resolution: see above
Revised Text:
Actions taken:
September 16, 2003: received issue
March 8, 2005: closed issue

Discussion:
?? On page 513 remove the following sentence from the Semantics section of the
Actor metaclass:
Each actor represents a coherent set of roles that users of the subject can play
when interacting with it.
?? On page 5 replace the current glossary definition of “actor” with the following
text copied from the metaclass definition:
An actor specifies a role played by a user or any other system that interacts with
the subject.


Issue 6240: UML2 super/pgs.17 + 598/"topLevel" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no)
Nature: Revision
Severity: Minor
Summary:
Subject: topLevel standard stereotype is referred to on pg 17 and retired on pg 598.

Resolution: Remove the complete entry for “top level” in the Glossary.
Revised Text:
Actions taken:
September 16, 2003: received issue
March 8, 2005: closed issue

Issue 6241: Actors that are outside and inside the system (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
There is a fundamental problem with the Actor element.
It is defined as
"An Actor models a type of role played by an entity that interacts with the subject 
(e.g., by exchanging signals and data), but which is external to the subject."


Now put your modeling focus on a subsystem. Use cases of that subsystem can have
external subsystems as actors. Let A be an actor of a use case. A is an external subsystem.


But now put your modeling focus on the whole system. Now A isn't an actor anymore, but
a subsystem. The same "real world" entity is defined twice in my model: as an actor and
as a subsystem. It depends on my modeling focus, but that's more a topic of the view and
not of the model.


The problem is common in business process modeling. In the BPM view a employee is a
stereotyped class, e.g. business worker. In the system analysis view (for a system
that should support parts of my business processes) the employee is an actor of the system.


We solved that problem by not using actors, but stereotyped classes. But I'm not feel
happy with that solution, because it just a workaround.


Any ideas?

Resolution:
Revised Text:
Actions taken:
September 9, 2003: received issue
March 9, 2005: closed issue

Discussion:
This problem pertains to the relationship between two (or more) models. In the example
cited, the first model is the one where A is an actor. The second model is the one where A
is a subsystem of a bigger system. Note that these are distinct models of two different
systems. Relating an element in one model to one or more elements in another (in this
case containing model) can be done in a variety of ways (e.g., using dependencies, trace
relationships, etc.) and is a methodological issue that is deemed outside the scope of the
UML specification.
Disposition: Closed, no change


Issue 6242: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
I've been looking at Figure 458 and can't quite get it, but don't know if
it's an issue -the problem I have is that the instance model seems to mix
meta-levels; we have an instance of the UML (meta) class, Class and an
instance of the user stereotype(class) Clock - yet on the diagram this jump
in metalevels is not mentioned. I can't see how this can be the true
Instance model. Could someone provide me with the XMI fragment that this
figure is intended to produce - I think that this would give me more of a
clue about what's going on.

Resolution: see above
Revised Text:
Actions taken:
September 12, 2003: received issue
March 8, 2005: closed issue

Discussion:
It is indeed an important preoccupation that there is no illustration of how to interchange
profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the
XMI spec. “instance model seems to mix meta- levels” is a common misunderstanding of
the Profile spec that has been solved through the previous issue resolutions. In particular,
the Profile/MOF correspondence has been specified and illustrated. This allows us to
apply the MOF/XMI mechanism. We therefore propose to provide an example that
illustrates the XMI interchange of profiles. The specification should be amended as
follows:
?? In Profiles:Profile:semantics, at the end of this paragraph, add
Using XMI to exchange Profiles
As shown Figure 447 (Extension : Semantics), there is a direct correspondence
between a profile definition and a MOF metamodel. XMI can therefore be directly
applied to exchange Profiles. We will take the example Figure 449 (Extension :
Notation) of a profile that we will call “HomeExample” to illustrate how a profile can
be exchanged. We will see that a profile can be exchanged as a model, as a XMI
schema definition, and that models extended by the profile can also interchange their
definition and extension.
Figure 449 shows a “Home” stereotype extending the “Interface” UML2 metaclass.
Figure 447 illustrates the MOF correspondence for that example, basically by
introducing an association from the “Home” MOF class to the “Interface” MOF class.
For illustration purpose, we add a property (tagged value definition in UML1.4)
called “magic:String” to the “Home” stereotype.
The first serialization below shows how the model Figure 449 (instance of the profile and
UML2 metamodel) can be exchanged. <?xml version="1.0" encoding="UTF-8"?>
<XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mof="http://schema.omg.org/spec/MOF/2.0"
xmlns:uml="http://schema.omg.org/spec/UML/2.0">
<uml:Profile xmi:id="id1" name="HomeExample">
<ownedStereotype xsi:type="uml:Stereotype" xmi:id="id2" name="Home">
<ownedAttribute xmi:id="id3" name="base_Interface" association="id5"
type=”id9”/>
<ownedAttribute xmi:id="id4" name="magic" type=”id10”/>
</ownedStereotype>
<ownedMember xsi:type="uml:Extension" xmi:id="id5" memberEnd="id3 id6">
<ownedEnd xsi:type="uml:ExtensionEnd" name="extensionHome" xmi:id="id6"
type="id2" association="id5" isComposite="true" lower="0"/>
</ownedMember>
<!--There should be metaclass reference between the profile and the
extended metaclass -->
<metaclassReference xmi:id="id8">
<uml:elementImport xsi:type="uml:ElementImport"
importedElement=”id9”/>
</metaclassReference>
</uml:Profile>
<mof:Class xmi:id=”id9”
href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/>
<mof:PrimitiveType xmi:id=”id10”
href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/>
<mof:Tag name="org.omg.xmi.nsURI"
value="http://www.mycompany.com/schemas/HomeExample.xmi"
element="id1"/> <mof:Tag name="org.omg.xmi.nsPrefix"
value="HomeExample" element="id1"/>
<mof:Tag name="org.omg.xmi.xmiName" value="base_Interface"
element="id3"/>
</XMI>
We will now obtain a XMI definition from the « HomeExample » profile. That XMI
description will itself define in XML how the models extended by the HomeExample will
be exchanged in XMI. We can see here that a XMI schema separated from the standard
UML2 schema can be obtained. This XMI definition is stored in a file called
“HomeExample.xmi”. <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace =
"http://www.mycompany.com/schemas/HomeExample.xmi"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:uml="http://www.omg.org/spec/UML/2.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://schema.omg.org/spec/XMI/2.1"
schemaLocation="XMI.xsd"/>
<xsd:import namespace="http://schema.omg.org/spec/UML/2.0"
schemaLocation="UML20.xsd"/>
<xsd:complexType name="Home">
<xsd:choice minOccurs="0" maxOccurs ="unbounded">
<xsd:element name="base_Interface" type="xmi:Any"/>
<xsd:element name="magic" type="xsd:string"/>
<xsd:element ref="xmi:Extension"/>
</xsd:choice>
<xsd:attribute ref="xmi:id"/>
<xsd:attributeGroup ref="xmi:ObjectAttribs"/>
<xsd:attribute name="base_Interface" type="uml:Interface"
<xsd:attribute name="magic" type="xsd:string" use="optional"/>
use="optional"/>
</xsd:complexType>
<xsd:element name="Home" type="Home"/>
</xsd:schema>
Let us provide an example of an Interface extended by the Home stereotype.  Figure 452 – Using the “HomeExample” profile to extend a model
Now the XMI code below shows how this model extended by the profile is
serialized. A tool importing that XMI file can filter out the elements related to the
“HomeExample” schema, if the tool does not have this schema (profile)
definition.
<?xml version="1.0" encoding="UTF-8"?>
<XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:uml="http://schema.omg.org/spec/UML/2.0 "
xmlns:HomeExample="http://www.mycompany.com/schemas/HomeExample.xmi">
<uml:Package xmi:id="id1" name="ClientPackage">
<ownedMember xsi:type="uml:Interface" xmi:id="id2" name="Client"/>
<packageImport xsi:type="uml:ProfileApplication" xmi:id="id3">
<importedProfile href="HomeExample.xmi#id1"/>
</packageImport>
</uml:Package>
<!-- Stereotypes -->
<HomeExample:Home base_Interface="id2" magic="1234"/>
</XMI>
Disposition: Resolved
<<Home>>
Client
ClientPackage


Issue 6243: Association not affecting ends (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:
Restore UML 1.x capability of modeling associations without modifying
the end types.  This is needed for database modeling, for profiles to be
used with fixed-schema repositories, and is the differentiator of UML
over OWL, etc.

Resolution: see above
Revised Text:
Actions taken:
September 8, 2003: received issue
March 8, 2005: closed issue

Discussion:
Summary
The intent of this resolution is to harmonize the relational (UML 1.x) and
object-oriented (UML 2) viewpoints in modeling associations, properties,
and navigability. It recommends separating ownership and navigation,
while preserving the other beneficial aspects of the UML 2 model, in
particular, the unification of properties and association ends. The changes
provide more flexiblity than both UML 1.x and 2.0 in modeling commonly
needed combinations of navigability and ownership.
Comparing UML 1.x and UML 2:
UML 1.x supported the specification of associations without modifying the
classes being associated. Association ends were always owned by the
association, regardless of the navigability of the association. The model
was most appropriate for relational applications such as databases, hash
tables, SmallTalk dictionaries, and predicate logic, and was useful when
the classes being associated should not be modified for some reason,
such as using a read-only model, or derived associations. It was less
appropriate for object-oriented applications, which expected that
specifying navigation of an association would modify the source class of
the navigation by defining an attribute on it to support runtime traversal
from instances of the class. The UML 1.x model also separated attributes
and associations, even though these are usually different views of the
same underlyi ng semantic.
UML 2 requires modification of the classes being associated in common
cases. In particular, it requires that an association end (modeled as a
property) be owned by the end classes when it is the source of navigation.
The model is most appropriate for object-oriented or record-based
applications, and supports supports class diagrams and composite
structure diagrams as views on a single underlying model. It is less
appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify
the source class of the navigation.
Example:
Suppose we model an association of teachers to courses like this:
In UML 2 this means:
For the relational modeler, the above will normally imply a column in the Teacher
table, even when this is not desired. Instead, the modeler might want an
intersection/correlation table, which in effect puts the columns on the association.
UML 2 offers this solution to have the association own properties for teacher and
course:
However, this prevents navigation from both teachers and courses, or at least
does not require it in the generated implementation. The modeler probably
wants the compiler to generate an API or other means for querying a course for
its teacher. The model must be refined to:
This again has the undesired effect of an attribute on Teacher, because the
current specification does not indicate that derived associations should not affect
the end classes. In addition, it is a detailed model more appropriate for the late
design stage, rather than early as in the first example figure. And a late stage
Teacher Course
0..* 1
+teacher +course
Teacher
course : Course [0..*]
Course
1
0..*
+teacher
+course
Teacher Course
1 0..*
+teacher +course
Teacher
course : Course [0..*]
TeacherCourseAssociation
teacher : Teacher [1]
course : Course [1]
0..*
1
+teacherCourse +teacher Course
1
0..*
+teacher
+course
/
1
1
+teacherCourse  model might migrate the column across to the other end, to prevent repeated
groups and normalize the database:
These examples shows that navigability in relational modeling is a requirement
for query services, rather than property ownership. The model should indicate it
is possible at runtime to get courses given a teacher, rather than indicate
Teacher has a course property.
Proposed changes to Infrastructure:
In Figure 73:
Add association between Property and Association that identifies the
owned ends that are navigable, called navigableOwnEnd, specialized from
ownedEnd:
In Infrastructure, Association class, section 11.3.1:
In Description section:
Replace second paragraph with:
“An end property of an association that is owned by an end
class or that is a navigable owned end of the association
Teacher Course
teacher : Teacher [1] 1
0..*
+teacher
+course
Property
isReadOnly : Boolean = false
isDerivedUnion : Boolean = false
Association
isDerived : Boolean = false
0..1 *
+owningAssociation
{subsets association,
subsets namespace,
subsets featuringClassifier}
+ownedEnd
{ordered,
subsets memberEnd,
subsets feature,
subsets ownedMember}
2..*
+association
0..1
+memberEnd
{ordered,
subsets member}
+navigableOwnedEnd
{subsets ownedEnd}  indicates that the association is navigable from the opposite
ends, otherwise the association is not navigable from the
opposite ends.”
In Associations section:
ownedEnd entry, delete "non-navigable".
Add navigableOwnedEnd attribute:
navigableOwnedEnd : Property [*] The navigable ends that
are owned by the association itself. Subsets
Association.ownedEnd.
In Constraints section add new constraint:
Association ends of associations with more than two ends must be
owned by the association.
if memberEnd->size() > 2
then ownedEnd->includesAll(memberEnd)
In Semantics section:
Delete the sentence “The semantics of navigable association ends
are the same as for attributes.”
In Notation section:
Replace paragraph above Figure 77 with:
"Figure 77 shows that the attribute notation can be used for
an association end owned by a class, because an
association end owned by a class is also an attribute. This
notation may be used in conjunction with the line -arrow
notation to make it perfectly clear that the attribute is also an
association end."
Change caption of Figure 77 to "Example of attribute notation for
navigable end owned by an end class."
In Infrastructure, in Property class, section 11.3.5:
Replace second two paragraphs with:
“A property related to a class by ownedAttribute represents an
attribute, and might also represent an association end. It relates an
instance of the class to a value or set of values of the type of the
attribute.“A property related to an association by memberEnd or its
specializations represents an end of the association. The type of
the property is the type of the end of the association.”
In Constraints section:
Replace rule 5 with:
[5] A navigable property can only be redefined or subsetted
by a navigable property.
(subsettedProperty->exists(sp | sp.isNavigable()
implies isNavigable())
and
(redefinedProperty->exists(rp | rp.isNavigable
implies isNavigable())
Replace rule 7 with:
[7] Only a navigable property can be marked as readOnly.
isReadOnly implies isNavigable()
In Additional Operations section add new operation:
The query isNavigable indicates whether it is possible to
navigate across the property.
Property::isNavigable() : Boolean
IsNavigable = not classifier->isEmpty() or
association.owningAssociation.navigableOwnedEnd -
>includes(self)
In Semantics section:
First paragraph, replace second sentence with:
“When related to an association via memberEnd or one of its
specializations, it represents an end of the association.”
Ninth paragraph, after "If a navigable property", delete "(attribute)".
Proposed changes to MOF 2 Core:
Section 15.2 (MOF Instances Model), under Link Slot, p 59, remove "(it is
owned by a Class)".
Section 16.1 (Migration from MOF 1.4): under Association End, in the right
column, remove the second sentence "If the property is owned by the
association, it is not navigable (no reference is referencing it)." Proposed changes to Superstructure:
In Figure 30:
Add association between Property and Association that identifies the
owned ends that are navigable, called navigableOwnEnd, specialized from
ownedEnd:
In Association class, section 7.11.2:
In Description section:
Replace second paragraph with:
“An end property of an association that is owned by an end
class or that is a navigable owned end of the association
indicates that the association is navigable from the opposite
ends, otherwise the association is not navigable from the
opposite ends.”
In Associations section:
ownedEnd entry, delete "non-navigable".
Add navigableOwnedEnd attribute:
navigableOwnedEnd : Property [*] The navigable ends that
are owned by the association itself. Subsets
Association.ownedEnd.
Property
isDerived : Boolean = false
isReadOnly : Boolean = false
isDerivedUnion : Boolean = false
/ default : String
aggregation : AggregationKind = none
/ isComposite : Boolean
Association
isDerived : Boolean = false
0..1 *
+owningAssociation
{subsets association,
subsets namespace,
subsets featuringClassifier}
+ownedEnd
{ordered,
subsets memberEnd,
subsets feature,
subsets ownedMember}
0..1
2..*
+association
+memberEnd
{ordered,
subsets member}
+navigableOwnedEnd
{subsets ownedEnd}  In Constraints section add new constraint:
Association ends of associations with more than two ends must be
owned by the association.
if memberEnd->size() > 2
then ownedEnd->includesAll(memberEnd)
In Semantics section:
Delete the sentence “The semantics of navigable association ends
are the same as for attributes.
In Examples section:
Replace paragraph above Figure 34 with:
"Figure 34 shows that the attribute notation can be used for
an association end owned by a class, because an
association end owned by a class is also an attribute. This
notation may be used in conjunction with the line -arrow
notation to make it perfectly clear that the attribute is also an
association end."
Change caption of Figure 34 to "Example of attribute notation for
navigable end owned by an end class."
In Property class, section 7.11.4:
Replace second two paragraphs with:
“A property related to a class by ownedAttribute represents an
attribute, and might also represent an association end. It relates an
instance of the class to a value or set of values of the type of the
attribute.”
“A property related to an association by memberEnd or its
specializations represents an end of the association. The type of
the property is the type of the end of the association.”
In Constraints section:
Replace rule 4 with:
[4] A navigable property can only be redefined or subsetted
by a navigable property.
(subsettedProperty->exists(sp | sp.isNavigable()
implies isNavigable())
and
(redefinedProperty->exists(rp | rp.isNavigable implies isNavigable())
Replace rule 6 with:
[6] Only a navigable property can be marked as readOnly.
isReadOnly implies isNavigable()
Add Additional Operations section after Constraints containing:
[1] The query isNavigable indicates whether it is possible to
navigate across the property.
Property::isNavigable() : Boolean
IsNavigable = not classifier->isEmpty() or
association.owningAssociation.navigableOwnedEnd -
>includes(self)
In Semantics section:
First paragraph, replace second sentence with:
“When related to an association via memberEnd or one of its
specializations, it represents an end of the association.”
Ninth paragraph, after "If a navigable property", delete "(attribute)".
In ReadLinkAction class, Constraints, in OCL of constraint [4], replace “isNavigable =
#true” with “isNavigable()”.


Issue 6244: Metamodel for applying a stereotype (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
What part of the metamodel is for applying a stereotype to a single
element in a user model?  I can only find the appliedProfile association
for applying profiles to packages.  Figure 458 shows a repository model
for it, but doesn't give the name of the relation between a class and
the Clock stereotype.

Resolution: This issue is resolved by the solution to issue 6347.
Revised Text:
Actions taken:
September 8, 2003: received issue
March 8, 2005: closed issue

Issue 6246: fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <<merge> (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
medium significance

The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities.

This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal.  Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs."

This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction.  Yet the Figure 175 says otherwise

Suggested resolution:

The root of this problem may be:

a.  Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed.  
b.  In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages."  It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages.  This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages"  is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction.
c.  Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two.  This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept.

Resolution:
Revised Text:
Actions taken:
September 10, 2003: received issue
March 9, 2005: closed issue

Discussion:
The author of the issue seems to have misread the spec. Figure 141 shows a dependency
from IntermediateActions (not IntermediateActivities) to StructuredActivities. However,
there was indeed a merge in the original FAS that coupled the Intermediate and
Structured Activities, but this link was removed in response to issue 6179. Therefore,
even that is no longer a problem and the statement about the separation of these two types
of activities is valid.
As for the recommended solution related to package merge, that issue is dealt with as part
of the resolution to issue 6279.
Disposition: Closed, no change


Issue 6247: Question about InterruptibleActivityRegion (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I am not sure about the semantics of the InterruptibleActivityRegion.


If I have such a region with an Accept Event Action to wait for an
event to terminate the region, what happens if there is no token
flow within the region, but the event occurs?


I think the Accept Event Action is active. I did not found another
statement in the specification. That means that all outgoing
egdes get tokens after event occurence. 


Normally that is not the semantic the modeler wants. Nothing should happen
if there is no token flow in the activity region.

Resolution: see above
Revised Text:
Actions taken:
September 11, 2003: received issue
March 8, 2005: closed issue

Discussion:
In InterruptibleActivityRegion, first paragraph
First sentence
after "interrupted", add ", including accept event actions in the
region,".
at end of paragraph, add new sentence "AcceptEventActions in the region that
do not have incoming edges are enabled only when a token enters the region,
even if the token is not directed at the accept event action."
In AcceptEventAction, Semantics, end of first sentence add "(also see
InterruptibleActivityRegion)".


Issue 6248: UML super/Section 2/Compliance points (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
The actual compliance levels as given on p. 1 ("no", "partial", "compliant", "interchange") are inadequate. 

For example, it is unclear what it means to "comply to the semantics", since semantics is generally stated in the proposal in terms of the system being modeled. Does a tool that simply provides a way to draw syntactically well-defined UML diagrams "comply to the semantics"?

Furthermore, it is also unclear what it means to "comply to abstract syntax". What about a tool that presents the notation, but does not use the abstract syntax as its internal representation? Would such a tool only be able to claim "partial compliance", even if it provides 100% of the UML notation? If not, what is the criteria for compliance with abstract syntax?

Even more problematic, XMI compliance is only required at the "interchange" level, which also requires compliance to abstract syntax, notation and semantics. This would seem to exclude any tool that processes XMI, but does not use the notation-for example, an execution engine that runs off XMI input or a tool that configures itself using an XMI-formatted UML model. There should be a way to claim XMI compliance without being a full modeling tool.

In general, the compliance levels do not seem to be defined in a way that will be useful for the range of tools that may want to usefully claim UML compliance.

Recommendation: 

The 2U proposal (ad/2003-01-08) contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. The UML 2.0 specification as adopted should compliance discussion based on the 2U approach.

Resolution: see above
Revised Text:
Actions taken:
September 11, 2003: received issue
March 8, 2005: closed issue

Discussion:
Replace section 2 (“Conformance”) with the text in the appended PDF file.
C:\mydata\
documents\external\Standards\OMG\UML2.0\FTF\Issues\ComplianceLevels\Compliance.section.addin.


Issue 6249: UML 2 Super/p125 and p126/typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
p. 125, last paragraph, first line
"As it turns out, this seemis redunadancy..."


p. 126, second line
Figures 23.4 and 23.5 are not there

Resolution: see above
Revised Text:
Actions taken:
September 12, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 125, replace the phrase:
“…this seemis redundancy…”
with:
“…this apparent redundancy…”
On page 126 remove the sentence:
“Figures 23.4 and 23.5 depict another way of thinking about this. .”


Issue 6250: fig236 Datastore example/Datastore should not directly linked with actions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
A datastore is a specialized CentralBufferNode. But in figure 236
the datastore node is directly linked with action nodes. That is not 
allowed.

Resolution:
Revised Text:
Actions taken:
September 12, 2003: received issue
March 9, 2005: closed issue

Discussion:
The pins are elided in the example. This notation is inherted from object nodes.
Disposition: Closed, no change


Issue 6251: UML 2 super/Composite Classes/Connecting parts of parts (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Consider a model where a composite class, CC, has two parts A and B, both
typed by class CT. If CT has a part PT, then can I describe a connection
between A.PT and B.PT? It seems to me that the metamodel can't capture this
because Connections can only be associated to parts, not parts of parts (i.e
the metamodel for parts has a flat structure) . So the connection would end
up being just a reflexive connection from PT to itself, which would be typed
by a reflexive association on the type of PT.


If there is a way of connection parts of parts I would like to see more
explanation somewhere in the spec.

Resolution: see above
Revised Text:
Actions taken:
September 15, 2003: received issue
March 8, 2005: closed issue

Discussion:
Connectors can only connect parts that are in the same classifier – thus, they
cannot connect parts of parts in the following manner:
A: CT
PT
B: CT
PT
The resolution to issue 6668 added a constraint to connector which makes this
restriction more explicit. The following might be a slightly improved version of this
constraint:
[4] The ConnectableElements attached as role to each ConnectorEnd owned by a
Connector must be roles of the classifier that owned the Connector, or they must be ports
of such roles.
Disposition:


Issue 6252: Defenition of redefines????? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
Redefinition of Associations is causing me some concern.  I have a attached a RoseModel which expresses it better than verbiage.

 

This is my first post to this group and I would appreciate a reply upon receipt just to let me know it is being reviewed

Resolution:
Revised Text:
Actions taken:
September 15, 2003: received issue
March 9, 2005: closed issue

Discussion:
Unforutnately, the Rose model attached to this issue was not stored in the issues database,
so the details of this issue remain unknown. An e- mail request for the model to the
originator went without response.
Disposition: Closed, no change


Issue 6253: What does redefines mean in package extensibility? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
What does redefines mean in package extensibility?

Resolution: see above
Revised Text:
Actions taken:
September 16, 2003: received issue
March 8, 2005: closed issue

Discussion:
The new rules for package merge in response to issue 6279 deal explicitly with how
redefinition is handled.


Issue 6255: UML2 Super / Classes/ Incorrect reference to "access" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
There are several places in the draft spec that refer to an "access" relationship when it should refer to a "uses" relationship instead.  The access relationship according to the appendix is obsolete.  The the incorrect reference I have found are on  page 39,  page 32. 

Resolution:
Revised Text:
Actions taken:
September 17, 2003: received issue
March 9, 2005: closed issue

Discussion:
The meaning of the <<access>> stereotype has changed between UML 1.x and
UML 2.0. The usages of <<access>> on page 32 and 39 are consistent with the
UML 2.0 definition of <<access>> and should remain as is. The semantic
discontinuity between UML 1.x and UML 2.0 in the meaning of the <<access>>
stereotype was the subject of substantial discussion within the FTF team, and the
UML 2.0 meaning has been purposefully retained.
The reference to “the appendix” refers to Table 28 in appendix B.3 on page 597
of the UML2 Superstructure FAS (ptc/03-09-15). This table notes that the UML
1.x meaning of <<access>> is obsolete but says nothing about the UML 2.0
meaning of <<access>>. Given the structure of Table 28, there does not seem
to be an easily understandable way of being more explicit about this without a
complete restructuring of table; this does not seems warranted.
Disposition: Closed, no change


Issue 6256: UML2 Super / association end naming convention (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
To be consistent with the convention of other names in the spec, the names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent).

Resolution:
Revised Text:
Actions taken:
September 18, 2003: received issue
March 9, 2005: closed issue

Discussion:
Region::transition no longer has an ‘s’ at the end, while ActivityGroup::nodeContent and
ActivityGroup::edgeContent no longer exist. These were all the result of a series of
changes that occurred during the finalization work.
Disposition: Closed, no change


Issue 6257: UML2 Super / SimpleTime package / missing multiplicities (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The multiplicities for the various constraints are unspecified in the documentation and the metamodel: 

Specifically, the multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1 

Resolution: see above
Revised Text:
Actions taken:
September 18, 2003: received issue
March 8, 2005: closed issue

Discussion:
The identified multiplicities should be “1”. Note that the min and max constraints
are redefinitions of min and max constraints that are given the multiplicities “1”.


Issue 6258: UML 2 Super / State machines-CommonBehavior / undefined owner of triggers (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
It is not clear which kind of model element owns a Trigger specification (the Behavior to which it applies or something else?) 

Resolution: Duplicate of 6629.
Revised Text:
Actions taken:
September 19, 2003: received issue
December 2, 2004: closed issue

Issue 6259: UML2 Super / Primitive Types / implementation issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects. 

As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them. 

There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2. 

Resolution:
Revised Text:
Actions taken:
September 19, 2003: received issue
March 9, 2005: closed issue

Discussion:
This short note sketches out two possible solutions to the TypeExpressio ns problem. The
latter is the issue of modeling standard C++ declarations that involve pointers and
references such as:
1. int * pi
2. int & ri
3. int * * ppi
4. Myclass * pm
5. Myclass * & arpm[5]
Before discussing solutions, it is important to note that in a situation where C++ is being
modeled for needs such as round-trip engineering, which requires an unambiguous
mapping between models and code, a special C++ profile must be defined. The profile is also needed to constrain the general UML semantics to C++ semantics. Hence, both
proposed solutions assume that such a profile exists.
In addition, both solutions are based on the view that a pointer or a reference to some
type is a separate type that is distinct from the type that it is referencing. Thus, a pointer
to the type MyClass is a separate type from MyClass.
Possible Solution 1
This solution defines a special stereotype of Association for each useful combination of
pointer and reference types. For example, the following stereotypes of Association could
be defined:
«ptr» for *
«ref» for &
«ptr-ptr» for * *
«ptr-ref» for * &
etc.
In that case, the examples above would be modeled as follows2:
«cpp-function»
main
«primitive»
int
1
«ptr» pi
1
«ref» ri
1
«ptr-ref» rpi
«cpp-class»
MyClass 1
«ptr» pm
5
«ptr-ref» arpm
In addition, an alternative text-based notational form (e.g., to be used in list boxes) might
be defined for these stereotypes, such as:
arpm : «ptr-ref» MyClass [5]
which could be expanded to the graphical form shown above.
The major drawback with this solution is that it requires a separate stereotype for each
possible combination of references and pointers. In most real- world applications, of
course, only a relatively small number of such combinations are used implying that only
2 Note the use of the «cpp-function» stereotype to model C++ functions, including the “main” program.
This is a stereotype of the abstract metaclass Behavior, which is a subtype of Class. a small number of stereotypes need to be defined. However, there is always the
possibility that a given application may use some combination that has not been defined.
Another potential problem is the handling of cases of pointers or references to constant
types, such as:
const int * cpi
This could be solved with additional stereotypes such as «const-ptr», although that would
increase the number of stereotypes needed. This sub- issue probably warrants further
study.
Possible Solution 2
This solution is more flexible, but leads to more complex models. It requires the explicit
definition of the appropriate pointer or reference types using two stereotypes of the Type
concept in UML, «reference» and «pointer»3, and an associated Dependency stereotype
«target». The two Type stereotypes would each require exactly one «target» dependency
to the appropriate target type. For example, the following two type declarations would be
required in a model4:
«pointer»
*int
«primitive»
int «target»
«pointer»
*MyClass
«primitive»
MyClass «target»
«reference»
*&MyClass «target»
These types would then be used for the following declarations in a model:
pi : *int
rpm : *&MyClass [5]
Given that these solutions exist to the problem, this resolution proposes that this part of
the spec remain unchanged.
Disposition: Closed, no change


Issue 6260: UML 2 Super / Interactions / no create message (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
I am trying to find a mechanism to create a message that represents creation of lifeline. It used to be modeled as a relationship 'action' between Message and Action in UML 1.4. 

Note: There is a mechanism in UML 2 to create a message that represents destruction of lifeline. Its modeled as 'Stop' metamodel element. 

Shouldn't we have something symmetrical to represent creation of lifeline message? 

Resolution: duplicate
Revised Text:
Actions taken:
September 19, 2003: received issue
December 2, 2004: closed issue

Discussion:
The notation and modeling of create messages is the subject of issue 6077 and will be
solved in the context of that issue’s resolution.
Disposition: Duplicate


Issue 6261: UML Superstructur 03-08-02: Notation for ConditionalNode is missing (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
The Notation and Presentation Options sections of
the ConditionalNode are empty (p. 315).

Resolution: Same as Issue 6071 (Conditional Node and Loop Node notation missing
Revised Text:
Actions taken:
September 5, 2003: received issue
December 2, 2004: closed issue

Issue 6263: UML 2 Super / Interactions / No way to model reply messages (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
It seems that there is no direct way to specify a "reply" message in the UML metamodel for Interactions -- even though there is a notation for this concept (dashed arrow). 

Resolution: see above
Revised Text:
Actions taken:
September 26, 2003: received issue
December 2, 2004: closed issue

Discussion:
The notation and modeling of return (reply) messages is the subject of issue
6077 and will be solved in the context of that issue’s resolution.
Disposition: Duplicate


Issue 6264: Recommendation for InteractionOccurrences (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Northrop Grumman (Dr. Brian Willard, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Recommend for InteractionOccurrences be equated to ActivityNodes of Activity
Diagrams rather than ObjectNodes as currently specified.  This spec
reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447):


Interaction Overview Diagrams are specialization of Activity Diagrams that
represent Interactions Interaction Overview Diagrams differ from Activity
Diagrams in some respects.
1. In place of ObjectNodes of Activity Diagrams, Interaction Overview
Diagrams can only have either (inline) Interactions or
InteractionOccurrences. Inline Interaction diagrams and
InteractionOccurrences are considered special forms of ActivityInvocations.

Resolution:
Revised Text:
Actions taken:
September 26, 2003: received issue
March 9, 2005: closed issue

Discussion:
While the motivation for this suggestion is understandable, the proble m is that, despite
the conceptual and notational similarities between activity flows and the flows shown in
Interaction Overview Diagrams, the two are semantically distinct. Thus a flow in activity
diagrams assumes token flow semantics, the semantics of flows represented in interaction
overview diagrams are different (i.e., each lifeline has its own token and the tokens of
different lifelines are not synchronized necessarily and can move at different speeds).
Hence, despite its intuitive appeal, this recommendation is inappropriate.
Disposition: Closed, no change


Issue 6277: On templateableElment - additonal features (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:
The query getParameterableElements() returns the set of elements that may be used as the parametered element for a template parameter if this templateable element ???." 

I think the previous sentence is not complete?

Resolution: see above
Revised Text:
Actions taken:
September 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issue was resolved as part of the resolution to issue 6203. The correct
sentence is the following (copied from the resolution to issue 6203):
The query parameterableElements() returns the set of elements that may be used as the parametered
elements for a template parameter of this templateable element.


Issue 6278: Sequence diagram conditions on Message arrows (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Thematix Partners LLC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Uncategorized Issue
Severity:
Summary:
Sequence diagrams in UML 1.x  supported a conditional expression to a
message arrow that was inadvertently omitted from the UML 2.0 Superstructure
specification.  This annotation enabled the modeler to -- in essence --
place guards on messages.  Such guards, or more properly ConditionalActions,
would be evaluated at run time to determine which message arrow(s) would be
executed.  In particular, the UML 1.5 Superstructure document specifies the
following:
 
-In Section 3.60.5.1: "Any condition ... expression attached to the arrow
becomes, in a detailed action model, the test clause action in a
ConditionalAction ... in the dispatching Procedure.


-In section 3.63.2: "An arrow may also be labeled with a condition and/or
iteration expression."


-In Section 3.63.3:  "A branch is shown by multiple arrows leaving a single
point, each possibly labeled by a condition.  Depending on whether the
conditions are mutually exclusive, the construct may represent
conditionality or concurrency."


-In 3.72.2.4: "A condition represents a Message whose execution is
contingent on the truth of the condition clause. The condition-clause is
meant to be expressed in pseudocode or an actual programming language; UML
does not prescribe its format. An example would be: [x > y]."
A "branch" condition, or ConditionalAction, is expressed in the form:
           Œ[¹ condition-clause Œ]¹


Recommendation:


The UML 2.0 Superstructure FTF team should determine how to reinstate
ConditionalActions for Sequence Diagrams, given the new abstract syntax for
Sequence Diagrams.  There are two reasons for this:
1) To maintain backward compatibility with UML 1.0 through 1.5 is important.
2) Pragmatically, it offers a graphically simple technique to express
messaging situations that involve branching.  Granted, the ALT operation
supports the equivalent notion;  however,  it comes with a graphical
complexity that is not always desired.




Discussion:


{IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or
why it wasn't} 

Resolution:
Revised Text:
Actions taken:
September 29, 2003: received issue
March 9, 2005: closed issue

Discussion:
UML 2.0 interactions are not fully backwards compatible with UML 1.x interactions;
neither are the respective sequence diagrams. Conditions in interactions are now shown
with either opt or alt fragments. In additions, conditions can be shown using interaction
overview diagrams. Adding the 1.x sequence diagram conditions would be completely
inconsistent with the new style of sequence diagrams and would thus cause much
confusion. It also was not scalable for real- life applications, albeit it looked cute in text
books.
The branching lifeline construct of UML1 would increase confusion and complexity of
UML2, not decrease it.
The original branching notation in UML1 had the following problems:
- On a branch, the lifelines had to conceptually split into two logically-distinct
lifelines, one corresponding to each arm of the branch. This is awkward to draw,
difficult for tools to manage, confusing for people, and probably modeled
incorrectly a large amount of the time.
- It is also not clear which part of the split lifeline goes with which condition,
especially if there are ne sted branches. It might be OK for just one lifeline, but if
multiple lifelines appear in messages in the condition region, this may not even be
conceptually sound.
- There is no way to show the recombination of lifelines at the end of the branch.
SOME lifelines may have messages that could merge back onto a single lifeline,
but this is by no means required in all cases.
- Nested conditional or loops become unworkable visually, and their semantic
soundness is also questionable.
In the new notation, the lifelines also conceptually split, but the separation of the diagram
into physically-separate vertical sections, each corresponding to one arm of the branch,
removes the visual problem. It also removes the conceptual problem: each region
represents a conceptual split of ALL lifelines in the branch, so there is no problem in
telling which version of a lifeline goes with which other version of a lifeline.
When it comes to loops, the previous notation was even more deficient. You could draw
a backward arrow, but the semantics were highly unfounded. We can't build a sound
model on suggestive notation that is not well founded and which does not scale up.
The new notation is absolutely clear and similar to much previous notation in modeling
even before OO modeling. It is also close to a traditional program, so most users
shouldn’t have a hard time following it. Even nonprogrammers have seen examples (in
product manuals and other things) of structure text of the form
IF xxx
do this
...
ELSE
do this So even non techies are familiar with this kind of structure. The branching lifeline
notation, however, was confusing for everybody.
The old branching lifeline constructs were seriously flawed technically and visually. The
new constructs are sound and scalable. Let's not put the bad ones back in.
Disposition: Closed, no change


Issue 6279: PackageMerge (from Kernel) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
A package merge defines how one package extends another package by merging their contents.

Description

A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable.

This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions.

It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified."

The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set.

This operation known as PackageMerge is performed when it is desired to produce new elements  (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with .

This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as  "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…".  After being extended, a package is not what it was prior to being extended.  Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name."

Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name.   By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards .

A reductio ad absurdum argument can be posed, as follows:

Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2.

Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1.

If  S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2.

Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T.

Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source.


Resolution: see above
Revised Text:
Actions taken:
September 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
The rules of package merge need to be clarified and made consistent across the MOF,
Infrastructure, and Superstructure. Due to various implementation-related and similar
concerns identified with the “define” form of package merge used to define the UML 2
metamodel (see issues 6186, 6188, 6189, 6190, 6191, 6194, 6198, 6246, 6253, 6471,
6517, 6642) the FTF decided to only support a single form of package merge: the
“extend” form defined in the MOF specification. This not only reduces gratuitous
complexity but also solves a number of implementation issues (particularly those related
to mapping the merge notions to standard OO languages). Last but not least, if used in the
right way, the “extend” type of package provides a very convenient solution to the
definition of compliance levels (6187, 6196, 6197, 6248) such that tools that implement a
higher level of compliance can easily import XMI of modeles defined at a lower level of
compliance, without having to do any special conversion.
However, even the “extend” version of package merge defined in the MOF spec needs to
be upgraded and clarified, so that the handling of all possible merge situations is fully
defined. The following resolution was worked out after long discussions among the FTF
members and has been programmatically verified. The resolution proposes fixes to all
three related specs: the MOF 2.0 spec, the UML Infrastructure spec, and the UML 2.0
Superstructure spec. The main definition of package merge is the same in all cases, but
needs to be inserted in different parts of each document. In addition, there are several
additional fixes that are specific to each document.
The shared definition of package merge is captured in the attached PDF file in the form
of a metaclass definition that needs to be inserted in the proper place in the Super and
Infra documents in place of the current definitions.
C:\mydata\
documents\external\Standards\OMG\UML2.0\FTF\Issues\PackageMergeModels\PackageMergeDefinition.040804.pdf
Updates required to the Superstructre spec:
1. Replace the diagram in Figure 43 on page 99 with the following diagram that includes
the following changes from the original: ?? The changed name for Package::ownedType (resolved by issue 6918)
?? Renaming of PackageMerge::mergingPackage to
PackageMerge:receivingPackage (for clarity to match the text in the spec)
PackageableElement Namespace
DirectedRelationship
PackageableElement
PackageMerge
Type
Package
0..1
*
+owningPackage
{subsets namespace} +ownedMember
{redefines ownedMember}
1
*
+receivingPackage
{subsets source,
subsets owner}
+packageMerge
{subsets ownedElement}
1
+mergedPackage
{subsets target}
*
0..1
+nestedPackage {subsets ownedMember}
+nestingPackage
{subsets namespace}
* 0..1
+/ownedType
{subsets ownedMember}
+package
{subsets namespace}
2. Replace the entire PackageMerge description (section 7.3.12 of the Superstructure
FAS) with the text in the embedded PDF file above.
Updates required to the Infrastructure spec:
1. Replace the diagram in Figure 94 on page 152 with the following diagram that
includes the following changes from the original:
?? Removal of the generalization from Package to Basic::Package, since this is no
longer required due to the new rules for package merge defined in this resolution
?? Renaming of PackageMerge::mergingPackage to
PackageMerge:receivingPackage (for clarity to match the text in the spec) Namespace
PackageableElement
PackageMerge
Type
Package
* 0..1
ownedMember
{redefines ownedMember}
owningPackage
{subsets namespace}
*
0..1
nestedPackage
{subsets ownedMember}
nestingPackage
{subsets namespace}
*
1
packageMerge
{subsets ownedElement} +receivingPackage
{subsets source,
subsets owner}
1
mergedPackage
{subsets target}
* 0..1
/ownedType
{subsets ownedMember}
package
{subsets namespace}
2. Replace the entire PackageMerge description (section 11.8.3 of the Infrastructure
FAS) with the text in the embedded PDF file above.
Updates required for the MOF 2.0 spec:
1. Completely remove sections 14.1 and 14.2 that describe different kinds of merges,
since the MOF will reuse the definition of merge that it gets from the infrastructure.
2. Replace all uses of the keyword <<combine>> by the keyword <<merge>> in figures
1, 6, and 14 and also in the text.
3. In section 8 on page 11, first paragraph, 2nd last sentence, remove “combine,”
4. In section 8.2 on page 11, remove the entire second paragraph that talks about the
difference of package merges.
5. In the remaining paragraph of section 8.2, replace all references to the “merging”
package by corresponding references to the “receiving” package.


Issue 6280: UML2.super (or infra)/Profiles-Stereotype (18.3.7) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:
UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram
customization mechanism


This feature was supported in UML1.4 by an attribute called "icon:string".
At the time of the design of the Profile metamodel for UML2.0, it has been
argued this this was a mechanism to be treated by the diagram interchange
proposal. To my knowledge, this is not the case, or if it is this is not
eplained.
This is at least a backward compatibility issue
Two options can at least be envisaged :
1 if that is supported by the global "2.0" specifications, explain in the
profile chapter how
2 introduce back this "icon:string" attribute. In that cas, thenotation
ch^pter has to be extended to explain how this icon can be displayed, and
how multiple stereotype can be handled.

Resolution: see above
Revised Text:
Actions taken:
October 1, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Profile chapter
In the profile metamodel (Abstract syntax, Figure 446), add the Image metaclass, and
an association between “Stereotype” and Image as follows:
Stereotype Image
icon *
*
In Class description
Add the following text:
Image (from Profiles)
Physical definition of a graphical image.
Description
The Image class provides the necessary information to display an Image in a
diagram. Icons are typically handled through the Image class.
Attribute No additional attributes.
Associations
No additional associations.
Constraints
No additional constraints.
Semantics
Information such as physical localization or format is provided by the Image
class. The Image class is abstract. It must be concretely defined within
specifications dedicated to graphic handling (see for example the UML 2.0
Diagram Interchange OMG adopted specification).
In Class description : Stereotype : association area,
Replace
“No additional associations.”
By
icon : Image [*] Stereotype can change the graphical appearance of the extended
model element by using attached icons. When this association is not null, it references the
location of the icon content to be displayed within diagrams presenting the extended
model elements.
In Class description : Stereotype : Constraints area, at the end add:
[3] Stereotype names should not clash with keyword names for the extended model
element.
In Class description : Stereotype : Notation area, at the end of the first paragraph “If
multiple stereotypes … guillemets” add:
When the extended model element has a keyword, then the stereotype name will be
displayed close to the keyword, within separate guillemets (example:
«interface»«Clock» ).
In Class descrip tion : Stereotype : Notation area, after the paragraph “Presentation
options”, add a new paragraph
Icon presentation
When a stereotype includes the definition of an icon, this icon can be graphically
attached to the model elements extended by the stereotype. Every model element that has a graphical presentation can have an attached icon. When model elements
are graphically expressed as:
?? Boxes (see Figure 461), the box can be replaced by the icon, and the name
of model element appears below the icon. This presentation option can be
used only when a model element is extended by one single stereotype, and
when properties of the model element are not presented (i.e. attributes,
operations of a class). As an other option, the icon can be presented in a
reduced shape, inside and on the top of the box representing the model
element. When several stereotypes are applied, several icons can be
presented within the box.
?? Links, the icon can be presented close to the link
?? textual notation, the icon can be presented on the left of the textual
notation.
Several icons can be attached to a stereotype. The interpretation of the different
attached icons in that case is a semantic variation point. Some tools may require
to have different images for the icon replacing the box, fo r the reduced icon inside
the box, for icons used within explorers, etc. Depending on the image format,
other tools may choose to display one single icon into different sizes.
Some model elements are already using an icon for their default presentation. A
typical example of this is the actor model element which uses the stickman icon.
In that case, when the model element is extended by a stereotype with an icon, the
stereotype’s icon replaces the default presentation icon within diagrams.
In Class description : Stereotype : Notation, add at the end of the “Examples” Paragraph
the following figure
Figure 461 – Presentation options for an extended class.


Issue 6281: UML2 Super/Composite Structures (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Divergence between XMI/MDL and the PDF/FM
The XMI and MDL files for UML 2 super both state that Port is a subclass of
Property and yet the appropriate diagram in the spec (fig 97) doesn't - this
fragment of the adopted XMI spec illustrates the point: 


<ownedType xsi:type="cmof:Class"
xmi:id="_UML_CompositeStructures_Ports_Port" name="Port" 
> > superClass="_UML_CompositeStructures_InternalStructures_Property 
> > _UML_CompositeStructures_InternalStructures_ConnectableElement 
> > _UML_Classes_Kernel_StructuralFeature">

Resolution: The resolution of issue 6356 removes this problem.
Revised Text:
Actions taken:
October 2, 2003: received issue
March 8, 2005: closed issue

Discussion:


Issue 6308: super AND infra / Section 11.8.3 of Infra, 7.13.2 of Super / PackageMerge (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Page 155 of the Infra Adopted Spec ptc/03-09-15 [sic] I think the date order got changed from Euro to US on this
Page 101 of the Super "Final" Adopted Spec ptc /03-08-02 [sic] The date says August 2003 









Resolution: withdrawn by submitter
Revised Text:
Actions taken:
October 10, 2003: received issue
October 10, 2003: closed issue

Discussion:


Issue 6309: UML2 Super/Kernel::Classifier (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
In 03-08-02.pdf, page 62, attribute should be /attribute

Resolution: see above
Revised Text:
Actions taken:
October 9, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 50 in the attribute called “attribute” (2nd line of the page), add a slash to
the entry to indicate that it is derived as follows:
/attribute


Issue 6310: UML2 Super/Profiles (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
In figure 446, only packages that specialise Constructs::Package can contain
a Profile Application. Whereas I think that the packages to which we need to
apply profiles are those packages that specialise Kernel::Package

Resolution:
Revised Text:
Actions taken:
October 9, 2003: received issue
March 9, 2005: closed issue

Discussion:
Well, Kernel is defined in the infrastructure, and construct is build in the superstructure.
So I believe it is the way around : the opposite.
Disposition: Closed, no change


Issue 6315: UML 2 Super/Components & Deployment chapters missing OCL constraints (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The constraints in the Component and Deployment chapters are expressed in verbal English. They should ideally also be represented in OCL

Resolution: see above
Revised Text:
Actions taken:
October 13, 2003: received issue
March 8, 2005: closed issue

Discussion:
In section 8.3.1, Associations, /provided add the following OCL to define the derivation:
context Component
def: RealizedInterfaces : (classifier : Classifier) : Interface =
(classifier.clientDependency->select
(dependency |
dependency.oclIsKindOf(Realization) and
dependency.supplier.oclIsKindOf(Interface)
)
)->collect (dependency | dependency.client)
def: UsedInterfaces : (classifier : Classifier) : Interface =
(classifier.supplierDependency->select
(dependency |
dependency.oclIsKindOf(Usage) and
dependency.supplier.oclIsKindOf(Interface)
)
)->collect (dependency | dependency.supplier)
context Component::provided derive:
let implementedInterfaces = self.implementation->collect(impl |
impl.contract) and
let realizedInterfaces = RealizedInterfaces(self) and
let realizingClassifierInterfaces =
RealizedInterfaces(self.realizingClassifier) and let typesOfRequiredPorts = self.ownedPort.provided
in
(
(
(implementedInterfaces->union(realizedInterfaces)
)->union(realizingClassifierInterfaces)
)->union(typesOfRequiredPorts)
)->asSet()
In section 8.3.1, Associations, /required add the following OCL to define the derivation:
context Component::required derive:
let usedInterfaces = UsedInterfaces(self) and
let realizingClassfierUsedInterfaces =
UsedInterfaces(self.realizingClassifier) and
let typesOfUsedPorts = self.ownedPort.required
in
(
(usedInterfaces-
>union(realizingClassifierUsedInterfaces)
)->union(typesOfUsedPorts)
)->asSet()
NB: The resolution to issue 7178 sharpens the verbal expression of these derivations,
consistent with the OCL.


Issue 6316: UML2 Super/Ports (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
03-08-02.pdf:


This from the descrciption of Ports(p169):
"For a behavior port, the instance of the owning classifier will handle
requests arriving at this port (as specified in the behavior
of the classifier, see Chapter 13, "Common Behaviors"),"
Is how this works a semantic variation point - if so then it should say so.


 IMO, the very least we should allow is that Port can participate in an
Association so that its class can have an association end that points to its
parent, and so can delegate behaviour appropriately

Resolution:
Revised Text:
Actions taken:
October 14, 2003: received issue
March 9, 2005: closed issue

Discussion:
Regarding the first paragraph of the summary, there is nothing additional to specify. As
the specification stated, the behavior port forwards any arriving signals to the owning
classifier. The behavior of that classifier deals with that signals in the manner specified
by that behavior. This is not a semantic variation, but just a consequence of the way how
behavior is specified (see Chapter 13).
In response to the second paragraph of the issue summary, only classifiers participate in
associations. As a port is not a classifier but a feature of a classifier, associations do not
apply to it. However, the type of the port (a classifier) can participate in associations.
Disposition: Closed, no change


Issue 6317: UML2 Super/Instances (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
03-08-02.pdf


In Figure 120, "l1", which I believe is an InstanceSpecification appears to
be nested inside another (anonymous) InstanceSpecification, ":Car". However,
looking at the metamodel for Instances, one InstanceSpecification cannot own
another. So, in the repository for the diagram in Figure 120, which model
element owns the InstanceSpecification "l1"? This is important because for
example when it comes to delete ":Car" how does the repository know to
delete "l1"?

Resolution:
Revised Text:
Actions taken:
October 15, 2003: received issue
March 9, 2005: closed issue

Discussion:
Just because there is a composition relationship between the ‘real’ instances (in the
runtime system being modeled) does not mean there need be a composition between the
InstanceSpecifications used to model them. The Issue points out a fairly obscure example
with structured classes but the same would apply if instances of 2 classes were shown
with a composition between them. Similarly the fact that some shapes are nested in
others.
Disposition: Closed, no change


Issue 6337: Figure 61 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 61 - shows a ball connected to a cup, but this notation is not shown
in the Diagrams section (7.18). It's not clear whether this is actually an
Assembly Connector, or some other concept. The spec should be clear on
whether this is an additional notation or not.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The diagram in question is the following one:
ISensor
TheftAlarm ProximitySensor
It shows two classifiers apparently joined via their implemented/required interfaces.
Unfortunately, this notation conflicts with the notation used in the Components chapter,
where the ball- in-socket combination implies a connector (I have seen this cause the
same type of confusion in at least one other case).
The notation above is questionable as it is: it is not clear whether it represents a statement
that somehow relates the two classifiers or not, or whether it is merely a statement about
the relationship between the two interfaces (note that the two interfaces do not
necessarily have to be the same type as shown in this diagram).
Therefore, this resolution proposes that the ball- in-socket notation be used exclusively for
implicit connectors, to eliminate such confusion. This means the following change to the
text:
?? Remove figure 61 from the spec and the entire paragraph immediately preceding it.


Issue 6338: description of Component on page 137 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
The description of Component on page 137 says that the provided and required
interface associations are derived both directly, from implement and use
dependencies, and from realizing classifiers and owned ports. What isn't
clear to me is whether the cup and ball notation can be used for all
provided and required interfaces, or just for those directly implemented and
used. If it can be used for all then it isn't clear whether you can
distinguish between direct and derived interfaces. However, I note on Figure
89 that /orderedItem is preceded by a slash - is that how the difference is
notated?

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is an important issue. It applies to a wider context than just Components and
AssemblyConnectors, viz. to CompositeStructure and Connectors in general. The
/orderedItem is only an implicit referral to this issue – it needs to be clarified:
In figure 89, remove the slash from /account. This is a counter- intuitive example. Keep
the slash for /orderedItem and explain clearly by inserting the following text as a new
paragraph on page 140 after the paragraph that ends with “Optionally, specific instances
(InstanceSpecifications) can also be referred to as in this notation”:
Interfaces that are exposed by a Component and notated on a diagram, either
directly or through a port definition, may be inherited from a supertype
component. These interfaces are indicated on the diagram by preceding the name
of the interface by a forward slash. An example of this can be found in figure 89,
where “/orderedItem” is an interface that is implemented by a supertype of the
Product component.


Issue 6347: Profiles in fixed repositories (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Clarification
Severity: Critical
Summary:
Do profiles working for fixed repositories in UML 2?  My understanding
is that they are at M3 now, so they wouldn't.  If that's the case, then
what is their purpose?  The other feature of dynamically changing
metaclasses is something a repository could provide if it was useful,
instead of using stereotypes.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
1 Change the text in the overview of profiles
(actual text)
The Profiles package contains mechanisms that allow metaclasses from existing
metamodels to be extended to adapt them for different purposes. This includes the ability
to tailor the UML metamodel for different platforms (such as J2EE or .NET) or domains
(such as real-time or business process modeling). The profiles mechanism is consistent
with the OMG Meta Object Facility (MOF).
(Add)
Positioning profiles versus metamodels, MOF and UML:
The infrastructure specification is reused at several meta-levels in various OMG
specifications that deal with modeling. For example, MOF uses it to provide the ability to
model metamodels, whereas the UML superstructure uses it to model the UML model.
This chapter deals with use cases comparable to the MOF at the meta-meta- level, which
is one level higher than the rest of the superstructure specification. Thus, in this chapter,
when we mention “Class”, in most cases we are dealing with the meta-metaclass “Class”
(used to define every meta class in the UML superstructure specification (Activity, Class,
State, Use Case, etc.).
Profiles History and design requirements
The Profile mechanism has been specifically defined for providing a lightweight
extension mechanism to the UML standard. In UML 1.1, stereotypes and tagged values
were used as string-based extensions that could be attached to UML model elements in a
flexible way. In subsequent revisions of UML, the notion of a Profile was defined in
order to provide more structure and precision to the definition of Stereotypes and Tagged values. The UML2.0 infrastructure and superstructure specifications have carried this
further, by defining it as a specific meta- modelling technique. Stereotypes are specific
metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of
packages.
The following requirements have driven the definition of profile semantics from
inception:
1. A profile must provide mechanisms for specializing a reference
metamodel (such as a set of UML packages) in such a way that the
specialized semantics do not contradict the semantics of the reference
metamodel. That is, profile constraints may typically define wellformedness
rules that are more constraining (but consistent with) those
specified by the reference metamodel.
2. It must be possible to interchange profiles between tools, together with
models to which they have been applied, by using the UML XMI
interchange mechanisms. A profile must therefore be defined as an
interchangeable UML model. In addition to exchanging profiles
together with models between tools, profile application should also be
definable “by reference” (e.g. “import by name”); that is, a profile
does not need to be interchanged if it is already present in the
importing tool.
3. A profile must be able to reference domain-specific UML libraries
where certain model elements are pre-defined.
4. It must be possible to specify which profiles are being applied to a
given Package (or any of specializations of that concept). This is
particularly useful during model interchange so that an importing
environment can interpret a model correctly.
5. It should be possible to define a UML extension that combines profiles
and model libraries (including template libraries) into a single logical
unit. However, within such a unit, for definitional clarity and for ease
of interchange (e.g. ‘reference by name’), it should still be possible to
keep the libraries and the profiles distinct from each other.
6. A profile should be able to specialize the semantics of standard UML
metamodel elements, e.g., in a model with the profile “Java model”
generalization of classes should be able to be restricted to single
inheritance, without having to explicitly assign a stereotype «Java
class» to each and every class instance.
7. A notational convention for graphical stereotype definitions as part of
a profile should be provided. 8. In order to satisfy requirement [1] above, UML Profiles should form a
metamodel extension mechanism that imposes certain restrictions on
how the UML metamodel can be modified. The reference metamodel
is considered as a “read only” model, that is extended witho ut changes
by profiles. It is therefore forbidden to insert new metaclasses in the
UML metaclass hierarchy (i.e. new super-classes for standard UML
metaclasses) or to modify the standard UML metaclass definitions, e.g.
by adding meta-associations. Such restrictions do not apply in a MOF
context where in principle any metamodel can be reworked in any
direction.
9. The vast majority of UML case tools should be able to implement
Profiles. The design of UML profiles should therefore not constraint
these tools to have an internal implementation based on a metametamodel/
metamodel architecture.
10. Profiles can be dynamically applied to or retracted from a model. It is
possible on an existing model to apply new profiles, or to change the
set of applied profiles.
11. Profiles can be dynamically combined. Frequently, several profiles
will be applied at the same time on the same model. This profile
combination may not be foreseen at profile definition time.
12. Models can be exchanged regardless of the profiles known by the
destina tion target. The destination of the exchange of a model
extended by a profile may not know the profile, and is not required to
interpret a specific profile description. The destination environment
interprets extensions only if it possesses the required profiles.
2 Change in the text of Stereotype: semantics
(Change)
A stereotype is a limited kind of metaclass that cannot be used isolated, but must always
be used in conjunction with one of the metaclasses it extends. Each stereotype may
extend one or more classes through extensions as part of a profile. Similarly, a class may
be extended by one or more stereotypes.
An instance of a stereotype is linked to an instance of an extended metaclass (or
stereotype) by virtue of the extension between their types.
(Into)
A stereotype is a limited kind of metaclass that cannot be used by itself, but must always
be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may
be extended by one or more stereotypes.
An instance “S” of Stereotype is a kind of (meta) class. Relating it to a metaclass “C”
from the reference metamodel (typically UML) using an “Extension” (which is a specific
kind of association), signifies that model elements of type C can be extended by an
instance of “S” (see example Figure 454). At the model level (such as in Figure 457)
instances of “S” are related to “C” model elements (instances of “C”) by links
(occurrences of the association/extension from “S’ to “C”).
Any model element from the reference metamodel (any UML model element) can be
extended by a stereotype. For example in UML, States, Transitions, Activities, Use cases,
Components, Attributes, Dependencies, etc. can all be extended with stereotypes.
3 In Profile : semantics
(add)
The most direct implementation of the Profile mechanism that a tool can provide, is by
having a metamodel based implementation, similar to the Profile metamodel. However,
this is not a requirement of the current standard, which requires only the support of the
specified notions, and the standard XMI based interchange capacities. The profile
mechanism has been designed to be implementable by tools that do not have a
metamodel-based implementation. Practically any mechanism used to attach new values
to model elements can serve as a valid profile implementation. As an example, the
UML1.4 profile metamodel could be the basis for implementing a UML2.0-compliant
profile tool.
4 in Package : Semantics
Currently : No additional semantics.
(Replace with)
The association “appliedProfile” between a package and a profile crosses metalevels: It
links one element from a model (a kind of package) to an element of its metamodel and
represents the set of profiles that define the extensions applicable to the package.
Although this kind of situation is rare in the UML metamodel, this only shows that model
and metamodel can coexist on the same space, and can have links between them.
5 In Extension : Semantics
(Change )
In order to be able to navigate to the extended metaclass when writing constraints, the end must have a
name. If no name is given, the default name is baseClass. (into)
The equivalence to a MOF construction is shown in Figure 447. This figure illustrates the case shown in
Figure 449, where the “Home” stereotype extends the “Interface” metaclass. The MOF construct equivalent
to an extension is an aggregation from the extended metaclass to the extension stereotype, navigable from
the extension stereotype to the extended metaclass. When the extension is required, then the cardinality on
the extension stereotype is “1”. The role names are provided using the following rule : The name of the role
of the extended metaclass is –base“ExtendedMetaclassName”-; the name of the role of the extension
stereotype is –extension“StereotypeName”-.
Constraints are frequently added to stereotypes. The role names will be used for
expressing OCL navigations. For example, the following OCL expression states that a
Home interface shall not have attributes:
self.baseInterface.ownedAttributes->size() = 0
Interface Home
baseInterface extensionHome
1 0..1
Figure 447 – MOF model equivalent to extending “Interface” by the “Home” stereotype
6 in Stereotypes : Examples
(Change)
Note that in order to be able to write constraints on the stereotype Clock that should be applied to the
metaclass Class or any of its relationships, it is necessary to give the end typed by the metaclass a name for
navigation purposes. A typical such name would be for example base.
In Figure 455, an instance specification of the example in Figure 454 is shown. Note that the extension
must be
composite, and that the derived required attribute in this case is false.
(Into)
In Figure 455, an instance specification of the example in Figure 454 is shown. Note that the extension
must be composite, and that the derived isRequired” attribute in this case is false. Figure 455 shows the
repository schema of the stereotype “clock” defined in Figure 454. In this schema, the extended instance
(:Class; “name = Class”) is defined in the UML2.0 (reference metamodel) repository. In a UML modeling
tool these extended instances referring to the UML2.0 standard would typically be in a “read only” form, or
presented as proxies to the metaclass being extended.
(It is therefore still at the same meta-level as UML, and does not show the instance model of a model
extended by the stereotype. An example of this is provided in Figures 457 and 458.) The Semantics subsection
of the Extension concept explains the MOF equivalent, and how constraints can be attached to
stereotypes.
(Update Figure 458 “Showing values of stereotypes and a simple instance specificiation”) StopWatch
<<Clock>> <<Clock>>
Resolution=2
:Class
name="StopWatch"
:Clock
resolution=2
baseClass extensionClock


Issue 6348: Control pins (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
There should be a special kind of pin for control tokens.  This will
allow parameter sets to be used with control, for example.  Also
resolves issue of where control is bufferred when it is direceted at a
join.  Can be implemented as a pin that has no parameter, by making them
the last in the ordering of pins, so no parameter corresponds to them.
This is also a request of the SysML team.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Using control with parameter sets requires a user-level type for control, which
could be used with parameters. Since UML does not standardize a user-level
model library, the resolution below allows it to be indicated on ObjectNode. To
address the other half of the issue requires that pins be marked as control for the
action, rather than data.
Figure 187 of the FAS, ObjectNode, add the attribute
isControlType : Boolean = false
In ObjectNode class:
Description, second paragraph:
Remove “and”.
At end of sentence, add “, and carrying control values.”
Attributes (CompleteActivities) add entry:
isControlType : Boolean = false Tells whether the type of the
object node is to be treated as control.
Semantics (CompleteActivities), add new paragraph at end:
An object node may indicate that its type is to be treated as a
control value, even if no type is specified for the node. Control
edges may be used with the object node having control type.
Notation    Under Figure 275 of the FAS, paragraph beginning
"(CompleteActivities)", third sentence, replace "and ordering" with ",
ordering, and control type".
After Figure 187, add new figure with caption:
Control pins
In Pin class,
Change title of "Attributes" section to "Attributes (CompleteActivities)", and
add new entry:
isControl : Boolean = false Tells whether the pins provides data to
the actions, or just controls when it executes it.
Add new section "Constraints (CompleteActivities), with new constraint:
[1] Control pins have a control type.
isControl implies isControlType
Semantics, add new paragraph at end:
"(CompleteActivities) Control pins always have a control type, so
they can be used with control edges. Control pins are ignored in
the constraints that actions place on pins, including matching to
behavior parameters for actions that invoke behaviors. Tokens
arriving at control input pins have the same semantics as control
arriving at an action, except that control tokens can queue up in
control pins. Tokens are placed on control output pins according to
the same semantics as tokens placed on control edges coming out
of actions."
Notation
Just before the last sentence of the section, in its own paragraph,
add "(CompleteActivities) Control pins are shown with a text
annotation placed near the pin symbol {control}.". In ControlFlow class, Constraints, change first constraint to:
[1] Control flows may not have object nodes at either end,
except for object nodes with control type.


Issue 6349: Control at joins (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Where are control nodes buffered when directing control to a join?

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Control only means that an action may start, so multiple control tokens have the
same effect as one. There is no need to buffer them. Clarify as indicated below.
In JoinNode class, Semantics section, after the numbered list, add this sentence
before the one that's there:
"Multiple control tokens offered on the same incoming edge are combined
into one before applying the above rules."
In Action class, Semantics section,
in the numbered list, in [2], after the first sentence add: "If multiple control
tokens are available on a single edge, they are all consumed."
in the second paragraph after the numbered list, about reentrancy, modify
the beginning of the third sentence as follows: "In this case, control tokens
are discarded, and data tokens collect ..."


Issue 6350: Dependency multiplicity to CollaborationOccurrence (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Significant
Summary:
Figure 100 says Dependency must be in exactly one
CollaborationOccurrence.  Presumably there are dependencies that are not
in collaboration occurrences

Resolution: The multiplicity of the end at CollaborationOccurrence should be changed to “0..1”.
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Issue 6351: InformationFlow realization (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Significant
Summary:
InformationFlow realization should be to more than relationships.  It
could be to any set of elements

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Philippe Desfray:
The realization association can be attached to any kind of "link" that relates "entities" such as
classes or parts, and that can convey the information flow . This is typically the case for
Dependencies, associations and ... connector.
Relationship is supposed to abstract all that kind of "links". However, despite I beleive
remembering of a decision to have a regular generalization of all kind of "links" to relationship, it
is not the case for "connector" which is a feature.
There are two solutions for this :
1 add a new "realization" association from InformationFlow to "connector", or
2 let connector also be a subclass of "relationship".
Conrad Bock
If Philippe still feels my the earlier revision (realizing “Element”) is too broad, then it would be fine
just to include ActivityEdge and
Message as possible realizations of InformationFlow, since these are the behavioral elements
across which information can flow.
Proposed resolution :
Add uni-directional associations between InformationFlow and Connector, between
InformationFlow and Message, between InformationFlow and ActivityEdge
The following changes are required:
?? Replace the diagram in figure 412 with the following one that shows three new
explicit import dependencies between InformationFlows and InsternalStructures,
InformationFlows and BasicInteractions, InformationFlows and BasicActivities
packages: Kernel InternalStructures PrimitiveTypes
Models InformationFlows Templates
BasicActivities BasicInteractions
«merge»
«merge»
«merge»
«import» «import»
«import»
?? Replace the diagram in figure 413 by the following diagram:
Connector
ActivityEdge
Message
realizingConnector
Relationship
DirectedRelationship
InformationFlow
source {subsets source}
*
InformationItem
Classifier
represented
*
*
conveyed
*
1..* realization
*
realizingActivityEdge
*
NamedElement
1..*
target {subsets target}
*
1..*
* *
* *
realizingMessage *
*
Adds associations from InformationFLow to Connector, to ActivityEdge, to Message,
and redefine the target and source associations from InformationFLow to NamedElement,
o Removes the redundant Classifier::representation and
Relationship::abstraction roles (since these are directed relationships, the
convention is not to name roles that cannot be referenced)
?? Add the following items to the list of Associations on page 532:
o realizingConnector : Connector[*] Determines which Connectors will
realize the specified flow
o realizingActivityEdge : ActivityEdge[*] Determines which ActivityEdges
will realize the specified flow o realizingMessage : Message[*] Determines which Messages will realize
the specified flow
o target : NamedElement[1..*] Defines to which target the conveyed
InformationsItems are directed
o source : NamedElement[1..*] Defines from which origin the conveyed
InformationsItems are initiated


Issue 6352: Deployment location (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Revision
Severity: Significant
Summary:
In Deployments, the spec uses "location" as an association end name, but
"node" in MDL file.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The MDL is out of date with the spec. the role name on the DeploymentTarget type
should be “location” (association between DeploymentTarget and Deployment). Update
the MDL file.


Issue 6354: Association end names and part types (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Dr. Bruce Powel Douglass, bruce.douglass(at)us.ibm.combruce.douglass(at)telelogic.com)
Nature: Revision
Severity: Significant
Summary:
In the notation of composite structure, are association end names
allowed to be presented on connectors?  If so, how are they
distinguished from port type?

Resolution:
Revised Text:
Actions taken:
October 20, 2003: received issue
March 9, 2005: closed issue

Discussion:
The issue probably refers to connector end names. No restrictions are given on the
adornment of connector ends. There could, in fact, be a difficulty to distinguish visually
whether a given text is the name of a port or the name of the connector end. (Note: the
difficulty is not with port type, but with port; the notation for port type has no confusion
due to the preceding colon.) In practice, this confusion will not arise as typically
connector ends would not be named unless they do not connect via ports. Otherwise,
proximity has to be used to differentiate (e.g., the name of the port could be written inside
the part or class symbol. Note that there is no difficulty differentiating in the metamodel
or a tool implementing the metamodel. The difficulty is merely one of parsing a graphical
document. The small likelihood of a problem does not warrant a special notation.
Disposition: Closed, no change


Issue 6355: partWithPort without ports (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Revision
Severity: Significant
Summary:
Seems like partWithPort should be able to connect parts of parts without
needing to use ports.  Just use partWithPort to part, connectorEnd to
part of part.  Loosen constraint 2 of ConnectorEnd to allow all parts

Resolution: Duplicate of 6251.
Revised Text:
Actions taken:
October 20, 2003: received issue
December 2, 2004: closed issue

Issue 6356: Ports as properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm(at)johndeere.com)
Nature: Revision
Severity: Significant
Summary:
Ports should be properties (better yet parts), to participate in
composite association when desired.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
The issue suggests that ports be considered subtypes of Property. After discussions in the
FTF, it was agreed to make this change to support the dynamic creation of ports (and
possibly, their destruction during the life of the owning classifier).
Consequentially, the following changes to the specification of port (relative to ptc/03-08-
02) are suggested:
In Figure 97 “The Port metaclass” on p.154, delete the inheritance from
StructuralFeature, but add the inheritance from Property. Delete the inheritance from
ConnectableElement. Change the text on EncapsulatedClassifier.ownedPort to “subsets
ownedAttribute”. The modified diagram is shown below.
StructuredClassifier
(from InternalStructures)
Property
(from InternalStructures)
ConnectorEnd
0..1
+partWithPort Interface
(from Interfaces)
Port
isBehavior : Boolean = false
isService : Boolean = true
*
*
+redefinedPort
{subsets redefinedElement}
* *
+/required
* *
+/provided
EncapsulatedClassifier
*
0..1
+ownedPort
{subsets ownedAttribute}
{subsets redefinitionContext}
Property
(from InternalStructures)
In Section 9.3.11, “Ports (from Ports)” make the following changes:
Change the first sentence after the heading to “A port is a property of a classifier…”.
In the constraint section, delete constraint [1] and renumber the following constraint from
[2] to [1].
Add the following new constraints:
[2] Port.aggregation must be composite.
[3] When a port is destroyed, all connectors attached to this port will be destroyed also.
[4] A defaultValue for port cannot be specified when the type of the Port is an Interface. In section 9.3.7. “ConnectorEnd (from InternalStructures, Ports)” add an additional
constraint
[3] The property held in self.partWithPort must not be a Port.


Issue 6357: Port is a Property in XMI (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Revision
Severity: Significant
Summary:
Port is a Property in the XMI, but not in the spec.  This is because in
MDL file Port is a Property, but it is only visible in the object
browser.  It was only hidden from the diagrams instead of being deleted.
U2P internal history live on.  Search on name="Port"

Resolution: Duplicate of 6281.
Revised Text:
Actions taken:
October 20, 2003: received issue
December 2, 2004: closed issue

Issue 6358: Outgoing edges of initial nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Add constraint on initial nodes that its outgoing edges can only be
control.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Constraint section of InitialNode, p 335, add this constraint:
"[2] Only control edges can have initial nodes as source."


Issue 6359: Guards on initial nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Carify whether guards can be used at initial nodes.


Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Semantics section of initial nodes, p 335, in the first paragraph, in the next-to-last
sentence, before "(see Activity)", add the words:
", for example by guards"


Issue 6360: Caption typo (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Caption to Figure 251 (Final node example) should be flow final
example

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change caption for Figure 213
-from: “Final node example.”
-to: “Flow Final and Activity Final example.”


Issue 6361: Activity final clarification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Clarify the effect of an activity final node when only some of the
non-streaming output parameters have tokens.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Semantics section of ActivityFinalNode, p 298, in the first paragraph, add this to
the next-to- last sentence:
", using the null token for object nodes that have nothing in them."


Issue 6362: Side effects of value specifications (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:
Clarify whether guards and other value specification can have side
effects

Resolution:
Revised Text:
Actions taken:
October 20, 2003: received issue
March 9, 2005: closed issue

Discussion:
Whether ValueSpecifications might have side effects varies depending upon which of its
concrete subclasses one is examining. If a particular ValueSpecification is any of the
subclasses LiteralBoolean, LiteralInteger, LiteralString, LiteralUnlimitedNatural,
LiteralNull or InstanceValue, the answer seems that they obviously are incapable, by
definition, of having side effects. In contrast, it seems plausible that the Expression and
OpaqueExpression subclasses of ValueSpecification might very well have side effects.
However, other considerations argue against explicitly saying so. Interpretation of the
contents of an OpaqueExpression’s body attribute is delegated to an external “linguistic
analyzer” (page 47) and therefore, by definition, outside the scope of UML.
Consequently, one cannot determine whether an OpaqueExpression’s body has sideeffects.
Even though their tree structure is non-opaque and captured in UML, similar
logic applies to evaluating whether Expressions can have side effects. An Expression is a
“structured tree of symbols” where symbol interpretation “depends on the context of the
expression” (page 46). Since the required “context” is not defined, the definition of the
semantics of an expression is again outside the scope of UML. Since explicitly stating
whether side-effects are allowed would be either irrelevant (for OpaqueExpression and
Expression) or belaboring the obvious (fo r the Literal subclasses and InstanceValue), it
seems unreasonable to suggest making any changes to the texts in section 7.5 of the
UML2 Superstructure FAS (ptc/03-08-02) or in section 9.7 of the UML2 Infrastructure
FAS (ptc/03-09-15). Note, also, that only the Expression and OpaqueExpression
subclasses of ValueSpecfication are included in the Infrastructure FAS, so conclusions
regarding the Literal subclasses and InstanceValue do not apply to the Infrastructure.
The situation for guards is also somewhat more complex than one might expect since
there are three different types of guards defined in the SuperFAS specification:
ActivityEdge (section 12.3.3, page 293) defines a guard as a ValueSpecification.
The semantics of these guards are further discussed under DecisionNodes on
page 320. Consequently, the considerations outlined above for the subclasses of
ValueSpecification are relevant here as well.
The discussion of Interaction diagrams in section 14.4 (page 447) says that a
guard “is a Message” and “is meant to be expressed in pseudocode or an actual
programming language; UML does not prescribe its format”. Again, definition of
guards is out of UML’s scope, so their potential for side effects cannot be
determined, and arguably, should not be inhibited. The Transition class of State Machines (section 15.3.14, page 498) defines a
guard to be a Constraint that “should be pure expressions without side effects.
Guard expressions with side effects are ill formed.” And on page 501 of the same
section, “Guards should not include expressions causing side effects. Models that
violate this are considered ill formed.” Hence, the SuperFAS is already explicit
about preventing side effects for Transition guards. Note that because guards are
Constraints, they have a specification attribute that references a
ValueSpecification describing the constraint’s definition. To prevent side effects
on this ValueSpecification, Transition defines to local constraints that (1) require
the value specification to evaluate to a boolean which does not, by definition,
have side effects, and (2) explicitly prevent side effects. So, situation already
handled.
The Infrastructure FAS does not contain the word “guard” outside of the glossary, which
has been excluded by another issue resolution. So no changes to it are required.
Disposition: Closed, no change.


Issue 6363: Guard evaluation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:
Clarify that not all the guards are required to be evaluated, only that
one succeed (expand on race condition sentence).

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Semantics section of Decision Node, p 320, in the second paragraph, before the
sentence beginning "For decision points", add the sentence:
"If the implementation can ensure that only one guard will succeed, it is not
required to evaluate all guards when one is found that does."


Issue 6364: Decision behaviors on control tokens (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:
Clarify that decision behaviors work on control tokens.  Suggest that
control tokens invoke behaviors with no input parameters.  Behavior can
use ReadSelfAction to access host if necessary

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Constraint section of Decision Node, p 320, change the first two sentences of
constraint [2] to:
"A decision input behavior has zero or one input parameter and one output
parameter. Any input parameter must be the same as or a supertype of the type
of object tokens coming along the incoming edge."
In the Semantics section of Decision Node, p 320, last paragraph, change the first
sentence to:
"If a decision input behavior is specified, then each data token is passed to the
behavior before guards are evaluated on the outgoing edges. The behavior is
invoked without input for control tokens."


Issue 6365: ReadSelfAction with no host (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Extend ReadSelfAction to return behavior object if there is no host.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In ReadSelfAction class, Semantics section, replace the first sentence with
"For activities that have no other context object, the activity itself is the context object. See
behaviors as classes in Common Behavior and discussion of reflective objects in Activity."


Issue 6366: Clarify ReadSelfAction in activity behaviors (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:
Clarify the semantics of ReadSelfAction for behaviors used in activities
(decision input, etc).

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Semantics section of ReadSelfAction, p 248, change the first sentence, before the
hyphen to:
"Every action is part of some activity, as are behaviors invoked by actions or
other elements of activities. Activities are optionally attached in some way to the
specification of a classifier"


Issue 6367: Combining joined tokens (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Join nodes should have an option to combine tokens with identical
values.  For example, when joining flows created by a fork duplicating
tokens.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 190, add an attribute to JoinNode:
isCombineDuplicate : Boolean = true.
Updated Figure 190 shown below.
In JoinNode class:
Rename “Attributes” section to “Attributes (CompleteActivities)”
in Attributes (CompleteActivities) section, add this entry:
“isCombineDuplicate : Boolean [1..1] Tells whether tokens
having objects with the same identity are combined into one
by the join. Default value is true.”
in Semantics section, before the last paragraph, in its own paragraph, add:
"If isCombineDuplicate is true, then before object tokens are offered
to the outgoing edge, those containing objects with the same
identity are combined into one token."


Issue 6369: Clarify join specs referencing control flow edges (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity:
Summary:
Clarify that join specs reference to control flow edge names as being
boolean.

Resolution:
Revised Text:
Actions taken:
October 20, 2003: received issue
March 9, 2005: closed issue

Discussion:
The text refers to edges and tokens generally, so explicitly includes data and
control edges already.
Disposition: Closed no change


Issue 6370: Clarify join rules (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity:
Summary:
Clarify that a successful non-and join spec still combines the incoming
tokens by the same rules as "and".

Resolution:
Revised Text:
Actions taken:
October 20, 2003: received issue
March 9, 2005: closed issue

Discussion:
The text is clear on this. Join rules are stated as the basic semantics, which are assumed
in the complete semantics.
Disposition: Closed, no change


Issue 6371: Join example (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
The example for join, Figure 263, doesn't make sense from a domain point
of view.  Orders aren't accepted and shipped concurrently.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 263, change
-from: “Accept Order”
-to: “Send Invoice”


Issue 6373: Parameters in Features and Common Behavior (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
The Features model (Figure 28) shows BehavioralFeature with the
parameter association presumably derived from formalParameter and
returnResult, whereas the Common Behavior model (Figure 312) shows
Behavior formalParameter and returnResult derived, derived from the
parameter association.  These parameter models for operations and
behavior should be the same.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
As pointed out in the summary, these portions of the specification should be consistent,
which can be accomplished either by making the features model consistent with the
common behavior model, or vice versa. While the issue does not notice this, there is
actually a defect in the features model in that it is missing a consistency constraint
between the formal parameter and the return parameters. The proposed resolution to issue
7344 resolves the discrepancy between superstructure and infrastructure on how to
interpret parameters. This resolution brings the parameter model in CommonBehavior in
synchronicity with the proposed resolution 7344.
In Figure 311 “Common Behavior” change parameter to ownedParameter. Delete the
derived associations Behavior.formalParameter and Behavior.returnResult.
In Section 13.3.3. Behavior, Associations, delete the definitions of formalParameter and
returnedResult. Change parameter to ownedParameter.
In Section 13.3.3, Semantics, on p. 439 change the first paragraph:
When a behavior is invoked, its attributes and parameters (if any) are created and appropriately
initialized. Upon invocation, the arguments of the original invocation action are made available to
the new behavior execution corresponding to its formal parameters, if any. When a behavior
completes its execution, a value or set of values is returned corresponding to each return result
parameter, if any.
To
When a behavior is invoked, its attributes and parameters (if any) are created and appropriately
initialized. Upon invocation, the arguments of the original invocation action are made available to
the new behavior execution corresponding to its parameters with direction in and inout, if any.
When a behavior completes its execution, a value or set of values is returned corresponding to
each parameter with direction out, inout, or return, if any.


Issue 6374: Initial nodes in structured actions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Dr. Tracy Gardner, tgardner(at)uk.ibm.com)
Nature: Clarification
Severity:
Summary:
Clarify whether structured actions can have initial nodes

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The rules for initial node execution in structured activities should be the same as
for activities, but limited to the immediately containing structured node. Changes
below.
In InitialNode class, Semantics:
In first sentence:
Replace "invoking" with "executing.
At end add "(or structured node, see StructuredActivityNode)."
At end of second sentence add: ", but not in initial nodes in structured
nodes contained by the activity."
In StructuredActivityNode, in Semantics, second paragraph, replace first
sentence with:
"No subnode in the structured node, including initial nodes and accept
event actions, may begin execution until the structure node itself has
started."


Issue 6375: Flows across SAN boundaries (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Dr. Tracy Gardner, tgardner(at)uk.ibm.com)
Nature: Clarification
Severity:
Summary:
Clarify that control and object flows can cross SructuredActivityNode
boundaries (we need this).

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The only restriction on edges is that if they are owned by the structured node,
then the source and target must in the structured node (constraint 1 of
StructuredActivityNode). There is no restriction on edges not owned by a
structured activity node. Clarify this as below.
In StructuredActivityNode:
Constraints, first constraint, at end, add “, and vice versa.”
Semantics, add third sentence: “Edges not contained by a structured node
can have sources or targets in the structured node, but not both.”


Issue 6376: Terminating a SAN (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Dr. Tracy Gardner, tgardner(at)uk.ibm.com)
Nature: Clarification
Severity:
Summary:
How do you end a SructuredActivityNode in the way that an
ActivityFinalNode ends an Activity?

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
The rules for activity node execution in structured activities should be the same as for
activities. Changes below.
In ActivityFinalNode class, Semantics, first sentence, before first comma, add "(or
structured node, see StructuredActivityNode)".
In StructuredActivityNode, in Semantics, second paragraph, at end, add:
"Tokens reaching an activity final node in a structured node abort all flows in the
immediately containing structured node only. The other aspects of terminaition
are the same as for activity finals contained directly by activities (see
ActivityFinalNode)."


Issue 6377: AcceptCallAction in SAN (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Dr. Tracy Gardner, tgardner(at)uk.ibm.com)
Nature: Revision
Severity:
Summary:
What is the behavior when a SAN contains an AcceptCallAction with no
incoming control links.  Is the accept only enabled once when the SAN
receives a control token, or it it enabled for the lifetime of the SAN?
Either way, how do you model the other behavior.

Resolution: see above
Revised Text:
Actions taken:
October 20, 2003: received issue
March 8, 2005: closed issue

Discussion:
Clarify that an AcceptEventAction with no incoming edges in a SAN is enabled for the
lifetime of the SAN, as specified below. Use an AcceptEventAction with incoming
edges To accept only one event, or an interruptible region or exception to terminate the
AcceptEventAction.
In AcceptEventActionClass,
Semantics section:
Third paragraph:
Add to the end of the first sentence:
", whichever most immediately contains the action. In
addition, an AcceptEventAction with no incoming
edges remains enabled after it accepts an event."
Delete the second sentence.
At the end of the paragraph add:
"An AcceptEventAction with no incoming edges and
contained by a structured node is terminated when its
container is."
Examples section:
Delete third sentence, including “(CompleteActions)” at the end.
In StructuredActivityNode, Semantics section, in second paragraph,
at end of first sentence, add:
"(see exception at AcceptEventAction)."


Issue 6378: Questions about CentralBufferNode semantic (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I have a question about the flow semantic according to
a CentralBufferNode.


p.312 (Examples) says:
"...because each token can only be drawn from the object node
by one outgoing edge."


What exactly happens if a CentralBufferNode has more than one
outgoing edge. Is it defined which one is used?


In the example on p. 312 I cannot see why the edge leading to
the action "Use parts" is prefered to the action "Pack parts" as
described in the text ("All the parts that are not used will be packed...").

Resolution: see above
Revised Text:
Actions taken:
September 5, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Examples section of CentralBufferNode, p 312, in the paragraph above Figure 230,
change the last sentence to:
"All the parts that are not used will be packed as spares, and vice versa, because
each token can only be drawn from the object node by one outgoing edge. The
choice in this example is non-deterministic."


Issue 6379: Visibility of a Package (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Under notation (top of page 100), says that “The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (‘+’ for public and ‘-’ for private).” 

 

This statement does not mention protected () or package (~) visibility; only public and private. 

 

Cross Reference:

On page 31 of Adopted Superstructure spec, figure 6, the VisibilityKind enumeration class has attributes public, private, protected

Resolution: see above
Revised Text:
Actions taken:
October 22, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
The issue correctly summarizes the state of affairs in the UML2 Superstructure FAS and
UML2 Infrastructure FAS documents. The existing text is in fact correct because
Constraint [1] for Package requires that package elements with non-empty visibility have
either public or private visibility, effectively excluding protected and package visibilities.
To improve the clarity of the text on this matter, the following text additions are
suggested:
1. Add the sentence "Package elements with defined visibility may not have
protected or package visibility." to the end of the last paragraph in the Notation
subsection, page 101, of Section 7.13.1 Package in the UML2 Superstructure FAS
(ptc/03-08-02).
2. Add the sentence "Package elements with defined visibility may not have
protected or package visibility." to the end of the last paragraph in the Notation
subsection, page 154, of Section 11.8.2 Package in the UML2 Infrastructure FAS
(ptc/03-09-15).
Disposition: Resolved


Issue 6380: Typo on Notation for CombinedFragment? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
On page 413 of Superstructure spec (Adopted) – section concerning notation for CombinedFragments of Sequence diagram, for the Operator Ignore/Consider, the Textual Syntax seems to have a typo -- should that be straight brackets surrounding the last <message name> to denote optional, rather than the curly brackets? 

 

In other words:     

 

Textual syntax: (ignore | consider ){ <message name>{,<message name>}* }

Should Be:

 

Textual syntax: (ignore | consider ){ <message name>[,<message name>]* }


Resolution:
Revised Text:
Actions taken:
October 22, 2003: received issue
March 9, 2005: closed issue

Discussion:
The grammar on page 413 is correct. It denotes a comma-separated list of message
names. It may contain more than two elements.
Disposition: Closed, no change


Issue 6381: Figure 395 requires a lot more explanation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 395 requires a lot more explanation. The abstract syntax claims that
the effect of a transition be expressed as an Activity and so I suppose this
is what this diagram represents, but I don't recognise the rectangle
notation from activities. It's also not clear whether the arrows represent
flows or transitions - if fact they can't be either, because some of the
arrows start on states and end on actions. It also isn't clear whether there
are any rules about the construction of these transitions; for example, I
assume that there can only be one signal receipt and that it has to be the
first symbol encountered, but that isn't stated. There may be an explanation
that I missed, in which case it should be placed nearer the figure, or an
appropriate reference inserted. The various symbols should also appear in
the diagrams section.

Resolution: see above
Revised Text:
Actions taken:
October 23, 2003: received issue
March 8, 2005: closed issue

Discussion:
The intent for this presentation option is to provide a graphical representation for triggers
and actions attached on a transition. This notational enhancement is not about mixing
activity graph notation into a statemachine.
Therefore, the answer to Alan’s question is that all the graphical segments connecting
action and trigger symbols map to a single transition. Semantically the transition is the
one that owns the activity that contains the actions represented by the symbols. It is a
tool implementation issue whether a transition with graphical actions is composed by
creating a transition and then attaching the action/trigger symbols to it, or nodes are
created and connected by several graphical segments which all map to a single transition.
The proposed resolution:
Metamodel: Add an import dependency between BehaviorStateMachines and
StructuredActivities. BehaviorStateMachines
ProtocolStateMachines MaximumOneRegion
<<merge>>
Kernel BasicBehaviors
Interfaces Ports
<<merge>>
<<merge>>
<<merge>>
StructuredActivities
Notation section shall be updated as the table below:
Issue6381Table.pdf
The text starts with “The following icons provide” through figure 395 shall be replaced
with the following:
Presentation options
Triggers and actions may be notated either textually or using graphical symbols
on a transition. This section describes the graphical presentation option.
The graphical action presentation of a transition consists of one or more graphical
symbols attached on a transition each representing a trigger or an action.
The sequence of symbols may consist of a single trigger symbol (or none), a
sequence of zero or more signal send or action sequence symbols. All the action
symbols are mapped to an activity containing a sequence node that sequences the
actions according to their graphical order on the transition path.
Each action symbol is mapped to an instance of an action in that sequence. In case of an actionsequence
symbol, it may be mapped to an opaque action or to a sequence of action or activity node
instances in case where the actions in the sequence symbols are mapped to the action semantics.
In principle, tools supporting the actions presentation options shall support also
the BasicActivities package and the StructuredActivities package, which are the
semantic concepts supporting that notation. Otherwise, the entire set of actions
in a transition shall be mapped to an opaque behavior, where there is no semantic
mapping to the action symbols. The graphical nodes split one logical transition to several graphical arrow segments, all mapped to a
single transition instance (see Figure 395). It is not prescribed here whether this graphical action
presentation is composed from a single graphical line segment with attached icons, or several line
segments connecting the icons. This is a tool issue and up to the decision of tool builders.
Signal receipt
The “signal receipt” symbol may be shown as a five-pointed polygon that looks
like a rectangle with a triangular notch in one of its sides (either one). It represents
the trigger of the transition. The textual trigger specification is denoted inside the
symbol, similar to the textual notation. Specifically, if the transition owns a guard,
the guard is also described within the signal receipt icon, using the textual
notation:
<trigger> ‘[‘ <guard> ‘]’
The signal receipt is always first in the path of symbols and a transition path can
only have at most one such symbol.
Signal sending
Signal sending is a common action that has a special notation. It may be shown as
a five-pointed polygon that looks like a rectangle with a protruding triangle on
one of its sides (either one). The actua l parameters of the signal are shown inside
the symbol. On a given path, the signal sending graphic must follow the signal
receipt icon if the latter exists.
The signal sending symbol maps to a SendSignalAction within the activity owned
by the transition on which the graphic is attached. If a tool uses only basic
actions, the sent signal may be captured within the body of an instance of an
opaque action. It is possible to have multiple signal sending nodes on a transition
path.
Action sequence
An action sequence node is a rectangle that contains a textual
representation of actions owned by the transition. The action
sequence symbol must follow the signal receipt symbol if one exists
for that transition. The action sequence symbol is mapped to an
opaque action, or to a sequence symbol containing instances of
actions recursively.
Note that the graphical action presentation option combines only the above symbols into a single
transition. Choice and junction symbols (see Figure 395) for example, are not mapped to actions on
transition but to choice and junction pseudo-states (note that similar symbols are also used in
activity graphs in which they map to actions, but in state machines they map to pseudo states).
Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches
of the choice through the junction symbol, and a transition from the junction to the busy state.


Issue 6396: UML 2 super / state machines / entry and exit actions cannot be redefined (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the current metamodel it does not appear as if state entry and exit actions can be redefined. Since transition actions can be redefined, this restriction does not make sense and should probably be removed. 

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
To be precise, actions on transitions are not redefined, but replaced. It is the transition
which is being redefined. Practically it allows the overriding of transition actions.
A similar approach should be taken for state actions and “doActivity” actions. Therefore,
the redefinition text for states on page 481 should be modified from:
“A simple state can be redefined (extended) to become a composite state (by adding a region) and a
composite state can be redefined (extended) by adding regions and by adding vertices, states,
entry/exit/do activities (if the general state has none), and transitions to inherited regions.”
To:
A simple state can be redefined (extended) to become a composite state (by adding a region) and a
composite state can be redefined (extended) by adding regions and by adding vertices, states, and
transitions to inherited regions. All states may add or replace entry, exit, and “doActivity” actions.


Issue 6397: UML 2 Super / state machines / restriction on redefining transitions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
On page 502, there is a constraint that says that if a transition has a non-unique par <source state, trigger> it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. 

Resolution: see above
Revised Text:
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
The rationale for the limitation is to allow visual determination of the redefinition
relationships without relying on tool specific
Capabilities. However in these cases where such graphical ambiguity exist, it can be
resolved by showing the conflicting transition(s) in the derived statemachine as well.
Furthermore, several tools supporting statemachine redefinition always show all the
“inherited” transitions so such disabiguity does not exist in the first place.
Therefore the proposed resolution is to remove the constraint. That is, remove the last
paragraph of the Transition redefinition subsection on page 502:
Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely
defined by this pair can be redefined. This excludes transitions with the same source, same trigger
but different guards from being redefined.


Issue 6399: UML 2 Super / Interfaces / Cannot nest classes in interfaces (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The Java spec says that it is legal to have Java Classes nested in Interfaces: 

9.1.3 Interface Body and Member Declarations 
The body of an interface may declare members of the interface: 

InterfaceBody:
                { InterfaceMemberDeclarationsopt }

InterfaceMemberDeclarations:
                InterfaceMemberDeclaration
                InterfaceMemberDeclarations InterfaceMemberDeclaration

InterfaceMemberDeclaration:
                ConstantDeclaration
                AbstractMethodDeclaration
                ClassDeclaration 
                InterfaceDeclaration
                ;


But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML 



Resolution: see above
Revised Text:
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
The associations of Interface where the nestedClass needs to be inserted
shows typos and omission of multiplicities, so we will fix those as well.
The proposed resolution allows more than just Interfaces definitions to be
nested in an Interface, but allows any kind of classifier to be nested. This
is achieved by rerouting the Interface::nestedInterface association end
from terminating on Interface to terminating on Classifier and changing its
name to: Interface::nestedClassifier. New Diagram replaces figure 58 on
page 112.
Current Text
Replace the following text in the Associations subsection New Text and Figure
Add Classifier and a composition from Interface to Classifier
ownedAttribute: Property[*] References all the
properties owned by the
Interface. (Subsets
Namespace.ownedMember and
Classifier.feature. )
ownedOperation: Operation[*] References all the
operations owned by the
Interface. (Subsets
Namespace.ownedMember and
Classifier.feature.)
nestedClassifier: Classifier[*] References all the
Classifiers owned by this
Interface. (Subsets
Namespace.ownedMember.)
redefinedInterface: Interface[*] References all the
Interfaces redefined by
this Interface. (Subsets
Element.redefinedElement.)


Issue 6400: UML 2 super / Activities / structured activity node contradiction (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Activity::structuredNode subsets both node and group, but structured activity nodes can only be contained in one place (either group or node); should it be derived? 

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
March 9, 2005: closed issue

Discussion:
Structured nodes are both nodes and groups, but this does not imply they are owned by
more than one thing. Groups are owned optionally by activities or other groups. Nodes
are owned optionally by activities, Structured nodes are inherit these possiblities, and
extend nodes to be optionally owned by structured nodes.
Disposition: Closed, no change


Issue 6401: UML 2 Super / Interface / missing owner of operation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property. 

Resolution: see below
Revised Text: interface: Interface[0..1] The interface that owns this operation. (Subsets RedefinableElement::redefinitionCont ext, NamedElement::namespace and Feature::featuringClassifier.) (EDITOR COMMENTS: Had to modify this fix to fit document conventions)
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
Agreed. We shall add such an operation. In Figure 11 of the Abstract Syntax,
both the Class and the (newly added) Interface attributes shall be added to the
diagram. In 7.3.36 of the 040725 Interim FAS, under the Attributes subsection,
insert text after the following existing text:


Issue 6402: UML 2 Super / Simple Time / incorrect multiplicities (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1 

Resolution: Duplicate of 6257
Revised Text:
Actions taken:
October 31, 2003: received issue
December 2, 2004: closed issue

Issue 6403: UML 2 Super / Activities / inconsistent naming (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent) to be consistent with the rest of the specification 

Resolution: This is duplicate with 6256.
Revised Text:
Actions taken:
October 31, 2003: received issue
December 2, 2004: closed issue

Issue 6404: UML 2 Super / Package Templates / StringExpression inconsistency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved. 

Resolution: see above
Revised Text:
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
The diagram in figure 438 is incorrect and does not match the text. The correct diagram is
shown below. In addition, the definition of the new metaclass StringExpression has been
omitted as well as the increment to ValueExpression. The following changes are required
to correct these problems.
?? Replace the diagram in figure 438 on page 560, with the following diagram:
ValueSpecification
ParameterableElement
(from TemplatesCommon) Expression
(from Kernel)
NamedElement StringExpression
0..*
0..1
+subExpression
{ordered,
subsets ownedElement}
0..1
0..1
+nameExpression
{subsets ownedElement}
?? Remove constraint [1] of NamedElement on page 560 because the effect is obtained
by using the explicit metaclass StringExpression.
?? Remove constraint [2] of NamedElement since it contradicts the text in the Semantics
section, which states that an element can have both the name and the nameExpression
?? Add the following two new metaclass descriptions after figure 439 on page 562: 17.5.12 StringExpression
An expression that specifies a string value that is derived by concatenating a set of sub-string
expressions, some of which might be template parameters.
Description
StringExpression is a specialization of the general Expression metaclass which adds the ability to
contain sub-expressions and whose operands are exclusively LiteralStrings.
Attributes
No additional attributes.
Associations
o subExpression : StringExpression[0..*] The StringExpressions that constitute this
StringExp ression. Subsets Element::ownedElement.
Constraints
[1] All the operands of a StringExpression must be LiteralStrings
operand->forAll (op | op.oclIsKindOf (LiteralString))
[2] If a StringExpression has sub-expressions, it cannot have operands and vice versa (this avoids the
problem of having to define a collating sequence between operands and subexpressions).
if subExpression->notEmpty()
then operand->isEmpty()
else operand->notEmpty()
Additional Operations
[1] The query stringValue() returns the string that concatenates, in order, all the component string
literals of all the subexpressions that are part of the StringExpression.
StringExpression::stringValue() : String;
if subExpression->notEmpty()
then subExpression->iterate(se; stringValue = ‘’|
stringValue.concat(se.stringValue()))
else operand->iterate()(op; stringValue = ‘’ |
stringValue.concat(op.value))
Semantics
A StringExpression is a composite expression whose elements are either nested StringExpressions or
LiteralStrings. The string value of the expression is obtained by concatenating the respective string
values of all the subexpressions in order. If the expression has no subexpressions, the string value is
obtained by concatenating the LiteralStrings that are the operands of the StringExpression in order.
Notation
See the notation section of NamedElement on page EDITOR.
Examples
See figure 439 on page EDITOR.
17.5.13 ValueSpecification (as specialized)
Description
StringExpression is a specialization of the general Expression metaclass which adds the ability to
contain sub-expressions and whose operands are exclusively LiteralStrings.
Attributes
No additional attributes.
Associations
No additional associations.
Constraints
No additional constraints.
Semantics
This adds the capability for ValueExpressions to act as template parameters.
Disposition: Resolved


Issue 6406: UML 2 Super / Deployments / node composition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Node::nestedNode should be an aggregate (containment by value) property

Resolution: Add the composition to the MDL and the spec.in figure 125
Revised Text:
Actions taken:
October 31, 2003: received issue
March 8, 2005: closed issue

Issue 6407: UML 2 super / Templates / parameters cannot have names (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The specification refers to template parameters by their names, implying that they are named elements; however, TemplateParameter is defined as a specialization of Element. Should TemplateParameter be a type of NamedElement? 

Resolution: This is the same issue as issue 6262.
Revised Text:
Actions taken:
October 31, 2003: received issue
December 2, 2004: closed issue

Issue 6425: UML 2 Infras./Interactions/ execution occurrence should not be abstract (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
ExecutionOccurrence should not be abstract, as it has no specializations

Resolution: see above
Revised Text:
Actions taken:
November 4, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
March 8, 2005: closed issue

Discussion:
Change meta-model and the corresponding Figure 326,328 to make ExecutionOccurence
a regular class.


Issue 6426: ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re Chapter 2, Components, Figure 2-15, p. 118: The figure caption
says that the figure is an example of connector wiring, but the text
directly below the caption says that the figure "may be used as a notation
option for dependency based wiring."  These two statements appear to be
contradictory.


Recommendation: To avoid having an ambiguous notation, specify that
dependency notation should be used for dependency based wiring.  (This
recommendation may be affected by the resolution of the issue submitted
about semantic distinctions between different ways to wire components
together).

Resolution:
Revised Text:
Actions taken:
November 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
The statement may need to be revised but is consistent with the Interfaces chapter. A
number of people have commented that the ball-and-socket notation is useful for
structural diagrams (e.g. Martin Fowler). Note that we have other occurrences in UML
where a notation has different meanings depending on context. E.g. a ‘straight line’ on a
structural diagram means an Association whereas on a composite structure diagram, it
means a connector.
Disposition: Closed, no change


Issue 6427: ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: In the definition of Connector in Chapter 3, Composite Structures, p.
137, the "end" Association's multiplicity is 2..*.  It is not clear what the
notation should be when the multiplicity is greater than 2.


Recommendation: Define a notation for Connectors when multiplicity is
greater than 2, or constrain the multiplicity to be 2..2.

Resolution:
Revised Text:
Actions taken:
November 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
The notation for connector uses the notation for association. Consequentially, connectors
with multiplicities larger than 2 are drawn using the diamond notation as described in the
Chapter on associations.
Disposition: Closed, no change.


Issue 6428: ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re the definition of Connector in Chapter 3, Composite Structures,
third paragraph of the Semantics section, which starts on p. 137 with "If
the type of the connector is ommitted...":  This paragraph is inpenetrable.


Recommendation: Re-write the section around concrete examples for each
point.

Resolution:
Revised Text:
Actions taken:
November 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
The indicated paragraph (now on p.164) describes how the type of a connector is inferred
if the type was omitted. It describes three scenarios: (i) the roles the connector is
associated with realize interfaces with an association between them; (ii) the connector
realizes a collaboration; (iii) anything else. The text is very clear in describing each
situation and how to find (or construct) the type of the connector.
Disposition: Closed, no change


Issue 6429: Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re the definition of Port in Chapter 3, Composite Structures, third
paragraph of the Notation section, which starts on page 142: This paragraph
discusses how to notate the multiplicity of a Port (last line of p. 142),
referring to Figure 3-35 on page 143.  However, the semantics of Port
multiplicity do not appear to be spelled out.


Recommendation: Define the semantics of the multiplicity of a Port.

Resolution:
Revised Text:
Actions taken:
November 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
The semantics of the multiplicity of a port is inherited from the semantics of structural
feature and property.
Disposition: Closed, no change


Issue 6431: ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re the definition of Port in Chapter 3, Composite Structures,
constraint [1], p. 146, which says: "The multiplicities on connected
elements must be consistent." This seems too vague.  Consistency needs to be
defined more precisely.


Recommendation: The English statement of the constraint should be expressed
directly in terms of the properties of the metamodel.  (The constraint
should be expressed in OCL too, of course.)

Resolution: see above
Revised Text:
Actions taken:
November 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
Different systems will have different rules for what is consistent, which means
that this is a semantic variation point. Proposed resolution:
?? In the Semantics sub-section of StructuredClassifier starting on page 174,
move the next-to-last an last paragraphs in the section (“The manner of
creation of the containing classifier….” and “All instances corresponding to
parts of a structured classifier…”) to be second and third paragraphs of
that sub-section respectively.
?? Following that paragraph, insert the following text:
Semantic Variation Point
The rules for matching the multiplicities of connector ends and those of parts and
ports they interconnect are a semantic variation point. Also, the specific topology
that results from such multi-connectors will differ from system to system. One
possible approach to this is illustrated in Figures 116 and 117 below.


Issue 6432: ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue: Re Chapter 3, Composite Structures, Table 3, p. 151: The "Reference"
column for Port refers to ComplexPorts.  ComplexPorts are not defined in the
specification.


Recommendation: Delete the reference to ComplexPorts and clarify the
language in the Reference column for Port accordingly

Resolution: see above
Revised Text:
Actions taken:
November 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Reference entry for Port in Table 6 on page 178, replace the last sentence
(“The optional ClassfierName is only used for ComplexPorts.”) with the following:
“The optional ClassifierName is only used if it is desired to specify a class
of an object that implements the port. “


Issue 6434: UML Superstructure: 03-08-02 / <<instantiate>> (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
Definition mismatch:


p. 108/109:
"...dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class."


p. 595:
"A usage dependency among classifiers indicating that
operations on the client create instances of the supplier."


Either use a <<create>> dependency on p. 108/109 or change definition on p. 595.


I think the instantiate dependency is a relationshp between an instance and its specification.

Resolution: Duplicate of issue 6159
Revised Text:
Actions taken:
November 5, 2003: received issue
December 2, 2004: closed issue

Issue 6437: targetScope on StructuralFeature and AssociationEnd (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
UMl 1.x supported targetScope on StructuralFeature and AssociationEnd. This does not seem to be present in UML 2.0 when looking at Property or elsewhere. For backward compatibility this should be reinstated or alternatively at least be a standard tag in Appndix B.

Resolution: see below
Revised Text: Insert a new section as follows: Changes from UML 1.x The property isStatic in UML 2 serves in place of the metaattribute ownerScope of Feature in UML 1. The enumerated data type ScopeKind with two values, instance and classifier, provided in UML 1 as the type for ownerScope, is no longer needed because isStatic is boolean. (2) Current Text: section 7.9.5 StructuralFeature on page 75 of FAS Revised Text: Insert a new section as follows: Changes from UML 1.x The metaatribute targetScope which characterized StructuralFeature and AssociationEnd in prior UML is no longer supported. (3) Current Text: section 7.11.2 Association, which ends on page 86 of FAS following Figure 36. Revised Text: Insert a new section to follow Figure 36, as follows: Changes from UML 1.x AssociationEnd was a metaclass in prior UML, now demoted to a member of Association. The metaatribute targetScope which characterized AssociationEnd in prior UML is no longer supported. Fundamental changes in the abstract syntax make it impossible to continue targetScope or replace it by a new metaattribute, or even a standard tag, there being no appropriate model element to tag. In UML 2, the type of the property determines the nature of the values represented by the members of an Association.
Actions taken:
November 5, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
March 8, 2005: closed issue

Discussion:
Both targetScope and ownerScope were in UML 1.4 and 1.5 of type ScopeKind, where
ScopeKind is an enumeration of values: instance, classifier. The definition of
ownerScope was: “denotes whether a feature belongs to individual instances or an entire
classifier.” For targetScope of AssociationEnd, UML 1.4 says: “Specifies whether the
target value is an instance or a classifier”.
Neither targetScope nor ownerScope nor ScopeKind made it into UML 2 under those
names, but of these three, the last two are supported under new names in new ways.
ownerScope for Feature was replaced in UML 2 by the metaattribute isStatic. There
ought to have been a “Changes from UML 1.x” section to explain this. The purpose of
ScopeKind (which had two enumerated values) is served by using boolean.
In contrast, targetScope for StructuralFeature and AssociationEnd was dropped
altogether, as a complication that had insufficient usage or clarity to merit continuance,
and thru the consolidation of attribute and association end by associations to Property. (In
the view of some, the target of a property is sufficiently modeled in UML 2 by the Type
of the property.) There ought to have been Changes sections for this also.
Three different insertions are needed.
(1) Current Text:
section 7.9.2 Feature on page 73 of FAS


Issue 6439: UML 2.0 significant typo - collaboration diagram (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:
In the UML 2.0 Superstructure final adopted specification 
document 03-08-02 (and all previous versions), the phrase 
"collaboration diagram" appears in the last row of Figure 464 on 
page 590, and in no other place in the entire document. This 
occurrence probably missed the global change from "collaboration 
diagram" to "communication diagram". This is a key figure that is 
likely to be reproduced in many articles and slide sets, and 
should be fixed. 

Resolution: This is the same as issue 6066.
Revised Text:
Actions taken:
November 6, 2003: received issue
December 2, 2004: closed issue

Issue 6440: Excessive syntactic and semantic overlap between structured Classifiers (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
 There is excessive syntactic and semantic overlap between two
kinds of structured Classifiers: StructuredClasses::Classes and Components.
It is confusing to users how to choose between these constructs, and how to
apply them correctly. The confusion extends to how Ports and Interfaces are
used with these constructs, since it is unclear how to use both of these in
a complementary manner.
Recommendation: Remove one of these structured Classifiers, or clarify how
to choose between and apply them. Also explain how to apply Ports and
Interfaces in a complementary manner for both black-box and white-box views
of structured Classifiers.


Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
The issuer may not have been aware that this overlap is due to the fact that Component is
simply a special kind of structured Class, so that this “overlap” is to be expected.
Components should be used where the additional specializations that they provide are
useful.
Disposition: Closed, no change


Issue 6442: Specification of parametric models (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: It is unclear how to specify parametric models as they are used
in systems engineering. In particular, it is unclear how to specify
mathematical or logical equations (e.g., Force = mass * acceleration) that
constrain the values of classifier attributes/properties. Systems engineers
must be able to:
a) Specify the dependencies between parameters and expressions or
constraints. This must support arbitrarily complex and continuous time
equations.
b) Allow parameters to be passed into expressions.

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
To enable writing mathematical formulas for constraints, UML 2 provides the option to
write constraints in languages othe r than UML and OCL and include the result in a UML
2 model as an Expression and/or OpaqueExpression, which are then referenced as the
body of a UML 2 Constraint. Expressions and OpaqueExpression are the model elements
provided for such purposes. For this reason, they are provided with an attribute to
indicate their language.
The Issue is correct in noting that UML 2 itself does not include the language of applied
mathematics. UML 2 does permit reuse of the same mathematical expression in more
than one constraint, and allows the choice of a language other than UML. Users of UML
2 are advised to choose whatever constraint langugage best meets their special
requirements.
A detailed review of the relevant parts of UML 2 are as follows:
7.6.1 Constraint states A user-defined Constraint is described using a specified
language, whose syntax and interpretation is a tool responsibility. The Associations of
Constraint include its specification, which is a ValueSpecification[0..1]
ValueSpecification is an abstract named and typed model element, with concrete
subclasses Expression and OpaqueExpression. OpaqueExpression (7.5.2) has attributes
body (a mandatory string) and an optional attribute to indicate the language of the string.
The same expression or opaqueExpression instance can be used as the ValueSpecification
for any number of constraints. These are the means provided by UML 2 to specify parametric mathematical models as a
constraint, and to re-use the same mathematical expressions in as many constraints as one
wishes.
It is not appropriate to defer this issue to another revision of UML, because it is not
within the intended scope of UML to reproduce or replace the familiar notations of
mathematical physics and various mechanical and electronic engineering disciplines.
sysML can identify a branch of mathematics as the default language for constraints, and
can extend the metamodel such that a new subtype of constraint is recognized which uses
such language by default.
A suitable choice of a mathematical constraint language, other than OCL, is
recommended to submitters responding to the sysML RFP
Disposition: Closed, no change


Issue 6443: The name "required interface" is misleading (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
The name "required interface" is misleading
Description: The name "required interface" is misleading, since a required
interface is not really an interface; it is a usage of an interface.
Recommendation: Rename "required interface" to something more descriptive

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
The same can be said for “provided” interface. People generally understand that
“provided interface” is an implementation of an interface, not a (subtype of) Interface.
The same applies to “required interface”, which is a usage of an interface. Perhaps a more
descriptive adjective can be found, but unless a concrete, intuitive term is suggested we
should stick with “required interface”.
Disposition: Closed, no change


Issue 6447: Corrections and improvements to glossary definitions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: Consider the following corrections and improvements to Terms
and Definitions:


Activation ­ Consider changing from “the execution of an action” to
“initiating the execution of an action”.


Analysis ­ Delete the term “software”.


Artifact ­ Delete the term “software”.


Comment ­ Replace term “note” with “comment”.
Runtime. run-time for a physical system, to imply execution of the
operational system. (S-pg 252)


Deployment diagram ­ Replace “software artifacts as nodes” with “artifacts
on nodes”. Delete the term software and change as to on.


Design ­ Delete the term “software”. Delete “required functional and
 quality”. This is too restrictive, and doesn't include physical
requirements, etc.


Design time - Delete the term “software”.


Development process - Delete the term “software”.


Diagram ­ Update the types of diagrams to be consistent with the proposal
(i.e. timing diagrams, structure diagrams, information flow, etc)


Generalization ­ Insert “indirect” prior to “instance of the general
classifier”.


Inheritance ­ Delete last fragment “related by behavior”.


Interaction diagram ­ Include reference to timing diagram.


Interaction overview diagram ­ delete “s” on nodes


Layer ­ Don’t restrict the use of the term partition to reflect a vertical
slice of the architecture. This is too limiting. Add a qualifier such as
may.


Modeling time - Delete the term “software”.


Module - Delete the term “software”.


Object diagram ­ should this be replaced with Instance diagram.


Part ­ Add the following after classifier instance “or roles of a
 classifier”. Reference the definition for “Role”, which provides
clarification.


Partition - Don’t restrict the use of the term partition too much. Partition
can reflect the grouping of any set of model elements based on a set of
criteria.


Run time ­ Insert after “computer program” “or a system”.


Specification ­ Consider changing the definition to “a set of requirements
for a system or other classifier.


Subsystem ­ Replace “See package” with “See system”


System ­ Replace system definition with the following: A component which
contains parts, and has observable properties and behaviors.


Trace ­ Add the following ­ A dependency between a derived requirement and a
source requirement


Use case diagram ­ Change from “A diagram that shows the relationships among
actors and use cases within a system” to “A diagram that shows the
relationships among actors, the subject (system), and use cases

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
The glossary has been completely removed from the specification as a result of the
resolution to issue 6211. Therefore, these recommendations are no longer applicable
Disposition: Closed, no change


Issue 6448: Inconsistent use of terms "implement" and "realize" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: The terms “implement” and “realize” are used inconsistently
throughout the specification. These terms should be defined in the glossary
(Preface, Terms and Definitions) and applied consistently throughout the
specification.


Resolution: see above
Revised Text:
Actions taken:
November 6, 2003: received issue
March 8, 2005: closed issue

Discussion:
The confusion arises mostly because of the introduction of the new metaclass
“Implementation”, which is a specialization of the “Realization” metaclass for the case
where a classifier realizes an interface. This introduces a differentiation between two
terms that were used synonymously in the past and also in other parts of the specification.
The problem will be solved by renaming the concept of “Implementation” to
“InterfaceRealization”. This frees up the term “implementation” from its very specialized
semantics, allowing it to be used interchangeably with the term “realization”. (The
alternative of revisiting the 600 or so occurrences of these two terms and adding
clarifying text is impractical.)
The following changes need to be made:
?? Replace the diagram in figure 58 on page 112 with the following diagram:
Realization
(from Dependencies)
Property
(from Kernel)
Operation
(from Kernel)
Interface
*
0..1
+nestedInterface
{ordered, subsets ownedMember}
{subsets namespace,
subsets redefinitionContext}
*
*
+redefinedInterface {subsets redefinedElement}
*
0..1
+ownedAttribute
{ordered, subsets attribute, subsets ownedMember}
{subsets classifier, subsets namespace,
subsets featuringClassifier}
0..1
*
{subsets redefinitionContext}
+ownedOperation
{ordered, subsets feature, subsets ownedMember}
InterfaceRealization ?? In the Description sub-section of the BehavioredClassifier class on page 113 replace
the line:
A BehavioredClassifier may have implementations.
with the following line:
A BehavioredClassifier may have interface realizations.
?? Replace the item for “implementation” in the Associations sub-section of
BehavioredClassifier class on page 113 with the following entry:
?? interfaceRealizations : InterfaceRealization [*] (Specializes Element.ownedElement and
Realization.clientDependency.)
?? Replace the title and Description section of Implementation on page 113:
7.15.2 Implementation (from Interfaces)
Description
An Implementation is a specialized Realization relationship between a Classifier and an Interface.
The implementation relationship signifies that the realizing classifier conforms to the contract
specified by the interface.
with the following text fragment:
7.15.2 InterfaceRealization (from Interfaces)
Description
An InterfaceRealization is a specialized Realization relationship between a Classifier and an
Interface. This relationship signifies that the realizing classifier conforms to the contract specified
by the Interface.
?? Replace the last paragraph of the semantics section of Implementation on pages 113
and 114:
An implementation relationship between a classifier and an interface implies that the classifier
supports the set of features owned by the interface, and any of its parent interfaces. For behavioral
features, the implementing classifier will have an operations or reception for every operation or
reception, respectively, owned by the interface. For properties, the implementing classifier will
provide functionality that maintains the state represented by the property. While such may be done
by direct mapping to a propertyof the implementing classifier, it may also be supported by the
state machine of the classifier or by a pair of operations that support the retrieval of the state
information and an operation that changes the state information.
with the following text fragment (no te that this also fixes several typos in the
above):
An interface realization relationship between a classifier and an interface implies that the classifier
supports the set of features owned by the interface, and any of its parent interfaces. For behavioral
features, the realizing classifier will have an operation or reception for every operation or
reception, respectively, defined by the interface. For properties, the realizing classifier will provide
functionality that maintains the state represented by the property. While such may be done by
direct mapping to a property of the realizing classifier, it may also be supported by the state
machine of the classifier or by a pair of operations that support the retrieval of the state
information and an operation that changes the state information.
?? Replace the first sentence of the second paragraph of the Notation sub-section of
Interface on page 115: 2.0 Superstructure FTF
Disposition: Resolved
OMG Issue No: 6448
Document {Report document number} Page 323
The implementation dependency from a classifier to an interface is shown by representing the
interface by a circle or ball, labelled with the name of the interface, attached by a solid line to the
classifier that implements this interface (see Figure 59).
with the following phrase (this also fixes some typos in the above text):
The interface realization dependency from a classifier to an interface is shown by representing the
interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the
classifier that realizes this interface (see Figure 59).
?? Replace the first sentence of the first paragraph of the “Presentation option” subsection
of Interface on page 116:
Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage
dependencies to provided and required interfaces, respectively, may be shown using dependency
arrows (see Figure 62).
with the following phrase (this also fixes some typos in the above text):
Alternatively, in cases where interfaces are represented using the rectangle notation, interface
realization and usage dependencies are denoted with appropriate dependency arrows (see Figure
62).
?? Replace the third bullet item in the “Component diagram” sub-section on page 149:
o Realization, Implementation, Usage Dependencies
with the following item:
o Realization, Interface Realization, Usage dependencies


Issue 6449: Diagram Taxonomy corrections (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Description: The diagram taxonomy should be corrected as follows:
a) "Collaboration Diagram" as a subtype of "Interaction Diagram" should be
renamed "Communication Diagram";
b) "Collaboration Diagram" should be added as a subtype of "Composite
Structure Diagram";
c) "Interaction Diagram" should be classified as a subtype of "Sequence
Diagram" and "Activity Diagram"

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
Item (a) is a duplicate of issue 6066 (already resolved).
For item (b) all the various kinds of composite structure diagrams are deemed to be the
same kind of diagram type, whether they represent collaborations or internal class
structures.
For item (c), the submitter probably meant “Interaction Overview Diagram” instead of
“Interaction Diagram”. However, while there are some shared syntactical elements
between activity diagrams and communication overview diagrams (such as the fork and
join notations), the semantics of these are not the same. So, it is not correct to show them
as subtypes of Activity Diagrams.
Disposition: Closed, no change


Issue 6450: Removal of gratuitous restrictions to software applications (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
Removal of gratuitous restrictions to software applications
Description: UML is being used extensively for systems modeling as well as
software modeling. Consequently, gratuitous restrictions to software
applications should be removed from the specification.

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
March 9, 2005: closed issue

Discussion:
While this is probably true, the issue statement is too vague and to general. Without a
concrete list of issues that identify where and how systems modeling is impeded by the
current definition of UML, this issue is not meaningful.
Disposition: Closed, no change


Issue 6453: UML 2.0 Superstructure FTF issue - Profiles (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:
In the Profile chapter, there is no section for "Changes from UML 1.4" for
stereotypes


However, one feature of UML1.4 : attaching tagged values independently of
any stereotype, has disappeared in UML2.0


The evolution tagged values --> attribute should be discussed and that
particular case enlighted. a specific pattern for converting UML1.4
stereotype independant tags into UML2.0 should be provided.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Class description : Stereotype, Notation
Add at the end of the paragraph “Presentation option”
It is a semantic variation point that a tool can choose to display or not
stereotypes. In particular, some tools can choose not to display “required
stereotypes”, but to display only their attributes (tagged values) if any.
In Class description : Stereotype
Add at the end (just before 18.4) the following paragraph
Changes from previous UML
In UML1.3, tagged values could extend a model element without the required presence of
a stereotype. In UML1.4, this capacity, although being still supported, was recommended
to use only for backward compatibility reason. In UML2.0, a tagged value can only be
represented as an attribute defined on a stereotype. Therefore, a model element must be
extended by a stereotype in order to be extended by tagged values. The usage of the
“required” extension mechanism can however provide an automated stereotype
extension, on which attributes can be valuated. The end user service can therefore be very
close to the one provided by UML1.3, depending on tool support of this functionality.


Issue 6454: 14.3: StateInvariant and ExecutionOccurrence (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
14.3: StateInvariant and ExecutionOccurrence are both subclasses of InteractionFragment.  "Each interaction fragment is conceptually like an interaction by itself." [14.3.9] And, indeed, "An ExecutionOccurrence is an instantiation of a unit of behavior..." [14.3.4]  But, "A StateInvariant is a constraint on ... state..." [14.3.17]  That's not like an interaction by itself, nor like any interaction at all.  We've mixed models of behavior with specifications of constraints on state.


This is an example of a recurrent problem in the specification: subclasses that are not like their superclasses.
...


Suggested resolution:  Review the specification with this in mind and correct all improper subtyping

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
It seems that the submitter missed the fact that the interactions metamodel is actually a
syntactically-oriented metamodel rather than a semantically-oriented one. That is, the
concepts in this metamodel are derived from their role in the abstract syntax of
interactions rather than the semantic entities that they represent. Thus, the concept of
InteractionFragment is a syntactical notion (something that is attached to a lifeline), and
not a semantic notion. So, in this case, there is no problem of subclasses not being like
their superclasses, since each specialization of InteractionFragment inherits all the things
from its superclass.
Perhaps the interactions metamodel could have been organized differently, but that kind
of rearrangement is out of scope for an FTF.
Disposition: Closed, no change


Issue 6457: Abandon the OMGS4LMMA (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
If the so-called OMGS4LMMA is accepted, it is not possible that an InformationFlow could connect both Classes and Instance Specifications.
...


Suggested resolution: Abandon the OMGS4LMMA.  Apply InstanceSpecification uniformly (for example, an informationFlow is used to connect classes and an instanceSpecification  of an informationFlow is used to connect instanceSpecifications of classes, that is, to connect objects.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The issue is not clear what document changes are required to ‘abandon the
OMGS4LMMA’: in general in the past restrictions claimed as a result of the 4 layer
metadata architecture were based on a misunderstanding rather than anything
documented in an adopted specification. There is nothing (e.g. in section 7.2 of
Superstructure, in particular 7.2.8) to stop linking of classes at different meta-levels:
indeed this is used in Profiles.
With respect to the example of InformationFlows these do not in fact cross meta- levels
since an instance of InstanceSpecification is at the same level (M1) as an instance of
Class: as section 7.2.9 of Superstructure states “The instances, which are sometimes
referred to as “run-time” instances, that are created at M0 from for example Person
should not be confused with instances of the metaclass InstanceSpecification that are also
defined as part of the UML metamodel“
Disposition: Closed, no change


Issue 6458: Change 'Part' to 'Role. (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
In the UML 1 specification, "every time a word coinciding with the name of some construct in UML is used, that construct is referenced." [UML 1  2.3.4]


In the UML 2 specification, the word, 'part,' is used both to mean a Part and with its ordinary meaning.


This is an example of a recurrent problem in the specification: words that name UML 2 concepts are used both to refer to that concept, or an instance of that concept, and with their ordinary meaning.  The rule of the UML 1 specification needs to be both stated and carefully followed.
...


Suggested resolution: Change 'Part' to 'Role.'  This permits the use of 'part' to mean part.  Add the rule of the UML 1 specification.  Carefully follow that rule.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The issue suggests a massive rewrite needing very careful attention. Note that
'part' is not synonymous with 'role': A role is a ConnectableElement referenced
by a StructuredClassifier, while a part is a property specifying instances that a
classifier owns by composition. All parts are roles, but not every role is a part.
However, the issue is correct in that many times when "part" is used informally in
the specification, "role" could be used instead. To implement this suggestion,
every occurrence of the term "part" would need to be examined carefully. (There
may be also some impact if Port is made a property.) We could of course blanket
replace part by role and then introduce another term for role. As it stands, the
value of this suggestion may be questionable.
Disposition: Closed, no change


Issue 6459: glossary (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Uncategorized Issue
Severity:
Summary:
The glossary included with the appendices of the text that was adopted by the voters has been removed and that text inserted as normative text.  There is no authority for the editors preparing the final adopted specification to make this major change.  To make matters worse, the change introduces contradictions into the normative part of the specification.
...


Suggested resolution:  Move this text back where it came from.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
This issue was resolved with the resolution to issue 6211, when the glossary was moved
out of section 4. (NB: This resolution is independent of the question of whether there
should be a glossary in the spec or not and, if there is, what it should look like – which is
still under discussion as this resolution is proposed..)


Issue 6461: UML 2 Issue: Connector types (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
This is the definition of Connector (Superstructure, p. 163): "Specifies a
link that enables communication between two or more instances. This link may
be an instance of an association, or it may represent the possibility of the
instances being able to communicate because their identities are known by
virtue of being passed in as parameters, held in variables, created during
the execution of a behavior, or because the communicating instances are the
same instance. (...)"

This paragraph is clearly a reinterpretation of the five old association and
link stereotypes, now obsolete. Let's rewrite the second sentence as
follows, inserting those old stereotypes for clarity:

This link may be an instance of an association, <<association>>
or it may represent the possibility of the instances being able to
communicate because their identities are known 
by virtue of being passed in as parameters, <<parameter>>
(by virtue of being) held in variables, <<???>>
(by virtue of being) created during the execution of a behavior, <<local>>
or because the communicating instances are the same instance. <<self>>

It seems that the concept conveyed by the old <<global>> stereotype has
completely disappeared (probably an improvement). But the comma between the
words "variables" and "created" suggests that a new kind of connector, or
link, has been introduced. But maybe the true intention of the writer was:

(by virtue of being) held in variables created during the execution of a
behavior, <<local>>

That is, the comma between the words "variables" and "created" would be
superfluous. It is not very important whether the kinds of Connector
correspond to the old stereotypes, but it is important to know how many
kinds of Connector there are.

PROPOSED SOLUTION
Suppress the comma between the words "variables" and "created". 

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

Discussion:
Change the quoted sentence to “…passed in as parameters, he ld in variables or slots, or
because the communicating instances are the same instance.”


Issue 6465: UML 2 Issue: Include(s) and Extend(s) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT
The notation for the Extend and Include relationships is a dashed arrow with
open arrow and the keyword <<extend>> or <<include>> (Superstructure, pp.
516, 518). Nevertheless, the notation examples given in pages 521, 523 and
524 write "extends" and "includes", with an final "s". The other examples
are allright.

PROPOSED SOLUTION
Fix the notation examples.


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

Discussion:
?? Replace the diagram in figure 406 on page 521 with the following diagram:
??
package TransactionUseCases
package ATM Services
package Administration
Card
Identification
Perform ATM
Transaction
On-Line
Help «extend»
condition: {customer
selected HELP}
extension point: Selection
Withdraw Transfer Funds Deposit
Funds
«includes»
«include»
Read Log
Register ATM
at Bank  ?? Replace the Notation entry for “Extend” in Table 22 on pg. 523 with the
following diagram
Perform ATM Transaction
«extend» extension points
Selection
?? Replace the Notation entry for “Extend (with Condition)” in Table 22 on pg. 523
with the following diagram
«extend»
Condition: {customer selected HELP}
extension point: Selection
?? Replace the Notation entry for “Include” in Table 22 on pg. 524, with the
following diagram:
Withdraw
Card
Identification


Issue 6468: Section 7.3.1 ElementImport (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Semantics discussion includes the statement
An imported element can be further imported by other namespaces using either element or member imports.
 
The phrase "member import" is not defined and does not appear anywhere else in the spec.  What does it mean?   Provide an example of member import.

Resolution: see above duplicate
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Discussion:
This issue is a duplicate of a portion of #6168, which see for resolution. Because this is
shared by the UML2 Superstructure FTF and the MOF2/UML2 Infrastructure FTF, this
duplicate closure applies to documents ptc/03-08-02 and ptc/03-09-15.
Disposition: Duplicate


Issue 6469: Section 7.3.5 PackageImport (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
This section is unique because it does not have a Notation section like all of the others

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
Section 7.3.5, page 38, of the UML2 Superstructure FAS (ptc/03-08-02) and the
corresponding section 11.6.5, page 145, of the UML2 Infrastructure FAS (ptc/03-09-15)
both contain Notation sections. The text in the Superstructure document has an identical
paragraph in the Infrastructure text.
The Notation section in the Infrastructure document contains an additional paragraph that
does not appear in Superstructure document. This paragraph is related to the subject of
issue 6168 and will be dealt with in the resolution of that issue.
Disposition: Closed, no change


Issue 6471: Section 7.13.2 Package Merge (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 47.  Some of the relationships appear to be generalization and some appear to be realization.  It is not clear when Package Merge is useful or necessary.  A more concrete example would help

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
A more comprehensive explanation of the rationale for package merge has been provided
as part of the resolution to issue 6279. Clarifications are given of the abstract example in
47. However, the UML metamodel itself is a concrete and extremely comprehensive
example of the usage of package merge. This too has been pointed out in the text for the
resolution to issue 6279.


Issue 6472: Section 7.15.3 Interfaces (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The text states "Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62)."  Figure 62 has an association and a generalization relationship, not dependencies.

Resolution: This issue was resolved by the resolution to issue 6069.
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Issue 6473: Section 7.18 Diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Table 4 - the Package Import dependency should be <<access>> not <<uses>>.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
(1) Add a table entry after the Realization entry in Table 4, with the following
fields:
?? Path Type: Usage
?? Notation of:
<<use>>
?? Reference: See Usage (from dependencies) on page 100
(2) Remove the table entry for “PackageImport (private)”
(3) Remove the “(public)” modifier from the Path Type entry of “PackageImport
(public)”


Issue 6474: Section 8.1 Overview (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both.  They are not required to have both types.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Replace the third sentence of the second paragraph in section 8.1 on page 133 from:
It has one or more provided and required interfaces (potentially exposed via
ports), and its internals are hidden and inaccessible other than as provided by its
interfaces
with:
It has one or more provided and/or required interfaces (potentially exposed via
ports), and its internals are hidden and inaccessible other than as provided by its
interfaces


Issue 6475: Section 8.3.1 Component (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 81 should have identifiers for the provided interfaces.  Figure 83 is not consistent with section 7.15.3 in that it uses a realization instead of a dependency as described in the text related to Figure 62.  The examples in this section are not cohesive.  It is not clear how Figure 85 relates to the rest of the examples.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Add to figure 81 the following two name labels with the provided interfaces that are
currently unlabeled: “ItemAllocation” and “Tracking”.
Figure 83 is correct in using Dependencies to denote the provided and required interfaces
in the type declaration of a component (in this case, one without ports). Note that section
7.15.3 has been revised as a result of other issues logged.
It is correct that the set of examples in this chapter (as in others) do not form a single
complete worked example. This is left to books and other publications.


Issue 6476: Section 8.3.1 Component (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 89 and 90.  The text states "A component is shown as a Classifier rectangle with the keyword «component». Optionally, in the right hand corner a component icon can be displayed."  Some of the example components do not have the <<component>> included, just the icon is present.  My reading of the text is that this is incorrect.  The icon is optional but the <<component>> designation is required

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Tools may omit stereotype labels (if the context is clear). However, this is a
general notation feature, and the Component chapter should add the Stereotype
labels in figures 83, 85, 86, 87, 89 (one component label has shifted downwards
in the picture), 90, 91.


Issue 6477: Section 8.3.3 Realization (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The text states, "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."  What is an open arrowhead.  Compare and contrast that with the "stick arrowhead" described in the Presentation Options section of Class in Composite Structures (page 156).  Stick arrowhead can be found 6 times in the spec, while open arrowhead can be found 4 times.  They all appear to refer to the same notation.  I recommend that you chose one term.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Makes sense to use one term throughout spec. A search on Google returns more hits for
“open arrowhead” which appears the more general term.
Replace “stick arrowhead” with “open arrowhead” everywhere in the spec (search and
replace)


Issue 6478: Section 9.4 Diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Table 6.  The Collaboration and CollaborationOccurrence notation is incorrect

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The symbols for Collaboration and CollaborationOccurrence in Table 6, p.179, should be
shown with dashed outlines.


Issue 6479: Section 10 Deployments (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 130 and 131.  If these are meant to be two representations of the same node, then make the contents the same or explain the differences. Figure 136 should be <<ExecutionEnvironment>> vice <<container>>.  Either that or the text is incorrect and needs to be changed

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
Figures 130 and 131 are not meant to be identical, but merely illustrations using
some of the same terms.
Figure 136 is incorrect, but this issue is a duplicate of issue 6924.
Disposition: Closed, no change


Issue 6480: Section 14.3.14 Message (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
The semantics section states, "There will normally be a return message from the called lifeline..."  while the Notation section refers to "The reply message from a method has a dashed line."  If the return message and the reply message are the same ting then only use one name.  If they are differnt, then explain the difference

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Page 429 change text (last paragraph):
If the Message represents a CallAction, There will normally be a return message
from the called lifeline back to the calling lifeline before the calling Lifeline will
proceed.
to:
If the Message represents a CallAction, there will normally be a reply message
from the called Lifeline back to the calling Lifeline before the calling Lifeline will
proceed.
Page 417 change text of last sentence in last paragraph from:
Typically the start Eventoccurrence and the finish Eventoccurrence will refer to
Eventoccurrences such as a receive Eventoccurrence (of a Message) and the
send Eventoccurrence (of a return Message).
To:
Typically the start Eventoccurrence and the finish Eventoccurrence will refer to
Eventoccurrences such as a receive Eventoccurrence (of a Message) and the
send Eventoccurrence (of a reply Message).


Issue 6481: Section 14.4 Diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Table 15.  The text describing message states, "asynchronous message, a call and a reply" but the graphic shows them in the order of call, asynchronous, reply.  The text should match the graphic.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The graphics in table 15 is correct.
Disposition: Closed, no change


Issue 6482: Section 14.4 Diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the text describing Figure 345 it states, "Thus the appearance of a w message after the v is an invalid trace."  There is no w message in the diagram.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The explanation of Figure 345 is correct: operator Consider may describe messages that
are not necessarily present on the diagram. The example means that message v should be
followed by q and not by either v or w.
Disposition: Closed, no change


Issue 6483: Section 14.4 Diagrams (02) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Table 19 the Message entry- it is unclear which message is which and I don't think any of them are reply messages

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
Duplicate of 6482
Disposition: Closed, no change


Issue 6484: Section 17 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Page 534 states, "When it is attached to an information channel, a black triangle on the information channel indicates the direction."  What is an information channel?  This is the only sentence in the document in which this phrase is used.


Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 532, add the following sentence at the end of the Description sub-section of
InformationFlow:
Information flows require some kind of “information channel” for transmitting
information items from the source to the destination. An information channel is
represented in various ways depending on the nature of its sources and targets.
It may be represented by connectors, links, associations, or even dependencies.
For example, if the source and destination are parts in some composite structure
such as a collaboration, then the information channel is likely to be represented
by a connector between them. Or, if the source and target are objects (which are
a kind of InstanceSpecification), they may be represented by a link that joins the
two, and so on.


Issue 6485: Appendix A Diagrams (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 464 includes a Collaboration Diagram. Is this a carryover error from UML 1.x or a reference to a diagram that contains Collaborations and CollaborationOccurrences

Resolution: This is the same issue as issue 6066
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Issue 6486: Clarify termination of asynchronous invocations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Clarify that asychronously invoked behaviors/operations aren't
terminated by activity final

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Semantics section of ActivityFinalNode, p 298, in the first paragraph, add this after
the first sentence:
"Any behaviors invoked asynchronously by the activity are not affected."


Issue 6488: Conditions for parameter sets (02) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Parameter sets need conditions for pre/postconditions

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
updated figure below (includes resolution of 6109):
In ParameterSet,
in Associations section, add this entry in alphabetical order with the
others:
“condition : Constraint [*] Constraint that should be satisified for the
owner of the parameters in an input parameter set to start
execution using the values provided for those parameters, or the
owner of the parameters in an output parameter set to end
execution providing the values for those parameters, if all
preconditions and conditions on input parameter sets were
satisfied.” in Semantics section, in the first paragraph, at the end add the sentence:
"The semantics of conditions of input and output parameter sets is
the same as Behavior preconditions and postconditions,
respectively, but apply only to the set of parameters specified.”


Issue 6490: Protocol machines do not subset state invariant (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Protocol machines subset guards, but not state invariant.  What's the
difference?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
Guards are interpreted in the sense of pre and post conditions under protocol stat
machine, which is a different meaning as a guard for a behavioural state.
State invariant has the same interpretation for both kinds of state machines. So there is no
reason to redefine or subset it. Historically, this feature has been created under protocol
state machine, and be generalized for all SM, though it has been judged that it is of a
general interest.
Disposition: Closed, no change


Issue 6491: Outputting constants (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
How are constants introduced in a flow, eg, to output a constant to an
activity parameter node?  UML 1.5 had GetLiteralAction to output a
constant.  Reintroduce it or some construct that has the same effect.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
ValuePin is a kind of InputPin that provides inputs to actions based on value
specifications. It has the following problems:
ValuePin cannot provide values for output activity parameter nodes. In
particular, it cannot be used to dynamically choose what value
specification to output to an activity paramater nodes, for example, with a
decision node (see example below).
ValuePin is is not flexible in when it is evaluated. It can only be evaluated
as an input to an action when the other inputs are already available.
A number of alternatives have been suggested:
?? Use a ValuePin with a CallBehaviorAction to a dummy behavior that
outputs the same value that is input to it. Most users find dummy
behaviors too cumbersome.
?? Use a value specification as a default value for an output parameter. This
does not address either of the above problems with ValuePin, since they
cannot be used for dynamically chosen values (see example below).
?? Use ConditionalAction with input value pins that each flow to an output pin
on only one the conditional branches. This is even more cumbersome
than dummy behaviors.
Consequently, the current metamodel is not backwardly compatible with UML 1.5
LiteralAction. Add an action for evaluating a value specification as described below.
In Figure 144, add ValueSpecificationAction, as shown (with change from 6222,
and consolidated layout In Actions chapter, insert new entry for ValueSpecificationAction alphabetically
as follows:
ValueSpecificationAction
ValueSpecificationAction is an action that evaluates a value specification.
Description
This action returns the result of evaluating a value specification.
Attributes
None.
Associations
value : ValueSpecification [1..1] (Specialized from Action:output) Value specification to
be evaluated.
Constraints
[1] The type of value specification must be compatible with the type of the result
pin.
[2] The multiplicity of the result pin is 1..1.
ReadSelfAction
OutputPin
(from BasicActivities)
Classifier
(from Kernel)
CreateObjectAction
1
0..1
+result
{subsets output}
1
*
+classifier Action
(from BasicActivities)
InputPin
(from BasicActivities)
DestroyObjectAction
isDestroyLinks : Boolean = false
isDestroyOwnedObjects : Boolean = false
1
0..1
+target {subsets input}
InputPin
(from BasicActivities)
TestIdentityAction
1
0..1
+first {subsets input}
1
0..1
+second {subsets input}
ValueSpecification
(from Kernel)
ValueSpecificationAction
1 0..1
+value
OutputPin
(from BasicActivities)
1
0..1
+result
{subsets output}
1
0..1
+result
{subsets output}
1
0..1
+result
{subsets output} Semantics
The value specification is evaluated when the action is enabled.
Notation
The action is labelled with the value specification, as shown below.
Figure – ValueSpecificationAction notation
Examples
The figure below shows a value specification action used to output a constant
from an activity.
Figure – Example ValueSpecificationAction
Rationale
ValueSpecificationAction is introduced for injecting constants and other value
specifications into activity flow.
Changes from previous UML
ValueSpecificationAction replaces LiteralValueAction from UML 1.5.
value specification
5
Integer
6


Issue 6499: Multiobject in UML2 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I am looking for the multiobject in the UML2 spec. 


It is defined in the UML1.5 spec. as part of the collaboration
diagram. The multiobject is shown as two rectangles in which
the top rectangle is shifted slightly vertically and horizontally.


Is this still valid for UML2? Where can I find the definition in the 
spec?

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

Discussion:
The multiplicity of a part in a collaboration is shown either by a multiplicity specification
in the upper right-hand corner of the part or between square brackets following the name
of the part. If no multiplicity is specified, it defaults to 1. Examples of this notation can
be seen in Figure 115.
Disposition: Closed, no change


Issue 6504: ActivityFinalNode and running actions - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
Reaching an ActivityFinalNode terminates the activity.
What happens to running actions within the activity? 


Is there an interruption? Or do they run to completion?


Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
In ActivityFinalNode, Semantics section, first paragraph, replace the first
sentence with:
“A token reaching an activity final node terminates the activity. In
particular, it stops all executing actions in the activity, and destroys all
tokens in object nodes, except in the output activity parameter nodes.
Terminating the execution of synchronous invocation actions also
terminates whatever behaviors they are waiting on for return.”


Issue 6505: Use Case Metamodel - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
I tried to understand some parts of the Use Case metamodel but get
stucked ...


Looking at figure 10-49 (p. 468) of the current (i.d. 3rd rev)
Superstructure document it is not clear or at least not that obvious 
to
me how the Actor is related to the Use Case.


The only possibility seems to be the relationship where the UseCase
participates taking the role useCase connected to the Classifier. But 
I
don't think that the Actor should play the role subject ...


Further, the relationship connecting Actors with UseCases allows the
placement of Multiplicities but users are not encouraged to use roles.
Why is this asymmetry introduced? I could imagine situations 
(especially
for business models) where roles would perfectly make sense even for
Actors. This would be the case always when a actor acts on behalf of
another entity or an actor is to be specialized w.r.t. a specific 
context.


Any ideas?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
An Actor is a kind of Classifier and, as such, it can have associations to other classifiers
including UseCase classifiers. There is nothing special or different about this particular
association to distinguish it from other associations. Hence, it was not deemed necessary
to have a special meta-association between actors and use cases. If one needs to know
which use cases a particular actor is associated with (or vice versa), it is sufficient to get
all associations attached to the element (use case or actor) and filter out the ones that
represent use case-actor associations.
I do not understand the comment about “users not encouraged to use roles” – I see no
such restriction anywhere in the metamodel. Actors can indeed be parts (i.e., roles) in
some collaboration, so the restriction and “asymmetry” listed here do not seem to exist.
Disposition: Closed, no change


Issue 6506: concurrent vs. parallel ExpansionRegions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
The 3rd rev. draft of UML 2's superstructure document introduces the
keywords "parallel", "iterative", and "stream" for ExpansionRegions 
(p.
292).


But the example figures given at page 296 uses "concurrent" instead of
"parallel" without any introduction.


Finally, the metamodel type ExpansionKind (p. 248) solely defines
"parallel" and the other two keywords mentioned above. "concurrent" is
completely missing.


Sure, there is a distinction between concurrency (pseudo-parallel
execution of processes or threads on one single CPU) and parallelity
(parallel execution of processes or threads on multiple CPUs) but I'm
not convinced if we should introduce this distinction at the
specification level.


Any ideas?

Resolution: Duplicate with 6099.
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Issue 6507: Binary associations decorated with large diamonds legal? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
The current Superstructure document states that "Any association may 
be
drawn as a diamond ...". This changes the behavior present in UML 1.x
significantly which only allowed the diamond for n-ary (n>2) 
associations.


As a consequence of this change a UML diagram may look more like an
Entity-Relationship model with some changes (placement of the
association's name, multiplicity notation, and all the semantics) 
than a
upward compatible UML digram.


Is this intended?


I tend to retain UML's former behavor to allow the large diamond only
for n-ary associations.


Any ideas or am I just misreading the spec?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
This issue reports the situation accurately. The answer is that it is intended to permit the
use of the diamond. Use of the word “may” is the sign that is not required that one use
the diamond. The user is free to retain the former notation which he evidently prefers.
Disposition: Closed, no change


Issue 6508: Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
While trying understand the jungle of diagrams offered by UML I 
probably
discovered an inconsistency within the most recent Superstructure 
document.


Page A-546 shows a class digram giving a taxonomy of structure and
behavior diagrams. The figure (numbered A-5) is accompanied with some
descriptive text at the same page.
The diagrams includes a box (class) for a diagram called the
"collaboration diagram" which is not mentioned in the document set
elsewhere. But the text mentiones a "communication diagram" which is
completely missing in the figure.


Additionally, shouldn't the "protocol state machine" be shown as a
specialization of the "state machine diagram"?

Resolution: duplicate
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Discussion:
This is the same issue as 6066. Note also that there is no special protocol-state machine
diagram – it is just a state machine diagram.


Issue 6509: Large diamond for binary associations legal? - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
Reviewing the current Superstructure spec I noticed that it allows the
usage of the large diamond in the middle of an association also for
binary associations which significantly changes to notation compared 
to
UML 1.x


By doing so UML class diagrams become Entity-Relationship flavoured 
but
do not have the semantics of those notation (identity, multiplicities,
etc.) and also the notation is still different (multiplicity,
association name, etc.).


Is it really intended to allow the usage of the large diamond also for
binary associations?


Personally, I'm quite reluctant accepting these change ...

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
Section 7.11.2 Association does indeed permit the use of the diamond for binary
associations. It also states in the Notation section: A binary association is normally
drawn as a solid line connecting two classifiers…
The person reporting this issue is free to continue with his preferred notation usage,
which is also recognized as not only OK, but “normal”.
Disposition: Closed, no change


Issue 6510: AcitivityEdge: weight=all vs weight=null - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
there is a mismatch in the specification. 


On p. 262 about the weight attribute on activity edges:
"A null weight means that all the tokens at the source are
offerd to the target."


But Fig. 6-39 on p. 265 specifies {weight=all} for the same purpose.


Which one is the correct one?


I think {weight=all} is the better alternative to express the
semantic.

Resolution: Duplicate with 6096.
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Issue 6511: Token flow semantics: Implicit fork and join - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
As mentioned on p. 250 an action execution is created when all its 
object flow and control flow prerequisites have been satisfied 
(implicit
join). Same for outgoing egdes (implicit fork).


Is it the same semantic for object nodes?

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
A token can traverse only one edge coming out of an object node. To clarify, in the
Semantics section of ObjectNode, p 350, add this sentence to the end of the first
paragraph:
"A token in an object node can traverse only one of the outgoing edges."


Issue 6512: Guard conditions at fork nodes - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I have a question about the token flow traffic rules within activity 
models:


It is allowed to have guards at outgoing edges from fork nodes.
The specification says about fork nodes:


"When an offered token is accepted on all the outgoing edges, 
duplicates of the token
are made and one copy traverses each edges."


This means that the fork node offers tokens to its outgoing edges, if 
all guard
conditions evaluates to true. So there is a dependency between the 
parallel flows
after a fork node. 


Is that true?


I think the fork node should offer tokens on all outgoing edges that 
accept the token.
If there is a guard condition at an outgoing edge, it is possible 
that the flow continues
only on two of three outgoing edges.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
See issue 7221 for discussion.
In ForkNode class, semantics section, first paragraph, replace the second
sentence with:
"If at least one outgoing edge accepts the token, duplicates of the token
are made and one copy traverses each edge that accepts the token. The
outgoing edges that did not accept the token due to failure of their targets
to accept it keep their copy in an implicit FIFO queue until it can be
accepted by the target. The rest of the outgoing edges do not receive a
token (these are the ones with failing guards). This is an exception to the
rule that control nodes cannot hold tokens if they are blocked from moving
downstream (see Activity)."
Disposition: Resolved


Issue 6513: Components and artifacts: Dependency problem - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
Reading the component section of the specification I come across a 
dependency
problem. Figure 2-9 shows a white-bix representation of a component. 
The bottom
compartment lists the related artifacts. But the direction of 
manifest dependency 
is from the artifact as source to the component as target. So the 
component
does not know anything about its implementing artifacts.


In my opinion the artifacts compartment is wrong.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The notation has functional use in offering the user a central view to get to the different
aspects of a component. The notation provided can be straightforwardly supported by
tools since they can find all artifacts that represent a certain component (viz. navigate
from the Artifact side: Artifact.manifestation.utilizedElement ) if they wish to support
this notation.
Disposition: Closed, no change


Issue 6514: Operation without - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
Page 55 of the current superstructure document lists the operation's
syntax as "visbility name (parameter-list) : property-string" and 
states
that "property-string optionally shows other properties of the 
operation
enclosed in braces".


I wondering where the good old return type or the property enclosed in
*curly* brackets might have gone.


If the "property-string" mentioned in the operation's syntax quoted
above is the return type the possibility to add operation wide
properties (like "query") is gone.


If the "property-string" is the way to add properties it should be
enclosed in curly brackets and the separation by the colon from the
parameter list containing also the return type could be misleading.
Hence the colon should be dropped or exchanged by another symbol.


Or am I just misreading the spec?

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
This issue is similar to issue s 6213 and 5951 and resolved by the resolution for issue
7135. This includes adding the “query” operation property.


Issue 6515: Inconsistency concerning VisibilityKind - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
Just a minor point, but still annoying to the reader ...


The superstructure lists at page 16 all four possible types (i.e.
"public", "private", "protected", and "package") but within the
Infrastructure document (page 73) solely "public" and "private" are
mentioned. The same for the enumeration example at page 116.


Also it would be helpful to shift the visual presentation options 
("+",
"-", "#", and "~") for VisibilityKind from the chapter describing
attributes (Superstructure p. 41) to more general description at page 
16
which is multiple referenced from other parts of the spec.

Resolution: see abov e
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issue was apparently drafted against a version of the UML2 Superstructure
document preceding the FAS (ptc/03-08-02). Consequently, SuperFAS location
references have been translated as follows:
Issue location Superstructure FAS location
“page 16” Section 7.3.6, page 39-40, VisibilityKind
“page 116” Section 7.12.2, page 97, Enumeration, Figure 42
“p. 41” Section 7.8.1, page 64, Classifier
Furthermore, the reference to “Infrastructure document (page 73)” is translated as Section
9.20.2, page 93, VisibilityKind, in the UML2 Infrastructure FAS (ptc/03-09-15).
Apparently, the InfraFAS does not include protected and package enumeration
literals for the VisibilityKind enumeration because MOF does not require them.
However, in view of the desire to have corresponding sections of the SuperFAS
and InfraFAS be identical, it seems necessary to add protected and package
literals to the definition of VisibilityKind in the InfraFAS. MOF (or any other reuser
of the Infrastructure) can choose to either (1) ignore unused values or (2)
provide constraints preventing their use, as appropriate. The following changes
are required to accomplish the task and bring both documents into alignment:
Add “protected” and “package” as the third and fourth literal values,
respectively, in the Description subsection of VisiblityKind, section 9.20.2,
page 93, of the UML2 Infrastructure FAS. Change the phrase “Any element marked as having package element is
visible” to “Any element marked as having package visibility is visible” in
the third sentence of the fourth bullet point in the Semantics subsection,
section 7.3.6, page 40, of the UML2 Superstructure FAS. (This change is
intended only as a grammatical change to provide correctness, clarity and
cross-document alignment by fixing a wrong word choice.)
Add a third bullet point to the Semantics subsection of VisibilityKind,
section 9.20.2, page 93, of the UML2 Infrastructure FAS with the text
“A protected element is visible to elements that have a generalization relationship
to the namespace that owns it.”
Add a fourth bullet point in the Semantics subsection of VisibilityKind,
section 9.20.2, page 93, of the UML2 Infrastructure FAS with the text
“A package element is owned by a namespace that is not a package, and is
visible to elements that are in the same package as its owning namespace. Only
named elements that are not owned by packages can be marked as having
package visibility. Any element marked as having package visibility is visible to
all elements within the nearest enclosing package (given that other owning
elements have proper visibility). Outside the nearest enclosing package, an
element marked as having package visibility is not visible.”
Add “protected” and “package” as the third and fourth literals, respectively,
of the VisiblityKind enumeration in Figure 42, section 7.12.2, page 97, of
the UML2 Superstructure FAS.
Add “protected” and “package” as the third and fourth literals, respectively,
of the VisiblityKind enumeration in Figure 63, section 9.20, page 92, of the
UML2 Infrastructure FAS.
Add “protected” and “package” as the third and fourth literals, respectively,
of the VisiblityKind enumeration in Figure 88, section 11.5.4, page 136, of
the UML2 Infrastructure FAS.
The suggestion to move the discussion of visibility presentation options to the
VisibilityKind section is reasonable and places discussion of these options in a
more likely location. However, removing the offending references presents
textual flow problems in both FASs. Rather than removing them, a discussion of
visibility presentation options is added to the VisibilityKind section. The following
changes are required to accomplish this:
In the first bullet under the text “In the following bullets, each of these parts
is described:” on page 120, section 11.3.3, of the UML2 Infrastructure FAS
replace the text “such as + or -.” with the text “such as +, -, #, or ~”.
In the discussion of VisibilityKind at the following locations UML2 Superstructure FAS, section 7.3.6, page 40
UML2 Infrastructure FAS, section 9.20.2, page 93,
add the following Notation subsection after the existing Semantics
subsection:
Notation
The following visual presentation options are available for
representing VisibilityKind enumeration literal values:
“+” public
“-“ private
“#” protected
“~” package


Issue 6516: Dependency notation for interfaces - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
Comparing figure 1-63 (Superstructure document page 92) with the text
placed above describing it and the presentation guidelines for 
interface
relationships (i.e. the relationships connecting an interface with its
requiring and/or providing classes) it seems that the dashed lines
announced in the text are gone in the figure.


Reading the text the arrow pointing from TheftAlarm to ISensor should 
be
realized as a dependency relationship and also the arrow pointing from
ProximitySensor to ISensor. The latter is currently realized as a
generalization arrow which is solely a valid presentation option for
relationships connecting a Component and their Interface. According to
the spec the arrow should be a dependency relationship that is
stereotyped with realizes having ProximitySensor as client and Isensor
as supplier.


Or am I just misreading the spec?
Any help and clarification appreciated

Resolution: Resolved by the resolution to issue 6069
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Issue 6517: Package Extensibility <<merge>> - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
When merging packages... How are associated state machines handled?


 

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The handling of non-MOF kinds of model elements is explained in detail the resolution to
issue 6279. The “default rule” in particular is relevant to this and similar cases.
Specifically, if two state machines are matched but not the same in the merged and
receiving package, the merge is not well formed. If they match and are the same, no
merge is performed.


Issue 6518: does "is not instantiable" imply "isAbstract"? - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:
Just a minor graphical typo: Page 487 of the superstructure document
specifies an InformationItem as not instanciable. But the classifiers
taxonomy provided at page E-565 of the same document depicts it as
instanciable class.


I guess it should be italicized.


Or am I just misinterpreting the sentence "is not instanciable"? I
guessed it implies "isAbstract == true".

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The intent of the constraint was not to say that the metaclass InformationItem is an
abstract class – the example in figure 414 clearly shows a model that requires instances of
this metaclass. Instead, it meant that at run time there could be no objects whose type is
represented by an InformationItem metaclass. Therefore, this metaclass should not be
made abstract.
The following changes should be made:
?? On page 533 in the Constraints subsection, change the numbering of the
constraints so that it starts at [1] (instead of [4]);
?? Change the spelling of “instanciable” in the last constraint to “instantiable”
?? Add the following OCL expression to the last constraint:
isAbstract
Disposition: Resolved


Issue 6519: Activity nodes and Stereotypes - UML2 Superstructure issue (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
The new Profiles package and the respective Stereotypes still seem 
very
"class-oriented" when it comes to notation (maybee my fault?). 
Specifically,
I have the following doubt:


If I want to define a Stereotype for an activity node, e.g. a 
ForkNode, is
the notation in the attached file correct?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The file that was supposed to be attached to the issue is missing. After having asked a
couple of time for it, no one could find it again. The issue cannot be understood/treated
without further information.
Disposition: Closed, no change


Issue 6520: GeneralizationSet Description clarification - UML2 Superstructure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
On page 121 of 03-08-02 the GeneralizationSet description reads:
7.17.3 GeneralizationSet (from PowerTypes)


A GeneralizationSet is an AutonomousElement (from Foundation :: 
Kernel ::
PackagingNamespaces) whose instances define


partitioned sets of Generalization relationships.


Description


Each Generalization is a binary relationship that relates a specific
Classifier to a more general Classifier (i.e., a subclass).


For clarification, should the parenthetical read "(i.e., a subclass 
to a
superclass).  As written, it may convey to some that the subclass is 
the
more general Classifier.

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
Was resolved as part of Issue No. 5980 (item 4), where sentence was changed to read
instead: “Each Generalization is a binary relationship that relates a specific Classifier to a
more general Classifier (i.e., from a class to its superclass).”


Issue 6521: The node "Order cancel request" that appears in figure 6-86 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
I would really appreciate an answer to the following questions 
regarding the
3rd revised submission of UML 2.0 superstructure from April 10, which 
I hope
is the most recent one:


1. The node "Order cancel request" that appears in figure 6-86 (page 
304),
and the node "Ready to award bid" and "Bid arrives that appear in 
figure
6-39 (page 265) are of the type  "Object nodes for tokens with signal 
as
type", presented in page 316?
If they are then there is a discrepancy between the respective 
graphical
notation in page 316 and page 331 (table 1), and pages 304 and 265.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
The nodes "Ready to award bid" in Figure 213, and "Order Cancel Request" in Figure
260 are AcceptEventActions, p 217. The notation for object nodes with signal type is
different, see Figure 275.
Disposition: Closed, no change


Issue 6522: Order cancel request (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
2. Assuming that, for example, "Order cancel request" that appears in 
figure
6-86 (page 304), is an object nodes with signal as type, from where 
or how
does it get the respective token which is then subtracted by the arc 
ending
in Cancel order?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 9, 2005: closed issue

Discussion:
This issue assumes that "Order Cancel Request" node in Figure 260 are object nodes. Is is
actually an AcceptEventActions (see issue 6521). The Order Cancel Request node gets it
token from an incoming signal.
Disposition: Closed, no change


Issue 6523: Typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:
page 261, on the Description of complete activities:
"Edges support controlling token flow and be contained in 
interruptible
regions."


page 269, second line says "It covers invocation nodes, control nodes
(...)". I believe it should read "It covers executable nodes, control 
nodes
(...)"


page 282, second line:
"A control flow is an edge starts an activity node after the previous 
one is
finished."


page 286, in constraints [2]:
"The input parameter must be the same as or a supertype the type of 
object
token coming along the incoming edge."


page 301, in Semantics:
"This is equivalent interposing a CentralBufferNode between the 
initial node
and its outgoing edges."
page 307, second line:
"A loop node is a costructured activity node that represents a loop 
with
setup, test, and body sections."
page 331, Table 2 caption should be "Graphic paths (...)" instead of
"Graphic nodes (...)". Table 3 caption should also be made more 
specific.

Resolution: duplicate
Revised Text:
Actions taken:
November 7, 2003: received issue
December 2, 2004: closed issue

Discussion:
The typos in this issue are duplicate with issue 6162. The questions are duplicate with
issues 6521 and 6522.


Issue 6526: /pages 485,487,495/mixed names for state machine diagram (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
The UML 1 terminology "StateChart" and another term "state diagram" also occurs.
 
Appendix A of the Superstructure spec makes it clear that the UML 2 name is "state machine diagram"
 
Recommendation: All occurrences of "statechart" and "state diagram" must be replaced with "state machine diagram" 

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 8, 2005: closed issue

Discussion:
The following changes need to be made:
?? On page 485, second sentence of the first paragraph on the page, replace the term
“statechart” with the term “state machine”
?? On page 487, in the first paragraph of the examples sub-section, replace the term
“statechart” by the term “state machine”
?? On page 494, in the first sentence of the Notation sub-section, replace the term
“statechart” by the term “state machine”.
?? On page 505, in the first sentence of the description of the Vertex concept, replace
the term “statechart” by the term “state machine”.


Issue 6527: Incorrect usage/definition of "emergence" in Common Behavior Chapter (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Thematix Partners LLC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Uncategorized Issue
Severity:
Summary:
PROBLEM STATEMENT


In section 13.1 of the Common Behaviors chapter, the following paragraph is
contains an incorrect definition of "emergent behavior":
"Emergent behavior results from the interaction of one or more participant
objects. If the participating objects are parts of a larger composite
object, an emerging behavior can be seen as indirectly describing the
behavior of the container object also. Nevertheless, an emergent behavior is
simply the sum of the executing behaviors of the participant objects."


The current area of scientific study know as Complex Adaptive Systems, or
Complexity Science",  describes emergent behavior as "the appearance of a
coherent pattern that arises out of interactions among simpler objects, that
is MORE than just their summed behavior."   (emphasis mine)  Furthermore,
Complexity Science expressly states that a behavior that is limited to the
sum of its behavior is NOT emergent.  (See references, below.)


Emergence is a primary area of study at the Santa Fe Institute and has Nobel
Laureates and MacArthur geniuses studying the effect.  Therefore, I think
that the use of the terms "emergence" (used once) and "emergent behavior"
(used 9 times) are not correct for Common Behavior chapter.  If left in,
they will cause confusion, because the terminology is already
well-established in both science and industry.



PROPOSED SOLUTION
1) Common Behavior Domain Model (Fig. 306) to contain the classed called
BehaviorEmergence.  Therefore, the class should wither be removed or another
tem substituted. 
2) Remove, or rename, all 9 usages of "emergent behavior" if the chapter and
appendix.



References (to name a few) :
 
Holland, J.H., Emergence: From Chaos to Order. 1998, Reading, MA:
Addison-Wesley. (MacArthur Fellowship Genius Award)


Gell-Mann, M., The Quark and the Jaguar: Adventures in the Simple and the
Complex. 1994, New York: W. H. Freeman. (Nobel Laureate in Physics)


Kauffman, S., At Home in the Universe: The Search for the Laws of
Self-Organization and Complexity. 1995, New York: Oxford University Press.
(Professor, Santa Fe Institute)


Coveney, P. and R. Highfield, Frontiers of Complexity: The Search for Order
in a Chaotic World. 1995, New York: Fawcett Columbine.


Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and
Chaos. 1992, New York: Simon and Schuster. (PhD in elementary particle
physics)


The Emergence of Everything: How the World Became Complex
by Harold J. Morowitz


Emergence: The Connected Lives of Ants, Brains, Cities, and Software -- by
Steven Johnson 

A New Kind of Science by Steve Wolfram

Resolution: see above
Revised Text:
Actions taken:
November 9, 2003: received issue
March 8, 2005: closed issue

Discussion:
The learned submitter of this issue correctly points to fascinating literature on the
emergence of structure. However, chaos theory does not have a unique claim on this
terminology, and moreover, the usage of this term in the common behavior section is
reasonably close to the terminology pointed to by the learned submitter. In UML,
emergent behavior refers to behavior that is not specified as a executing behavior but that
arises as the result of the cooperation of objects with executing behavior. In earlier drafts,
the term “supervenient behavior” was used, but deemed as too unusual a terminology.
(Note that supervenience would be the most accurate description of the phenomenon as
behavior arising from occurring behavior.)
In either case, emergence has reasonably close connotations, and there is little danger that
modelers are confused by the more specialized use of the term in chaos theory.
However, upon rereading the introductory section, the issue does warrant a small change:
Change the last sentence of the paragraph starting with “Emergent behavior results…” on
p.369 to “Nevertheless, an emergent behavior can result from the executing behaviors of
the participant objects.”


Issue 6596: page 95 diagram (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
On page 95 the diagram shows an assoziation between the class DataType and Property (with name ownedAttribute). This assoziation is'l listet in the assoziation section of the class DataTypes on page 95. Ther is an assoziation with the same name (ownedAttribute) but with a wrong type (Attribute). 

Resolution: see above
Revised Text:
Actions taken:
November 10, 2003: received issue
March 8, 2005: closed issue

Discussion:
Reading "assoziation is'l listet" as "association isn't listed", the issue makes a valid point.
The reference to Attribute is most certainly an editorial leftover from an earlier time
when Property was called Attribute. Changing Attribute to Property will make the text
consistent with the diagrams and the rest of the UML2 Superstructure specification.
Consequently, the following resolution is proposed:
1. In document ptc/03-08-02, page 95, section 7.12.1, change the text
"ownedAttribute: Attribute[*]" in the first bullet under the Associations heading
to "ownedAttribute: Property[*]".
2. Because this issue is shared by the UML2 Superstructure FTF and the
MOF2/UML2 Infrastructure FTF, a corresponding change is proposed in
document UML 2.0 Infrastructure specification:
3. In document ptc/03-09-15, page 133, section 11.51, change the text
"ownedAttribute: Attribute[*]" in the first bullet under the Associations heading
to "ownedAttribute: Property[*]".


Issue 6605: Missing actual arguments in submachines states (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:
A state machine, as a behavior, has formal parameters. When referencing it in a submachine state, we 
may need to pass actual arguments. However, nothing seems to be specified for that purpose in the 
UML2 metamodel. Is this a bug? If not, how can we send/retrieve data to/from a referenced submachine?

Resolution:
Revised Text:
Actions taken:
November 12, 2003: received issue
March 9, 2005: closed issue

Discussion:
Parameters are used in the context of behavior invocation. Submachines are not invoked
and therefore the mechanism of passing actual parameters does not apply. Data to/from
submachines can be retrieved by either defining it in the namespace of the context
classifier, where data is available according to the specification of behaviors, or by
defining the submachine as a template wit parameters representing the data and then
binding the desired data via template binding.
Disposition: Closed, no change


Issue 6606: No way to represent "uninterpreted" actions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:
Within a state machine we would like refer to an action defined rather "informally" using natural language. 
Among the list of actions metaclasses, we did not see any one that could be used to map our "informal" 
action. 
Suggestion for resolution: Add a UninterpretedAction metaclass in the metamodel. 
 

Resolution:
Revised Text:
Actions taken:
November 12, 2003: received issue
March 9, 2005: closed issue

Discussion:
In UML 2, uninterpreted actions in state machines are modeled as activities with no
nodes. Activity has attributes for uninterpreted strings. Also see issue 6094.
Disposition: Closed, no change


Issue 6607: Time trigger notation in state machines (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:
In activity diagrams a time expiration event can be notated using a special "time consumation" icon. 
For state machines it is not clear whether the same icon can be used. 

Resolution:
Revised Text:
Actions taken:
November 12, 2003: received issue
March 9, 2005: closed issue

Discussion:
The state machine chapter does not specify this notation. Since State machines and
activities are separate notations in UML2.0 there doesn’t seem to be a confusion any
longer.
Disposition: Closed, no change


Issue 6608: Notation when guards are used in conjunction with triggers in transitions (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:
According to the metamodel, a transition may have a guard and a trigger. However the specification
does not say how to draw a transition that has both. Should we put the guard,  (1) near the arrow 
which is before the "input" symbol representing the trigger signal, or (2) near the arrow which is after 
the "input" symbol or (3) inside the symbol representing the trigger? 

Resolution: see above
Revised Text:
Actions taken:
November 12, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issue is indeed currently overlooked by the transition iconic representation. The
proposed resolution is follow option (3) and add the guard using the regular notation
within the signal receipt symbol as follows
This will be clarified in the iconic transition section (as described in issue 6381).


Issue 6625: UML 2 Super/Actions/PrimitiveFunction missing properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
PrimitiveFunction is missing formalParameter and returnedResult properties, as referenced by ApplyFunctionAction on page 222. Should it be a specialization of Behavior? 

Resolution: See resolution of 7405.
Revised Text:
Actions taken:
November 21, 2003: received issue
March 8, 2005: closed issue

Issue 6626: section 9 (State Machines) of 3rd revision (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 9 (State Machines) of 3rd revision 

 

Page 454 - The Description of the class “Transition” associations fails to list the association “container” depicted on the drawing on page 415. 
Drawing on page 415 displays {redefines owner} for both container of Vertex and for Transition.  I believe these should be {subsets owner} (also in mdl file) 

Resolution: see above
Revised Text:
Actions taken:
November 23, 2003: received issue
March 8, 2005: closed issue

Discussion:
The “container” association end issue has been resolved by the resolution to issue 6238.
Transition::container already “subsets owner” (also changed by resolution to 6238). The
only changes that are required are:
??change the constraint on Vertex::container from “{redefines owner}” to “{subsets
owner}” in figure 354 (and in the metamodel) and,
??on page 528, to add the phrase “{Subsets Element.owner}” to the end of the text
explaining the “container” entry in the list of Associations of Vertex.


Issue 6627: UML 2 Super/Actions/non-existent feature "multiplicity" (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The third constraint on StructuralFeatureAction (page 258) uses the very non-existent feature "multiplicity" of the InputPin metaclass.  Not only that, but because this "multiplicity" feature doesn't exist, who is to tell what kind of element it is that defines the "is(lower, upper)" operation! Recall that the InputPin is a specialization of ObjectNode, which is not a MultiplicityElement, but defines a single attribute "upper : ValueSpecification."  Where is the corresponding "lower"? 

Resolution: This duplicates 6090.
Revised Text:
Actions taken:
November 25, 2003: received issue
December 2, 2004: closed issue

Issue 6628: UML 2 Super/Action/featuringClassifier misinterpreted (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular.  However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature! 

Resolution: see above
Revised Text:
Actions taken:
November 25, 2003: received issue
March 8, 2005: closed issue

Discussion:
StructuralFeatureAction class, Constraints, add a new constraint:
[ ] The structural feature has exactly one featuringClassifier.


Issue 6629: UML 2.0 Superstructure 3rd revision - Owner of triggers? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
Trigger specializes Element which has the constraint self.mustBeOwned() implies owner->notEmpty()

 

And defines mustBeOwned = true

 

Trigger and all of its specializations 

1.       never define any relationship that {subsets owner} 

2.       Do not override mustBeOwned

 

Therefore Trigger and all specializations will violate the constraint.

Resolution: Duplicate of 6206
Revised Text:
Actions taken:
November 25, 2003: received issue
December 2, 2004: closed issue

Issue 6642: Error in definition of PackageMergeKind (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Uncategorized Issue
Severity:
Summary:
Figure 9-11 specifies that the two values for PackageMergeKind are 'extent' and 'define'.  This is probably an editorial error.  I suppose the same error exists in the OMG Standard petal file(s).


Under PackageMerge, Properties, the sentence, 'mergeType: PackageMergeKind Specifies the kind of package merge to perform, define, or extend.', has an extra comma, the last, which should be removed.  This sentence might better be written with a colon in place of the first comma:


mergeType: PackageMergeKind     Specifies the kind of package merge to perform: define or extend.

Resolution:
Revised Text:
Actions taken:
November 27, 2003: received issue
March 9, 2005: closed issue

Discussion:
This issue is made moot by the resolution to issue 6279, which merges the two kinds of
merge into one. This is actually a MOF issue and not a superstructure issue. However, we
might as well close it here, since 6279 provides the MOF resolution as well.
Disposition: Closed, no change


Issue 6643: UML 2 Super / use cases / incorrect comments in notation section (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML 2.0 Superstructure ptc/03-08-02 

In table 22, in the Notation cell associated to the "Include" Note Type,
the comments associated to the two Use Case shoud be exchanged :
the Whidraw UC should be the including UC; the Card Identification should
be the included UC. 

Resolution: see above
Revised Text:
Actions taken:
November 29, 2003: received issue
March 8, 2005: closed issue

Discussion:
Replace the figure in the entry for Include in table 22 (pg. 524) by the following
figure:
Withdraw Card
Identification
«includes»
including (use case) included (use case)


Issue 6644: UML 2.0 Superstructure reccomendation (derived unions) (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.


Resolution: This is a duplicate of issue 6430
Revised Text:
Actions taken:
November 30, 2000: received issue
December 2, 2004: closed issue

Discussion:
 


Issue 6646: UML 2.0 Superstructure Derived Union vs. derivationExpression? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
The use of the latter would eliminate the isDerivedUnion Property from the Class Property and would eliminate the subsets and union property strings from all the associations.  Also would allow for the definition of more complex derivations other than simple unions.  A Property could be overridden/redefined for each child class to update the derivation for that class.

 

Most importantly the information would be stored in a more appropriate location.  When attempting to determine a value for a property one simply need look at the derivationExpression and not look at all other properties to determine which properties subset this derived union.  Given the number of mistakes using derived union in the UML 2.0 Spec it seems apparent that this is error prone.

 

Implementation would also be easier.  Most modeling tools could simply add a couple of tagged values to allow for the definition of derivationExpression.  Also languages would be able to generate a standard function call to calculate the derivationExpression.

 

Example:

 

The  Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement.  In order to determine how to actually derive the value of ownedMember one has to currently iterate all the properties to determine which ones subset the derived union property and then perform the union.  Also, one would have to ensure the property strings are on each subsetting member.

 

Using the derivationExpression one would only need the following in one location:

 

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

 

If desired, but not required, the derivation expression could be displayed on a diagram via a comment. 


Resolution: This is really a continuation of issue 6644, not a separate issue.
Revised Text:
Actions taken:
December 1, 2003: received issue
December 2, 2004: closed issue

Issue 6647: UML2 Super/Composite Classes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
pg 168: The provided and required interfaces completely characterize any
interaction that may occur between a classifier and its
environment at a port.


If the type of a port is a class, perhaps with superclasses, then I don't
see how the above statement can be true.

Resolution: see above
Revised Text:
Actions taken:
December 2, 2003: received issue
March 8, 2005: closed issue

Discussion:
The issue is correct in pointing out that the term “completely characterizes” is rather
sweeping. Change the first sentence of the last paragraph of p.168 of adtf/03-08-02 to:
“The provided and required interfaces completely characterize any interaction that
may occur between a classifier and its environment at a port with respect to the
data communicated at this port and the behaviors that may be invoked through
this port. The interfaces do not necessarily establish the exact sequences of
interactions across the port.”


Issue 6648: UML2 Super/parts (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
03-08-02.pdf, page 174:part: Property References the properties specifying
instances that the classifier owns by composition.
This association is derived, selecting those owned properties where
isComposite is true.


This seems to imply that /parts can only reference Properties whose types
are Class, Interface, Templateable Class., i.e. only those subtypes of
Classifier that denote instances. Is this correct - if so then it should be
more explicit in the constraints (I couldn't see any other reference to this
constraint).

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
March 9, 2005: closed issue

Discussion:
A property, as structural feature, is a typed element. There are no constraints on part
properties different from any other structural feature.
Disposition: Closed, no change


Issue 6666: UML2 Super/Structured Classes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
03-08-02.pdf


Figure 95 - the term {subsets redefinit ionContext}


appears in an odd place - I assume it belongs as a complement to
redefinedConnector, rather than ownedConnector

Resolution:
Revised Text:
Actions taken:
December 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
StructuredClassifier is the redefinitionContext for Connector (inherited from the relation
between RedefinableElement and Classifier).
Disposition: Closed, no change


Issue 6667: Page 164 - there are two constraints sections for Connector (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Page 164 - there are two constraints sections for Connector

Resolution: Delete the section “Constraints” at the top of p. 164 of adtf/03-08-02.
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Issue 6668: UML2 Super/Connector (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
If as has been suggested structured classes completely encapsulate their
parts, then I would expect to see a constraint against Connector,  which
states that the parts associated to its ends via "role" or "partWithPort"
should be owned by the same StructuredClassifier as owns the Connector.

Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
The suggested constraint does not hold as stated. In fact, Figure 114 on p.172 of adtf/03-
08-02 gives an example where a connector is between two roles that are not parts of the
same containing classifier. The rationale for this seemingly unintuitive capability is to
support the ROOM “slide- in” capsules.
However, there is a weaker constraint that was omitted: that a Connector can only
connect roles that are roles of the same Classifier. In section “Constraints” for
“Connector” add:
[4] The ConnectableElements attached as role to each ConnectorEnd owned by
a Connector must be roles of the same Classifier.
In addition, insert a newline before “Examples” in this section.


Issue 6669: UML2 Super/Ports (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
page 168 - isBehavior: Boolean Specifies whether requests arriving at this
port are sent to the classifier behavior of this
classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383).
Such ports are
referred to as behavior port. Any invocation of a behavioral feature
targeted at a behavior
port will be handled by the instance of the owning classifier itself, rather
than by any
instances that this classifier may contain. The default value is false.


This needs to be backed up by a constraint that ensures that no
ownedConnectors may connect to such a Port.

Resolution:
Revised Text:
Actions taken:
December 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
The suggested constraint is incorrect. Consider the situation where a part P
of Classifier C is connected to a behavior port of C. This situation would
violate the proposed constraint.
Disposition: Closed, no change


Issue 6670: UML2 Super/Connector End (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
p 165, partWithPort: Property [ 0..1 ] Indicates the role of the internal
structure of a classifier with the port to which the connector
end is attached.


Is there any significance to the fact that the term role is used, or is part
meant here? There seems to be no constraint that makes it explicit that
partWithPort must associate to a part (i.e. a property with
isComposite=true.)

Resolution:
Revised Text:
Actions taken:
December 4, 2003: received issue
March 9, 2005: closed issue

Discussion:
There is no such constraint. For an example, see the related resolution to issue 6668.
Disposition: Closed, no change


Issue 6674: subsettedProperty->forAll(sp | isDerivedUnion) ? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
As used in UML 2 Infra and Super is it intended that all properties that are subset by some other properties be derived unions?

 

So that the following constraint would be true for the Class Property… 

subsettedProperty->forAll(sp | isDerivedUnion) ?

 

 

I understand this may not be a requirement but am just trying to understand if this is how it is used in the Spec.


Resolution: This is a duplicate of issue 6430
Revised Text:
Actions taken:
December 4, 2003: received issue
December 2, 2004: closed issue

Issue 6675: UML 2 Super/Activities/end naming consistency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
ActivityGroup::edgeContents and ActivityGroup::nodeContents should probably be renamed to ActivityGroup::edgeContent and ActivityGroup::nodeContent so as so be consistent with the rest of the specification. 

Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 180, p 271,
Figure 183, p 273,
Figure 191, p 276,
Figure 192, p 277,
rename the association end "edgeContents" to "containedEdge" and "nodeContents" to
"containedNode", including in the {redefines} constraints in Figures 183, 191, and 192.
In Association section of ActivityGroup, p 301, replace "edgeContents" with
"containedEdge" and "nodeContents" with "containedNode".


Issue 6676: UML 2 Super/Activities/assocition end specialization consistency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
ActivityGroup::edgeContents and ActivityGroup::nodeContents are redefined by subclasses ActivityPartition (Figure 183), InterruptibleActivityRegion (Figure 191), and StructuredActivityNode (Figure 192), but the opposites of these properties are subsetted instead. Would make more sense to apply either redefinition or subset constraints to both ends of the associations rather than a mixture of both? 


Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
In figure 180, p 271, add {union} constraint to the inGroup association ends from
ActivityEdge and ActivityNode to ActivityGroup.


Issue 6677: UML 2 Super/Activities/invalid multiplicity 0 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
InterruptibleActivityRegion::edgeContents redefines the multiplicity of ActivityGroup::edgeContents to be 0, which violates the constraint that an upper bound must be greater than 0 

Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
The minimum multiplicity was set to zero because edges have no special
semantics in interrupting regions, but consequently there is no effect of including
them either. Remove the specialized association.
In Figure 191, p 276, remove the association between InterruptibleActivityRegion
to ActivityEdge.


Issue 6678: UML 2 Super / Activities / inconsistency in representing subsetting (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Instead of subsetting ActivityEdge::inGroup with an ActivityEdge::interruptibleRegion property (as is done with ActivityNode), a completely new association (ActivityEdge::interruptibleRegion<->InterruptibleActivityRegion::interruptingEdge) is introduced. Why the inconsistency?

Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 191, p 276. rename association ends:
- "interruptibleRegion" from ActivityNode to
InterruptibleActivityRegion to "inInterruptibleRegion".
- "interruptibleRegion" from ActivityEdge to
InterruptibleActivityRegion to "interrupts".
and remove entire "inGroup" association from ActivityEdge to
InterruptibleActivityRegion.
In Associations (CompleteActivties) section of ActivityEdge, p 293, replace
"interruptibleRegion" with "interrupts".
In Associations section of ActivityNode, replace "interruptibleRegion" with
"inInterruptibleRegion".
Rename "Associations" section heading of ActivityNode to "Associations
(CompleteActivities)".


Issue 6679: UML 2 Super / Activities / association end naming (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
ActivityNode::interruptibleRegion should probably be renamed to ActivityNode::inInterruptibleRegion so as to be consistent with ActivityNode::inGroup, ActivityNode::inPartition, and ActivityNode::inStructuredNode.

Resolution: See changes for 6678.
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Issue 6680: UML 2 Super / Activities / subsetting two properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Activity::structuredNode subsets two properties, Activity::node and Actvity::group. This is among the few, if not the only, cases in the metamodel where a containment property subsets two superset containment properties. What is the semantic intent of this constraint? Should Activity::structuredNode be derived from the set of structured activity nodes in Activity::node and Actvity::group (StructuredActivityNode is both a group and a node)? 

Resolution: see above
Revised Text:
Actions taken:
December 4, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 192, p 277, make association end structuredNode from Activity to ActivityEdge
derived.
In Associations (StructuredActivities) section of Activity, insert "/" before
"structuredNode".


Issue 6682: See CommonBehavior for a description of Event specifications (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Clarification
Severity: Critical
Summary:
The text says "See CommonBehavior for a description of Event specifications." 

Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. 

But we aren't told there or anywhere how to specify an event nor how to specify a type of event. 

Resolution: see above THEN below
Revised Text: p216, AcceptCallAction, Semantics, first paragraph, rephrase: “This action accepts (event) occurrences representing the receipt of calls on the operation specified by the call trig ger. If an ongoing activity has executed an accept call action that has not completed and the owning object has an event occurrence representing a call of the specified activity, the accept call action claims the occurrence and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the occurrence, but one and only one action will claim the occurrence. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in a token on the returnInformation output pin. The execution of the accept call action is then complete. This return information token flows like any other data token, but the information in it is opaque and may not be manipulated by any actions. It only has meaning to ReplyA.” p217, AcceptEventAction, Semantics, parapraph 1-2, rephrase: Accept event actions handle event occurrences detected by the object owning the activity. Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. If the accept event action is executed and the object detected an occurrence matching the specification on the action and the occurrence has not been accepted by another action or otherwise consumed by another behavior, then the accept signal action completes and outputs a token describing the occurrence. If such a matching occurrence is not available, the action waits until such an occurrence becomes available, at which point the action may accept it. In a system with concurrency, several actions or other behaviors might contend for an available occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions. If the occurrence is of a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications. If an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept occurrences, no matter how many it accepts. It does not terminate after accepting an occurrence and outputing a value, but continues to wait for other occurrences. This semantic is an exception to the normal execution rules in Activities. p370, Common Behaviors, Basic behaviors, first paragraph, substitute: “partially ordered sequences of events” to “partially ordered sequences of occurrences” “observable events” to “observable occurrences” p372, p372, Common Behaviors, Communications, 2nd paragraph on page, substitute: “the invocation event that eventually will lead” to “the invocation occurrence that eventually will lead” Tthird paragraph, rephrase: The detection of an (event) occurrence may cause a behavioral response. For example, a statemachine may transition to a new state upon detection of the occurrence of a trigger event or an activity may be enabled upon receipt of a message. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. The behavior will be executed in the context of the receiving object (i.e., the receiving object will host the behavior execution). The details of identifying the behavior to be invoked in response to the occurrence of an event is a semantic variation point. p381, Behavior, Semantics, Paragraph 3: The behavior executes within its context object, independently of and concurrently with any existing behavior executions. The object which is the context of the behavior manages the input pool holding the (event) occurrences to which a behavior may respond (see BehavioredClassifier on page 383). As an object may have a number of behaviors associated, all these behaviors may access the same input pool. The object ensures that each occurrence on the input pool is consumed by only one behavior. p383, BehavioredClassifier, Semantics Paragraph 2: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. p489, StateMachine, Overview: State machines can be used to express the behavior of part of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the detection of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine. p491, StateMachine, Semantics, Event Processing: Event occurrences are detected and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority-based schemes. The semantics of event processing is based on the run-to-completion assumption, interpreted as run-tocompletion processing. Run-to-completion processing means that an event occurrence can only be taken from the pool and dis patched if the processing of the previous current event occurrence is fully completed. Run-to-completion may be implemented in various ways. For active classes, it may be realized by an eventloop running in its own thread, and that reads event occurrences from a pool. For passive classes it may be implemented as a monitor. The processing of a single event occurrence by a state machine is known as a run-to-completion step. Before commencing on a runto-completion step, a state machine is in a stable state configuration with all entry/exit/internal activities (but not necessarily state (do) activities) completed. The same conditions apply after the run-to-completion step is completed. Thus, an event occurrence will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine. The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its runto- completion step. When an event occurrence is detected, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event (type) is not in the deferred event list of the current state configuration, the occurrence is discarded and the run-tocompletion step is completed. In the presence of orthogonal regions it is possible to fire multiple transitions as a result of the same event occurrence — as many as one transition in each region in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined. Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions (i.e., “bottomlevel” region) can fire at most one transition as a result of the current event occurrence. When all orthogonal regions have finished executing the transition, the current event occurrence is fully consumed, and the run-to-completion step is completed. During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a state machine, then the transition step is not completed until the invoked object complete its run-tocompletion step. p498, Transition, Overview: A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to the occurrence of an event of a particular type. p498, Transition, Associations, guard, substitute: “The guard is evaluated when an event is dispatched by the state machine.” to “The guard is evaluated when an event occurrence is processed by the state machine.” p500, Transition, Enabled transitions, 2nd bullet: • One of the triggers of the transition is satisfied by the event (type) of the current occurrence. An event satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization thereof.
Actions taken:
December 8, 2003: received issue
March 8, 2005: closed issue

Discussion:
The following changes support the sentiment at the FTF meeting in Anaheim to
regularize the terminology around events. Several people were strongly in favor of
making these changes and nobody expressed opposition, so I have carried out the changes
that I promised by searching the text document.
Broadly, the following issues are addressed:
1. Establish and enforce a consistent naming policy for metaclasses over the
categories of types, instances, values, and uses (references).
2. Restore Event as a class with subclasses instead of having subclasses of Trigger,
and have Trigger point to Event (a particular trigger instance would point to an
instance of a particular event subclass).Also add additional event subclasses for
creation, destruction, initiation, and completion.
3. Rename a few other classes that break the pattern, such as using “occurrence” in
their name when they do not refer to event instances, e.g.,
CollaborationOccurrence..
4. Clean up occasional sloppiness in the text in making distinctions between model
things and runtime thingstypes and instances with respect to behavioral things
such as events and executions, broadly speaking to be consistent about
type/instance distinctions. The terminology obeys the following principles:
Consistent naming policy
There was inconsistency in naming various kinds of behavioral things, with the same
word being used for different things. In particular, the distinction between instances, roles, and value specifications was done differently and inconsistently. As these
important but sometimes subtle distinctions are tricky enough, the naming inconsistencies
made understanding difficult. The proposal supplies a regular pattern of naming. First we
note the 4 different levels at which a concept might appear:
Type level – Represents generic types of entities in models, such as classes, etc. These
are the most common constituents of models.
Instance level – These are the things that models represent at runtime. They don’t appear
in models directly (except very occasionally as detailed examples), but they are necessary
to explain the semantics of what models mean.
Uses within a context – These are the things that represent instances within a generic,
reusable context. A realization of UML2 was that the things called instances in UML1
were mostly roles: they map to instances in an instance of their container, but they are not
instances because they are generic.
Value specifications – Another realization of UML2 is that values can be specified at
various levels of precision. What appears in models is usually not values but
specifications of values that may or may not correspond to a single value.
Individual appearances of a type within a context – These are the roles within a generic,
reusable context. When their context is instantiated, they are also bound to contained
instances, but as model elements they are reusable structural parts of their context; they
are not instances themselves. A realization of UML2 was that the things called instances
in UML1 were mostly roles: they map to instances in an instance of their container, but
they are not instances because they are generic.
We have the following categories of concepts that we try to name using uniformnaming
patterns:
Types : Instances : Modeling of instancesValues : Individual use within a contextUses
Classifier : Instance : InstanceSpecification : Part, /Role, XXXUse (e.g.,
CollaborationUse)
Class : Object : InstanceSpecification : Part, Attribute
Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger)
(XXXUse)
Behavior : Execution : ExecutionSpecification : (various) (e.g., ActivityNode, State),
XXXUse (e.g., InteractionUse)
The appearances have too wide a variety of names to reduce to a single pattern, although
the form XXXUse is suggested for simple cases. In particular, the word “event” has been used inconsistently throughout the document to
mean both type and instance. The word “event” will now mean the type and the word
“occurrence” will mean the instance. When necessary, the clarifications full form event
(type) and (event) occurrence are may be used. Note that this is consistent with the
frequent usage “an event occurs” = the occurrence of an event of a given type, so much of
the language can be left unchanged; it is not necessary (and in fact is probably wrong) to
say “an event occurrence occurs”, because the noun form (an occurrence of X) and the
verb form (an event X occurs) are really too ways to say the same thing.
Event restored as metaclass.
The other complaint was the removal in the UML2 adopted specification of the
subclasses of Event by pushing all of the subtyping information into subtypes of Trigger.
While this works OK for transitions, it removed the possibility of talking about the
various kinds of events directly, which several people emphasized was important.
The other change has been addingSo I have restored subclasses of Event: ChangeEvent,
SignalEventSendEvent, etc, etc. At the same time I removed the subclasses of Trigger,
because Trigger will now just reference an Event, which can be of any subtype. This
change was urgently requested by several people and it does close a big hole in the
conceptual model at little cost (except for lots of minor edits). The metamodel cost is
only one additional reference within Trigger and a couple of extra constraints in actions
to make sure the right kind of event is reference in a trigger. But it now allows the
various event subclasses to be used independently of Trigger, which seems important for
descriptive purposes to many people.
Conflicts with the new naming pattern
I have had to rename a few other classes to avoid confusion, notably
CollaborationOccurrence to CollaborationUse (it has nothing to do with event
occurrence, so the name was misleading). The English word “occurrence” has several
senses, but we have given a temporal meaning to “occurrence” and a “spatial” meaning to
“use”.
I have gone through and cleaned up the usage of the words event, trigger, and occurrence,
consistent with these general principles. I didn’t fuss about every minor wording where
the meaning is clear enough, but I focused on all the important or possible misleading
wordings, especially in definitions and key semantics. Hopefully the terminology is now
consistent and uniform.
Imprecise wording
I also corrected some language that was imprecise in making distinctions between the
various levels of behavior. Changes to the published UML superstructure text:
Note: Boldface within quotes shows the portion of the quote that changed. Roman face shows the
unchanged portion. This convention is not applicable if the whole quote is in roman face.
Changes to the metamodel are shown in red.
Event stuff – This replaces the Trigger subclasses with Event subclasses (as in UML1)
and makes necessary changes in wording
p212, diagram 150 and metamodel, Accept event actions: Delete association from
AcceptCallAction to CallTrigger with rolename ‘trigger’.
p216, AcceptCallAction, Associations: Delete ‘trigger: CallTrigger’ entry.
p216, AcceptCallAction, Constraints, rephrase constraint 1:
The result pins must match the in and inout parameters of the operation specified by the trigger event in
number, type, and order.
p216, AcceptCallAction, Contraints: Add new constaint 2:
“[2] The trigger event must be a CallEvent.
self.trigger.event.oclIsKindOf (CallEvent)”
p216, AcceptCallAction, Semantics, sentence 1, rephrase as:
This action accepts events representing the receipt of calls on the operation specified by the trigger call
event.
p217, AcceptEventAction, Associations, trigger, rephrase comment sentence 2:
“If it is a trigger with a signal event, a signal of any subtype of the specified signal type is accepted.”
p217, AcceptEventAction, constraints, rephrase constraints 2 and 3 as follows:
“[2] If the trigger event is a ChangeEvent, there are no output pins. Same is true for CallEvent if this class
is AcceptCallAction and not one of its children.
[3] If the trigger event is a SignalEvent or a Time Event, there is exactly one output pin.”
p254, ReplyAction, Associations, replyToCall: Change type from “CallTrigger” to “Trigger” and rephrase
the comment as “The trigger specifying the operation whose call is being replied to.”
p254, ReplyAction, Constraints, rephrase constraint 1:
“[1] The reply value pins must match the return, out, and inout parameters of the operation on the event
on the trigger in number, type, and order.” p254, ReplyAction, Constraints, add new constraint:
“[2] The event on replyToCall trigger must be a CallEvent.
self.replyToCall.event.oclIsKindOf (CallEvent)”
p254, ReplyAction, Semantics, Paragraph 2, last sentence, replace “call trigger” with “call event on the
trigger”.
p377, Diagram 317, Triggers:
Remove all the subclasses of Trigger. Add a directed association from Trigger to a new class Event with
the rolename ‘event’, multiplicity 1. [[Not shown in the PDF file]]
Add a new diagram “Events” after diagram “Triggers”. Place it in package Communications. Place in it
abstract class Event as a subclass of PackageableElement. Take the hierarchy of classes formerly
subclassed from Trigger, replacing ‘Trigger’ in each class name with ‘Event’, and place the new hierarchy
as a subclass to Event. Rename “AnyEvent” (formerly “AnyTrigger”) to be “AnyReceiveEvent”. The
subclasses preserve the attributes and associations that existed in the former hierarchy under Trigger.
On the new Events diagram, also add as subclasses of Event the abstract metaclasses
ExecutionEvent and LifetimeEvent. Add an association to Behavior called “behavior”
with multiplicity 0..1. Add as subclasses of ExecutionEvent the concrete metaclasses
ExecutionStartEvent and ExecutionFinishEvent. Add an association to Classifier called
“type” with multiplicity 0..1. Add as subclasses of LifetimeEvent the concrete
metaclasses CreationEvent and DestructionEvent.
p378, Diagram 318, Simple Time: Replace class “TimeTrigger” with class “TimeEvent”.
P378: Insert the following new entries into the chapter in the appropriate alphabetic order. Add the
appropriate empty sections to satisfy the style.
[begin inserted text]
ExecutionEvent (from Events)
An abstract class representing the initiation or completion of execution of behavior.
Associations
behavior: Behavior[0..1] -- The kind of behavior whose execution is being modeled.
Semantics
This event represents the initiation or completion of execution. The kind of behavior being modeled is
optional.
[Thomas: Is Behavior the most general class to type an execution? I know there were a
number of changes to the schema. Maybe it is an Action now. We want to cover
anything that could be an execution region on a lifeline, at least. Please check.]
ExecutionInitiationEvent (from Events)
An event representing the initiation of execution of a behavior. Semantics
This event is not usually used as a trigger. It is usually used in interaction models.
ExecutionCompletionEvent (from Events)
An event representing the completion of execution of a behavior.
Semantics
This event is not usually used as an explicit trigger. On a transition, the absence of a trigger implies the
completion event of the current state. It is usually used in interaction models.
LifetimeEvent (from Events)
An abstract class representing the creation or destruction of an instance.
Associatons
objectType: Classifier[0..1] -- The type of instance being modeled.
Semantics
This event reperesents the creation or destruction of an instance. The type of instance is optional.
CreationEvent (from Events)
An event representing the creation of an instance.
Semantics
This event is not usually used as an explicit trigger. It is usually used in interaction models.
DestructionEvent (from Events)
An event representing the destruction of an instance.
Semantics
This event is not usually used as an explicit trigger. It is usually used in interaction models.
[end inserted text]
p379, AnyTrigger:
Title: Change “AnyTrigger” to “AnyMessageEventAnyReceiveEvent”
Description: Rephrase: “An AnyMessageEvent AnyReceiveEvent for a given transition specifies that the
transition is triggered by the receipt of any message except for those specified explicitly on other transitions
for the same state.”
Semantics: Rephrase: “An AnyMessageEvent AnyReceiveEvent for a given transition specifies that the
transition is triggered by the receipt of any message except for those specified explicitly on other transitions
for the same state.”
Notation: Replace “AnyTrigger” with “AnyMessageEventAnyReceiveEvent”.
p385, CallTrigger:
Title: Replace “CallTrigger” by “CallEvent”
Summary: Replace by: “A CallEvent models the receipt by an object of a message invoking a call of an
operation.”
Description: Rephrase the first sentence as “A call event represents the reception of a request to invoke a
specific operation.” (cutting the final phrase of the original sentence)
Associations: Delete the phrase “that is specified by the call trigger” from the comment. Semantics: Rephrase first sentence as “A call event represents the reception of a request to invoke a
specific operation on an object.”
Changes from UML 1.x: Delete this section entirely.
p385, ChangeTrigger:
Title: Change “ChangeTrigger” to “ChangeEvent”.
Summary: Replace with “A change event models a change in the system configuration that makes a
condition true.”
Description, beginning of first sentence: Change “A change trigger specifies an event that occurs” to “A
change event occurs”.
Notation: Rephrase as “A change event is denoted in a trigger by a Boolean expression.”
Changes from UML1.x: Delete entire section.
p391, insert new class Event:
[begin insert]
Event (from Communications)
Description
An event is the specification of some occurrence that may potentially trigger effects by an object.
Attributes
No additional attributes.
Associations
No additional associations.
Constraints
No additional constraints.
Semantics
An event is the specification of some occurrence that may potentially trigger effects by an object. This is an
abstract metaclass.
Notation
None.
Changes from UML 1.x
None.
[end insert]
p392, MessageTrigger:
Title: Change “MessageTrigger” to “MessageEvent”.
Description: Rephrase as: “A message event specifies the receipt by an object of either a call or a
signal. MessageEvent is an abstract metaclass.”
p396, SignalTrigger:
Title: Change “SignalTrigger” to “SignalEvent”.
Summary: Delete the phrase “the fact that a behavior may trigger based upon”.
Semantics: Replace the first sentence by: A signal event occurs when a signal message, originally caused
by a send action executed by some object, is received by another (possibly the same) object.” p399, TimeTrigger:
Title: Change “TimeTrigger” to “TimeEvent”.
Summary: Replace entirely with “A TimeEvent specifies a point in time. At the specified time, the event
occurs.”
Description: Replace entirely with “A time event specifies a point in time by an expression. The expression
might be absolute or might be relative to some other point in time.
Changes from UML1.x: Delete “This metaclass replaces TimeEvent.”
p400, Trigger:
Summary: Rephrase as “A Trigger relates an Event to the Behavior that it may effect in an instance of a
Classifier. Event is an abstract metaclass.”
SemanticsDescription: Second sentence: Replace “triggers” by “trigger”. Third sentence: Delete “Trigger is
an abstract metaclass.”
Semantics: Delete sentence 3 “Based on ... respectively.”
Changes from UML1.x: Delete the final sentence “In UML2.0 ... event type.”
p498: TimeTrigger (from BehaviorStateMachines, as specialized):
Title: Change title to “TimeEvent”.
Description: Change “time triggers” to “time events”.
Naming pattern stuff and precise wording – overview explanation
(The current specification doesn’t have any overview that ties together the model and the runtime
configurations that it models. This provides at least a brief introduction and lays out the naming
conventions.)
Chapter 6, Preface. Before the Acknowledgements, insert the following sections:
[begin insertion]
Models and What They Model
A model contains three major categories of elements: classifiers, events, and behaviors. Each major
category models individuals in an incarnation of the system being modeled. A classifier describes a set of
objects; an object is an individual thing with a state and relationships to other objects. An event describes a
set of possible occurrences; an occurrence is something that happens that has some consequence within the
system. A behavior describes a set of possible executions; an execution is the performance of an algorithm
according to a set of rules. Models do not contain objects, occurrences, and executions, because those
things are the subject of models, not their content. Classes, events, and behaviors model sets of objects,
occurrences, and executions with similar properties. Value specifications, occurrence specifications, and
execution specifications model individual objects, occurrences, and executions within a particular context.
The distinction between objects and models of objects, for example, may appear subtle, but it is important.
Objects (and occurrences and executions) are the domain of a model and, as such, are always complete,
precise, and concrete. Models of objects (such as value specifications) can be incomplete, imprecise, and
abstract according to their purpose in the model. Semantic Levels and Naming
A large number of UML metaclasses can be arranged into 4 levels with metasemantic relationships among
the metaclasses in the different levels that transcend different semantic categories (e.g., classifiers, events,
behaviors). We have tried (with incomplete success) to provide a consistent naming pattern across the
various categories to place elements into levels and emphasize metarelationships among related elements in
different levels. The following 4 levels are important:
Type level – Represents generic types of entities in models, such as classes, states, activities, events, etc.
These are the most common constituents of models because models are primarily about making generic
specifications.
Instance level – These are the things that models represent at runtime. They don’t appear in models
directly (except very occasionally as detailed examples), but they are necessary to explain the semantics of
what models mean. These classes do not appear at all in the UML2 metamodel or in UML models, but they
underlie the meaning of models. We provide a brief runtime metamodel in the Common Behavior chapter,
but we do not formally define the semantics of UML using the runtime metamodel. Such a formal
definition would be a ma jor amount of work.
Uses within a context – These are the things that represent instances within a generic, reusable context. A
realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances
in an instance of their container, but they are not instances because they are generic.
Value specifications – A realization of UML2, compared to UML, is that values can be specified at various
levels of precision. The specification of a value is not necessarily an instance; it might be a large set of
possible instances consistent with certain conditions. What appears in models is usually not instances
(individual values) but specifications of values that may or may not be limited to a single value. In any
case, models contain specifications of values, not values themselves, which are runtime entities.
Individual appearances of a type within a context – These are roles within a generic, reusable context.
When their context is instantiated, they are also bound to contained instances, but as model elements they
are reusable structural parts of their context; they are not instances themselves. A realization of UML2 was
that the things called instances in UML1 were mostly roles: they map to instances in an instance of their
container, but they are model elements, not instances, because they are generic and can be used many times
to generate many different instances.
We have established the following categories of concepts that we try to name using uniformnaming
patterns:
Types : Instances : Modeling of instancesValues : Individual use within a contextUses
Classifier, Class : Instance, Object : InstanceSpecification : Part, /Role, Attribute, XXXUse (e.g.,
CollaborationUse)
Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger)
(XXXUse) Behavior : Execution : ExecutionSpecification : (various) (e.g., ActivityNode, State), XXXUse (e.g.,
InteractionUse)
The appearances category has too wide a variety of elements to reduce to a single pattern, although the
form XXXUse is suggested for simple cases where an appearance of an element is contained in a definition
of the same kind of element.
In particular, the word “event” has been used inconsistently in the past to mean both type and instance. The
word “event” now mean the type and the word “occurrence” means the instance. When necessary, the
clarifications phrases “event (type” (for event)) and “(event) occurrence” (for occurrence) are may be used.
Note that this is consistent with the frequent English usage “an event occurs” = the occurrence of an event
of a given type; so to describe a runtime situation, one could say “event X occurs” or “an occurrence of
event X” depending on which form is more convenient in a sentence. It is redundant and incorrect to say
“an event occurrence occurs”.
[end insertion]
Naming pattern stuff – renaming in the metamodel and text
p369, Figure 306: Change “BehaviorOccurrence” to “BehaviorPerformance”.
p370, BasicBehaviors, second paragraph: Change each appearance of “event” to “occurrence”.
p370, Figure 307: In the diagram, change each appearance of the subword “Event” to
“Occurrence” within a name.
p371, first full paragraph, first sentence: Insert “an occurence of” before “an invocation event may result”.
p371, Figure 308, Communication Domain Model: Change “InvocationEvent” to “InvocationOccurrence”
and change “ReceivingEvent” to “ReceiveOccurrence” [sic].
p371, last paragraph: Change all appearances of “event” to “occurrence”.
p372, Figure 309, Domain Model Showing Request Kinds: Change all subwords “Event” to “Occurrence”
in names, except change “ReceivingEvent” to “ReceiveOccurrence”.
p372, after Figure 309 in section “Communications”, replace all text on page as follows,:
[begin insert]
An invocation event occurrence represents the recognition of an invocation request after its receipt by a
target object. Invocation event occurrences are the result of the execution of invocation actions (see
“InvocationAction” on page 236). Invocation actions include send actions and call actions. A send action is
specified by a Signal (see “Signal” on page 395) and argument values. The execution of a send action results in a send request, which results in a call event occurrence when it is recognized by the target object.
A call action is specified by an Operation and argument values. The execution of a call action results in a
call request, which results in a call event occurrence when it is recognized by the target object. Signal event
occurrences and call event occurrences are specified by the corresponding metaclasses (see “SignalEvent”
on page 396 and “CallEvent” on page 385).
As shown in Figure 308, an object hosts a behavior execution (i.e., a behavior will be executed in the
context of that object). The execution of an invocation action by the behavior constitutes an invocation
occurrence. The invocation occurrence results in a request object that transmits the invocation request from
the sender object (caller) to the receiver object (target). The receipt of the request by the receiver is
manifest as a receive occurrence. When the receive occurrence matches a trigger defined in the class of the
target object, it causes the execution of a behavior. The details of identifying the behavior to be invoked in
response to the occurrence of an event are a semantic variation point. The resulting behavior execution is
hosted by the target object. The specific mechanism by which the data passed with the request (the
attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the
data or copies are passed with the request) is a semantic variation point. If the invocation action is
synchronous, the request object also includes sufficient information to identify the execution that invoked
the behavior, but this information is not available for the use of the invoked behavior (and, therefore, is not
modeled). When a synchronous execution completes, this information is used to direct a reply message to
the original behavior execution.
The detection of an (event) occurrence by an object may cause a behavioral response. For example, a state
machine may transition to a new state upon the occurrence of an event specified by a trigger owned by the
state machine or an activity may be enabled upon the occurrence of an event specified by a trigger owned
by an object. When an event occurrence is recognized by an object, it may have an immediate effect or the
event may be saved in an event pool and have a later effect when it is matched by a trigger specified for a
behavior.
The occurrence of a change event (see “ChangeEvent” on page 385) is based on some expression becoming
true. A time event occurs when a predetermined deadline expires (see “TimeEvent” on page 399). No data
is passed by the occurrence of a change event or a time event. Figure 317 shows the hierarchy of events.
[end of insert]
p373, Figure 310, Domain Model showing event kinds: Delete diagram.
The following changes to Chapter 14, Interactions, bring the terminology in line with the
remainder of the spec. Most notably, ExecutionOccurrence and EventOccurrence are
renamed ExecutionSpecification and OccurrenceSpecification to be parallel to
ValueSpecification (where execution and occurrence belong to the run-time system like
object and value). Note, however, that trace, as discussed in this chapter, properly
belongs to the run-time system, therefore discus sions of (event) occurrences in traces
remain valid (probably more valid than previously, with the proper distinction between models of instances and instances themselves). [There is additional loose wording in this
chapter that mixes up class models, instance models, and actual instances, but I’m not
going to rewrite all of that; most of it is understandable enough if you don’t take it
literally.]
Pp405326ff, Figure 326 and the following diagrams: In the metamodel, change class
“ExecutionOccur rence” to “ExecutionSpecification” and change “EventOccurrence” to
“OccurrenceSpecification” using a captial- letter-sensitive replace. Change class
“Interactio nOccurrence” to “InteractionUse”. Propagate the change to all the diagrams in
the chapter. Do a search-and-replace on these terms throughout the chapter. Do NOT
replace “eventoccurrence” or “event occurrence”, which properly refer to the run-time
environment.
p416, EventOccurrence: Should have been replaced by “OccurrenceSpecification”
Rephrase first paragraph as follows:
“OccurrenceSpecifications represent event occurrences -- moments in time to which the executions of
Actions are associated. An OccurrenceSpecification is the basic semantic unit of Interactions. The
sequences of occurrences specified by them are the meanings of Interactions. Messages are sent through
either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions
of consumption.”
Remainder of section: The replace specified previously should have been done.
p417, ExecutionOccurrence: Should have been replaced by “ExecutionSpecification” but
requires some modification.:
Replace the first paragraph as follows:
'An ExecutionSpecification is a specification of the execution of a unit of behavior within the Lifeline.
Since the The duration of an ExecutionSpecification will have some duration, it is represented by two
OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.'
Remainder of section: The chapter-wide subsititions should have been done.
Semantics: Replace the text as follows:
The trace semantics of Interactions merely see an ExecutionnOccurrence as the trace <start, finish>.
There may be event occurrences between these. Typically the start event occurrence and the finish event
occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a
Message) and the send OccurrenceSpecification (of a return Message).
p419, Interaction, Semantics, third paragraph, first sentence, rephrase:
“A trace is a sequence of event occurrences, each of which is described by an
OccurrenceSpecification in a model.” p420, Interaction, Relation of Trace Model to Execution Model, paragraph 3-6, rephrase:
An InvocationOccurrence in the Execution model corresponds with an (event) Occurrence in a trace.
Occurrences are modeled in an Interaction by OccurrenceSpecifications. Normally in Interaction the
action leading to the invocation as such is not described (such as the sending action). However, if it is
desirable to go into details, a Behavior (such as an Activity) may be associated with an
OccurrenceSpecification. An occurrence in Interactions is normally interpreted to take zero time.
Duration is always between occurrences.
Likewise a ReceiveOccurrence in the Execution model is modeled by an OccurrenceSpecification.
Similarly the detailed actions following immediately from this reception is often omitted in Interactions,
but may also be described explicitly with a Behavior associated with that OccurrenceSpecification.
A Request in the Execution model is modeled by the Message in Interactions.
An Execution in the Execution model is modeled by an ExecutionSpecification in Interactions. An
Execution is defined in the trace by two Occurrences, one at the start and one at the end. This corresponds
to the StartOccurrence and the CompletionOccurrence of the Execution model
p423, InteractionOccurrence: Should have been renamed to “InteractionUse”.
The chapter-wide substitution will fix the wording in the text of this class.
p443: Replace “CollaborationOccurrence” and “Collaboration Occurrence” by
“Collaboratio nUse” everywhere on the page.
Conflicts with the new pattern—necessary renamings
Need to replace some other uses of the word “Occurrence” in class names, normally with
the word “Use”, to avoid semantic confusion about the names:
p155: In metamodel Figure 100 and elsewhere in the metamodel rename
“CollaborationOccurrence” to be “CollaborationUse” and propagate to diagrams (notably
figure 100). In the association Classifier-CollaborationUse (as renamed) rename
rolename “occurrence” to “collaborationUse”. Global replace in the document “CollaborationOccurrence”
with “CollaborationUse”. Global replace “collaboration occurrence”
with “collaboration use” (cloning capitals).
p157, Classifier (as specialized), associations: rename “occurrence” as
“collaborationUse”.
p179: Top diagram: Rename “Collaboration Occurrence” as “Collaboration Use”. p424, within syntax and following paragraphs: Rename “collaborationoccurrence” as
“collaborationuse”.
Event versus occurrence—cleaning up imprecise wording
The following changes clean up the use of the word event as distinguished from (event)
occurrence:
p216, AcceptCallAction, Semantics, first paragrap


Issue 6690: UML2 Super/Signal (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
13.3.21 suggests that Signal has no additional associations, and yet in
Figure 316 it has ownedAttribute.


I also note that in the mdl file Signal inherits from BehaviouredClassifier
but I can't see that on Figure 316


If it is a BehaviouredClassifier it seems odd that it has no concrete
BehaviouralFeatures.

Resolution: see above
Revised Text:
Actions taken:
December 10, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the Associations section for Signal, add:
ownedAttribute: Property [*] The attributes owned by the signal. The association
is ordered and subsets Classifier.attribute and Namespace.ownedMember.
In the mdl file, delete the specialization of Beha vioredClassifier by Signal.


Issue 6691: Consistent Naming (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:
Associations with and end on the class Value Specification that subset owner have inconsistent names:

 

ownerUpper

ownerLower

owningConstraint

owningInstanceSpec

owningParameter

owningProperty

owningSlot

 

I would recommend renaming ownerUpper and ownerLower to owningUpper  and owningLower to be consistent.

 

All other properties that subset owner on other classes should be renamed consistently:


Resolution: see above
Revised Text:
Actions taken:
December 11, 2003: received issue
March 8, 2005: closed issue

Discussion:
This is being rather picky, but is an easy change in both the Infrastructure and
Sueprstructure (since these are non-navigable association ends they are not actually
referenced in the text).
Superstructure resolution:
In figure 10 on page 40, change the association end names “ownerUpper” and
“ownerLower” to “owningUpper” and “ownignLower” respectively.
Infrastructure resolution:
In figure 46 on page 75, change the association end names “ownerUpper” and
“ownerLower” to “owningUpper” and “ownignLower” respectively.


Issue 6728: page 136, "BasicComponents", (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Ms. Nancy Siegel, omg(at)nancysiegel.com)
Nature: Uncategorized Issue
Severity:
Summary:
Superstructure, final adopted spec 03-08-02, page 136, "BasicComponents", 
contains this inscrutable phrase in the first paragraph: 


In addition, because a itself Class is a subtype of an 
EncapsulatedClassifier,...


This should be fixed up in the final version, if you can 
figure out what you meant to say :-)

Resolution: see above
Revised Text:
Actions taken:
December 18, 2003: received issue
March 8, 2005: closed issue

Discussion:
Change the sentence to read:
In addition, because a Class itself is a subtype of an EncapsulatedClassifier,


Issue 6865: Ambuiguity in value pin evaluation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
When the value specification of a ValuePin is an expression, when is the
expression evaluated?

Resolution:
Revised Text:
Actions taken:
November 5, 2003: received issue
March 9, 2005: closed issue

Discussion:
The text is specific that the value specification is evaluated when the other
prerequisites for starting the action are satisfied.
Disposition: Closed no change


Issue 6868: UML 2 Super/State machines/pseudostate name consistency (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The specification refers to a PseudoState type (page 469), but in the Rose model, it is named "Pseudostate".

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 469, change the title of section 15.3.8 from “PseudoState” to Pseudostate. This
makes it conform to the metamodel in figure 354.


Issue 6869: UML 2 Super / state machines / oclIsKindOf arguments error (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The syntax of the oclIsKindOf() is not correct in all occurrences. For example, constraints 4 and 6 in section 15.3.8 (page 470) use the syntax oclIsKindOf(self.stateMachine, ActivityGraph) whereas constraints 9 and 10 use the syntax owner.oclIsKindOf(Region). 

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
On page 470 in constraint 4 of PseudoState remove the term:
and not oclIsKindOf(self.stateMachine, ActivityGraph)
On page 470 in constraint 6 of PseudoState remove the term:
and not oclIsKindOf(self.stateMachine, ActivityGraph)


Issue 6870: UML 2 Super / state machines / non-existent property reference (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Constraints 4 and 6 in section 15.3.8 (page 470) refer to the non-existent stateMachine property on PseudoState (i.e. self.stateMachine). 

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
This issue was resolved as part of the solution to issue 6872. However, the diagram that
resulted from that fix, incorrectly names the association end Pseudostate::stateMachine as
‘Pseudostate::state machine’. The corresponding text entry is OK and has the proper
name (stateMachine). The following fix needs to be overlaid on top of the change for fix
6872:
?? In the diagram for StateMachines (fig. 354 on page 457 of the FAS), change the name
of the Pseudostate::state machine association end to “stateMachine”
??


Issue 6871: UML 2 Super / state machines / incorrect property redefinition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Constraints 9 and 10 in section 15.3.8 (page 470) refer to the owner property, but the owner property is redefined by Vertex::container, as shown in Figure 354 on page 457. Vertex::container should probably subset owner instead

Resolution: This is a subset of issue 6626 and is resolved by the same resolution.
Revised Text:
Actions taken:
December 31, 2003: received issue
December 2, 2004: closed issue

Issue 6872: UML 2 Super / state machines / misplaced operation definition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The containingStateMachine() operation is defined in the "Additional Operations" for StateMachine (see section 15.3.12, page 491) rather than in the corrsponding section(s) for the type(s) to which it applies.

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
The following holds at present: A state machine is decomposed into 1 or more regions,
which it owns. A region owns a set (possibly empty) of transitions and a set (possibly
empty) of vertices. A special kind of vertex is a state, which can be decomposed into zero
or more regions. The state owns its regions. The general rule, then, is that all transitions
and vertices are owned by a region. However, there are two exceptions: the entry and exit
points of a state machine, which are owned by the state machine itself, and references to
entry and exit points, which are owned by the appropriate state.
Based on this analysis, the function containingStateMachine() needs to be defined for
each of the following classes:
??Vertices (the general case) with special provisions for connection point pseudostates
and connectionpoint references.
??Regions
??Transitions
The following changes need to be made:
(1) Region: on page 476 add the following text after the “Additional constraints” subsection
of the Region metaclass:
Additional operations
[1] The operation containingStateMachine() returns the state machine in which this Region is
defined.
context Region::containingStateMachine () : StateMachine:
result = if stateMachine->isEmpty() then
state.containingStateMachine()
else
stateMachine
(2) Vertex: on page 506 add the following text following the “Associations” section of
the Vertex metaclass: Additional operations
[1] The operation containingStateMachine() returns the state machine in which this Vertex is
defined.
context Vertex::containingStateMachine () : StateMachine:
result = if not container->isEmpty() then
-- the container is a region
container.containingStateMachine()
else if (oclIsKIndOf(Pseudostate)) then
-- entryor exit point?
if (kind = #entryPoint) or (kind = #exitPoint) then
stateMachine
else if (oclIsKindOf(ConnectionPointReference)) then
state.containingStateMachine()
-- no other valid cases possible
(3) Transition: on page 499 add the following text after the “Additional constraints” subsection
of the Transition metaclass:
Additional operations
[1] The operation containingStateMachine() returns the state machine in which this Transition is
defined.
context Transition::containingStateMachine () : StateMachine:
result = container.containingStateMachine()
(4) StateMachine:
(i) Remove constraint [5] of StateMachine on page 490
(ii) Remove additional operation [3] for StateMachine on page 491
For this to work, the association ends of StateMachine::connectionPoint and
State::connection must be made navigable. This means that the following additional
changes need to be made:
(i) Replace the diagram for state machines in Figure 354 on page 457 with the following
diagram: (ii) In the “Associations” sub-section of PseudoState, replace the statement “No
additional associations” with the following item:
??stateMachine: StateMachine [0..1] The StateMachine in which this PseudoState is defined. This
only applies to PseudoStates of the kind entryPoint or exitPoint. {Subsets Element::owner}.
(iii) In the “Associations” sub-section of Connectio nPointReference, add the following
item at the end of the list:
??state: State [0..1] The State in which this PseudoState is defined. {Subsets Element::owner}.


Issue 6873: UML 2 Super / state machines / non-existent return type (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The LCA operation, defined in section 15.3.12 (page 194) has a non-existent return type, CompositeState

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
In the context of the UML2.0 metamodel the LCA of two states shall be a model element
which is either a state or the region, which is the least common container of the states in
the statemachine containment hierarchy. Practically it can be either a region or an
orthogonal states as these are the only statemachine model elements that contain more
than a single element (regular states contain 0..1 region, and therefore won’t be LCAs)
This implies the following corrections to the text:
Constraint 4 on page 470 shall be modified to
[4]All transitions incoming a join vertex must originate in different regions of an orthogonal state.
(self.kind = #join)
implies
self.incoming->forAll (t1, t2 | t1<>t2 implies (self.stateMachine.LCA(t1.source, t2.source).isOrthogonal)
Constraint 6 shall be modified to:
[6] All transitions outgoing a fork vertex must target states in different regions of an orthogonal state.
(self.kind = #fork) implies
self.outgoing->forAll (t1, t2 | t1<>t2 implies
(self.stateMachine.LCA(t1.target, t2.target).isOrthogonal)
The additional operations section (p 491) shall be modified to specify the LCA function
without the OCL definition, since lacking a common metamodel element for state and
region makes the OCL specification of it too cumbersome to add any value.
Therefore the ancestor operation on page 491 shall be removed, and the LCA operation
will be defined as follows:
[1] The operation LCA(s1,s2) returns the an orthogonal state or a region which is least common ancestor of
states s1 and s2 based on the statemachine containment hierarchy.
The paragraph Transition execution sequence shall be corrected on page 501 to the
following: Every transition, except for internal and local transitions, causes exiting of a source state, and entering of
the target state.
These two states, which may be comp osite, are designated as the main source and the main target of a
transition.
The least common ancestor (LCA) of a (compound) transition is a region or an orthogonal state which is
the LCA of the source and target states of the (compound) transition. The LCA operation is an operation
defined for the statemachine class.
If the LCA is a region, then the main source is a direct subvertex of the region which contains the
source states, and the main target is a the subvertex of the region that contains the target states.
In case where the LCA is an orthogonal state, the main source and main target are the orthogonal state
itself. The reason is that transition crossing regions of an orthogonal state forces exit of the entire
orthogonal state and reentering all of its regions.


Issue 6874: UML 2 Super / use cases / invalid subsetting (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
UseCase::extensionPoint subsets Classifier::feature, but ExtensionPoint is not a specialization of Feature.

Resolution: see above
Revised Text:
Actions taken:
December 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
In Figure 401 (and in the corresponding diagram in the metamodel) in the
association end UseCase::extensionPoint, remove the “subsets feature”
specialization leaving only “subsets ownedMember”.
Also, on page 519, the corresponding description should be changed from:
?? extensionPoint: ExtensionPoint References the ExtensionPoints owned by the use case.
(Specializes Classifier.feature and Namespace.ownedMember.)
to:
?? extensionPoint: ExtensionPoint References the ExtensionPoints owned by the use case.
(Specializes Namespace.ownedMember.)


Issue 6875: Components / provided and required interfaces -- derived or subsets (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

Resolution:
Revised Text:
Actions taken:
January 2, 2004: received issue
March 9, 2005: closed issue

Discussion:
[After discussion with the submitter] The above solution would apply if a component
could only expose interfaces through Impleme ntation relationships. However, a
derivation is appropriate because there are 3 ways in which a component can provide an
interface (analogous arguments hold for required interfaces):
The provided interfaces of a component are those interfaces that are
a. implemented by the component or
b those typing its provided ports
c. those interfaces exposed by internal elements (if no interfaces are defined on the
component itself)
This derivation has been formalized in OCL as part of issue 6315.
Disposition: Closed, no change


Issue 6876: Appendix B/Standard Stereotypes too heavyweight and incompletely defined (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This is in my opinion important enough to be considered by the FTF since
it affects implementability.


Appendix B contains a list of Standard Stereotypes. 
Ironically, due to the nature of the UML2 Profile mechanism this
mechanism is more heavyweight than a subclass since it requires a
separate instance - so for the <<call>> stereotype of Usage one ends up
with not only a instance of Usage but an attached instance of Call -
this is far more heavyweight than having a distinct subclass of Usage
which would result in only one object. And it's also harder to process
via XMI or APIs.


The Appendix is not adequate as a definition and does not use the
official Stereotype notation? In particular it does not make clear the
name of the instance of Stereotype (which I can only guess would be the
capitalized form of the stereotype keyword e.g. "Call"), nor does it
specify the name of the association used to attach an instance of the
stereotype with the instance of the metaclass. And, of course, is there
actually a Profile object (or objects) that contains these stereotypes?
Can users consider this Profile already applied to any UML model or does
it have to be explicitly done or is this a variation point? 


Finally, Appendix B is not properly referenced: 7.14.1 refers to the
"Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
Standard Profile".

Resolution: see above
Revised Text:
Actions taken:
January 8, 2004: received issue
March 8, 2005: closed issue

Discussion:
The “lightweight” nature of UML stereotypes in general is in reference to the extent to
which they modify the definition of UML and not to the resources required to maintain
them in a model repository. That is, stereotypes are (intended to be) fully consistent with
the syntax and semantics of standard UML and, therefore, do not change the standard in
any way. On the other hand, so-called “heavyweight” modifications do change the
meaning and/or syntax of the standard, regardless of how minor that might be.
However, the remaining part of the issue raised is deemed valid and the following change
is proposed to deal with the problems identified. The following is a summary of the
changes:
?? The standard profile is divided into three separate profiles corresponding to
compliance levels L1, L2, and L3 (instead of a single profile with three compliance
points Basic, Intermediate, and Complete). This simplifies things and avoids the need
to introduce separate compliance points for the standard profile (see following item). ?? The standard profiles are handled as any other profiles: they can be applied to a
model by the standard mechanism used for any profile (i.e., declaring it explicitly).
?? The tabular format of the original spec is retained since it is adequate and also more
compact and more readable than an equivalent graphical specification. (Note that
none of the standard stereotypes defines additional meta-attributes/tagged values.)
The following changes are required in the document:
1. Move the “implement” stereotype to level L2 (from L1) since components do not
appear at L1.
2. Insert the following new version of the appendix
Disposition: Resolved
C:\mydata\
documents\external\


Issue 6877: UML2 super/notation/Keywords (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This is a general issue that is quite pervasive. I think it is important
enough to be considered by the FTF.


The specification is littered with keywords which are used on diagrams
to indicate various things. 


What the specification sorely needs is an Appendix that gathers them all
together. And cross-references each with where it is defined and the
compliance level it is associated with.
Also what it needs is a general description of the semantics of
keywords, how they differ from 'Standard Stereotypes' and associated
constraints - e.g. it should not be allowed to declare a Stereotype with
a name which, when decapitalized, is the same as a keyword (since they'd
be indistinguishable). 


Arguably keywords would be depicted with a distinct notation from
stereotypes (based on language design principles and to help users
interpret diagrams where they see words in guillemets and don't know
whether to look it up in the list of keywords or stereotypes) but that
is probably too major a change to make at this stage. However the
notation should be clarified to cover the following cases:
A) if the same element requires a keyword and has a stereotype applied
are they shown in 2 separate <<xxx>> expressions or in one, separated by
a comma?
B) if a stereotype is applied to a class normally indicated by a
keyword, does that keyword still need to be provided?

Resolution: see above
Revised Text:
Actions taken:
January 8, 2004: received issue
March 8, 2005: closed issue

Discussion:
The following changes are proposed to resolve this issue:
1. On page 585, insert a new appendix (Appendix B: UML Keywords) in the list of
appendices
2. Create a new appendix (Appendix B), between the current appendices A and B that
explains what keywords are and provides a list and a brief description of each as
follows:
Appendix B. UML Keywords
UML keywords are reserved words that are an integral part of the UML notation and
normally appear as text annotations attached to a UML graphic element or as part of a
text line in a UML diagram. These words have special significance in the context in
which they are defined and, therefore, cannot be used to name user-defined model
elements where such naming would result in ambiguous interpretation of the model. For
example, the keyword “trace” is a system-defined stereotype of Abstraction (see
Appendix C) and, therefore, cannot be used to define any user-defined stereotype. In UML, keywords are used for four different purposes:
?? To distinguish a particular UML concept (metaclass) from others shring the same
general graphical form. For instance, the «interface» keyword in the header box of a
classifier rectangle is used to distinguish an Interface from other kinds of Classifiers.
?? To distinguish a particular kind of relationship between UML concepts (metaassociation)
from other relationships sharing the same general graphical form. For
example, dashed lines between elements are used for a number of different
relationships, including Dependencies, relationships between UseCases and an
extending UseCases, and so on.
?? To specify the value of some modifier attached to a UML concept (meta-attribute
value). Thus, the keyword «singleExecution» appearing within an Activity signifies
that the “isSingleExecution” attribute of that Activity is true.
?? To indicate a Standard Stereotype (see Appendix C). For example, the
«modelLibrary» keyword attached to a package identifies that the package contains a
set of model elements intended to be shared by multiple models.
Keywords are always enclosed in guillemets («keyword») which serve as visual cues to
more readily distinguish when a keyword is being used. (Note that guillemets are a
special kind of quotation marks and should not to be confused with or replaced by
duplicated “greater than” (>>) or “less than” (<<) symbols, except in situations where the
available character set may not include guillemets.) In additio n to identifying keywords,
guillemets are also used to distinguish the usage of stereotypes defined in user profiles.
This means that:
a) Not all words appearing between guillemets are necessarily keywords (i.e., reserved
words) and,
b) Words appearing in guillemets do not necessarily represent stereotypes.
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>]* “»”
where
<label> ::= <keyword> | <stereotype-label>
Keywords are context sensitive and, in a few cases, the same keyword is used for
different purposes in different contexts. For instance, the «create» keyword can appear
next to an operation name to indicate that it as a constructor operation, and it can also be
used to label a Usage dependency between two Classes to indicate that one Class creates
instances of the other. This means that it is possible in principle to use a keyword for a
user-defined stereotype (provided that it is used in a context that does not conflict with
the keyword context). However, such practices are discouraged since they are likely to
lead to confusion.
The keywords currently defined as part of standard UML are specified in Table XXX
below, sorted in alphabetical order. The following is the interpretation of the individual
columns in this table: ?? Keyword provides the exact spelling of the keyword (without the guillemets)
?? Language Unit identifies the language unit in which the keyword is defined (and,
implicitly, the chapter in which the keyword is described)
?? Metamodel Element specifies the element of the UML metamodel (either a metaclass
or a metaclass feature) that the keyword denotes
?? Semantics gives a brief description of the semantics of the keyword (see further
explanations below); more detailed explanations are provided in the Notation sections
of the corresponding metaclass description. The following formats are used
1. If the entry contains the name of a UML metaclass, this indicates that the
keyword is simply used to identify the corresponding metaclass.
2. If the entry is a constraint (usually but not necessarily an OCL expression), it
specifies a constraint that applies to metamodel elements that are tagged with that
keyword.
3. If the entry is in the form“standard stereotype:L<x>”, where <x> = 1, 2, or 3, it
means that the keyword represents a stereotype that is defined at compliance
level. In those cases, the more detailed description of the semantics can be found
in Appendix C.
?? Notation Placement indicates where the keyword appears (see further explanations
below). The following conventions are used to specify the notation placement:
1. “box header” means that the keyword appears in the name compartment of a
classifier rectangle
2. “list box header” means that the keyword is used as a header on a list box
appearing as part of a classifier specification
3. “dashed line label” means that the keyword is used to as a label on some dashed
line, such as a Dependency.
4. “in- line label” means that the keyword appears as part of a text line (usually at the
front), such as an attribute definition
5. “between braces” means that the keyword appears between “curly” brackets
(similar to the constraint notation) and is used to select the value of some property
of a metaclass .
Table XXX. UML keywords
Keyword Language Unit Metamodel Element Semantics Notation Placement
abstraction Classes Abstraction Abstraction box header access Classes PackageImport not (visibility = #public) dashed line label
activity Activities Activity Activity box header
actor Use Cases Actor Actor box header
apply Profiles ProfileApplication Package::appliedProfile
->collect(ap |
ap.importedProfile)
dashed line label
artifact Deployments Artifact Artifact box header
artifacts Deployments Component list box header
attribute Activities ActivityPartition
::represents
ActivityPartition
::represents->forAll(r |
r.oclIsKindOf(Property))
swimlane header
auxiliary Classes Classifier standard stereotype:L1 box header
buildcomponent Components Component standard stereotype:L3 box header
call Classes Usage standard stereotype:L1 dashed line label
centralBuffer Activities CentralBufferNode CentralBufferNode box header
class Activities ActivityPartition
::represents
Activitypartition
::represents->forAll(r |
r.oclIsKindOf(Class))
swimlane header
component Components Component Component box header
create Classes Usage standard stereotype:L1 dashed line label
create Classes BehavioralFeature standard stereotype:L1
(constructor)
in-line label on operation
create CompositeStructures Dependency Applies only to
dependencies between an
InstanceSpec and
Parameter of an operation,
indicating a return
parameter of an Operation
that is a constructor
dashed line label
datastore Activities DataStoreNode DataStoreNode box header
datatype Classes DataType DataType box header
delegate Components Connector Connector::kind =
#delegation
connector label
deploy Deployments Connector delegation connector dashed line label
deployment spec Deployments DeploymentSpecification Deploy mentSpecification box header
derive Classes Abstraction standard stereotype:L1 dashed line label
destroy Classes BehavioralFeature standard stereotype:L1 in-line label on operation
device Deployments Device Device box header
document Deployments Artifact standard stereotype:L2 box header
element access Classes ElementImport not (visibility = #public) dashed line label
element import Classes ElementImport visibility = #public dashed line label
entity Components Component standard stereotype:L2
(business concept)
box header enumeration Classes Enumeration Enumeration box header
executable Deployments Artifact standard stereotype:L2 box header
executionEnviron
ment
Deployments ExecutionEnvironment ExecutionEnvironment box header
extend Use Cases Extend Extend dashed line label
extended State Machines Region Region::extendedRegion
->notEmpty()
between braces
extended State Machines StateMachine StateMachine
::redefinedBehavior
-> notEmpty()
between braces
external Activities ActivityPartition ActivityPartition
::isExternal = true
swimlane header
file Deployments Artifact standard stereotype:L2 box header
focus Classes Class standard stereotype:L1 box header
framework Classes Package standard stereotype:L1 box header
from Common Behaviors Trigger to show port name in expression
implement Components Component standard stereotype:L1 box header
implementationCl
ass
Classes Class standard stereotype:L1 box header
import Classes PackageImport visibility = #public dashed line label
include Use Cases Include Include dashed line label
information Auxiliary::Informatio
nFlows
InformationItem InformationItem box header
instantiate Classes Dependency Dependency dashed line label
instantiate Classes Usage standard stereotype:L1 dashed line label
interface Classes Interface Interface box header
library Deployments Artifact standard stereotype:L2 box header
localPostconditio
n
Actions Constraint Action::localPostcondition box header
localPrecondition Actions Constraint Action::localPrecondition box header
manifest Deployments Manifestation Manifestation dashed line label
merge Classes PackageMerge PackageMerge dashed line label
metaclass Profiles Classifier metaclass being
stereotyped
box header
metamodel Auxiliary::Models Model standard stereotype:L3 box header
model Auxiliary::Models Model Model box header
modelLibrary Classes Package standard stereotype:L1 box header
multicast Activities ObjectFlow ObjectFlow::isMulticast flow label
multireceive Activities ObjectFlow ObjectFlow
::isMultireceive
flow label occurrence Composite Structures Collaboration (Behavior::context) from a
Collaboration to the
owning
BehavioredClassifier,
indicating that the
collaboration represents
the use of a classifier
dashed line label
postcondition Activities Constraint Behavior::postcondition box header
precondition Activities Constraint Behavior::precondition box header
primitive Classes PrimitiveType PrimitiveType box header
process Components Component standard stereotype:L2 box header
profile Profiles Profile Profile box header
provided
interfaces
Components Component Component::provided list box header
realization Classes Classifier standard stereotype:L2 box header
realizations Components Component Component
::realizations->collect(r |
r.realizingClassifier)
list box header
refine Classes Abstraction standard stereotype:L1 dashed line label
representation Auxiliary::Informatio
nFlows
Classifier InformationFlow
::conveyed
dashed line label
represents Composite Structures Collaboration (Behavior::context) from a
Collaboration to the
owning
BehavioredClassifier;
collab. Is USED in the
classifier
dashed line label
required
interfaces
Components Component Component::required list box header
responsibility Classes Usage standard stereotype:L1 dashed line label
script Deployments Artifact standard stereotype:L1 box header
selection Activities Behavior ObjectFlow::selection box header
selection Activities Behavior ObjectNode::selection box header
send Classes Usage standard stereotype:L1 dashed line label
service Components Component standard stereotype:L2 box header
signal Common Behaviors Signal Signal box header
singleExecution Activities Activity Activity
::isSingleExecution = true
inside box
source Deployments Artifact standard stereotype:L2 box header
specification Components Classifier standard stereotype:L2 box header
statemachine State Machines BehavioredClassifier::
ownedBehavior
BehavioredClassifier
::ownedBehavior.
oclIsKindOf(
StateMachine)
box header
stereotype Profiles Stereotype Stereotype box header
structured Activities StructuredActivityNode StructuredActivityNode box header
substitute Classes Substitution Substitution dashed line label subsystem Components Component standard stereotype:L2 box header
systemModel Auxiliary::Models Model standard stereotype:L3 box header
trace Classes Abstraction standard stereotype:L1 dashed line label
transformation Activities Behavior ObjectFlow
::transformation
box header
type Classes Class standard stereotype:L1 box header
use Classes Usage Usage dashed line label
utility Classes Class standard stereotype:L1 box header


Issue 6896: "• value : InstanceSpecification (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

Resolution: see above
Revised Text:
Actions taken:
January 10, 2004: received issue
March 8, 2005: closed issue

Discussion:
On page 60 in the “value” attribute of Slot, change the type of this attribute from
“InstanceSpecification” to “ValueSpecification”


Issue 6897: importedMember property (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The importedMember property is derived from the ElementImports and the PackageImports. 

self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()->union(self.packageImport.importedPackage->collect(p | >p.visibleMembers())))) 

The query importedMembers(...) should be importMembers(...). A fixed version is: 

self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()->union(self.packageImport.importedPackage->collect(p | >p.visibleMembers())))) 

Resolution: see above
Revised Text:
Actions taken:
January 10, 2004: received issue
March 8, 2005: closed issue

Discussion:
This is indeed a simple typo and easily fixed. It has to be fixed in both the Infrastructure
and Superstructure.
Superstructure resolution
In the OCL expression for constraint [2] of Namespace on page 36, replace the string
“importedMembers” by the string “importMembers”.
Infrastructure resolution
In the OCL expression for constraint [1] of Namespace on page 143, replace the string
“importedMembers” by the string “importMembers”.


Issue 6898: missing closing bracket (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) ) 


The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) ) 

Resolution: see above
Revised Text:
Actions taken:
January 10, 2004: received issue
March 8, 2005: closed issue

Discussion:
On page 58, replace the OCL expression for constraint [4] with the following
expression:
classifier->forAll(c | (c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)))


Issue 6900: UML 2 Super / Interactions / Two typos (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
On page 408 there is text that says: 

        Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335. 

I think it should say: 

        Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336. 


On page 414 there is text that says 

        See example of the usage of collaboration occurrences in Figure 345. 

I think it should say: 

        See example of the usage of collaboration occurrences in Figure 339. 


Resolution:
Revised Text:
Actions taken:
January 14, 2004: received issue
March 9, 2005: closed issue

Discussion:
Is already resolved in adopted spec text. The text mentioned above is not on page 408,
but on page 418, and it says figure 336, as suggested. The other typo is on page 440, not
414, and it refers to Figure 346, which is correct (you suggest Figure 339, which is about
interaction occurence with value return).
Disposition: Closed, no change


Issue 6901: UML 2 Super / Classes / (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
on page 115 (section 7.15.3) when talking about the Notation of an
interface, the third paragraph (between figure 59 and 60) says:
"
The usage dependency from a classifer to an interface is shown by
representing the interface by a half-circle or socket, labeled
with the name of the interface, attached by a solid line to the 
classifier that **implements** this interface (see Figure 60).
"

And I think it should say:
"
The usage dependency from a classifer to an interface is shown by
representing the interface by a half-circle or socket, labeled
with the name of the interface, attached by a solid line to the 
classifier that **requires** this interface (see Figure 60).
" 
 

Resolution: see above
Revised Text:
Actions taken:
January 14, 2004: received issue
March 8, 2005: closed issue

Discussion:
On page 115, replace the sentence:
The usage dependency from a classifer to an interface is shown by representing
the interface by a half-circle or socket, labeled with the name of the interface,
attached by a solid line to the classifier that implements this interface (see Figure
60).
with the sentence:
The usage dependency from a classifer to an interface is shown by representing
the interface by a half-circle or socket, labeled with the name of the interface,
attached by a solid line to the classifier that requires this interface (see Figure 60).


Issue 6902: UML 2 Super / General / Idenitfy sections specifying run-time semantics (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. 

Resolution: see above
Revised Text:
Actions taken:
January 15, 2004: received issue
March 8, 2005: closed issue

Discussion:
Insert the following text after the last paragraph of section 6.2.
6.3 On the Run-Time Semantics of UML
The purpose of this section of the document is to provide a very high- level view
of the run-time semantics of UML and to point out where the various elements of
that view are covered in the spec. The term “run-time” is used to refer to the
execution environment. Run-time semantics, therefore, are specified as a mapping
of modeling concepts into corresponding program execution phenomena. There
are, of course, other semantics relevant to UML specifications, such as the
repository semantics, that is, how a UML model behaves in a model repository.
However, those semantics are really part of the definition of the MOF. Still, it is
worth remarking that not every concept in UML models a run-time phenomenon
(e.g., the “package” concept).
6.3.1 The Basic Premises
There are two fundamental premises regarding the nature of UML semantics. The
first is the assumption that all behavior in a modeled system is ultimately caused
by actions executed by so-called “active” objects (see definition on page 387).
This includes behaviors, which are objects in UML 2, which can be active and
coordinate other behaviors. The second is that UML behavioral semantics only
deal with event-driven, or discrete, behaviors. However, UML does not dictate the
amount of time between events, which can be as small as needed by the
application, for example, when simulating continuous behaviors.
6.3.2 The Semantics Architecture
Fig. 1 identifies the key semantic areas covered by the current standard and how
they relate to each other. The items in the upper layers depend on the items in the
lower layers but not the other way around. (Note that the struc ture of metamodel package dependencies is somewhat similar to the dependency structure indicated
here. However, they are not the same and should be distinguished. This is because
package dependencies specify repository dependencies not necessarily run-time
dependencies.)
Fig. 1. A schematic of the UML semantic areas and their dependencies
At the highest level of abstraction, it is possible to distinguish three distinct
composite layers of semantic definitions. The foundational layer is struc tural. This
reflects the premise that there is no disembodied behavior in UML – all behavior
is the consequence of the actions of structural entities. The next layer is
behavioral and provides the foundation for the semantic description of all the
higher- level behavioral formalisms (the term “behavioral formalism” refers to a
formalized framework for describing behavior, such as state machines, Petri nets,
data flow graphs, etc.). This layer, represented by the shaded box in Fig. 1, is the
behavioral semantic base and consists of three separate sub-areas arranged into
two sub- layers. The bottom sub- layer consists of the inter-object behavior base,
which deals with how structural entities communicate with each other, and the
intra-object behavior base, which addresses the behavior occurring within
structural entities. The actions sub- layer is placed on top of these two. It defines
the semantics of individual actions. Actions are the fundamental units of behavior
in UML and are used to define fine-grained behaviors. Their resolution and
expressive power are comparable to the executable instructions in traditional
programming languages. Actions in this sub- layer are available to any of the
higher- level formalisms to be used for describing detailed behaviors. The topmost
layer in the semantics hierarchy defines the semantics of the higher-level
behavioral formalisms of UML: activities, state machines, and interactions. Other
behavioral formalisms may be added to this layer in the future.
6.3.3 The Basic Causality Model
The “causality model” is a specification how things happen at run time and is
described in detail in the Common Behaviors chapter on page 369. It is briefly
summarized here for convenience, using the example depicted in the
communication diagram in Fig. 2. The example shows two independent and
possibly concurrent threads of causally chained interactions. The first, identified
by the thread prefix ’A’ consists of a sequence of events that commence with
activeObject-1 sending signal s1 to activeObject-2. In turn, activeObject-2 responds by
invoking operation op1( ) on passiveObject-1 after which it sends signal s2 to activeObject-
3. The second thread, distinguished by the thread prefix ‘B’, starts with activeObject-4
invoking operation op2( ) on passiveObject-1. The latter responds by executing the
method that realizes this operation in which it sends signal s3 to activeObject-2.
The causality model is quite straightforward: objects respond to messages that are
generated by objects executing communication actions. When these messages
arrive, the receiving objects eventually respond by executing the behavior that is
matched to that message. The dispatching method by which a particular behavior
is associated with a given message depends on the higher- level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point).
Fig. 2. Example illustrating the basic causality model of UML
The causality model also subsumes behaviors invoking each other and passing
information to each other through arguments to parameters of the invoked
behavior, as enabled by CallBehaviorAction (see definition on page ??EDITOR).
This purely “procedural” or “process” model can be used by itself or in
conjunction with the object-oriented model of the previous example.
6.3.4 Semantics Descriptions in the Specification
The general causality model is described in the introductory part of chapter 13
(CommonBehaviors) and also, in part, in the introduction to chapter 14
(Interactions) and the section on Interaction (14.3.7) and Message (14.3.14)
The structural foundations are mostly covered in two chapters. The elementary
level is mostly covered in chapter 7, where the root concepts of UML are
specified. In particular, the sections on InstanceSpecifications (section 7.7 of the
FAS), Classes and Associations (section 7.11), and Features (section 7.9). The
composites level is described primarily in chapter 9 (Composite Structures), with
most of the information related to semantics contained in sections 9.3.12
(Property concept) and 9.3.13 (StructuredClassifier). In addition, the introduction
to this chapter contains a high- level view of some aspects of composite structures.
The relationship between structure and behavior and the general properties of the
Behavior concept, which are at the core of the behavioral base are described in
CommonBehaviors (in the introduction to chapter 13 and in section 13.3.3 in
particular).
Inter-object behavior is covered in three separate chapters. The basic semantics of
communications actions are described in the introduction to chapter 11 (Actions)
and, in more detail, in the sections describing the specific actions. These can
potentially be used by an object on itself, so can be inter- or intra-object . The
read/write actions can also be used to by one object to access others objects, so
are potentially inter- or intra-object. These actions can be used by any of the
behavior formalisms in UML, so all are potentially inter-object behaviors.
However, the interactions diagram is designed specifically to highlight interobject
behavior, under its concept of message. These are defined in the
Interactions chapter (sections 14.3.14 and 14.3.15), while the concepts of events
and triggers are defined in the Communications package of CommonBehaviors
(chapter 13). Event occurrences are defined in section 14.3.3 of the Interactions
chapter. The other two behavior formalisms can be translated to interactions
when they use inter-object actions.
All the behavior formalisms are potentially intra-object, if they are specified to be
executed by and access only one object. However, state machines are designed
specifically to model the state of a single object and respond to events arriving at
that object. Activities can be used in a similar way, but also highlight input and
output dependency between behaviors, which may reside in multiple objects.
Interactions are potentially intra-object, but generally not designed for that
purpose.
The various shared actions and their semantics are described in chapter 11. Finally, the higher- level behavioral formalisms are each described in their own
chapters: Activities in chapter 12, Interactions in chapter 14, and State Machines
in chapter 15.


Issue 6911: UML 2 Super / Templates / subsetting templateParameter (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

Resolution: see above
Revised Text:
Actions taken:
January 15, 2004: received issue
March 8, 2005: closed issue

Discussion:
This is correct, since the corresponding association is a specialization of both the
TemplateParameter::parameteredElement to
ParameterableElement::templateParameter association as well as the owner—
ownedElement association. Therefore, the following changes are required:
?? pg. 542, fig. 427, add the “subsets templateParameter” to the specialization
constraint on the ParameterableElement::owningParameter role.
?? Pg. 543 for the description of owningParameter replace:
o owningParameter : TemplateParameter[0..1]The formal template parameter that owns
this element. Subsets Element::owner.
With:
o owningParameter : TemplateParameter[0..1]The formal template parameter that owns
this element. Subsets Element::owner and ParameterableElement::templateParameter..


Issue 6913: The contents of the Interfaces package is shown in Figure 51 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. " 

Should be "Figure 58" 

Resolution: see above
Revised Text:
Actions taken:
January 16, 2004: received issue
March 8, 2005: closed issue

Discussion:
In the first sentence of section 7.15 on page 112, replace “Figure 51” by “Figure
58”


Issue 6914: The query 'hostElement' has some errors (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
See the comment lines starting with -- !! in the following listing: 


-- !! on the next line, ModelElement should probably be changed -- !! to Element. hostElement() : ModelElement; hostElement = if self.Method->size() > 0 then self.Method else if self.State->size() > 0 then self.State else if self.Transition->size() > 0 then self.Transition else if self.Message->size()>0 then self.Message -- !! size should be size() on the next line else if self.Stimulus->size>0 then self.Stimulus endif endif endif -- !! should be endif on the next line endi -- !! missing endif on this line -- !! remove the closing bracket on the next line ]

Resolution: see above
Revised Text:
Actions taken:
January 19, 2004: received issue
March 8, 2005: closed issue

Discussion:
NB: Bran reformatted the issue text to clarify the location of the problem
See resolution to 7319. It removes this operation.


Issue 6915: The section "Associations (BasicActivities)" is not complete (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The section "Associations (BasicActivities)" is not complete because the association between Activity and Action (depicted in Figure 176) is not described. 

The following item should be added to the description: 

- action: Action[0..*] The Actions the Activity is composed of. 

Resolution: See resolution of 7319. This association is replaced with SequenceNode.
Revised Text:
Actions taken:
January 19, 2004: received issue
March 8, 2005: closed issue

Issue 6917: • /context : Classifier [0..1] (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"• /context : Classifier [1] The classifier that owns the behavior of which this action is a part." 

The multiplicity should be [0..1] in order to be consistent with the multiplicity in Figure 176. 


"• /context : Classifier [0..1] The classifier that owns the behavior of which this action is a part." 

Resolution: In Action class, Attributes, change multiplicity of /context to [0..1]
Revised Text:
Actions taken:
January 19, 2004: received issue
March 8, 2005: closed issue

Issue 6918: Inconsistencies between Figure 3 and the detailled description of package (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"• package: Package [0..1] References the owning package of a package. Subsets NamedElement::namespace." 

should be 

"• package: Package [0..1] References the owning package of a type. Subsets NamedElement::namespace." 

Furthermore, the following description for an association depicted in Figure 43 is missing: 

nestingPackage: Package [0..1] References the owning package of a package. Subsets NamedElement::namespace. 

Resolution: see above
Revised Text:
Actions taken:
January 19, 2004: received issue
March 8, 2005: closed issue

Discussion:
It seems that the Superstructure incorrectly reproduced the corresponding diagram from
Constructs in the Infrastructure. The following changes are needed in Figure 43:
?? Change the role name of “Package::ownedClassifier” to “Package::ownedType”
?? Change the role name of “Package::packageExtension” to “Package::packageMerge”
Also, the following needs to be added to the list of Associations of Package on page 100:
?? nestingPackage: Package [0..1] References the Package that owns this Package. Subsets
NamedElement::namespace.


Issue 6919: Inconsistencies between Figure 43 and the detailled description of Package (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Figure 43 includes an association between Package and Type, whose endpoints are "+package" and "+/ownedClassifier" respectively. 

On p. 100, section "Associations", the following association is listed: ownedType: Type[*] 

The name of the endpoint in Figure 43 should be "+/ownedType", not "+/ownedClassifier". 

Resolution: Duplicate of issue 6184.
Revised Text:
Actions taken:
January 19, 2004: received issue
December 2, 2004: closed issue

Issue 6924: UML-2 deployment diagram notation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
An issue concerning UML-2 deployment diagram notation. 

The ExecutionEnvironment notation is a Node symbol with a keyword within guillemots. But what is the keyword? The text says <<ExecutionEnvironment>> but in the examples says <<container>> (figure 136) and <<execution env>> (Table 8, covering the symbols in a deployment diagram). 

Resolution: see above
Revised Text:
Actions taken:
January 26, 2004:
March 8, 2005: closed issue

Discussion:
Update the following occurrences to the standard normative strings
- page 198 «execution env» => «executionEnvironment»
- figure 136, page 193 «container» => «executionEnvironment»
- figure 135, page 192 «container» => «executionEnvironment»
page 193, Notation : «ExecutionEnvironment» => «executionEnvironment»


Issue 6925: UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory.  This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents. 

Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured).  In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear:  "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations." 

Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]).  If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated! 

Resolution: see above
Revised Text:
Actions taken:
January 18, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change meta-model and Figure 331 – multiplicity of “decomposedAs” association
between Lifeline and PartDecomposition – from “1” to “0..1”.
Change text page 427 (description of the decomposedAs property from:
decomposedAs: PartDecomposition[1]References
into:
decomposedAs:PartDecomposition[0..1] References
(i.e., change multiplicity, and add an extra space in front of the word “References” for
readability)


Issue 6926: UML 2 Super / Dependencies / Abstraction should have an optional mapping (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1. 

Resolution: see above
Revised Text:
Actions taken:
January 21, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change Figure 51 so that the association end Abstraction::mapping has a multiplicity of
0..1 as shown below:
0..1
Usage Permission
Realization
Substitution
Classifier
1
*
+contract
{subsets supplier, subsets target}
*
1
+substitution
{subsets ownedElement, subsets clientDependency}
+substitutingClassifier
{subsets client, subsets source}
Classifier
(from Kernel)
OpaqueExpression
(from Kernel)
Abstraction
0..1
+mapping
{subsets ownedElement}
Dependency NamedElement
*
1..*
+clientDependency
+client
*
1..*
+supplierDependency
+supplier
NamedElement
(from Kernel)
DirectedRelationship
(from Kernel)
PackageableElement
(from Kernel)
On page 107, in the Associations section of Abstraction, add a multiplicity specification
to the association end “mapping” as follows:
mapping : Expression[0..1]
Disposition: Resolved


Issue 6928: UML 2 Super / Interactions / navigability of enclosingOperation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329). 

Resolution: see above
Revised Text:
Actions taken:
January 25, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change meta-model and Figure 329 to make enclosingOperand property of
InteractionFragment navigable.


Issue 6929: UML 2 Super / Classes / Properties owned by properties (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers) 

Resolution: see above
Revised Text:
Actions taken:
January 26, 2004: received issue
March 8, 2005: closed issue

Discussion:
Indeed, figure the metamodel fragment shown in Fig. 66, shows that a Property can own
another Property. Since Property is a kind of Feature, it is necessary to loosen the
multiplicity shown in figure 28 from 1..* to 0..*. The following changes are required:
Superstructure specification fixes:
?? In figure 28 on page 71, change the multiplicity of Feature::featuringClassifier from
1..* to 0..*
?? In the Associations subsection of section 7.9.2 (Feature) for the “featuringClassifier”
entry, change the multiplicity fro 1..* to 0..*
Infrastructure specification fixes:
?? In figure 18 on page 45, change the multiplicit y of Feature::featruingClassifier from
1..* to 0..*
??


Issue 6930: UML 2 Super / Realize keyword-stereotype (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired. 

The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this. 

Resolution:
Revised Text:
Actions taken:
January 26, 2004: received issue
March 9, 2005: closed issue

Discussion:
In the resolution to issue 6220, it was clarified that the notation for Realization that uses
the “realize” keyword is invalid. Since there are no other uses of the “realize” keyword,
the statement in Table 28 is now correct: this keyword is retir ed.
Concerning the “bigger problem” alluded to in the issue, it is already raised as part of
issues 6876 and 6877.
Disposition: Closed, no change


Issue 6931: typo p 403 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
We are aware that other parts of the UML languatge definition the term “trace” is used also for other purposes." 

should be 

"We are aware that in other parts of the UML language definition the term “trace” is used also for other purposes." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Correct the spelling of the word “language” on page 403:
We are aware that in other parts of the UML language definition the term “trace”
is used also for other purposes.


Issue 6932: typo p 420 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
These attribute definitions may appear near the top of the diagram frame or within note symbols other places in the diagram." 

should be 

"These attribute definitions may appear near the top of the diagram frame or within note symbols at other places in the diagram." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Add the missing word “at” to the sentence on page 420:
These attribute definitions may appear near the top of the diagram frame or within note symbols at
other places in the diagram.


Issue 6933: typo p 421 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"The local attriburte PIN of UserAccepted is declared near the diagram top." 

should be 

"The local attribute PIN of UserAccepted is declared near the diagram top." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Correct the spelling of the word “attribute” on page 421:
"The local attribute PIN of UserAccepted is declared near the diagram top."


Issue 6934: graphic nodes (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"The graphic nodes that can be included in structural diagrams are shown in Table 14." 

This is refering to Table 14 which lists nodes in *secuence* diagrams, not in *structural* diagrams. Probably, the correct sentence would be: 

"The graphic nodes that can be included in sequence diagrams are shown in Table 14." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change text on page 436 from
"The graphic nodes that can be included in structural diagrams are shown in Table 14."
into
"The graphic nodes that can be included in sequence diagrams are shown in Table 14."


Issue 6935: typo p 240 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source and target." 

should be 

"Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target." 

Resolution: Duplicate with 7012.
Revised Text:
Actions taken:
January 28, 2004: received issue
December 2, 2004: closed issue

Issue 6936: typo p 356 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"The name is not restricted, but it is often just shows the type of object or data that flows through the pin." 

should be 

"The name is not restricted, but it often just shows the type of object or data that flows through the pin." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
In StructuredActivityNode class, Notation section, fourth sentence, remove "is" before
"often".


Issue 6937: object edges" sould be replaced by "object flows (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
They are object nodes and receive values from other actions through object edges." 

==> "object edges" sould be replaced by "object flows". 

"They are object nodes and receive values from other actions through object flows." 

Resolution: In InputPin class, top section, second sentence, replace the last word with "flows".
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Issue 6938: object edges" should be replaced by "object flows (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Output pins are object nodes and deliver values to other actions through object edges." 

==> "object edges" should be replaced by "object flows". 

"Output pins are object nodes and deliver values to other actions through object flows." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
In OutputPin class, top section, second sentence, replace the last word with "flows".


Issue 6940: typo p 340 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
This case maps to a model containing a a join node with all the incoming ..." 

should be 

"This case maps to a model containing a join node with all the incoming ..." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
In ForkNode class, Notation section, in fourth sentence replace the duplicated word "a"
with a single "a".


Issue 6941: Inconsistency between section "Associations" and Figure 327 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In Figure 327, the association end of the association between Lifeline and Expression is called "discriminator", whereas the respective association belonging to Lifeline is called "selector": 

"selector : Expression[0..1] If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change the meta-model and Figure 327 to rename the role name of Expression in the
association with the Lifeline from “discriminator” to “selector” to match the text.


Issue 6942: Constraint [2] - Missing parenthesis in OCL (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
"(self.selector->isEmpty implies not self.represents.isMultivalued()) or (not self.selector->isEmpty implies self.represents.isMultivalued())" 

should be 

"(self.selector->isEmpty() implies not self.represents.isMultivalued()) or (not self.selector->isEmpty() implies self.represents.isMultivalued())" 

Furthermore, I don't understand why this constraint is necessary, since the multiplicy of 'represents' is exactly 1. 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change OCL constraint on page 427 into:
not (self.selector->isEmpty() ) implies self.represents.isMultivalued()


Issue 6943: Wrong association name (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
lifeline: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered" 

should be 

"covered: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered" 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change the attribute name on page 434 (section Association) from “lifeline” to “covered”
as per the issue summary above.


Issue 6944: type p 419 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences." 

should be 

"A GeneralOrdering is shown by a dotted line connecting the two Eventoccurrences." 

Resolution: see above
Revised Text:
Actions taken:
January 28, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change text on page 419 (section Notation) from:
“A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences."
into
"A GeneralOrdering is shown by a dotted line connecting the two EventOccurrences."


Issue 6945: UML 2 Super / Classes / Dependency should not be abstract (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some): 

Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown 
Table 4, P.130, defines a visual symbol for it 
Fig. 101, P.155, shown as abstract 
Fig. 126, P.183, shown as abstract 
Fig 130, P.188, shows a pure dependency in an example 
Table 9, P.199, defines a visual symbol for it

Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters. 


Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
Dependency should clearly not be an abstract class since there are many cases where the
general concept of Dependency is used. Therefore, the diagrams in figures 101 and 126
should be replaced with the following diagrams (respectively) in which Dependency is
shown as concrete. (NB: the diagram above includes the results of applying resolution 6352)
Also, in the metamodel, the class Dependency should be made concrete rather than
abstract


Issue 6946: UML 2 Super / Deployments / Invalid cross-references (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec. 

Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
Update the references in the table as follows:
Association : page 81(section 7.11.2)
Dependency : page 108 (section 7.14.3)
Generalization : page 66 (section 7.8.2)


Issue 6947: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:
Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:



Issue 1:
Top of page 365, text says:
The graphic nodes that can be included in structural diagrams are 
shown in Table 11.


In the next line, the table caption says:
Table 11 - Graphic nodes included in activity diagrams


Proposed resolution:
The table caption is correct, and the text above it needs to be changed 
to conform.

Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
In sentence above Table 11, page 365, replace "structural diagrams" with "activity
diagrams".


Issue 6948: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:
Middle of page 366, text says:
The graphic paths that can be included in structural diagrams are 
shown in Table 12.


In the next line, the table caption says:
Table 12 - Graphic nodes included in activity diagrams


Proposed resolution:
The table caption is correct, and the text above it needs to be changed 
to conform.

Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
In sentence above Table 11, page 366, replace "structural diagrams" with "activity
diagrams".


Issue 6949: Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:
Top of page 367, text says:
Activity diagrams have graphical elements for containment. These 
are included in Table 13.


In the next line, the table caption says:
Table 13 - Graphic nodes included in activity diagrams


Proposed resolution:
These are inconsistent, although not necessarily wrong. They should be 
made consistent. 

Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change caption for Table 13, page 367, to "Graphic elements for containment in activity
diagrams".


Issue 6950: Typo in Collaboration Diagram figure (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Ms. Nancy Siegel, omg(at)nancysiegel.com)
Nature: Uncategorized Issue
Severity:
Summary:
In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443, 
figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs 
a colon, and should be "y:superB" (as it is in the top right box). 

Resolution: see above
Revised Text:
Actions taken:
January 29, 2004: received issue
March 8, 2005: closed issue

Discussion:
Discussion:
On page 443, Figure 346, diagram sd Q change name of the second Lifeline from
“ysuperB” into “y:superB”


Issue 6958: UML 2 Super / General / specialization labeling convention (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent. 

Resolution: see above
Revised Text:
Actions taken:
February 4, 2004: received issue
March 8, 2005: closed issue

Discussion:
In line with the conventions adopted in resolution to issue 7158 the following changes are
required throughout the document:
For each metaclass heading in the Class Descriptions part of each language unit chapter
add, in brackets, the name of the sub-package in which the concept is defined as part of
the title. (We will no longer use the old “specialized” or “as specialized” designation,
since these are all package merge increments and not specializations – as per the new
package merge definition. All headings that use that old form will also be changed to the
new form.) For example,
11.3.2 AcceptEventAction
should be replaced by
11.3.2 AcceptEventAction (from CompleteActions)
If a class increment is defined in multiple packages, the packages will be listed in
alphabetical order separated by commas.
The attached spreadsheet file contains the information on the defining sub-package for
every increment in the spec (in Column C “Sub-Package”).
Disposition: Resolved
C:\mydata\
documents\external\Standards\


Issue 6959: What level of MOF 2.0 is the metamodel for UML 2.0? (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:
UML 2.0 does not state which level of MOF (EMOF, CMOF, or 
whatever else) provides its meta-meta-model. Therefore, there is 
no formal statement defining which Class definition (Basic or 
Constructs package level) and so forth is the basis for the 
definitions in the UML 2.0 specification. UML tools implement 
this class, so it's probably a good idea to know which one it's 
supposed to be. (Proof, in case you're wondering: The names 
EMOF and CMOF do *not* occur anywhere in the Superstructure 
final adopted specification 03-08-02. The name MOF does, but 
not in the context of which version of MOF defines the 
UML metametamodel.) 


If there is an ambiguity in which it is, the FTF needs to resolve 
it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it 
should be stated clearly in the specification.

Resolution: see above
Revised Text:
Actions taken:
February 4, 2004: received issue
March 8, 2005: closed issue

Discussion:
In the newly added section 6.3.1., which describes the specification format,
replace the phrase in the third sentence of the sixth paragraph:
The abstract syntax is defined by a MOF model (i.e., the UML metamodel)…
by the phrase:
The abstract syntax is defined by a CMOF model (i.e., the UML metamodel)…


Issue 6960: Inconsistency betw. Figure 328 and associations listed in s. Associations (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Inconsistency between Figure 328 and the associations listed in section "Associations". 

If there is an association between MessageEnd and Interaction according to 

• interaction: Interaction[1] The enclosing Interaction owning the MessageEnd 

then it is missing in Figure 328. 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
Remove the entire item for “interaction” , including its description, in the Associations
list of MessageEnd on page 431.


Issue 6961: Inconsistent multiplicity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Inconsistent multiplicity 

"• ownedUseCase: UseCase References the use cases owned by this classifier. (Specializes Namespace.ownedMember.)" 

According to Figure 401 the multiplicity should be [*]. ==> 

"• ownedUseCase: UseCase[*] References the use cases owned by this classifier. (Specializes Namespace.ownedMember.)" 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Discussion:
The convention used in the document was that an unspecified multiplicity means [*}.
However, it is better to be explicit. Therefore, the following change needs to be made:
On page 514 for the association ownedUseCase: Use case add the multiplicity so that the
item looks as follows:
o ownedUseCase : UseCase[*] References the use cases owned by this classifier.
(Subsets Namespace.ownedMember)


Issue 6962: UseCase - Extend is not a Namespace (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
UseCase - Extend is not a Namespace 

See association end +condition of the association between Extend and Constraint: +condition {subsets ownedMember} 

Extend is not a Namespace, however. Therefore +condition cannot subset ownedMember. 

Extend should either specialize Namespace or the property string of +condition should be changed to {subsets ownedElement}: +condition {subsets ownedElement} 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Discussion:
?? In figure 401 on page 512, change the constraint on Extend::condition from “{subsets
ownedMember}” to “{subsets ownedElement}”
?? On page 515 in the description for the “condition” association of Extend, change the
last sentence (in parentheses) from “Specializes Namespace.ownedMember.” to
“Specializes Element.ownedElement.”.


Issue 6963: UseCase - Inconsistencies with Figure 401 (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
UseCase - Inconsistencies with Figure 401 

According to Figure 401, the mulitiplicy of association end +subject is "*". 

On page 519 it is "subject : Classifier References the subjects to which this use case applies. The subject ..." 

and should be 

"subject : Classifier[*] References the subjects to which this use case applies. The subject ..." 

dito for "include" and "extend" 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2003: received issue
March 8, 2005: closed issue

Discussion:
Actually, the default is that an unspecified multiplicity means “*”. However, for greater
clarity, the changes recommended above will be made:
Replace the following text on page 519:
??subject : Classifier References the subjects to which this use case applies. The
subject or its parts realize all the use cases that apply to this
subject. Use cases need not be attached to any specific subject,
however. The subject may, but need not, own the use
cases that apply to it.
??include : Include References the Include relationships owned by this use
case. (Specializes Classifier.feature and
Namespace.ownedMember.)
??extend : Extend References the Extend relationships owned by this use
case. (Specializes Classifier.feature and
Namespace.ownedMember.)
??extensionPoint: ExtensionPoint References the ExtensionPoints owned by
the use case. (Specializes Classifier.feature and
Namespace.ownedMember.)
with the text that includes the multiplicities:
?? subject : Classifier[*] References the subjects to which this use case applies. The
subject or its parts realize all the use cases that apply to this
subject. Use cases need not be attached to any specific subject,
however. The subject may, but need not, own the use
cases that apply to it.
??include : Include[*] References the Include relationships owned by this use
case. (Specializes Classifier.feature and
Namespace.ownedMember.) ??extend : Extend[*] References the Extend relationships owned by this use
case. (Specializes Classifier.feature and
Namespace.ownedMember.)
??extensionPoint: ExtensionPoint[*] References the ExtensionPoints owned by
the use case. (Specializes Classifier.feature and
Namespace.ownedMember.)


Issue 6964: Second row of table 22, column "Notation", labels switched (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Second row of table 22, column "Notation", labels switched. 

The use case "Withdraw" should be the including use case. "Card identification" should be the included use case. 

Resolution: Same issue as 6643
Revised Text:
Actions taken:
January 31, 2004: received issue
December 2, 2004: closed issue

Issue 6965: UseCase - Constraint for non-circular include relation (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
UseCase - Constraint for non-circular include relation 

I suggest to add the following fragments to the sections "Additional Operations" and "Constraints": 

Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases. 

UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) ) 


Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self) 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Discussion:
The following fixes are proposed:
?? pg. 520 add the following constraint at the end of the list of constraints:
[4] A use case cannot include use cases that directly or indirectly include it
not self.allIncludedUseCases()->includes(self)
?? pg. 520 Just before the Semantics section add a new section:
Additional Operations
[1] The query allIncludedUseCases() returns the transitive closer of all use cases
(directly or indirectly) included by this use case:
UseCase::allIncludedUseCases() : Set(UseCase)
allIncludedUseCases =
self.include->union(self.include->collect(in | in.allIncludedUseCases())


Issue 6966: Typo in OCL (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Typo in OCL 

extensionLocation->forAll (xp | extendedCase.extensionPoint->include(xp)) 

should be ("includes" instead of "include") 

extensionLocation->forAll (xp | extendedCase.extensionPoint->includes(xp)) 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Discussion:
On page 515, replace the current constraint expression for the first constraint of the
Extend metaclass from
extensionLocation->forAll (xp |
extendedCase.extensionPoint->include(xp))
to
extensionLocation->forAll (xp |
extendedCase.extensionPoint->includes(xp))


Issue 6967: UseCase - Include - Constraint for irreflexivity (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
UseCase - Include - Constraint for irreflexivity 

I suggest to add the following constraint for Include: 

Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase 

Resolution: This issue is resolved by the resolution to issue 6965.
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Issue 6968: typo (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Last sentence on page: 

"..., it is typically defined in _the_ some classifier or package ..." 

Resolution: see above
Revised Text:
Actions taken:
January 31, 2004: received issue
March 8, 2005: closed issue

Discussion:
In the last sentence of the Description of Actor on page 512, replace the sentence:
Since an actor is external to the subject, it is typically defined in the some classifier or package that
incorporates the subject classifier.
By the sentence:
Since an actor is external to the subject, it is typically defined in the same classifier or package that
incorporates the subject classifier.


Issue 6969: UML 2 Super / use cases / incorrect table title (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

Resolution: see above
Revised Text:
Actions taken:
February 2, 2004: received issue
March 8, 2005: closed issue

Discussion:
Change the title of the table on pages 523-524-525 (Table 22) from:
Graphic nodes used in sequence diagrams
To
Graphic nodes used in use case diagrams


Issue 6970: UML2 superstructur: actor (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
UML2 superstructure 03-08-02
p. 513
"[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."



A subsystem is a component stereotype, so it doesn't make sense to mention it here.


I would propose the following constraint instead of the above one:
"[1] An actor can only have associations to classifiers, and these associations must be binary."


It makes sense that an actor can have binary associations to the subject they are interacting with.
The subject of an use case is a classifier.


Resolution: see above
Revised Text:
Actions taken:
February 2, 2004: received issue
March 8, 2005: closed issue

Discussion:
The recommended modification is actually incorrect. The intent of the constraint was to
specifically only allow the associations to 4 types of model elements listed in the
constraint and no others (this was mandated by backward compatibility with 1.x use
cases). Classifier, on the other hand is a much broader category that includes many other
things in addition to the four listed.
However, since subsystem is not a full- fledged metaclass in UML 2.0 but a stereotype of
component, it will be removed from the list.
The recommended resolution is to replace the current first constraint for actors on page
513:
[1] An actor can only have associations to use cases, subsystems, components and
classes, and these associations must be binary.
With the following revised text:
[1] An actor can only have associations to use cases, components, and classes. Furthermore, these
associations must be binary.
self.ownedAttribute->forAll (a |
(a.association->notEmpty()) implies
((a.association.memberEnd.size() = 2) and
(a.opposite.class.oclIsKindOf(UseCase) or
(a.opposite.class.oclIsKindOf(Class) and
not a.opposite.class.oclIsKindOf(Behavior))))


Issue 6972: self-activation notation in Sequence diagrams missing (uml2-superstructure-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.


E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56


This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

Resolution: duplicate
Revised Text:
Actions taken:
February 6, 2004: received issue
December 2, 2004: closed issue

Discussion:
This is a duplicate of issue 6226, since “self-activation” is merely a special case
of the “overlapping execution occurrences” situation.
Disposition: Duplicate


Issue 6974: Ambiguous semantics of isStatic (uml2-superstructure-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
The semantics of isStatic = true is ambiguous for structural features
  declared on classifiers that have children.  It is not defined whether
  this gives a single value for the classifier and all its descendents,
  or values for the classifier and each descendant separately.

Resolution: see above
Revised Text:
Actions taken:
February 9, 2004: received issue
March 8, 2005: closed issue

Discussion:
An example: Suppose some classifier A is specified in UML as having a static
feature, in particular someProperty: integer.
Suppose A is specified as a parent, generalizing two children, B1subA and
B2subA. Suppose further that for some system, which is supposed to conform
with this specification, the value 5 is specified for A.someProperty
Analysis of the issue:
1. UML 2 semantics in the FAS do not determine whether specializations inherit
the value along with the static features of their parents. Given that the child
B1subA will inherit the static .someProperty, must B1subA.someProperty = 5?
2. Readers of the spec are likely to read into UML such inheritance of values,
because OO programming languages provide for inheritance of static values.
The issue asks for a ruling on this point: either explicitly specify inheritance of
static values, or explicitly state that it is a semantic variation point. To take the
third path, of saying the values are CANNOT be inherited, is out of the question
because it would bar us from modeling C++, Java, or C#.
This resolution proposes inheritance of static values should be a semantic
variation point.
Extended di