In section 8.3.2, a "Connector" is defined as either a "delegate" or an "assembly" connector. The definition is based on "required port" resp. "provided port". However, these terms are not defined in the document; furthermore, they do not make sense at all. In section 9.3.11, a port is defined to have "provided" and/or "required" interfaces, which are well-defined. However, in the whole document is no definition for a "provided port" or "required port". From my understanding, such a thing does not make sense at all. A port is a point of interaction, and the terms "provided/required port" are non-sense. Please, provide a definition of "provided port" and "required port", or remove the corresponding sections. I hope I could help You with Your great work, Yours, Dr. Uli Margull PS: I came across this topic when working for the AutoSAR standard (car manufacturer and OEMs). They have the same unclear usage of "provided port" and "required port", and looking into the UML standard 2.0 did not help me to resolve this issue.

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

Figure 12 of the 040814 rev has the association from Property to
Association as derived:

memberEnd /association
Property ----------------------------------> Association

and it wasn't derived in the FAS. The issues cited are: 6243 and 7365,
but neither mentions the change. The derivation is not explained in the
association entry on Property. Is this a metamodel typo?

No Data Available

In my interpretation of the current semantics description of UML
activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
have identified some rather unpleasant properties of the current
traverse-to-completion semantics. The full discussion together with
examples can be found in the attached .pdf, the short of it is:

*) the current semantics does not prevent deadlocks (as it is
supposed to do)

*) it rather induces deadlocks even in simple examples (e.g. examples
in the UML spec are wrong)

*) it makes for a very complex evaluation and introduces unnecessary
synchronization in the (basically asynchronous) notation of Activiy
Diagrams.

I therefore propose to relax the semantics of token flow by dropping
the constraint that every Action has to accept all tokens for all its
input pins at once. MergeNodes should als be able to buffer tokens
until their conditions are satisfied. This is a more natural way of
interpreting ADs.

This is a duplicate of issue 7221

Page 155 of the Infra Adopted Spec ptc/03-09-15 [sic] I think the date order got changed from Euro to US on this
Page 101 of the Super "Final" Adopted Spec ptc /03-08-02 [sic] The date says August 2003

withdrawn by submitter