We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
Does XMI support that?

So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

Any suggestions? Don't you think we should fix that somehow?

No Data Available

Version 2.4 intruduces a new UML primitive type - Real.

This information has not been mentioned on page 127 - 7.3.44.

The package name (I suppose Kernel) has not been defined for LiteralReal - chapter 7.3.29 (page 95); table of contents (page II).

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

On page 36, Figure 7.16 shows the content of Interface package. Interface element has associations to four other elements with multiplicity of *. Multiplicity information is not defined on page 89, where the association names for Interface element has been defined.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Is there a semantic difference between markign an associationEnd with isID=true and putting an upper bound of "1" on its opposite end (i.e., a value of this end is related to a maximum of 1 value on the other end)?

If there is no semantic difference, is Property::isID only useful for attributes that are not association ends (like primitive attributes that are typically not ends)?

Assume a classifier A has a property that is an association end typed by B, and assume its opposite end has the
multiplicity 1..1.
Even if this implies that, at any time, only one instance of A can be associated with a given instance of B, nothing
stops this association from changing over time. Thus, a given instance of B cannot be used “a priori” for identifying
an instance of A. So there is no redundancy with the semantics of Property::isID as suggested by the issue.
Disposition: Closed - No Change

Several Figures has wrong package name shown. In all cases package name should be "Core" instead of "Constructs":

• Figure 7.3 - The Core packages
• Part II, Figure 2 - The Core package contains the packages PrimitiveTypes, Abstractions, Basic, and Constructs...
• Figure 9.1 - The Core package is owned by the InfrastructureLibrary pack...
• Figure 10.1 - The Core package is owned by the InfrastructureLibrary package...
• Figure 11.1 -The Core package is owned by the InfrastructureLibrary package...

Also, the package name should be shown on the tab.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

On page 35, Figure 7.15 the Namespace element is described as Namespace from Dependencies package, but (on page 103) Namespace element is defined from Kernel package only.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

look at Page 46, there is a typo in the word "metaatribute" in the sentence:
...
"AssociationEnd was a metaclass in prior UML, now demoted to a member of
Association. The metaatribute targetScope"

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Referenced UML Superstructure Version: 2.4 beta2

Issue:

In chapter 16 on use cases, a <<subsystem>> stereotype is applied to the subject (or system boundary) in three figures:

• Figure 16.5 - Example of the use cases and actors for an ATM system (p. 614)
• Figure 16.8 - Example of a use case for withdrawal and transfer of funds (p. 616)
• Figure 16.11 - Use cases owned by a package (p. 621)

According to Table B.1 - UML Keywords (p. 712), that specific stereotype is only applicable to Component. The subject of a use case is of type Classifier.

So the named diagrams are not syntactically wrong but slightly irritating to the reader because there is no indication that in these examples, the use case subject is actually a more specific type of a classifier, namely a component. The diagrams could lead to misinterpretations like "it is allowed to use the subsystem stereotype for any use case subject".

The textual description for Figure 16.5 does not clarify but only states "For example, the use cases shown in Figure 16.5 on page 614 apply to the “ATMsystem” classifier"
Regarding Figure 16.8 the accompanying text makes no clarification.
Figure 16.11 is even more confusing as it seems to be the case that the component being subject to the use cases is part of a package. Also the package name "ATMtopPkg" does not seem to be a good name for a package.

Recommendation:

1) Add textual description to explain the origin of the <<subsystem>> stereotype on the three diagrams
or
remove subsystem stereotype as UML examples should not include constructs of any profile (even if it is one of the standard profiles)

2) Rename "ATMtopPkg" in Figure 16.11 (e.g. to ATMNetwork)

Merged with 18071

Graphically, Constraints appear independently so the unordered
characteristric of NamedElement.ownRule seems sensible. However in a textual
rendering ordering is appropriate.

For instance, Constraints may sensibly be layered so that simple Constraints
come first and act as guards against redundant evaluation of later
Constraints.

For instance, when auto-generating a specification such as the OCL
specification, a specific ordering is required in the generated output.

Please change to

.

The ownedRule property is actually on Namespace, not NamedElement.
In general, it is not appropriate to add constraints to the abstract syntax in order to capture presentation issues, like the
textual rendering of an order. Further, the UML semantics provide no requirement that ownedRules be evaluated in
any particular order, so, as far as UML is concerned, there is no underlying meaning to such ordering.
Disposition: Closed - No Change

It seems there is an issue with derived Property.opposite.

Spec says:

/ opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end.

By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class.
It does not work when navigable end is owned by association:

Constraint #1:
[1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

Any comments?
Which one is correct? Property description or constraint text?

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

I noticed that all normative UML2.x infrastructure and superstructure documents have the same bug:

In ProfileApplications, under Associations, the following property is incorrect:

• importedProfile: Profile [1]
References the Profiles that are applied to a Package through this ProfileApplication.
Subsets PackageImport::importedPackage

It should describe the following property ProfileApplication::appliedProfile : Profile[1] as follows:

appliedProfile : Profile[1]
References the Profile that is applied to a Package through this ProfileApplication.
Subsets DirectedRelationship::target

In the UML2.xInfrastructure metamodel and the 2.4 beta2 merged metamodel
the documentation for ProfileApplication::appliedProfile should be changed from:

References the Profiles that are applied to a Package through this ProfileApplication.

to:

References the Profile that is applied to a Package through this ProfileApplication.

This affects the following documents:

UML2.4 Infrastructure & Superstructure beta2 (ptc/2010-11-16 and ptc/2010-11-14)
UML2.3 Infrastructure & Superstructure (formal/2010-05-03 and formal/2010-05-05)
UML2.2 Infrastructure & Superstructure (formal/2009-02-04 and formal/2009-02-02)
UML2.1.2 Infrastructure & Superstructure (formal/2007-11-04 and formal/2011-11-02)
UML2.1.1 Infrastructure & Superstructure (formal/2007-02-06 and formal/2007-02-05)
UML2.0 Infrastructure & Superstructure (formal/2005-07-04 and formal/2005-07-05)

This affects the following normative files:

http://www.omg.org/spec/UML/20101101/UML.xmi
http://www.omg.org/spec/UML/20101101/Infrastructure.xmi
http://www.omg.org/spec/UML/20090901/Infrastructure.cmof
http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
http://www.omg.org/spec/UML/20061012/Infrastructure.cmof

The same bug is also in the Documents/Specifications/2.4/Deliverable files in SVN revision 21132

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Subsection Associations is not in synch with the abstract syntax depicted in Figure 13.12.

In the abstract syntax, change expression is typed by ValueSpecification, whereas in Association section it is described as Expression.

Possible resolution:

Change changeExpression : Expression

to

changeExpression : ValueSpecification.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The textual syntax of CallEvent and SignalEvents states the following:

"<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
<assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

<assignment-specification> is optional and may be omitted even if the operation has parameters."

Does this mean that the parameters of the event are still assigned to attributes of the context object? If so, how long are those implicitly assigned
attribute values stored in the context object? Since this is just a workaround to be able to express guard conditions that evaluate whether a transition can fire based
on the recieved trigger, I would assume, the implicitly assigned attribute values are kind of transient or temporarly and will become invalid (or deleted) after all guards of the outgoing state are evaluated. Otherwise, I would like have this paragraph stated
clearer. It is a vital and crucial part how to deal with triggering events and with guard that refer to those trigger events.

There is no implication in this notation of “transient” or “temporary” assignment. The values are assigned to the given
attributes, which retain those values until reassigned. However, the exact mechanism for accomplishing the intent
behind this notation is not formalized in the specification. The UML 2.5 specification now includes the following
clarification (from Subclause 13.3.4):
“<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping
is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to
support this notation. If it does, it may provide a mapping to standard UML abstract syntax, e.g., by implicitly inserting
Actions to carry out the behavior implied by the notation.”
Disposition: Closed - No Change
Report

On page 177, Clause 12, second paragraph, in the middle, XMI is written
in small case, as "...whose xmi serialization...", maybe it's recomended
to write in upper case as in the rest of the document.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

On page 14, Figure 7.3 of the OMG Unified Modeling Language (OMG UML),
Infrastructure document, I think there's a small error in the picture.

The picture details the Core package, as explained in the text. But
the name in the top of the package is written as "Construct" (please
note that I'm talking about the name of the whole package, the left-
hand side one in the picture, and not the name os the sub-package
Construct itself).

It gets a little bit confusing that the name of the whole package
is written as "Construct" instead of "Core".

Please note also that the Figure "Part II, Figure 2" on page 27 is
the same. And Figure 9.1 on page 29. And Figure 10.1 on page 91. And
11.1 on page 103. And maybe others that I couldn't find now.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In “Figure A.3 Two Diagrams of Packages” the left most diagram has a header that says:

“i) Package symbol (as part of a larger diagram diagram)”

This text should be (as far as I can figure out)

“i) Package symbol (as part of a larger package diagram)”

Similarly, the paragraph before the diagram has the following text

“Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

To clarify this, make the following one word change

“Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a package diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

Accept the proposals

On page 9 of the OMG Unified Modeling Language (OMG UML), Superstructure
document, there is the same error (or maybe, typo) as in the Infrastructure
document. It's in the seventh bullet at the beginning of the page, where
it's written:

XMI Metadata Interchange (XMI)

Maybe the correct text would be:

XML Metadata Interchange (XMI)

That is, XML instead of XMI at the beginning of the phrase.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

On page 5 of the OMG Unified Modeling Language (OMG UML), Infrastructure
document, I think there's a small error (maybe a typo). It's in the last
line of this page, where it's written:

XMI Metadata Interchange (XMI)

Maybe the correct text would be:

XML Metadata Interchange (XMI)

That is, XML instead of XMI at the beginning of the phrase.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The textual syntax of CallEvent and SignalEvents states the following:

"<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
<assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

<attr-name> is an implicit assignment of the corresponding parameter of the operation to an attribute (with this name)
UML Superstructure Specification, of the context object owning the triggered behavior"

This may lead to a situation where name clashes can occurr, if the context object already contains an identically named attibute.
How should situations like a name clashes be resolved?

The corresponding wording in the UML 2.5 specification is (from Subclause 13.3.4):
“<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation
to a Property or Variable of the context object for the triggered Behavior.”
The “assigned-name” is the name of a Property or Variable that the context object already contains, not a definition of
a new attribute. There is therefore no possibility of “name clash”.
Disposition: Closed - No Change

In the OMG Unified Modeling Language (OMG UML), Infrastructure document,
it is said that this document, and the Superstructure document, should be
used in conjunction (page 9) as the two volumes cross-reference each other
and the specifications are fully integrated.

But on page 2 of the OMG Unified Modeling Language (OMG UML), Infrastructure
document we can find 2 compliance levels. And on page 2 of the OMG Unified
Modeling Language (OMG UML), Superstructure document (ptc/2010-11-14 version
2.4) we can find 4 compliance levels. Which is rioght ? Two our four ? As
both documents are integrated shouldn't them have the same explanation for
compliance levels ?

It gets a little confusing to understand this.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Figure 15.45 of superstructure v2.3 illustrates the representation of deferred triggers on states. The transition between states "Get Cups" and "Pour coffee" specifies a trigger "light goes out" which is also identified as a deferred trigger of state "Get Cups". Does "light goes out" trigger the transition, or is it deferred? If the figure is not wrong, it would probably be helpful to add a comment in the text (note that figure 15.45 is not referenced in the text).

Indeed, this is a very confusing example and is also wrong as the submitter points out. Also, there should
be some explanation of this diagram.
Replace this diagram with a simpler one and add some explanatory text.

According to the abstract syntax, Generalization::generalizationSet has upper bound *.

According to the text:

Package PowerTypes A generalization can be designated as being a member of a particular generalization set.

There is only one place where the possibility of many sets is mentioned, where it says:

“The generalizationSet association designates the collection of subsets to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into subsets (e.g., partitions or overlapping subset groups) using the generalizationSet association. Each collection of subsets represents an orthogonal dimension of specialization of the general Classifier.”

The first of these sentences implies that a Generalization can belong to many (“collection of”) GeneralizationSets. The second sentence contains a phrase “subsets (e.g., partitions or overlapping subset groups)” that makes little sense. Rephrasing “subset groups” as “subsets” gives us “e.g., partitions or overlapping subsets” which seems to imply that the GeneralizationSets may overlap. But then “Each collection of subsets represents an orthogonal dimension of specialization” translates to “each collection of GeneralizationSets represents an orthogonal dimension…” which is obviously wrong. Rephrasing as “Each GeneralizationSet represents an orthogonal dimension …” makes more sense: but if they are orthogonal, how can they overlap?

Then, in the notation and further explanations, there is no discussion whatsoever of the possibility of a generalization belonging to many GeneralizationSets.

I think this is clearly an error in the metamodel.

The text that the issue complains about is no longer in the spec. It’s clear that a Generalization can belong
in more than one GeneralizationSet: “The generalizationSet property designates the GeneralizationSets to
which the Generalization belongs.”
However, there is a misleading phrase in the Notation that could be improved.

UML specification does not provide exact rules for element names. For example, namespace "provides a means for resolving composite names, such as name1::name2::name3." What are the rules for the name1/2/3? Could we use spaces, dashes, digits?
For the class name we should: "capitalize the first letter of class names (if the character set supports uppercase)." But what are the rules for the class name? "A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse." But what are the rules for the use case name?

There are no rules for names in UML. The UML standard does not restricted what characters can be used in a name
or how the name is constructed.
Disposition: Closed - No Change

I downloaded (and partially read) the UML Superstructure file "10-05-05.pdf" from your site. That's one of two defining documents of UML 2.3.

Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose.

Agreed. This is diagram 14.5 in the new text.
Fix the diagram by replacing the second “entry” label with the label “exit”.

Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose

Merged with 16111

Typo: say join and not joint.

The notation for a fork and join is a short heavy bar (Figure 15.25). The bar may have one or more arrows from source
states to the bar (when representing a joint).

It should indeed be “join” and not “joint”. Correct the text appropriately