There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: “contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)”.

Issue 4848 also raises a similar problem with Namespace.contents

I am trying to properly designate an exception returned from a message sent to a Java object.

In UML a return is drawn as a dashed line with an open arrow. But is that the same for an exception returned? I can stereotype a return with the <<exception>> which is fine , but how do I properly draw the returned exception. I don't think the exception should be drawn the same as an asynchronous signal because control pops out from the exception raiser and returns to the callee at the exception handling point (it is the result of the original call, but the exception return is to a different point in the flow).... so it isn't exactly a signal.... but it does alter the control flow..

So in my mind, if I wanted to show a returned exception, I should draw it like a return (dashed line with open stick arrowhead) labelled <<exception>>

But I defer to someone with more expertise to untangle this for me. I spent time and could not find an answer to this in the UML 1.4 docs

This is a subset of the issue addressed by issue 7397.

Behaviors: objects that don't exist?

At 13.1 we read:

"Behaviors, as such, do not exist on their own, and they do not communicate. ... (Note that an executing behavior may itself be an object, however.)"

It is not clear what this is intended to mean. To the untutored reader it seems to be a contradiction.

What a behavior is and what a behavior execution is is fundamental to this half of UML. Whatever is intended should be spelled out clearly for the reader, very clearly.

see above

Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

No Data Available

Why there are two different Backbone Diagrams in the UML 1.5 Specification. The one on Page 71 shows that a Feature has a visibility and a ModelElement has just a name, nothing more. On Page 596 an Feature has the visibility not anymore, but ModelElement has one, how this should be interpreted, which one is the right visibility

No Data Available

The package structure of UML 1.3 makes it difficult to deploy small parts of
the "physical" metamodel separately. For example, a MOF-based facility that
supports classes from Behavioral_Elements.Common_Behavior must support all
of Behavioral_Elements. A facility that supports Exceptions must also
support Use Cases and State Machines. This has been a problem in the
formation of the CWM metamodel which extends UML. Its interfaces and DTDs
are made to be much too large.

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

No Data Available

According to the UML 1.4 metamodel, a ModelElement can contain any number of
taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

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

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

If not, at simple well-formedness rule

self.taggedValue = { }

attached to TaggedValue would do the trick.

see above, resolved

The semantics of classifier ownerscope is ambiguous for structural
features declared on classifiers that have children. It is not
defined whether this gives value for the classifier and all its
descendents, or values for the classifier and each descendant
separately.

see above

This is a general issue that is quite pervasive. I think it is important
enough to be considered by the FTF.

The specification is littered with keywords which are used on diagrams
to indicate various things.

What the specification sorely needs is an Appendix that gathers them all
together. And cross-references each with where it is defined and the
compliance level it is associated with.
Also what it needs is a general description of the semantics of
keywords, how they differ from 'Standard Stereotypes' and associated
constraints - e.g. it should not be allowed to declare a Stereotype with
a name which, when decapitalized, is the same as a keyword (since they'd
be indistinguishable).

Arguably keywords would be depicted with a distinct notation from
stereotypes (based on language design principles and to help users
interpret diagrams where they see words in guillemets and don't know
whether to look it up in the list of keywords or stereotypes) but that
is probably too major a change to make at this stage. However the
notation should be clarified to cover the following cases:
A) if the same element requires a keyword and has a stereotype applied
are they shown in 2 separate <<xxx>> expressions or in one, separated by
a comma?
B) if a stereotype is applied to a class normally indicated by a
keyword, does that keyword still need to be provided?

see above

This is in my opinion important enough to be considered by the FTF since
it affects implementability.

Appendix B contains a list of Standard Stereotypes.
Ironically, due to the nature of the UML2 Profile mechanism this
mechanism is more heavyweight than a subclass since it requires a
separate instance - so for the <<call>> stereotype of Usage one ends up
with not only a instance of Usage but an attached instance of Call -
this is far more heavyweight than having a distinct subclass of Usage
which would result in only one object. And it's also harder to process
via XMI or APIs.

The Appendix is not adequate as a definition and does not use the
official Stereotype notation? In particular it does not make clear the
name of the instance of Stereotype (which I can only guess would be the
capitalized form of the stereotype keyword e.g. "Call"), nor does it
specify the name of the association used to attach an instance of the
stereotype with the instance of the metaclass. And, of course, is there
actually a Profile object (or objects) that contains these stereotypes?
Can users consider this Profile already applied to any UML model or does
it have to be explicitly done or is this a variation point?

Finally, Appendix B is not properly referenced: 7.14.1 refers to the
"Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
Standard Profile".

see above

The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

see above

"The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

Should be "Figure 58"

see above

Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

see above

In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

see above

ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

see above

The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

see above