Issues for UML 2.6 Revision task Force mailing list

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

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

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

Issue 6071: Conditional Node and Loop Node notation missing
Issue 6083: More examples
Issue 6086: More explanation needed on Figure 339
Issue 6088: Parameterization of lifelines
Issue 6137: Promote local conditions to ExecutableNode
Issue 6150: Notation for method
Issue 6353: Deployment a dependency?
Issue 6368: Join nodes that destroy tokens
Issue 6395: UML 2 Super / State machines / Transition triggers cannot be redefined
Issue 6441: Integration between behavioral "sublanguages": Interactions and Activities
Issue 6445: Clarification of use case semantics
Issue 6470: Section 7.11.2 Association
Issue 6487: Conditions for parameter sets
Issue 6497: ptc-03-09-15/Need for examples to include instance models
Issue 6498: ptc-03-09-15/Explain the new association modeling constructs
Issue 6624: freeing namespace
Issue 6645: UML 2.0 Superstructure Kernal/Packages
Issue 6878: UML 2 Infrastructure / rule for redefinition of Property
Issue 6922: Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R
Issue 6927: UML 2 Super / Interactions / Ambiguous diagram tags
Issue 6975: missing illustrations of graphical paths for create and destroy messages
Issue 7223: Questions about DataTypes and generalization
Issue 7227: UML2 Super/Deployment/inheritance
Issue 7229: UML2 Super/Deployments/Manifestation
Issue 7255: Priority of the joint transition
Issue 7329: large overlap between structural features and variables
Issue 7337: inconsistency in the action model
Issue 7338: metaattribute isReadOnly
Issue 7372: surface notation for state machines
Issue 7398: Provide exception handling for all behaviors.
Issue 7620: Coupling between StateMachines and Activities
Issue 7952: Alternative entry and exit point notation is ambiguous
Issue 7997: Too much navigability from Generalizations
Issue 8012: Section: Classes, Behavior
Issue 8014: Disjointness should be independent of generalization
Issue 8016: Action for retrieving activity instance
Issue 8024: End objects of a link In the semantics of AssociationClass
Issue 8026: Contextualized attribute values Figures 121
Issue 8034: Notation for classifierBehavior
Issue 8077: Properties on Association for end objects
Issue 8278: section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification
Issue 8335: ReadStructuralFeatureAction
Issue 8464: Section: 16.3.1
Issue 8473: Activities section
Issue 8479: Section: Activities - clarification
Issue 8480: Section: Activities : Why is exception type needed?
Issue 8489: ExpansionRegion (behavior in the shorthand notation)
Issue 8495: Add constraints on ConditionalNode
Issue 8501: SequenceNode should have way to set output pins in CompleteStructured
Issue 8684: Add a Constraint
Issue 8693: Section: 10.3.1
Issue 8699: UML2-rtf issue: communication diagram
Issue 8700: Meaning of relationship between iteration clause and Lifeline.selector clau
Issue 8748: Operation calls on behavior ports
Issue 8756: Section: Classes
Issue 8758: Association in UseCase diagram
Issue 8761: Arguments of Message
Issue 8764: Section: 14.3.3
Issue 8765: Section: 14.3.3 Page: 508+
Issue 8779: ConditionalNode inputs used by more than one test
Issue 8786: Arguments of Message
Issue 8787: Numbering
Issue 8788: Variables
Issue 8855: Issue 7368 - make Classifier::useCase navigable
Issue 8883: UML 2.0 Super/Use Cases/Subject of a Use Case
Issue 8897: OutputPin
Issue 8898: Syntax of Transition
Issue 8899: reply messages in interactions
Issue 8975: UML2 Super / 14.3.13 Interaction
Issue 9008: Section: Classes
Issue 9013: Section: Activities
Issue 9015: Section: Classes
Issue 9111: Page: 492-493
Issue 9124: Need more flexible notation for activity partitions
Issue 9145: Page: 107
Issue 9225: No notation for associating Exceptions with Operations
Issue 9247: No ReadParameterAction or WriteParameterAction
Issue 9339: consistent ordering of Association::memberEnd and ownedEnd
Issue 9369: Section: 7.3.9
Issue 9370: Section: Sequence diagrams
Issue 9371: All associations ends in the UML2 metamodel itself should be navigable
Issue 9400: Notation for ordering action input and output pins
Issue 9401: ControlNodes in ActivityPartitions
Issue 9402: Reception has no notation for its signal
Issue 9406: UML2: No notation for indicating Operation::raisedException
Issue 9445: Link notation for instance diagrams does not cope with multiple classifiers
Issue 9599: New issue on notation for multiple stereotypes
Issue 9701: Unnecessary restriction on aggregations being binary
Issue 9702: No way of specifying element documentation
Issue 9703: Unclear usage of LiteralExpression::type
Issue 9705: ValueSpecification::isComputable()
Issue 9751: UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement
Issue 9754: Section: 7.3.33
Issue 9805: Default value types
Issue 9834: Relationships
Issue 9840: Section: 15.3.12, p 588, 589
Issue 9842: Guidance for Representing Enumeration Values
Issue 9886: OCL Syntax in expressions
Issue 9887: Optional values and evaluation of defaults
Issue 9923: Section: 13 & 14
Issue 9962: Subclasses of InstanceSpecification
Issue 9999: Association::isDerived should be derived
Issue 10345: Section: 7
Issue 10411: Section: Chapter: 7.3.2.4 View
Issue 10413: Constraint.context vs Constraint.constrainedElement
Issue 10474: Connector contract is inflexible
Issue 10597: Behavioral port
Issue 10600: UML 2 Superstructure: Abstractions should be acyclic
Issue 10635: Presentation option for return parameter for operation type are incomplete
Issue 10656: clarification on Behavior::specification / meaning of InterfaceRealization
Issue 10781: Section: 10.3.4 of formal/2007-02-03
Issue 10821: ValueSpecification that refers to some Element shall be defined
Issue 10822: Ability to define "context specific" default values for Part
Issue 10823: names and namespaces
Issue 10824: Units and types are still problematic
Issue 10957: UML 2.1.1 - notation for parameter sets
Issue 10999: 9.3.9 Invocation Action
Issue 11092: Section: 14.4 Timing Diagram: Continuous time axis
Issue 11272: Section: Annex A: Diagrams
Issue 11273: Section: Annex A: Diagrams
Issue 11287: Section: 7.3.3
Issue 11307: Section: 16.3.5
Issue 11323: UML2 Property collaborationRole should be removed
Issue 11342: Section: 7.3.37 Package (from Kernel)
Issue 11410: simpleTime package problems
Issue 11807: Figure 7.48 and the accompanying discussion under 7.3.21
Issue 11815: Section: 14.4
Issue 11827: UML2 Issue: notation for Literals does not allow for name
Issue 12162: pull semantics are only supported on Action inputs, not outputs
Issue 12166: should be able to show gates on communication diagrams
Issue 12197: UML 2: Need an explicit listing of all semantic variation points
Issue 12203: UML 2 has lost cability to represent operations by collaborations
Issue 12267: Section: 7.3.41
Issue 12272: Section 7.3.44
Issue 12274: new constraint ?
Issue 12279: Section: 18.3.3
Issue 12285: UML Super 2.1.2: section 18.3.2
Issue 12354: Section: 15.3.7 Constraint [2]
Issue 12355: UML 2.1.2 Super: Execution Specification
Issue 12434: Section: Activities
Issue 12511: Callout notation for many clients/suppliers
Issue 12544: role bindings of a CollaborationUse
Issue 12566: 3 3.2 Behavior (CommonBehaviors/BasicBehaviors)
Issue 12568: Section: 14.3.24, 14.3.20
Issue 12570: UML2 issue regarding Redefinition
Issue 12837: Figure 7.65 and its explanation, P115
Issue 12852: issue to address how problem 11240 was actually addressed in UML 2.2 spec
Issue 12860: InterfaceRealization
Issue 12942: Actors cannot own Operations - a contradiction
Issue 13058: 18.3.8 Generalization of stereotyped model elements
Issue 13088: MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug
Issue 13165: There is no way to specify the behavior of operations which are members of data types
Issue 13192: UML: Standard Techniques to disambiguate crossing lines needed
Issue 13255: UML2.2 RTF: EnumerationLiteral is a DeploymentTarget
Issue 13395: UML2: Unclear how to indicate what events a classifier might send
Issue 13425: Section: 7.3.9 Comment should be NamedElement
Issue 13449: we can create an invalid active state configuration
Issue 13452: Section 9.3.4 Collaboration Use, 2nd constraint creates unneces
Issue 13466: Lack of clarity about meaning of package shapes containing elements with fully qualified names
Issue 13651: UML2.2. Contradications in 14.3.10
Issue 13656: UML 2 - appearance of Association Ends as members of the related classes
Issue 13657: Section: 9.3.11 Port
Issue 13664: UML 2.2 InteractionOperand abstract syntax
Issue 13841: Concrete specialization of the Relationship meta-class are missing
Issue 13848: issue within UPDM with profile diagrams
Issue 13856: Section: 18.3.6
Issue 13858: Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)
Issue 13859: The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading
Issue 13862: Section: 18.3.8
Issue 13908: there are numerous places where associations between UML elements have only one, navigable role
Issue 13926: Template Binding Question
Issue 13927: Subsets vs. Redefines
Issue 13936: UML2: Need clarification on circle plus notation for containment
Issue 14022: Visibility and Import relationships
Issue 14044: Should there be a constraint for extends equivalent to 16.3.6 [4]
Issue 14045: semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear
Issue 14078: UML 2: notation and concepts for unbound and un-owned template parameters are not clear
Issue 14081: Package merge is missing a rule
Issue 14084: Subsets vs. Redefines
Issue 14090: authorize a reference to an operation in a realized interface.
Issue 14183: Need notation option to show type stereotype on typed element
Issue 14186: The spec may require some clarification regarding figure 14.16
Issue 14227: UML: Issue with stereotype icons in a profile
Issue 14356: Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics
Issue 14426: Association class notation with just class or association
Issue 14449: PrimitiveType has missing constraints
Issue 14536: Stereotyped Constraints in UML
Issue 14544: Stereotyped Constraints in UML
Issue 14555: UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual
Issue 14588: are Create messages aynch or synch, or doesn't it matter?
Issue 14928: Property subsets other regular property, non-derived union
Issue 14930: One association end is derived, another is not
Issue 14933: UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language
Issue 14934: Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling
Issue 14935: Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition
Issue 14936: UML: Need more robust value model that would enable capture of values vs time
Issue 14937: UML: Incorporate SysML Requirements Model into UML
Issue 14938: UML: Include text description field with model element
Issue 14939: UML Associate an image/icon with each model element
Issue 14940: UML: Provide unique URL/URI Reference to/from Model Elements
Issue 14941: UML: Include text description field with model element --- additional information added
Issue 14942: UML:Notational option to display inherited features in a subclass
Issue 14943: Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership
Issue 14944: UML: A strong ability to support reviewing packages
Issue 14945: UML: Support for maintaining what-if models in repository without massive duplication
Issue 14946: UML Support for multiple library levels
Issue 14947: UML: A strong ability to support generating Documents
Issue 14948: UML: Diagrams as Model Elements
Issue 14949: UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs
Issue 14950: UML: Better Definition of Compliance
Issue 14951: UML: Large Scale Model Support:Federated/Distibuted Models
Issue 14952: UML: Cross model dependencies
Issue 14953: UML: Improve Sequence Diagram Semantics (3-issues)
Issue 14954: UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments
Issue 14955: UML:Access to standardized ontologies within models
Issue 14956: UML: Better Profile Capabilitiy
Issue 14957: UML: Timing semantics for activity diagram
Issue 14958: UML: Higher-level reusable frameworks
Issue 14959: UML has no way of distinguishing Notes from Comments
Issue 14978: NamedElements whose owners do not subset Namespace
Issue 15050: Parameter
Issue 15123: Sequence diagram and Communication diagrams should support instances as lifelines
Issue 15207: Timing Diagram and interchange
Issue 15236: not sure it is possible to define a constraint without a context
Issue 15237: issue10087 and association-like notation
Issue 15239: Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications
Issue 15240: Owning of interaction fragments is ambiguous when InteractionOperands are present
Issue 15248: Initialization of complex fields
Issue 15290: Ports
Issue 15303: How to specify actual parameters to pass to parameterized submachine StateMachine
Issue 15312: Issue on UML 2.3 - Use of isAbstract for Interfaces
Issue 15315: Aggregation missing from Property string syntax
Issue 15400: Nasty UML 2.x Issue - /qualifiedName is not unambiguous
Issue 15421: UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling
Issue 15440: Issue on UML 2.4 - notation for Component::provided
Issue 15449: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations
Issue 15451: Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex
Issue 15485: UML 2 issue: connectors typed by Association Class
Issue 15763: No Constraint for multiple associations
Issue 15788: UML 2.3 Infra 12 Incomplete conformance for infinity
Issue 15823: Part document structures in Superstructure need to conform to ISO standard Document Template Conventions
Issue 15849: Creation of an expansion node under an activity is allowed by UML and SysML specifications
Issue 15850: Restrictions on decision nodes
Issue 15889: Retationships and composite structures
Issue 15890: New notation for attribute
Issue 15903: XMI representation of stereotype application
Issue 15930: Tags typed by classes/blocks
Issue 15991: Notation of Lifelines
Issue 16116: Package URI Attribute Uses Obsolete RFC 2396
Issue 16117: Profile URI Attribute - Mingled URI Definition and Use in XMI
Issue 16118: Metaclass stereotype notion
Issue 16119: Metaclass stereotype notion (02)
Issue 16249: State::stateInvariant multiplicity too restrictive
Issue 16292: Use cases specifying the same subject cannot be associated: exception
Issue 16307: A deferrable trigger may have a guard
Issue 16342: Ambiguous stereotype notation
Issue 16350: Navigability orthogonal to end ownership or not?
Issue 16357: UML: unification of OCL declarations
Issue 16484: UML Appendix A: After Figure A.4
Issue 16567: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model
Issue 16569: Relation of message arguments to signature parameters ambiguous
Issue 16570: Message arguments for a Signal signature too restrictive
Issue 16571: Message arguments should not be contained in a message
Issue 16572: OccurrenceSpecification should have at least an optional notation
Issue 16658: The included use case is always required for the including use case to execute correctly
Issue 16897: Abstraction::mapping should be of type ValueSpecification or OpaqueExpression
Issue 16999: UML 2.4/2.5 Aliases
Issue 17096: Concerning Transition and its owned elements
Issue 17226: Message Signature in Interactions and Reception.ownedParameter
Issue 17315: Interaction.action should subset ownedMember in lieu of ownedElement
Issue 17390: Migrate UML::Component's ability to own UML::PackageableElements to UML::Class
Issue 17393: Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier
Issue 17464: Link notation for stereotype property value
Issue 17536: Specifying the multiplicity of a part with an attribute
Issue 17564: applying and associating stereotypes and explanation of all aspects of their serialization
Issue 18239: test
Issue 18951: isReplaceAll=true and lowerBound > 1
Issue 18955: Problems with OCL definition of Package::makesVisible
Issue 18969: Relax Association::/endType from [1..*] to [0..*]
Issue 18971: ExtensionEnd upper/lower inconsistent with MultiplicityElement
Issue 18972: Semantic error in Lifeline::interaction_uses_share_lifeline
Issue 18973: Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant
Issue 18982: XMI.xmi is not merged
Issue 19009: In the Use Case section, it is unclear whether a use case requires an actor
Issue 19010: Abstract Syntax diagram for Use Cases
Issue 19011: Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case
Issue 19012: Use cases and use of arrows
Issue 19013: Extension point
Issue 19014: Description of the OCL
Issue 19017: Improving the association direction notation
Issue 19024: Sequence Diagram: Message limitation
Issue 19070: About behavior ports
Issue 19122: About prescribed port implementation
Issue 19133: Cannot set an activity as the source or target of an information flow
Issue 19167: Information flow instantiation
Issue 19179: BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization
Issue 19185: Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2
Issue 19186: Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2
Issue 19187: Problems with normative UML 2.5 Beta 2 Standard profile
Issue 19188: Notation for PrimitiveTypes
Issue 19189: Can PrimitiveTypes be user-defined and where?
Issue 19190: A PrimitiveType can/cannot have owned attributes.
Issue 19191: Clause 21 Primitive Types is misnamed
Issue 19193: Descriptions missing for PseudostateKind literals
Issue 19194: Rg. Reception.ownedParameter
Issue 19199: How to access a token value in a guard?
Issue 19202: Type conformance for classifiers
Issue 19209: Generalization should be limited to relate similar UML-elements
Issue 19253: Missing OpaqueXXX body constraint
Issue 19254: InstanceSpecification validity is not modelable
Issue 19282: Name of Package in Figure 7.3 should be "Core" rather than "Constructs"
Issue 19285: UML 2.5 Figure 10.10 Error
Issue 19288: Multiple Generalization Sets
Issue 19320: UML 2.5 Figure 14.25 Choice Pseudostates
Issue 19322: Rename Specialization/Generalization between abstract classes
Issue 19323: Ambiguous Profile::profileApplication
Issue 19324: UML 2.5 Issue on DI for reply arrows
Issue 19325: UML 2.5 Visibility of a packagedElement
Issue 19329: UML transition-centric state machine arrows (01)
Issue 19330: UML transition-centric state machine arrows (02)
Issue 19334: UML 2.5 issue on examples in 17.4.5
Issue 19335: UML 2.5 Overly strict restriction on message slope in seq diagrams
Issue 19337: Unclear statement regarding Lifeline shape
Issue 19338: Including use case depends on included use case but Include is no subclass of Dependency
Issue 19342: Unnamed elements in a namespace
Issue 19345: Incorrect drawing of non-navigable redefined opposites
Issue 19346: Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity
Issue 19349: NamedElement::allNamespaces is invalida at model root
Issue 19350: TypeElement / TypedElement typo
Issue 19351: Incorrect OrderedSet returns
Issue 19353: Specification should not contain any methodology
Issue 19364: UML 2.6 Issue --- SignalEvent Triggers
Issue 19365: UML 2.5 Mandatory but suppressible compartments
Issue 19406: Incorrect Result in ReduceAction Example
Issue 19409: Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams
Issue 19420: meaning is not clear
Issue 19422: Message should extend Namespace
Issue 19427: Incomplete sentence
Issue 19430: Incorrect sentence
Issue 19438: ExpansionNodes owned by ExpansionRegions?
Issue 19454: UML wording in Superstructure 2.4.1
Issue 19455: BehavioralParameter should be BehavioralFeature
Issue 19468: Semantics of static features
Issue 19472: No specification of which visibility marking corresponds to which VisibilityKind value
Issue 19488: Issue against UML: implementation of OCL constraint containingProfile
Issue 19511: Classifier::ownedTemplateSignature needs to subset Element::ownedElement
Issue 19512: UML 2.5 Beta 2 XMI invalid
Issue 19523: Actor association constraint makes UseCase subclass of Class
Issue 19538: Another UML 2.5 Beta 2 XMI invalidity
Issue 19540: UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight
Issue 19545: Section 15.5.3: a missed word
Issue 19564: Pin multiplicity and token upper bound

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

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

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

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


Issue 6083: More examples (uml2-rtf)

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


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

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


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

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

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

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


Issue 6088: Parameterization of lifelines (uml2-rtf)

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

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

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


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

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

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

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


Issue 6150: Notation for method (uml2-rtf)

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

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

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


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

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

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

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


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

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

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

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


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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


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

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

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

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


Issue 6470: Section 7.11.2 Association (uml2-rtf)

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:
What is the sematics of an association with neither end navigable? Provide an example of when this might be used. (C to D page 85).

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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


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

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


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


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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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


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


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


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


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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 6624: freeing namespace (uml2-rtf)

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


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


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


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


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


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


If not, let's put it there.


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

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

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


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

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

 

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

ownedType

nestedPackage

ownedRule

 

An OCL equivalent would be as follows:

 

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


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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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

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


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

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


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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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


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


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


with the OCL:


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


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


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


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


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


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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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


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


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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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


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


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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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


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

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

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

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


Issue 7338: metaattribute isReadOnly (uml2-rtf)

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


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

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

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

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

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

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

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


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

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


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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 7997: Too much navigability from Generalizations (uml2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 22, 2004: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8012: Section: Classes, Behavior (uml2-rtf)

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8014: Disjointness should be independent of generalization (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Evan K. Wallace, evan.wallace(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8016: Action for retrieving activity instance (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Revision
Severity: Minor
Summary:
Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications. 

Resolution: ReadSelfAction does this for behaviors that have no context object. The next RTF can either modify ReadSelfAction or add a new action to handle the case of a behavior with a context object. This is needed for reflective applications cited in the specification, see the semantics of Activity. Disposition: Deferred
Revised Text:
Actions taken:
December 30, 2004: received issue

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


Issue 8024: End objects of a link In the semantics of AssociationClass (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity. 

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8026: Contextualized attribute values Figures 121 (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:
Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8034: Notation for classifierBehavior (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8077: Properties on Association for end objects (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
January 5, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8278: section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue
February 14, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8335: ReadStructuralFeatureAction (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8464: Section: 16.3.1 (uml2-rtf)

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


Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change
Revised Text:
Actions taken:
March 4, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8473: Activities section (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Revision
Severity: Minor
Summary:
Add presentation option for multiple object flows between two actions, shown as one line. 

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8479: Section: Activities - clarification (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities. 

Resolution: The clarification that is required is on Constraint [3] of Section 12.3.23 ExceptionHandler (in UML 2.2, ptc/08-05-05). Note that, as stated in the issue, the constraint can only be formalized within the Activities clause for structured nodes, because, before merging with BasicActions, only structured nodes are modeled as having output pins.
Revised Text: In Section 12.3.23, replace Constraint [3] with: [3] If the protected node is a StructuredActivityNode with output pins, then the exception handler body must also be a StructuredActivityNode with output pins that correspond in number and types to those of the protected node.
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8480: Section: Activities : Why is exception type needed? (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8489: ExpansionRegion (behavior in the shorthand notation) (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

Resolution: The shorthand notation does not actually require that the behavior have exactly one return parameter. However, it should be clarified that the expansion nodes shown in the shorthand notation should correspond one to one to the input and output pins of the behavior.
Revised Text: In Section 12.3.27 (ExpansionRegion), under Notation, at the end of the paragraph immediately preceding Figure 12.83, add: In the shorthand notation, there must be one input expansion node corresponding to each in or inout parameter of the behavior (which must have at least one such parameter) and one output expansion node corresponding to each out or inout parameter of the behavior.
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8495: Add constraints on ConditionalNode (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.). 

Resolution: Agreed that nodes in the test and body part of the clauses of a conditional node must be owned by the conditional node and that these parts should be disjoint.
Revised Text: In Section 12.3.17 (Clause), under Constraints (Package StructuredActivities) add: [2] The test and body parts must be disjoint. In Section 12.3.18 (ConditionalNode), under Constraints, before the existing constraint, add: Package StructuredActivities [1] The union of the ExecutabledNodes in the test and body parts of all clauses must be the same as the subset of nodes contained in the ConditionalNode (considered as a StructuredActivityNode) that are ExecutableNodes. [2] No ExecutableNode may appear in the test or body part of more than one clause of a conditional node. Package CompleteStructuredActivities
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8501: SequenceNode should have way to set output pins in CompleteStructured (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do. 

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8684: Add a Constraint (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
No consistency condition is put between predecessor clauses, for instance two clauses can be the predecessor of each other. Add a Constraint: The transitive closure of predecessorClause must be a strict partial order. 

Resolution: agreed
Revised Text: In Section 12.3.18 (ConditionalNode) under Constraints (Package StructuredActivities), add the constraint (numbered appropriately): [x] No two clauses within a ConditionalNode maybe predecessor clauses of each other, either directly or indirectly.
Actions taken:
April 5, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8693: Section: 10.3.1 (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

Resolution:
Revised Text:
Actions taken:
April 10, 2005: received issue

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8699: UML2-rtf issue: communication diagram (uml2-rtf)

Click
here for this issue's archive.
Source: Philadelphia Insurance Companies (Mr. James A. Schardt, vze238pq(at)verizon.net)
Nature: Uncategorized Issue
Severity:
Summary:
UML2-rtf issue related to communication diagrams: 

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

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

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


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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8700: Meaning of relationship between iteration clause and Lifeline.selector clau (uml2-rtf)

Click
here for this issue's archive.
Source: Philadelphia Insurance Companies (Mr. James A. Schardt, vze238pq(at)verizon.net)
Nature: Uncategorized Issue
Severity:
Summary:
UML2-rtf issue: Meaning of the relationship between the iteration clause and the Lifeline.selector clause. 

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

Does the current UML2 communications diagram notation support the following: 

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

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

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

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

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

Discussion:
Disposition:	Deferred to UML 2.4 RTF


Issue 8748: Operation calls on behavior ports (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

Resolution:
Revised Text:
Actions taken:
May 1, 2005: received issue

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


Issue 8756: Section: Classes (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections. 

Resolution:
Revised Text:
Actions taken:
May 3, 2005: received issue

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


Issue 8758: Association in UseCase diagram (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Actor and UseCase can't own Properties, this means that associations
> in UseCase diagram are always non-navigable at both ends. 
> Is this correct? 

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

Resolution:
Revised Text:
Actions taken:
May 3, 2005: received issue

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


Issue 8761: Arguments of Message (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
arguments of call actions or arguments of message (for example 
> setName(name) where "name" is variable defined in Interaction), but 
> now arguments are simple ValueSpecification, so can't have 
> refference to "real" argument (variable, member, parameter of behavior etc.) 
> Maybe Argument should be in metamodel as in UML 1.4, or at least 
> ValueSpecification should be subclassed in Interactions package and 
> introduce reference to Element that value it represents? 

Resolution:
Revised Text:
Actions taken:
May 3, 2005: received issue

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


Issue 8764: Section: 14.3.3 (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
May 4, 2005: received issue

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


Issue 8765: Section: 14.3.3 Page: 508+ (uml2-rtf)

Click
here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Enhancement
Severity: Significant
Summary:
Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

Resolution:
Revised Text:
Actions taken:
May 4, 2005: received issue

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


Issue 8779: ConditionalNode inputs used by more than one test (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

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

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


Issue 8786: Arguments of Message (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
3. Arguments of Message 
Variables, members and other "value holders" can be used as arguments of call actions or arguments of message (for example setName(name) where "name" is variable defined in Interaction), but now arguments are simple ValueSpecification, so can't have reference to "real" argument (variable, member, parameter of behavior etc.)
Maybe Argument should be in metamodel as in UML 1.4, or at least ValueSpecification should be subclassed in Interactions package and introduce reference to Element that value it represents?

Resolution: See issue 8761 for disposition
Revised Text:
Actions taken:
May 18, 2005: received issue

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


Issue 8787: Numbering (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Messages in UML 2.0 can't have numbers in the model, but all examples of sequence and communication diagrams are with numbers. How numbers should be mapped into model? How to migrate with old activator, successors, predecessors?


Resolution:
Revised Text:
Actions taken:
May 18, 2005: received issue

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


Issue 8788: Variables (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
What namespace should be owner of variables used in sequence diagram?
If variables are added into Interaction, they conflict, because every execution (method for example, or even loop) can introduce variables with some names, that should be not accessible outside.
Maybe ExecutionSpecification or InteractionFragment should be NameSpaces and declare collection for storing variables?

Resolution:
Revised Text:
Actions taken:
May 18, 2005: received issue

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


Issue 8855: Issue 7368 - make Classifier::useCase navigable (uml2-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
To indicate _which actor_ initiates the interaction a communicates association may optionally be adorned with an _arrow head_ to represent navigability.
(No arrowhead indicates either actor can initiate the interaction.)

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

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

Resolution:
Revised Text:
Actions taken:
June 2, 2005: received issue

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


Issue 8883: UML 2.0 Super/Use Cases/Subject of a Use Case (uml2-rtf)

Click
here for this issue's archive.
Source: MID GmbH (Mr. Detlef Peters, d.peters(at)mid.de)
Nature: Clarification
Severity: Significant
Summary:
Section 16.3.2 allows "classifiers in general to own use cases". Section 16.3.6 however states that the "subject of a use case could be (...) any other element that may have behavior". These elements are called "BehavioredClassifier" by Section 13 and are a specialization of Classifier.
Please clarify the consequences of these statements:
- may all Classifiers be owners of UseCases, but only BehavioredClassifiers be the subject of a UseCase?
- what is the semantics of Non-BehavioredClassifiers, e.g. an Interaction or OpaqueBehavior, owning a UseCase or being a subject of it? A UseCase "represents a declaration of an offered behavior" (16.3.6), so how can Non-BehavioredClassifiers ever offer a behavior?

Resolution:
Revised Text:
Actions taken:
June 28, 2005: received issue

Issue 8897: OutputPin (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
OutputPin should hold output value, but there is no way to store it. Should be introduced similar metaclass like ValuePin for InputPin

Resolution:
Revised Text:
Actions taken:
June 20, 2005: received issue

Issue 8898: Syntax of Transition (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Syntax of Transition is described as:
" <transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

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

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

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


Resolution:
Revised Text:
Actions taken:
June 20, 2005: received issue

Issue 8899: reply messages in interactions (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Similar situation with reply messages in interactions.

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

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


Resolution:
Revised Text:
Actions taken:
June 20, 2005: received issue

Issue 8975: UML2 Super / 14.3.13 Interaction (uml2-rtf)

Click
here for this issue's archive.
Source: MID GmbH (Mr. Detlef Peters, d.peters(at)mid.de)
Nature: Clarification
Severity: Significant
Summary:
Chapter 14.3.13 states on p. 526 that "Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with
Messages between the ConnectableElements of the Classifier." From chapter 9.3.13, it is obvious that only StructuredClassifiers can have such ConnectableElements. Additionally, chapter 13.3.2 states that the context of a Behavior is a BehavioredClassifier. When looking at the Classifier Hierarchy in Appendix F of the Spec, you will find a single Element which is a BehavioredClassifier, but not a StructuredClassifier: the UseCase.
This is where the problems start.
A UseCase is not allowed to have properties at all, but may be the owner of an Interaction. Consequently, with the current version of the Spec, an Interaction owned by a UseCase may never have any Lifeline at all!


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

Resolution:
Revised Text:
Actions taken:
August 25, 2005: received issue

Issue 9008: Section: Classes (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
September 25, 2005: received issue

Issue 9013: Section: Activities (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not? 

Resolution:
Revised Text:
Actions taken:
September 25, 2005: received issue

Issue 9015: Section: Classes (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

Resolution:
Revised Text:
Actions taken:
September 25, 2005: received issue

Issue 9111: Page: 492-493 (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
October 24, 2005: received issue

Issue 9124: Need more flexible notation for activity partitions (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Activity diagrams currently support two notation styles for denoting membership in a partition: horizontal or vertical, and possibly nested "swimlanes" and a parenthesized list of partition names displayed above an activity node. These notation styles are adequate in many cases, but can result in diagrams that are either difficult to layout or don't sufficiently display relationships between nodes that are in the same partition. In addition, control nodes often shouldn't belong to any partition at all, but may need to be displayed in a partition with adjoining nodes for diagram layout purposes. In this case, apparent inclusion in the partition on the diagram should not necessarily imply membership in the partition. 

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

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

Resolution:
Revised Text:
Actions taken:
October 28, 2005: received issue

Issue 9145: Page: 107 (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
November 10, 2005: received issue

Issue 9225: No notation for associating Exceptions with Operations (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In UML2, exceptions are represented as Types associated with an Operation via the multivalued raisedException property. The types have names and possibly structure (e.g. holding details of an error) and may use inheritance. However  there is no notation defined for actually modeling Types associated with Operations as raisedExceptions.


Resolution:
Revised Text:
Actions taken:
December 8, 2005: received issue

Issue 9247: No ReadParameterAction or WriteParameterAction (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
One difference between UML activity and BPEL process is that all
data flows in UML must be explicit through connections between
activity parameter nodes, pins, central buffer nodes, and/or data
store nodes. UML activities can also have structural features and
variables which allow data to be passed between actions without
object flows, corresponding more like BPEL variable references.

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

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

Resolution:
Revised Text:
Actions taken:
January 18, 2006: received issue

Issue 9339: consistent ordering of Association::memberEnd and ownedEnd (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Given that these are both {ordered}, indicating that ordering is important, then it seems only sensible that the ordering should be consistent, i.e. if Property p appears before Property q in memberEnd then that should also be the case for ownedEnd.
There should therefore be a constraint added to this effect.
 
There should probably also be a review of other cases where an ordered Property subsets another ordered property.
Or should there be a more general constraint defined at the meta-level?
 

Resolution:
Revised Text:
Actions taken:
January 31, 2006: received issue

Issue 9369: Section: 7.3.9 (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:
I propose an optional enhancement of the comment symbol: It is possible to draw a small circle at the end of the anchor line. That way it is easier to read a diagram if the anchor line crosses other dependency lines. The small circle is already used in several diagrams. It is part of the famous Visio stencil of Pavel Hruby.

Resolution:
Revised Text:
Actions taken:
February 21, 2006: received iissue

Issue 9370: Section: Sequence diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Significant
Summary:
A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

Resolution:
Revised Text:
Actions taken:
February 21, 2006: received issue

Issue 9371: All associations ends in the UML2 metamodel itself should be navigable (uml2-rtf)

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

Resolution:
Revised Text:
Actions taken:
February 23, 2006: received issue

Issue 9400: Notation for ordering action input and output pins (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter. 

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

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

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

Resolution:
Revised Text:
Actions taken:
February 28, 2006: received issue

Issue 9401: ControlNodes in ActivityPartitions (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name. 

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

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

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

Resolution:
Revised Text:
Actions taken:
February 28, 2006: received issue

Issue 9402: Reception has no notation for its signal (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
There doesn't appear to be any notation of indicating the signal of a Reception. Reception may also be missing a constaint similar to SendSignalAction where the parameters of the BehavioralFeature have to match the ownedAttributes of the Signal in number, order, and type.

Resolution:
Revised Text:
Actions taken:
February 28, 2006: received issue

Issue 9406: UML2: No notation for indicating Operation::raisedException (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Section 7.3.36 specifies the notation for Operation, but there is no notation for denoting raisedExceptions.  Section 12.3.41 introduces Parameter::isException and suggests exception parameters are indicated out parameters with {exception} after the parameter type to indicate Parameter::isException=true. 

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

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

Resolution:
Revised Text:
Actions taken:
March 1, 2006: received issue

Issue 9445: Link notation for instance diagrams does not cope with multiple classifiers (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 7.54 of ptc/06-01-02 shows an Instance Diagram notation for a
Link.
With the accompanying text:
"An instance specification whose classifier is an association represents
a link and is shown using the same notation as for
an association, but the solid path or paths connect instance
specifications rather than classifiers. It is not necessary to
show an underlined name where it is clear from its connection to
instance specifications that it represents a link and not
an association. End names can adorn the ends. Navigation arrows can be
shown, but if shown, they must agree with the
navigation of the association ends."


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


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


Resolution:
Revised Text:
Actions taken:
March 15, 2006: received issue

Issue 9599: New issue on notation for multiple stereotypes (uml2-rtf)

Click
here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, trutt(at)us.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:
Description of Problem


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


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


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


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

Resolution:
Revised Text:
Actions taken:
April 24, 2006: received issue

Issue 9701: Unnecessary restriction on aggregations being binary (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
There seems to be no reason why n-ary Associations are required to have aggregation=none: there should be a restriction that this is allowed for at most one End but it could reasonably be allowed

Resolution:
Revised Text:
Actions taken:
May 4, 2006: received issue

Issue 9702: No way of specifying element documentation (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
There is no equivalent in UML 2.x of the 'documentation' tag at UML 1.x: a standard way of distinguishing the description of an element.
Comment is generic and has no property to distinguish the 'inherent' description of an element from annotations on specific diagrams, and there is no standard stereotype which could be applied (though use of a stereotype is arguably heavyweight for what is a fairly pervasive requirement).
 

Resolution:
Revised Text:
Actions taken:
May 4, 2006: received issue

Issue 9703: Unclear usage of LiteralExpression::type (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
 LiteralExpression inherits a type property but its use, semantics and notation are not documented. There should at least be appropriate constraints e.g. that LiteralString.type is a subtype of PrimitiveTypes::String.
 

Resolution:
Revised Text:
Actions taken:
May 4, 2006: received issue

Issue 9705: ValueSpecification::isComputable() (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
ValueSpecification::isComputable() introduces conformance requirements not captured in compliance points.
Section 7.3.54, Additional Operations states : "A conforming implementation is expected to deliver true for this operation for all value specifications that it can compute, and to compute all of those for which the operation is true. A conforming implementation is expected to be able to compute the value of all literals."
 

Resolution:
Revised Text:
Actions taken:
May 4, 2006: received issue

Issue 9751: UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics.
The UML superstructure doc 05-07-04, chapter 7.3.10 states,
that Constraint has context and constrainedElement associations(properties).


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


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


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


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


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



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



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



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

Resolution:
Revised Text:
Actions taken:
May 18, 2006: received issue

Discussion:


Issue 9754: Section: 7.3.33 (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:
I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement

Resolution:
Revised Text:
Actions taken:
May 23, 2006: received issue

Issue 9805: Default value types (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
The type of a default value should conform to the type of the property/parameter that owns it. Constraints to that effect should be added to the UML specification. 


Resolution:
Revised Text:
Actions taken:
June 6, 2006: received issue

Issue 9834: Relationships (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Why Transition, ActivityEdge, Message, Connector are not Relationships?
At least Transition and ActivityEdge should be DirectedRelationships in my opinion.
 
If this is done intentionally, please explain, otherwise please register an issue.

Resolution:
Revised Text:
Actions taken:
June 20, 2006: received issue

Issue 9840: Section: 15.3.12, p 588, 589 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There are 3 kinds (TransitionKind) of transitions: internal, external and local. Are there firing priorities between these? For example, consider the case of an internal transition within a state and an external transition with same state as its source state, triggered by the same event, with no guard conditions. If that event occurs, which transition(s) will fire? The standard states, "An internal transition in a state conflicts only with transitions that cause an exit from that state," but neither the firing priorities nor the transition selection algorithm define how such a conflict should be resolved. 

Resolution:
Revised Text:
Actions taken:
June 26, 2006: received issue

Issue 9842: Guidance for Representing Enumeration Values (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Guidance should be given as to how to use the properties of
EnumerationLiteral to represent the typical scenario of an
EnumerationLiteral having a distinct value and meaning e.g. the color
Blue is represented as the code B or the number 5. In this case I would
expect the name of the EnumerationLiteral to be "Blue" with an
associated LiteralString (via inherited property
InstanceSpecification::specification) of "B" or LiteralInteger of 5. The
notation for this could be that for default values e.g. Blue = "B" in
the 'attribute' compartment. Or alternatively the InstanceSpecification
syntax could be used as per Figure 7.52.

Resolution:
Revised Text:
Actions taken:
June 27, 2006: received issue

Issue 9886: OCL Syntax in expressions (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
When OCL is used in body of OpaqueExpressions it's unclear what syntax should be used - in particular whether keywords like "context:", "inv:", "pre:" should be used or not. Section 7.3.35 should, for OCL, reference the correct concrete syntax element in the OCL spec.             Additional material for this issue:
 
At the moment in 7.3.35 there is just a 'style guideline' for how OCL constraints/expressions should be expressed using an OpaqueExpression
For interoperability there should be a stronger statement that OCL constraints *must* have language = "OCL".
Also it should be made clearer that such OpaqueExpressions should have type=Boolean

Resolution:
Revised Text:
Actions taken:
July 6, 2006: received issue

Issue 9887: Optional values and evaluation of defaults (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
7.3.44 says that the defaultValue is "A ValueSpecification that is evaluated to give a default value for the Property when an object of the owning Classifier is instantiated."
This makes it a bit pointless to have such as property as optional since it will always be set to its default value (though in theory the property could be explicitly unset - in which case it will not use the default value either.
There is a need for dynamic evaluation of an expression associated with a Property if no value has been explicitly set.
 
Proposed resolution:
 - if lower = 1 then defaultValue is assigned to the property when object is instantiated (and when the class is attached to an object using reclassify)
 - if lower = 0 then no assignment is made but the defaultValue (if present) is evaluated each time the property value is read: in effect it is acting as a derived property until a value is explicitly assigned.
 
This behavior must also be included in the description of ReadStructurualFeatureAction (11.3.37) which does not mention default values at all.

Resolution:
Revised Text:
Actions taken:
July 6, 2006: received issue

Issue 9923: Section: 13 & 14 (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Significant
Summary:
Some of the concepts defined in the Interaction chapter (n 14), as for example BehaviorExecutionSpecification, are more general than Interaction and shoul dbe part of the chpater 13 which concern is behavior in general. I suggest to review the chapter 14 in order to extract from this section all the concept that are generic w.r.t. behavior and to put them in the chapter 13.

Resolution:
Revised Text:
Actions taken:
July 18, 2006: received issue

Issue 9962: Subclasses of InstanceSpecification (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Now, when link is not Link and is not Relationship, tool 
>> developers must use 
>> a lot of hacks for handling this "special kind of instance" 
>> as path, to 
>> create special algorithms for "relatedElements" calculation,  
>> to prevent 
>> type changes to regular classifier and for many other situations.
>> Why Link metaclass was removed? Why all subclasses of 
>> Instance were removed? 

>I don't know. I personally would like to see an explicit Link class in
>the Instances metamodel - see the MOF Core specification (abstract
>semantics chapter - which is purely descriptive and does not add these
>Instance extensions to MOF or UML) for what I have in mind. I would
>support adding this all into UML since it would be a non-disruptive
>(forward compatible) extension.

>> Node instance and Component instance "different handling" and 
>> notation 
>> creates a lot problems also, because it is not possible to 
>> recognize them in 
>> the model (classifier could be unspecified).

Resolution:
Revised Text:
Actions taken:
July 25, 2006: received issue

Issue 9999: Association::isDerived should be derived (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the L3 metamodel there are only 5 Associations with isDerived=true.
These are: 
    A_context_action
    A_deployedElement_deploymentTarget
    A_state_redefinitionContext
    A_extension_metaclass
    A_containedEdge_inGroup
 
However there are clearly many more Associations which are in practice derived - for example anything with an end which is a derivedUnion. 
It seems that an Association should automatically be derived if one or both of its ends are derived. 
 
Proposed resolution:
Make Association::isDerived itself a derived property (so it becomes Association::/isDerived)
The OCL for the derivation would be:
  context Association isDerived = self.memberEnd->exists(isDerived)

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue

Issue 10345: Section: 7 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract) 

Resolution:
Revised Text:
Actions taken:
September 12, 2006: received issue

Discussion:


Issue 10411: Section: Chapter: 7.3.2.4 View (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
Although it is mentioned in the text it isn't 100% clear that a view has only one conforming viewpoint. Define a constraint for a view that only one conform relationship to a viewpoint is allowed. 

Resolution:
Revised Text:
Actions taken:
October 13, 2006: received issue

Issue 10413: Constraint.context vs Constraint.constrainedElement (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
The situation is now more-or-less clear.
We will use a variant specified OCL spec for evaluating OCL constraints.


However in my humble opinion, UML spec could also benefit if the descriptions
of context and constrainedElement were clarrified a bit on how one should use them.
As Karl correctly notes, when 2 properties can be used to specify the same thing,
this introduces ambiguities in the model.


Even if "nothing prevents the context and constrainedElement from beeing the same object",
on the other hand nothing prevents these 2 from beeing different objects.
Hence if author produces some UML model with constraints where constrainedElement!=context,
the readers of this model cannot interpret it unambiguously.
And I can imagine many cases, where constrainedElement will not be equal to context.
For example if constraints are placed in a separate package from their constrained elements
(perhaps constrained elements are in a separate, read-only library and constraints can not
be added there; or for other packaging reasons). In this case context of these constraints
will be their owner package (per UML2.1 rules) and constrainedElement will be completely
unrelated to it.



PS
And this applies not only in the narrow case of constraints, specified in OCL.
Almost all other languages need contextual information.
For the sake of argument, lets say the constraint is specified in English language.
Well, it so happens, that English language also needs some context to interpret sentences.
The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL.


E.g. Imagine the constraint with specification=OpaqueExpression{language=English; body="these must be yellow"}
placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property.
Now there is an ambiguity.
If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow.
If the constraint.constrainedElement is used, then apples in the box must be yellow.





> Karl Frank wrote:
> 
> Agreed.  But imo it is a defect for the same thing to be specified in two equivalent ways.  EVen if the context is by definition the constrained element, in the case of a
> constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent.
> 
> But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec.
> 
> - Karl
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: Branislav Selic [mailto:bselic@ca.ibm.com]
> Sent: Thursday, May 18, 2006 5:21 PM
> To: Karl Frank
> Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org
> Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement
> 
> I was indeed raising a separate OCL issue (a major one, I believe), but I was also saying that there is no real issue with the UML 2 spec. In fact, if you think about it,
> there is nothing to prevent constrainedElement and context from being the same object. There is no real contradiction here.
> 
> Bran

Resolution:
Revised Text:
Actions taken:
May 22, 2006: received issue

Discussion:


Issue 10474: Connector contract is inflexible (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Connector contract is inflexible and cannot bind connector ends to parts in the contract behavior. A Connector can have a contract which is a Behavior which specifies the valid interaction pattern across the connector. The Behavior could be an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. However, the parts in the Behavior (lifeliines. activity partitions, target input pins, variables, etc.) cannot be bound to the ports at the end of the connector. So it is difficult to understand what part participating ports play in the contract beahvior. Another problem is that the may be more than one interaction between the parts at the connector ends representing different conversations between the same parties over the same connector. This would require more than one behavior for the contract in order to describe each interaction. 

Instead, the contract for a connector should be a CollaborationUse. The connectorEnds would then be bound to the roles they play in that contract. The Collaboration of the CollaborationUse can contain multiple ownedBehaviors which represent the interaction protocols between the roles. Parts playing these roles (as indicated by a CollaborationUse) would have to interact in a manner consistent with the corresponding Collaboration ownedBehavior. (These can match by name, but we may want to consider an extension that allowed bindings between operations of the parts and behavior of the collaboration to allow more flexible contracts). 

The interactions between connected consumers and providers instances are initiated by one party or the other (may not be the same for all such interactions). The provider will typically define the protocol consumers must follow in order to use the provided capabilities. One way to model these protocols is to set the type of the Port providing the capability to the Collaboration defining the protocol. Then the type of the CollaborationUse for any Connector connected to that port would be the type of the Port.

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

Issue 10597: Behavioral port (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier
Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02)
Section: 9.3.11 Port
 
Description:
 
Currently, the semantics of ports may be summarized as follows:
 
1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port."
  
2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost."
  
Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port.
 
Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect.
 
Suggested resolution:
 
1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports.
 
2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior.
 
3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 
 
4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method.

Resolution:
Revised Text:
Actions taken:
January 18, 2007: received issue

Issue 10600: UML 2 Superstructure: Abstractions should be acyclic (uml2-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
The UML Abstractions concept should include a constraint that a graph involving Abstraction relationships should be acyclic; i.e. an <element type> cannot be both a transitively higher level of abstraction and transitively lower level of abstraction of the same <element type>. 

not self.getHigherLevelAbstractions()->includes(self)     


Resolution:
Revised Text:
Actions taken:
January 19, 2007: received issue

Issue 10635: Presentation option for return parameter for operation type are incomplete (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Section 7.3.36 Operation, under Presentation Options explains notation options for expressing the return value of an Operation. The example is: 

toString(): String 

means the same thing as 

toString(return: String) 

This should also be the same as: 

toString(return result: String) 

That is, the default name of the return parameter is "result". This is to be consistent with OCL's reference to the result of an operation in a post condition, and to allow a behavior to be able to refer to a return parameter by name. 

Resolution:
Revised Text:
Actions taken:
January 29, 2007: received issue

Discussion:


Issue 10656: clarification on Behavior::specification / meaning of InterfaceRealization (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing 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 section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the 
specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form 
in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation 
elements, although it is not necessarily computable." 

If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes.  However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times: 
1. An Operation in a provided Interface 
2. The same Operation copied into a realizing Class used as the type of a Port 
3. An Operation of a Component containing the Port 
4. The method Behavior whose specification is the Operation owned by the Class 
5. If the Behavior is an Activity, the ActivityParameterNodes 
6. The InputPins and OutputPins of a CallOperationAction that invokes the operation 

In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations. 

There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain. 

Consider changing the description of property Behavior::specification in section 13.3.2 from: 
Designates a behavioral feature that the behavior implements. The behavioral 
feature must be owned by the classifier that owns the behavior or be inherited 
by it. The parameters of the behavioral feature and the implementing behavior 
must match. If a behavior does not have a specification, it is directly associated 
with a classifier (i.e., it is the behavior of the classifier as a whole). 

to: 

Designates a behavioral feature that the behavior implements. The behavioral 
feature must be owned by the classifier that owns the behavior or be realized or inherited 
by it. The parameters of the behavioral feature and the implementing behavior 
must match. If a behavior does not have a specification, it is directly associated 
with a classifier (i.e., it is the behavior of the classifier as a whole). 

The possible problems with this change are: 
1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here. 
2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem. 

Some advantages are: 
1. It matches the common understanding or realization 
2. It reduces redundancy in the model 
3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to. 


Resolution:
Revised Text:
Actions taken:
February 9, 2007: received issue

Discussion:


Issue 10781: Section: 10.3.4 of formal/2007-02-03 (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The direction of deployment dependency is wrong in all figures that use this kind of dependency, e.g. figure 10.9 on page 216 (direction is opposite to the one stated in metamodel). The deployment dependency in these figures is being drawn from artifact (client) to target (suplier), though figure 10.4 on page 210 defines Deployment as being dependency with DeploymentTarget as client and DeployedArtifact as supplier, so direction should be opposite - from target to artifact. As an alternative, the metamodel could be adjusted.

Resolution:
Revised Text:
Actions taken:
February 19, 2007: received issue

Issue 10821: ValueSpecification that refers to some Element shall be defined (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
ValueSpecification that refers to some Element shall be defined. It could be named ElementValue. We need that for tagged values that references to model elements. It could be used for Argument value also

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 10822: Ability to define "context specific" default values for Part (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Ability to define "context specific" default values for Part. It is widely used for system modeling (SysML), but it is not possible to map that to UML

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 10823: names and namespaces (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Namespace defines derived "member" collection for NamedElements identifiable by name.
However not all Namespaces subset this collection, so NamedElements are added just to ownedElements.
 
Example: Activity and ActivityNodes.  Actions and ObjectNodes could have identical names because they are not added into "ownedMember" collection and are not identified by name.
Is this correct or bug in metamodel? I believe we could find more such Namespaces.

Resolution:
Revised Text:
Actions taken:
March 14, 2007: received issue

Issue 10824: Units and types are still problematic (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Units and types are still problematic. UML notation is not able to show tags of some referenced elements - in case of attributes, they should show tags of type, in case of slots, they should show tags of type of defining feature (secondary reference).



Resolution:
Revised Text:
Actions taken:
March 9, 2007: received issue
March 15, 2007: re-assigned from SYsML FTF to the UML 2 RTF

Issue 10957: UML 2.1.1 - notation for parameter sets (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
I note that the notation for parameters sets shown is for invocations of activities, not for activity definitions. Is it intended that there is a similar notation for grouping activity parameter nodes that represent parameter sets?

Resolution:
Revised Text:
Actions taken:
March 27, 2007: received issue

Issue 10999: 9.3.9 Invocation Action (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
In the semantics, the spec needs to state what happens if there are multiple instances corresponding to the port (which might happen if the multiplicity upper bound of the port is greater than 1)

Resolution:
Revised Text:
Actions taken:
May 10, 2007: received issue

Issue 11092: Section: 14.4 Timing Diagram: Continuous time axis (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Significant
Summary:
Table 14.6., State or condition timeline: It is unclear how the time information is stored in the interaction model. Especially if it is a continuous timeline. Please clarify the repository model for timing diagrams

Resolution:
Revised Text:
Actions taken:
June 8, 2007: received issue

Issue 11272: Section: Annex A: Diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
There are less diagram kinds defined than UML diagrams. In particular I miss a diagram kind for object, deployment and composite structure diagrams

Resolution:
Revised Text:
Actions taken:
August 10, 2007: received issue

Issue 11273: Section: Annex A: Diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
The abbreviation sd for interaction diagrams should be renamed to id. sd stands for sequence diagram, but there three more interaction diagrams. It is confusing to have a diagram kind sd for a timing diagram.

Resolution:
Revised Text:
Actions taken:
August 10, 2007: received issue

Issue 11287: Section: 7.3.3 (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
There is actually two closely related issues I would like to report. One is an (as I understand it) error related to figure 7.20 and the other is a humble request to enhance the documentation by more explicitly clarifying the semantics of association ends that are owned by an end class. Starting with the (possible) error. According to the specification (page 39) "An end property of an association that is owned by an end class or [...] is navigable from the opposite ends; [...]" Somewhat further down in the text there is a statement saying (page 43) "Aggregation type, navigability, and end ownership are orthogonal concepts [...]" Although this may be true in terms of notation, it is clear from the first citation (and common sense) that navigability and end ownership cannot be conceptually orthogonal. Moving on to figure 7.20, the first relation demonstrates this supposed orthogonality by showing a relation where the end connected to B is owned by A, but not navigable from A. I understand that this part might have been written with notation in mind; to demonstrate the orthogonality of the notational elements. It might, however, be considered bad practice to show notational examples that are inconsistent with the rest of the specification. The second "issue" is related to the concept of a property that is an association end owned by an end class. It took me quite some time and a lot of re-reading to understand that the "end class" was a of a different type than the type of the property. The only real hint about this was the last statement on a paragraph in on page 42 (in the notation section) stating that "This property is owned by the classifier at the other end." Since the whole concept of ownership seems a little vague, it might be a good idea to include a paragraph detailing this fact in the description of the semantics of associations. I hope this might be of some use.

Resolution:
Revised Text:
Actions taken:
August 21, 2007: received issue

Discussion:


Issue 11307: Section: 16.3.5 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The Description section states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly." This is often understood as stating that the behavior of an included use case has to be executed during every execution of the behavior of the including use case. Example: The following informal use case fragment contains a conditional call of an included use case: Step x: If the user choses to print the reports, <<include>> the use case "Print reports". With the understanding given above, this use case fragment would be invalid (at least if the included use case is not included elsewhere in the including use case). In a similar vein, the Semantics section states: "All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed." Besides the obvious error (the sentence should say: "... is executed at a single location in the including use case ..."), this is sometimes understood as stating that the behavior of the included use case must be executed exactly once during the execution of the including use case. Another (equally wrong) interpretation would be that the included use case must be included exactly once in the use case specification (implying, for example, that there must not be two lines in the same textual use case specification containing an <<include>> directive for a certain use case). Both sections should be clarified, clearly stating that: - The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram). Analogy: A routine that contains multiple calls to a subroutine in its source code. - The including use case is responsible for calling the included use case. It may choose to call it once, repeatedly, or not at all. Analogy: A routine with conditional execution paths or iterative behavior, performing subroutine calls conditionally or iteratively. Proposal for changing the sentence in the Description section: "Note that the included use case is not optional, and is always required for the including use case to be fully specified. The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram)." Proposal for a change and an addition in the Semantics section: "All of the behavior of the included use case is executed in the including use case before execution of the including use case is resumed. Depending on behavior of the including use case, the included use case may be called once, multiple times or not at all." I would be very pleased to receive a first, quick reply by mail.

Resolution:
Revised Text:
Actions taken:
August 27, 2007: received issue

Issue 11323: UML2 Property collaborationRole should be removed (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
The collaborationRole property of Collaboration does not appear to be needed and could be removed. A Collaboration's ownedAttributes subsets inherited derived union role, and therefore represent the roles in a Collaboration. Since Property is extended to be a ConnectableElement, collaborationRole is redundant with ownedAttributes. In addition, the description does not seem to make sense. A collaborationRole can't reference connectable elements (possibly contained in another classifier) because the roles of a Collaboration must be parts or ownedAttributes of that Collaboration. The roleBindings of a CollaborationUse bind the roles of its Collaboration type to parts of some other classifier. 

However, there could be another interpretation of collaborationRole. If Collaborations are used to represent patterns, then a Collaboration's ownedAttributes may represent the common part of the pattern while the collaborationRoles represent the variable part. Instantiating the pattern with a CollaborationUse may then mean that the Classifier owning the CollaborationUse would need to directly contain the common parts (copies of them from the collaboration), and require roleBindings to the variable parts. In this case, collaborationRole parts would require bindings (and therefore subclass role) while ownedAttributes don't (and wouldn't subclass role)? 

In any case, the purpose of property collaborationRole is unclear and should be amplified in the specification to distinguish it from ownedAttributes and how it should be used.

Resolution:
Revised Text:
Actions taken:
August 30, 2007: received issue

Issue 11342: Section: 7.3.37 Package (from Kernel) (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The type of association 'packageMerge' is shown as 'Package'. In contradiction to this is the describing text of this association and the Figure 7.14 on p. 34 showing that the association 'packageMerge' is from 'Package' to 'PackageMerge'. Correct in chapter '7.3.37 Package (from Kernel)' the type of association 'packageMerge' from 'Package' to 'PackageMerge'. 

Resolution:
Revised Text:
Actions taken:
September 12, 2007: received issue

Discussion:


Issue 11410: simpleTime package problems (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
We are experiencing problems with elements of simpleTime Package. 
TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package.
If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds).
 

 

 

Resolution:
Revised Text:
Actions taken:
September 14, 2007: received issue

Issue 11807: Figure 7.48 and the accompanying discussion under 7.3.21 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Figure 7.48 and the accompanying discussion under 7.3.21 GeneralizationSet>Examples on pp 78-79 uses the example of a generalization set consisting of a single class to explain the proper use of the isCovering and isDisjoint attributes. I believe this example is infelicitous in the context of this exposition because generalization sets consisting of a single class present a special case, and this detracts from the exposition. In what way are they a special case? IF (a generalization set consists of a single class AND it is {incomplete}) THEN it can *only* be {disjoint}. This is because if the complement of an {incomplete} generalization set is non-empty, and consists of all instances that are NOT members of the solitary class in the generalization set. In other words, for a generalization set consisting of a single class, the combination {incomplete, overlapping} is self-contradictory. IF (a generalization set consists of a single class AND it is {complete}) THEN it can *only* be {overlapping}. This is because the complement of a {complete} generalization set is the null set, and the null set is a member of every set. In other words, the combination {complete, disjoint} is self-contradictory. I would recommend pointing out that generalization sets consisting of a single class represent a special case, and I would treat them separately (?footnote). For purposes of the exposition, I would modify Figure 7.48 to include at least two classes (perhaps Employee, Manager) instead of just Employee in the right-hand generalization set. 

Resolution:
Revised Text:
Actions taken:
December 9, 2007: received issue

Issue 11815: Section: 14.4 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Our company uses UML 2.1 for model driven architecture. We are now at the point, where we need interaction overview diagrams (like the example on figure 14.28 on page 530). So, we searched the UML elements that are used in this diagram: ControlFlow, InteractionUse, InitialNode, ActivityFinalNode, ... Then, we tried to combine them via the metamodel to have a little class diagram which shows us the connections of the elements (for example ControlFlow has source and target to ActivityNode). But there is one problem: We can't find a way to add the InteractionUse in this diagram. It seems, that a ControlFlow isn't able to have an InteractionUse on one of its ends. Can you tell us, how the InteractionUse can be used correctly (so we can use it for XMI-export)? Thank you in advance. We look forward to hearing from you.

Resolution:
Revised Text:
Actions taken:
December 13, 2007: received issue

Issue 11827: UML2 Issue: notation for Literals does not allow for name (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Literals e.g. LiteralString are NamedElements but the notation does not allow for specifying the name.


Resolution:
Revised Text:
Actions taken:
December 17, 2007: received issue

Issue 12162: pull semantics are only supported on Action inputs, not outputs (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
pull semantics are only supported on Action inputs, not outputs. There is currently no ActionOutput having a toAction: Action Property allowing action output pins to refer and write to parameters, variables or structural features. Either UML2 should include ActionOutputPin, or remove ActionInputPin and allow a Pin to have an optional action: Action [0..1].

Resolution:
Revised Text:
Actions taken:
January 7, 2008: received issue

Issue 12166: should be able to show gates on communication diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In the 2.1.1 specification (070205): 

Although the superstructure specification does not mention it, I believe that we should be able to show gates on communication diagrams. 
Gates are not connectable elements so we cannot attach connectors to them.  How then would we show message pathways (connectors) to the represented lifeline on the communication diagram? Gates don't "represent" connectable elements as lifelines do. 

I would like to request clarification on this point.

Resolution:
Revised Text:
Actions taken:
January 8, 2008: received issue

Issue 12197: UML 2: Need an explicit listing of all semantic variation points (uml2-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
A readily accessible list of all semantic variation points in the UML superstructure. It should probably be a separate appendix for easy reference and maintenance.

Resolution:
Revised Text:
Actions taken:
January 24, 2008: received issue

Issue 12203: UML 2 has lost cability to represent operations by collaborations (uml2-rtf)

Click
here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Revision
Severity: Minor
Summary:
It appears that UML 2 has lost the ability to represent operations by collaborations. (There the collaboration related the parameters of the operation as roles.) Now a collaboration use can only be owned by a classifier. A behavior could still be explained by an operation, but not an operation. If this is desired, the references to operations owning collaboration uses need to be purged. Otherwise it has to be fixed that operations can own collaboration uses.

Resolution:
Revised Text:
Actions taken:
January 31, 2008: received issue

Issue 12267: Section: 7.3.41 (uml2-rtf)

Click
here for this issue's archive.
Source: OFFIS e.V. (Mr. Christian Mrugalla, nobody)
Nature: Revision
Severity: Minor
Summary:
The last sentence of the Semantics definition for Parameter is: "If the behavioral feature is an operation, then the type and multiplicity of this parameter is the same as the type and multiplicity of the operation itself.". The multiplicity of an operation is not defined in the standard: Operation does neither inherit from MultiplicityElement, nor has it an element called 'multiplicity'. Proposed resolution: Replace this sentence by: "If the behavioral feature is an operation, then the type of this parameter is the same as the type of the operation itself

Resolution:
Revised Text:
Actions taken:
March 10, 2008: received issue

Discussion:


Issue 12272: Section 7.3.44 (uml2-rtf)

Click
here for this issue's archive.
Source: OFFIS e.V. (Mr. Christian Mrugalla, nobody)
Nature: Enhancement
Severity: Significant
Summary:
The metaclasses 'Attribute' and 'AssociationEnd' (defined in UML 1.x) are merged in the metaclass 'Property' in UML 2.x. But the terms 'attribute' and 'association end' are still used in the standard, based one the two possible Property-containments (Property owned by a 'Class' respectively by an 'Association'). In addition, a semantic for the different values of the meta-property 'aggregation' is only defined for a 'Property' of style 'association end'. I propose to re-introduce the metaclasses 'Attribute' and 'AssociationEnd' as specializations of 'Property', making 'Property' an abstract class (the meta-property 'aggregation' should be then moved to AssociationEnd).

Resolution:
Revised Text:
Actions taken:
March 12, 2008: received issue

Issue 12274: new constraint ? (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
Should there be a constraint ensuring that named elements with private visibility cannot be accessed outside their owning namespace? For example, the type of a property should not be a private member of a namespace outside of its namespace hierarchy…


Resolution:
Revised Text:
Actions taken:
March 11, 2008: received issue

Issue 12279: Section: 18.3.3 (uml2-rtf)

Click
here for this issue's archive.
Source: OFFIS e.V. (Mr. Christian Mrugalla, nobody)
Nature: Clarification
Severity: Critical
Summary:
Section 18.3.3 states, that "An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier". Whereas in section 7.3.3 (Association) on page 43, it is stated that: "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts [...]" The mentioned description in ExtensionEnd seems to contradict the definition of an Association. For the UML Profile Extension Mechanism two issues are essential to be clarified: 1) Is it possible, that an ExtensionEnd (which is owned by the Extension instead of the extended Class) is navigable? 2) Is it possible in a UML-Profile to define an Association which relates a Stereotype with a metaclass and which is navigable on *both* association ends (if the association end which refers to the stereotype is owned by the association itself instead of by the extended class)? [unidirectional Associations navigable from a stereotype to the extended metaclass seem to be allowed, as exemplified in the SysML 1.0 Standard at page 164] 

Resolution:
Revised Text:
Actions taken:
March 14, 2008: received issue

Issue 12285: UML Super 2.1.2: section 18.3.2 (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
In the semantics section the spec says



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

 

I have two issues with this. This first is that in all example that follows – the extension role names don’t have a dollar in them and so are inconsistent with the spec.

 

Secondly, I think this should say that these are the default names if the modeller doesn’t provide any. In fact later on in the Presentation Options section of 18.3.8, the spec says:

 

“If the extension end is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element.”

Resolution:
Revised Text:
Actions taken:
March 19, 2008: received issue

Discussion:


Issue 12354: Section: 15.3.7 Constraint [2] (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Constraint [2] says: A protocol transition never has associated actions. My problem is that this constraint makes it impossible to specify a consistent pair of a server protocol state machine (PSM) and a client PSM. The server PSM has call events as triggers. It also has internal events causing autonomous state transitions. However, the latter transitions must be notified to the client PSM. This can only be done by actions in which signal events are generated to the client FSM. Such signals are the triggers in the client FSM; and in fact the same problem happens here. Since the call events to the server PSM are caused by internal events at the client PSM, that force call events to the server PSM in the actions. I hope this issue can be solved or at least clarified. Thanks.

Resolution:
Revised Text:
Actions taken:
March 23, 2008: received issue

Discussion:


Issue 12355: UML 2.1.2 Super: Execution Specification (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
The description for Execution Specification says:

“An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The

duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start

ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.”

 

 

This sounds right to me. However, the association ends ‘start’ and ‘finish’ are to the more general OccurrenceSpecification, thus:

“Associations

• start : OccurrenceSpecification[1]

References the OccurrenceSpecification that designates the start of the Action or Behavior.

• finish: OccurrenceSpecification[1]

References the OccurrenceSpecification that designates the finish of the Action or Behavior.”

 

The semantics also refer to OccurrenceSpecification.

“Semantics

The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences

between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a

receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).”

 

The spec should make the description, association and semantics sections consistent.

Resolution:
Revised Text:
Actions taken:
March 25, 2008: received issue

Issue 12434: Section: Activities (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Activity regions and their contents should be redefinable

Resolution:
Revised Text:
Actions taken:
May 9, 2008: received issue

Issue 12511: Callout notation for many clients/suppliers (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
It is allowed that for example a trace relationship has more than one client or supplier. It is unclear how the callout notation looks like for such a relationship.

Resolution:
Revised Text:
Actions taken:
May 27, 2008: received issue
January 12, 2010: moved to UML 2 RTF

Discussion:
Discussion:
This is a UML2 issue, since SysML does not modify Trace in the least. UML has
no convention for callouts on n-ary relations. Defer to UML2 RTF.
Disposition: Deferred


Issue 12544: role bindings of a CollaborationUse (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Enhancement
Severity: Significant
Summary:
Using a simple Dependency to define the role bindings of a CollaborationUse seems too "light". I suggest to change for a Realization relationship which has a stronger - and i think more convenient - semantic.

Resolution:
Revised Text:
Actions taken:
June 23, 2008: received issue

Issue 12566: 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Problem 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) is having relationship redefinedBehavior, that should be derived

Resolution:
Revised Text:
Actions taken:
July 10, 2008: received issue

Issue 12568: Section: 14.3.24, 14.3.20 (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Problem 5 5.1 Interactions diagrams shows messages that are type of MessageSort (from Interactions/BasicInteractions, level L1). There is no way to express that a message is an exception. Only signals and calls are expressed. Exception is none of them ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed

Resolution:
Revised Text:
Actions taken:
July 10, 2008: received issue

Issue 12570: UML2 issue regarding Redefinition (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
For practical reasons, we would like to consider  certain properties of redefinable elements to be inheritable (or possibly derived from the redefined element). 

For example, if one were to redefine a property, then if the type of a redefining property were not explicitly set, it could inherit (or derive) the type from the redefined property.    This would save on space in the serialized model and also help keep the model in a consistent state at all times, if for example the type of the redefined property were to change.   

Currently, there are constraints mentioning that the Type of the redefining property must be 'consistent' with that of the redefined property,  any resolution would have to consider modifying such constraints to take redefinition into account. 

Other properties that could be considered inherited would be do/entry/exit actions of  a state and, target of a transition amongst others. 

I believe this might be a similar argument to issue 12530. 


Resolution:
Revised Text:
Actions taken:
July 10, 2008: received issue

Issue 12837: Figure 7.65 and its explanation, P115 (uml2-rtf)

Click
here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:
there is a following description:
"A in package P3(P3::A) represents the result of the merge of P1::A into
P2::A and not just the incremnetP2::A."


According to definition of Package import, 
If the name of an imported element is the same as the name of an element 
owned by the importing namespace, that element is not added to the importing namespace.


Therefore, if there is same name A on the Pacakge"P3", P2::A is invisible from P3?


Resolution:
Revised Text:
Actions taken:
September 8, 2008: received issue

Issue 12852: issue to address how problem 11240 was actually addressed in UML 2.2 spec (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
 believe we need to raise a new issue to address how problem 11240 was actually addressed in the UML 2.2 spec. 

If I'm not mistaken, the fix for issue 11240 should involve redefining TemplateParameter::default and constraining the type to Classifier.    However, all that was actually done to address the problem was to remove the offending (redundant) "defaultClassifier" property.    The original issue: http://www.omg.org/issues/uml2-rtf.html#Issue11240 ,  makes mention of the redefinition. 

Resolution:
Revised Text:
Actions taken:
September 11, 2008: received issue

Issue 12860: InterfaceRealization (uml2-rtf)

Click
here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:
InterfaceRealization.contract and InterfaceRealization.implementingClassifier currently subset Dependency.supplier  and Dependency.client respectively. 

 

It seems to be that redefinition is a more appropriate relationship between these attributes, because InterfaceRealization.supplier  and InterfaceRealization.client (as inherited) are restricted to the multiplicities of, and will always have the exactly the same values as, InterfaceRealization.contract and InterfaceRealization.implementingClassifier.


Resolution:
Revised Text:
Actions taken:
September 25, 2008: rewceived issue

Discussion:


Issue 12942: Actors cannot own Operations - a contradiction (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The ability for an Actor to implement an Interface was added as a result of this issue against the UML2 specification: http://www.omg.org/issues/uml2-rtf.html#Issue8078

Because an Actor is now a BehavioredClassifier it can implement interfaces, but according to the UML superstructure specification, Actors cannot own Operations.  This situation seems to contradict the semantics for InterfaceRealization (UML Superstructure v2.1.2 section 7.3.25): 

"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 implementing classifier will
have an operation or reception for every operation or reception, respectively, defined by the interface."



Resolution:
Revised Text:
Actions taken:
October 8, 2008: received issue

Issue 13058: 18.3.8 Generalization of stereotyped model elements (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:
It is not clear whether it is allowed to have a generalization relationship between two model elements that have different stereotypes. Please clarify in the uml specification

Resolution:
Revised Text:
Actions taken:
November 6, 2008: received issue

Issue 13088: MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug (uml2-rtf)

Click
here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:
Using the profile, an element can have several stereotypes. However, in 
the metamodel, an element can not have several labels traducing these 
stereotypes. A traduction in the metamodel of this kind of element 
(stereotyped several times) can not be made.

Resolution: This does not seem as a problem of MARTE in particular. It applies to any profile. If somewhere it may be solved, it is probably in the UML RTF or next UML RFP. I suggest to either Close No Change or Transfer to the UML 2.4 RTF. Disposition: Transferred to UML 2.4 RTF
Revised Text:
Actions taken:
September 26, 2008: received issue
February 17, 2010: transferred from MARTE FTF

Discussion:


Issue 13165: There is no way to specify the behavior of operations which are members of data types (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I would like to bring to your attention (as the contact person for the UML standard) a small bug we found with the UML specification: There is no way to specify the behavior of operations which are members of data types such as enumerations. Such operations can be modeled in UML, since each classifier can have operations, and this is useful to describe, e.g. Java enumeration operations. However, they cannot be assigned method behaviors, since nested behavior can only be added to classes.
One solution to this would be allowing to nest classifiers in data types - i.e. to copy the association nestedClassifier: Classifier [*] to DataType (just as was done for case for ownedOperation : Operation [*]).

Resolution:
Revised Text:
Actions taken:
December 18, 2008: received issue

Issue 13192: UML: Standard Techniques to disambiguate crossing lines needed (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
With the increasing use of UML and descendant languages (e.g.., SysML) for more complex diagramming situations, the occasion for crossing lines becomes increasingly hard to avoid.  When such happens, it often becomes difficult to determine the correct start/destination of each line. This is compounded by the use of tree structures for the depicting of generalization and aggregation/composition relationships. 

 

 

Whenever two lines cross, there can ambiguity associated with the line path.  The UML standard should supply a normative technique to resolve this ambiguity, The introduction of a “jog”  - a small curve in one of the intersecting lines – has traditionally be acceptable.         

 

Proposed solution: 

 

In the diagram appendix, add a paragraph introducing the problem and recommending a standard graphical solution. A diagram may be useful to convey the intent. 

 

 If a normative solution is not desired, the paragraph can recommend several selected approaches to resolve the disambiguities.


Resolution:
Revised Text:
Actions taken:
December 24, 2008: received issue

Issue 13255: UML2.2 RTF: EnumerationLiteral is a DeploymentTarget (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
EnumerationLiteral is an InstanceSpecification; InstanceSpecification is a DeploymentTarget.  This makes EnumerationLiteral a DeploymentTarget, which is clearly nonsense.

 

I strongly question both of these inheritance relationships

Resolution:
Revised Text:
Actions taken:
January 14, 2009: received issue

Issue 13395: UML2: Unclear how to indicate what events a classifier might send (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML2 has Receptions which can be included in realized/provided Interfaces to indicate what Signal events a Classifier is able to receive.  But it isn't clear how a Classifier would indicate in its interfaces what events it might send/generate, and therefore what events a collaborating Classifier connected to this Classifier in some way would need to be prepared to handle. 

UML2 Reception semantics should be updated to indicate Receptions can appear in either Realized/provided or Usage/required Interfaces. A Reception in a required interface would indicate a signal event the owning classifier might send through a SendSignalAction or BroadcastSignalAction. This would provide all the interface information needed on both sides of a connector to know what SignalEvents might be sent and/or received

Resolution:
Revised Text:
Actions taken:
January 30, 2009: received issue

Issue 13425: Section: 7.3.9 Comment should be NamedElement (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Significant
Summary:
I propose to define the Comment as a NamedElement instead of Element. The SysML and UPDM working groups identified that it is necessary that comment based model elements have a name, could be packaged and identified. 

Resolution:
Revised Text:
Actions taken:
February 3, 2009: received issue

Issue 13449: we can create an invalid active state configuration (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Adam Neal, adamneal(at)ca.ibm.com)
Nature: Clarification
Severity: Significant
Summary:
The spec states: "An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region." This is slightly ambiguous as one could take it to mean that the region is the region who owns the target dirctly. This would allow one to create the case where we can create an invalid active state configuration. consider: S1's region1 owns S2 and S3 who both have sub verticies. An entry point on S1 should only be able to target one vertex with region1 (either a direct or deeply nested vertex), but not more then one. If the assumption by a user was made that both the verticies in S2 and S3 could be targeted (since they are owned by different regions) then the tooling would essentially be allowing concurrent entries into a single region. Where as, really we need to specify more along the lines of that the LCA region of the source and target may have at most a single transition. An entry point pseudostate is an entry point of a state machine or state. For each transition that targets a vertex in region R, there may not exist another transition targeting a vertex in region R nor any region contained within R. Also, given the alternate semantics of entering a state (that regions don't have to be entered and the state itself can remain active), entry points should not be required on composite states only. Connecting to an entry point with no outgoing transitions or to the state border itself should be considered semantically the same. One usecase for this is that users may define entry/exit code on the state itself to preform some basic behavior, but in redefined contexts want to enhance the behavior by continuing that transition to a sub vertex. 

Resolution:
Revised Text:
Actions taken:
February 6, 2009: received issue

Issue 13452: Section 9.3.4 Collaboration Use, 2nd constraint creates unneces (uml2-rtf)

Click
here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson.george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:
Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that.  It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first.  The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second.  The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration.

 

This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations.

Resolution:
Revised Text:
Actions taken:
January 30, 2009: received issue

Issue 13466: Lack of clarity about meaning of package shapes containing elements with fully qualified names (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
The UML specification is not clear what it means for an element with a fully qualified name to appear within a package shape on a package diagram.

 

7.3.37 says “The members of the package may be shown within the large rectangle”.  So it seems to rest on the definition of members, which is the union of owned members and imported members.

This is somewhat reinforced by “elements that become available for use in an importing package through a package import or element import may have a distinct color or be dimmed to indicate that they cannot be modified”.  Note that the definition of ElementImport says “identifies an element in another package, and allows the element to be referenced using its name without a qualifier”.  So we’d expect imported elements to be dimmed, but not have a name qualification (a poor user experience if I may say so).

 

Subsidiary issue: Why does it say that they cannot be modified?  This is a matter for tool implementers, and has no place in the UML spec.

 

But elsewhere it says “The public contents of a package are always accessible outside the package through the use of qualified names”; 

 

So how should I interpret the appearance of an element shape within a package shape when the element has its fully-qualified name (as frequently appears in the UML spec itself)?  Does this imply the existence of an import or not?  According to  “The public contents of a package are always accessible outside the package through the use of qualified names” no import is necessary; according to “The members of the package may be shown within the large rectangle” an import is necessary.  At the very least this should be clarified.

 

More deeply perhaps the issue is that the definition of the term “referencing an element” is very dubious.    Does appearing on a diagram involve referencing?  How about appearing in tool windows, type pickers, etc? 


Resolution:
Revised Text:
Actions taken:
February 9, 2009: received issue

Discussion:


Issue 13651: UML2.2. Contradications in 14.3.10 (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
14.3.10: says “An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.”  However slightly lower down it says “The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).”  These appear to be directly contradictory.  

 

Is it necessary for the start and finish occurrences of an ExecutionSpecification to be ExecutionOccurrenceSpecifications?  Is it valid to have a MessageOccurrenceSpecification at the start and finish of an ExecutionSpecification?  Is it valid to have both a MessageOccurrenceSpecification and an ExecutionOccurrenceSpecification representing the start/end of a ExecutionSpecification?   Are Message reception and Execution commencement the same or different events?

 

Also the multiplicity on the source (non-navigable) end of ExecutionOccurrenceSpecification.Execution is 1, which makes the model clearly invalid.  I believe it should either be 2 or 0..2, depending on the answers to the questions above.

Resolution:
Revised Text:
Actions taken:
March 2, 2009: received issue

Issue 13656: UML 2 - appearance of Association Ends as members of the related classes (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:
Since the dot notation was introduced to represent ownership of association ends separately from navigability, it appears that the following is the case: a navigable association end that is owned by the association does not appear in the namespace of the class from which it is navigable.  How, then, can it be said to be navigable?  I believe that all navigable ends should appear in the namespace of the class from which they are navigable, regardless of who owns the ends.

Resolution:
Revised Text:
Actions taken:
March 3, 2009: received issue

Discussion:


Issue 13657: Section: 9.3.11 Port (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: UML 2.2 Beta1 (2008/05/01)

Section: 9.3.11 Port

 

Summary:

 

Consider the MARTE2 FTF proposal developed in the resolution to MARTE issue 11820 in the scope of the tactical resolutions being developed for clauses 8 and 9 of the UML superstructure specification for the UML 2.3 RTF.

 

The MARTE resolution to issue 11820 attached is available in ballot1 of the MARTE2 FTF as “issue11820 resolved.doc” here:

 

http://www.omgwiki.org/marte-ftf2/doku.php?id=marte_ftf2_ballot_1

Resolution:
Revised Text:
Actions taken:
March 3, 2009: received issue

Issue 13664: UML 2.2 InteractionOperand abstract syntax (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Section 14.3.16 says “An InteractionOperand is contained in a CombinedFragment.”  Yet the abstract syntax figure 14.7 shows that an InteractionOperand may be contained by a CombinedFragment, or may (via inheritance) be owned by an InteractionOperand.   These are inconsistent and the specification should make clear which is correct.

Resolution:
Revised Text:
Actions taken:
March 9, 2009: received issue

Issue 13841: Concrete specialization of the Relationship meta-class are missing (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Enhancement
Severity: Significant
Summary:
Concrete specialization of the Relationship meta-class are missing. Except few cases restricted to very specific usages (import/merge, association), and according to the current meta-model, all concrete instaciations of Relationship are Dependencies. This situation has an undesirable side-effect in UML models but also in some UML profiles like SysML and MARTE. Indeed, specialized or extended relationships like Deployment or Allocation generate unexpected dependencies between related elements. A solution might be to add a concrete (Directed)Relationship meta-class in the meta-model. The concept of "Allocation" is very generic and might provides that meta-class. It would be a convenient generalization for Deployment.

Resolution:
Revised Text:
Actions taken:
March 27, 2009: received issue

Issue 13848: issue within UPDM with profile diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
there is an issue within UPDM with profile diagrams. As there are multiple stereotypes in the diagrams, showing metaclass and extension clutters the diagrams.
They become literally unreadable in the spec as they need to fit in the page, since every element takes addition space for extension:

In MagicDraw, we have such notation:

It saves time, is intuitive, but this is non standard thing, so we cannot use it in UPDM.

I would like to raise an issue on the notation of extended metaclass, but I'm open for discussion :)

Resolution:
Revised Text:
Actions taken:
March 31, 2009: received issue

Issue 13856: Section: 18.3.6 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Figure 18.8 includes a Metamodel formalism which has never been introduced, in particular with respect to customized metamodels. The presentation as a package with a triangle is new at this point. Although the concept of a metamodel is verbally explained in the Infrastructure, there is no abstract syntax. It becomes implicitly clear that a metamodel is a package. I suggest to insert a definition of a Metamodel as a subclass of Package in the Infrastructure document or in the Profiles chapter of this document. This also allows to explain what is meant by "applying a metamodel". Also, the term "a UML2 metamodel" (p. 666) is unclear, taking into account that UML2 itself is a metamodel. This all should be clarified due to the importance of the metamodel concept in this chapter. The same applies to the respective chapter of the Infrastructure document.

Resolution:
Revised Text:
Actions taken:
April 9, 2009: received issue

Issue 13858: Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box) (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

Resolution:
Revised Text:
Actions taken:
April 9, 2009: received issue

Issue 13859: The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading. Although it serves to explain the package import, it should not suggest an improper application of stereotypes. The stereotype defined here (Device) holds attributes which are not typical for devices as such. For instance, a device is not expected to have a color or volume. It may make sense to apply this stereotype to a class of TVs, but not to a class of dishwashers, for example. A better disctinction would be electrical versus non-electrical devices, or handheld versus non-handheld. Second, the attributes as shown here refer to properties which are significant for instances, not for classes. The example basically shows that we can create a TV class, declaring this to be a device. The Factory package shows an instantiation, setting the volume to some value, but omitting the remaining attributes - which *must* be set as well. The volume parameter for a class of TVs is questionable - what should it mean? This may lead the reader to believe that the volume parameter is meaningful for instances of the model element, although it is associated to the stereotype instance which is associated to the model element. Basically, the element in the Factory package denotes the class of all TVs whose volume is set to 10. This still does not imply a meaning for the instances.

Resolution:
Revised Text:
Actions taken:
April 9, 2009: received issue

Issue 13862: Section: 18.3.8 (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The reader may be led to believe that the application of the stereotype <<clock>> changed the model by adding an operation "Click" to the class StopWatch. It should be clarified that the operation must be owned by the StopWatch even without applying the stereotype. The stereotype instance may, of course, be associated to this operation, and serves as a pointer, for example, to be used in model transformations. Figure 18.18 does not provide this information; it shows the result of the application and not the state before.

Resolution:
Revised Text:
Actions taken:
April 9, 2009: received issue

Issue 13908: there are numerous places where associations between UML elements have only one, navigable role (uml2-rtf)

Click
here for this issue's archive.
Source: Atego (Mr. Phillip Astle, phil.astle(at)atego.com)
Nature: Enhancement
Severity: Significant
Summary:
In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin.

Resolution:
Revised Text:
Actions taken:
April 29, 2009: received issue

Issue 13926: Template Binding Question (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
In  the spec, there is a constraint on TemplateParameterSubstitution, as follows:

actual->forAll(a | a.isCompatibleWith(formal.parameteredElement)) 

"actual" and "formal" are TemplatableElement. So looking up "isCompatibleWith" definition in the spec, I find this:

The query isCompatibleWith() determines if this parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. Subclasses should override this operation to specify different compatibility constraints. 

ParameterableElement::isCompatibleWith(p : ParameterableElement) : Boolean; 
isCompatibleWith = p->oclIsKindOf(self.oclType) 

This means if I defined a class template with a template parameter linked to Interface A (a ParametrableElement), and I used this interface to type a property inside the class template, that I cannot substite the interface with Class B that realizes Interface A, because Class B and Interface A do not have compatible kinds (metaclasses). 

Is this what the constraint is saying? Is this Valid?

Resolution:
Revised Text:
Actions taken:
April 29, 2009: received issue

Issue 13927: Subsets vs. Redefines (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

Resolution:
Revised Text:
Actions taken:
May 8, 2009: received issue

Issue 13936: UML2: Need clarification on circle plus notation for containment (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Clarification
Severity:
Summary:
Section 7.3.37, Notation indicates that "The members of the package may be shown within the large rectangle. Members may also be shown by branching lines to member elements, drawn outside the package. A plus sign (+) within a circle is drawn at the end attached to the namespace (package). ". It is unclear if this is intended to apply to any Element owner/ownedElement relationship (such as nested classes, owned behaviors, etc.) or only to packages. Some vendors do support circle-plus notation to depict metamodel containment, others don't. If it applies only to packages, then what is the notation for these other membership associations? 

Resolution:
Revised Text:
Actions taken:
May 18, 2009: received issue

Issue 14022: Visibility and Import relationships (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity:
Summary:
Am I wrong or is there actually something inconsistent in the specification around the concept of "visibility"?


As I underlined for the ballot 6 vote, the current specification explicitly states that Element/PackageImport has no impact on element visibility. Cf. my comments posted on the 27th of April about issue #11567: 


"According to the current definition of the visibility concept, my understanding is that it's neither necessary nor possible to use Import relationships to make an element "visible" (i.e. available). The specification explicitely states that :


* an ImportedElement can only have a public visibility or no visiblity at all (cf. ElementImport, constraint #2)


* (p111) : "The public contents of a package are always accessible outside the package through the use of qualified names. "


* (p66): "The visibility of the ElementImport may be either the same or more restricted than that of the imported element. "


Then, the only concrete effect of an Import relationship is to give the ability to refere to an element using its simple name rather than its qualified one."


Nevertheless, and even if there is no impact on the resolution, I found this sentence in the discussion of issue #12833 (ballot 8) : ". The names of stereotypes or classes in a parent profile are not visible to a profile nested in that parent profile without a PackageImport"


Resolution:
Revised Text:
Actions taken:
June 23, 2009: received issue

Issue 14044: Should there be a constraint for extends equivalent to 16.3.6 [4] (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity: Minor
Summary:
Should there be a constraint for extends equivalent to 16.3.6 [4], that extends should be an acylic relationship between use cases?

Resolution:
Revised Text:
Actions taken:
July 1, 2009: received issue

Issue 14045: semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity: Significant
Summary:
The semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear. There is a rule specifying that use cases may be only be associated with other use cases with different subjects because they describe a complete usage of the subject. But that doesn't explain what it means to have any association. The only hint is in the notation section that gives some examples as "(e.g., to denote input/output, events, and behaviors)." However these details ought to be part of semantics and expanded on.

Resolution:
Revised Text:
Actions taken:
July 1, 2009: received issue

Issue 14078: UML 2: notation and concepts for unbound and un-owned template parameters are not clear (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
When creating classifier templates, it is possible to have template parameters that are not owned by the classifier, in at least the following situations:

 

1.      When the classifier is a partial binding, i.e. it is bound to a template classifier but not all the parameters are bound

2.      The classifier extends a template classifier and has a redefined signature.

 

In these cases, what is the notation for the non-owned parameters?   Let’s say, for example, that we define C1[A: Class, B: Class].  Then we create C2<A->G>.  Does the notation for C2 show a parameter box with B, indicating that B remains to be bound?

 

Indeed, from a metamodel point of view, is it correct for C2 to have a signature that refers to B as one of its non-owned parameters, or is C2’s signature “derived” according to “In a canonical model a bound element does not explicitly contain the model elements implied by expanding the templates it binds to, since those expansions are regarded as derived.”

 

Similarly, given C1[A: Class, B: Class], let C3 inherit from C1.  Does the notation for C3 show a parameter box with A and B?

 

Let C3 inherit from C1 and also be bound to it.  Is it possible for the formal parameter A defined in C1 to be substituted by the formal parameter A defined (by inheritance) in C3, according to the statement in 17.5.3: “In case of complete binding, the bound element may have its own formal template parameters, and these template parameters can be provided as actual parameters of the binding”?

Resolution:
Revised Text:
Actions taken:
July 15, 2009: received issue

Issue 14081: Package merge is missing a rule (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity: Minor
Summary:
Package merge is missing a rule for when two elements have conflicting values for isLeaf, cf. the rule for abstract elements

Resolution:
Revised Text:
Actions taken:
July 16, 2009: received issue

Issue 14084: Subsets vs. Redefines (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

Resolution:
Revised Text:
Actions taken:
May 8, 2009: received issue

Issue 14090: authorize a reference to an operation in a realized interface. (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Ansgar Radermacher, ansgar.radermacher(at)cea.fr)
Nature: Enhancement
Severity: Significant
Summary:
A common task is to implement the operations of an interface I in a class A. The implementation of an operation has a specification reference to the realized operation. In the current UML specification, the operation must be copied into the class before it can be realized, since only owned behavioral features can be referenced: "(section 13.3.2) ... The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it.". I.e. the standard only allows to reference inherited operations, but not realized operations. This is not very practical, since it implies not only copying the operation but also assuring that it remains synchronized with the operation that is defined in the interface (of course, the modeling tool could do the synchronization, but it would still imply storing redundant information within the model). It would be good to authorize a reference to an operation in a realized interface.

Resolution:
Revised Text:
Actions taken:
July 22, 2009: received issue

Issue 14183: Need notation option to show type stereotype on typed element (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

A part (property, port, etc.) of a class is a TypedElement and can of course have applied stereotypes of its own. However, it is often useful to know not only the Type of a TypedElement, but how that type is stereotyped. This would provide more complete information about the type that helps communicate the meaning of the model. 

Some tools by default show the stereotypes of a type on parts typed by that type. For example, if Interface Purchasing is stereotyped as <<Provider>>, a port typed by that Interface might be displayed as <<Provider>>purchaser: Purchasing. But this is actually incorrect because it shows <<Provider>> extending a Port while the stereotype is defined to extend Inteface, not Property. 

UML2 should provide a notation option to allow Type stereotype names to be displayed in TypedElements. The example above could be more correctly shown as purchaser: <<Provider>> Purchasing - the stereotype for the interface is next to the interface, on the other side of the colon. If the Port is a <<Service>> port, then that would be shown as <<Service>>purchaser: <<Provider>>Purchasing. 


Resolution:
Revised Text:
Actions taken:
August 6, 2009: received issue

Issue 14186: The spec may require some clarification regarding figure 14.16 (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Clarification
Severity:
Summary:
The spec may require some clarification regarding figure 14.16 . 

I believe that  "PIN" is just an attribute of the interaction "UserAccepted" but it may be unclear from the picture alone. 

In addition, how can the local attribute PIN be passed as a parameter to the operation Code()?   On the message "Code" would we specify an attribute of type Opaque Expression and use PIN ?  This seems to break the formal link between PIN the attribute and PIN the argument. 

Resolution:
Revised Text:
Actions taken:
August 11, 2009: received issue

Issue 14227: UML: Issue with stereotype icons in a profile (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Gary Johnston, gjohnsto(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Currently, a profile can include an icon for a stereotype.  This means that a stereotype can have just one icon.  If a stereotype extends more than one UML metaclass the profile designer might want to include different icons depending on which of the metaclasses the stereotype is applied to.  For example, if I define a stereotype <Foo> that extends both <metaclass> Interface and <metaclass> Class, I will probably want a different icon for the two different usages of <Foo> but there is no way to define more than one icon per stereotype. 
The suggestion is that one should be able to specify an icon for the extension relationship between a stereotype and metaclass instead of (or in addition to, perhaps) on the stereotype itself.  Profile authors would then be able to assign distinct icons for different stereotype usages.  And UML tools would then be able to display distinct icons in such cases. 
This issue came up during discussions of the in-progress SoaML specification & profile.  One of its stereotypes (<ServiceInterface>) extends both Class and Interface and the icons for each should be visually distinct.  Currently, profiles don't provide a way to make this happen. 

Resolution:
Revised Text:
Actions taken:
August 27, 2009: received issue

Issue 14356: Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics & test this statically with OCL & dynamically with OCL & fUML scenarios.      Bran,

Your comments and those from Dave Hawkins & Salman Qadri confirm my 
suspicions that it would be unwise to submit a resolution to 8023 in ballot 10; I won’t.

Dragan Milicev’s paper is really excellent; I’m really glad you pointed this out.
I highly recommend this paper for consideration in the UML2 RFI workshop:

On the Semantics of Associations and Association Ends in UML
Milicev, D.;
Software Engineering, IEEE Transactions on
Volume 33,  Issue 4,  April 2007 Page(s):238 - 251 
http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326

Dragan clearly states that his formalization of association is squarely in 
the domain of intentional semantics; not extensional semantics as stated in 
clause 7.3.3:

“An association describes a set of tuples whose values refer to typed 
instances. An instance of an association is called a link.”

This paper points to a fundamental limitation in the way the runtime 
semantics of the UML2 has been specified in clause 6.3.1 in the domain of 
extensional semantics:

“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 real problem here isn’t in the fact that there are two different ways to 
specify the semantics of associations ­ the restrictive interpretation in 
Dragan’s terminology which is really an extensional semantics and the 
intentional semantics Dragan proposes which I believe is fundamentally 
correct (as far as I’ve read it).

The real problem is in the semantic mismatch between the extensional & intentional semantics of associations (assuming Dragan is right).
The current extensional semantics of the UML2 is based on an impoverished notion of collections: sets & sequences.
Dragan’s intentional semantics for associations involves the same categories of collections that OCL uses: sets, sequences & bags (see clause 7.5.11 in ocl2/ocl2.1)

What this all means is that we need to focus an RTF cycle on reconciling the algebra of collections across OCL & the extensional & intentional semantics of UML2 and of fUML.
The goal of this reconciliation is twofold: 

we should be able to specify all necessary well-formedness constraints on the relationship between M1 & M0 in OCL 
we should be able to use fUML to exercise relevant scenarios of events starting in one M1/M0 context and finishing in another M1/M0’ context and specify in OCL well-formedness constraints on the relationship between M0/M0’ as a function of the events processed & the behavior that happened as a result of processing by some active object (see clause 6.4.2). 


We can use the fUML subset to scope this reconciliation effort to something manageable as an RTF; learn from this experience and use that to tackle more exotic things like state machines.

Resolution:
Revised Text:
Actions taken:
September 8, 2009: received issue

Issue 14426: Association class notation with just class or association (uml2-rtf)

Click
here for this issue's archive.
Source: Raytheon (Mr. Roy M. Bell, Roy_M_Bell(at)raytheon.com)
Nature: Clarification
Severity: Significant
Summary:
Association class notation should include just the class symbol or
  just the association symbol, in addition to the current combination of
  these. Association classes are both associations and classes and
  should be able to be notated as either one separately.

Resolution:
Revised Text:
Actions taken:
September 19, 2009: received issue

Issue 14449: PrimitiveType has missing constraints (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The UML specification text for PrimitiveType states that it has no operationsnor attributes:


"A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of
UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."


However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations.


Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType.

The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification.

Resolution:
Revised Text:
Actions taken:
October 5, 2009: received issue

Issue 14536: Stereotyped Constraints in UML (uml2-rtf)

Click
here for this issue's archive.
Source: Alion Science and Technology (Mr. Jim Logan, jllogan+omg(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the UML 2.2 spec (ptc/2008-05-05), there is no way to show that a constraint on a class has a stereotype or stereotype tags. I would like to see something with nested braces. For example, { <<stereotype>> constraint1: body {tag1=value, tag2=value} }.

I recommend changing the notation from this:

A Constraint is shown as a text string in braces ({}) according to the following BNF:

<constraint> ::= '{' [ <name> ':' ] <Boolean-expression> '}'


to this:

A Constraint is shown as a text string in braces ({}) according to the following BNF:

<constraint> ::= '{' [ <stereotypes> ] [ <name>  ':' ] <Boolean-expression> [ '{' <valuestring> '}' ] '}'

The <stereotypes> and <valuestring> use the presentation options described in 18.3.8 (Stereotype).


Resolution:
Revised Text:
Actions taken:
October 7, 2009: received issue

Issue 14544: Stereotyped Constraints in UML (uml2-rtf)

Click
here for this issue's archive.
Source: Alion Science and Technology (Mr. Jim Logan, jllogan+omg(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
The UML 2.2 spec (ptc/2008-05-05) does not allow showing only a constraint name in braces. I have found this non-standard feature very valuable when working with business users and would like to see it allowed.

The most flexible way to use constraints is to have a short, informal English description as the name, and real OCL as the formal expression. Having the flexibility to show either the name or the expression gives the best of two worlds: business SMEs can read and validate the informal English name while tools can use the OCL expression to actually enforce the constraints. In addition, a diagram can present a view for business SMEs or a view for technical people.

I recommend changing the notation from this:

<constraint> ::= '{' [ <name> ':' ] <Boolean-expression> '}'


to this:

<constraint> ::= '{' [ <name> ] ':' <Boolean-expression> | <name> '}'


This change would allow:

the author to choose to show: 
only { : expression } for technical users (a common practice) 
only { name } for non-technical users (a currently disallowed but important practice) 
both { name : body } 
the viewer to tell the difference between the name and the expression when only one is shown 
consistency with the way several other things work in UML, such as: 
action names 
action pin names 
instance specification names (i.e., just shows the name when there's no type)

attributes (i.e., one can suppress the ": Type")


Resolution:
Revised Text:
Actions taken:
October 8, 2009: received issue

Issue 14555: UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the model, Actual is shown as 1.* and OwnedActual is shown as *.

In the text 17.5.5, Actual is shown as 1 and OwnedActual is shown as 0..1.

Resolution:
Revised Text:
Actions taken:
October 12, 2009: received issue

Discussion:


Issue 14588: are Create messages aynch or synch, or doesn't it matter? (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:

In 14.3.24, the textual definition of MessageSort is badly formatted, which needs to be fixed.  Then it provides for messages of sorts synchCall, asynchCall, asynchSignal, createMessage, deleteMessage and reply.

 

So is a createMessage synchronous, or asynchronous, or can it be either?  The semantics of CreateObjectAction say “The new object is returned as the value of the action” - which implies that synchronous ought to be a possibility.  But chapter 14 appears silent on this topic.

Resolution:
Revised Text:
Actions taken:
October 28, 2009: received issue

Issue 14928: Property subsets other regular property, non-derived union (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections.

Association::memberEnd is not union but is subsetted 
Class::ownedAttribute is not union but is subsetted 
TemplateSignature::parameter is not union but is subsetted 


Resolution:
Revised Text:
Actions taken:
January 8, 2010: received issue

Issue 14930: One association end is derived, another is not (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
One association end is derived, another is not.  It causes implementation issues, as when we set one end, opposite should be automatically set also.
 
Vertex::outgoing [0..*] is derived, opposite Transition::source [1] is not
Activity::structuredNode [0..*] is derived, opposite StructuredActivityNode::activity [0..
ConnectableElement::end [0..*] is derived, opposite ConnectorEnd::role [1] is not
Package::ownedType [0..*] is derived, opposite Type::package [0..] is not
Package::nestedPackage [0..*] is derived, opposite Package::nestingPackage [0..] is not
Vertex::incoming [0..*] is derived, opposite Transition::target [1] is not


Resolution:
Revised Text:
Actions taken:
January 8, 2010: received issue

Issue 14933: UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Refactor UML to separate SW-Specific Aspects from Foundation Language

One useful refactoring would be to separate UML into a abstract modeling part and a software model part, so that other standards can base themselves on the abstract modeling piece without the baggage of software specific features. We would not want to encourage programming language-specific profiles, but wish to take out things such as components from the base UML profile.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14934: Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling.

One problem with UML now is that the ability to simplify by applying more consistency is not taken advantage of. By being consistent – eliminating special cases, the specification becomes smaller, the modelers have to learn less, the tools can reuse code, and UML becomes easier to understand and use. 

As behaviors (e.g., operations, activities) are classifiers, there is no good reason why the class and composite structure diagrams cannot be used to model them. This would allow for diagrams showing inheritance, composition, associations, dependencies, etc. While this may not be “OO”, it would support functional decomposition/programming approaches, simplify, and make more regular the specification. See the RFI response ad/2009-08-05.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14935: Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In OMT, states could be modeling on the class diagram, which was a powerful alternative approach to capture the structure of a state machine. It made clear the relationships between entry/exit actions of superstates on substates, the ability to override responses to trigger/actions pairs of superstates by a substate, the scope of a defer, what a history node really does, etc. understandable in a way that statemachines don’t do because of their different presentation style. This should also restore the ability to identify state-specific attributes and constraints, and the ability to specify parameters on the state’s possible behaviors – two features that have often been requested. Restoring this ability will make UML treatment of states more like their treatment for classes. Similar ideas have been periodically proposed, see http://www.conradbock.org/statemachine.html.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14936: UML: Need more robust value model that would enable capture of values vs time (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Current timing model does not enable useful capture/mapping of values vs time. UML does support initial values and current values, but not evolving values. This is necessary for proper description of the behavior, capture of simulations, requirements development

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14937: UML: Incorporate SysML Requirements Model into UML (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Software Developers, and any people who are using UML as a core language can use the ability to capture /categorize requirements

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14938: UML: Include text description field with model element (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14939: UML Associate an image/icon with each model element (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML should support the ability to associate an image/icon with each model element. Current approaches only allow a stereotype based approach. Each model instance should be able to have its own icon. 


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14940: UML: Provide unique URL/URI Reference to/from Model Elements (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Unique URL/URI Reference to/from Model Elements

In Model-Driven Development (MDD), the model is the repository of truth on the project. However, we recognize that the complete containment of all information on a project in a single tool repository is not a near-term solution. To this end, we need the ability to support explicit references from model elements to externals (such as documents, other types of models) and similar references back. 

This are not just pointers, we need the ability to incorporate information (e.g., documents, web pages, diagrams, pictures) from elsewhere and to support refreshing with current data, as well as the export of model information into external locations. Some simple examples:

1.    A driving requirements document may contain tables and pictures, a modeler will need direct access to these elements.

2.    A reviewer of a model may need to see diagrams where the appropriate and current icons substitute for the UML graphical elements.

3.    An organization may wish to publish documentation of a particular aspect of the model on the internet and wish that the visitors always obtained the latest information

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14941: UML: Include text description field with model element --- additional information added (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

This capability is required for modelers to incorporate significant amount of explanatory documentation for each element. The ability to include textual descriptions for each model element and other basic metadata should be part of UML. In addition, such text should be augmented with the ability to structure and format the model element descriptions.

We would like to see support for RTF, PDF, XML, HTML, and XHTML, as well as support for including graphics

Similarly, a modeler should be able to type any attribute with a string-like type that allows for similar formatting or markup.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14942: UML:Notational option to display inherited features in a subclass (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
The ability to see the inherited features is often necessary, however, such items should be displayed in a graphically consistent manner – and available on all tools.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14943: Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Non-structural, non-owning Containment
While packages and stereotypes have their purposes, we need another way of combining and identifying groups of related elements based on specific partitioning criteria. This allows us to categorize and organize system elements – a common task for SEs.

We could use this to identify those elements that are related to a particular architectural layer, due in a particular delivery, produced by a particular manufacturer, or related to a particular concern (e.g., security).

Model elements could belong to any number of these containers. These containers should appear on diagrams, tables, and the browsers, but should not confer or change any prior ownership. Populating these containers could be done mechanically and/or by execution of rules. The containers can have value properties and dependencies that are considered to logically apply to the members of the container


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Discussion:


Issue 14944: UML: A strong ability to support reviewing packages (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
A strong ability to support reviewing packages
On the large projects, we find that the project needs the ability to present model subsets to reviewers, and allow commenting, proposed corrections, assignment of action items, and red-line comparisons. UML needs the ability to create these review packages in a way that can support the types of changes that reviewers propose – without changing the underlying model.

The creation of these review packages should support both rule-based and manually constructed packages, including the diagrams and the selection of elements.

These could be based on IEEE 1471 views and the use of QVT.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14945: UML: Support for maintaining what-if models in repository without massive duplication (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Support for maintaining what-if models in repository without massive duplication

 

UML and descendant modeling languages should be able to support multiple solutions within a model without excessive duplication. This could be because of planned system evolution or because we need to compare multiple approaches. One solution might be to support standardized named effectivity/expiration fields for each model element (including dependencies). All diagrams, queries, reports, etc., could be conditioned by a selected date. Instead of dates, a set of version numbers could apply to each model element, with the model filtering work in same way. 


Resolution:
Revised Text:
Actions taken:
January 11, 2010: reeived issue

Issue 14946: UML Support for multiple library levels (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In large-scale development environments where development may be iterative and/or incremental, it often happens that there are standardized libraries of common or reusable elements, in various levels of completion. These may be type definitions, classes, objects, parts, requirements, etc. While current «import» and «access» are useful to reuse these elements, we need the ability to specify an ordered chain of libraries, where an element usage would obtain the first occurrence of the element in the chain. Note that the libraries may be located remotely or on the web.

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14947: UML: A strong ability to support generating Documents (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
A strong ability to support generating Documents
On the type of projects that we work on, we find that the project needs the ability to produce standardized documents from the models. While most tools support documentation generation to some extent, the rules used to construct the documents are not standardized. UML needs the ability to create these documents in a standardized way that can support automatic generation from the package structure, the model element descriptions (see above), incorporating diagrams, externals (see URL/URI above), and document models (a UML model of the document by composition of sections).

The creation of these documents should support rule-based and manually constructed diagrams.

These could be based on IEEE 1471 views and the use of QVT.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14948: UML: Diagrams as Model Elements (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Diagrams as Model Elements
Make diagrams full and equal model elements, tied to the regular model element that the diagram is displaying. Refer to the SysML specification in Annex A.

All diagrams types should have an unique 2-3 character model element type, and also supporting diagram types.

As a regular model element is should be able to support attributes, such as ownership, status, purpose, version (possibly operations also) and dependencies. As a model element, it should be referable by any URL/URI scheme that can reference model elements.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14949: UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Leverage and build upon fUML semantics and associated formalism to provide semantics for behavior and structure


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14950: UML: Better Definition of Compliance (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Diagram / Model Interchange
The current level of Diagram and Model interchangeability is appalling and is a significant barrier to further penetration of UML/SysML Into the marketplace. With the advent of new test suites (such as by OMG’s Model Interchange Working Group (MIWG)), the UML specification should require demonstrated success in some of these tests before a UML tool can be declared conforming to UML.

OCL Support
A minimal required support for OCL should be defined as part of compliance.

QVT Support
A minimal required support for QVT should be defined as part of compliance.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14951: UML: Large Scale Model Support:Federated/Distibuted Models (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Large Scale, Distributed, and Federated System Support
Many projects of interest have become so large that for practical reasons more than one “model” may be required. Such models may also be at different locations and supported in different tools. We need features in UML that will support very large distributed heterogeneous models in a standard way.

While the complete solution to this strong need is not yet known, such features will probably need to include: 

1.    higher level concepts than the standard package; 

2.    a uniform URL/URI convention for models and model elements; 

3.    standard APIs so that the tools can query each other; 

4.    a strong ability to support IEEE 1471 views; 

5.    ability to synchronize different models; 

6.    ability to propose changes across models. 

While some of these solutions components may be considered tool issues, users with large models need a consistent standard solution. This may solved by a separate RFP but any changes to UML for other reasons must be checked to see if it interferes with large model scenarios.

As a related problem, there seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14952: UML: Cross model dependencies (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
There seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up. For example, can a tool transverse a dependency that crosses models. Can a tool transverse the reverse direction?

These need to be solved in a way that is internally consistent and consistent with distributed/federated models


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14953: UML: Improve Sequence Diagram Semantics (3-issues) (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML is missing useful sequence diagram support for.

 

1)      Information Flows

2)      Continuous or Repeating messages (for example, on the 200th heart beat message)

3)      Improved timing semantics (requirements for min/max timing)

 

Without these features, it will not be possible to represent common situations on sequence diagrams or specify realtime behavior. It may also prevent mapping to state diagrams. 

Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Discussion:


Issue 14954: UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In sequence diagrams the use of Assert, Negate, Consider, and Ignore fragments often leaves the reader confused about their intent.

 

For example, an Assert fragment is intended to mean that this fragment is the only sequence of events to be considered. This could be interpreted as the only sequence 

1)      that can occur; so the reader/developer does not need to consider others as they are impossible

2)      that is interesting; so that the reader/developer can ignore the others as being not interesting

3)      that is allowed; so if something else occurs it is an error

4)      that is allowed; so that the reader/developer needs to prevent the others from occurring.

 

Similar issues arise with the other fragments

An Negate Fragment, could be interpreted as

1)      this fragment can never occur, so don’t worry about it

2)      If this fragment occurs this is an error

3)      You need to prevent this fragment from occurring

 

These can be solved by adding a parameter to these fragments

 

e.g., Fact (this is the way it is); Enforce (this is the way we have to make it); Error (violations are errors); Ignore (don’t worry about violations)


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14955: UML:Access to standardized ontologies within models (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In many situations it is necessary to refer to externally defined ontologies, e.g., for types (esp enumerated types) icons, parts, etc. We need a way to select something from a rich list defined elsewhere.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14956: UML: Better Profile Capabilitiy (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Better Profile Capability
The profile mechanism needs to better support the general refactoring and reuse of profile elements to allow for compatible language evolution. This can include renaming on import, pulling in partial profiles, suppressing features, etc.

Profiles should support a more sophisticated ability to add contextual and usage based information, such as consistency rules, formatting rules, model/diagram filters, GUI and presentation options, transformation, documentation, and code generation.

These desired profile features are similar in nature to features required by viewpoints – the ability to control much of the model presentation based on audience or circumstances.


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14957: UML: Timing semantics for activity diagram (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Timing semantics for activity diagram
Enable timing diagrams and associated timing semantics to support activity diagrams.

 


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14958: UML: Higher-level reusable frameworks (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Templates, Patterns, and Frameworks
The current ability to capture software templates need to be expanded or augmented in ways that can be used to depict and utilize system design and architectural patterns, and higher-level reusable frameworks


Resolution:
Revised Text:
Actions taken:
January 11, 2010: received issue

Issue 14959: UML has no way of distinguishing Notes from Comments (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Though it is common in tools to provide a way of adding notes to diagrams that are not serialized as part of the model XMI, this is nowhere documented in the UML specification. Nor is there any notational means of distinguishing the 2 (since the dashed line attaching Comments to Elements is optional). 


Resolution:
Revised Text:
Actions taken:
January 12, 2010: received issue

Issue 14978: NamedElements whose owners do not subset Namespace (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Action is a kind of NamedElement, but the owners of Actions do not subset the property “namespace”.  

 

The same is true of ActivityNode, but this was discussed in 8668 and resolved as correct.

 

The same is true of CollaborationUse: a CollaborationUse is not in the ownedMembers of its Classifier.

 

The same is true of MessageEnd and MessageOccurrenceSpecification and Gate.

 

The same is not true of InteractionFragment, i.e. InteractionFragments appear in the namespace of their enclosing interaction.  

 

Are all of these correct?

Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue

Issue 15050: Parameter (uml2-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:
Who could explain me the following constraint on Parameter within section 9.3.10:

 

Constraints [1] A parameter may only be associated with a connector end within the context of a collaboration. self.end->notEmpty() implies self.collaboration->notEmpty()

 

I wanted to draw delegation connectors between a port and as for example the Parameters of a behaviour such as an activity. Am I allow to do that?


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

Issue 15123: Sequence diagram and Communication diagrams should support instances as lifelines (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Sequence diagram and Communication diagrams should support instances as lifelines

Resolution:
Revised Text:
Actions taken:
March 9, 2010: received issue

Issue 15207: Timing Diagram and interchange (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In the more compact version of  the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another. 
In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle". 

Some facts: 
If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram.   
StateInvariant is an InteractionFragment. 
The StateInvariant is kept in the Interaction::Fragment  ordered collection. 

Issue: 
The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state? 
StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first. 
Having to duplicate the StateInvariant and/or Constraint seems incorrect?   
( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous ) 



Am I overlooking something obvious?   If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient. 

Any insight would be appreciated. 

Resolution:
Revised Text:
Actions taken:
April 16, 2010: received issue

Issue 15236: not sure it is possible to define a constraint without a context (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
According to the semantics sub-clause of the §7.3.10, it seems that the intent is that there is a relationship between the context and the owner of the constraint:


“In general there are many possible kinds of owners for a Constraint. The only restriction is that the owning element must have access to the constrainedElements.

 The owner of the Constraint will determine when the constraint specification is evaluated. For example, this allows an Operation to specify if a Constraint represents a precondition or a postcondition”

I not sure it is possible to define a constraint without a context. I believe a constraint always has a context even if it is an implicit one.

Maybe a convenient solution would be to make the context non-derived but mandatory ([1..1]) with a default value set to the constraint’s owner.


Resolution:
Revised Text:
Actions taken:
March 16, 2010: received issue

Issue 15237: issue10087 and association-like notation (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
No problem with the issue itself or the proposed resolution. I’m just wondering about the principle of the “association-like notation”.

My concerns:

The specification says that “An attribute may also be shown using association notation”. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself. 

If it’s only a matter of notation, how to distinguish in a diagram between:

a)      an attribute with an association-like notation

 and

b)       a “true” association?

Yves


Resolution:
Revised Text:
Actions taken:
March 23, 2010: received issue

Issue 15239: Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications.   This is because in the metamodel the start and finish of an ExecutionSpecification are OccurrenceSpecifications, not ExecutionOccurrenceSpecifications.  This means that it appears to be valid for the MessageOccurrenceSpecification that is a Message's receiveEvent to also be the start of an ExecutionSpecification.


The text is equally ambiguous.  The 14.3.10 paragraph "An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification" appears to say unambiguously that the start and finish must be ExecutionOccurrenceSpecifications.  However the later sentence "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)" both introduces ambiguity through the use of the word "typically", and then proceeds to blatantly contradict the earlier paragraph.


This causes tool interoperability problems.


I suggest targeting ExecutionSpecification::start and finish onto ExecutionOccurrenceSpecification, and rewriting the contradictory semantics accordingly.

Resolution:
Revised Text:
Actions taken:
May 4, 2010: received issue

Issue 15240: Owning of interaction fragments is ambiguous when InteractionOperands are present (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
It is not clear from chapter 14 how interaction fragments are supposed to be owned when there are InteractionOperands present.

 

It seems to be the case, but is not stated, that everything diagrammatically inside the operand should be owned by the fragment.  This would, I think, give rise to the following consequences:

 

1.       The top and bottom of each fragment and operand must be on the same Lifeline or Execution.  A fragment cannot span different executions or have its boundaries cover different levels of execution nesting.

2.       Everything inside of a fragment/operand must be entirely contained by the fragment/operand. This includes both sides of a message, all nested fragments, interaction uses, and the top and bottom of execution specifications.

 

However it appears to be a valid instance of the metamodel to parent arbitrary fragments at any level of nesting, which would enable these constraints to be violated.

 

The specification should confirm these ownership constraints.  This would best be done in conjunction with the sentence “InteractionOperand contains an ordered set of InteractionFragments” in section 14.3.16, which should state exactly which InteractionFragments must be owned by the InteractionOperand.

 

Different vendors’ interpretations of this ambiguity can cause interoperability problems.

Resolution:
Revised Text:
Actions taken:
May 4, 2010: received issue

Discussion:


Issue 15248: Initialization of complex fields (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Is there a standard UML way of initializing complex fields. Several examples below

 

A: Integer (3,2) =   (1,2,3,4,5,6)

A: Integer (3,2) =  ((1,2,3), (4,5,6))

A: Integer (3,2) =  ((1,2), (3,4), (5,6))

 

And are they all the same?

 

A: Integer (2,3)  =  (1,2,3,4,5,6)

A: Integer (2,3)  = ((1,2,3), (4,5,6))

A: Integer (2,3)  = ((1,2), (3,4), (5,6))

 

And are these the same?

And what’s the difference. 

 

And here another set


Measurement (a Type)

   Value: Real

   Unit : String

 

Experiment:Measurement(3)        =   (1.0, “ft”, 2.0,”ft”,3,”ft”)

                                                            = ((1.0,”ft”), (2.0,”ft”), (3,”ft”))


Experiment:Measurement(3,2))   =   (1.0, “ft”, 2.0,”ft”,3,”ft”, 4,”ft”, 5,”ft”,6,”ft”)

                                                               ((1.0,”ft”), (2.0,”ft”), (3,”ft”), (4,”ft”), (5,”ft”), (6,”ft”))

                                                              (((1.0,”ft”), (2.0,”ft”), (3,”ft”)), ((4.0,”ft”), (5.0,”ft”), (6,”ft”)))



My preferences are for the last one above (the one with the extra set of parenthesis), because is better support composition 

e.g.

 

NullResults:Measurement             =    (0.0,”ft”)

StartingResults:Measurement(3) =   (NullResults, NullResults, NullResults)

Experiment:Measurement(3,2)    =  (StartingResults, ((4.0,”ft”),(5.0,”ft”),(6.0,”ft”)))

                                                            

 

The UML spec is silent about the correct way of doing this. I’d like to have a language independent way of doing this.


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

Issue 15290: Ports (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity:
Summary:
We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification.
 
Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class?
 
Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)?
 
How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed?

Resolution:
Revised Text:
Actions taken:
June 15, 2010: received issue

Issue 15303: How to specify actual parameters to pass to parameterized submachine StateMachine (uml2-rtf)

Click
here for this issue's archive.
Source: Atego (Mr. Simon Moore, simon.moore(at)atego.com)
Nature: Clarification
Severity: Significant
Summary:
A State Machine can have parameters. How can values for these parameters be passed from a submachine State which references a State Machine with parameters?

Resolution:
Revised Text:
Actions taken:
June 25, 2010: received issue

Issue 15312: Issue on UML 2.3 - Use of isAbstract for Interfaces (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Use of isAbstract for Interfaces

-------------------------------------

 

Section 7.3.24 of Superstructure states: “Because an interface is merely a declaration it is not an instantiable model element; that is, there are no instances of 

interfaces at run time.”

And also: “An interface cannot be directly instantiated. Instantiable classifiers, such as classes, must implement an interface”

.

 

This would imply that isAbstract (inherited from Classifier) must be true. However there is no constraint to this effect on Interface. Furthermore none of the notation examples show the Interface name in italics.

This is an issue for the Model Interchange Working Group


Resolution:
Revised Text:
Actions taken:
June 28, 2010: received issue

Issue 15315: Aggregation missing from Property string syntax (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The syntax for property strings (defined using BNF in Notation section of 7.3.44) does not include the ability to specify aggregation of shared or composite.


Resolution:
Revised Text:
Actions taken:
June 29, 2010: received issue

Issue 15400: Nasty UML 2.x Issue - /qualifiedName is not unambiguous (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
qualifiedName is not unambiguous

 

Section 7.3.33 states:

 “A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces.” And the description of the property has: “A name that allows the NamedElement to be identified within a hierarchy of nested Namespaces.”

Constraint [2] describes the derivation of /qualifiedName which makes use of the names of the containing namespaces.

 

However the use of isDistinguishableFrom in the constraint for Namespace, which allows the names to be the same but the types different, means that the name alone may not unambiguously identify either the element or its namespaces.

 

It seems that we have the following options:

-          Remove the notion of type from isDistinguishableFrom and insist on the names being different

-          Somehow include the type/metaclass in the qualified name (which I think we can do without needing a qualified name for the type itself – since UML has a flat namespace – but it could cause problems for profiles or other metamodels)

-          Drop the idea that the qualified name allows unambiguous identification. Which would be a shame. And might affect it being marked as {id} as per the recent issue resolution

 

BTW the OCL for the derivation of /qualifiedName uses union() to construct it: however AFAIK this will not result in a String.


Resolution:
Revised Text:
Actions taken:
August 5, 2010: recerived issue

Issue 15421: UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling (uml2-rtf)

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 14.4 that describes Interaction diagrams, there are statements describing interaction overview diagrams that is highly misleading and which, in my consulting experience with numerous UML users, have been the source of much misunderstanding:

"Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions"

as well as:

"Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams"

While there is indeed syntactic similarity between the two forms (e.g, with fork and join nodes), the underlying semantics between the two diagrams are quite different. For instance, activities, by definition, fully complete their execution before passing control/data tokens to their successors (as defined by the token passing rules), whereas this does not hold in general for interaction uses (the blocks in an overview diagram). In fact, while one object/lifeline could still be completing its business in one interaction use block (so to speak), its collaborating peer could already have entered a successor block. That is, in general, there is no implicit synchronization between lifelines when entering and exiting the blocks in an overview diagram. (Far too many users assume this type of synchronization, resulting in erroneous or unimplementable model specifications.)

There are numerous other semantic differences between Interactions and Activities (e.g., the latter include the notion of pins, control and data flow tokens, etc., while the former do not have any such notions), which further invalidate the claim that one is a special variant of the other. Finally, the metamodels underlying the two diagrams are completely different To summarize: Interaction Overview diagrams are NOT a specialization or variant of Activity Diagrams.

The solution to this problem is not just to remove the two misleading statements, but to also add an explanation that explicitly points out the differences between the two, so that readers are not misled by the similarity in notations.


Resolution:
Revised Text:
Actions taken:
August 19, 2010: received issue

Discussion:


Issue 15440: Issue on UML 2.4 - notation for Component::provided (uml2-rtf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 8.3.1 and Table 8.4 there are several examples of nation claiming to show ‘provided interface’ for a Component.

However Component::provided is a derived property – with many base properties on which it is based.

 

Hence it seems completely un-obvious what a tool is supposed to store/export if a user draws one of these diagrams. Or is it intended that users not be allowed to draw them at all, but invoke a query (in some manner rightly not covered by the UML spec) to cause the ‘provided’ line (and possibly related elements) to be displayed?

A further problem is that the ‘provided’ notation is identical to the ‘provided interface’ notation documented in section 7.3.24. And Table 8.1 makes reference to 7.3.24 for the notation although it uses the different term ‘implements’.

 

Therefore it seems that the notation should be separated from the derived property, with the notation retained for simple realizedInterfaces  – either by removing the term ‘provided’ from the description of the diagrams or renaming the property to be more descriptive

Resolution:
Revised Text:
Actions taken:
August 30, 2010: received issue

Issue 15449: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. 


Two group of proposed changes were removed from 14977.


The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274
Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf


The second group involves associations that are under-specified in the sense that each association:
- does not own any end (i.e., both ends are navigable according to 7.3.45)
- none of the ends subset/redefine ends of another association that has semantic directionality


The criteria for an association to have semantic directionality is:
a) one end is navigable; the other isn't
b) one end is composite; the other isn't
c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't
d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0)
e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0)


Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any.


In UML2.4, there are 9 associations that fail all of (a) through (e):
[qvto:transformation]  A_containedEdge_inGroup
[qvto:transformation]  A_containedNode_inGroup
[qvto:transformation]  A_covered_coveredBy
[qvto:transformation]  A_edge_inPartition
[qvto:transformation]  A_generalizationSet_generalization
[qvto:transformation]  A_inInterruptibleRegion_node
[qvto:transformation]  A_inPartition_node
[qvto:transformation]  A_predecessorClause_successorClause
[qvto:transformation]  A_subject_useCase


19 associations satisfy (a), (b), (c) but fail either (d) and (e):


[qvto:transformation]  A_before_toAfter
[qvto:transformation]  A_classifier_templateParameter_parameteredElement
[qvto:transformation]  A_connectableElement_templateParameter_parameteredElement
[qvto:transformation]  A_end_role
[qvto:transformation]  A_extension_metaclass
[qvto:transformation]  A_incoming_target_node
[qvto:transformation]  A_incoming_target_vertex
[qvto:transformation]  A_inputElement_regionAsInput
[qvto:transformation]  A_interruptingEdge_interrupts
[qvto:transformation]  A_method_specification
[qvto:transformation]  A_operation_templateParameter_parameteredElement
[qvto:transformation]  A_outgoing_source_node
[qvto:transformation]  A_outgoing_source_vertex
[qvto:transformation]  A_outputElement_regionAsOutput
[qvto:transformation]  A_parameterSet_parameter
[qvto:transformation]  A_parameteredElement_templateParameter
[qvto:transformation]  A_powertypeExtent_powertype
[qvto:transformation]  A_submachineState_submachine
[qvto:transformation]  A_toBefore_after


All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association).


The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end.

Resolution:
Revised Text:
Actions taken:
September 8, 2010: received issue

Issue 15451: Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Currently, the prevalent use of property subsetting/redefinition mechanism has been confined to a pairs of properties defined within a single artifact (e.g., metamodel, user model, ....) In principle, the specification allows using this mechanism even for a pair of properties where the subsetted/redefined property is defined in one artifact (e.g., a metamodel) and the  subsetting/redefining property is defined in another artifact (e.g., a profile extending the metamodel). This flexibility could be useful in practice -- e.g., see some of the proposed changes for SysML1.3 here: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:9_ports_and_flows.


The specification does not explicitly discuss what is the semantics of subsetting/redefinition when the subsetted/redefined property is in a different artifact, potentially at a different level than the artifact where the subsetting/redefining property is defined.


Combinations of subsetted/redefined property vs. subsetting/redefining property could include:
- metamodel/profile
- profile/profile
- library/profile

Resolution:
Revised Text:
Actions taken:
September 8, 2010: received issue

Issue 15485: UML 2 issue: connectors typed by Association Class (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:
Multiple tool vendors have failed to implement support for a Connector that has a type of an AssociationClass.  This may be partly due to the fact that Connector (9.3.6) doesn’t explicitly describe this variation under type.  Nor does any example show this use.  I would expect that the properties/methods of Connector that has a type of an AssociationClass to be represented similarly to representation of an AssociationClass between Classes.

Resolution:
Revised Text:
Actions taken:
September 10, 2010: received issue

Issue 15763: No Constraint for multiple associations (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Antonio Petri, antonio.petri(at)oracle.com)
Nature: Clarification
Severity: Minor
Summary:
There isn't a constraint that prevents multiple associations from being specified between the same Actor and Use Case. Multiplicity is handled already by the multiplicity at the association's ends, so having two or more different associations seems to be redundant.

Resolution:
Revised Text:
Actions taken:
October 19, 2010: received issue

Discussion:


Issue 15788: UML 2.3 Infra 12 Incomplete conformance for infinity (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:
Issue 15780 for OCL suggests resolving the inconsistent definition of
UnlimitedNatural
by defining '*' infinity (and '-*' minus infinity) as valid Integer and Real
values.


This is appropriate to resolve the anomally that


Integer conformsTo Real so any Integer is a valid Real,
UnlimitedNatural conformsTo Integer so any UnlimitedNatural is a valid
Integer 


except that at present '*' is a valid UnlimitedNatural without a valid
Integer
or Real counterpart.


The resolution of Issue 14196, introducing UnlimitedNatural to the OCL
specification, indicates that any use of UnlimitedNatural '*' as an Integer
or Real requires a conversion to invalid. This imposes an undesirable
implementation burden in addition to the anomalous conformance behaviour.


Therefore please add '*' (and '-*') to Integer and Real.


Resolution:
Revised Text:
Actions taken:
October 27, 2010: received issue

Discussion:


Issue 15823: Part document structures in Superstructure need to conform to ISO standard Document Template Conventions (uml2-rtf)

Click
here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, trutt(at)us.fujitsu.com)
Nature: Revision
Severity: Minor
Summary:
Title: Part document structures in Superstructure need to conform to
ISO standard Document Template Conventions
Category: Editorial

Nature of Problem

UML 2.3 RTF resolved ISSUE 14296 as follows:
“
“
Summary:
This is a multipart standard, use of "Part I, II, III" make confusion.
Delete Part III and Make others rewrite as clauses. 7. General
Introduction, 10 Infrastructure Library, and renumber other clauses.
Also, delete Part III page.
Resolution:
Agree to change word “Part” to “Sub Part” throughout document.
“

PTC/9-9-08 , the UML 2.3 Superstructure convenience document has the changes of the
tem “Part” to “Subpart”, as per the resolution to ISSUE


However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

Also, ISO document templates do not allow hanging text.

The introductory text for each is not in any numbered clause.

Proposed Resolution:

Change term “Part” to “Subpart”, as in PTC/9-9-8.


Add a new section

6.4.3 Contents of Subparts

6.4.3.1 Contents of Subpart I ­ Structure

<move the hanging intro from Part I into this subclause, with minor edits to fix pointers
to sections>

6.4.3.2 Contents of Subpart II ­ Behaviour

<move the hanging intro from Part II into this subclause, with minor edits to fix pointers
to sections>

6.4.3.3 Contents of Subpart III- Supplement

<move the hanging intro from Part III into this subclause,>

6.4.3.4 Contents of Subpart IV - Annexes

<move the hanging intro from Part IV into this subclause,>

Resolution:
Revised Text:
Actions taken:
November 22, 2010: received issue

Discussion:


Issue 15849: Creation of an expansion node under an activity is allowed by UML and SysML specifications (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Which semantic for an expansion node owned by an activity (instead an expansion region)?


According OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Chapter 12.3.26


An expansion node is an object node used to indicate a flow across the boundary of an expansion region.


An expansion region is a structured activity region that executes multiple times corresponding to elements of an input collection. This specific structured activity node is using expansion node as input and output. From outside the expansions regions the elements of expansion nodes only appear as a collections, the elements of collection are only accessible from "inside the collection".


Semantic of an expansion node owned by an expansion region is then well defined. However, in abstract syntax nothing prevents to create an expansion node owned by an activity instead of an expansion region. In this case semantic is questionable.
If this kind of construction is not expected, a specific constraint should be added in UML specification in order to prevent an activity to owned expansion nodes. On the contrary, if this construction allowed, associates semantic should be defined.

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

Discussion:


Issue 15850: Restrictions on decision nodes (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I’m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and

1)      If the Object flow is good, the object flow is then passed to a downstream activity 

Or

2)      If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error

 

I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision. 


Resolution:
Revised Text:
Actions taken:
November 5, 2010: received issue

Discussion:


Issue 15889: Retationships and composite structures (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML Relationships, Comments and Constraints are unable to deal properly with composite structures that have more than one nested level. For instance: assume a class “A” with two properties “b1” and “b2” both typed by a class B with only one property “p”.  A relationship, a comment or a constraint cannot target specifically A.b1.p and not A.b2.p.

Resolution:
Revised Text:
Actions taken:
December 10, 2010: received issue

Discussion:


Issue 15890: New notation for attribute (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:
Capability to get a modular diagram thanks to the “link notation”
Capability to show the aggregation kind
 
However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.
 
What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?
 

Resolution:
Revised Text:
Actions taken:
December 10, 2010: received issue

Discussion:


Issue 15903: XMI representation of stereotype application (uml2-rtf)

Click
here for this issue's archive.
Source: Universidad Politecnica de Madrid ( Prof. Miguel de Miguel, mmiguel(at)dit.upm.es)
Nature: Uncategorized Issue
Severity:
Summary:
I think that the source of confusion could be the paragraph in page 683 in 10-11-13.pdf

 

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

 

In this paragraph the “XMI based interchange capacities” are mentioned, but there is not

a direct reference to page 684, to clarify that these the “XMI interchange capacities” are specified in 684. This paragraph

gives the impression that the XMI interchange format is not closed.


Resolution:
Revised Text:
Actions taken:
December 17, 2010: received issue

Discussion:


Issue 15930: Tags typed by classes/blocks (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
The UML Superstructure spec states in Subclause 18.3.7 that:

 

“A Profile can define Classes, DatatTypes, PrimitiveTypes and Enumerations as well as Stereotypes since Profiles imports Constructs. However, these types can only be used as the type of properties in the profile, they cannot be used as types in models the profile is applied to since they apply at the meta-model level, not the model level. It is however possible to define these types in separate packages and import them as needed in both profiles and models in order to use them for both purposes. 

 

Stereotypes can participate in binary associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass.”

 

However, the restrictions expressed in this text are not formalized by any constraints. Either OCL should be added to formalize these restrictions, or the restrictions should be removed

Resolution:
Revised Text:
Actions taken:
January 12, 2011: received issue

Discussion:


Issue 15991: Notation of Lifelines (uml2-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Adam Neal, adamneal(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
In UML 2.3, section 14.3.19 (Lifelines), the notation of a lifeline is given as follows:

<lifelineident> ::= ([‘[‘ ‘]’]] [: [decomposition]) | ‘self’ <selector> ::= <expression> <decomposition> ::= ‘ref’ <interactionident> [‘strict’] 

Given a Lifeline has an explicit name, it seems as though its not allowed to be displayed. Does anyone know if there is a specific reason for not showing the name of a Lifeline given it has one?


Resolution:
Revised Text:
Actions taken:
January 26, 2011: received issue

Discussion:


Issue 16116: Package URI Attribute Uses Obsolete RFC 2396 (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
Specification requires URI package attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

Resolution:
Revised Text:
Actions taken:
April 17, 2011: received issue

Issue 16117: Profile URI Attribute - Mingled URI Definition and Use in XMI (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format:
uri = http://profileParentQualifiedName/version/profileName.xmi
When URI is used for XMI, the profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

Resolution:
Revised Text:
Actions taken:
April 17, 2011: received issue

Issue 16118: Metaclass stereotype notion (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
Text says: "A Class that is extended by a Stereotype may be extended by the optional stereotype «Metaclass» ..."
The second "extended" has no sense.
It should say something like: "A Class that is extended by a Stereotype may be denoted by the optional stereotype «Metaclass» ..."

Resolution:
Revised Text:
Actions taken:
April 17, 2011: received issue

Issue 16119: Metaclass stereotype notion (02) (uml2-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
Text says: "The names of Profiles are shown using a dashed arrow with an open arrowhead from the package to the applied profile."
"The names" is not relevant in this context. The arrow is related to profile application.
The text should say something like: "The applied  Profiles are shown ..."

Resolution:
Revised Text:
Actions taken:
April 17, 2011: reeived issue

Issue 16249: State::stateInvariant multiplicity too restrictive (uml2-rtf)

Click
here for this issue's archive.
Source: Northrop Grumman (Mr. Christopher McClure, christopher.mcclure(at)ngc.com)
Nature: Enhancement
Severity: Minor
Summary:
The multiplicity of State::stateInvariant is specified as [0..1].  This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state.  Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc.

Resolution:
Revised Text:
Actions taken:
May 16, 2011: received issue

Issue 16292: Use cases specifying the same subject cannot be associated: exception (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
The UML Superstructure Specification V2.4 states in 16.3.6 UseCase (from UseCases): “Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject.”


For the longest time, this looked like a common-sense rule.  However, it seems to me that in the context of SOA there is at least on exception to this rule.  


Let’s say that:
1.  The subject represents a component (as understood in SOA) and the use cases represent the component’s services.  
2.  The initiating actor of all of the component’s services is Another Use Case.  This reflects the SOA reality that services are not directly consumed by human actors but by other use cases.  
3.  The component offers services A and B, both of which trace back to legitimate uses.
4.  As it happens, when service B is defined in detail it turns out that one of its steps amounts exactly to the functionality represented as service A.


In such situations, where the subject already has a public service (A) that can actually be reused by one or more of its other public services (B), I think it’s entirely reasonable to allow B to be associated with A.  After all, A’s initiating actor is Another Use Case, which is exactly what B is.  In object-orientated terms this amounts to an object performing an operation on itself.


I propose for UML to accommodate this scenario.

Resolution:
Revised Text:
Actions taken:
May 28, 2011: received issue

Issue 16307: A deferrable trigger may have a guard (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
It is an unfortunate restriction to omit guards from the specification of <trigger>/defer.

Please explicitly state or reconsider this restriction since using a guard would simplify many scenarios involving event deferral

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16342: Ambiguous stereotype notation (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Suppose we have a stereotype S extending UML::Class.
We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class.


The UML notation for stereotype allows showing applications of S as <<S>> but this notation does not clearly show what kind of element the element is.
In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous.


The UML notation could be extended to show optionally the metaclass of an element, e.g., <<S>> [Class] vs. <<S>> [Activity] vs. <<S>> [StateMachine].


Proposed resolution:


in clause 18.3.9, Stereotype, under notation, change:


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 or before the name of the model 
element, or where the name would appear if the name is omitted or not displayed. For model elements 
that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes 
can be displayed within a pair of guillemets near the upper right corner of the graphical representation. 
If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list 
with a pair of guillemets. 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»). 


to:


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 or before the name of the model 
element, or where the name would appear if the name is omitted or not displayed optionally followed by the name of the
model element's metaclass within a pair of square brackets. For model elements 
that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes 
can be displayed within a pair of guillemets near the upper right corner of the graphical representation optionally 
followed by the name of the model element's metaclass within a pair of square brackets.
If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list 
with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword,
  within separate guillemets (example: «interface» [Interface], «Clock» [Class]). 

Resolution:
Revised Text:
Actions taken:
June 22, 2011: received issue

Issue 16350: Navigability orthogonal to end ownership or not? (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
At one point (page 42) the specification reads:
"Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation."


The same thought can be found here: http://www.omg.org/issues/issue15128.txt :
"... an old constraint from UML 1.x when navigability meant the same as ownership of property"


However at another place (page 38) the specification reads:
"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."


So is navigability orthogonal to end ownership or not? I think that the specification is somewhat unclear concerning these issues.

The descriptions of ownedEnd and navigableOwnedEnd don't clarify much and seem to be too brief.

Resolution:
Revised Text:
Actions taken:
June 28, 2011: received issue

Issue 16357: UML: unification of OCL declarations (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:
UML supports declarations of elements with multiplicity bounds; OCL does not
OCL supports declarations of nested collections; UML does not


A possible unification of the capabilities/syntaxes could be achieved by UML introducing Bag/OrderedSet/Sequence/Set as alternatives for {ordered,unique} etc and OCL adopting <> brackets and multiplicity qualification.


Concrete Syntax
-----------------------


The syntax is not obvious


All of Set<Type[0..5]> or Set<Type>[0..5] or Set<Type : 0..5> or Set[0..5]<Type> could be a bounded Set.


All of Set<Set<Type[0..5]>[0..5]> or Set<Set<Type>[0..5]>[0..5] or Set<Set<Type : 0..5>: 0..5> or Set[0..5]<Set[0..5]<Type>> could be a 2D bounded Set.


Set[0..5]<Set[0..5]<Type>> seems to best localize the multiplicity for the collection-type.


Abstract Syntax
----------------------


UML embeds its 'collection' declaration in a MultiplicityElement, which doesn't scale to nested collections. MultiplicityElement is a nuisance for OCL since it provides an alternate form of collection declaration to the CollectionType type constructor. A unified behaviour could deprecate MultiplicityElement and introduce a CollectionType type constructor with ordered, unique, lower, upper in addition to signature attributes.


Nullable Unit Collection Semantics
-----------------------------------------------


So far so good, but there is an OCL semantic issue that is exposed by a compatibility conversion of MultiplicityElement.


Currently MyType[0..1] is a nullable non-collection, so an OCL navigation of an unspecified value gives a null, which crashes any navigated collect iteration such as a->collect(b)->collect(c). A crash on a null  object is confusing with respect to an empty collection for which iterations just skip the empty. Deprecating MultiplicityElement would convert MyType[0..1] to Set[0..1]<MyType>; clearly a collection not an object, which avoids the value-dependence that a MultiplicityElement that happens to have a unit upper bound is not a Collection. There is now no way to express a nullable object, so perhaps a { nullable } constraint can be supported. This restores the semantic coverage and conversion compatibility: [1] is ignored, [0..1] is treated as {nullable} and other multiplicities become correspondingly bounded collections. This also has the benefit that ordered and unique would cease to have any relevant semantics for non-collection objects thereby eliminating OCL's dilemma as to whether a [1] { ordered, unique } should be converted to a unit OrderedSet rather than a unit Set by the -> operator.


However, we can now wonder what the difference is between MyType{nullable} and Bag[0..1]<MyType> and why modelers should prefer one or the other. A difference is that in OCL a->collect(b)->collect(c) will crash if b is a null MyType{nullable} whereas it will skip over a null for the empty collection. This seems really bad; a collect over a structurally valid model crashes. But is this OCL just throwing a problem over the fence to UML? Perhaps the problem is that OCL 2.3 has still not resolved the distinct semantics of null and invalid. Perhaps, since OclVoid conforms to all types, null has null/empty values of all properties with a 0 lower bound. Therefore null.oclAsType(NamedElement).name could be null rather than invalid, and so a->collect(b)->collect(c) should crash on invalid structures, but return a result including interspersed nulls for intermediate collects at null nullable elements.


So the difference between MyType{nullable} and Bag[0..1]<MyType> is that:


MyType{nullable} is what modelers will normally use. It is an object that may be null and always participates in an iteration as exactly one value, which may be null which may in turn participate in strucyurally valid iterations.


Bag[0..1]<MyType> is a clumsy but consistent alternative. It is a unit collection that may be empty and only participates in an iteration when not empty.


Resolution:
Revised Text:
Actions taken:
July 8, 2011: received issue

Issue 16484: UML Appendix A: After Figure A.4 (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
There is a list of possible namespaces that are suitable for appearing in the package header (containing • activity • class • component • deployment • interaction • package • state machine • use case)

 

It seems to me that there are other possible namespaces that could be diagramed. For example

Model, Node, Datatype, etc.


Resolution:
Revised Text:
Actions taken:
August 2, 2011: received issue

Issue 16567: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
SysML 1.3 -- http://www.omg.org/cgi-bin/doc?ptc/2011-08-10 -- is defined as an extension of UML 2.4.1
What is the XMI serialization of applying the profile to a UML 2.4.1 Package?


The XMI serialization of the application of a profile in UML 2.4.1, section 18.3.7, was written at a time when UML2.0 required Stereotypes to be directly contained in a Profile. UML 2.3 relaxed this. According to the Stereotype semantics defined in UML 2.4.1 (18.3.9), a Stereotype may be contained in a Profile or a Package which defines the namespace for the Stereotype.


The XMI serialization in 18.3.7 is defined by a contrived example where a Stereotype is directly contained in its Profile (see Figs. 18.8, 18.9). SysML 1.3 has several nested packages (see Fig 4.3 in SysML 1.3) Neither UML 2.4.1 nor XMI 2.4.1 clearly address how the serialization of the application of Package-nested Stereotypes works.


For SysML 1.3, the XMI published for the SysML profile itself looks like this:


<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
         xmlns:mofext="http://www.omg.org/spec/MOF/20110701"
         xmlns:uml="http://www.omg.org/spec/UML/20110701">
   <uml:Profile URI="http://www.omg.org/spec/SysML/20110919/SysML" xmi:type="uml:Profile"
                xmi:id="_OMG_SysML_20110919_SysML__0"
                name="SysML"
                visibility="public">
...
      <packagedElement xmi:type="uml:Package" xmi:id="_OMG_SysML_20110919_SysML_Blocks" name="Blocks">
...
         <packagedElement xmi:type="uml:Stereotype" xmi:id="_OMG_SysML_20110919_SysML_Blocks-Block"
                          name="Block">
...
         </packagedElement>
...
      </packagedElement>
   </uml:Profile>
   <mofext:Tag xmi:type="mofext:Tag" xmi:id="_OMG_SysML_20110919_SysML__2"
               name="org.omg.xmi.nsPrefix"
               value="SysML"
               element="_OMG_SysML_20110919_SysML__0"/>
</xmi:XMI>


Given the fact that, per the MOF/XMI 2.4.1 specification, only the toplevel UML Package Namespace maps to an XMI Document Namespace,
it follows that nested UML Package Namespaces have no corresponding XML Namespace declaration.


This means that SysML's Blocks Package cannot have any XML Namespace declaration per current MOF/XMI 2.4.1 rules.
Therefore, the only possible serialization for this example is the following:


<xmi:XMI 
        ....
        xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
        ....
        >
    <uml:Package name="A" ........>
    ....
        <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:_OMG_SysML_20110919_SysML_Blocks-Block base_Class="123" xmi:id="456" ... />
    ....
</xmi:XMI>


This particular serialization may be surprising to some who might have expected:


<xmi:XMI 
        ....
        xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
        ....
        >
    <uml:Package name="A" ........>
    ....
        <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:Block base_Class="123" xmi:id="456" ... />
    ....
</xmi:XMI>


The familiar-looking XMI serialization assumes that all UML CLassifiers in scope of a Profile have unique XMI:id values. The reason is very subtle but it is a consequence of the fact that the MOF/XMI specification maps only the toplevel UML Namespace into a corresponding XML Namespace declaration -- i.e., a toplevel UML::Model/Package/Profile has a corresponding XML Namespace declaration & prefix; nested UML Namespaces do not!


This means that the UML Namespace distinguishability criteria that suffices for ensuring UML NamedElements are distinguishable within the same UML Namespace
is insufficient to guarantee that the *XMI* encoding of such UML NamedElements will be also distinguishable in the scope of their containing XML Namespace!


For SysML 1.3, I specifically used an unconventional XMI:id generation algorithm that encodes the fully qualified path (name/metatype/linearized collection order) of each UML Element so as to ensure that each XMI:id Element in the scope of an XMI document is distinguishable within that document.


Resolution:
Revised Text:
Actions taken:
September 27, 2011: received issue

Discussion:


Issue 16569: Relation of message arguments to signature parameters ambiguous (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
In section 14.3.18, the constraints 3 and 4 say that the arguments of message must correspond to the parameters/properties of the signature (operation/signal). This leads to an ambiguous siuation in some situations. For example:


Let's assume there is an operation with the following signatur op1(x:String[*], y:String[*]) or a Signal S with two properties
S::p1 : String[0..1]
S::p2 : String[0..1]


Since there is no direct relationship between an argument and a parameter/property it is not possible to determine what argument belongs to the first parameter/property (list in case opf operation example) and what to the second one.


This problem always occurrs when two parameters/properties of the same type are specified in a sequence and the first one has either an optional multiplicity or an upper bound equals *.


A possible solution is to introduce an additional metaclass MessageArgumentSpecification, which should be contained by Message instead of ValueSpecification directly, with the following structure:


MessageArgumentSpecification{
   refersTo: TypedElement [1] {where the    referenced TypedElement is either an instance of parameter or property}
   arguments : ValueSpecification [1..*] {ordered}
}

It might be also considerable to keep the association between a referenced element and an argument bilateral. In this case, the association between Message and MessageArgumentSpecification should be ordered.

Resolution:
Revised Text:
Actions taken:
September 29, 2011: received issue

Issue 16570: Message arguments for a Signal signature too restrictive (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Minor
Summary:
Constraint 4 of Message in section 14.3.18 requires that in case of a Signal signature, the arguments of the message must correspond to the properties of the Signal.


We found this constraint too restrictive. A Signal is a classifier, hence it is possible to create an InstanceSpecification for the Signal. A InstanceSpecification can be referenced by an InstanceValue (ValueSpecification) from within the message argument list. 


We suggest to weaken the first sentence of constraint 4 a little from :


In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the 
Signal.


to


In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the 
Signal, or to the Signal itself.

Resolution:
Revised Text:
Actions taken:
September 29, 2011: received issue

Issue 16571: Message arguments should not be contained in a message (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Minor
Summary:
Figure 14.4 - Messages in the spec depicts that arguments of a message are contained in that message. This containmentship is not necessary and in many cases counterproductive.


The containment prevents ValueSpecifications for being reused in multiple messages. Instead, the very same ValueSpecification must be created in each message.

Since ValueSpecification is a PackageableElement, there is no problem in making the association between Message and ValueSpecification a non-containment association.

Resolution:
Revised Text:
Actions taken:
September 29, 2011: received issue

Issue 16572: OccurrenceSpecification should have at least an optional notation (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Significant
Summary:
Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.


For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:


1. Create an Action and let it being contained by the Interaction
2. Configure that Action and apply the corresponding stereotype
3. Create the ActionExecutionSpecification
4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
6. Link the ActionExecutionSpecification with the Action


The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).


Since UML 2.4, the steps are reduced to the following one:
1. Create an OccurrenceSpecification on a lifeline
2. Apply a stereotype to the OS and configurethe OS


The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.


The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation. 


Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.

Resolution:
Revised Text:
Actions taken:
September 29, 2011: received issue

Issue 16658: The included use case is always required for the including use case to execute correctly (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
In the 'Descriiption' section of chapter '16.3.5 Include (from UseCases)' there is a sentence: 
'Note that the included use case is not optional, and is always required for the including use case to execute correctly.'


Interpretation of ‘include’ relationship, implying that it’s usage is valid only if included UC is obligatory for including UC to execute correctly, 
is probably the source of opinion, that the only way to model conditional parts of UC scenario using external UC, is by using ‘extend’ relationship.


I find such conclusion in many books dealing with analysis/UML, for instance: ' Business Analysis’, page 188 (ISBN-10: 1906124612,ISBN-13: 978-1906124618).


As a result the difference in aplicability between ‘include’ and ‘extend’ relationship is stressed almost only based on conditionallity of relationship between UC.


In my opinion it’s valid to use ‘include’ relationship when pointing to another UC, that won’t be executed every time the base UC does. 
It’s just the internal logic of base UC scenario, that decides if it’s appropriate to call external UC or not. 
And if we depend only on result of an external UC, we should use ‘include’ relationship (so most of the time), while when there is a need to introduce its logic we should use ‘extend’ relationship.


I think, that the sentencje:
'Note that the included use case is not optional, and is always required for the including use case to execute correctly' 
should be removed or clarified, because if forces analysts to use mostly (if not only) an ‘extend’ relationship, that is far more complicated to use and time consuming to document than ‘include’.

Resolution:
Revised Text:
Actions taken:
November 10, 2011: received issue

Issue 16897: Abstraction::mapping should be of type ValueSpecification or OpaqueExpression (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Minor
Summary:
In many cases, modeler would like to specify the mapping of an Abstraction on an informal level by just providing a LiteralString or OpaqueExpression describing the mapping in a natural language. 


The necessity to use an Expression is for this kind of usage of this feature cumbersome and clunky.

The resolution could be to use a more common metaclass of Expression, i.e. ValueSpecification, to provide the highest level of flexibility to the modeler, how mappings can be specified.

Resolution:
Revised Text:
Actions taken:
December 14, 2011: received issue

Issue 16999: UML 2.4/2.5 Aliases (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
There is no capability in UML for giving an element an alternate name (an alias) within the package that defines it.


Resolution:
Revised Text:
Actions taken:
January 17, 2012: received issue

Issue 17096: Concerning Transition and its owned elements (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
is there a reason why a transition's effect and triggers of a state machine transition (section 15.3.14 in UML 2.4, respectively section 14.5, subsection Transition in UML 2.5 initial submission) do not belong to the transition's namespace as members? Both simply subset ownedElement. In contrast, a transition's guard subsets Namespace:ownedRule, which made me think the former ones ought to subset Namespace:onwedMember in lieu of Element:ownedElement as well.

I roughly flicked through the open issues of UML, but did not find anything related to this question. So, if there was not decided deliberately, I would open an issue for that

Resolution:
Revised Text:
Actions taken:
February 4, 2012: received issue

Issue 17226: Message Signature in Interactions and Reception.ownedParameter (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
currently (till 2.5) a message's signature is of type NamedElement that
resolves either to an Operation or Signal. Apart from the fact that the
nearest common superclass is Namespace, the use of elements of different
inheritance hierarchies makes it cumbersome/impractical to work with the
signatures easily. You always have to check what concrete signature is
associated, cast it into the appropriate subclass (i.e. either Signal or
Operation) and use it further.


Regarding Message::Signature, I was wondering, whether it wouldn't be
simpler and far more consistent to refer to a BehavioralFeature
(Operation/Reception which has to have an Signal associated) directly
instead of NamedElement (which ought to be Namespace)?


This leads to a situation where I was wondering why a Reception, though
it is a BehavioralFeature, does not say any word about owned parameters
at all? However, if Receptions would be able to capture information
about parameter, too, the treatment of Reception and Operation would be
pretty much the same with regard to their parameter semantics. So, it
might be worth to reconsider the relationship between BehavioralFeature,
Reception and Parameter. We could supplement


BehavioralFeature::ownedParameter {ordered, subsets
Namespace::ownedMember} containment


with


/Reception::ownedParameter [0..1] {redefines
BehavioralFeature::ownedParameter } containment


The derivation algorithm of Reception::ownedParameter could be similar
to the following: A Reception declares at most one Parameter. Its type
and name must exactly the name and type of the Signal, referenced by
Reception::signal, if present. The direction kind of a Reception's
Parameter must be set to IN exclusively.


context Reception
inv 'parameter':
if not self.signal.oclIsUndefined then
        not self.ownedParameter.oclIsUndefined and
self.ownedParameter.type = self.signal and self.ownedParameter.name =
self.signal.name and self.ownedParameter.directionKind ==
ParameterDirectionKind::IN
else
endif


This would ease the usage of BehavioralFeatures a lot, I'd say. In case
of Messages, one would only have to walk over
Message::signature::parameter instead of casting it down to either an
Operation or Signal..


Resolution:
Revised Text:
Actions taken:
March 12, 2012: received issue

Issue 17315: Interaction.action should subset ownedMember in lieu of ownedElement (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Minor
Summary:
In Figure 14.5 of UML 2.4.1 (and still valid for UML 2.5), the association end 'action' of Interaction subsets Element.ownedElement. Since Interaction is a Namespace and Action a NamedElement, I reckon it ought to subset Namespace.ownedMember instead.

Resolution:
Revised Text:
Actions taken:
April 19, 2012: received issue

Issue 17390: Migrate UML::Component's ability to own UML::PackageableElements to UML::Class (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:


UML::Component::packagedElement : UML::PackageableElement { subsets UML::Namespace::ownedMember }


This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.


As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:


UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.


Unfortunately,  other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).


Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:


1) nested UML::Profiles and UML::ProfileApplications
2) specialization of a general classifier nested within its packagedElements
3) applying a stereotype defined in a UML::Profile nested within its packagedElements
4) the target of an elementImport from a UML::Namespace nested within its packagedElements

Resolution:
Revised Text:
Actions taken:
May 22, 2012: reeived issue

Issue 17393: Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Currently, UML 2.4.1 requires that:
The graph of classifier generalization relationships must be acyclic
See 7.3.8 Classifier [2]


Generalization hierarchies must be directed and acyclical. A classifier cannot be both a transitively general and
transitively specific classifier of the same classifier.


This constraint probably came from the influence of programming languages on the design of the UML.
This constraint is certainly useful in many domain-specific applications of the UML but it is certainly not useful across all domains.
For example, in ontologies, it is common practice to use circular generalization relationships among classifiers to express their semantic equivalence; see: http://www.w3.org/TR/owl2-syntax/#Equivalent_Classes
The ODM 1.0 includes this approach as an option for using the UML as a notation for OWL1 ontologies — see 14.2.5.11 in http://www.omg.org/spec/ODM/1.0/
A generalization must be owned by the specialized classifier
See 7.3.20:


specific: Classifier [1]
References the specializing classifier in the Generalization relationship. Subsets DirectedRelationship::source and
Element::owner


This ownership constraint prevents using the UML where a generalization between A and B needs to be added without modifying A or B.

Resolution:
Revised Text:
Actions taken:
May 23, 2012: reeived issue

Issue 17464: Link notation for stereotype property value (uml2-rtf)

Click
here for this issue's archive.
Source: Atego (Mr. Simon Moore, simon.moore(at)atego.com)
Nature: Enhancement
Severity: Significant
Summary:
It would be very useful if a notation was defined to allow a stereotype instance property value which references another instance in the model to be shown as a link on a diagram.


For example, a stereotype Foo could have a property Bar of type Foo (in order that one Foo can reference another Foo). On a diagram showing two instances of Foo, you could then add and show a link between them labelled Bar rather than only being allowed to use a compartment or callout note.

This would be useful to many profiles, but I couldn't find an existing issue which covered it.

Resolution:
Revised Text:
Actions taken:
July 2, 2012: received issue

Issue 17536: Specifying the multiplicity of a part with an attribute (uml2-rtf)

Click
here for this issue's archive.
Source: Lockheed Martin (Mr. John Watson, john.watson(at)lmco.com)
Nature: Clarification
Severity: Minor
Summary:
This is a request to add a capability in UML to specify the upper and/or lower multiplicity value of a part (composite aggregation relationship) with a class attribute of type integer; typically this attribute is a derived attribute. When derived, a constraint can be used to define the value derivation.


This capability has been found to be useful in the following applications. 
1.      When reference models are re-used in different contexts this capability allows some variants to be specified in the reference model and the value be automatically derived based on its use in the new context.  
2.      The value of the multiplicity to be used for a specific configuration may be derived through an analysis performed external to the model.
 
A diagram is available that shows an example of the concrete syntax that could be used. In this example a constraint is defined for the attribute “numberOfPedals”. If this diagram would be helpful and I can forward it.  I did not see a means of attaching a jpg diagram to this on-line form.  
This capability can be developed in a way that does not impact on code generation or execution, as the values can all be constant at run time (and at code-generation time). 
The primary purpose of this is to allow the ability to have reference models for variations without using the overhead of templates (otherwise the whole model might need to be a template of template, which would certainly be unwieldy and confusing), and to allow for a common way of specifying this for descendant languages like SysML.

Resolution:
Revised Text:
Actions taken:
August 2, 2012: received issue

Issue 17564: applying and associating stereotypes and explanation of all aspects of their serialization (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
UML needs to explain in terms of UML what applying and associating
 stereotypes means and additionally needs to explain all aspects of their
 serialization. The UML specification has yet to explain what it means what "applying a stereotype" and what "stereotypes can participate in associations" mean in terms of UML.


Since the UML profile mechanism is definitely not a metamodeling extension facility, these explanations must be made in terms of UML directly rather than indirectly via the "MOF2-equivalent semantics".


Below is a 3-step proposal to explain what "applying a stereotype" and "stereotypes can participate in associations" mean in terms of UML.
This proposal is illustrated using the SysML profile definition of the ValueType, Unit and QuantityKind stereotypes shown below:











Point #1) The UML specification only shows how an instance of a stereotype is serialized but it does not say what that serialization is in terms of the UML metamodel.


For example, we have:


- 2 serializations of UML::InstanceSpecification



      <packagedElement xmi:type="uml:InstanceSpecification"

                       xmi:id="_ISO-80000-1-SysML_mass_PackageableElement"

                       name="mass">





      <packagedElement xmi:type="uml:InstanceSpecification"

                       xmi:id="_ISO-80000-1-SysML_kilogram_PackageableElement"

                       name="kilogram">



- 2 serializations of instances of stereotypes, QuantityKind and Unit.




   <sysml:QuantityKind xmi:id="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance__InstanceSpecification"

                       base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>





   <sysml:Unit xmi:id="_ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance__InstanceSpecification"

               base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

               quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

               symbol="kg"/>




I claim that serializations of instances of stereotypes are in fact just serializations of UML::InstanceSpecifications whose classifiers are stereotypes.

That is, the above two elements are really a different serialization of the following:





   <packagedElement xmi:id="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance__InstanceSpecification"

xmi:type="uml:InstanceSpecification"

classifier="_SysML_Blocks_PackageableElement-QuantityKind_PackageableElement" 
                base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>





   <packagedElement xmi:id="_ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance__InstanceSpecification" 

               xmi:type="uml:InstanceSpecification"

               classifier="_SysML_Blocks_PackageableElement-Unit_PackageableElement"


               base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

               quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

               symbol="kg"/>




The rationale for this is simply that we must be able to specify constraints in OCL as well as queries/transformations in QVT and actions in any action language (e.g., ALF) where we can operate on instances of stereotypes without having to implement profile-specific tooling.




Point #2) The UML specification should explicitly say that:




2.1) an instance of a stereotype is a distinguished instance of UML::InstanceSpecification whose classifier is the stereotype definition


2.2) what distinguishes an UML::InstanceSpecification whose classifier is a UML::Stereotype is that it is serialized differently than any other UML::InstanceSpecification (whose classifier is not a UML::Stereotype)


The rationale for (2.1) is that this is the simplest way to address this point without introducing a new metaclass in the UML metamodel.
The rationale for (2.2) is that we need a way to tell how to serialize any UML::InstanceSpecification, whether it is an instance of a stereotype or something else.


Point #3) The meaning of "stereotypes can participate in associations" is that it is possible to create link instance of such an association (i.e., a UML::InstanceSpecifications) and that the slots of this link instance refer to the distinguished UML::InstanceSpecifications corresponding to the instances of the stereotypes related via such a link.


The problem is that the UML specification (2.4 and 2.5) does not say how to serialize such links.


This is something that caused me a lot of headaches when producing the XMI for SysML 1.3.
Because the ISO-80000-1-SysML.xmi and ISO-80000-1-QUDV.xmi are libraries, there will be references to elements defined in them.
Since the SysML profile has associations between Unit & QuantityKind, it means that we should be able to externally refer to particular links between particular instances of Unit & QuantityKind.


I tried to do this in 1.3 but I realize that I got it wrong, specifically, the slot values refer to the UML elements representing Unit and QuantityKind when in fact they should be referring to the distinguished UML::InstanceSpecifications representing the instances of Unit & QuantityKind (see in bold below):


      <packagedElement xmi:type="uml:InstanceSpecification"

                       xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

                       name="a_kilogram[unit]_mass[quantityKind]">

         <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

         <slot xmi:type="uml:Slot"

               xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

            <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

            <value xmi:type="uml:InstanceValue"

                   xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value__ValueSpecification.0"

                   instance="_ISO-80000-1-SysML_kilogram_PackageableElement"/>

         </slot>

         <slot xmi:type="uml:Slot"

               xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

            <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

            <value xmi:type="uml:InstanceValue"

                   xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value__ValueSpecification.0"

                   instance="_ISO-80000-1-SysML_mass_PackageableElement"/>

         </slot>

      </packagedElement>




These should have been:


      <packagedElement xmi:type="uml:InstanceSpecification"

                       xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

                       name="a_kilogram[unit]_mass[quantityKind]">

         <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

         <slot xmi:type="uml:Slot"

               xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

            <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

            <value xmi:type="uml:InstanceValue"

                   xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value__ValueSpecification.0"

                   instance="_ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance__InstanceSpecification"/>

         </slot>

         <slot xmi:type="uml:Slot"

               xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

            <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

            <value xmi:type="uml:InstanceValue"

                   xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot__Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value__ValueSpecification.0"

                   instance="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance__InstanceSpecification"/>

         </slot>

      </packagedElement>



Point #3) There is no crossing of metalevels in SysML's ValueType (extension of UML::DataType) associated to stereotypes extending UML::InstanceSpecification (Unit, QuantityKind)





In practice, it means that if we defined, say, "MassInKilograms", a UML::DataType and applied SysML::ValueType to it, we would have something like this:


      <packagedElement xmi:type="uml:DataType"

                       xmi:id="123"

                       name="MassInKilograms"/>

      <sysml:ValueType xmi:id="456" base_DataType="123" 

                       unit="_ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance__InstanceSpecification"

                       quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance__InstanceSpecification"/>




And we should be able to explicitly create a link instance for the association between ValueType & Unit and its slots would refer to the distinguished UML::InstanceSpecifications corresponding to the stereotype instances thus related, I.e.:

"456" and "_ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance__InstanceSpecification"





Similarly, the link instance for the association between ValueType & QuantityKind would have as its slots the following:

"456" and "_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance__InstanceSpecification"




The rationale for this point is that since stereotypes can participate in associations, it follows that instances of stereotypes can be linked via instances of such associations.


Resolution:
Revised Text:
Actions taken:
August 27, 2012: received issue

Discussion:


Issue 18239: test (uml2-rtf)

Click
here for this issue's archive.
Source: Object Management Group (Mr. Juergen Boldt, juergen(at)omg.org)
Nature:
Severity:
Summary:
test

Resolution:
Revised Text:
Actions taken:
October 30, 2012:

Issue 18951: isReplaceAll=true and lowerBound > 1 (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
About the AddStructuralFeatureAction the UML 2.5 spec states that, if isReplaceAll is true: “[…]The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1 “( §16.8.3).

 

In the other hand, the semantics of the multiplicities states the following (§7.5.3):  “If a MultiplicityElement specifies a multivalued multiplicity (i.e., upper bound greater than 1), then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.”.

 

Does it mean that executing this action with isReplaceAll=true on a structural feature with a lower multiplicity greater than one will result in an invalid model or, in other words, that such a usage is somehow “illegal”?


Resolution:
Revised Text:
Actions taken:
September 13, 2013: received issue

Issue 18955: Problems with OCL definition of Package::makesVisible (uml2-rtf)

Click
here for this issue's archive.
Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
 I see problems with definition of Package::makesVisible - which is expressed in OCL.:



makesVisible(el : NamedElement) : Boolean
The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
pre: member->includes(el)
body: ownedMember->includes(el) or
(elementImport->select(ei|ei.importedElement = VisibilityKind::public)->collect(importedElement.oclAsType(NamedElement))->includes(el)) or
(packageImport->select(visibility = VisibilityKind::public)->collect(importedPackage.member->includes(el))->notEmpty())



Actually those problems carry on from the previous versions of UML;
but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
I assumed this section is old/abandoned and did not pay much attention to it.

But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul :-) ), so we have an updated variant.
But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
If we are updating OCLs anyway, I think it would be a good time to also correct those.

So here goes:


--------------------------------------------------------------------------------

Problem #1

the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):




ei.importedElement = VisibilityKind::public


The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
I think this passage should be restated as follows:



ei.visibility= VisibilityKind::public


i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

Also the whole case handling element imports could be rewritten to simplify it:
elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports 
checking whether imported element matches the element el.


--------------------------------------------------------------------------------

Problem #2
the case handling package imports (line #3 of the body) is also borked:



packageImport->select(visibility = VisibilityKind::public)->collect(importedPackage.member->includes(el))->notEmpty()


Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:



packageImport->select(visibility = VisibilityKind::public)

But the next part again makes no sense



...->collect(importedPackage.member->includes(el))->notEmpty()

here expression part



importedPackage.member->includes(el)

produces a boolean - whether element el is included among the members of the package being imported.
So the result of the expression part



...->collect(importedPackage.member->includes(el))...

is a collection of booleans (of the form: {false, false, true, false, true} ),
where each boolean signifies whether element is among the members of each particular imported package.

Then it makes no sense to test that for emptiness:



->notEmpty()

this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

I think this passage should be restated as follows:



packageImport->select(visibility = VisibilityKind::public)->exists(importedPackage.member->includes(el))

I.e. we are iterating through all (public) package imports and checking whether element el appears among members
of at least one of the imported packages.


--------------------------------------------------------------------------------


So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):




pre: member->includes(el)
body:
ownedMember->includes(el) or
elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))


Resolution:
Revised Text:
Actions taken:
September 24, 2013: received issue

Issue 18969: Relax Association::/endType from [1..*] to [0..*] (uml2-rtf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
An association could be defined with untyped association ends.


UML2.5 currently prevents defining such associations.
If it becomes well-formed in 2.6, this capability will be useful for the Precise Semantics of Composite Structures, particularly for untyped connectors.



Resolution:
Revised Text:
Actions taken:
September 26, 2013: received issue

Issue 18971: ExtensionEnd upper/lower inconsistent with MultiplicityElement (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
Issue 13992 changes the cardinality of MultiplicityElement lower and upper. This was not tracked by ExtensionEnd, which consequently has validation errors.

Resolution:
Revised Text:
Actions taken:
September 24, 2013: received issue

Issue 18972: Semantic error in Lifeline::interaction_uses_share_lifeline (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
The OCL for Lifeline::interaction_uses_share_lifeline has a semantic error at "... implies usingInteraction.lifeline->select..." the RHS of implies is non-Boolean.

Changing "select" to "exists" makes the semantic problem go away

Resolution:
Revised Text:
Actions taken:
September 24, 2013: received issue

Issue 18973: Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
The OCL in UMLDI for UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant at "memberEnd->includes(e.modelElement))" has a semantic error becuase e is already an Element.

Suggest change "e.modelElement" to "e".

Resolution:
Revised Text:
Actions taken:
September 24, 2013: rewceived issue

Issue 18982: XMI.xmi is not merged (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:
In UML 2.4.1 Infrastructure/Superstructure.xmi provided the raw Packages. XMI.xmi provided the merged packages so that in UML 2.4.1 we have uml::Association.


UML 2.5 abandons the merge and so there is just XMI.xmi. uml::Association exists via an import, but the primary definition is now uml::StructuredClassifiers::Association.

To preserve compatibility with the UML 2.4.1 metamodel, the unmerged packages could be provided in e.g. UMLPackages.xmi, with XMI.xmi providing the merged packages as before.

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

Issue 19009: In the Use Case section, it is unclear whether a use case requires an actor (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the Use Case section, it is unclear whether a use case requires an actor. 

For example, in 18.1.3 it says:

“Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors.”  Which requires at least one actor per Use Case. However, the resolution for 18045 deleted “one or more” from earlier in 18.1.3     

Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19010: Abstract Syntax diagram for Use Cases (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Abstract Syntax diagram for Use Cases should show that there is some intended relationship between an Actor and a Use Case. This should have the correct multiplicities as determined in the issue above. It can be a subset of existing relationships in the metamodel

Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19011: Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case. Much of the use case literature says, that the actors of the base use case are automatically actors of the extension or inclusion. They also say that duplicating the actors, that is, connecting the base’s actors to the extension or inclusion, implies that these actors may be needed twice for the extension/inclusion. This approach of assuming that the base’s actors are actors of the extension/inclusion is natural when the use cases are detailed out in sequence diagrams, and is almost a necessity when the extension/included use case can be used by many base use cases (where their actors could be different in each case).  If an explicit actor is added to the extension/inclusion, is it added to the base’s actor or replace it?

Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19012: Use cases and use of arrows (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Modelers often use arrows on the relationships between use cases and their actors. This is never explained/allowed/disallowed in the spec. One would think that if arrows are allowed, then qualifiers, ownership balls, {ordered}, {unique}, etc. would also be allowed. Almost no one uses those arrows as true navigability. Perhaps some mention of the arrows is required and to allow for user determined semantics.

Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19013: Extension point (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Selection points appear to be documented in the properties of a use case. However, extension points are also allowed to be referred to in the condition note attached to the «extend» relationship. Is it legal to refer to an extension point that is not defined in the use case? Does this automatically add the extension point to the base use case. An example of this is in figures 18.3 and 18.11

Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19014: Description of the OCL (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
 The description of the OCL on an actor limits associations to Use Cases, Components, and Classes. However, the OCL limits it to Use Cases and Classes, forbids, behavior, and doesn’t explicitly mention Components.

a.       I assume that Components are types of Classes, but Behavior is generally not a class (it’s a classifier), so I wonder why the limitation on behavior is needed?

b.      Wouldn’t this allow an Actor to have an attribute/part that is typed by a class?

c.       Isn’t this entire restriction obsolete? We don’t seem to be insisting that actors are outside of the subject anymore, almost all modeling approaches, allow for actors to be full design elements within a system. This is necessary to support multiple layers of system analysis, so that at one level some of the parts of a system become actors to other parts when modeled at the level. Requiring the modeling to introduce redundant elements to represent actors that are part of the higher-level system seems inappropriate.


Resolution:
Revised Text:
Actions taken:
October 11, 2013: received issue

Issue 19017: Improving the association direction notation (uml2-rtf)

Click
here for this issue's archive. Click here for this issue's attachments.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
The UML 2.5 notation for associations in section 11.5.4 states (4th paragraph):


On a binary Association drawn as a solid line, a solid triangular arrowhead next to or in place of the name of the Association and pointing along the line in the direction of one end indicates that end to be the last in the order of the ends of the Association. The arrow indicates that the Association is to be read as associating the end away from the direction of the arrow with the end to which the arrow is pointing (see Figure 11.27). This notation is for documentation purposes only and has no general semantic interpretation. It is used to capture some application-specific detail of the relationship between the associated Classifiers.


In practice, the order of association ends is not very useful. Deriving the direction of an association based on association end cardinality, aggregation type and navigability, which is a function of ownership (see Property::isNavigable()) would be more useful.


I propose the following criteria (written in QVT Operational):


modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1';


/**
 * @author nicolas.f.rouquette@jpl.nasa.gov
 * October 2013 - UML2.6 Improving the association direction notation.
 */
transformation AssociationDirectionCheck(in selectedAssociations:uml);
property associations : Set(uml::Association) = selectedAssociations.rootObjects()[uml::Association];


main() {
log('Analyzing ' + associations->size().repr() + ' associations');
associations->sortedBy(qualifiedName)->forEach(a) {
var p := a.memberEnd![name='p'];
var q := a.memberEnd![name='q']; 
log('Association ' + a.name + ' : ' + p.type.name + ' -- ' + q.type.name);
p.describe('end1');
q.describe('end2');
}
}


helper uml::Property::describe(in prefix:String) {
var a := self.association;
assert fatal (a.oclIsKindOf(uml::Association));
var other := a.memberEnd->excluding(self)->any(true);
var dir := 'n/a';
if (self.isMemberEndLogicallyDirectedToOtherEnd()) then dir := self.name + '>>' + other.name endif;
if (other.isMemberEndLogicallyDirectedToOtherEnd()) then dir := other.name + '>>' + self.name endif;
log(prefix + ': ' + self.namespace.name + '::' + self.name + ' : ' + self.type.name 
+ '[' + self.lower.repr() + '..' + (if self.upper < 0 then '*' else self.upper.repr() endif) + ']'
+ ' {memberEnd#' + a.memberEnd->indexOf(self).repr()
+ ', aggregation=' + self.aggregation.repr()
+ ', isNavigable=' + self.isNavigable().toString()
+ ', direction=' + dir
+ '}');
}


helper uml::Property::isMemberEndLogicallyDirectedToOtherEnd() : Boolean {
var a := self.association;
assert fatal (a.oclIsKindOf(uml::Association));
var other := a.memberEnd->excluding(self)->any(true);
var fwdDirByClassOrNav := ((self.owner = a) and (other.owner <> a)) or (not self.isNavigable()) and other.isNavigable();
var fwdDirByComposition := (not self.isComposite) and other.isComposite;
var fwdDirByCardinality := (not self.isComposite) and (not other.isComposite) and (self.upper <= 1) and (other.upper < 0 or other.upper > 1);
return fwdDirByClassOrNav or ((not fwdDirByClassOrNav) and (fwdDirByComposition or fwdDirByCardinality));
}


query Boolean::toString() : String { if (self) then return 'Y' endif; return 'F'; }




For a representative set of test cases varying all combinations of association end aggregation type, cardinality, ownership, navigability, member end order, 
the above criteria suffices to determine whether an association with ends p and q is in the forward direction (p>>q) or reverse (q>>p):


[10/13/13 2:03 PM] Analyzing 22 associations
[10/13/13 2:03 PM] Association AB'0 : A'0 -- B'0
[10/13/13 2:03 PM] end1: AB'0::p : A'0[1..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: A'0::q : B'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association AB'1 : A'1 -- B'1
[10/13/13 2:03 PM] end1: AB'1::p : A'1[1..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: AB'1::q : B'1[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association AB0 : A0 -- B0
[10/13/13 2:03 PM] end1: AB0::p : A0[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: A0::q : B0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association AB1 : A1 -- B1
[10/13/13 2:03 PM] end1: AB1::p : A1[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: AB1::q : B1[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association CD'0 : C'0 -- D'0
[10/13/13 2:03 PM] end1: CD'0::p : C'0[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: C'0::q : D'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association CD'1 : C'1 -- D'1
[10/13/13 2:03 PM] end1: CD'1::p : C'1[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: CD'1::q : D'1[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association CD0 : C0 -- D0
[10/13/13 2:03 PM] end1: CD0::p : C0[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: C0::q : D0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association CD1 : C1 -- D1
[10/13/13 2:03 PM] end1: CD1::p : C1[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
[10/13/13 2:03 PM] end2: CD1::q : D1[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association EF'0 : E'0 -- F'0
[10/13/13 2:03 PM] end1: EF'0::p : E'0[1..1] {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}
[10/13/13 2:03 PM] end2: E'0::q : F'0[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association EF'1 : E'1 -- F'1
[10/13/13 2:03 PM] end1: EF'1::p : E'1[1..1] {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}
[10/13/13 2:03 PM] end2: EF'1::q : F'1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association EF0 : E0 -- F0
[10/13/13 2:03 PM] end1: EF0::p : E0[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
[10/13/13 2:03 PM] end2: E0::q : F0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association EF1 : E1 -- F1
[10/13/13 2:03 PM] end1: EF1::p : E1[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
[10/13/13 2:03 PM] end2: EF1::q : F1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH'0 : G'0 -- H'0
[10/13/13 2:03 PM] end1: GH'0::p : G'0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: G'0::q : H'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH'1 : G'1 -- H'1
[10/13/13 2:03 PM] end1: GH'1::p : G'1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: GH'1::q : H'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH'2 : G'2 -- H'2
[10/13/13 2:03 PM] end1: H'2::p : G'2[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: G'2::q : H'2[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH0 : G0 -- H0
[10/13/13 2:03 PM] end1: GH0::p : G0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: G0::q : H0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH1 : G1 -- H1
[10/13/13 2:03 PM] end1: GH1::p : G1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: GH1::q : H1[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association GH2 : G2 -- H2
[10/13/13 2:03 PM] end1: H2::p : G2[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: G2::q : H2[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association IJ'0 : I'0 -- J'0
[10/13/13 2:03 PM] end1: J'0::p : I'0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: I'0::q : J'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association IJ'1 : I'1 -- J'1
[10/13/13 2:03 PM] end1: J'1::p : I'1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: I'1::q : J'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association IJ0 : I0 -- J0
[10/13/13 2:03 PM] end1: J0::p : I0[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: I0::q : J0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] Association IJ1 : I1 -- J1
[10/13/13 2:03 PM] end1: J1::p : I1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
[10/13/13 2:03 PM] end2: I1::q : J1[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}


To facilitate reviewing this criteria, these associations are shown in the attached class diagram.

Resolution:
Revised Text:
Actions taken:
October 13, 2013: received issue

Discussion:


Issue 19024: Sequence Diagram: Message limitation (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In several places in the UML 2.5 spec the message line (that goes from lifeline to lifeline) is restricted to have the destination end no higher than the source end.

 

While this sounds reasonable, it’s not really logically required in the general case. 

 

No, I’m not talking about faster-than-light messages.

 

When a sequence diagram / fragment is “weak” (not strict) ordering, the individual life-lines can have their own time scale, and as long as causality is followed. And as each life-line’s time scale need not be uniform, a message going from one location on one lifeline to another lifeline but physically higher need not violate any logical or physical limitations. 

 

Please eliminate the restriction preventing upward aiming message lines when the ordering is weak.  This will allow the modelers to have better use of the diagram real-estate.

Michael

Resolution:
Revised Text:
Actions taken:
October 19, 2013: received issue

Issue 19070: About behavior ports (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
On the semantics of behavior ports, UML 2.5 §11.3.3 says:

 

“A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any”

 

It is not clear whether “the Behavior” refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation.

 

This has to be clarified.


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

Issue 19122: About prescribed port implementation (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
Description:

The prescription made in the §11.3.3 about the implementation of Port seems to be overly restrictive:  

“When an instance of an EncapsulatedClassifier is created, instances corresponding to each of its Ports are created and held in the slots specified by each Port, in accordance with its type and multiplicity. These instances are referred to as “interaction points” and provide unique references.”

 

As long as port is defined as “a distinct interaction point”, of which the primary purpose is: “enabling different communications to be distinguished based on the Port through which they occur”, the implementation described by the text quoted above, and which based on the instantiation of a separate object, is actually a possible implementation but it is not the only one.

 

An alternative valuable implementation is to make them pure routing information that does not required any structural part instance (cf. SDL port semantics). UML should not prevent implementations of that kind.

 


Resolution:
Revised Text:
Actions taken:
November 22, 2013: received issue

Issue 19133: Cannot set an activity as the source or target of an information flow (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
According to the constraints specified for an InformationFlow, its sources and targets can be only of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship.

In my opinion, Activity should also be included in the list.

Resolution:
Revised Text:
Actions taken:
December 4, 2013: received issue

Issue 19167: Information flow instantiation (uml2-rtf)

Click
here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
Summary:
Information flow instantiation.  There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things. 

 


Resolution:
Revised Text:
Actions taken:
December 26, 2013: received issue

Issue 19179: BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Currently interface realizations are not included in the conformance specification on BehavioredClassifier. In particular this is a problem for subsetting semantics when the subsetted property resides on an Interface.

Resolution:
Revised Text:
Actions taken:
January 11, 2014: received issue

Issue 19185: Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2 (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:
ExtensionEnd::lower invalidly redefines MultiplicityELement::lower (see issue 13992) - the multiplicity of ExtensionEnd::lower doesn't fall within that of MultiplicityELement::lower.

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19186: Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2 (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Revision
Severity: Significant
Summary:
NamedElement::clientDependency is derived (see issue 15056) but the following subsets are not:


Artifact::manifestation
BehavioredClassifier::interfaceRealization
Classifier::substitution
DeploymentTarget::deployment

IMHO, this defeats the intent of the resolution since one still has to "modify the model" in order to set up these special kinds of dependency. Besides, I don't know what it means for a non-derived property to subset a derived property which is not a union...

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19187: Problems with normative UML 2.5 Beta 2 Standard profile (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Revision
Severity: Significant
Summary:
The stereotypes in the normative machine consumable file for the Standard profile, available at http://www.omg.org/spec/UML/20131001/StandardProfile.xmi, are missing the comments, constraints, and properties that were present in the normative files for the L2 and L3 profiles in UML 2.4.1 (http://www.omg.org/spec/UML/20110701/StandardProfileL2.xmi and http://www.omg.org/spec/UML/20110701/StandardProfileL3.xmi).

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19188: Notation for PrimitiveTypes (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Latest UML 2.5 spec has 

 

In 21 Primitive Types 21.3 Notation

 

“There is no notation for PrimitiveTypes. There is notation for literal values of PrimitiveTypes; this notation is covered in Clause 8.2.” 

 

However, in Figure 21.1 Primitive Types, there appears to be notation for PrimtitveTypes. And explicitly in 10.2.5 Examples

 

“Figure 10.2 illustrates the notation for defining a PrimitiveType”

 

Similarly in 10.2.4, a notation for PrimitiveType is described.

 

So which is it? Is there notation for PrimitiveType or not? This needs to be made clear.

 

Perhaps what is meant is “There is no notation for defining literals of any new (modeler-defined) PrimitiveType.” And replace the 2nd sentence with “There is notation for literal values of the UML-supplied PrimitiveTypes; this notation is covered in Clause 8.2.” 

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19189: Can PrimitiveTypes be user-defined and where? (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In 10.2.3 it says that 
 
“A PrimitiveType defines a predefined DataType, without any substructure.”
 
What does it mean to be “predefined” If a PrimitiveType is predefined, then how can it be defined by a modeler? I recommend that the word “predefined” be deleted from this sentence. In addition, the general impression is that the PrimitiveTypes are only located in the PrimitiveType package and cannot be anywhere else 
 
Though based on a statement in Profile a PrimitiveType could be in a profile, though it couldn’t be used in a model «grin». 

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19190: A PrimitiveType can/cannot have owned attributes. (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
A datatype can have ownedAttributes. A primitivetype is a subclass of Datatype, so it can have owned attributes. However a primitive type cannot have any substructure. Unfortunately “substructure” is not defined.
 
This is repeated by the by the classifier definition for PrimitiveType[Class] however there is no OCL that enforces any restriction.
 
Either eliminate the restriction or define substructure and write some OCL.

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19191: Clause 21 Primitive Types is misnamed (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Clause 21 is titled Primitive Types. However the content describes only the predefined types of UML that are located in the PrimitiveTypes package. The section should be titled, Primitive Types Package (or similar.

Resolution:
Revised Text:
Actions taken:
January 17, 2014: received issue

Issue 19193: Descriptions missing for PseudostateKind literals (uml2-rtf)

Click
here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:
Descriptions are missing for PseudostateKind enumeration literals, as are comments for those elements in the normative machine consumable file for UML, available at http://www.omg.org/spec/UML/20131001/UML.xmi (see related issue 17978).

Resolution:
Revised Text:
Actions taken:
January 22, 2014: received issue

Issue 19194: Rg. Reception.ownedParameter (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception.

 

As a matter of fact, with the invariant ‘same_structure_as_signal’ there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter.

 

In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints.


Resolution:
Revised Text:
Actions taken:
January 16, 2014: received issue

Issue 19199: How to access a token value in a guard? (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:
It is specified that the evaluation of the guard of an ActivityEdge could use the value in the token offered to the edge (see page 392 and 406). However the way, how a guard accesses the value in the token is never specified.


15.2.3 page 392
>An offer shall only pass along an ActivityEdge if the guard for 
>the edge evaluates to true for the offered token. 


That sentence could get interpreted, that the guard will evaluate the object in the token (in case it contains one). Maybe I'm over interpreting the sentence. Then how about this one, taken from the chapter on DecisionNodes:


15.3.3 page 406
>...the value contained in an incoming object token may be used in 
>the evaluation of the guards on outgoing ObjectFlows


Since it is explicitly specified for ActivityEdges coming out of DecisionNodes, I think the same should be true with any Edges.


Now that I have established, that guards should have access to the value in an object token, the question remains, how is this done? The natural way would be to define a parameter of the guard, the same way this is done for selection Behaviors. However guards are ValueSpecifications, and this element cannot have parameters. The Value could be specified by a Behavior, but as far as I understand, this behavior can only have a return parameter (even though there is no constraint).

How could this get solved? Maybe we need a new subclass of ValueSpecificaton like TokenValueSpecification to be used in Expressions? Or we need to allow Behaviors to be used as guards. Another possibility would be to do it the fUML way: The value in the token is compared with the result of the guard-Expression. Here we don't need a parameter. However it would make it hard to define certain kinds of guards (e.g. token.value between l and u) and I don't think, that the current specification includes the interpretation of fUML.

Resolution:
Revised Text:
Actions taken:
January 30, 2014: received issue

Issue 19202: Type conformance for classifiers (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Subclause 9.2.3 (Semantics), Generalization, sixth paragraph, last sentence ("A Classifier is a Type, and conforms to itself and to all of its generalizations.") contradicts the previous sentences.  Classifiers conform to their metaclassifiers, not necessarily themselves or their generalizations.  This sentence might have been intended to refer to the instances of a classifier.

Resolution:
Revised Text:
Actions taken:
February 3, 2014: received issue

Issue 19209: Generalization should be limited to relate similar UML-elements (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Revision
Severity: Significant
Summary:
The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances?


The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293).


Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view.


Suggestion:
Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses.

Resolution:
Revised Text:
Actions taken:
February 10, 2014: received issue

Issue 19253: Missing OpaqueXXX body constraint (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
Presumably a well-formed UML model should have well-formed content, so surely there should be an OpaqueAction/Behavior/Expression constraint that requires the body to be well-formed in its corresponding language?

Resolution:
Revised Text:
Actions taken:
February 21, 2014: received issue

Issue 19254: InstanceSpecification validity is not modelable (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid.


InstanceSpecification may be used to create test models and so should necessarily be valid.


It is not easy for tooling to detect which is the design intent.

Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully.

Resolution:
Revised Text:
Actions taken:
February 21, 2014: received issue

Issue 19282: Name of Package in Figure 7.3 should be "Core" rather than "Constructs" (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The subtitle of the Figure 7.3:
"The Core Packages"
But the Name of the Package in the figure is "Constructs".

Resolution:
Revised Text:
Actions taken:
March 10, 2014: received issue

Issue 19285: UML 2.5 Figure 10.10 Error (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In UML 2.5, Figure 10.10 is entitled 

 

ISensor is a required Interface of TheftAlarm

 

However, the figure only shows an unnamed required Interface. 


The diagram needs to have the Interface named “ISensor” on the diagram. 

Resolution:
Revised Text:
Actions taken:
March 20, 2014: received issue

Issue 19288: Multiple Generalization Sets (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
A generalization can appear in multiple generalization sets. The notation
for this isn't completely clear to me as there are no examples of this
case in the spec and the existing examples would be ambiguous if followed.


The main problem is that there are multiple labels for the generalization
set properties, for example the :TreeSpecies and {disjoint, incomplete}
labels in the Tree example. Somehow these need to be visually joined to
show they are properties of the same set. Additionally there are no
examples showing the set name and any other properties so it's not clear
what the full notation is.


I'd guess the notation should actually be a single label in the form:


name{complete, disjoint} : PowerType


or


{complete, disjoint} name : PowerType


Which of those makes most sense?


Resolution:
Revised Text:
Actions taken:
March 21, 2014: received issue

Issue 19320: UML 2.5 Figure 14.25 Choice Pseudostates (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 14.25 Choice Pseudostates  (and text above/below)

 

The description of the figure indicates that the left hand (sub)diagram indicates the empty diamond should be on the right and the one with the operand inside the diamond  should be on the left. 

 

The subdiagrams are backwards. 

Resolution:
Revised Text:
Actions taken:
March 30, 2014: received issue

Issue 19322: Rename Specialization/Generalization between abstract classes (uml2-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:
Inheritance between an abstract and a solid class should not be named Inheritance (or specialization or generalization).
Reason: If abstract classes do not have filled in methods, the concrete class just implements them, not extend. Therefore inheritance between concrete class and an abstract class is really an implementation. But implementation is used for interfaces. Therefore we need different name to describe the relationship between abstract class and concrete class.

Resolution:
Revised Text:
Actions taken:
March 31, 2014: received issue

Issue 19323: Ambiguous Profile::profileApplication (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
Profile::profileApplication {subsets directedRelationship wrt target} and occludes Package::profileApplication {subsets directedRelationship wrt source}.


This means that


aProfile.profileApplication <> aProfile.oclAsType(Package).profileApplication

Since Profile::profileApplication is unnavigable, suggest renaming Profile::profileApplication as Profile::application

Resolution:
Revised Text:
Actions taken:
March 31, 2014: received issue

Issue 19324: UML 2.5 Issue on DI for reply arrows (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the UML 2.5 spec, the reply arrow on sequence diagrams now has two forms.

 

17.4.4 Notation 

Message

 

· A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head. 

 

However, the DI section of the specification, p 754.

Only allows the filled arrow head and does not support an option to specify which. 

 

This will mean that diagram interchange will not preserve use of the open arrow head (which is the traditional way of doing this)

Michael Jesse Chonoles

Change-Vision.

Resolution:
Revised Text:
Actions taken:
March 31, 2014: received issue

Issue 19325: UML 2.5 Visibility of a packagedElement (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
12.2.4 Notation

 

The visibility of a packagedElement may be indicated by preceding the name by a visibility symbol (‘+’ for public and ‘-’ for private). Packages may not have protected or package visibility.

 

This is a bit unclear, as the 2nd sentence does not include the first. I think you should say:

…

Package and their contained elements may not have protected or package visibility.


Resolution:
Revised Text:
Actions taken:
March 31, 2014: received issue

Issue 19329: UML transition-centric state machine arrows (01) (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the UML 2.5 spec Figure 14.31 shows and the text describes the alternative exit point notation as a bracketed space  

 

--- (exit point name) ---

 

The UML 2.5 spec in Figure 14.30 shows and the text describes the alternative entry point notation as a bracketed space with the string “via”.

 

--- (via entry point name) à

 

This leaves the following, albeit pathological case:

 

1st state --- (via pointName) à 2nd state

 

From the notation, you can’t be sure if “pointName” is the name of the entry point or if “via pointName” is the name of the exit point.

 

One possible interpretation of the spec goes back to diagram in 14.32 and notices that there is no “leaving arrow head” from the symbol for the exit point, but there is one for the entry point. If this is not accidental, then

 

1st state --- (via pointName) à 2nd state 

means the entry point pointName

And the

1st state --- (via pointName) --- 2nd state 

means the exit point “via pointName”

 

However, this is pretty obscure and if intended should be clarified in the spec. If not intended, either “via” should be explicitly reserved (not allowed) in exit point names or the notation modified to distinguish them. 


Resolution:
Revised Text:
Actions taken:
April 5, 2014: received issue

Issue 19330: UML transition-centric state machine arrows (02) (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
2nd related issue

All the notation in the alternative transition-centric examples use solid, filled arrow heads.  All the notation for the traditional state-centric examples use v-shaped arrow heads.  However, the text never mentions this difference. The spec should clarify if this is part of the notation.


Resolution:
Revised Text:
Actions taken:
April 5, 2014: received issue

Issue 19334: UML 2.5 issue on examples in 17.4.5 (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
In 17.4.5, the 3rd example, is

                V=mymsg(w=myout:16):96

 

However, the description says 

“This is a reply message assigning the return value 69 to ‘v’

 

Choose either 96 or 69 and make consistent.


Resolution:
Revised Text:
Actions taken:
April 13, 2014: received issue

Issue 19335: UML 2.5 Overly strict restriction on message slope in seq diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
(BTW, where should the issues found on UML 2.5 go, Is there a 2.6 mailing list?)

 

In UML 2.5 Paragraph 17.4.4. Notation 

Message:

“..A line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event.”

 

While this restriction appears reasonable when first read, it is really overly strict.

 

In the default, WEAK, interpretation of sequence diagrams, the time-wise ordering of occurrences within a lifeline is independent of occurrences on other lifelines, subject to cause/effect sequencing (message sending—>message reception). And, of course, the order of occurrences as depicted on the lifeline must be maintained. 

 

This is practically equivalent to saying that each lifeline has its own clock or timescale, and that ordering by that clock must be maintained and that causality across lifelines must be maintained. It is often thought that one could change the timescale (and not necessarily smoothly) on a lifeline without changing the interpretation or legality of the diagram.

 

However, the restriction on messages not taking a non-negative slope, prevents otherwise legal changes in scale and makes invalid some diagrams that do not violate causality or the within-lifeline ordering. 

 

Please relax this restriction

Resolution:
Revised Text:
Actions taken:
April 13, 2014: received issue

Issue 19337: Unclear statement regarding Lifeline shape (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Section 17.3.4 states


"The Lifeline head has a shape that is based on the classifier for the part that this lifeline represents."


"part" is ambiguous. Its meaning can not be inferred from the specification of the Lifeline class. Can you change the wording of this sentence to clarify what is meant by  "part" ? 

Proposed change : The Lifeline head has a shape that is based on the Type of the ConnectableElement that this lifeline represents.

Resolution:
Revised Text:
Actions taken:
April 16, 2014: received issue

Issue 19338: Including use case depends on included use case but Include is no subclass of Dependency (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The following sentences of the specification made me wonder why Include is no subclass of Dependency.


"As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa."

Instead of the dependency being reflected in the direction of the relationship, the class could explicitly have Dependency semantics.

Resolution:
Revised Text:
Actions taken:
April 16, 2014: received issue

Issue 19342: Unnamed elements in a namespace (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:
I’ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name.

 

NamedElement defines the query isDistinguishableFrom():

 

---

isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names.

 

body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies

ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty()

---

 

If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view.

 

Is that an issue or did I miss something?

Resolution:
Revised Text:
Actions taken:
April 8, 2014: received issue

Issue 19345: Incorrect drawing of non-navigable redefined opposites (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
Fig 9.10 shows three navigable Property.property


Fig 9.13 shows Operation.operation as navigable


The textual descriptions and the XMI consistently have redefined/subsetted opposites as unnavigable, so the diagrams are at fault.

[From an OCL perspective three different Property.property makes OCL navigation troublesome.]

Resolution:
Revised Text:
Actions taken:
April 19, 2014: received issue

Issue 19346: Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
Fig 7.4 is drawn with ParameterableElement.owningTemplateParameterSubstitution as * rather than the 0..1 that appears in the text and model.

Resolution:
Revised Text:
Actions taken:
April 19, 2014: received issue

Issue 19349: NamedElement::allNamespaces is invalida at model root (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:
The specified OCL body for NamedElement::allNamespaces has its tests in the wrong order and consequently fails at the root since in:


if owner.oclIsKindOf(TemplateParameter) and
  owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace) then
    ...
else
  if namespace->isEmpty()
    then ...


At the root owner is null and the navigation results in invalid for both arms of the conjunction and consequently the if condition and if result.


Suggest the more readable, less redundant and more correct:


if owner = null 
then OrderedSet{} 
else
    let enclosingNamespace : Namespace = 
        if owner.oclIsKindOf(TemplateParameter)
        and owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace)
        then owner.oclAsType(TemplateParameter).signature.template.oclAsType(Namespace)
        else namespace
        endif
    in enclosingNamespace.allNamespaces()->prepend(enclosingNamespace) 
endif

Resolution:
Revised Text:
Actions taken:
April 20, 2014: received issue

Issue 19350: TypeElement / TypedElement typo (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The Property::isCompatibleWith constraint has a TypeElement/TypedElement typo.

A similar typo occurs in 7.5.3.

Resolution:
Revised Text:
Actions taken:
April 22, 2014: received issue

Issue 19351: Incorrect OrderedSet returns (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:
The OCL for


StructuredClassifier::part() and Operation::results()


retuirns a projection of an OrderedSet and so itself returns an OrderedSet. However the operations are declared to return Sets.

Suggest adding ->asSet() to discard the ordering prior to return.

Resolution:
Revised Text:
Actions taken:
April 22, 2014: received issue

Issue 19353: Specification should not contain any methodology (uml2-rtf)

Click
here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:
The statement "Such instances are often described by Interactions." is about methodology and not the language. For example I have a different opinion about that and would write "Such instances are often described by Activities."


I propose to discard the sentence or to change it to

"Such instances are described by concrete Behaviors."

Resolution:
Revised Text:
Actions taken:
April 23, 2014: received issue

Issue 19364: UML 2.6 Issue --- SignalEvent Triggers (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
On p 345 under the details of Transition it says:

 

SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere. 

 

However, on the next page under Signal receipt signal it says:

 

The Signal receipt symbol is shown as a five-pointed polygon that looks like a rectangle with a triangular notch in one of its sides (either one). It maps to the trigger of the Transition and does not map to an Action of the Activity that specifies the effect Behavior. The names of the Signals of the Trigger as well as any guard are contained within the symbol as follows: 

 

<trigger> [‘,’ <trigger>]* [‘[‘ <guard> ‘]’] 

 

Where <trigger> is specified as described in sub clause 13.3.4 with the restriction that only Signal and change Event types are allowed. The trigger symbol is always first in the path of symbols and a compound transition can only have at most one such symbol.

 

This means, that when the Signal Receipt symbol is used, and the trigger syntax is <name>[‘(‘[<assignment-specification>]’])’] is unambiguously a SignalEvent trigger and not a  CallEvent trigger

Resolution:
Revised Text:
Actions taken:
April 25, 2014: received issue

Issue 19365: UML 2.5 Mandatory but suppressible compartments (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Clarification
Severity:
Summary:
In 11.4.4 (Classes) Notation

“A Class has four mandatory compartments: attributes, operations, receptions (see 9.2.4) and internal structure (see 11.2.4).”

 

However, a bit later in 11.4.5 Examples

 

“Figure 11.16 shows three ways of displaying the Class Window, according to the options set out for Classifier notation in 9.2.4. The top left symbol shows all compartments suppressed.” 

 

It’s a bit confusing to have mandatory but suppressible compartments. 

 

And in 9.2.4 (Classifier) Notation

Some compartments in Classifier shapes are mandatory and shall be supported by tools that exhibit concrete syntax conformance. Others are optional, in the sense that a conforming tool may not support such compartments. 

Any compartment may be suppressed. A separator line is not drawn for a suppressed compartment. If a compartment is suppressed, no inference may be drawn about the presence or absence of elements in it.

 

Many readers have been confused by this use of mandatory. Apparently “mandatory” means mandatory for the tool vendor to support, but not mandatory to display.  

 

In 11.2.4 Notation, it is clarified. E.g., 

This compartment is mandatory: all tools that conform to the concrete syntax of UML must implement it.

 

I’m requesting a similar clarification in 11.4.4


Resolution:
Revised Text:
Actions taken:
April 18, 2014: received issue

Issue 19406: Incorrect Result in ReduceAction Example (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Unless my understanding of the ReduceAction is way off, the example says that with an input collection of four integers (2,7,5,3) the result of applying the ReduceAction to this collection with an addition function is 11. I believe the result should be 17 since 2+7+5+3 = 17 regardless of order.

Resolution:
Revised Text:
Actions taken:
May 4, 2014: received issue

Issue 19409: Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams (uml2-rtf)

Click
here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
Summary:
Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams, which can never execute. The first behavior is a successor of the first behavior, and, as such, can never execute.

 

The figures can be fixed by preceding the first behavior with a start node which has as its successor a merge node, which has as its successor the first behavior.  Then the loop back from the downstream decision node must be connected to the merge node. 


Resolution:
Revised Text:
Actions taken:
May 9, 2014: received issue

Issue 19420: meaning is not clear (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In the part where the adornments on Association symbol are explained, the third bullet point seems to be confusing.


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.

Though I am not in a position to say whether it's incorrect or not but I think it's bit convoluted as in  "property string is placed so that it's not confused with a property string"?

Resolution:
Revised Text:
Actions taken:
May 20, 2014: received issue

Issue 19422: Message should extend Namespace (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
Messages in Interactions should extend Namespace similarly as Transition extends Namespace. Being a Namespace (would be backwards compatible) would make it possible to specify Constraints among Parameter of the Signature merely in the context of the particular Message and in addition to  the Constraints already applied on the signature itself. This would enable testers to specify fine-grained interdependencies among Parameter (and for argument generation) in that particular situation. Such a feature on Messages would be actually quite handy for test generation purposes – also, similar to what is currently already possible and being done with Transitions.

 

Any thoughts on that?

Resolution:
Revised Text:
Actions taken:
April 14, 2014: received issue

Issue 19427: Incomplete sentence (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In the explanation for "Entering a State" concept w.r.t. alternate entry points for a composite state, it appears that the description for "Entry point entry" is not a complete sentence.


Entry point entry:

Resolution:
Revised Text:
Actions taken:
May 21, 2014: received issue

Issue 19430: Incorrect sentence (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
v=mymsg(w=myout:16):96 // this is a reply message assigning the return value 69 to ‘v’ and // the value 16 for the out parameter ‘myout to ‘w’.

The return value is 96 but the comment suggests 69 is getting assigned to v.

Resolution:
Revised Text:
Actions taken:
May 22, 2014: received issue

Discussion:


Issue 19438: ExpansionNodes owned by ExpansionRegions? (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Are ExpansionNodes owned by their ExpansionRegions?  ENs are pin-like, so it seems like they should be, but then I would have expected ER::in/outputElement and EN::regionAsIn/Output to be subsetted from StructuredActivityNode::node and ActivityNode::inStructuredNode, respectively.  ENs could still be owned by ERs as SANs without the subsetting, but I couldn't find what the spec says about it.  Is there a MIWG test for this case?

Ed S's response:http://www.omg.org/archives/model-interchange/msg02614.html

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

Issue 19454: UML wording in Superstructure 2.4.1 (uml2-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I have a comment concerning wording in the UML 2.4.1 Superstructure document
you are using both "classifier rectangle" and "class rectangle" for describing
presentation options. Is this really appropriate?
I'd like to suggest to use "classifier rectangle" consistently since  
there is no
special representation shape of a class, and class is a specialization  
of classifier.
Additionally, at page 152, you give "Classifier rectangle" with  
capital letter.
I think that, in terms of consistency, it should be "classifier  
rectangle" there as well.

Resolution:
Revised Text:
Actions taken:
June 5, 2014: received issue

Issue 19455: BehavioralParameter should be BehavioralFeature (uml2-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:
In Section 13.4, Subsection Behavior, Subsubsection Constraints, the Constraint parameters_match says in the second sentence:

 

“The Behavior Parameters must also "match" the BehavioralParameter Parameters, but the exact requirements for this matching are not formalized.”

 

BehavioralParameter is not correct and should say BehavioralFeature.

Resolution:
Revised Text:
Actions taken:
June 7, 2014: received issue

Discussion:


Issue 19468: Semantics of static features (uml2-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity:
Summary:
“In §9.4.3, the following sentence: “The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true)” may suggest that a static feature cannot relates to the instances of this classifier. This does not seem to be the intent.  If so, improve the sentence. Otherwise explain how the semantics of a property which have the same value for all the instances of a classifier shall be modeled.”


Resolution:
Revised Text:
Actions taken:
June 12, 2014: eceived issue

Issue 19472: No specification of which visibility marking corresponds to which VisibilityKind value (uml2-rtf)

Click
here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Clarification
Severity: Significant
Summary:
Nowhere does the spec say which visibility marking corresponds to which value.  There is no specification that # means protected, for example.  This would best live in 7.4.4.

Resolution:
Revised Text:
Actions taken:
June 16, 2014: received issue

Issue 19488: Issue against UML: implementation of OCL constraint containingProfile (uml2-rtf)

Click
here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:
Problem: Recursion in calls to the OCL operation containingProfile() does not properly terminate.

Current OCL in the spec for Stereotype.containingProfile():
self.namespace.oclAsType(Package).containingProfile()  
The problem with this is that the argument won't be seen as a Profile after oclAsType(Package).
    
I suggest instead this OCL for Stereotype.containingProfile():
     if self.namespace.oclIsKindOf(Profile) 
        then self.namespace 
        else self.namespace.containingProfile()
     endif


Current OCL in the spec for Package.containingProfile():
   if self.oclIsKindOf(Profile) 
      then  self.oclAsType(Profile)  
      else  self.namespace.oclAsType(Package).containingProfile()  
   endif

I suggest instead this OCL for Package.containingProfile():
    if self.oclIsKindOf(Profile) 
       then  self 
       else  self.namespace.containingProfile()  
    endif

There still may be problems if, for example, a Classifier (or other subtypes of Namespace) were a namespace for a Package. In those cases (which I assume don't really happen), we would need additional containingProfile() methods like the one on Package.


Resolution:
Revised Text:
Actions taken:
June 25, 2014: received issue

Issue 19511: Classifier::ownedTemplateSignature needs to subset Element::ownedElement (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
UML composite properties must subset Element::ownedElement.
Classifier::ownedTemplateSignature doesn't.


Note that issue 12244 suggested making a change to replace
the ownedElement subset with a redefinition of another
property. By 2.5 the change had already been made, so
the issue was closed no change in ballot 1. However it was
never the correct thing to do as the previously resolved
general composite issue 14926 pointed out.

Resolution:
Revised Text:
Actions taken:
July 7, 2014: received issue

Issue 19512: UML 2.5 Beta 2 XMI invalid (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
The UML.xmi available from http://www.omg.org/spec/UML/20131001/UML.xmi,
currently linked as UML 2.5 Beta 2, isn't valid. It contains duplicate
ids for the package imports, so it isn't even valid XML let alone XMI.


Resolution:
Revised Text:
Actions taken:
July 7, 2014: received issue

Issue 19523: Actor association constraint makes UseCase subclass of Class (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
The constraint on Actors
inv: Association.allInstances()->forAll( a | a.memberEnd->collect(type)->includes(self) implies (
a.memberEnd->size() = 2 and
let actorEnd : Property = a.memberEnd->any(type = self) in
actorEnd.opposite.class.oclIsKindOf(UseCase) or
( actorEnd.opposite.class.oclIsKindOf(Class) and not
actorEnd.opposite.class.oclIsKindOf(Behavior)) )
)


uses the sub-expression 
actorEnd.opposite.class.oclIsKindOf(UseCase)
where the actorEnd is a Property, whose opposite is a Property, whose class is a Class. So oclIsKindOf(UseCase) can never be true, as UseCase is a subclass of BehavioredClassifier, and not of Class.

Resolution:
Revised Text:
Actions taken:
July 16, 2014: received issue

Issue 19538: Another UML 2.5 Beta 2 XMI invalidity (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
For constraint specifications that "Cannot be expressed in OCL",
there is an invalid language attribute in the XMI. For example:


<specification xmi:type="uml:OpaqueExpression" xmi:id="ObjectFlow-same_upper_bounds-_specification" language=""/>


language is a multivalued property with primitive type and these
can only be represented as elements.


(In 2.4.1 such unexpressable constraints were represented as
(OCL,true), it's not clear the above change is intentional.)

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19540: UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:
The description for the ActivityEdge weight includes:


It must evaluate to a positive LiteralUnlimitedNatural
and may be a constant.


I think that should be "an UnlimitedNatural value" rather
than "LiteralUnlimitedNatural". (I'm not sure there's
any need to specify that it may be a constant either.)

Resolution:
Revised Text:
Actions taken:
July 24, 2014: received issue

Discussion:


Issue 19545: Section 15.5.3: a missed word (uml2-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In fourth paragraph, phrase "While the ExecutableNode is executing, it is considered to hold a single control indicating it is execution." the word "token" is missed. 
The corrected sentence: "While the ExecutableNode is executing, it is considered to hold a single control token indicating it is execution."

Resolution:
Revised Text:
Actions taken:
July 25, 2014: reeived issue

Issue 19564: Pin multiplicity and token upper bound (uml2-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity:
Summary:
I'm a little confused about the relationship between the multiplicity
of a Pin and its token upper bound. What does it mean for the token
upper bound to be less than the multiplicity upper bound, or even
the multiplicity lower bound?

Resolution:
Revised Text:
Actions taken:
July 25, 2014: received issue