PROBLEM STATEMENT
"When one or more ends of the association have isUnique=false, it is
possible to have several links associating the same set of instances."
(Superstructure, p. 81)

As Pierre-Alain Muller demonstrated in an informal conversation with Bran
Selic during a lunch in San Francisco in the last UML Conference (I also was
taking part in that conversation), isUnique must have the same value for all
ends in an association.

This has implications, for example, for the property strings that can be
placed near the association ends (

,

,

). According to the
table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
the opposite end must be a Set or an OrderedSet, too; and if one end is a
Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

PROPOSED SOLUTION
Explain this in the Spec.

This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/
trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an
association end is derived from the links that instantiate the association as modified by the isUnique marking.
So, even if there are two links targeting an instance in the extent of the association, if the property is
marked as unique then there will only be one instance in the collection. This interpretation allows there to
be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation
is in fact the intended interpretation of the current spec, and should be clarified as such.
Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in
contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass
that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is
clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to
give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5.
This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently
nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it
once, then that should be legal, even though the size of the value of B is larger than that of A.
The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use
of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified
definition.
This also resolves issue 5977.

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

In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered

No Data Available

In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read

Indeed so.

The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.

No Data Available

In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly.

No Data Available

The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".

No Data Available

In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information.

The line should read:

protectedAction: Action [0..*]

No Data Available

In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type"

Remove one of the dots between protectedAction and availableOutput

No Data Available

The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.

see above

The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.

No Data Available

At the bottom of the page, the characters "antics." should be removed

No Data Available

Issue: Constructs::Class has a superClass property that redefines general,
which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
Constructs::Class also inherits from Basic::Class, which has superClass as a
property (section 10.2, 66, p. 97). What does this mean? Is this a bug?
Is it something correct having to do with package merge?

Recommendation: Determine whether this is intended or an oversight. If it
is an oversight, correct it. If not, explain the meaning of having these
both of these properties.

No Data Available

Issue: It appears that associations with neither end names nor
multiplicities on non-navigable ends are used in parts of the UML Core that
are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for
example. I understand that for elements defined via EMOF, this signifies a
simple property. But is it appropriate for elements defined with CMOF.

Recommendation: Either correct this by adding multiplicities and end names
or explain in the specification why it is alright to omit them in these
cases

The meaning of this convention should be explained in the document.

PROBLEM STATEMENT
According to Superstructure, p. 430, the notation for messages in
interaction diagrams is as follows (we put assumptions between parenthesis):

asynchronous message - (solid line) open arrowhead
synchronous message - (solid line) filled arrowhead
reply message - dashed line (filled or open arrowhead?)
object creation - dashed line open arrowhead

However, the example given in Figure 333, p. 414, shows a different
notation:

asynchronous message - solid line open arrowhead (not shown in this diagram,
but in others)
synchronous message - solid line filled arrowhead
reply message - dashed line OPEN arrowhead
object creation - SOLID line open arrowhead

Another confusing aspect of the notation is that in a reply message, which
is not a true message, the message name is the name of the operation invoked
on the callee (same as in the corresponding synchronous call), but it
suggests instead that there is an operation with this name in the caller. In
Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
operation named foo in class C1, which is wrong: foo is defined in C2, not
in C1. It would make more sense to label a reply message with the name of
the value returned.

PROPOSED SOLUTION
The simplest solution would be to fix Figure 333 using a dashed arrow to
represent object creation, although this would yield the same notation for
object creation and reply message. Therefore, beyond this simplest solution,
we propose something more advanced: First, state explicitly the notation for
all kinds of messages, leaving no place for assumptions. Second, use a
filled arrowhead for reply messages, since this emphasizes the conceptual
proximity to the synchronous message it is a reply from. Third, use the
notation for object creation also for object deletion, which currently is
not mentioned. That is:

asynchronous message - SOLID LINE open arrowhead
synchronous message - SOLID LINE filled arrowhead
reply message - dashed line FILLED ARROWHEAD
object creation OR DELETION - dashed line open arrowhead

Or better, simply drop object creation as an special kind of message. Object
creation (and deletion) was not considered a special kind of message in UML
1, and it is not at all clear why it should be in UML 2. Probably, an object
creation is either synchronous or asynchronous, but not "something else" in
the same meta-specialization row. In fact, the constraints and semantics of
Message (Superstructure, p. 429) do not consider object creation as
messages: "The signature must either refer an Operation (...) or a Signal",
"A Message reflects either an Operation call (...) or a sending and
reception of a Signal". Neither does the meta-attribute Message.messageSort,
which has the following permitted values: synchCall, synchSignal,
asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
mean? The "sorts" of message are not defined in the Spec. Although calls are
considered in other places to be either synchronous or asynchronous, signals
are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
and 395), therefore at least synchSignal is banned.

Finally, we also propose to label reply messages with the name of the value
returned by the operation call, not the operation name itself. In Figure
333, this would leave the replies foo() and doit() without label, and the
last reply would be labeled simply as "x".

see above

I didn't recognize it before, but now I am surprised that the action
symbol
is not the same as the UML1 activity symbol ("shape with straight top
and bottom
and with convex arcs on the two sides").
Actions are no activities, but the semantic is similar for
the "normal" UML user.
In UML1 the user has to distinguish between the activity symbol and
the state symbol ("round-cornered rectangle"), especially if states
and activities
are shown within the same diagram.
Now you has to use the UML1 state symbol for actions. I think that
this is confusing
for the normal UML user.
Another point is that the action symbol is the same as the state
symbol. There will
be no chance for a misunderstanding, because both symbols are not
allowed within the same
diagram. But it would be much clearer if the action symbol has a
different notation and
looks like the UML1 activity symbol.

So, why not using the UML1 activity symbol for UML2 actions?

No Data Available

The current Infastructure document defines it at page 54 as (line
numbers have been added by me):
(1) multiplicity ::= multiplicity_range
(2) multiplicity_range ::= [lower '..'] upper
(3) lower ::= integer
(4) upper ::= unlimited_natural | '*'

But at page 56 (also page 20 of the Superstructure document which
copies
the definition) it says:

(5) multiplicity ::= multiplicty_range [

]
(6) multiplicity_range ::= [lower '..'] upper
(7) lower ::= integer | value_specification
(8) upper ::= unlimited_natural | '*' | value_specification
(9) order_designator ::= ordered | unordered
(10) uniqueness_designator ::= unique | nonunique

There are several problems arising from this definition:

(P1) (9) and (10) are never used
(P2) Defining the lower bound as "integer" (according to page 142 of
the
Infrastructure document) allows it to specify multiplicities with
lower bounds below 0 (e.g. [-5..7], [-42..0])
(P3) (4) and (8) include the asterisk symbol to denote an
infinite
upper bound. Though, this is redundant since the symbol is already
there
as part of the lexical representation of unlimited_natural (according
to
page 144 of the Infrastructure document)
(P3) (4) and (8) define the upper bound using the datatype
"unlimited_natural" which comprimises all integer numbers starting
from
zero. Thus multiplicities like [0..0] would be legal.
(P4) It should be mentioned that the lower part is lower or equal to
the
value given for the upper part (where '*' is geater than any other
element of the set named integer). Otherwise multiplicities like
[8..2]
would be considered legal.
(P5) What is the role of the value_specification mentioned at (8) and
(9) isn't it redundant there?

Or am I just misreading the spec?

No Data Available

At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted – it makes no sense to have a dependency independently of the depending (source) element.

No Data Available

Description: Consider the following recommendations to improve Information
Flow semantics:
b) Allow Information Flow to be specialized and decomposed using
aggregation.
c) Allow Information Flow between classifiers with ports and interfaces.
Make provisions for relating the information flow to a port, such that an
Information Flow can flow through a port.
d) Allow Information Flows between classifiers with object flows across
activity partitions.
e) Change the name from Information Flow to Item Flow (or something similar)
to allow for the flow of non-information, such as physical items specified
in systems engineering applications.

see above

Description: The following are some recommendations to improve Activity
diagrams for systems engineering applications:
a) Generalize pins so that they can be applied to control as well as data.
b) Clarify how activity diagrams can be used to represent continuous
behavior (e.g., streaming input).
c) Clarify how an object node to represent a role.

No Data Available

Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
opposite =
if owningAssociation->empty() and association.memberEnd->size() = 2 then
let otherEnd = (association.memberEnd - self)->any() in
if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
else Set {}
endif

See issue 8451 for disposition

Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities

No Data Available

There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine

<--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.

No Data Available

Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3

No Data Available

Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well.

I believe this violates a well-formedness rule that all structural features must be distinguishable.

See issue 8461 for disposition

TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template.

No Data Available

pg. 75: StructuralFeature::isReadOnly
Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values:

Changeable (unrestricted)

readOnly (no changes after initialization)

[Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.]

The following additional choices were available in UML1:

CreateOnly (add a set any time after initialization but no further changes)

addOnly (may add members to the set but not change or remove any)

Both of these occur in practice often enough.

see above

The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
the keyword «represents»." and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish.

see above

In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled.

No Data Available

Issue: The UML infrastructure specification does not specify the syntax for names. This prevents model interchange.

Proposal: Specify the syntax for the string in Name. At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.

Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.

[After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job. Or, in any event, get us started.]

No Data Available

PROBLEM STATEMENT
There is no definition for navigability or navigation in the Spec. Other
concepts of similar importance, such as visibility, multiplicity, etc., are
defined in the Spec, so it is not clear why it should be assumed that this
concept does not require a definition.

PROPOSED SOLUTION
Add definition in Section 4 (Terms and definitions): The navigability of a
binary association specifies the ability of an instance of the source
classifier to access the instances of the target classifier by means of the
association instances (links) that connect them. Navigability is closely
related to the possibility of sending messages through associations (a
message cannot be sent through an association instance against its
navigability, that is, navigability is required for sending messages through
associations), but they remain nonetheless different concepts.

Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change

"An instance specification is a model element that represents an instance in a modeled system." [7.7.1] That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.

At the same time, a lifeline represents a connectable element. [14.2]

This is an example of a recurrent problem in the specification: model elements that represent other model elements.

At the same time, "attributes of a class are represented by instances of Propert[ies]..."

This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.

The theory of representation needs to be settled. That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.

No Data Available

Class Diagram:Constructs/Packages in the Rose file shows the
nestedPackage/package association the spec shows
nestedPackage/nestingpackage

I believe the spec to be in error...

I am not sure where to report this and or who keeps this model up to
date. Any recommendations would be appreciated

No Data Available

Issue: The superficial impression that Core::Abstractions is the lowest
layer in the U2P Core does not stand up under close examination.
Core::Basic is closer to being the fundamental layer because it uses none of
the new association modeling constructs (such as derived unions and subsets)
to define itself; but is not entirely so because it imports two packages
from Abstractions.

Recommendation: It would be worth considering whether the two packages that
Basic imports from Abstractions can be placed in Basic, so that Basic is
unambiguously the lowest layer in Core. This would also make EMOF
unambiguously the lowest-—i.e. the most fundamental—-layer of MOF, since
EMOF is based on Core::Basic while CMOF is based on Core::Constructs.

No Data Available

Constructs association owningCommet:Element[0..1] c-> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c-> ownedCommet:Comment[0..*] as defined in Kernel/Root.

see below

There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical.

It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?

closed no change

I believe I found an omission from the UML 1.5 Specification formal/03-03-01:

p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"

In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".

p. Index-1 cites "Action" p 2-103.

p. 2-103 has no mention of "Action".

The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.

My question is what is definition of the "Action" Class in Fig. 2-18?

closed no change

3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) =============================================

according to the logic upperbound is the same as the lower bound.

should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?

closed no change

In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies

see above

Secondly, there are two classes "NamedElement" holding un-redefined
attribute "name", one is in the
package "InfrastructureLibrary.Core.Basic", and the other is in the
package "InfrastructureLibrary.Core.Abstractions.Namespaces". The
problem is that there are a lot of classes directly or indirectly
inheriting both of them e.g. class "InstanceSpecification" in package
uml.classes.kernel, and it causes problem of duplicated parameters in
class creation in the generated JMI interfaces. e.g.
"
public InstanceSpecification createInstanceSpecification
(java.lang.String name,
infrastructurelibrary.core.abstractions.visibilities.VisibilityKind
visibility, java.lang.String name, java.util.Collection classifier);
"
Similiar cases happen to attribute "type", "isAbstract" etc.

No Data Available

The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].

No Data Available

At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.

No Data Available

In the last paragraph, the period after the word "collections" on the second line should be removed

No Data Available