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.

There are less diagram kinds defined than UML diagrams. In particular I miss a diagram kind for object, deployment and composite structure diagrams

current text (688): UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors

[AC] I believe here one or more constraints are missing. The associations an Actor can have are correctly constrained (see page 694) to be only with UseCase, Class and Component.
A UseCase, in my opinion and in the whole literature that I know, can only have associations with Actors (while it can have other types of relationship, such as dependencies with other classifiers).
If I am right, then also what is written on page 688 - “UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors).” - should be corrected.

I've also doubts on the following constraint: “UseCases can not have Associations to UseCases specifying the same subject.”. In my opinion, and in my interpretation of what is written on page 686, UseCases can not have Associations to UseCases, whether they specify or not the same subject.

What form of association may exist among UseCases specifying different subjects?

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.

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

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

is self-contradictory. IF (a generalization set consists of a single class AND it is

generalization set is the null set, and the null set is a member of every set. In other words, the combination

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.

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'.

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).

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.

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

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.

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.

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.

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.

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

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.

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.

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

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]

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.

Problem 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) is having relationship redefinedBehavior, that should be derived

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.

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