Issues for UML 2.4 Superstructure and Infrastructure Revision Task Force

To comment on any of these issues, send email to uml2-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3898: Specify XMI parameters for the UML / XMI interchange format (uml2-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

When the UML spec standardises an XMI-generated interchange format for 
UML
models, it should include:

  * the "input" MOF meta-model for UML that was used to generate the
    interchange format, and

  * a formal statement of the other XMI "parameters" used to generate
    the interchange format.

If possible, the UML spec should include a definitive meta-model for 
UML
expressed as a MOF / XMI document.  This is a MOF alignment issue.

Resolution:
Revised Text: In appendix G of the Superstructure document (formal/05-07-04) and appendix A of the Infrastructure document (ptc/04-11-16) add the following sentence as the last sentence in The XMI specification corresponding to this specification can be found in OMG document Editor�s note: This is actually redundant and superseded by the resolution to 8678
Actions taken:
September 22, 2000: received issue
August 23, 2006: closed issue

Discussion:

alignment is strong 2.0 requirement

Issue 4448: Does visibility apply to creating an destroying links? (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

  It isn't clear whether visibility of association ends applies to
     creating and destroying links.  If it does, then what if one end is
     private and the other public, can the private end create or destroy
     a link?

Resolution: see above
Revised Text: In Superstructure, Classes, and in Infrastructure, Core::Abstractions, Visibility package NamedElement Attribute, visibility entry, change description to �Determines where the NamedElement appears within different Namespaces within the overall model, and its accessibility.� Semantics, second paragraph in Superstructure, first paragraph in Infrastructure first sentence, replace �in different namespaces within a model� with �, either in namespaces or in access to the element. second sentence, replace �import and generalization� with �import, generalization, and access�. VisibilityKind, Semantics, first paragraph, replace "and Packages packages" with ", Packages, and Classes packages" in Superstructure, and with �, Packages, and Classifiers packages� in Infrastructure. In Superstructure, Classes, and in Infrastructure, Core::Basic Class, Semantics, at end, add new paragraph: "A class cannot access private features of another class, or protected features on another class that is not its supertype. When creating and deleting associations, at least one end must allow access to the class." In Superstructure, Actions WriteLinkAction, Constraints, add new constraint "The visibility of at least one end must allow access to the class using the action." CreateLinkObjectAction, Semantics, first sentence, after "semantics" add "and constraints".
Actions taken:
August 3, 2001: received issue
August 23, 2006: closed issue

Discussion:

More time is needed to consider the interaction of visibility with associations, to align it
with visibility of properties....The specification inadvertently omitted that visibility constrains access, as well as
importation and inheritance. In the particular case of classes, visibility constrains the
actions of methods of the class. Creation and destruction of links should be allowed by
methods that have access to at least one end of the association.

Issue 4937: Sending a signal after a delay (uml2-rtf)

Click here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Sending a signal after a delay

Resolution: The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).
Revised Text: closed no change
Actions taken:
March 5, 2002: received issue
October 22, 2002: deferred
October 27, 2008: closed issue

Discussion:

Can't handle time the way state machines, with expressions, because
  action model needs to be more precise.
Why not on other actions besides SendSignalAction?
What is the relation to the time submission?
Too much for FTF. [Action Semantics FTF]: Can't handle time the way state machines, with expressions,
because action model needs to be more precise. Why not on other actions besides
SendSignalAction? What is the relation to the time submission? Too much for FTF.
Too much of an enhancement for FTF, as indicated in the issue report. In the meantime,
modelers can define actions for time delay.

Issue 5593: Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace ) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents) 

The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter ! 

2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of �accessable� objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by �friend� Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors (�contents� instead of �acessable�).

Resolution: Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
August 25, 2002: received issue
December 28, 2004: moved to UML2 RTF
October 27, 2008: closed issue

Issue 5794: Designates a Generalization (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The text: 

Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement. 

disagrees in plurality with the * cardinality of the generalization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

Resolution: closed no change
Revised Text:
Actions taken:
December 15, 2002: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:

This pertains to a part of the UML 1.4 spec which is completely changed in UML 2.0.

Issue 5804: 2.5.2.27 ModelElement (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The text "deploymentLocation The set of locations may differ. Often it is more restrictive on the child." has no corresponding association in any diagram. The closest match is documented in 2.5.2.12 Component on pages 2-31 and 2-32. If this is the non-inherited feature discussed on page 2-44 is it not redundant and doesn't it cloud the meaning of the feature?

Resolution: closed no change
Revised Text:
Actions taken:
December 19, 2002: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:

The referenced section 2.5.2.27 is from the UML 1.5 specification (formal/03-03-01,
page 2-43). The reference to deploymentLocation was not carried forward into UML 2.0.
In UML 2.0, �deploymentLocation� is a String attribute of DeploymentSpecification
(formal/05-07-04, section 10.3.5, page 199).

Issue 5896: logic upperbound is the same as the lower bound. (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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?

Resolution: closed no change
Revised Text:
Actions taken:
April 4, 2003: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:

This pertains to an area in previous versions of UML that has completely changed in
UML 2.0. The issue is no longer relevant.

Issue 5907: formal/03-03-01 : Omission of definition of Class "Action" (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: closed no change
Revised Text:
Actions taken:
April 21, 2003: received issue
December 28, 2004: moved to UML2 RTF
August 23, 2006: closed issue

Discussion:

UML 2 Revision Task Force Disposition: Closed, no change
OMG Issue No: 5907
Document ptc/06-01-01 Page 621
OMG Issue No: 5907
Title: Formal/03-03-01: Omission of Definition of Class �Action�
Source:
Kurt Stephens, ks@kurtstephens.com
Summary:
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?
Discussion:
This pertains to parts of an older version of the UML spec (1.5) which has completely
changed in UML 2.0. This issue is no longer relevant.
Disposition: Closed, no change

Issue 6002: relationship should just be a cross-reference (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

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?

Resolution: closed no change
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

It was an explicit design decision to split off the Abstractions hierarchy from the part of
the Infrastructure that supports the UML and MOF modeling languages. The general idea
behind the Abstractions concepts is to provide a potentially useful �grab-bag� of
metamodeling patterns that might prove useful some day in as yet unknown modeling
languages. On the other hand, the Basic and Constructs packages are specifically
designed to support the MOF and UML languages. The separation is intended to ensure
that MOF and UML remain unaffected by the needs of future modeling languages.

Issue 6003: document appears to be inconsistent in how it handles concepts (uml2-rtf)

Click here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Critical
Summary:

This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept. 

In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell. 

I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group. 

Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This issue relates to the old version of Infrastructure. In this case, there is clearly a
misunderstanding on part of the submitter about the architecture of the Infrastructure and
the semantics of package merge. Once these are understood, the issue disappears.
However, it is definitely the case that the introductory text describing the architecture and
the role of package merge are extremely unclear and need to be fixed. These will be dealt
with as part of the resolution to issue 6002.
Disposition: Closed, no change

Issue 6004: Relationship and DirectedRelationship in Core::Constructs (uml2-rtf)

Click here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Minor
Summary:

There doesn't seem to be any value in the specialization of Relationship and DirectedRelationship in Core::Constructs from their definitions in Core::Abstractions::Relationships. The documentation clearly states that the specializations don't add anything to the either concept. In fact, it appears that this can be said for everything in the Core::Constructs Root Diagram. 

If this is the case, why do these specializations exist? The UML spec is big enough - there is no point in adding things that don't need to be there. If the goal is to merely create a single diagram that includes concepts and relationships that were previously spread across multiple diagrams, then why not simply create the diagram and have every contained concept refer to the package where it was originally defined? 

If there is a compelling reason for these specializations, then that reason needs to be spelled out in the spec - because it isn't obvious to me.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

See the resolutions to issue 6002 and 6003.
Disposition: Closed, no change

Issue 6005: cross-reference missing (uml2-rtf)

Click here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Significant
Summary:

The reference to TypedElement in the Expressions diagram for Core::Constructs makes no cross-reference to the definition of TypedElement in Core::Abstractions::TypedElements or Core::Basic. 

Is it a reference to either of these or is it yet another definition of a concept with the same name?

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This is intentional because Abstractions and Basic are de-coupled from each other in the
latest version of the Infrastructure. This allows the two to evolve independently.
However, this is not explained very well (and is even incorrect) in the introduction to the
Infrastructure, which needs to be rewritten substantively to clarify how these things relate
to each other. That will be handled as part of the resolution to issue 6002.
Disposition: Closed, no change

Issue 6006: Classes diagram of the Core::Constructs package (uml2-rtf)

Click here for this issue's archive.
Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com)
Nature: Clarification
Severity: Significant
Summary:

In the Classes diagram of the Core::Constructs package, the references to StructuralFeature, Relationship, Type, and Classifier have no cross-reference to the package where they were originally defined, whereas other concepts in this diagram do. It is clear from the fact that some of these concepts are involved in derived roles or relationships, that they MUST have been defined somewhere else. 

The document needs to be fixed so that it is self consistent and so that proper cross-references are indicated.

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

See the resolutions to issues 6005, 6003, and 6002.
Disposition: Closed, no change

Issue 6082: Suspension Region (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Enhancement
Severity: Minor
Summary:

�Supspension region� is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call. 

This has been flagged as a potential FTF issue before.

Resolution: Discussion: This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision. Disposition: ClosedOutOfScope
Revised Text:
Actions taken:
August 29, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

This is a concept that highlights a syntactic requirement. Often users think that
suspension is always the case between call and reply, but since lifelines may be
decomposed into independent sub-parts, this is not necessarily the case. That is why it is
needed to clarify a synchronization situation. Still it is a new concept, and cannot be
considered critical for the use of Interactions.

Issue 6111: Reentrancy 1 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

How is the effect if isReentrant achieved for actions other than call
actions?  isReentrant is only on behaviors.  Perhaps it should also be
available on actions and operations

Resolution: The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default. In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.
Revised Text: In Figure 12.2, add the attribute declaration "isLocallyReentrant: Boolean = false" inside the class box for Action. In Subclause 12.3.2 Action, under Attributes, add at the beginning: Package FundamentalActivities � isLocallyReentrant: Boolean If true, the action can begin a new, concurrent execution, even if there is already another execution of the action ongoing. If false, the action cannot begin a new execution until any previous execution has completed. The default is false. Under Semantics, replace the paragraph If a behavior is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a nonreentrant behavior does not start the behavior when the behavior is already executing. In this case, control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise. An invocation of a reentrant behavior will start a new execution of the behavior with newly arrived tokens, even if the behavior is already executing from tokens arriving at the invocation earlier. with: If an action is not locally reentrant (isLocallyReentrant=false, the default), then no more than one execution of it will exist at any given time within the context of a single execution of the containing activity. Even if the action would normally begin an execution according to the rules above, it will not start a new execution if there is already one ongoing within the same activity execution. In this case, the action simply does not accept any tokens offered to it until its ongoing execution has finished. At this point, if the required tokens are still available, the action may accept the offers and begin a new execution. On the other hand, if an action is locally reentrant (isLocallyReentrant=true), then it will begin a new execution any time the rules above allow it, even if there are one or more executions already going within the same activity execution. This means that there may be, within any one execution of the containing activity, more than one concurrent execution of the action ongoing at any given time. A call action for a non-reentrant behavior will also act locally non-reentrant, whatever the value of the isLocallyReentrant property for the action. Moreover, an invocation action for a non-reentrant behavior will not execute if there is any currently running execution for the behavior, whether invoked by this action or any other (see "CallAction" (from Basic Actions) on page xxx). In Subclause 11.3.8, under Semantics, after the first paragraph, add: If the behavior invoked by a call action is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a non-reentrant behavior does not start the behavior when the behavior is already executing. An invocation of a reentrant behavior may start a new execution of the behavior when offered the required tokens, even if the behavior is already executing. However, it will not invoke the behavior if there is an ongoing behavior execution invocated by the same action within the same activity execution, and the action has isLocallyReentrant=false (see "Action" (from CompleteActivities, FundamentalActivities, StructuredActivities) on page xxx). Disposition: Resolved
Actions taken:
August 30, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

A resolution of this issue has to await further clarification of the activity view of
reentrancy. This issue should be resolved in a manner consistent with activities, if
possible. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 6176: UML 2 Super/Metamodel::Constructs/owningComment (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see below
Revised Text: The issue identifies as real problem in the Rose model InfrastructureLibrary.cat file. The offending "owningComment" association end name appears only in this file (most recent version: ftp://ftp.omg.org/pub/UML_2.0_superstructure-ftf/_UML2 Super.MDL.040711.zip) and does not appear in either the UML 2.0 Superstructure FAS (ptc/03-08-02) or the UML 2.0 Infrastructure FAS (ptc/03-09-15). Proposed Resolution: In the InfrastructureLibrary.cat file, change the name of the association end InfrastructureLibrary::Core::Abstractions::Comments::owningComment to InfrastructureLibrary::Core::Abstractions::Comments::owningElement. Revised Text: Editor�s note: This was fixed in the metamodel � however, it also required a change to the diagram in figure 9.10 In the InfrastructureLibrary.cat file, change the name of the association end InfrastructureLibrary::Core::Abstractions::Comments::owningComment to InfrastructureLibrary::Core::Abstractions::Comments::owningElement.
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

The issue identifies as real problem in the Rose model InfrastructureLibrary.cat file. The
offending "owningComment" association end name appears only in this file (most recent
version: ftp://ftp.omg.org/pub/UML_2.0_superstructure-ftf/_UML2-Super.MDL.040711.zip) and does
not appear in either the UML 2.0 Superstructure FAS (ptc/03-08-02) or the UML 2.0
Infrastructure FAS (ptc/03-09-15).
Resolution: In the InfrastructureLibrary.cat file, change the name of the association end
InfrastructureLibrary::Core::Abstractions::Comments::owningComment to
InfrastructureLibrary::Core::Abstractions::Comments::owningElement.

Issue 6187: UML 2 Super/Metamodel::Super/missing merge (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

No packages from Abstractions are currently merged into any compliance level pending
reorganization of Abstractions.
Disposition: Closed, no change

Issue 6194: UML 2 Super/Package merge/redefinitions issue - lost association ends (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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 {redefines ownedBehavior} <--> 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.

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

Property ownedStateMachine:StateMachine has been removed as a result of other issue
resolution, so this particular problem no longer exists. Other instances of lost association
ends resulting from package merge are handled in their own specific issue.
Disposition: Closed, no change

Issue 6197: UML 2 Super/Metamodel::Kernel/missing merges (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

No packages from Abstractions are currently merged into any compliance level pending
reorganization of Abstractions.
Disposition: Closed, no change

Issue 6201: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: See issue 8451 for disposition
Revised Text:
Actions taken:
September 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 6216: UML 2 Super/pg.75/kinds of changeability (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: Infrastructure Spec: Remove section 9.2.1 ChangeabilityKind. It s not part of the UML2 metamodel and is not referenced anywhere else in the InfrastructureLibrary or Superstructure specification.
Actions taken:
September 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

The only subclass of abstract metaclass StructuralFeature in UML2 is Property which
already has ownedAttribute isReadOnly: Boolean. This property comes from package
Basic and is part of the alignment with MOF2.
MOF2 also has a number of rules about initialization of read-only properties that may
make the distinctions between changeable and readOnly unnecessary. It is not clear what
the value for createOnly would be over having a default for a read-only property. And
addOnly semantics may be better handled by the containing class rather than the feature
itself.

Issue 6262: UML 2 Super / Templates / TemplateParameter not named (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 23, 2003: received issue
August 23, 2006: closed issue

Discussion:

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 temp late.
Discussion:
The real problem is not the one stated above. This is because there is a mistaken
assumption here that the metamodel element called TemplateParameter models the actual
parameter. Instead, it is merely a �pointer� to the parameter. A more precise name might
be to call it ParameterReference or ParameterSelector. But, such a change would require
a very careful examination of the very, very many references to the term �template
parameter� to distinguish whether it refers to the actual parameter or to the reference to
the parameter. This is a significant change that, arguably, is out of scope of this FTF,
since it is not something that is broken or inconsistent in the spec. The metamodel element called TemplateParameter is merely a �pointer� to some named
element owned by the templateable element (e.g., an attribute) that has been designated
as a template parameter. Therefore, there is no need for TemplateParamter to be a named
element, since it is never referenced.
Disposition: Closed, no change

Issue 6275: raisedException (uml2-rtf)

Click here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: See issue 8461 for disposition
Revised Text:
Actions taken:
September 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

The spec explicitly states that such redefinitions need to be made explicitly. This is
related to the resolution to more general issue 8461. Any resolution to this issue will be
resolved as part of the resolution to 8461.

Issue 6372: Notes versus curly braces (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity:
Summary:

Why do decision input behaviors use the note notation and join
specification use curly braces?

Resolution: A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and"). Revised Text: None Disposition: Closed, no Change
Revised Text:
Actions taken:
October 20, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

This is does not affect usage or implementability enough for the FTF to address,
and requires too many changes. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 6389: Syntax of names (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 22, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

The name of a metaclass is captured in a MOF String, which in XMI is enclosed in
quotation marks. Therefore, there is no problem with model interchange here.
The reason there are no syntax restrictions on names is that it provides latitude to support
different naming conventions used in different contexts and languages. Restricting this
could prove to be an impediment to the use of UML in situations that have their own
idiosyncratic rules for names.
Disposition: Closed, no change

Issue 6398: UML 2 Super / Kernel features / cannot exclude superclass properties (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
August 23, 2006: closed issue

Discussion:

This may be the case, but modifying this aspect of UML exceeds the bounds of FTF
scope. Excluding inherited properties makes the meaning of specialization/generalization
unpredictable and violates a common invariant of object-oriented systems. Generalization
is not always the best way to model relationships between classes, and the desire to
redefine or remove inherited properties is often a good indication that delegation should
be used instead. Delegation is especially useful in situations where classes need to be
decoupled for change management or other reasons.
Disposition: Closed, no change

Issue 6405: UML 2 super / Dependencies / improper subsetting? (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty...

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Resolution:
This is already resolved in the UML 2.2 specification.
Revised Text:
None.
Disposition:	Closed No Change

Issue 6422: Section 9.3.3 (uml2-rtf)

Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:

The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration.  I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section.  In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

Resolution: Original discussion: The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4. New comments (March 2009): This issue dates back to 2003. I propose we close it on the grounds of cost/benefit. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
November 4, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4. Disposition: Deferred

Issue 6423: Section 9.3.4 page 161, Presentation Option (uml2-rtf)

Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: In Section 9.3.4., delete subsection �Presentation Option�.
Actions taken:
November 4, 2003: received issue
August 23, 2006: closed issue

Discussion:

I do agree with the submitter that this presentation option could be confusing. It has been
taken over from UML 1.4 for reasons of backwards compatibility. While I have not seen
any examples of actual use, it would be unwise to change this further in a backwards
incompatible way without being able to point to practical experience of the use of this
construct. If no practical experience can be found, it might be best to delete this
presentation option.

Issue 6433: 03-04-01 Chap 2 p. 112/Components: Different ways to wire components (uml2-rtf)

Click here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
paragraph says: �A component has a number of provided and required
Interfaces, that form the basis for wiring components together, either using
Dependencies, or by using Connectors.�   Is this really an either or choice?
What is the real semantic distinction?  And what is the semantic distinction
between wiring via connectors without ports vs. wiring via connectors with
ports?


Recommendation: Clearly specify the semantic distinctions among the three
ways of wiring components together:


1) Via Dependencies
2) Via Connectors without Ports
3) Via Connectors with Ports.


If there are no semantic distinctions--that is, if the distinctions are
purely mechanical--then the specification should probably changed such that
there is one way to wire components together.

Resolution: Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired. We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.
Revised Text: In 8.3.1 Semantics, replace: "The wiring between components in a system or other context can be structurally defined by using dependencies between component interfaces (typically on structure diagrams). Optionally, a more detailed specification of the structural collaboration can be made using parts and connectors in composite structures, to specify the role or instance level collaboration between components (See Clause Composite Structures)." By: "The wiring between components in a system or other context can be structurally defined by using dependencies between compatible simple Ports, or between Usages and matching InterfaceRealizations that are represented by sockets and lollipops on Components on component diagrams. Creating a wiring Dependency between a Usage and a matching InterfaceRealization, or between compatible simple Ports, means that there may be some additional information, such as performance requirements, transport bindings, or other policies that determine that the interface is realized in a way that is suitable for consumption by the depending Component. Such additional information could be captured in a profile by means of stereotypes." Also delete the following sentence: "The mapping between external and internal view is by means of dependencies (on structure diagrams), or delegation connectors to internal parts (on composite structure diagrams)." and replace it by "Dependencies on the external view provide a convenient overview of what may happen in the internal view; they do not prescribe what must happen." Delete the word "Again" from the following sentence that starts "Again, more �" and capitalize "More �" Insert the following text before figure 8.14: "When a Dependency is wired from a Usage to an InterfaceRealization, the dependency arrow should be shown joining the socket to the lollipop. A Dependency may be wired from a simple Port with a required interface to a simple Port to a provided interface, in which case it is a notational option to show the dependency arrow joining the socket to the lollipop. A Dependency may be shown from a simple Port to an internal realizing Classifier to indicate that the interface provided or required by the Port is in fact provided or required by the Dependency's supplier. All of these options are shown in Figure 8.14" Replace figure 8.14 with this: Delete the following paragraph below 8.15: "The wiring of components can be represented on structure diagrams by means of classifiers and dependencies between them (Note: the ball-and-socket notation from Figure 8.15 may be used as a notation option for dependency based wiring). On composite structure diagrams, detailed wiring can be performed at the role or instance level by defining parts and connectors." Disposition: Resolved
Actions taken:
November 4, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 6444: Activity diagram problems (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 2003: received issue
August 23, 2006: closed issue

Discussion:

This is too vaguely stated to act on. Part of item a) is covered in 6348. defer. From FTF: This is too vaguely stated to act on. Part of item a) is covered in 6348. defer
RTF: Could not obtain clarification from filer. The part of item a) referred to in the FTF
comment is that 6348 enabled pins to treat data as control (Pin.isControl) and allowing
control edges to be used with object nodes (ObjectNode.isControlType). Part of item b)
was addressed in FTF issue 6902, which added text to section 6.3 explaining that UML is
for discrete modeling, but it �does not dictate the amount of time between events, which
can be as small as needed by the application, for example, when simulating continuous
behaviors.�
Disposition: Closed, no change

Issue 6446: Clarification of Information Flow semantics (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: In section 17.2.1 InformationFlow � Constraints Change: 1] The sources and targets of the information flow can only be of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link). into: 1] The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link).
Actions taken:
November 6, 2003: received issue
August 23, 2006: closed issue

Discussion:

These are very good suggestions but such changes clearly qualify as new
features � since they extend the current definition of Information Flows � and are,
therefore, out of scope of the FTF.  Resolution:
b) needs an entire new specification. The combination of these new mechanisms with the
relations between targets & sources, the association Information Items is not at all
defined. That door is dangerous to open now. I suggest to reject this one.
Regarding c): Information flow are explicitly allowed between ports and interfaces. (may
be the issue is outdated)
d) OK, although I have never seen a dependency drawn between partitions. It also shows
an inconsistency in the spec that does not allow sources & target being ActivityNodes.
Regarding e) "Information" is purposely a very broad word that encompasses anything
we want to exchange between sources and targets. It does not prevent at all "physical
items": their circulation is also information.

Issue 6451: UML 2 Super / Dependency / ownership of dependencies (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

Unfortunately, this recommended fix would not solve the problem since more than one
model element can be the source (client) of a Dependency. Since, in general, each source
element is equal to all the others, there is no basis for singling out one of them to be the
�owner�.
Disposition: Closed, no change

Issue 6456: Use 'represent' for the relationship of a model (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
August 23, 2006: closed issue

Discussion:

Indeed. It would be useful if the theory of representation was settled. However, this is a
deep issue that exceeds the scope of an F/RTF. Hence, it is better to defer this issue to a
subsequent revision of UML. The submitter is absolutely right and that more care should have been taken in the use of
this term and many others. Unfortunately, the problem is endemic in both the Infra and
Super specs (and, likely, many other OMG specs). A count reveals close to 500 uses of
the word �represent� or its derivatives scattered throughout the document. Each of these
would have to be examined and appropriate action taken. Of course, this would only
solve this particular case of loose terminology but not the overall problem. The FTF
punted this issue by deferring it. However, it is unrealistic to expect that any future RTF
will have the resources or the time to fix this particular problem, let alone the more
general problem.
What is really required is a set of OMG-wide style guidelines and, possibly, a glossary of
approved defined terms that should be used in writing all submissions related to
modeling. This is a problem that exceeds this particular specification and should be posed
as an issue to the OMG as a whole.
Furthermore, although the loose use of �represents� is confusing in certain spots, in most
cases, it is not a problem that will lead to errors in tool implementation or significant
misinterpretation by readers. Therefore, it is proposed to close this issue in the context of
this specification. Disposition: Closed, no change

Issue 6460: UML 2 Issue: definition of navigability (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
October 27, 2008: closed issue

Issue 6463: UML 2 Issue: Message notation (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see above
Revised Text:
Actions taken:
November 7, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
August 23, 2006: closed issue

Discussion:

We have here 3 different problems:
1. There is an error in the illustration (partly due to Visio problems)
2. Notation needs to be fairly backward compatible
3. Notation needs to be fairly consistent with its semantics
The first problem is easily fixed.
The two latter problems are potentially in conflict. Here are the individual problems:
1. Create and reply messages use the same notation
a. This is true, but it does not seem to trouble users of these constructs UML 2 Revision Task Force Disposition: Resolved
OMG Issue No: 6463
Document ptc/06-01-01 Page 44
b. They are distinguishable as the create message arrowhead always ends at
the head of a new lifeline. That is never the case for any other message.
2. Reply message uses open arrowhead even though it is the reply of a synchronous
call.
a. Again this does not seem to bother users, but filled arrowhead would be
preferable, but not backward compatible.
3. Textual notation for reply messages
a. The current notation does include what is needed, and the suggested
changes fail to address what is needed. In the example we have on the last
reply message �x=bar(_):15� and this means the following:
i. �x=� tells where the value of the reply should be stored. x is an
attribute of the lifeline receiving the reply.
ii. �bar� is the name of the operation and it is true that this may be
redundant if we demand always to use execution occurrences to tie
call and reply, but in fact we do not require this. It seems
reasonable to indicate the name of the operation called to obtain
the result.
iii. �(_)� means that there is one parameter and it is not a return
parameter and is therefore insignificant at the reply. There may
have been return parameters and we would have needed this
parenthesis.
iv. �:15� gives the value of the operation returned. Since sequence
diagrams describe very concrete runs, the returned value is
important.
4. The create, delete and reply messages are not properly coded in the metamodel
a. this is unfortunately the case and should be corrected.
Conclusion: We do not do any changes of the notation, mainly because confusion is not
so high and it is backwards compatible. We need to correct the figure and the coding of
the special messages.
Revised Text:
Add to the enumeration of MessageSort the following items:
� createMessage � the message designating the creation of another lifeline object
� deleteMessage � the message designating the termination of another lifeline
� reply � the message is a reply message to an operation call

Issue 6492: ptc-03-09-15/Non-navigable ends with no role names nor multiplicities (uml2-rtf)

Click here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The meaning of this convention should be explained in the document.
Revised Text: OMG Issue No: 6492 Title: ptc-03-09-15/Non-navigable Ends with No Role Names Nor David Frankel Consulting (Mr. David S. Frankel, df@davidfrankelconsulting.com) Summary: 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 Resolution: The meaning of this convention should be explained in the document. Revised Text: In the Superstructure document, add to section 6.5.2 on page 16, as the second last bullet of the list, the following item: � If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints � although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) � Associations that are not explicitly named, are given names that are constructed according to the following production rule: �A_� <association-end-name1> �_� <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. In the Infrastructure document, add to section 6.3.1 on page 6, as the second last bullet of the list, the following item: � If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints � although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) OMG Issue No: 6492 Associations that are not explicitly named, are given names that are constructed according to the following production rule: �A_� <association-end-name1> �_� <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. Disposition: Resolved
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 6493: ptc-03-09-15/Constructs::Class superClass property (uml2-rtf)

Click here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This is not a problem, since the rules of package merge unify these two properties as
defined in rule 2 of the general transformation rules of package merge (see page 118 of
ptc/04-10-02)
Disposition: Closed, no change

Issue 6496: ptc-03-09-15/Relationships among Core packages (uml2-rtf)

Click here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Resolved by Issue 7956. Basic (and no other UML2 or MOF2 compliance level) no
longer merges anything from Abstractions. Figure 64 on page 91 of the Infrastructure
specification is simply a schematic diagram to show that model elements in Basic were
influenced and/or derived (by copy) from elements in Abstractions. But there is no longer
any connection between Basic and Abstractions.
Disposition: Closed, no change

Issue 6500: Federated models - UML2 issue (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

When creating a complete environment for agreements and BCF we need 
to 
work with ModelElements, classes, package, models etc created and 
managed by many unrelated person and organisations. This means that 
we 
need to support loosely coupled models (federated models) where an 
association starts in one model (stored in doc A) and ends in another 
model (stored in document B).


This may mean that we need to add references to an external 
modelelement 
so the assoication that references "out" to external ME need to be 
annotated with for example UUID of remote modelelement, name of model 
where the remote/external model , physicial location of remote model 
(URL) etc.
We may also want to attach constraints to the remote modelement that 
restricts "incomming" associations.


The question is how are loosely coupled model handled in UML 2 ?

Resolution: closed no change
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
April 25, 2011: closed issue

Discussion:

Model is a kind of Package and can be imported and referenced. There is no implication about storage units. XMI supports references that cross document boundaries. This is a tool issue, and many tools do support the requirements listed in the summary.

Issue 6501: Rose Model of UML 2.0 spec (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This problem was detected and resolved in the FTF.
Disposition: Closed, no change

Issue 6502: Multiplicity seems to be broken - UML2 Infra & Super (uml2-rtf)

Click here for this issue's archive.
Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de)
Nature: Uncategorized Issue
Severity:
Summary:

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 [{order_designator}]
(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?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed isuse

Discussion:

UML 2 Revision Task Force Disposition: Closed, no change
OMG Issue No: 6502
Document ptc/06-01-01 Page 641
Or am I just misreading the spec?
Discussion:
The response to these items is embedded below each:
� (P1) (9) and (10) are never used
This claim is simply incorrect: both of these designators can be used in specifying
a multiplicity
� (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])
Technically, this is true, but the possibility is prevented by an OCL constraint.
The BNF is used merely to define the valid notational forms and does not deal
with semantic constraints, which are covered elsewhere. The case where a lower
bound would require an UnlimitedNatural does not seem to be required and may
confuse some readers and would likely cause a disruption in numerous
implementations.
�
(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)
This was fixed in the FTF.
� (P4) (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.
Once again (see the response to (P2)), the submitter is mistakenly assuming that
the BNF is used to define the semantic constraints, whereas it merely specifies the
notation.
�
(P5) 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.
Again, there is a constraint that deals with that case.
� (P6) What is the role of the value_specification mentioned at (8) and (9) isn't it
redundant there?
Value specifications allow the use of various symbolic references. Disposition: Closed, no change

Issue 6503: Why not using the UML1 activity symbol for UML2 actions? (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
March 5, 2004: moved to the Superstructure FTF from Infrastructure
August 23, 2006: closed issue

Discussion:

This is too large and debatable a change for the FTF to address, and does not
affect implementability. UML2 completely separates state machine and activity semantics and notation. This
eliminates the need to have different symbols to distinguish states from activities on the
same diagram. UML2 could have used the UML1.x activity notation for actions in an
activity, but rounded rectangles are somewhat easier to draw by hand, and there shape
may be simpler to manage. At this point, the cost of changing this is probably greater
than its value.
Disposition: Closed, no change

Issue 6524: class "InfrastructureLibrary.core.constructs.Association", (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

 found something strange in the specification of UML 2.0.
First of all, in the 
class "InfrastructureLibrary.core.constructs.Association", there is 
an attribute "ownedEnd" with return type 
of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it 
its direct subclass "infrastructurelibrary.profiles.Extension", there 
is an attribute "ownedEnd" which redefines ownedEnd in 
class "Association", but with return 
type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity 
of 1. It causes conflicts of generated JMI interface.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Extension is a subclass of Association, and ExtensionEnd is a subclass of Property. So
Extension::ownedEnd: ExtensionEnd is an implicit redefinition of inherited property
Association::ownedEnd: Property. Redefinitions of this sort are used throughout the
UML2 metamodel, many of them occurring as the result of package merges.
Unfortunately, there is no way to have this fixed without a major reworking of the entire
UML metamodel and a change in the definition of UML 2. This is because the concept of
property redefinition is (a) a fundamental capability of UML 2.0 and (b) very tightly
integrated into the metamodel. Removing it, which is what would be required to deal with
this issue, is far outside the scope of an RTF.
Disposition: Closed, no change

Issue 6525: two classes "NamedElement (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

The submitter seems to be unfamiliar with the rules for redefinition and package merge,
which resolve such issues in general. In this particular case, due to the fact that
Abstractions and Basic have been de-coupled in the FTF work, the two are completely
distinct elements and are not intended to be used together. If someone does decide to use
them together, however, package merge would resolve any contention. See also the
resolution to issue 6003 and 6002.
Disposition: Closed, no change

Issue 6630: UML 2 Super / Classes / dependencies should be unidirectional (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see above
Revised Text: In figure 15 on page 32, make the association end NamedElement::supplierDependency non-navigable. (According to the convention used in the spec (section 6.5.2), this means that the supplier NamedElement does not have a property that explicitly identifies the set of dependencies that target it.) In section 7.3.33 on page 100 in the Associations subsection of NamedElement, remove the entire �supplierDependency� item.
Actions taken:
November 26, 2003: received issue
August 23, 2006: closed issue

Discussion:

This is fully consistent with the pattern used for all the other kinds of directed
relationships (Generalization, PackageMerge, ElementImport and PackageImport.)
Note that this does not prevent tools from readily determining the dependencies targeting
a particular model element if necessary, since that information can be easily computed or
cached by the tool when the dependency is constructed.

Issue 6637: UML 2 Infra/Metamodel/missing derivation indicators (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived.

Resolution: Discussion: This was fixed in release 2.1. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 21, 2003: received issue
February 18, 2005: moved from infrastructure
October 27, 2008: closed issue

Issue 6639: remove paragraph (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.

Resolution:
Revised Text:
Actions taken:
November 25, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

The offending paragraph was removed during the finalization phase. The issue is no
longer applicable.
Disposition: Closed, no change

Issue 6640: number of the figure is wrong (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 25, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This paragraph was removed in the finalization phase, so the issue is no longer relevant.
Disposition: Closed, no change

Issue 6641: well-formedness rules are not numbered correctly (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 26, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6659: multiplicity of the association named "type" of type DataType (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6660: The multiplicity of association named subaction of type Action ill formed (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].

Resolution:
Revised Text:
Actions taken:
December 1, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6661: In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6662: In the last paragraph, the period after the word "collections" on the secon (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 2, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6665: UML 1.5 table of contents (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>

Resolution:
Revised Text:
Actions taken:
December 3, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6692: Operations and derived attributes (uml2-rtf)

Click here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:

I am looking at ValueSpecification which introduces Additional Operations, such as integerValue().  My question is : What is the reasoning behind making these Operations vs. Derived attributes?

 

In MultiplicityElement we have a derived attribute lower which is equal to lowerBound().  What logic is used to determine whether an Operation has a corresponding Attribute?

 

Also the spec seems to indicate that all derived values will be implemented via some operation.  Is this a requirement or an assumption of implementation?

 

Why can�t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()� what makes the lowerBound() operation required?

Resolution:
Revised Text:
Actions taken:
December 10, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

It is usually a question of balance between efficiency and the need to minimize the
storage requirements for storing models (in both dynamic and persistent store). In
principle, anything that can be computed should be defined as an operation. Non-derived
attributes provide the basic input data from which such computations can be effected.
Derived attributes are typically used when the computation is judged to be inefficient in
some sense. (Clearly, there is a discretionary element in this, and such criteria are not
necessarily applied consistently in the spec.)
In the particular case of MultiplicityElement::lowerBound(), this was necessary since it is
possible that no lower bound was actually specified by the modeler.
Concerning derived values, the intent is to provide a specification of how each derived
feature is computed, whether through a formally specified formula (in OCL, for
example), or, where this is impractical or infeasible for some reason, in precise natural
language. However, because this is a lengthy undertaking requiring significant resources,
it was deemed impractical to hold up release of the specification until this task was
completed. Instead, its completion has been relegated to subsequent revision task forces.
The same applies to various constraints.
Disposition: Closed, no change

Issue 6696: Remove one of the dots between protectedAction and availableOutput (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 15, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed isssue

Discussion:

The issue no longer applies. UML 2 replaced JumpHandler with ExceptionHandler.
Disposition: Closed, no change

Issue 6697: Associations section of element JumpHandler (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

The line should read: 

protectedAction: Action [0..*]

Resolution:
Revised Text:
Actions taken:
December 15, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

JumpHandler (UML 1.5) is replaced by ExceptionHandler in UML 2. The type of the
protected node is correct (ExecutableNode).
Disposition: Closed, no change

Issue 6699: UML 2.0 infra and super Constraints Diagram of the Kernel (uml2-rtf)

Click here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: Change Figure 7 on page 24 to show Constraint::namespace to be navigable (this was already done in the Rose model). Editor�s note: This change also needed to be made in the Inrastructure document in the Constraints package of Abstractions.
Actions taken:
December 16, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Constraint::namespace redefines NamedElement::namespace so it should retain the same
name. Namespace was probably used instead of owningNamespace to keep the name
shorter and to follow the conventional meaning of the word (and its use in XML).

Issue 6700: UML 2.0 Kernel Operations Diagram and Features Diagram and mdl (uml2-rtf)

Click here for this issue's archive.
Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com)
Nature: Uncategorized Issue
Severity:
Summary:

The operations diagram redefines the formalParameter Property and removes the {ordered subsets parameter subsets ownedMember}.

 

The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn�t defined in the spec.

 

I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

 

This would require the ownerformalParam be made navigable.  But I feel that this change is already required to sync the OCL and Superstructure specs.

 

An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

Resolution: No longer applicable closed no chnage
Revised Text:
Actions taken:
December 16, 2003: received issue
February 18, 2005: moved from infrastructure
April 25, 2011: closed issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6702: The numbering of the sub-sections in 2.7.2 is wrong (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6703: In "2.9.3.5 Instance", numbering of different well-formedness rules wrong (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6704: The section about Procedure does not contain any well-formedness rules (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 17, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6724: The Composition section does not follow the usual conventions (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6725: missing closing parenthesis (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution: Indeed so.
Revised Text: On page 616 of ptc/04-10-02 change the last line of the second additional operation from: else (ancestor (s1, s2.container) to else (ancestor (s1, s2.container))
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Issue 6726: At the bottom of the page, the characters "antics." should be removed (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6727: In 2.13.3, the first sub-section about ActivityGraph is not numbered (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 18, 2003: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This refers to an old version of the spec. The referenced text is not present in the new
version.
Disposition: Closed, no change

Issue 6866: Part subtype (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Would be useful to be able to assign a subtype for objects that fill a
part, to add additional characteristics.  For example, a person fills
the Employee part of a company, and is reclassified under a subtype of
person that has an office.  It is not sufficient to use the subtype as
the type of the part, because the model wouldn't record what objects are
allowed to fill the parts.  The object is reclassified under the subtype
after filling the part.

Resolution: The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF. Revised Text: None. Disposition: Closed, out of scope
Revised Text:
Actions taken:
November 5, 2003: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

The issue suggests a new feature of UML. While interesting, such is considered outside
the scope of this FTF. The issue suggests a new feature of UML. While interesting, such is considered outside
the scope of this FTF.

Issue 6923: Class InfrastructureLibrary::Core::Basic::Property (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Class InfrastructureLibrary::Core::Basic::Property contains an attribute named 'default' of type 'String'. If initial values should be provided for a Property instance, then there is no possibility to evaluate the string without a schema. I'm not sure about the intension of this default property, especially for MOF (it seems to be useable only for visualization in UML). 

Proposed resolution: If evaluation should be processable by tools (e.g. code generators), then the type of 'default' must be changed to class "Type" or a schema for evaluation should be provided.

Resolution:
Revised Text:
Actions taken:
January 19, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Property defaults in Basic and Constructs (and therefore EMOF and CMOF) can only be
specified for primitive types, so only String is needed. UML2 Kernel supports more
complex default values through defaultValue:ValueSpecification. In
Kernel::Property:/default is derived from defaultValue.
Disposition: Closed, no change

Issue 6989: UML 2 Super/Interactions/Constraints for create messages (uml2-rtf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:

page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

Constraints need to be updated as new sorts of messages are added.

Resolution:
Revised Text:
Actions taken:
February 16, 2004: received issue
August 23, 2006: closed issue

Discussion:

The following constraint could be added:
�[9] No EventOccurences should occur before receiving the create message on
the corresponding Lifeline�
However this constraint does not allow modeling a situation where a create message may
be sent to an existing entity either due to error or intent (e.g., to model erroneous
behavior).
The above constraint applies to valid interactions. It is unclear how this constraint
applies to multivalued instances.
Therefore, it seems safer to not add this constraint.    Duplicate of Issue 8327 (even though this came first), see the resolution of 8327
Disposition: See issue 8327 for disposition

Issue 6990: manage simultaneity of events (uml2-rtf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Significant
Summary:

Issue 1: to have the possibility to manage simultaneity of events, and be able to 

trigger a transition by a condition on several events. By this way, the triggering 

condition of a transition may be specified through an event formula such as: (e1 and e2) or e3 

This point we then involve to relax a constraint on the semantics of RTC and to introduce then 

the possiblity to dequeue several events of the queue at the same time. May it be just an 

additional open variation semantics point?

Resolution: Simultaneous events and transitions triggered by a logical combination of events require a major modification or enhancement to the current Run-To-Completion semantics, where events are handled one at a time. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
February 17, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

The RTC model is currently fundamental to UML statemachines. Allowing several
events to be posted to a statemachine has a significant ramification on the current spec
beyond just adding a way to express simultaneity. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 6991: transtion (uml2-rtf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:

Issue 2: In the same spirit, we would like also to specifiy that a transtion is fired 

only if an event is not available at a given instant. We need the concepts of instant 

and event absence. Note that the absence combined with "and" and "or" can express kinds of 

priorities (e.g., "a and not b").

Resolution: Triggering a transition with the absence of an event seems to make sense only under a synchronous semantics which defines slices of time where that event might occur or not. It require a major modification or enhancement to the current, asynchronous Run-To-Completion semantics, where events are handled one by one in a timeless sequence. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
February 17, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

This proposal is relevant in case where simultaneity of events is allowed as requested in
issues 6990. Since 6990 is deferred, this request shall be deferred as well. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 7105: In normative XMI file for the metamodel, no Associations have a name. (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the normative XMI file for the metamodel, no Associations have a
name.
The name is needed for generating APIs and (in some cases) XMI elements;
and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
Core has the following constraint for CMOF:
[6] Names are required for all classifiers and features (though there is
nothing to prevent these names being automatically generated by a tool).



(Association is a classifier)


We could get by with not having a name in the MDL and auto-generating a
name into the XMI. This is in fact what the Unisys XMI plug-in did when
no Association name was provided - and this was hence reflected in the
normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).

Resolution:
Revised Text:
Actions taken:
March 8, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This is a duplicate of issue 6492, which was resolved in earlier ballots.
Disposition: See issue 6492 for disposition

Issue 7161: UML 2 Super/Interactions/Need constraints that cover multiple Lifelines (uml2-rtf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:

Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.


Or  when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.


In order to achieve this, it would be desirable to use:
1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

Resolution: Discussion: Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects". Disposition: Closed Out Of Scope
Revised Text:
Actions taken:
March 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Although this is a reasonable feature to request, it is an enhancement that exceeds the
scope of the FTF. One of the main issues with it is that the semantics of defining such
constraints in a distributed environment are not simple and require some serious
consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the
restrictions on guards reflect this to prevent specifying distributed decisions that would
imply implicit synchronization. The fact is, however, that many systems are such that it is
known that the lifelines are not concurrent and checking remotely or on enclosing objects
is not really hazardous. The problem is that we do not have a good way to define this in
the specification. This is of course not dependent upon Interactions, but is a feature of all
of UML. There seems to be a need to define object groups that share the same �thread�
and are only pseudo-concurrent. If we had had such a construct, the guard could cover
any subset of such a �same-thread-set-of-objects�.

Issue 7166: show object flow or interactions (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

Resolution: This issue has already been discussed in previous F/RTFs and considered out of scope: FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address. RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them. Revised Text: None Disposition: Closed Out of Scope
Revised Text:
Actions taken:
March 19, 2004: received issue
March 22, 2004: moved from infra- to superstructure-ftf
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Activity diagrams only show task dependency, which can be achieved by multiple
implemented processes. An activity can have more than one initial node. These
are all started when the activity is. The initial nodes can be used in separate
partitions to indicate which actions are taken on the client and server. If the two
processes are completely independent, then this is a request is for a hybrid
diagram, especially when trying to show shared objects. This is too much for an
FTF to address.  FTF: Activity diagrams only show task dependency, which can be achieved by multiple
implemented processes. An activity can have more than one initial node. These are all
started when the activity is. The initial nodes can be used in separate partitions to indicate
which actions are taken on the client and server. If the two processes are completely
independent, then this is a request is for a hybrid diagram, especially when trying to show
shared objects. This is too much for an FTF to address.
RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are
many combinations and not enough experience to choose among them.

Issue 7246: Figure 78 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however.

Resolution: Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
April 15, 2004: received issue
October 27, 2008: closed issue

Discussion:

Resolution deferred for the next RTF

Issue 7247: Connector - "provided Port" and "required Port" not defined Constraint 1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts."

Resolution: The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue.
Revised Text: Replace 8.3.3 constraint [1] which currently says: [1] A delegation connector must only be defined between used Interfaces or Ports of the same kind (e.g., between two provided Ports or between two required Ports). By [1] Each feature of each of the required interfaces of each Port or Part at the end of a connector must have at least one compatible feature among the features of the provided interfaces of Ports or Parts at the other ends, where the required set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's provided interfaces, and the provided set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's required interfaces. Replace the whole of the section 8.3.3 Semantics by the following: "A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by one or more instances that have "compatible" capabilities. These situations are modeled through a delegation connector from a Port to compatible Ports or Parts. Delegation connectors can be used to model the hierarchical decomposition of behavior, where services provided by a component may ultimately be realized by one that is nested multiple levels deep within it. The word delegation suggests that concrete message and signal flow will occur between the connected ports, possibly over multiple levels. It should be noted that such signal flow is not always realized in all system environments or implementations (i.e., it may be design time only). A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. At execution time, signals will be delivered to the appropriate port. In cases where multiple target ports support the handling of the same signal, the signal will be delivered to all these subordinate ports. The execution time semantics for an assembly connector are that signals travel along an instance of a connector. Multiple connectors directed to and from different parts, or n-ary connectors where n> 2, indicates that the instance that will originate or handle the signal will be determined at execution time. The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services. Also, in contexts where components are used to extend a system by offering existing services, but also adding new functionality, connectors can be used to link in the new component definition." Note: I have not attempted the OCL for the constraint in this resolution. That can be a subsequent issue.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Resolution deferred for the next RTF

Issue 7248: Connector - inconsistencies in Constraint [2] (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Connector - inconsistencies in Constraint [2] Constraint [2] says: "[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an �implements� relationship to the Interface type of that Port." There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a ConnectableElement. 2. What is "the Interface type of that Port" ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one?

Resolution: This constraint and the following two are currently incomprehensible (see 7249 and 7250). According to Internal Structures, "What makes connectable elements compatible is a semantic variation point." I see no particular reason to change this for components, and given that connectors are n-ary, it would be hard to do so. So I propose simply to delete the constraints. Profiles are free to restrict connectors to binary and to impose signature compatibility, based on type or contract compatibility, if they wish to.
Revised Text: Delete 8.3.3 constraint [2] which currently says: [2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an "implements" relationship to the Interface type of that Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Resolution deferred for the next RTF

Issue 7249: Connector - inconsistencies in Constraint[3] (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Connector - inconsistencies in Constraint[3] Constraint [3] says: "[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port." There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a ConnectableElement. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a ConnectableElement) - what is the "target Interface"? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does "signature compatible" mean for Interfaces?

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [3] which currently says: [3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Resolution deferred for the next RTF

Issue 7250: Connector - inconsistencies in Constraint[4] (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Connector - inconsistencies in Constraint[4] Constraint [4] says: "[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port." There are two problems with this constraint: 1. What is "the union of the Interfaces of these target Ports"? First, it is not clear, what a "union of interfaces" is. A "union of a set of interfaces" could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because "union of interfaces" is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does "signature compatible" mean?

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [4] which currently says: [4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 7251: Connector - inconsistencies in Constraint[5] (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Connector - inconsistencies in Constraint[5] Constraint [5] says: "[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port." There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a ConnectableElement. 2. It is not clear what a "required Port" or a "provided Port" is.

Resolution: See 7248 for the discussion.
Revised Text: Delete 8.3.3 constraint [5] which currently says: [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.
Actions taken:
April 15, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 7274: UML2 Infra/11.5.1/Invalid reference to Attribute class (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In section 11.5.1 (DataType) the first association is specified as:


ownedAttribute: Attribute[*] The Attributes owned by the DataType.


This is out of date: the class Attribute has been replaced by Property,
though the association name is OK referring to 'Attribute'. This is
reflected in the diagram above that text (Fig 86).


Proposed resolution:
Replace the above text with:
ownedAttribute: Property[*] The Properties owned by the DataType.

Resolution:
Revised Text:
Actions taken:
April 28, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Fixed by resolution to issue 6596
Disposition: Closed, no change

Issue 7303: simple time model" in CommonBehavior (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: (i) It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.

Resolution: Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 5, 2004: receive dissue
October 27, 2008: closed issue

Discussion:

A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the �simple
time model� and related concepts is required.

Issue 7304: Notation sections for TimeObservation and DurationObservation (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

The Notation sections for TimeObservation and DurationObservation seem inadequate: 1. The syntax for TimeObservation only allows "now" as a TimeExpression, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for DurationObservation includes the unexplained non-terminal symbol "duration". 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated.

Resolution: This issue has already been considered by prior RTFs and deemed out of scope, per the following discussion previously recorded for this issue: A proper resolution of this issue depends on changes in progress with respect to the action and activity model. In addition, a more encompassing improvement of the "simple time model" and related concepts is required. Thus, the resolution of this issue is best considered to be strategic. Revised Text: None Disposition: Closed Out of Scope
Revised Text:
Actions taken:
May 5, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the �simple
time model� and related concepts is required.

Issue 7339: Property defines an association "datatype" which is redundant (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Significant
Summary:

Property defines an association "datatype". This association is redundant for the following reasons: (i) A DataType is a kind of classifier, so saying that a property can be owned by a DataType adds nothing new. (ii) as feature, one can navigate from the property to the featuringClassifier, and so the navigability to an owning data type is already given. Moreover, an association to a data type would be incorrect if the property would otherwise be owned by a different Classifier. Moreover, if this property is owned by a classifier, there is no guarantee that the datatype association references the same DataType. There are no consistency constraints. Anyway, this association is redundant, can possibly lead to inconsistent models, and should be deleted. The last sentence on p.92 "A property may be owned by and in the namespace of a datatype." is correct even if the association is deleted. However, this sentence adds no new information either and is best deleted also.

Resolution: see pages 14 - 17 of ptc/2011-01-19
Revised Text:
Actions taken:
May 15, 2004: received issue
April 25, 2011: closed issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 7343: Section 11.7 (uml2-rtf)

In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure.

Resolution:
Revised Text:
Actions taken:
May 16, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

This is a fixed by the resolution to issue 7344. BehavioralFeature no longer separates
returnResult and formalParameter. It has BehavioralFeature::ownedParameter and
Parameter has direction:ParameterDirectionKind.
Disposition: Closed, no change

Issue 7362: Clarify example in figure 133 (uml2-rtf)

Could you describe in details the meaning of the example described in Figure 133, because it could very useful to understand the deployment specification concept. Moreover, is there anything lacking in figure 134? It contains no model element with the <<deployment specification>> stereotype.

Resolution: see above
Revised Text: Replace the first sentence of the Notation subsection of DeploymentSpecification description (ptc/04-10- 02, page 214; formal/05-07-04, page 199) with the following text: �A DeploymentSpecification is graphically displayed as a classifier rectangle (Figure 133) attached to a component artifact deployed on a container using a regular dependency arrow.� (Note that in formal/05-07-04 the replacement text would refer to �Figure 10.11� instead of �Figure 133�.)
Actions taken:
May 19, 2004: received issue
August 23, 2006: closed issue

Discussion:

Figure 133 (page 214, ptc/04-10-02; same as Figure 10.11, page 199, formal/05-07-04) is
not discussed in or referenced by the text, and as pointed out by the issue, the figure
caption does not provide any clue has to how the figure assists understanding of the text.
It seems to be meant merely as an example of what the specification level (left box) and
instance level (right box) look like. A simple reference to the figure from the text should
help clarify the role of the figure.
The point of Figure 134 is to show how a DeploymentSpecification instance is associated
with the Artifact(s) it describes. The figure seems to accomplish this goal without the
necessity of a �model element with the <<deployment specification>> stereotype�. The
issue text does not say why such an addition would be helpful, and the figure seems to
accomplish its goal as is. No change seems needed. Note that the first sentence of
DeploymentSpecification�s Notation subsection is poorly formed: �A
DeploymentSpecification is graphically displayed as a classifier rectangle that is attached
to a component artifact that is deployed on a container using a regular dependency
notation is used.�

Issue 7364: section on connectors in the component chapter (uml2-rtf)

The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section.

Resolution: Moving all of BasicComponents.Connector into InternalStructures, although perhaps strategically a good idea, seems like a bridge too far for the RTF. Also Thomas is not entirely accurate when he says it adds no new functionality apart from the notation. In particular BasicComponents adds the idea of a connector contract, which is a set of Behaviors. Therefore I propose that we leave the text where it is, albeit we should fix the many bugs in it that are the topics of this and other issues. However the proposal that kind:ConnectorKind should be derived is entirely sensible, especially since the current constraints on connector kind are the topic of numerous issues (7248-7251).
Revised Text: Under 8.1, Basic Components, replace the following sentence: "In addition, the BasicComponents package defines specialized connectors for 'wiring' components together based on interface compatibility." by "In addition, the BasicComponents package allows a connector to carry one or more Behaviors that specify the valid interaction patterns across the connector." Under 8.3.3, replace the first sentence: "The connector concept is extended in the Components package to include interface based constraints and notation." by "The connector concept is extended in the Components package to include contracts and notation." In the model (figure 8.3) show /kind: connectorKind as derived. Under 8.3.3 Description, insert the word "derived" before the phrase "connector kind attribute". Under 8.3.3 Connector Attributes, Package BasicComponents, replace: � kind : ConnectorKind Indicates the kind of connector. By: � /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif
Actions taken:

Discussion:

Issue 7375: useless example on p.330, Figure 247 (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

p.330, Figure 247. This example is useless, as it canot be understood without much detail on the FFT computation. It would be better to use examples that readers can readily understand.

Resolution: The issue is subjective. Some readers might find the example helpful. The example is useful as a depiction of a realistic computation. Revised Text: None Disposition: Closed, no Change
Revised Text:
Actions taken:
May 20, 2004: received issue
May 24, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

The issue is subjective. Some readers might find the example helpful. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 7392: Interactions model sequences of events (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event.

Resolution: Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 29, 2004: received issue
October 27, 2008: closed issue

Discussion:

Resolution deferred for the next RTF

Issue 7397: add an interaction fragment (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

Sequence diagrams are often used to describe abstract system behavior in the form of the interaction of the system with its environment. Experience has shown that systems have normal behavior and exceptional behavior (in response to unusual or unexpected events). UML2 has introduced a mechanism of representing exceptions. However, interactions do not give us a vehicle of showing exceptional behavior. Recommendation: add an interaction fragment indicating exceptional handling similar to the way this is done in the activity chapter.

Resolution:
Revised Text:
Actions taken:
May 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

Indeed. However, this is a feature request that is outside the scope of an FTF. Exception handling would be good to have also in sequence diagrams. However, judging
from work done in the UML Testing Profile, and from the Master thesis of a student from
University of Oslo, it is not as simple to include as implied in this suggestion. Introducing
another operator for a combined fragment is hardly enough, but may be part of the final
solution.
Disposition: Closed, no change

Issue 7401: XMI schema (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

"[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed.

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue
August 23, 2006: closed issue

Discussion:

Resolution deferred for the next RTF. This is a duplicate with 3898.
Disposition: See issue 3898 for disposition

Issue 7406: TimeObservationAction and DurationObservationAction (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed.

Resolution: Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 29, 2004: received issue
October 27, 2008: closed issue

Discussion:

A proper resolution of this issue depends on changes in progress with respect to the
action and activity model. In addition, a more encompassing improvement of the �simple
time model� and related concepts is required.

Issue 7407: The specification is fond of using 'typically.' (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The specification is fond of using 'typically.' The term should be use with care in a specification. Typically, 'must' or 'may' are better choices. For example, at 7.4.1 p.42: The multiplicity bounds are typically shown in the format: lower-bound..upper-bound It will be better to write: The multiplicity bounds are shown in the format: lower-bound..upper-bound simply deleting 'typically.' (In this case, the syntax specification should show the case when the two bounds are equal.)

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue
August 23, 2006: closed issue

Discussion:

This is indeed a valid issue, since the term typically (sorry!) leads to confusion and
ambiguity that should not be encountered in a spec. Unfrotunately, there are 72 uses of
this term in the current spec and each one would have to be reviewed individually. This
does not seem feasible in the short time left for the work of this FTF. Therefore, it is
work that should be picked up by a subsequent RTF.======================The discussion associated with the resolution to issue 6456 equally applies here (except
that there are 71 uses of this term and its derivatives � still a very large number).
Disposition: Closed, no change

Issue 7756: Unconsistent association extension description (uml2-rtf)

Click here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:

 b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447.
---

Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles.
.


Discussion

In Profiles:Profile:semantics, change the paragraph 

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel.

Into

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.

Resolution:
Revised Text: This change needs to be made in both the Infrastructure (ptc/04-11-16) and Superstructure specs (ptc/04-10-02): >>>>> "In Profiles:Profile:semantics, replace the following text: As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. The effect of new (meta)associations within profiles can be achieved in limited ways either by: 1. adding new constraints within a profile that specialize the usage of some associations of the reference metamodel, or 2. extending the Dependency metaclass by a stereotype and defining specific constraint on this stereotype. As an illustration of the first approach, the examples in Figure 450 and Figure 451 could be extended by adding a �HomeRealization� stereotype that extends the �InterfaceRealization� UML metaclass. The �Bean� stereotype will introduce the constraint that the �interfaceRealization� association can only target �InterfaceRealization� elements extended by a �HomeRealization� stereotype and the �HomeRealization� stereotype will add the constraint that the �contract� association can only target interfaces extended by a �Home� stereotype. As an illustration of second approach, one can define a stereotype �Sclass� extending Class and a stereotype �Sstate� extending State. In order to specify the default state of an �Sclass�, a �DefaultState� stereotype extending �Dependency� can be defined, with the constraints that a DefaultState Dependency can only exist between an Sclass and an Sstate. Into Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
Actions taken:
September 3, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7757: Unconsistent Profile extension description (02) (uml2-rtf)

Click here for this issue's archive.
Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr)
Nature: Uncategorized Issue
Severity:
Summary:

 18.3.5 says that "A profile by definition extends a reference  metamodel or another profile."
 While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..."
---

Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile".

The reference to profile extension should be simply discarded. A profile extends a reference metamodel.
.


Discussion

In Profiles:Profile:semantics, change the first sentence 

A profile by definition extends a reference metamodel or another profile.


Into

A profile by definition extends a reference metamodel.

Resolution:
Revised Text:
Actions taken:
September 3, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

In Profiles:Profile:semantics, change the first sentence
A profile by definition extends a reference metamodel or another profile.
Into
A profile by definition extends a reference metamodel.
Here also, the suggested change has been already made. This issue is obsolete (already
solved).
Disposition: Closed, no change

Issue 7782: Move Comment into Basic and add Kind (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Move Comment into Basic and add Kind
The ability to annotate and describe elements and diagrams is pretty
fundamental so should be included in Basic.
There should also be the recognition that there are different kinds of
comment: for example most tools have a dialog allowing people to enter a
Description for an Element; and separately may allow the element to be
annotated on diagrams in a particular context. At the moment there is no
way to distinguish these.
The UML Metamodel itself is an example of the need for different kinds
of Comment: each Class has a number of distinct sections (e.g.
Description, Semantics, Notation).
Hence there should be a 'kind' attribute on Comment to reflect this.

Resolution: Disposition: Closed, no change
Revised Text: Resolved in the FTF.
Actions taken:
September 24, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Discussion:

Resolution
Changes to Infrastructure:

Remove the class Comment and the association Element::ownedComment from Figure 71 and add to Figure 65

Move Section 11.1.1 Comment to 10.1.1 and renumber the following sections in sections 11.1 and 10.1

Issue 7783: Missing XMI tags in spec and XMI rendition of metamodel (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This issue applies to Infrastructure, Superstructure and MOF


In the XMI for Superstructure for example (in OMG document ad/03-04-02),
while this does use the nsuri for MOF (using the correct form
xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
contain any XMI tags to define for UML what its nsuri and prefix should
be: which are needed in order to generate the UML xsd.
Neither does the XMI for the MOF Core itself contain an XMI tag to
define that the nsuri and prefix should be as just quoted.


In any case these important values should be included in the
specification documents as well as being buried in tags in the XMI
files.

Resolution:
Revised Text: OMG Issue No: 7783 Title: Missing XMI tags in spec and XMI rendition of metamodel In the XMI for Superstructure for example (in OMG document ad/03-04-02), while this xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not contain any XMI tags to define for UML what its nsuri and prefix should be: which are needed in order to generate the UML xsd. Neither does the XMI for the MOF Core itself contain an In any case these important values should be included in the specification documents as Add the following text to the end of Appendix A: XMI Serialization and Schema XMI allow the use of tags to tailor the schemas and documents that are produced using XMI. The following have been explicitly set for the UML2 Infrastructure Model; the others are left at their default values: � tag nsURI set to "http://schema.omg.org/spec/UML/2.0/umlL0.xml" for L0 � tag nsURI set to "http://schema.omg.org/spec/UML/2.0/umlLM.xml" for LM � tag nsPrefix set to "uml" (for both cases) Changes to MOF: Add the following text to the end of Appendix A: XSD and XMI for MOF 2.0 XMI allows the use of tags to tailor the schemas that are produced and the documents that are produced using XMI. The following have been explicitly set for EMOF; the others are left at their default values: � tag nsURI set to "http://schema.omg.org/spec/MOF/2.0/emof.xml" � tag nsPrefix set to "emof" The following have been explicitly set for CMOF; the others are left at their default values: � tag nsURI set to http://schema.omg.org/spec/MOF/2.0/cmof.xml � tag nsPrefix set to "cmof" Disposition: Resolved
Actions taken:
September 24, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7889: Inconsistent use of 'Element' between MOF and UML (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.
 
Proposed resolution:
 
MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.

Resolution:
Revised Text: Resolution: In MOF Core, Element and Object will have their names swapped as proposed. There is no effect on Infrastructure: MOF is in effect merging in Object as a new superclass to Element. Figure 2 � Replace class name "Element (from Elements)" by "Object" � Replace class name "Object" by "Element" � Replace the 7 operations for the Object (now Element) class by the following: getMetaClass() : Class container() : Element equals(object : Object) : Boolean get(property : Property) : Object set(property : Property, object: Object) isSet(property : Property) : Boolean unset(property : Property) � Replace the 3 operations for the Factory class by the following: createFromString(dataType : DataType, string : String) : Object convertToString(dataType : DataType, object: Object) : String create(metaClass : Class) : Element Section 9.1 � Change section name from Object to Element � Replace the first para by the following: Every Element has a Class which describes its properties and operations. The Element is an Instance of this Class. Element extends Abstraction::Elements::Element. All model elements that specialize Reflection::Element inherit reflective capabilities. In particular, this includes all model elements from UML2 Infrastructure. � Replace the Operations section by the following text: getMetaClass() : Class Returns the Class that describes this element. container(): Element Returns the parent container of this element if any. Return Null if there is no containing element. equals(object: Object): Boolean Determines if the object equals this Element instance. For instances of Class, returns true if the object and this Element instance are references to the same Object. For instances of DataType, returns true if the object has the same value as this Element instance. Returns false for all other cases. get(property: Property) : Object Gets the value of the given property. If the Property has multiplicity upper bound of 1, get() returns the value of the Property. If Property has multiplicity upper bound >1, get() returns a ReflectiveSequence containing the values of the Property. If there are no values, the ReflectiveSequence returned is empty. ReflectiveSequence is defined in section "MOF::Common" on page 24. Exception: throws IllegalArgumentException if Property is not a member of the Class from class(). set(property: Property, object: Object) If the Property has multiplicity upper bound = 1, set() atomically updates the value of the Property to the object parameter. If Property has multiplicity upper bound >1, the Object may be either a ReflectiveCollection or a ReflectiveSequence. The behavior is identical to the following operations performed atomically: ReflectiveSequence list = element.get(property); list.clear(); list.addAll((ReflectiveSequence) object); There is no return value. Exception: throws IllegalArgumentException if Property is not a member of the Class from getMeta-Class(). Exception: throws ClassCastException if the Property's type isInstance(object) returns false and Property has multiplicity upper bound = 1 Exception: throws ClassCastException if Object is not a ReflectiveSequence and Property has multiplicity upper bound > 1 Exception: throws IllegalArgumentException if object is null, Property is of type Class, and the multiplicity upper bound > 1. isSet(property: Property): Boolean If the Property has multiplicity upper bound of 1, isSet() returns true if the value of the Property is different than the default value of that property. If Property has multiplicity upper bound >1, isSet() returns true if the number of objects in the list is > 0. Exception: throws IllegalArgumentException if Property is not a member of the Class from class(). unset(property: Property) If the Property has multiplicity upper bound of 1, unset() atomically sets the value of the Property to its default value for DataType type properties and null for Class type properties. If Property has multiplicity upper bound >1, unset() clears the ReflectiveSequence of values of the Property. The behavior is identical to the following operations performed atomically: ReflectiveSequence list = element.get(property); list.clear(); There is no return value. After unset() is called, element.isSet(property) == false. Exception: throws IllegalArgumentException if Property is not a member of the Class from getMetaClass(). Constraints No additional constraints. Semantics Class Element is the superclass of all model elements in MOF, and is the superclass of all instances of MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Object, MOF supports any number of meta layers as described in Chapter 1, "MOF Architecture". The following describes the interaction between default values, null, isSet, and unSet. Single-valued properties: If a single-valued property has a default: o It is set to that default value when the element is created. isSet=false o If the value of that property is later explicitly set, even to the default value, isSet=true o If the property is unSet, then the value of the property returns to the default, and isSet=false If a single-valued property does not have a default: o At creation, its value is null. isSet=false o If the value of that property is later explicitly set, even to null, isSet=true o If the property is unSet, then the value of the property returns to null, and isSet=false Multi-valued properties: o When the element is created, it is an empty list. isSet=false o If the list is modified in any way (except unSet), isSet=true o If the list is unSet, it is cleared and becomes an empty list. isSet=false. The implementation of isSet is up to the implementer. In the worst case it can be implemented by having an additional boolean, but usually for a particular implementation it can be implemented more efficiently (e.g. by having an internal distinguished value used to represent "no value set"). For default values, implementations are not required to access stored metadata at runtime. It is adequate to generate a constant in the implementation class for the default. Rationale Element is introduced in package Reflection so that it can be combined with Core::Basic to produce EMOF which can then be merged into CMOF to provide reflective capability to MOF and all instances of MOF. Section 9.2 Replace Operations section by the following text Operations createFromString(dataType: DataType, string: String): Object Creates an Object initialized from the value of the String. Returns null if the creation cannot be performed. The format of the String is defined by the XML Schema SimpleType corresponding to that datatype. Exception: NullPointerException if datatype is null. Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage(). convertToString(datatype: DataType, object: Object): String Creates a String representation of the Object. Returns null if the creation cannot be performed. The format of the String is defined by the XML Schema SimpleType corresponding to that dataType. Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage(). create(metaClass: Class): Element Creates an element that is an instance of the metaClass. Element::metaClass == metaClass and metaClass.isInstance(element) == true. All properties of the element are considered unset. The values are the same as if element.unset(property) was invoked for every property. Returns null if the creation cannot be performed. Classes with abstract = true always return null. The created element's metaClass == metaClass. Exception: NullPointerException if class is null. Exception: IllegalArgumentException if class is not a member of the package returned by getPackage(). Add new section 9.3 as follows: 9.3 Object Reflection introduces Object as a supertype of Element in order to be able to have a Type that represent both elements and data values. Object represents 'any' value and is the equivalent of java.lang.object in Java. Section 10 � Replace the first sentence by: An element has an identifier in the context of an extent that distinguishes it unambiguously from other elements. Figure 3 � Replace "Element( (from Elements)" by "Object" � In class Extent, replace objects(): ReflectiveSequence by elements(): ReflectiveSequence � In class URIExtent, replace uri(object:Object): String by uri(element:Element): String � And replace object(uri:String): Object by element (uri:String): Element Section 10.1 � Replace first para by: An Extent is a context in which an Element in a set of Elements in a set can be identified. An element may be a member of zero or more extents. An Extent is not an Element, it is part of a MOF capability. � Replace Operations section by: useContainment(): Boolean When true, recursively include all elements contained by members of the element(). elements(): ReflectiveSequence Returns a ReflectiveSequence of the elements directly referenced by this extent. If exclusive()==true, these elements must have container()==null. Extent.elements() is a reflective operation, not a reference between Extent and Element. See Chapter 4, "Reflection" for a definition of ReflectiveSequence � Replace Rationale section by: Extents provide a context in which MOF Elements can be identified independent of any value in the Element. Section 10.3 � Replace first sentence by: Identity extends Basic::Property with the ability to designate a property as an identifier for the containing element. � Replace Rationale by: Objects must have identity. The Property isID formalizes this capability in the metadata describing the object.. Section 10.4 � Replace first sentence by: An extent that provides URI identity. A URIExtent can have a URI that establishes a context that may be used in determining identifiers for elements identified in the extent. Implementations may also use values of properties with isID==true in determining the identifier of the element. � Replace Operations section by contextURI(): String Specifies an identity for the extent that establishes a URI context for identifying elements in the extent. An extent has an identity if a URI is assigned. URI is defined in IETF RFC-2396 available at http://www.ietf.org/rfc/rfc2396.txt. uri(element: Element): String Returns the URI of the given element in the extent. Returns Null if the element is not in the extent. element(uri: String): Element Returns the Element identified by the given URI in the extent. Returns Null if there is no element in the extent with the given URI. Note the Object does not (necessarily) contain a property corresponding to the URI. The URI identifies the element in the context of the extent. The same element may have a different identifier in another extent. � Replace Rationale by URIs are the defacto standard identity mechanism for the Web and are therefore useful for identifying MOF elements and navigating links between them. Figure 5 � Replace operations in ReflectiveCollection with: add(object : Object) : Boolean addAll(elements : ReflectiveSequence) : Boolean clear() remove(object : Object) : Boolean size() : Integer � Replace operations in ReflectiveSequence with: add(index : Integer, object : Object) get(index : Integer) : Object remove(index : Integer) : Object set(index : Integer, object : Object) : Object Section 10.5.1 � Replace entire section with the following: 10.5.1 ReflectiveCollection RefelectiveCollection is a reflective class for accessing properties with more than one possible value. It is defined in package MOF::Common in order to facilitate reuse in many other MOF capabilities. For ordered properties, ReflectiveSequence (see below) must be returned. Modifications made to the ReflectiveCollection update the Element's values for that property atomically. Exception: throws ClassCastException if the Property's type isInstance(Element) returns false. add(object : Object): Boolean Adds object to the last position in the collection. Returns true if the object was added. addAll(objects: ReflectiveSequence): Boolean Adds the objects to the end of the collection. Returns true if any objects were added. clear() Removes all objects from the collection. remove(object : Object): Object Removes the specified object from the collection. Returns true if the object was removed. size(): Integer Returns the number of objects in the colleciton. Section 10.5.2 � Replace entire section with the following: 10.5.2 ReflectiveSequence ReflectiveSequence is a subclass of ReflectiveCollection that is used for accessing ordered properties with more than one possible value. Modifications made to ReflectiveSequence update the Element's values for that property atomically. Modifications made to the ReflectiveSequence update the Element's values for that property atomically. Exception: throws IllegalArgumentException if a duplicate would be added to the collection and Property.isUnique()==true. Exception: throws IndexOutOfBoundsException if an index out of the range of 0 <= index < size() is used. Exception: throws IllegalArgumentException if a duplicate would be added to the list and Property is of type Class or Property.isUnique()==true. add(index: Integer, object : Object) Adds object to the specified index in the sequence, shifting later objects. get(index: Integer): Object Returns the object at the given index in the sequence. remove(index: Integer): Object Removes the object at the specified index from the sequence. Returns the object removed. set(index: Integer, object: Object): Object Replaces the object at the specified index with the new object. The removed object is returned. Behavior of particular operations defined in ReflectiveCollection is the following when applied to a ReflectiveSequence: add(object: Object): Boolean Adds object to the end of the sequence. Returns true if the object was added. addAll(objects: ReflectiveSequence): Boolean Adds the objects to the end of the sequence. Returns true if any objects were added. remove(,object: Object): Boolean Removes the first occurence of the specified object from the sequence. Figure 5 � Replace the Object superclass with Element Figure 13 � Replace the Element (from Elements) superclass with Object � Replace the class Object with Element � Replace the following operation on Object (now Element): invoke(op : Operation, arguments : Argument) : Element with: invoke(op : Operation, arguments : Argument) : Object � Replace the 3 operations on Factory with: name : String createElement (class : Class, arguments : Argument) : Element createLink(association : Association, firstElement : Element, secondElement: Element) : Link � Replace the 4 operations on Extent with: elementsOfType(type : Class, includeSubtypes : Boolean) : Element linksOfType(type : Association) : Link linkedElements(association : Association, endObject : Element, end1ToEnd2Direction : Boolean) : Element linkExists(association : Association, firstElement : Element, secondElement : Element) : Boolean � Replace the 2nd property of Argument with: value: Object � Replace the association ends firstObject and secondObject with firstElement and secondElement. Section 13.1 � Replace entire section with the following text: 13.1 Link This is a new class that represents an instance of an Association, in the same way that Element represents an instance of a Class. Properties association: Association This is the Association of which the Link is an instance. firstElement: Element This is the Element associated with the first end of the Association. secondElement: Element This is the Element associated with the second end of the Association. Operations equals(otherLink:Link): Boolean Returns True iff the otherLink has association, firstElement, secondElement all equal to those on this Link. delete() Deletes the Link. This may leave the same elements associated by other links for this Association. Constraints The firstElement must conform to the type of the first memberEnd of the association. The secondElement must conform to the type of the second memberEnd of the association. The set of Links as a whole must not break the multiplicity constraints of the association member ends. Semantics When the link is created, it is not assigned to any Extent. Rationale Since MOF 2.0 allows the same pair of elements to be linked more than once in the same Association (if isUnique=false for the association ends), then Link needs to be more a simple tuple value, though not as heavyweight as a first class Element. Changes from MOF 1.4 None. The MOF 1.4 navigation capabilities are retained. Section 13.2, Argument � Replace entire section with the following: 13.2 Argument This is a new datatype that is used to represent named arguments to open-ended reflective operations. It is open-ended and allows both Elements and data values to be supplied. Properties name: String The name of the argument. value: Object The value of the argument. Constraints None: constrains will be dependent on the context of where the Argument is supplied. Semantics None. Rationale Since MOF 2.0 allows Operation parameters and Properties to have defaults, it is necessary to explicitly identify the values supplied. Changes from MOF 1.4 Values supplied to constructors are now identified rather than being deduced through the ordering. Section 13.3 � Introduce new section for Element that was previously called Element and not given a section number but 'lost' in 13.2 13.3 Element CMOF Reflection adds the following extra operations. Operations delete() Deletes the Element. invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] Calls the supplied Operation on the element, passing the supplied Arguments and returning the result. The Operation must be defined on the Class of the Element, and the arguments must refer to Parameters of the Operation. If an Argument is not supplied for a Parameter its default value, if any, will be used. isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean Returns true if this element is an instance of the supplied Class, or if includeSubtypes is true, any of its subclasses. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Parameters to operations are now identified by name. Section 13.3, Factory Renumber to 13.4 (due to reinstatement of Object - see previous change) and replace test with the following: 13.4 Factory CMOF Reflection adds two extra operations. Operations createElement(class:Class, arguments : Argument[0..*]) : Element Unlike the simple create() operation this allows arguments to be provided for use as the initial values of properties. The arguments must refer to DataType Properties of the Class. If an Argument is not supplied for a Property its default value, if any, will be used. createLink(association : Association, firstElement : Element, secondElement : Element) : Link This creates a Link from 2 supplied Elements that is an instance of the supplied Association. The first Element is associated with the first end (the properties comprising the association ends are ordered) and must conform to its type. And correspondingly for the second Element. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Names have changed. Section 13.4, Factory Renumber to 13.5 (due to reinstatement of Object - see previous change) and replace test with the following: 13.5 Extent CMOF Reflection adds four extra operations. Operations elementsOfType(type : Class, includeSubtypes : Boolean) : Element [0..*] This returns those elements in the extent that are instances of the supplied Class. If includeSubtypes is true, then instances of any subclasses are also returned. linksOfType(type : Association) : Link[0..*] This returns those links in the extent that are instances of the supplied Association. linkedElements(association : Association, endElement : Element, end1ToEnd2Direction : Boolean) : Element [0..*] This navigates the supplied Association from the supplied Element. The direction of navigation is given by the end1ToEnd2Direction parameter: if true, then the supplied Element is treated as the first end of the Association. linkExists(association : Association, firstElement : Element, second Element : Element): Boolean This returns true if there exists at least one link for the association between the supplied elements at their respective ends. Rationale Adds the equivalent of MOF 1.4 capabilities. Changes from MOF 1.4 Names have changed. Disposition: Resolved
Actions taken:
November 1, 2004: received issue
February 18, 2005: moved from infrastructure
August 23, 2006: closed issue

Issue 7908: Design principles (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

 have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is

Resolution:
Revised Text:
Actions taken:
November 10, 2004: received issue
August 23, 2006: closed issue

Discussion:

One can argue for and against the thesis in this issue. However, it is, in essence, a critique
that does not really indicate how the problem is to be fixed other than to redo all of UML
2.0 from the beginning. Since that falls outside the scope of an RTF and also of reality,
this issue will be closed with no changes made.
Disposition: Closed, no change

Issue 7909: Problem with diagram references in Profiles section (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S� to "C").

But the 2 references should be to Figure 456 and Figure 461 respectively.

Resolution:
Revised Text: The following change needs to be made in both the Infrastructure (ptc/04-11-16) and Superstructure specs (ptc/04-10-02) � with the appropriate figure numbers for each document. In the 2nd paragraph in Profile:Stereotype Semantics Change the text An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S� to "C"). Into An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 456). At the model level (such as in Figure 461) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S� to "C").
Actions taken:
November 14, 2004: received issue
August 23, 2006: closed issue

Discussion:

Issue 7938: DataType attributes UML 2 Super (ptc/04-10-02) (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.

Resolution: See issue 7939 for disposition
Revised Text:
Actions taken:
November 19, 2004: received issue
August 23, 2006: closed issue

Issue 7939: DataType attributes UML 2 Super (ptc/04-10-02) (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.

Resolution:
Revised Text: Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedAttribute on page 59. Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedOperation on page 59. Infrastructure (ptc/04-11-16) Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedAttribute on page 140. Insert the sentence: This is an ordered collection. Between the first and second sentence of the description for the association end DataType::ownedOperation on page 140.
Actions taken:
November 19, 2004: received issue
August 23, 2006: closed issue

Issue 7942: Section: 7.3.43 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Notation for a primitive type should be <<primitiveType>> instead of <<primitive>>. That's more consistent to the general usage of keywords that they are identical to the metaclass name

Resolution:
Revised Text:
Actions taken:
November 22, 2004: received issue
August 23, 2006: closed issue

Discussion:

This argument may be valid, but the impact of making this change at this point when
tools have been released and books have been published based on the old notation, it
simply does not seem to be worth the disruption that it would cause.
Disposition: Closed, no change

Issue 7946: Section: 7.2.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel.

Resolution: see above
Revised Text: In the Infrastructure spec in section 7.2.8 on page 29, replace the following text: When a language is reflective, there is no need to define another language to specify its semantics. MOF is reflective since it is based on the InfrastructureLibrary, and there is thus no need to have additional meta-layers above MOF. by the following text: MOF is reflective since it is based on the InfrastructureLibrary. This allows it to be used to define itself. For this reason, no additional meta-layers above MOF are defined.
Actions taken:
November 23, 2004: received issue
August 23, 2006: closed issue

Discussion:

The submitter raises a philosophical point that may be valid and is certainly debatable.
However, the quoted statement was in the specific context of the explanation of the 4-
layer model, where it was used to justify why the architecture stops the potentially
infinite succession of metalevels at M3.
However, the text itself can be modified to avoid making a statement that can be
misunderstood as being a general statement.

Issue 7947: Classes (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that.

Resolution: See issue 8069 for disposition
Revised Text:
Actions taken:
November 24, 2004: received issue
August 23, 2006: closed issue

Discussion:

Issue 7948: section 2.10.4.1 detailed semantics of collaborations (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:


"However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."


Allow me to illustrate my interpretation of this section by means of an example.


Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?


Then, the spec goes on:


"Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."


So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.


Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.

Resolution:
Revised Text:
Actions taken:
November 24, 2004: received issue
August 23, 2006: closed issue

Discussion:

This issue appears to be against UML 1.x, as the semantics of collaboration does not
contain the cited passages and it relies on concepts that have been removed in UML 2.0.
Collaborations have been clarified significantly in UML 2.0; the author of this issue is
invited to check whether his concern still exists.
Disposition: Closed, no change

Issue 7949: Section: 7.3.44 - OCL incorrect (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [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->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif

Resolution: See issue 6201 for disposition
Revised Text:
Actions taken:
November 26, 2004: received issue
August 23, 2006: closed issue

Issue 7950: Interactions (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In the description of the Graphic Paths for a Communication Diagram I can
find no mention of what the lines between the Lifelines correspond to -
although I did find this in the description of Message: "On Communication
Diagrams, the Messages are decorated by a small arrow along the connector
close to the Message
name and sequence number in the direction of the Message." I assume this
means that the lines correspond to a Connector model element.


The Graphic Paths section should be updated to include this information and
justification added as to why a Connector is needed in order for Messages to
be shown between two lifelines on a Communication Diagram (this seems an
overly tight constraint to me).

Resolution: see above
Revised Text: Before (14.3.20 page 540): On Communication Diagrams, the Messages are decorated by a small arrow along the connector close to the Message name and sequence number in the direction of the Message. Revised text: On Communication Diagrams, the Messages are decorated by a small arrow in the direction of the Message close to the Message name and sequence number along the line between the lifelines (See Table 17 and Figure 351).
Actions taken:
November 26, 2004: reeived issue
August 23, 2006: closed issue

Discussion:

The line between two lifelines of a Communication Diagram is merely a placeholder for
the set of message identifiers (including sequence numbers) for messages between these
lifelines. Messages are also in sequence diagrams associated with connectors (optionally),
and there is no difference for Communication Diagrams.
On your resolution; I understand that this graphic path is not associated to a connector
but I found the use of the term "connector" in the description confusing and I think it
should be replaced. I also think that the graphic paths section for any diagram should
include all graphic paths, even if they don't represent abstract syntax elements.

Issue 7951: UML 2 Super Basic Interactions (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Basic Interactions includes SendOperationEvent whose superclass is
MessageEvent, which is in CommonBehaviors::Communications.


The problem is that the Basic Interactions package is in Level 1, but
CommonBehaviors::Communications is in Level 2.


The same is true for SendSignalEvent. In fact Event itself is also in
Communications so there's a problem with the whole set of Event subtypes
defined in BasicInteractions.

Also BasicActions::SendSignalAction references Communications::Signal

Resolution: Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 26, 2004: received issue
October 27, 2008: closed issue

Issue 7956: InfrastructureLibrary defines, but should not use package merge (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to 7623 said to replace all �import� by �merge� in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2. 

Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level.

Resolution: closed no change
Revised Text: Add the following to the end of the first paragraph in section 10, just before Figure 64: Figure 64 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Basic. Package Basic imports model elements from package PrimitiveTypes. Basic also contains metaclasses derived from shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Basic by copy. Add the following to the end of the paragraph just before figure 70. Figure 70 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Constructs. Package Constructs imports model elements from package PrimitiveTypes. Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy. Figure 70 uses PackageMerge to illustrate the packages that contribute to the definition of Constructs and how. The InfrastructureLibrary metamodel does not actually include these packages merges as Constructs is a complete metamodel that already includes all the metaclasses in the referenced packages. This allows Constructs to be understood and used without requiring the use of PackageMerge. Disposition: Resolved
Actions taken:
December 1, 2004: received issue
August 23, 2006: closed issue

Discussion:

Before 7623, InfrastructureLibrary defined, but did not use package merge. Packages in Abstractions were only imported into Basic and Constructs. And because neither Basic nor Constructs actually referred to anything in Abstractions, these imports had no consequence one way or the other. They had no effect on the merge, and no effect on XMI and/or XSD generation for either MOF2 or UML2.
However, changing them to merges, and modifying Constructs so a merge is required to make it complete changes things. In order to actually do the package merges resulting from 7623, and to generate the XMI and XSD for EMOF, CMOF, and all of the UML2 compliance levels, Abstractions must be cleaned up.  That is, all of the extraneous superclasses have to be removed, the proper superclasses from dependent packages have to be added in order for all references to be resolved before the merge, and any other errors that may be in Abstractions will need to be corrected. The full extent of the required changes cannot be known until the merges are actually attempted.
Both the Superstructure and MOF/Infra FTFs have agreed to defer Abstractions issues. Therefore, the resolution to issue 7623 should be amended so that Abstractions is not merged into Constructs, and therefore any issues resulting from these merges can be deferred. As a result, Abstractions will remain more decoupled from the rest of MOF2 and UML2 making it easier to address the deferred issues in an RTF. 
The "import"s that were in Figure 70 are not actually necessary. These are left over from the old definition of package merge which required the imports in order to make the imported metaclasses visible for subclassing by their corresponding merging classes. The new definition of package merge eliminates this subclassing and therefore the need to retain imports to merged packages. As a result, there are actually no dependencies between the Abstractions packages, Basic, and/or Constructs. 
However, it is still useful to indicate how Basic and Constructs were derived, and how they relate to Abstractions packages that contributed to their definition. This issue was resolved on a previous ballot. Changes are already in the Infra spec.
Disposition: Closed, no change

Issue 7958: should retain Comment and its associations to Element (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

Resolution: This is resolved in the UML 2.2 specification. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
December 1, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 7967: An observed time value must be written into a structural feature (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily

Resolution: Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
December 3, 2004: received issue
October 27, 2008: closed issue

Issue 7970: Minor error in BNF of an message argument (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Minor error in BNF of an message argument: Instead <argument> ::= (<[parameter-name> �=�] write <argument> ::= ([<parameter-name> �=�]

Resolution:
Revised Text: Before (in Section 14.3.20 page 540): <argument> ::= (<[parameter-name> �=�] <argument-value>) | (<attribute> �=� <out-parameter- name> [�:� <argument-value>] | � -� Revised: <argument> ::= ([<parameter-name> �=�] <argument-value>) | (<attribute> �=� <out-parameter- name> [�:� <argument-value>] ) | � -�
Actions taken:
December 7, 2004: received issue
August 23, 2006: closed issue

Issue 7973: UML 2 Super / Incorrect statement on port visibility (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The updated UML spec p162 states: 

"UML Superstructure 2.0 Draft Adopted Specification 

A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port 
symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its 
visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it 
is protected by default)." 

This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility.  Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #).

Resolution:
Revised Text: Replace the first paragraph of the Notation section on p.177, section 9.3.11 (Port) by "A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. The port symbol may be placed either operlapping the boundary of the rectangle symbol denoting that classifier or it may be shown inside the rectangle symbol."
Actions taken:
December 10, 2004: received issue
August 23, 2006: closed issue

Issue 7977: ReduceAction (uml2-rtf)

Click here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:

It has come to my attention that the removal of the ReduceAction (fair
enough) requires the use of a variable (a very bad idea) to construct an
alternative specification.
 
To do something like Reduce(<data expression>, Add) in UML 1.5, you
would have to say:


- An activity/structure node with variable Sum.
- The expansion region takes the collection as input and has no
output. In this case, the output collection will have only one
element in it.
- In the region, edges coming from/going to the inputs/outputs take
elements from the input collections and put elements in the output
collections.
- The region uses CallOperationAction with operation timeofLastCall to
get the time and CallBehaviorAction on the (primitive)
FunctionBehavior for addition and updates the variable.
- After the region is complete, the variable has the sum in it.


The 1.5 Action Model included variables so that those who "needed" them
could have them.  However, the introduction of variables changes the
static-single-assignemnt nature of the language and would now require
data-flow analysis of a developer model to work out what is happening.
Before all we had to do was scan for Variable Actions and reject the
developer model so proposed.


In other words, those of us in the translation business did not need
variables, and we could ignore those models that used them.  Now we're
stuck.

Topic: ReduceAction


UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
to elements of a collection until only only element is left.  It did not
constrain order or concurrency of application.  It was replaced with
ExpansionRegion UML 2, which requires commitment to order and
concurrency.

Resolution: Corrections to issue description:
Revised Text: UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 64 � The filer is explaining how to achieve the effect of UML 1.5 ReduceAction with UML 2 ExpansionRegion. It does not actually work, because each input collection must provide at least two values for each cycle on the contents of the region, whereas ExpansionRegion currently only provides one value per input per cycle. � The last paragraph of the discussion is incorrect. The concurrent mode of ExpansionRegion only allows concurrency, it does not require concurrency. In addition, the outputs of ExpansionRegion are collections, whereas the output of ReduceAction is a single element, calculated from the elements of the input collections. Even if a regular output pin is used instead of an ExpansionNode, the output of the contents of the region (the reducing action) must be returned to the input collection for further processing by the action. ReduceAction was inadvertently omitted from the U2P submission. For backwards compatibility with UML 1.5 it is added below, based on the UML 1.5 ReduceAction. Revised Text: In Actions: At end of Abstract syntax section, after Figure 156, add new figure as follows (adds ReduceAction to CompleteActions): Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 65 In Class Descriptions, add entry for ReduceAction, as follows: ReduceAction (from CompleteActions) (CompleteActions) ReduceAction is an action that reduces a collection to a single value by combining the elements of the collection. Generalizations Action (from BasicActions) Description This action takes a collection as input and produces an output by applying a behavior with two inputs pairwise to the elements of the collection. Attributes � isOrdered : Boolean = false Tells whether the order of the input collection should determine the order in which the behavior is applied to its elements. Associations � collection : InputPin [1] The collection to be reduced (subsets Action::input) � reducer : Behavior [1] Behavior that is applied to two elements of the input collection to produce a value that is the same type as elements of the collection. � result : OutputPin [1] Gives the output pin on which the result is put (subsets Action::output). Constraints [1] The type of the input must be a collection. [2] The type of the output must be compatible with the type of the output of the reducer behavior. [3] The reducer behavior must have two input parameters and one output parameter, of types compatible with the types of elements of the input collection. Semantics The behavior is invoked repeatedly on pairs of elements in the input collection. Each time it is invoked, it produces one output that is put back in an intermediate version of the collection. This repeats until the collection is reduced to a single value, which is the output of the action. If isOrdered is false, the order in which the behavior is applied to pairs of values is indeterminate. This will not affect the result of the action if the behavior is commutative and associative, see below. If separate invocations of the behavior affect each other, for example, through side-effects, the result of the actions may be unpredictable, however. If the reducing behavior is not commutative and associative, as with matrix multiplication, the order of the elements in the collection will affect the result of the behavior and the action. In this case, isOrdered should be set to true, so the behavior will be applied to adjacent pairs according to the collection order. The result of each invocation of the behavior replaces the two values taken as input in the same position in the order as the two values. If isOrdered = false, the reducer behavior should be commutative and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is commutative because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Commutativity and associativity are not required, but the result will be indeterminate if isOrdered = false. Notation None. Examples ReduceAction can be used to reduce a list of numbers to the sum of the numbers. It would have one input pin for a collection of numbers, one result pin for a number, and an addition function as the reducer behavior. For example, suppose the input collection has four integers: (2, 7, 5, -3). The result of applying the reduce action to this collection with an addition function is 11. This can be computed in a number of ways, for example, ( ( (2+7) + 5) + -3), (2 + (7 + (5 + -3))), ((2 + 7) + (5 + -3)). Rationale The purpose of ReduceAction is to specify the transformation of a collection to a single value by pairwise application of a behavior, without necessarily committing to the order in which the pairs are chosen. Changes from UML 1.5 ReduceAction replaces ReduceAction in UML 1.5. It has the same functionality, except it takes one collection instead of multiple as input, and produces one result instead of multiple. The effect of multiple input collections can be achieved in UML 2 with an input that is a collection of collections, where the nested collections are created by taking one element from each of the multiple collection inputs to the UML 1.5 ReduceAction.
Actions taken:
December 14, 2004: received issue
August 23, 2006: closed issue

Issue 7986: Section: 14.3.7 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:

... of an object. (missing period) ... destruction of the instance -> of the object ... that this instanceowns -> instance owns

Resolution: see above
Revised Text: Before (in section 14.3.7 page 519): A DestructionEvent models the destruction of an object New text: A DestructionEvent models the destruction of an object. Editor�s note: The above was already fixed in the copy edit of the formal spec Before: A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. It may result in the subsequent destruction of other instances that this instanceowns by composition (see �Common Behaviors� on page 453). New text: A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. It may result in the subsequent destruction of other objects that this object owns by composition (see �Common Behaviors� on page 453).
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Discussion:

The issue is in principle trivial as the suggestions are meant to be editorial. However,
implicitly the question of using �instance� or �object� sneaks in here. Neither in the
Interactions chapter nor in other chapters is the distinction well established. I have
decided here to propose an editorial change that use �object� whenever we are talking
about an instance of a class, and that is what we are doing here.

Issue 7987: Section: 14.3.13 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:

... needs not be the whole -> need not be

Resolution:
Revised Text:
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Discussion:

The suggested editorial change is incorrect English.
Disposition: Closed, no change

Issue 7988: Section: 14.3.14 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:

... <interactionconstraint> -> <InteractionConstraint> ... in Figure 335 -> Figure 335 or 352

Resolution:
Revised Text: Before in section 14.3.14 page 529: Please refer to an example of InteractionConstraints in Figure 335. New text [the editor needs to use cross-references]: Please refer to examples of InteractionConstraints in Figure 335 and Figure 352.
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 7989: Section: 14.3.16 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Minor
Summary:

... and InteractionOperand represent -> represents

Resolution:
Revised Text: Before in Section 14.3.16 page 530: An InteractionOperand represent one operand of the expression given by the enclosing CombinedFragment. New text: An InteractionOperand represents one operand of the expression given by the enclosing CombinedFragment.
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 7990: Section: Table 14 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Richard Sanders, )
Nature: Clarification
Severity: Significant
Summary:

Bottom of page: Node type "Stop" should be "Destruction event"

Resolution:
Revised Text: Before: [in column Node Type of the table 14] Stop New Text: DestructionEvent
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 7994: Presentation Options (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Presentation Options: Add after first sentence: "State symbols may optionally be used to describe a Constraint" "The regions represent the orthogonal regions of states" - delete this. The identifier need -> The name of the state need

Resolution: The text referred in this issue does no longer exist. Disposition: ClosedNoChange
Revised Text:
Actions taken:
December 18, 2004: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 7995: StateInvariants/Continuations (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

StateInvariants/Continuations: add to figure a Continuation (e.g. Idle) that spans :Y and an additional lifeline :X

Resolution:
Revised Text: Before (Table 14, page 553): Row on StateInvariant/Continuations New Text:
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 7996: Add concept "StateInvariant" (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add concept "StateInvariant" in figure, with arrows to "mystate" and "{Y.p == 15}"

Resolution:
Revised Text: Before (Figure 348 page 558): [a figure without any explanatory additions inside the illustrations] New Text: StateInvariant Disposition: Resolved
Actions taken:
December 18, 2004: received issue
August 23, 2006: closed issue

Issue 8015: Transitivity in composition (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Evan K. Wallace, evan.wallace(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends.

Resolution:
Revised Text: In the Superstructure document in section 7.3.3 on page 38 replace the sentence: Compositions define transitive asymmetric relationships�their links form a directed, acyclic graph. by the sentence: Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. In the Infrastructure document in section 11.3.1 on page 115 replace the sentence: Compositions define transitive asymmetric relationships�their links form a directed, acyclic graph. by the sentence: Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8017: Pin/parameter matching constraints (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Pin/parameter matching constraints: The wording for CallAction, constraints 2 and 3 should be consistent with the wording of constraint 3 for CallBehaviorAction and CallOperationAction

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

Resolved by Issue 7319.
Disposition: Closed, no change

Issue 8018: Section: CB/ACT (uml2-rtf)

Click here for this issue's archive.
Source: MEGA International (Mr. Antoine Lonjon, alonjon(at)mega.com)
Nature: Revision
Severity: Minor
Summary:

Matching by order difficult to implement Matching by order of the parameters of methods and operations and pins and parameters is difficult to implement in relation database implementations.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
October 24, 2006: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8019: Section: Classes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Dependency should specialize source/target On Dependency, client and supplier should specialize source and target from DirectedRelationship. Source/target are derived unions, so can't be used otherwise

Resolution:
Revised Text: see ptc/2006-04-01
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8021: Section: Classes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Specializing one association end Suppose we have a class diagram like this: <pre>
      aend                  bend
   A ----------------------------- B
   ^                               ^
   |                               |
   |                               |
   |                               |
   |                               |
   |                      subbend  |
   |               {subsets bend}  |
  SubA -------------------------- SubB


</pre>
 What metarelation is used between the lower left end and the upper left end (aend)? It is not redefined or subsetted.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

There are four properties in this model (assuming the properties are owned by the class):
A::bend, B::aend, SubA::subbend, and an unnamed property ::SubB (or SubB::subA by
default). The subsets constraint only indicates all the elements in SubA::subbend must be
contained in A::bend. There are no constraints or any other connection between
properties B::aend and SubB::subA.
Disposition: Closed, no change

Issue 8025: Associations between interfaces (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Associations between interfaces The wording of the caption in Figure 56 implies that association between interfaces have implication on required and provided interfaces. My udisjoinnderstanding from mailing list discussion is that this is only an example, not a semantics. Should be clarified in the caption that this is an example of applying associations to interfaces.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
October 24, 2006: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8027: Connector multiplicity notation (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Connector multiplicity notation The notation section of ConnectorEnd says multiplicities shown on connector lines represent the multiplicities of both the association *and* the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel.

Resolution: see above
Revised Text: In 9.3.7., sub-section �Constraints� add [4] The multiplicity of the connector end may not be more general than the multiplicity of the association typing the owning connector. In 9.3.7., sub-section �Notation�, replace �These adornments specify properties of the association typing the connector.� by �In cases where there is no explicit association in the model typing the connector, these adornments specify the multiplicities of an implicit association. Otherwise, they show properties of that association, or specializations of these on the connector.�
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

The adornments on connector ends either specify properties of the association that types
the owning connector (when that association is inferred) or it reflects properties of that
association, otherwise. The multiplicity may be more specific than the multiplicity of the
association typing the connector.

Issue 8028: create dependency Figures 103 and 121 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for BehavioralFeature as: "Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature."

Resolution:
Revised Text: In Figure 103, invert the arrow and delete the stereotype �create�. Insert the stereotype �create� before the operation name �make�. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is an operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype �create�, as shown in Figure 103). In Figure 121, invert the arrow and delete the stereotype �create�. Insert the stereotype �create� before the operation name �make�.
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8029: underlined association name (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

underlined association name Figures 120 and 121 underline the association names, which doesn't seem consistent with the notation for instances in Figure 21.

Resolution: The notation for instance specification seems clear that if an association name is shown on an instance specification, that this name would be underlined, see p.84: �It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.� (The diagram example in that section does not show the name.) Therefore, the above two figures are consistent with the notation defined for instance specifications. One could eliminate the association name, if so desired. Revised Text: Disposition: Closed, no change
Revised Text:
Actions taken:
December 30, 2004: received issue
October 27, 2008: closed issue

Issue 8030: Interactions chapter refers to ActivityInvocations (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Interactions chapter refers to ActivityInvocations The Interactions chapter still refers to ActivityInvocations, which was only in an intermediate draft of the original submission. I think it should be CallBehaviorAction or CallOperationAction, not sure.

Resolution: The term ActivityInvocations only appears once, on page 563 of ptc/04-10-02.
Revised Text: In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionUses. Inline Interaction diagrams and InteractionUses are considered special forms of ActivityInvocations CallBehaviorAction.
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8031: Destruction semantics in StructuredClassifier (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties

Resolution: see above
Revised Text: In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed."
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

After further discussions with Conrad, proposing enhancements to the text on p.171 along
the lines suggested by Conrad:
In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the
2nd paragraph by:
"All such links corresponding to connectors are destroyed, when the containing classifier
instance is destroyed."
This reflects Conrad's phrasing "all links that exist only because of connectors between
roles of the structured classifier". However, I use "corresponding to connectors" to match
the sentence before, where we talk about the creation of links corresponding to
connectors. The connectors being destroyed are precisely those connectors that we speak
about in the previous sentence. I think this is clearer.

Issue 8032: Link maintenance in StructuredClassifier (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics.

Resolution: see ptc/2006-04-01 p 94
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8033: Figure 119 missing multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Figure 119 missing multiplicity. Figure 119 (Connectors and parts in a structure diagram) is missing a multiplicity on the right side of the connetor

Resolution: see above
Revised Text: To make this clearer, insert the following parenthetical remark after �and two instances of the right wheel�: (as no multiplicity is specified for the connector end at the right wheel, the multiplicity is taken from the attached role)
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

The multiplicity on the right end of the connector has been purposefully elided, as
defined in section 9.3.7

Issue 8035: Notation for method (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Need a notation for instances of the specification/method metaassociation (Figure 311).

Resolution: See issue 6150 for disposition
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8036: Preserve order in result of read actions (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

The semantics of the various read actions (ReadStructuralFeatureAction, etc) should specify that the order of the retrieved collections is preserved in the values of the output pin.

Resolution:
Revised Text: Add the following sentence in the semantics section of ReadStructuralFeatureAction after the third sentence: �The order of the retrieved values in the output pin is the same as the ordering of the values of the structural feature.� Add the following sentence in the semantics section of ReadVariableAction after the second sentence: �The order of the retrieved values in the output pin is the same as the ordering of the values of the variable.�
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8037: Optional inputs (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

When does an action start when all its inputs are optional?

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

By optional inputs, the filer presumably meant that the lower multiplicity of the input
pins are all zero, perhaps due to being on a CallAction for a behavior or operation with
parameters that all have zero lower multiplicity. The Actions chapter only requires that
values are available on the input pins up to the lower multiplicity, which intentionally
leaves the case of all optional inputs open to the specialized behaviors that use actions
(see InputPin in Actions). If the action is in an activity, the action can be started with a
control flow (see ControlFlow). If it has no incoming control flow, and is not an
exception handler body of action for an ActionPin, the action can start when the
containing activity or structured node does (see InitialNode and StructuredActivityNode).
Disposition: Closed, no change

Issue 8038: IsReadOnly constriant (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

done) IsReadOnly constriant Constraint on StructuralFeature::isReadOnly: if true and there is no intialization value, then the lower multiplicity must be zero.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

This is overconstrained, because the default value could be set dynamically before
initialization, rather than a default value. As long as this happens before initialization is
over, there is no violation of multiplicity. In any case, UML doesn't enforce when
constraints are evaluated or inconsistencies repaired.
Disposition: Closed, no change

Issue 8039: DestroyObjectAction semantics (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Clarify the "owns" language in DestroyObjectAction to mean the objects related by composite associations

Resolution:
Revised Text: In Actions, DestroyObjectAction, Semantics, first paragraph, last sentence: after "objects owned by the object" insert "through composite aggregation ".
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8040: ObjectNode, constraint 1 In ObjectNode (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

ObjectNode, constraint 1 In ObjectNode, Constraints (Complete Activities), the first constraint regarding upperbound should be removed. The size of the object node buffers can be any size.

Resolution:
Revised Text: In Activities, remove constraint 1 in ObjectNode, Constraints (Complete Activities)
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Issue 8041: StructuredActivityNode specialized multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

The semantics of StructuredActivityNode still says "This constraint is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityNode". The FTF changed the metamodel for this to not use specialized multiplicity.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue
August 23, 2006: closed issue

Discussion:

The FTF issue was 6677 and was about interruptible regions, not structured activities.
Disposition: Closed, no change

Issue 8042: Terminology Issue (uml2-rtf)

Click here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity:
Summary:

When we build a state machine (nee State chart diagram) to define the behavior of a Dog, say, each dog instance has its own state.
 
In other words, each copy of the state machine diagram has it's own state.  What is the official term for each-copy-of-the-state-machine, the entity that has state. We need to be able to say "The <state machine thing> for Fido is in the state 'Barking'" and "The <state machine thing> for Rover is in the state Sleeping".

Resolution: Resolution: The submitter does not raise an issue against the specification, but asks a question for clarification. Such terminology might be useful in explaining the semantics, but is not required for the specification. Disposition: Closed, no change
Revised Text:
Actions taken:
December 30, 2004: received issue
October 27, 2008: closed issue

Issue 8062: section 9.20.2 VisibilityKind lists two types of visibility (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

In section 9.20.2 VisibilityKind lists two types of visibility--Public and Private. Yet the glossary (page 19) and Figure 80 on page 119 (and many other figures) list three--Public, Private, and Protected. Version 1.5 also defined a fourth type of visibility--Package. Please clarify and or enhance the definition of VisibilityKind in 9.20.2 to explain the differences between the glossary and the Figure.

Resolution:
Revised Text:
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The glossary has been removed in the final version of the spec. This issue is no longer
applicable.
Disposition: Closed, no change

Issue 8063: Text references Figure 8 and the correct figure number is 6 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Text references Figure 8 and the correct figure number is 6

Resolution: This is indeed an incorrect figure reference.
Revised Text: In the second paragraph of section 7.2.9 on page 29 of ptc/04-11-16 change the text fragment: Figure 8 to Figure 6 Editor�s note: This was fixed in the copy edit pass; no change required
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Issue 8064: unclear statement (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The last part of the following statement makes no sense to me: "Understandability. While increasing the precision and conciseness, the specification techniques should also improve the readability of the specification. For this reason a less than strict formalism is applied, since a strict formalism formal technigues" It appears that part of the sentence got left out as there is no period

Resolution: There is a word missing in this text.
Revised Text: In the introduction to section 8 on page 32 of ptc/04-11-16, in the bullet point for �Understandability� replace the text: For this reason a less than strict formalism is applied, since a strict formalism formal techniques with the following text: For this reason a less than strict formalism is applied, since a strict formalism implies formal techniques. Editor�s note: This was fixed in the copy edit pass; no change required
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Issue 8065: extra word in the last sentence of the paragraph under Attributes (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

 believe that there is an extra word in the last sentence of the paragraph under Attributes. "If the mulitplicity of the attribute is supressed if it is '1' (default in UML)." I believe the sentence should read "The multipliticy of the attribute is supressed if is is '1' (default in UML)."

Resolution:
Revised Text: In the first paragraph of the Attributes subsection of section 8.2.1 of ptc/04-11-16, replace the sentence: If the multiplicity of the attribute is suppressed if it is �1� (default in UML). with the sentence: If the multiplicity of the attribute is suppressed, it defaults to �1�.
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Issue 8066: clarify what a directed association is (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

 am not an expert on UML and am reading this to learn about it. Could you please clarify what a directed association is. A search of the document does not yield any other reference to this term.

Resolution: see above
Revised Text: Add the following text to the end of the paragraph above (pg. 39 in the Superstructure spec [pg. 116 in the Infrastructure spec]): This notation is for documentation purposes only and has no general semantic interpretation. It is used to capture some application-specific detail of the relationship between the associated classifiers.
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

There are no explicit references to the term �directed association� in the entire text of the
spec. Consequently, it is not clear from the issue text if this is a reference to (a) an
association with navigability adornments or (b) to the fact that an association name may
include an arrow indicating the order in which a binary association is to be traversed
when reading the diagram. Since the concept of navigability is discussed at length in the
spec, I will presume that the confusion is with the latter. With respect to that, the spec
states the following:
On a binary association drawn as a solid line, a solid triangular arrowhead next to or in
place of the name of the association and pointing along the line in the direction of one
end indicates that end to be the last in the order of the ends of the association. The arrow
indicates that the association is to be read as associating the end away from the direction
of the arrow with the end to which the arrow is pointing (see Figure 19).

Issue 8067: Section is badly worded and does not make a lot of sense (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Section is badly worded and does not make a lot of sense. I interpreted it as "Often an informal convention is used to show (a part of) a construct, e.g., the name of a class should be centered and in bold."

Resolution:
Revised Text: Replace the first sentence of section 8.2.9: Often is an informal convention how to show (a part of) a construct, like the name of a class should be centered and in bold. With the sentence: Often non-normative conventions are used in representing some part of a model. For example, one such convention is to always have the name of a class in bold and centered within the class rectangle.
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Issue 8068: typing error in the statement :unrestricted ? (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

 believe there is a typing error in the statement :unrestricted: Indicated that there is no restriction no [should be to?] adding new values, changing a value, or removing values to an occurrence of a StructuralFeature

Resolution:
Revised Text: In section 9.2.1 in the text accompanying the �unrestricted?� entry on page 44 of ptc/04-11- 16, replace the phrase: Indicates that there is no restriction no adding new values, with the phrase: Indicates that there is no restriction on adding new values, Editor�s note: Not done, superseded by the resolution to issue 6216.
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Issue 8069: What happened to real numbers (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals.

Resolution:
Revised Text:
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The Literals package is necessary to use the built-in primitive types Integer, String,
UnlimitedNatural, and Boolean. The Literal classes map values in value specifications to
the appropriate primitive type.
All other number types that are not built-in can be defined by introducing a new primitive
type, e.g. primitive type Real. These user-defined types are integrated into value
specifications via the instance value class.
Disposition: Closed, no change

Issue 8070: methods not defined under attributes (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In all previous sections when a diagram shows a named association, the text defines these under the heading Associations. All of a sudden you've changed methods and are not defining these under attributes. A clarification as to why this is done would help those of us who are not UML experts.

Resolution:
Revised Text:
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter is confused by the difference between the Associations and Attributes
subsections of metaclass descriptions. Note that this issue was raised in the context of the
older version of the spec (ptc/03-09-15). The required explanation was added in the later
version of the spec (ptc/04-11-16) in section 6.3.1.
Disposition: Closed, no change

Issue 8072: Figure 68 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 68 does not show the {composite} notation for the attribute ownedType: Type

Resolution: see above
Revised Text: In section 10.4.1 on page 105 in the descriptions for the items �nestedPackage� and �ownedType� delete the phrase �{composite}� (2 occurrences) from the text.
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The {composite} notation was removed in the finalization task force and any references
to it should also be removed.

Issue 8073: Section: 11.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The last phrase in the sixth paragraph from the top which starts with "For n-ary associations..." is an incomplete prepositional phrase and the meaning is unclear

Resolution:
Revised Text: On page 115 of ptc/04-11-16 replace the phrase: If the lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link� with the phrase: A lower multiplicity of 1 (or more) for an end of an n-ary association implies that one link� Editor�s note: This was fixed in the copy edit pass; no change required
Actions taken:
January 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8074: Section: 11.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The description refers to the Classifiers Diagram but no figure number (Figure 84) or page number (page 127) is given. It would greatly facilitate the reading if the user did not have to search for this. In section 6.3 on How to Read this Specification, it is stated that extensive cross-references are given. This specification would be better if more cross-references were given, especially when a figure or section that is found elsewhere in the document is referenced. I sent in a request to clarify Chapter/Section 10.2. I have since found that an excellent clarification exists in Chapter 11.3. If this had be referenced in Chapter 10.2 it would have saved this reader several hours of confusion and frustration

Resolution:
Revised Text:
Actions taken:
January 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

Note that this issue was raised in the context of the older version of the spec (ptc/03-09-
15). The required explanation was added in the later version of the spec (ptc/04-11-16) in
section 6.3.1.
Disposition: Closed, no change

Issue 8075: search for referenced item -- Section: 11.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

A reference is made to the Operations Diagram in the Description section but no figure number (93) or page number (146) is given. It would save time and greatly decrease the frustration factor for this reader if I didn't have to search for the referenced item.

Resolution:
Revised Text:
Actions taken:
January 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

There are numerous examples of this in the spec, far too numerous to detect and fix at
this point. Fortunately, for those looking at the spec in electronic form, there are
hyperlinks that direct readers to the appropriate references item. Given the size of this
spec (over 800 pages), this is definitely the preferred format for accessing this document
(furthermore, it is more environmentally friendly as well ;-) )
Disposition: Closed, no change

Issue 8076: Section: 11.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The phrase that starts "These constructs that are used..." is not a complete sentence and confusing. I believe that the word "that" needs to be deleted

Resolution:
Revised Text: Change the phrase in the second sentence of section 11.6 on page 139 from: These constructs that are used for� to: These constructs are used for� Editor�s note: This was fixed in the copy edit pass; no change required
Actions taken:
January 5, 2005: received issue
August 23, 2006: closed issue

Issue 8078: Actor is a specialized Classifier and not BehavioredClassifier (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

Actor is a specialized Classifier and not BehavioredClassifier. Therefore an actor is not allowed to realize an interface. I propose to inherit Actor from BehavioredClassifier. It is useful to model actors with interfaces. The actor/subject communication requires the definition of signals/messages that can be sent from the subject to an actor.

Resolution: see ptc/2006-04-01 p 108/109
Revised Text:
Actions taken:
January 6, 2005: received issue
August 23, 2006: closed issue

Issue 8079: Section: 11.6.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The each sentence in the third paragraph under semantics appears to have an incorrect "and" in them. I believe the and should be replaced by the word "or" in each sentence. The second paragraph seems to have a couple of misplaced hyphens.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02): On page 65, replace the paragraph: If more than one element with the same name would be imported to a namespace as a consequence of element imports or package imports, the names of the imported elements must be qualified in order to be used and the elements are not added to the importing namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, the name of the imported element must be qualified in order to be used and is not added to the importing namespace. with the paragraph: If more than one element with the same name would be imported to a namespace as a consequence of element imports or package imports, the elements are not added to the importing namespace and the names of those elements must be qualified in order to be used in that namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, that element is not added to the importing namespace and the name of that element must be qualified in order to be used. Infrastructure (ptc/04-11-16): On page 147, replace the paragraph: If more than one element with the same name would be imported to a namespace as a consequence of element imports or package imports, the names of the imported elements must be qualified in order to be used and the elements are not added to the importing namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, the name of the imported element must be qualified in order to be used and is not added to the importing namespace. with the paragraph: If more than one element with the same name would be imported to a namespace as a consequence of element imports or package imports, the elements are not added to the importing namespace and the names of those elements must be qualified in order to be used in that namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, that element is not added to the importing namespace and the name of that element must be qualified in order to be used.
Actions taken:
January 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

The hyphens problem was resolved by the resolution to issue 6164.
The submitter is making the wrong assumption about how element import works. The
statements are saying, in effect, that, in case of name clashes, the clashing name is NOT
imported (the submitter seems to be assuming that it is). However, the text should be
clarified to avoid confusion.

Issue 8080: Section: 11.8.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 98 shows an merged package P::A in the source package S. I do not see how P::A got merged when Figure 97 shows no merge between target P and source S or between source R and source S. The text says that packages P and Q are being merged by package R while package S merges on package Q (with the open ended arrow indicating Q as the target but the keyword <<merge>> at the end nearest S. The statement above Figure 98 says the transformed packages R and Q are shown but the figure has the packages labeled R and S. There appears to be no merge connection between P and S but a subpackage from P appears in S. The text and figures are very confusing and need clarification

Resolution:
Revised Text:
Actions taken:
January 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

This whole area was redone in the finalization phase so that the issue above is no longer
applicable.
Disposition: Closed, no change

Issue 8081: Section: 13.1.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Additional option [1] says that the query lowerBound () returns the lower bound of the multiplicity as an Integer. Why is the type Interger used instead of the type UnlimitedNatural? An integer can be a negative number but not so with naturals. My understanding is that multipliticity is not allowed to be less than 0.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02): On page 720 in the �lowerBound()� additional operation ([1]) of ExtensionEnd (section 18.3.3) replace the first line of the OCL: ExtensionEnd::lowerBound() : [Integer]; with the line: ExtensionEnd::lowerBound() : Integer; Infrastructure (ptc/04-11-16): On page 172 in the �lowerBound()� additional operation ([1]) of ExtensionEnd (section 13.1.3) replace the first line of the OCL: ExtensionEnd::lowerBound() : [Integer]; with the line: ExtensionEnd::lowerBound() : Integer;
Actions taken:
January 10, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter is losing sight of the fact that lowerBound is always constrained to be a
non-negative number by constraint [2] of MultiplicityElement (see page 77 in ptc/04-11-16).
However, there is an error here in the definition of this operation that has an extra set of
square brackets.
See also the resolution to issue 6502.

Issue 8082: Section: 13.1.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 115 shows the <<enumeration>> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5?

Resolution:
Revised Text:
Actions taken:
January 10, 2005: received issue
August 23, 2006: closed issue

Discussion:

The example shows an example of a user model that does not have to conform to the
conventions used in the spec itself. Furthermore, there is no Style Guideline associated
with Enumeration that might suggest that the convention used in the spec should be
applied to user models as well. Hence, this is a perfectly valid example and nothing needs
to be changed.
Disposition: Closed, no change

Issue 8083: Section: 7.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Second sentence in second paragraph under description is somewhat confusing. "The constraint does not necessilarily apply to the namespace itself, but may also apply to the elements in the namespace." The use of the word "also" bothers me. Do you mean "instead" rather than also. Wouldn't it make more sense, in the context of the first part of the sentence, that the constraint could instead apply to the elements in the namespace rather than the namespace. If you mean that a constraint could apply to both or the namespace or the element in the namespace then the statement needs to be reworded

Resolution: The text does need to be reworded to eliminate such confusion.
Revised Text: Superstructure (ptc/04-10-02): On page 102 (section 7.3.34) replace the sentence: The constraint does not necessarily apply to the namespace itself, but may also apply to elements in the namespace. with the sentence: A constraint associated with a namespace may either apply to the namespace itself, or it may apply to elements in the namespace. Infrastructure (ptc/04-11-16): On page 54 (section 9.5.2) replace the sentence: The constraint does not necessarily apply to the namespace itself, but may also apply to elements in the namespace. with the sentence: A constraint associated with a namespace may either apply to the namespace itself, or it may apply to elements in the namespace.
Actions taken:
January 12, 2005: received issue
August 23, 2006: closed issue

Issue 8084: Section: 7.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful.

Resolution: see above
Revised Text: OMG Issue No: 8084 U.S. Geological Survey (Ms. Jane Messenger, jmessenger@usgs.gov) There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that This is a duplicate of issue 6515, which was resolved in the FTF (Ballot 19). However, it seems that the fix for this issue was applied to the superstructure but was accidentally omitted in the infrastructure. Therefore, the fixes should be applied to the Infrastructure. The following changes need to be applied to the Infrastucture spec: 1. Add �protected� and �package� as the third and fourth literal values, respectively, in Figure 63 on page 99. 2. Add �protected� and �package� as the third and fourth literal values, respectively, in the Description subsection of VisiblityKind, section 9.20.2, page 100. 3. Add a third and fourth bullet point to the Semantics subsection of VisibilityKind, section 9.20.2, page 100. � A protected element is visible to elements that have a generalization relationship to the namespace that owns it. � A package element is owned by a namespace that is not a package, and is visible to elements that are in the same package as its owning namespace. Only named elements that are not owned by packages can be marked as having package visibility. Any element marked as having package visibility is visible to all elements within the nearest enclosing package (given that other owning elements have proper visibility). Outside the nearest enclosing package, an element marked as having package visibility is not visible. 4. Add �protected� and �package� as the third and fourth literals, respectively, of the VisiblityKind enumeration in Figure 88, section 11.6.2, page 142. 5. Add a Notation subsection to VisibilityKind at the bottom of page 100 as follows: Notation The following visual presentation options are available for representing VisibilityKind enumeration literal values: �+� public �-� private �#� protected �~� package
Actions taken:
January 12, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is a duplicate of issue 6515, which was resolved in the FTF (Ballot 19). However, it
seems that the fix for this issue was applied to the superstructure but was accidentally
omitted in the infrastructure. Therefore, the fixes should be applied to the Infrastructure.

Issue 8085: Section: 7.4.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Multiplicity is non-negative so shouldn't the lower bound be typed as an unlimited natural (a non-negative number) instead of an integer which can be negative? The upper bound is typed as an unlimited natural. This question also applies to Infrastructure (ptc/03-09-15, sections 9.11 and 9.12).

Resolution:
Revised Text:
Actions taken:
January 12, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter is losing sight of the fact that lowerBound is always constrained to be a
non-negative number by constraint [2] of MultiplicityElement (see page 97 in ptc/04-10-02).
See also the resolution to issue 6502.
Disposition: Closed, no change

Issue 8086: Section: 6.5.1: Error in example (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Error in example. Text for /isComposite : Boolean A state with isComposite = True is said to be a composite state. A composite state is a state that contains at leas one region> BUT the OCL says IsComposite = (region >1) which translates to is greater than one. Use the is equal to or greater than symbol or change the number to 0.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) Page 603 of section 15.3.11, change the OCL constraint for constraint [5] from: isSimple = content.isEmpty() to: isSimple = region.isEmpty() Page 603 of section 15.3.11, change the OCL constraint for constraint [6] from: isComposite = content.notEmpty() to: isComposite = region.notEmpty()
Actions taken:
January 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

This constraint was changed in the FTF. However, there seems to be an error in the OCL
for the corresponding �fixed� constraints which refer to a feature called �content�. This
should be replaced by the feature named �region�.

Issue 8088: Section: 7.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Clarification of subsetting is still confusing to me. The Note has an incomplete sentence for the last "sentence." I believe you need to remove the starting word "If."

Resolution: see above
Revised Text: see ptc/2006-04-01 pages 119/120
Actions taken:
January 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

The text deals with a subtle context and the current formulation may be somewhat
confusing to readers who are not used to formalized natural language.

Issue 8089: Section: 7.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association package:Package[0..1] is listed as being an association of Classifier. However, the only figure to diagram this association is Figure 14 and the association is from Type not Classifier.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) On page 50 in the Associations section of Classifier, remove the entry: package: Package [0..1] Specifies the owning package of this classifier, if any. Subsets NamedElement::namespace.
Actions taken:
January 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

This association end seems to be a remnant of some previous version of the metamodel. It
should be removed. The error only occurs in the Superstructure and not in the
Infrastructure.

Issue 8090: Section: 7.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

If constraind elements are those elements required to evaluate the constraint spedividation, why is the multiplicity for the specification: ValueSpecification[0..1]? Shouldn't the multiplicity be 1? If not, please clarify.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) Change the �specification� entry on page 57 from: specification: ValueSpecification[0..1] to: specification: ValueSpecification[1] Infrastructure (ptc/04-10-14) Change the �specification� entry on page 52 from: specification: ValueSpecification[0..1] to: specification: ValueSpecification[1]
Actions taken:
January 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

Indeed. The metamodel actually shows the multiplicity correctly.

Issue 8091: Section: 7.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Issues 6164 and 6159 still have not been addressed. Figure 36 reads that the client CarFactory is dependent upon the supplier Car which is not what the text states.

Resolution: The fix was not completed. Instead of VehicleType the text should refer to CarFactory.
Revised Text: Superstructure (ptc/04-10-02) Replace the entire paragraph at the bottom of page 61: In the example below, the Car class has a dependency on the Vehicle Type class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class. with the following paragraph: In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class.
Actions taken:
January 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8092: Section: 7.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I am confused by the statements that say "the name of the imported element must be qualified in order to to used and is not added to the importing namespace." Add a statement to clarify that if the name is qualified, how the element is referenced by another element.

Resolution:
Revised Text:
Actions taken:
January 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

I see no problem with this text. It seems perfectly clear. Basically, it is saying that, in
case of a name clash with a local element, the element with the clashing name is not
imported. If the latter element needs to be referenced, the fully qualified name has to be
used.
Disposition: Closed, no change

Issue 8093: Section: 7.3.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Text says that Manager constitutes one GeneralizationSet but Figure 42 uses the word Employee. Please correct

Resolution: The submitter is correct. This is a bug.
Revised Text: On page 74 of ptc/04-10-02 replace the second last sentence of the page from Here, Female Person or a Male Person of Person constitute one GeneralizationSet and Manager another to Here, Female Person or a Male Person of Person constitute one GeneralizationSet and Employee another
Actions taken:
January 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8094: Stereotypes applying in UML 2.0 (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

I have some questions regarding stereotypes using in UML 2.0.
 
1. How to declare user defined stereotype in the model? Should class with stereotype <<metaclass>> and metaclass name be created in the model? How to declare stereotype <<metaclass>>?
 
2. Is some relationship between stereotyped model element and stereotype instance exist? Where stereotype instance should be created (contained) and how model element can collect all applied stereotypes?

Resolution:
Revised Text:
Actions taken:
January 17, 2005: received issue
August 23, 2006: closed issue

Discussion:

These aspects have been largely discussed and amended in the spec. I believe that this
issue is outdated.
1. A <<metaclass>> model element should indeed be part of the model (if not
already present, it should be defined) and an extension between the stereotype
instance and that model element created as per the metamodel in figure 446.
2. The relationship between a stereotype instance and the stereotyped model element
is explained in the semantics section of Extension on page 717 and in figure 448.
Since, by definition, stereotyped model elements are not affected by the presence
of stereotypes, a tool will have to either do a search of the model or cache
information that identifies which stereotypes are applied to that model element.
Disposition: Closed, no change

Issue 8095: Section: 7.3.22 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figures 50 and 51 cause me confusion because Fig. 50 uses as the classifier name a type (String). Yet Fig. 51 shows "Other properties of the feature, such as type" on the second line of the slot streetNumber:Integer = 381. Should the classifier name in Fig. 50 be a type or something more like myAddress. Please clarify, especially that there is a difference, as indicated by the naming convertion, between the instance specification and the feature shown in the slot.

Resolution:
Revised Text:
Actions taken:
January 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter seems to be reading more into the text than is there. I see nothing
confusing about it. In figure 50, the name of the classifier of the InstanceSpecification
�streetName� is indeed �String� � as one would expect. Figure 51 shows an instance of
some composite data type (Address) with two attributes whose values are shown. In case
of the lower attribute (�streetNumber�) the type of attribute is shown as �Integer� � as
one would expect.
Disposition: Closed, no change

Issue 8096: Section: 7.3.32 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Since the lower bound of multiplicity can not be negative by definition, shouldn't the type of /lower MultiplicityElement be UnlimitedNatural? Also, /upper is missing from the list of attributes

Resolution:
Revised Text:
Actions taken:
January 20, 2005: received issue
August 23, 2006: closed issue

Discussion:

My apologies, I now see the /upper but still question use of Interger as the type for /lower instead of UnlimitedNatural. My apologies, I now see the /upper but still question use of Interger as the type for /lower
instead of UnlimitedNatural.
This issue has already been addressed by the resolution to issue 6502.
Disposition: Closed, no change

Issue 8097: Section: 7.3.32 Page: 96-99 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The document defines multiplicity as an "inclusive interval of non-negative integers" which is the same thing as Unlimited Naturals, but in several other places the "non-negative" qualifier for integer is left off leaving only integer as the definition of the lower bound and integers may be negative. Examples are Additional Operations [4]and in the second paragraph of semantics. Additional Operations [2] OCL is incorrect if the type for includesCardinality(c:Integer) is Integer because the third line says that includesCardinality = (lowerBound() <= C) and (UpperBound () >= C). Everywhere else it is stated that the upperBound is UnlimitedNatural NOT an integer. Remove the word "is" following specification in the second sentence of the first paragraph under Notation.

Resolution: see above
Revised Text: In the second sentence of the first paragraph under Notation (page 98 of the Superstructure [page 78 in the Infrastructure]), replace the phrase: the notation will include a multiplicity specification is shown as a text string containing the bounds of the interval with the phrase: the notation will include a multiplicity specification, which is shown as a text string containing the bounds of the interval
Actions taken:
January 20, 2005: received issue
August 23, 2006: closed issue

Discussion:

Constraint [2] of MultiplicityElement ensures that lower bounds of MultiplicityElements
are non-negative integers, so the problems that are listed in the issue cannot occur. (It
could be argued that it would have been �cleaner� to define the type of �lower� as
UnlimitedNatural, but that is merely an optimization that is not worth the disruption that
such a change would induce in existing tools.).
AdditionalOperation [2] is fine even if the argument C is a negative Integer. In fact,
defining the argument as a type Integer is certainly more general and will not result in
exceptions if a negative argument is provided.

Issue 8098: Section: 7.3.33 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I am not an OCL expert (barely a novice) but it seems to me that Constraint [2] is incorrect in stating "->select(ns|ns.name->isEmpty())". Shouldn't that be ->select(ns|ns.name->notEmpty()) because the constraint is saying that there is a name and all of the containing namespaces have a names (in other words, all of the containing namespaces are notEmpty).

Resolution:
Revised Text:
Actions taken:
January 20, 2005: received issue
August 23, 2006: closed issue

Discussion:

No, the OCL is correct. The fragment:
self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty())
is saying that if the set of namespaces whose name is empty is itself empty, then every
namespace has a name.
Disposition: Closed, no change

Issue 8099: Section: 7.3.34 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The sentence "The contraint does not apply to the namespace itself, but may also apply to elements in the namespace." would be better if "also" was replaced with "instead."

Resolution:
Revised Text:
Actions taken:
January 20, 2005: received issue
August 23, 2006: closed issue

Discussion:

That would actually be incorrect. The sentence is saying that the constraint may cover
either the namespace itself, or the names it contains, or, possibly, to both.
Disposition: Closed, no change

Issue 8100: Section: 7.3.35 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The modifications made for multiple languages (Issue 3391) could often be taken by the reader to mean that multiple languages may exist simultaneously in a single opaque expression. An example is the attribute "language:String[0..*] specifies the languages in which the expression is stated" could be interpreted to mean that the expression could be stated in mixed languages. Additionally plurality of verbs and modifying expressions often do not agree with the plurality of the sentence subject. An example of this is "The languages of an opaque expression, is specified, is often..." Subject is the sentence is "languages" so verb should be "are." Furthermore, this statement implies that a single ("an") opaque expression may have more than one language ("languages").

Resolution: see above
Revised Text: It is quite possible that multiple languages may co-exist in the same expression (although they are expected to be serialized rather than interleaved in such cases). These typically serve as alternative forms of expression for the same content. Revised Text: On page 104 of the Superstructure [page 58 of the Infrastructure] replace the first sentence in the Semantics subsection of OpaqueExpression: The interpretation of the expression body depends on the languages. with the following: The expression body may consist of a sequence of text strings � each in a different language � representing alternative representations of the same content. When multiple language strings are provided, the language of each separate string is determined by its corresponding entry in the �language� attribute (by sequence order). The interpretation of the text strings is language specific. Also, on page 105 of the Superstructure [there is no corresponding Infrastructure change], replace the first sentence of the third paragraph of the Notation subsection: The languages of an opaque expression, if specified, is often not shown on a diagram. with the following: The languages of an opaque expression, if specified, are often not shown on a diagram. In the Constraints subsection of OpaqueExpression on page 104 of the Superstructure [page 58 of the Infrastructure], replace the sentence No additional constraints. with the following constraints: [1] If the language attribute is not empty, then the size of the body and language arrays must be the same. language->notEmpty() implies (body->size() = language->size()) [2] If there is only one body then the size of the language is exactly 1 (corresponding to the default language). language->isEmpty() implies (body->size() = 1) Editor�s note: second constraint removed by resolution to 9191
Actions taken:
January 20, 2005: received issue
August 23, 2006: closed issue

Discussion:

It is quite possible that multiple languages may co-exist in the same expression (although
they are expected to be serialized rather than interleaved in such cases). These typically
serve as alternative forms of expression for the same content.

Issue 8103: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add ending guillemets to specification in isIndirectlyInstantiated. Verify that OCL for /provided:Interface[*] is correct. 3rd and 4th lines don't look right to me

Resolution: see above
Revised Text: Insert ending guillemets after specification. Editor�s note: fixed in formal copy edit Replace the term "RealizeInterfaces(self)" in line 3 of the OCL derivation expression for Component::provided on page 151 by the term "RealizedInterfaces(self)"
Actions taken:
January 21, 2005: received issue
August 23, 2006: closed issue

Discussion:

-- BranSelic - 19 May 2005
Line 3 of the OCL constraint should say "RealizedInterfaces(self)" instead of
"RealizeInterfaces(self)".

Issue 8104: Section: 8.3.1 - typo (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence

Resolution:
Revised Text: Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence. Editor�s note: fixed in formal copy edit
Actions taken:
January 21, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8105: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add component icon to fig. 90 <<component>> :ShoppingCart to be consistent with others in diagram

Resolution:
Revised Text: Add component icon to fig. 90, :ShoppingCart to be consistent with others in diagram
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Issue 8106: Section: 8.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Constraints have no OCL syntax or mention that constraints are not definable in OCL. Type in constraint [5] - delete "s" from first "Ports".

Resolution: Resolution: This actually refers to 8.3.3. The constraints have been fixed or deleted by other resolutions (7247-7251). Revised Text: None. Disposition: Closed, no change
Revised Text:
Actions taken:
January 24, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8107: Section: 9.20.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Either delete Issue 7240 note from page, make the correction, or explain why the correction was not made.

Resolution:
Revised Text: see ptc/2006-04-01 p 131
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8108: Section: 9.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Page references are incorrect for "Property" and "StructuredClassifier".

Resolution:
Revised Text: Update page references to latest status.
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Issue 8109: Section: 9.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Better choice of word in Changes from UML 1.x would be to change the "of" in last sentence to "that."

Resolution:
Revised Text: Change the last sentence in Changes� to �Together with the newly introduced internal structure concept replaces Collaboration.representedClassifier.
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8110: Section: 9.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Incorrect page number for reference for "Property" under Description

Resolution:
Revised Text: Update page number for reference for "Property" under Description
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Issue 8112: Section: 9.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add Generalization TypedElement (from Kernal) to fig. 96.

Resolution:
Revised Text:
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue assumes incorrectly that a ConnectorEnd is a typed element. This is not the
case.
Disposition: Closed, no change

Issue 8115: Section: 9.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add generalization for InvocationAction to fig 101 to agree with text on 187

Resolution:
Revised Text:
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

As a general rule, we do not show generalizations that are merge increments explicitly in
the abstract syntax.
Disposition: Closed, no change

Issue 8116: Section: 9.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to Constraints. Notation says to see "CallOperationAction" for an example, but no examples are given in that section

Resolution:
Revised Text: In notation, delete the parenthetical remark starting with �(for example��.
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Issue 8117: Section: 9.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I can't find appropriate figure for the generalization "Parameter (from Kernel, AssociationClasses)". Add appropriate OCL notation to Constraints

Resolution: see above
Revised Text: In constraints section of 9.3.20: Add OCL to constraint: [1] A parameter may only be associated with a connector end within the context of a collaboration. self.end.notEmpty() implies self.collaboration.notEmpty()
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

It is unclear what the issue is pointing to. Parameter is appropriately specialized from
Parameter in Kernel.
The resolution will focus on the OCL only.
-- ThomasWeigert - 18 May 2005
As far as I can see the Parameter (Collaboration) can't navigate to it's context. The
associations from Connectable Element ? to the context (Structured Classifier ? or
Collaboration) isn't navigable. Therefore it's not possible for the Parameter class to
evaluate the constraint.
-- TimWeilkiens - 20 May 2005
Tim, navigability is not meaningful in OCL 2.0, which means that your OCL expression
can navigate against the arrow.
-- BranSelic - 20 May 2005
Bran, in that case the OCL constraint is easy. However it sounds strange to me. How can
the parameter (the context of the constraint) evaluate the expression? Could you give me
the appropriate chapter reference in OCL specification?

Issue 8118: Section: 8.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Reword/rewrite the last two paragraphs of Semantics. Many grammatical mistakes between sentence subject and verb plurality (because of intervening phrases), hard to understand sentences, and an incomplete sentence (last one).

Resolution: I cannot find any such problem in section 8.3.2. However I do find the following, which has duplicated text: "A component's behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Component Realization Dependencies to these Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Realization Dependencies to these Classifiers"
Revised Text: In the Semantics section of 8.3.2, delete one occurrence of "In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Realization Dependencies to these Classifiers."
Actions taken:
January 24, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8119: Section: 8.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"In a system context where there are multople components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors." Combines what? Client keyword missing from fig. 93.

Resolution: I cannot find any such text in section 8.3.2, or indeed anywhere in the current specification. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
January 24, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8120: Section: 8.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Correct statement under Constraints to read "No additional constraints."

Resolution:
Revised Text: Change line following the �Constraints� heading to �No additional constraints.�
Actions taken:
January 24, 2005: received issue
August 23, 2006: closed issue

Issue 8127: Section: 9.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In Examples, the reference page number to SturcturedClassifier is incorrect

Resolution:
Revised Text: In Examples, correct the reference page number to SturcturedClassifier
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Issue 8128: Section: 9.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Associations need derived symbol added to role:ConnectableElement and /part:Property (as shown in fig. 95), a statement that role is derived, and multiplicities added to all associations (as shown in fig. 95).

Resolution: see ptc/2006-04-01 page 140
Revised Text:
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8129: Section: 12.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under Notation change "name of the part" to rolename to differentiate it from the name of the part (as in composition).

Resolution:
Revised Text: In section 9.3.13, under Notation, change the last paragraph to: �The name of the instance specification may be followed by the name of the role which the instance plays. The rolename may only be present if the instance plays a role.�
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Issue 8130: Section: 12.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig 121 uses the word "make" for the constructor. Unfortunately, this word could be misconstrued to be a noun and refer to the make of the car (Volvo, Audie, Ford) instead of the verb it is intend to be. Suggest changing "make" to "assemble."

Resolution:
Revised Text: In figure 121 in section 9.3.13, change make(brand: String) to createCar(brand: String)
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Issue 8131: Section: 9.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is no explanation in the chapter or the section on StrucutredActivities as to why two StructuredActivities packages are drawn, both <<merge>> in fig. 94. Please clarify somewhere

Resolution:
Revised Text:
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue misses that this section extends Structured Activities ? (see Figure 102).
Disposition: Closed, no change

Issue 8132: Section: 10.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 124 does not show what the Generalizations "Classifier (from Kernel, Dependencies, PowerTypes)" indicates, or the association ownedProperty:Property, or the multiplicity listed for attribute filename:String[0..1]

Resolution: see above
Revised Text: On page 207, section 10.3.1, in the Associations subsection, replace the text �ownedProperty : Property [*]� with �ownedAttribute : Property [*]�. In Figure 124, section 10.2, page 205, replace the attribute text �fileName:String� of the Attribute class to �fileName:String[0..1]�. In Section 10.3.1, page 207, Attributes subsection, change �filename� to �fileName�
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

[21 Apr 2005]
Figure 124 does correctly show the subject Generalization, but the labeling is not exactly
as given in the text on page 207. This is likely due to Rose�s limitation of showing only
one package name for a class, as is done in Figure 124 for Classifier shown as �(from
Dependencies)�. I don�t see an easy way to fix the figure to match the text, so I suggest
no change be made. The text on page 207 is very explicit about which Classifier is meant
� the one on page 50.
The complaint about ownedProperty:Property refers to the absensce of ownedProperty as
an association end name in Figure 124. In fact, the end named �ownedAttribute� should
be changed to �ownedProperty� to match the text.
Section 6.5.2 requires attribute multiplicity to be shown if it is not the default [0..*].
Consequently, the missing [0..1] multiplicity on the �filename:String� attribute of
Artifact should be added to Figure 124. Also, for editorial consistency, the �filename� in
the Attributes subsection on page 207 should be correctly render as �fileName�.
[22 Apr 2005]
Conrad Bock suggests: �Since the name "ownedAttribute" is used in classes as well as
datatypes already, it seems like we should leave it that way in deployments. No need to
incur a backwards incompatibility with 2.0.� Seems like a good suggestion. The Revised
Text section changed to preserve the ownedAttribute name rather than the ownedProperty
name.

Issue 8133: Section: 10.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo in 1st line of Notation. In Semantics, clarify which Appendix to see

Resolution: Both matters raised by this issue represent valid editorial clarifications to the text.
Revised Text: In section 10.3.1, page 208, second paragraph of the Semantics subsection, change the text: �(See the Appendix)� To: �(See Appendix C)�. In section 10.3.1, page 208, first paragraph of the Notation subsection, change the text: �a icon� To: �an icon�.
Actions taken:
January 25, 2005: receive dissue
August 23, 2006: closed issue

Issue 8134: Section: 10.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Kernel generalization is not shown in fig. 126

Resolution: see above
Revised Text: In figure 126 add NamedElement (from Kernel) as an additional superclass of DeployedArtifact.
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Although the Summary doesn�t say so, the issue�s archive indicates that the target pages
are 206 (where Figure 126 is located) and 210 (DeployedArtifact class description). The
text on page 210 says that DeployedArtifact inherits from �NamedElement (from Kernel,
Dependencies)� whereas Figure 126 shows it inheriting from �NamedElement (from
Dependencies)�. The additional increment should be included in the diagram.

Issue 8135: Section: 10.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The Associations for the Nodes Package text do not agree with Fig. 126.

Resolution: see above
Revised Text: On page 211 of ptc/04-10-02 (same as page 197, section 10.3.4, formal/05-07-04), change the text �location : Node [1] The Node which is the target of a Deployment.� To �location : DeployedTarget [1] The DeployedTarget which is the target of a Deployment.�
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Although the Summary doesn�t say so, the issue�s archive indicates that the target pages
are 206 (where Figure 126 is located) and 211 (Deployment class description), giving us
a clue that it is the Association section of the Deployment class that does not agree with
Figure 126. To agree with Figure 126, the type of the location should be DeployedTarget,
not Node. This change implies no semantic restrictions over the previous situation
because Node inherits from DeployedTarget.

Issue 8136: Section: 10.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Generalization, Association, and Constraints in text don't agree with fig. 127

Resolution: see ptc/2006-04-01 page148/149
Revised Text:
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8137: Section: 10.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig 126 does not show all generalizations listed; text for the Association deployment:Deployment[*] does not mention that the association specializes ownedElement as shown in the figure

Resolution: see above
Revised Text: On page 207 of ptc/04-10-02 in the Associations subsection�s description of �manifestation : Manifestation�, replace the sentence: This association is a specialization of the clientDependency association. with: {subsets NamedElement::clientDependency, subsets Element::ownedElement}. On page 216 of ptc/04-10-02 in the Associations subsection�s description of �deployment : Deployment�, replace the the sentence: This association is a specialization of the clientDependency association. with: {subsets NamedElement::clientDependency, subsets Element::ownedElement}.
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

A corresponding change needs to be made for the manifestation association in Figure 124
as well.

Issue 8138: Section: 10.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I don't believe that fig 125 shows the composite association between nodes and ExecutionEnvironment as expressed in Semantics. Typo - add ending guillemets to <<J2EE container.

Resolution:
Revised Text:
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

My reading of the subject section suggests that Node�s nestedNode association is the
�composite association� referred to in the Semantics section. The nestedNode association
is shown in Figure 125. The missing guillemet does appear in formal/05-07-04.
Disposition: Closed, no change

Issue 8139: Section: 10.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Constraints are not shown on fig 126 as other constraints have been shown on other figures. Under Notation, should "instance" be "instance specification?"

Resolution: see above
Revised Text: In Figure 125 on page 205 of ptc/04-10-02, remove the constraint under the CommunicationPath class. In Figure 126 on page 206 of ptc/04-10-02, remove the two constraints under the DeploymentSpecification class. Editor�s note: Should be in figure 127 (not figure 126 as stated above) In the Constraints subsection of CommunicationPath add the following OCL following the text for constraint [1]: self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget)) In the Constraints subsection of DeploymentSpecification add the following OCL following the text for constraint [1]: self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment)) In the Constraints subsection of DeploymentSpecification add the following OCL following the text for constraint [2]: self.deployment->forAll (d | d.location.deployedElements->forAll (de | de.oclIsKindOf(Component)))
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

The convention used in the UML specifications is to NOT include constraints in the
diagrams. The constraints in figures 125 and 127 should be removed and replaced by
OCL constraints.

Issue 8140: Section: 10.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig 124 shows that the Association utilizedElement:PackageableElement also subsets target

Resolution:
Revised Text: On page 220 of ptc/04-10-02 in the Associations subsection�s description of �utilizedElement : PackageableElement�, replace the words �supplier association� with �supplier and target associations� (page 201 of formal/05-07-04).the sentence: This association specializes the supplier association. with: {subsets Dependency::supplier, subsets Dependency::supplier}.
Actions taken:
January 25, 2005: received issue
August 23, 2006: closed issue

Issue 8141: Section: 10.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The specialization of the association nestedNode:Node is not shown in fig. 125

Resolution: There is no nestedClassifier association end that applies to this case.
Revised Text: In figure 125 change the constraint on Node::nestedNode from {redefines nestedClassifier} to {subsets ownedMember} In the Associations subsection of 10.3.11, replace the sentence: The association is a specialization of the ownedMember association from Namespace to NamedElement. with: {subsets Namespace::ownedMember}
Actions taken:
January 26, 2005: received issue
August 23, 2006: closed issue

Issue 8143: Section: 10.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Table 8 Node Reference says Node has keyword options <<device>> and <<execution environment>> but these are not mentioned in the Node section nor are they diagrammed anywhere.

Resolution: see above
Revised Text: Remove the sentence �Has keyword options �device� and �execution environment�.� from the Node row of Table 8, page 224, section 10.4. Remove the sentence �A Device is notated by a Node annotated with the stereotype �device�� from the Notation subsection, page 217, section 10.3.7. Editor�s note: This was changed to the correct phrasing instead of removing the entire sentence. Delete the third paragraph of the Semantics subsection on page 222, section 10.3.11, that begins with the text �Non-normative examples of nodes ��
Actions taken:
January 26, 2005: received issue
August 23, 2006: closed issue

Discussion:

There appears to be substantial confusion in the text regarding whether �device� and
�execution environment� are stereotypes of Node or subtypes of Node. The proposed
changes favor the subtypes of Node interpretation of these items because it results in far
less drastic changes to the text.
The issue references the text �Has keyword options �device� and �execution
environment�.� in the Node row of Table 8 on page 224, section 10.4. Rather than being
stereotypes as the offending text indicates, Device and ExecutionEnvironment are
defined as subtypes of Node in sections 10.3.7 and 10.3.8, respectively.
Note also that the text �A Device is notated by a Node annotated with the stereotype
�device�� in the Notation section on page 217 is inconsistent with the representation of
devices as a subtype of Node and should be removed as well.
In section 10.3.11, page 222, the third paragraph of the Semantics section suggests that
Nodes can be labeled with �application server�, �client workstation�, �mobile device�,
and �embedded device�. To be consistent with the subtypes of Node interpretation, the
former two of these prototypes would be better applied to the Device class and the latter
two, the ExecutionEnvironment class. Rather than moving these examples stereotypes, it
seems better to just remove them.

Issue 8144: Section: 11.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos and rewording requests Basic Concepts para 2 - Change "Behavior" to "Behaviors" Basic Concepts para 3 - Change "Operations" to "Operation calls" Intermediate Concepts para 1 sentence 1 - change "various action primitive actions" to "various primitive actions" Intermediate Concepts para 1 sentence 3 - rewrite to something like: S"pecifically, a single primitive action is defined so that it either carries out a computation or accesses object memory, but never both." Intermediate Concepts para 6 sentence 4 - Add verb in "multiplicity bound ignored" to "multiplicity bound is ignored" Intermediate Concepts para 6 last sentence - replace the pronoun "these" with the appropriate noun - I don't know if "these" refers to the points where the lower multiplicity bound is ignored or the points where the modeler has determined that the lower multiplicity bound is enforced. Intermediate Actions, Read Write Actions (page 230) para 3 sentence 1 - needs rewording: "ranging from" implies a "to" something which is not listed; "implementation-dependent" is a modifiying phrase but I don't know what it is modifying (the following comma may not be needed). My interpretation of the sentence meaning is: "Value specificationc cover various expressions ranging from implementation-dependent constants to complex expressions with possible side-effects."

Resolution:
Revised Text: Typos 1 => ok Typo 2 (i.e. Change "Operations" to "Operation calls")=> nok => it is really operations and not operation calls that are specified in the model. But BTW, in Basic Concepts para 3 sentence 1, one could change �behaviour invocation� to �behaviour invocations� to align with previous �operations calls� and �signal sends�. Typo 3 => ok Typo 4 => why not (but as I am not English native speaker, I am not very the right man to judge that nut it seems to me, a french guy, it is better ;-) Typo 5 => ok Typo 6 => nok => I think that in this case there is no ambiguities, �these� refers to the closes expression, in this the points where the modeler has determined that the lower multiplicity bound is enforced. Typo 7 => ok Revised Text: Section 11.1, p.229, sub section �Basic concepts�: para2, sentence1: change �Behavior" to "Behaviors� Editor�s note: fixed in formal copy edit para3, sentence1: change �behaviour invocation� to �behaviour invocations� Section 11.1, p.229, sub section �Intermediate Concepts�, para1: sentence 1 - change �various action primitive actions� to �various primitive actions�. sentences 2&3 - change �Specifically, primitive actions are defined so that they either carry out a computation or access object memory, and never both.� to �Specifically, a single primitive action is defined so that it either carries out a computation or accesses object memory, but never both.� Editor�s note: I reworded the proposed change slightly for readability Section11.1, p.230, sub section �Intermediate Concepts�, para6, sentence4: change �multiplicity bound ignored� to �multiplicity bound is ignored� Editor�s note: fixed in formal copy edit Section11.1, p230, sub section �Intermediate Actions, Read Write Actions�, para3, sentence 1 � change �Value specifications cover various expressions ranging from implementation-dependent, constants, and complex expressions, even with side-effects.� with �Value specification cover various expressions ranging from implementation-dependent constants to complex expressions with possible side-effects.�
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8145: Section: 11.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add that retureInformation:OutputPin[1..1] is a specialization or subsets output as shown in fig. 152. Add OCL expression for constraint 1 or that the constraint cannot be expressed in OCL. Constraint [3] contains a typo in the 1st line "isUnmrashall" should be "isUnmarshall"

Resolution: Missing OCL is a duplicate of 6452.
Revised Text: In Section 11.3.1, under Associations, insert �{subsets Action::output}� at the beginning of the description of �returnInformation�: {subsets Action::output} Pin where a value is placed containing sufficient information to perform a subsequent reply and return control to the caller. The contents of this value are opaque. It can be passed and copied but it cannot be manipulated by the model. Editor�s note: put constraint at the end to conform to general practice In the first line of Constraint [3], replace �isUnmrashall� with �isUnmarshall�. Editor�s note: was fixed in formal copy edit
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8146: Section: 11.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the specialization (subsets) statement to result:OutputPin[0..*] as shown in fig. 152. Add OCL statements to Constraints. Constraint [2] needs clarification. Last part of sentence is confusing. Typo - Semantics, para 2, sentence 1 - Change "unmarshall" it "isUnmarshall"

Resolution: Missing OCL is a duplicate of 6452.
Revised Text: In Section 11.3.2, under Associations, insert �{subsets Action::output}� at the beginning of the description of �result�: {subsets Action::output} Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity might not be preserved. Editor�s note: inserted at end of description to conform to standard format In Constraint [2], replace There are no output pins if the trigger events are only ChangeEvents, or if they are only CallEvents when this class is AcceptEventAction and not one of its children. with There are no output pins if the trigger events are only ChangeEvents, or if they are only CallEvents when this action is an instance of AcceptEventAction and not an instance one of a descendant of AcceptEventAction (such as AcceptCallAction). In the Semantics subsection, paragraph 2, sentence 1, replace �unmarshall� with �isUnmarshall�.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8147: Section: 11.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank

Resolution: see above
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Actions, Action:
Generalizations, remove �Dependencies�.
Editor�s note: not done since this is an automatic cross reference to a header (cannot
remove part of the header)
Associations:
/input and /output entries, at beginning of text, add
(Specialized from Element:ownedElement)
Editor�s note: adjusted to conform to document conventions
/context entry, change multiplicity to 0..1.

Issue 8148: Section: 11.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association fromAction:Action[1] missing the specialization or subsets statement shown in fig. 159. Add OCL statements to constraints. Fig. 161 shows the association +action between i2:ActionInputPin and s1:ReadSetAction and between i4:ActionInputPin and s2:ReadSetAction but this is not an association defined for ActionInputPin in the text or shown on fig. 159. Either correct +action association to +fromAction or add +action as an association of ActionInputPin. I may be totally incorrect but shouldn't there be some link or association from the classifier bar:Signal?

Resolution: See revised text. The rest is duplicate with 6452.
Revised Text: In Actions, ActionInputPin: Associations, entry for fromAction, before description, add "(Specializes from Element::ownedElement)". Editor�s note: changed �Specializes� to correct �Subsets� Examples, Figure 161: On links between i2:ActionInputPin and s1:ReadSelfAction, and between i4:ActionInputPin and s2:ReadSelfAction, replace "action" with "fromAction". Add one-directional link from :SendSignalAction to bar:Signal labeled �signal� on bar:Signal end. After above edits, the figure should look like this:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8149: Section: 11.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Remove the header Examples as there are none

Resolution:
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

The fact that the value of the insertAtPin must be greater than 0 is a run-time semantic
constraint that cannot be captured in the abstract syntax constraint OCL. The rest is a
duplicate of 8155.
Disposition: Closed, no change

Issue 8150: Section: 11.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Add "The insertion point is ignored when replacing all values." as last sentence in para 2 of Semantics. Remove the header Examples as there are none.

Resolution:
Revised Text: In Actions, AddVariableValueAction, at the end of the 2 nd paragraph under Semantics, add the sentence: The insertion point is ignored when replacing all values.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

The fact that the value of the insertAtPin must be greater than 0 is a run-time semantic
constraint that cannot be captured in the abstract syntax constraint OCL. The header issue
is a duplicate of 8155.

Issue 8151: Section: 11.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL statements as appropriate for Constraints. Typo - Need a couple of line feeds before the header Notation

Resolution: Missing OCL is a duplicate of 6452.
Revised Text: In Actions, BroadcastSignalAction, after the heading �Semantic Variation Point�, replace the line: The determination of the set of broadcast target objects is a semantic variation point.Notation with: The determination of the set of broadcast target objects is a semantic variation point.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8152: Section: 11.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 144 shows a default for isSynchronous:Boolean = true but this is not indicated in the Attributes section. Associations result:OutputPin[0..*] multiplicity does not match fig. 144; change the description to: "An ordered list of output pins..." and add a statement about the specialization or subsets. Add OCL notation to Constraints.

Resolution: Multiplicity is in proper format. Lists are always ordered. OCL is duplicate with 6346.
Revised Text: In Actions, CallAction: Attributes, isSynchronous entry, add � = true� after �Boolean�. Associations, result entry, at beginning of text add �(Specialized from Action:input)�.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8153: Section: 11.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to Constraints. Delete Examples heading as there are none

Resolution: See issues 8155 and 6346 for disposition
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8154: Section: 11.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to Constraints. Typo - place a period at the end of the definition of the operation:Operation[1] association Add a subsets or specialization statement to the association target:InputPin[1] as is shown in fig. 144

Resolution: OCL is duplicate with 6346
Revised Text: In Actions, CallOperationAction, Associations operation entry, add period at end of description. Editor�s note: fixed in formal copy edit target entry, at end of description, add �(subsets Action::input)�.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8155: Section: 11.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none

Resolution: Discussion: Fixed as part of a previous copy-edit pass of the spec. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
January 27, 2005: received issue
October 27, 2008: closed issue

Issue 8156: Section: 11.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8157: Section: 11.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none.

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8158: Section: 11.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In description, change "positive integer" to "unlimitedNumber greater than 0" Delete Examples hearder as there are none

Resolution: Example header is duplicate of 8155.
Revised Text: Actions, CreateLinkAction, Section 11.3.14, change 6 th sentence in first paragraph of description section to: �The insertion point is an integer greater than 0 giving the position to insert the link, or unlimited, to insert at the end.�
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8159: Section: 11.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete the header Examples as there are non

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Issue 8160: Section: 11.3.16 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none

Resolution:
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

The classifier referred to in the constraint is from the user model. The one in Figure 146
is from the UML metamodel.
Disposition: Closed, no change

Issue 8161: Section: 11.3.17 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "positive integer" in the Description section to "unlimitedNatural >0" Delete the header Example as there are none

Resolution:
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

The description sections are intentionally informal. The Semantics section and
constraints in LinkEndDestructionData specify unlimitedNatural. Headers issue is
duplicate with 8155.
Disposition: Closed, no change

Issue 8162: Section: 11.3.18 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I am confused by the request of issue 7179 to replace 'input' by 'target' in both constraints and then seeing 'input' replaced by 'target' only in the OCL notation. Please clarify. I am also confused by constraint [2] since part 11.3.19 InputPin says nothing about the type of inputPin. Delete the header Examples as there are none.

Resolution:
Revised Text:
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

In DestroyObjectAction, the input pin referred to in the first two constraints is retrieved
in OCL using the target association.
Constraint [2] is correct. An input pin is a specialized pin which is a specialized typed
element.
Example header is duplicate of 8155.
Disposition: Closed, no change

Issue 8163: Section: 11.3.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Bold the heading Associations. Delete the heading Examples as there are none. Constraint [2] of 11.3.18 says that input pin has no type but there is no such constraint mentioned for 11.3.19 (which is the section describing inputPin.

Resolution: see above
Revised Text: In Actions, InputPin, Make the �Associations� header boldface.
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

InputPin is a TypedElement and, so, inherits a �type� property. This property is optional.
Constraint [2] of 11.3.18 simply says that the input pin of a DestroyObjectAction has no
type, it does not make a general statement about input pins. The Example header issue is
a duplicate of 8155.

Issue 8164: Section: 11.3.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Superclass generalization is not written on fig. 144. Association argument:InputPin[0..*] multiplicity does not agree with fig. 144. Association argument:InputPin[0..*]in fig. 144 says it is ordered and subsets input. Add statements to the definition of the association. Under Constraints say none.

Resolution: see above
Revised Text: For �Association argument:InputPin[0..*] multiplicity does not agree with fig. 144.� => For me there is no pb. Revised Text: Section 11.3.20, p.234, Fig 144: add �NamedElement� and a generalization between �Action� and �NamedElement�. Editor�s note: This is not necessary as the generalization is shown in figure 11.2 Section 11.3.20, p.274 � Change �argument : InputPin [0..*] Specification of an argument value that appears during execution.� to �argument : InputPin [0..*] Specification of the ordered set of argument values that appears during execution.� Section 11.3.20, p.275 � add �None.� Under the constraint section. Editor�s note: the above change was not entered because it does not conform to the standard format
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

For �Association argument:InputPin[0..*] multiplicity does not agree with fig. 144.� =>
For me there is no pb.

Issue 8165: Section: 11.3.21 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Associated figures 148 & 150 do not diagram an direct association between LinkAction and InputPin. Please clarify, add to figures, or delete the association from the section. Constraint [2] OCL notation has an extra ending ) Semantics need to be rewritten clarifying how LinkAction and inputPin are associated. None of the figures containing the classifier LinkAction show an association with a multiplicity of 1..1. Delete heading Examples as there are none.

Resolution: see above
Revised Text: see ptc/2006-04-01 pages 169/170
Actions taken:
January 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

The relation between LinkAction, LinkEndData, and InputPin is given in constraint [3] in
the first Constraints section, and constraint [1] in the second Constraints section. Added
some text for this in the Semantics section. The constraint link end data input pin
multiplicity is given in constraint [3] of LinkEndData.

Issue 8166: Section: 11.3.22 -- significant revision? (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

If LinkEndCreationData is not an action, should it be in this part? Wouldn't the action be to read data from this element or write data to this element? LinkEndCreationData is found in two packages but the discussion/text only addresses its use from the IntermediateActions with no mention of its use in CompleteActions. If this section is to stay in this part then rewrite introduction, description, associations, constraints and semantics to address its use/application in CompleteActions. OCL notation for Constraint[2] does not say that the UnlimitedNatural must be >0 as is stated in the definition of the association insertAt:InputPin. Too many closing ")" for the number of opening "(" in Constraint [2] OCL notation Delete the Examples header as there are none.

Resolution:
Revised Text:
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

LinkEndCreationData is used relate input pins of CreateLinkAction and
CreateLinkObjectAction with other required information, which is the "data" referred to
in the name (see Figures 150 and 156). It is only used with CreateLinkAction and
CreateLinkObjectAction, so only makes sense in the Actions chapter. The semantics of
LinkEndCreationData already says it is used to specify qualifiers in complete actions.
The fact that insertAt must be greater than zero is a runtime constraint. The constraint
sections in the specificaiton only express modeltime constraints.
Disposition: Closed, no change

Issue 8167: Section: 11.3.23 -- significant revision? (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

I read and understand little difference between LinkEndData and LinkEndCreationData or LinkEndDestructionData. If none of these elements are actions what are they doing in Actions? Wouldn't the action be to read to or write from these elements? Add the package CompleteActions name to the Description and mention that LinkEndData identifies one end of a link to be destroyed. Add "(IntermediateActions)" to the first Constraint header. I'm not certain that constraint (IntermediateActions) [3] multiplicity agrees with the association value:InputPin[0..1] mulitplicity The instruction under semantics to see LinkAction and its children needs to be rewritten. Through following all of the instructions to see different sections, I finally found semantics information in ReadLinkAction, CreateLinkAction, and DestroyLinkAction. Delete header Examples as there are none.

Resolution:
Revised Text:
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

LinkEndData, LinkEndCreationData, and LinkEndDestructionData are used relate input
pins of descendants of LinkAction with other required information, which is the "data"
referred to in the names. The semantics sections specify the general case of
LinkEndData, and what is special about the subtypes LinkEndCreationData, and
LinkEndDestructionData. They are only used the descendants of LinkAction, so only
makes sense in the Actions chapter. LinkEndData is not just for link destruction, which
is covered in LinkEndDestructionData, and DestroyLinkAction. The third constraint of
LinkAction ensures the pins of the actions are the same as those referred to by their link
end data, it doesn�t give a multiplicity. The reference to LinkAction is to because the
actions explain the use of LinkEndData and its decendants. The examples header is
duplicate with 8155.
Disposition: Closed, no change

Issue 8168: Figure 89 on page 158 is incorrect (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way. 

More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7. 

Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes"

Resolution: The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text. Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2. The third aspect of this issue is a duplicate of 12236, already resolved.
Revised Text: Insert the following paragraph before the paragraph above 8.12 that starts with the words "Interfaces that are exposed �": "If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself. If a part has no ports, or complex ports, the notation for connector wiring is as specified in Clause Composite Structures. " Replace Figure 8.12, and its caption, by this: Figure 8.12 - An internal or white-box view of the internal structure of a component that contains other components with simple ports as parts of its internal assembly. Replace the paragraph immediately above 8.16 with this: "A delegation connector is notated as a Connector from the delegating Port to the handling Port or Part. If the delegation is handled by a simple Port, then the connector may optionally be shown connected to the single lollipop or socket as illustrated by figure 8.12." Replace the top part of 8.16 with this: This also resolves issues 9807 and 12241 and some of 8900. Disposition: Resolved OMG Issue No: 8249 Title: Section: 12.3.33 Source: U. S. Geological Survey (Jane Messenger, jmessenger@usgs.gov) Summary: Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two. Resolution: The OCL issue is covered by Issue 6346. The wording in UML 2.2 is already correct ("..even if an interruption occurs�"). However, zigzag should, indeed, be one word. Revised Text: In Section 12.3.33, under Presentation Option, change "zig zag" to "zigzag". Disposition: Resolved
Actions taken:
January 28, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8169: Section: 11.3.24 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

If this is not an action why is it discussed in Actions? Move to appropriate Chapter. Wouldn't the action be more like writing to LinkEndDestroyData? If it stays in this chapter please clarify the introduction and description especially explaining how this is different from LinkEndData. Also need to clarify/explain statement "Qualifer values are used in CompleteActions." I don't see a fit with that statement in this section. Attribute in fig 150 is isRemoveDuplicates:Boolean = false so change either the figure or the attribute name in the text. Add OCL notation to Constraints. Constraint [1] typo in "DestroyLinkActiuon" Constraint [2] needs to emphasize that the type UnlimitedNatural is >0. Delete the header Examples as there are none. Typo in Rationale - "LinkeEndDestructionData"

Resolution: see above
Revised Text: In Actions: Figure 150, LinkEndDestructionData, change isRemoveDuplicates to isDestroyDuplicates. LinkEndCreationData, Description, second paragraph, at end of sentence, insert "to specify links to create". LinkEndDestructionData: Description, second paragraph, at end of sentence, insert "to identify links to destroy". Constraint [1], replace DestroyLinkActiuon with DestroyLinkAction. Editor�s note: fixed in formal copy edit Rationale, replace LinkeEndDestructionData with LinkEndDestructionData.
Actions taken:
January 2, 2000: received issue
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

See discussion in issues 8166 and 8167 for parts of issue not addressed below. OCL is
duplicate with 6346.

Issue 8170: Section: 11.3.25 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the superclass pointer "(from Kernal)" to fig. 143. No operations are indicated in fig 143. Constraint [2] appears to have an operation name missing or misspelled

Resolution: see above
Revised Text: In Actions subsectioon Figure 143, add �(from Kernel)� to MultiplicityElement. Editor�s note: not done � The �from� designations have been removed from the figures entirely since they were not always definitive (they only indicated the topmost name in a hierarchical name) Remove the invalid MultiplicityElement increment defined in the metamodel in package UML::Actions::BasicActions MultiplicityElement, Operations, Operation [2]: after �Boolean�, add a semicolon.
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

By convention, operations are not shown in metamodel diagrams.
The reason why there is no �from Kernel� label in MultiplicityElement is because the
metamodel erroneously includes an increment of MultiplicityElement. This increment
should be removed.

Issue 8171: Section: 11.3.26 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The generalization in figure 142 doesn't agree with that mentioned in the section. Attributes are both ordered. Delete header Examples as there are none

Resolution: Example header is duplicate of 8155.
Revised Text: Generalization section of 11.3.26.: Replace �Pin (from BasicActions)� on page <ref> with �Action (from BasicActions)� on page <ref> Attributes section of 11.3.26.: Replace � body : String [1..*] Specifies the action in one or more languages. � language : String [*] Languages the body strings use, in the same order as the body strings with � body : String [1..*] {ordered} Specifies the action in one or more languages. � language : String [0..*] {ordered} Languages the body strings use, in the same order as the body strings
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Issue 8172: Section: 11.3.27 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Description should mention the multiplicity expressed in fig. 143. Delete the header Examples as there are none

Resolution:
Revised Text:
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue does not say which multiplicity.
Rest is duplicate of 8155.
Disposition: Closed, no change

Issue 8173: Section: 11.3.28 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - In description delete provide and change accept to accepts. Add OCL notation to Constraints. Delete header Examples as there are none.

Resolution: OCL issue is a duplicate of 6452. Header issue is a duplicate of 8155.
Revised Text: In Actions, Pin, under Description, change A pin is a typed element and multiplicity element that provides provide values to actions and accept result values from them. to A pin is a typed element and multiplicity element that provides values to actions and accepts result values from them.
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Issue 8174: Section: 11.3.29 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Please clarify the relationship and differences between QualifierValue, LinkEndCreationData, LinkEndData, and LinkEndDestructionData especially since QualifierValue, LinkEndData, and LinkEndCreationData are all in the CompleteActions package. Constraint [2] change "are" to "is" Delete Examples header as there are none.

Resolution: see above
Revised Text: In Actions, QualifierValue, Constraint [2], replace "are" with "is". Editor�s note: fixed in formal copy edit
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

See discussion in 8166, 8167, and 8169. QualifierValue in particular specifically says
link end data and related elements are for identifying links, and what they identify.

Issue 8175: Section: 11.3.30 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association exception:InputPin[1..1] is subsetted according to fig 158. Delete Examples heading as there are none

Resolution: Headers issue is duplicate with 8155.
Revised Text: In Actions, RaiseExceptionAction, Associations, exception entry, at end of description, add �(subsets Action:input)�.
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Issue 8176: Section: 11.3.31 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig 153 shows that the association result:OutputPin[1..1] is subsetted. Add OCL notation for constraint [1]. I believe the wording of constraint [1] might be better as: "The type of the result output pin is the type of the classifier."

Resolution: see above
Revised Text: In Actions, ReadExtentAction, Associations, result entry, at end of description add �(subsets Action:output)�.
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

OCL is duplicate with 6346. The wording is correct as is. The type is exactly the
classifier, rather than the type of the classifier (which would be a powertype, or a
metametaclass).

Issue 8177: Section: 11.3.33 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none

Resolution: See issue N/A for disposition
Revised Text:
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Issue 8178: Section: 11.3.34 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association result:OutputPin[1..1] is Specialized from Action:output according to fig. 155. Rewrite Constraint [4] as "The type of the object input pin is the type of the association class that owns the association end." Complete the Semantics section. Delete the header Examples as there are none

Resolution: see above
Revised Text: In Actions, ReadLinkObjectEndAction, under Associations, in the bullet for �object�, replace (Specialized from Action:input) with {subsets Action::input} and, in the description for �result�, insert �{subsets Action::output}� at the beginning: {subsets Action::output} Pin where the result value is placed. Under Semantics, add The value of the specified end of the input link object is place on the output pin of the action. Note that this is not the same as reading links of the link object�s association with the specified end as the open end. Identifying a link object explicitly identifies a single specific link, independently of the values of link ends other than the one specified to be read. Even if the multiplicity of the specified end is different from 1..1 in the association, it only has a single value from the point of view of a specific link object. This is why the output pin of a ReadLinkObjectAction always has a multiplicity of 1..1.
Actions taken:
January 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

Constraint [4] is correct as written. The association class is a type, the type of the link
object being read. (Note that the constraint refers to the association class of the link
object, not the Association metaclass.)
The Example header issue is a duplicate of 8155.

Issue 8180: Section: 11.3.35 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none.

Resolution: See issue 8155 for disposition
Revised Text: In Actions, ReadLinkObjectEndQualifierAction, Attributes, entry for result, description, at beginning add "(Specialized from Action:output)".
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8181: Section: 11.3.36 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraint [2]. Delete Examples header as there are none

Resolution: See issue 6452, 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8182: Section: 11.3.27 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete the Examples header as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8183: Section: 11.3.38 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete the Examples header as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8185: Section: 11.3.40 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - removeAt:InputPin [0..1] Unlimitednatural needs correcting. Add specialization to association removeAt:InputPin [0..1] as shown in fig. 147. Constraint [1] needs OCL notation. Add that the Unlimited Natural number must be >0 to the constraint definition. Delete Examples header as there are none. Last statement in the Changes from previous UML is not supported by fig. 147. There is no other mention of RemoveAttributeValusAction in this version of the Superstructure

Resolution: Example header is duplicate of 8155. OCL is duplicate of 6346.
Revised Text: Associations section of 11.3.40.: Replace � removeAt : InputPin [0..1] Specifies the position of an existing value to remove in ordered nonunique structural features. The type of the pin is Unlimitednatural, but the value cannot be zero or unlimited. with � removeAt : InputPin [0..1] {subsets Action::input} Specifies the position of an existing value to remove in ordered nonunique structural features. The type of the pin is UnlimitedNatural, but the value cannot be zero or unlimited. (Note: �N� in UnlimitedNatural is uppercase; added {subsets Action::input}) Remove last sentence in Changes from previous UML, Section 11.3.40.
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8186: Section: 11.3.41 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association removeAt:InputPin[0..1] is subsets input from Actions according to fig. 157. Correct typo in Constraint [1] "removaeAt". Add OCL notation for the constraint. Constraint also needs to mention that the Unlimited Natural must be >0. Typo - Last line of para 1 of semantics - change "support" to "supports" Delete header Examples as there are none

Resolution: see above
Revised Text: In Section 11.3.41, under Associations, insert �{subsets Action::input}� at the beginning of the description of �removeAt�: {subsets Action::input} Specifies the position of an existing value to remove in ordered nonunique variables. The type of the pin is UnlimitedNatural, but the value cannot be zero or unlimited. Editor�s note: constraint added at the end to conform to general format rules for constraints In line 1 of Constraint [1], replace �removaeAt� with �removeAt�. Editor�s note: fixed in formal copy edit In the last sentence of the first paragraph under Semantics, change �support� to �supports�. Editor�s note: fixed in formal copy edit
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Discussion:

OCL issue is a duplicate of 6452. Header issue is a duplicate of 8155.
The fact that the value on the removeAt pin must be greater than zero is a run-time
semantic requirement that cannot be captured in an abstract syntax constraint.

Issue 8187: Section: 11.3.43 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association target:inputPin[1] subsets input from BasicActions according to figure 145

Resolution:
Revised Text: In section 11.3.43, Associations,: Replace: � target: InputPin [1] The target object to which the object is sent. With: � target: InputPin [1] The target object to which the object is sent {subsets Action::/input}
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8188: Section: 11.3.44 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association target:inputPin[1] subsets input from Input according to fig 144. Add OCL notation to the constraints. Semantics [1] change "his" to "the".

Resolution: OCL is duplicate with 6346.
Revised Text: In Actions, SendSignalAction Associations, target entry, at end of description add �(subsets Action:input)�. Semantics, entry [1], first sentence, replace �his� with �this�.
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8189: Section: 11.3.45 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL Notation to Constraints

Resolution: See issue 6452 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8190: Section: 11.3.46 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraint [2]. My guess would be self.object.type=self.classifier.type (That's pure guess since I know very little OCL.) Delete header Examples as there are none

Resolution: See issue 6452, 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8191: Section: 11.3.47 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete header Example as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8192: Section: 11.3.48 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 241 shows the generalization of UnmarshallAction to be Actions (from Basic). Correct either figure or text. Association object:inputPin[1..1] subsets nput from Input and association result:OutputPin[1..1] subsets output from Output according to fig 241. Add OCL notation to constraints

Resolution: OCL is duplicate with 6346.
Revised Text: In Actions, UnmarshallAction Generalization, replace �AcceptEventAction (from CompleteActions)� with �Action (from BasicActions�. Associations object entry, at end of description add �(subsets Action:input)�. result entry, at end of description add �(subsets Action:output)�. Constraints, [4], replace �structural features� with �structural feature�.
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8193: Section: 11.3.49 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraints. Delete Examples header as there are none

Resolution: See issue 6452, 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8194: Section: 11.3.50 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association value:ValueSpecification[1] does not express a specialization in the figure. Please correct either text or figure. Add OCL notation to constraints

Resolution: OCL request is duplicate of 6346.
Revised Text: In section 11.3.50, Associations: Replace: � value : ValueSpecification [1] Value specification to be evaluated. {Specializes Action::output} With: � value : ValueSpecification [1] Value specification to be evaluated.
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8195: Section: 11.3.51 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 9, 2000: received issue
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8196: Section: 11.3.52 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete Examples header as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8197: Section: 11.3.42 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The text does not agree with fig. 152. Correct either the figure or the text. Fig shows that ReplyAction generalizes Actions (from BasicActions), that the association replyToCall is to CallEvent not Trigger, that the association replyValue is to InputPin not OutputPin and that this association subsets input from Actions, that the association returnInformation:InputPin subsets input from Actions. Constraint [1] uses the word "trigger" but figure would indicate that "call event" would be more correct. This constraint needs OCL notation. Semantics really don't agree with figure. [2] needs the word "to" added after meaning and the word trigger is still used when the figure would indicate call even is mor appropriate.

Resolution: OCL is duplicate with 6346. Figure 152 should use Trigger instead of CallEvent.
Revised Text: In Actions Figure 152, replace CallEvent with Trigger. ReplyAction Generalizations subsection, replace �AcceptEventAction (from CompleteActions)� with �Action (from BasicActions)�. Associations subsection replyValue entry, replace �OutputPin� with �InputPin�. At end of description, add �(subsets Action::input)�. ReturnInformation entry, at end of description, add �(subsets Action::input)�.
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8198: Section: 11.3.53 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Put a line feed before Notation header. Delete Examples header as there are none

Resolution: see above
Revised Text: In Actions, WriteStructuralFeatureAction, insert linefeed before Notation header
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Actions, WriteStructuralFeatureAction, insert linefeed before Notation header.
Rest is duplicate of 8155.

Issue 8199: Section: 11.3.54 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete header Examples as there are none

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Issue 8202: Section: 12.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Italicize activity as well as execution in sent 2 of para 1 under Actions and activities. Basic Activities describes basic and structured levels as orthogonal where either can be used without the other or both can be used to support modeling... . Yet StructuredActivities says that this level requires the basic level. Fig. 175 does not support this statement. Please clarify and fix.

Resolution: see above
Revised Text: In Activities, overview section, under heading StructuredActivities: Second sentence, replace "basic" with "fundamental". Third sentence, replace "intermediateand" with "basic, intermediate, and". Editor�s note: Second change fixed in formal copy edit
Actions taken:
January 31, 2005: received issue
August 23, 2006: closed issue

Discussion:

The italics in the first sentence are only for emphasis. They are not applicable to the
second.

Issue 8203: Property string {bag} is redundant (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Property string {bag} is redundant. Use property string {nonunique}defined for MultiplicityElement instead

Resolution:
Revised Text: Page 42, 2nd paragraph, second level bullet list: Replace text {bag} with {nonunique}.
Actions taken:
February 1, 2005: received issue
October 27, 2008: closed issue

Discussion:

The property strings {nonunique} and {bag} have the same meaning and representation in the repository

Issue 8204: {redefined <end-name>} should be named {redefines <end-name>} (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

{redefined <end-name>} should be named {redefines <end-name>}

Resolution: Typo in the Superstructure spec; it does not occur in the Infrastructure.
Revised Text: Superstructure (ptc/04-10-02) On page 39, in the explanation of the various types of property strings, change the explanation for the redefines property from: � {redefined <end-name>} to show that the end redefines the one named <end-name>. to: � {redefines <end-name>} to show that the end redefines the one named <end-name>.
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Issue 8206: Section: 12.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Remove duplicate redefines activity statement for association activity between StructuredActivityNode and Activity.

Resolution: See issue 7099 for disposition
Revised Text:
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8207: Section: 12.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to fig. 187 the associations localPrecondition:Constraint[0..*] and localPostcondition:Constraint[0..*] are subsets of ownedElement. In addition, the multiplicity shown in the fig does not agree with the multiplicity of the text for either association. Para 1, pg 338, sentence 3 appears to have an extra word - tokens - before control tokens. If this isn't extra, then rewrite sentence to make it more clear. The Rationale is a very good description of what an Action is and I suggest placing that paragraph in the Description section. The paragraph for the rationale is not really a rationale or justification--it is a description.

Resolution:
Revised Text: In section 12.3.2: Move all the content from the Rationale subsection to the beginning of the Description subsection and remove the Rationale subsection. Replace: � localPrecondition : Constraint [0..*] Constraint that must be satisfied when execution is started. � localPostcondition : Constraint [0..*] Constraint that must be satisfied when executed is completed. With: � localPrecondition : Constraint [0..*] Constraint that must be satisfied when execution is started. Subsets Element:ownedElement. � localPostcondition : Constraint [0..*] Constraint that must be satisfied when executed is completed. Subsets Element:ownedElement. In the semantics section, the first paragraph on page 338 (just after the steps for executing an action with contarol and data flows): Replace the third sentence: In this case, tokens control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise. With: In this case, control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise.
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Issue 8208: Section: 12.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

None of the multiplicities listed with the associations agree with the multiplicities diagrammed. Please correct either figures (probable) or the text. Associations in the text do not mention any subsets that are illustrated in the associated figures. There is no figure given for Activity in the IntermediateActivity Package but several references to that package (pg 343, 345. Please add a figure for that package for Activity or add Activity to one of the IntermediateActivity figures. Figure 211 is not discussed and appears to give no added value to the section unless figure 210 should contain an action to create a Trouble Ticket.

Resolution: The multiplicities only differ in format.
Revised Text: see ptc/2006-04-01 page192/193
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8209: Section: 12.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraints

Resolution: See issue 6452 for disposition
Revised Text:
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Issue 8210: Section: 12.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add subsets (or specializes) or redefines statements to associations as indicated by the associated figures. Correct either the association multiplicity or the associated diagram multiplicity so that they agree. Italicize ActivityEdge in fig. 196. Add OCL notation to constraints. In Semantics (CompleteActivities) change "Edges" beginning paragraphs 3 and 4 to "ActivityEdges". In notation change stick-arrowhead to open arrowhead

Resolution: see above
Revised Text: see ptc/2006-04-01 pages 194/195
Actions taken:
February 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Multiplicities are correct as written. Missing OCL is a duplicate of 6452. The word
�Edges� at the beginning of the indicated paragraphs is used colloquially, consistent with
usage throughout the semantics section, not as the name of the ActivityEdge metaclass.

Issue 8213: Section: 12.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete the headers Presentation Option and Style Guidelines as there are none. "In Figure 222, two ways to reach an activity final exist;..." the figure number needs to be changed to 223

Resolution: see above
Revised Text: In Activities, ActivityFinalNode, in paragraph above Figure 223, first sentence, replace �Figure 222� with �Figure 223�.
Actions taken:
February 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Activities, ActivityFinalNode, in paragraph above Figure 223, first sentence, replace
�Figure 222� with �Figure 223�. Rest is duplicate with 8155.

Issue 8214: Section: 12.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add IntermediateActivities to the section header list of packages. Typo - remove "that" from the first sentence. Add appropriate subsets information to the associations as shown in the diagrams. Make the text and diagram multiplicities agree for the associations. Add OCL notation to the constraints

Resolution: see above
Revised Text: In Activities, ActivityGroup First sentence, remove �(IntermediateActivities)� and �that�. Associations (FundamentalActivities), activity entry, at end of description, add �(subsets NamedElement::owner)�.
Actions taken:
February 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

ActivityGroup has no new characteristics in IntermediateActivities. The multiplicities
only differ in format. OCL is duplicate with 6346.

Issue 8215: Section: 12.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete the package name "(CompleteStructuredActivities)" after Attributes because ActivityNode is not part of that package according to the figures. Add subsets notations to the associations as shown in the figures. Change the multiplicities of the associations so that the figures and the text agree. Add OCL notation to the constraints

Resolution: see above
Revised Text: In Activities, ActivityNode In header, replace �StructuredActivities� to �CompleteStructuredActivities�. Associations (FundamentalActivities), activity entry, at end of description add "(subsets NamedElement::owner)". Associations (BasicActivities), redefinedElement entry, at end of description add "(redefines RedefinableElement::redefinedElement)" Associations (IntermediateActivities), inPartition entry, at end of description add "(subsets ActivityNode::inGroup)" Associations (StructuredActivities), move entry for inStructuredNode to Associations (CompleteActivities), and at the end of the description add �(subsets ActivityNode::inGroup)�. Associations (CompleteActivities), inInterruptibleRegion entry, at end of description add "(subsets ActivityNode::inGroup)".
Actions taken:
February 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

ActivityNode is part of CompleteStructuredActivities, see Figure 196. The multiplicities
only differ in format. OCL is duplicate with 6346.

Issue 8216: Section: 12.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

If BasicActivities and StructuralActivities are orthogonal, why does the structural level require the basic level? This concept is not supported by fig. 175. Please forgive me if I've already sent this one in, but I hadn't marked my comment as submitted.

Resolution: See issue 8202 for disposition
Revised Text:
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8217: Section: 12.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

Resolution: see above
Revised Text: Section 12.3.9: Change the first sentence in the description from: Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an activity and provide outputs from it. To: Activity parameter nodes are object nodes at the beginning and end of flows that provide a means to accept inputs to an activity and provide outputs from the activity, through the activity parameters.
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is a duplicate of 8219. However, the resolution of 8219 did not correct the
description, as requested.

Issue 8218: Section: 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

Resolution:
Revised Text:
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

The term �edge� is used to mean both kinds. The issue refers to the entire Activities
chapter. If there are specific cases where it should be replaced with one or the other kind
of edge, then issues can be filed on those.
Disposition: Closed, no change

Issue 8219: Section: 12.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

Resolution: see pages 200/201 of prc/2006-04-01
Revised Text:
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8220: Section: 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

Resolution:
Revised Text:
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue refers to the whole chapter 12. In general it is ok to use the term edge if
referring to activity edges in general. I agree that the term �control edge� or �control
flow� should be used if only referring to that kind of edge. Same for object flow. Provide
specific issues for such cases.
Disposition: Closed, no change

Issue 8222: Section: 12.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Associated fig. 184 does not show generalizations from FundamentalActivities for ActivityGroup or from Dependencies for NamedElement. The association activity:Activity[0..1] is not diagrammed in fig. 184. The description for the association represents:Element[0..1] needs rewording. Does it mean "An element constraining the behaviors invoked by the nodes in the partition" (constraining used as a verb) or "The element constraining behaviors that are invoked by the nodes in the partition (constraining used as the noun "constraining behaviors")? Fig. 184 shows additional associations: ContainedEdge:ActivityEdge[1..1] and containedNode:ActivityNode[1..1]. These need to be added to text. Add OCL notation to constraints.

Resolution: see above
Revised Text: In Activities, ActivityPartition, Associations, add entries: containedNode : ActivityNode [0..*] Nodes immediately contained in the partition. Redefined from ActivityGroup::containedNode. containedEdge : ActivityEdge [0..*] Edges immediately contained in the partition. Redefines ActivityGroup::containedEdge.
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Figure 184:
The generalization to ActivityGroup (BasicActivities) is correct because the
figure is in IntermediateActivities, which depends on BasicActivities.
The generalization to NamedElement (Kernel) is correct because
IntermediateActivities depends on Kernel, through BasicActivities and
FundamentalActivities.
The association activity:Activity[0..1] is not diagrammed because it is inherited
without specialization.
In ActivityPartition:
The description for the association represents:Element[0..1] uses �constraining�
as a verb. Neither sentence suggested by the filer seems better, and using
"constraining behaviors" in the particular sentence cited would be ungrammatical.
Rest is duplicate of 6346.

Issue 8223: Section: 12.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Associated fig. 192 spells association name as ownedParameterSet (no "s"), does not show the same multiplicity, and shows that this association subsets ownedMember. Make fig and text agree.

Resolution: Multiplicity in fig. 192 is �*� and in associations section �[0..*]�. Both are the same.
Revised Text: Associations section of 12.3.12.: Replace � ownedParameterSets : ParameterSet[0..*] The ParameterSets owned by this Behavior. with � ownedParameterSet : ParameterSet[0..*] {subsets Namespace::ownedMember} The ParameterSets owned by this Behavior. (Note: no �s� in ownedParameterSet; added subsets) Editor�s note: added constraint at the end of the text to conform to standard format
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8224: Section: 12.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Capitalize the "M" in ownedMember of the subsets not for the BehavioralFeature association ownedParameterSet:ParameterSet

Resolution:
Revised Text: In Activities, Figure 192, on association end named �ownedParameterSet� from BehavioralFeature, change subsets constraint to �subsets ownedMember�.
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8225: Section: 12.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 192 spells the association as ownedParameterSet (no "s"), does not express the same multiplitity as the text, and indicates that the association subsets ownedmember (need to capitalize the "M" in the figure). Make text and figure agree.

Resolution:
Revised Text: In section 12.3.13, subsection Associations, replace: � ownedParameterSets : ParameterSet[0..*] The ParameterSets owned by this BehavioralFeature. With: � ownedParameterSet : ParameterSet[0..*] The ParameterSets owned by this BehavioralFeature. Subsets Namespace::ownedMember. Editor�s note: Above is duplicate of 8223 In figure 192, change {subsets ownedmember} to {subsets ownedMember}.
Actions taken:
February 3, 2005: received sisue
August 23, 2006: closed issue

Issue 8226: MultiplicityElement BNF too restrictive (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of uniqueness-designator without preceding order-designator.
This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super which just shows {unique}.

Resolution:
Revised Text: OMG Issue No: 8226 The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super In the Superstructure document: On page 99 replace the BNF describing in the Presentation Options subsection of MultiplicityElement: <multiplicity> ::= <multiplicity-range> [ �{� <order-designator> [�,� <uniqueness-designator>] �}� ] <multiplicity-range> ::= [ <lower> �..� ] <upper> <lower> ::= <integer> | <value-specification> <upper> ::= �*� | <value-specification> <order-designator> ::= �ordered� | �unordered� <uniqueness-designator> ::= �unique� | �nonunique� with the following: <multiplicity> ::= <multiplicity-range> [ [ �{� <order-designator> [�,� <uniqueness-designator> ] �}� ] | [ �{� <uniqueness-designator> [�,� <order-designator> ] �}� ] ] <multiplicity-range> ::= [ <lower> �..� ] <upper> <lower> ::= <integer> | <value-specification> <upper> ::= �*� | <value-specification> <order-designator> ::= �ordered� | �unordered� <uniqueness-designator> ::= �unique� | �nonunique� In the Infrastructure document: On page 78, replace the BNF describing in the Presentation Options subsection of MultiplicityElement: <multiplicity> ::= <multiplicity-range> <multiplicity-range> ::= [ <lower> �..� ] <upper> <lower> ::= <integer> <upper> ::= �*� | <unlimited_natural> <order-designator> ::= 'ordered' | 'unordered' <uniqueness-designator> ::= 'unique' | 'nonunique' with the following: <multiplicity> ::= <multiplicity-range> [ [ �{� <order-designator> [�,� <uniqueness-designator> ] �}� ] | [ �{� <uniqueness-designator> [�,� <order-designator> ] �}� ] ] <multiplicity-range> ::= [ <lower> �..� ] <upper> <lower> ::= <integer> | <value-specification> <upper> ::= �*� | <value-specification> <order-designator> ::= �ordered� | �unordered� <uniqueness-designator> ::= �unique� | �nonunique� On page 81, replace the BNF describing in the Presentation Options subsection of MultiplicityElement (as specialized): multiplicity ::= <multiplicity_range> [ �{� <order_designator> �}� ] multiplicity_range ::= [ lower �..� ] upper lower ::= integer | value_specification upper ::= unlimited_natural | �*� | value_specification <order_designator> ::= ordered | unordered <uniqueness_designator> ::= unique | nonunique with the following: <multiplicity> ::= <multiplicity-range> [ [ �{� <order-designator> [�,� <uniqueness-designator> ] �}� ] | [ �{� <uniqueness-designator> [�,� <order-designator> ] �}� ] ] <multiplicity-range> ::= [ <lower> �..� ] <upper> <lower> ::= <integer> | <value-specification> <upper> ::= �*� | <value-specification> <order-designator> ::= �ordered� | �unordered� <uniqueness-designator> ::= �unique� | �nonunique�
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8227: Incomplete BNF for Property (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In BNF Notation for Property (11.3.4 of Infra, 7.3.44 of Super), <prop-modifier> is defined but never refered to

Resolution:
Revised Text: Superstructure (ptc/04-10-02) At the bottom of page 129, replace the line: [�{� <prop-property > [�,� <prop-property >]* �}�] with the line: [�{� <prop-modifier > [�,� <prop-modifier >]* �}�] Infrastructure (ptc/04-10-14) At the top of page 131, replace the line: [�{� <prop-property > [�,� <prop-property >]* �}�] with the line: [�{� <prop-modifier > [�,� <prop-modifier >]* �}�]
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8228: BNF Notation for Operation is too restrictive (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In 11.8.2 (Infra) and 7.3.36 (Super) the notation BNF requires a {<oper-property} any time there is a ':' after the operation name

Resolution:
Revised Text: On page 108 of the Superstructure [page 158 of the Infrastructure] spec in the Notation subsection of Operation, replace the BNF: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] �{� <oper-property> [�,� <oper-property>]* �}�] with the following BNF (add an extra pair of brackets): [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] [�{� <oper-property> [�,� <oper-property>]* �}�] ]
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Issue 8229: Used of "Redefines ...from Abstractions" in descriptions is misleading (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

For example 11.7.2 of Infra: the name property states 
Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement.

However there is no redefinition occurring; nor would it make sense.

Resolution: see above
Revised Text: In section 11.7.2 of Infrastructure, change � name: String [0..1] Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement. to: � name: String [0..1] The name of the NamedElement.
Actions taken:
February 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

This descriptions resulted from the old definition of package merge where the merging
package specialized and redefined matching classes and properties from the merged class.
Since this is no longer the case, the description of NamedElement::name should change.

Issue 8231: Section: 12.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

For the Attributes, Associations, and Constraints sub-sections change "None" to "No new." This would be a good policy to follow for all "(as Specialized)" concepts where no new information is presented in the 'as Specialized" concept.

Resolution: Discussion: This was fixed as part of an editorial pass in a previous release. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
February 4, 2005: received issue
October 27, 2008: closed issue

Issue 8232: Section: 12.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "None" to "No new" for sub-sections Attributes, Associations, and Constraints

Resolution: See issue 8670 for disposition
Revised Text:
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Issue 8233: Section: 12.3.16 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Package CompleteActivities is not supported by fig. 182 as a generalization for this concept. Change Figure 293 reference in sub-section Notation to either figure 294 or, more likely, figure 301.

Resolution:
Revised Text: Section 12.3.16, p.378: Change �ObjectNode (from BasicActivities, CompleteActivities)� on page 422� to �ObjectNode (from BasicActivities)� on page 422 Editor�s note: the above is simply a cross reference to a heading � it is not possible to make a separate heading for just the one increment, because of the way that the document is structured. Above change not entered. Section 12.3.16, p.379 in Notation subsection: change �This is useful when it needs to be distinguished from the standalone notation for pins shown on the left of Figure 29 and the top left of Figure 300.� To �This is useful when it needs to be distinguished from the standalone notation for pins, shown at top of Figures 294 and 301.�
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Issue 8234: Section: 12.3.17 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Multiplicity for StructuredActivities associations test:ActivityNode[0..*] and body:ActivityNode[0..*] and for CompleteStructuredActivities association bodyOutput:outputPin[0..*] do not agree with figures 195 and 196 respectively. Remove the second set of parantheses from the sub-section heading Associations ((CompleteStructuredActivities)).

Resolution:
Revised Text: In section 12.3.17, subsection Associations (StructuredActivities) replace: � test : ActivityNode [0..*] A nested activity fragment with a designated output pin that specifies the result of the test. � body : ActivityNode [0..*] A nested activity fragment that is executed if the test evaluates to true and the clause is chosen over any concurrent clauses that also evaluate to true. With: � test : ActivityNode [0..*] A nested activity fragment with a designated output pin that specifies the result of the test. � body : ActivityNode [0..*] A nested activity fragment that is executed if the test evaluates to true and the clause is chosen over any concurrent clauses that also evaluate to true. Editor�s note: The types have to be adjusted with resolution 8740 In the following subsection, replace: Associations ((CompleteStructuredActivities)) � bodyOutput : OutputPin [0..*] A list of output pins within the body fragment whose values are copied to the result pins of the containing conditional node or conditional node after execution of the clause body. With: Associations (CompleteStructuredActivities) � bodyOutput : OutputPin [0..*] A list of output pins within the body fragment whose values are copied to the result pins of the containing conditional node or conditional node after execution of the clause body.
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Issue 8235: Section: 12.3.18 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The generalization from CompleteStructuredActivities is not supported by the figures. Typo - add a space before last sentence in para 2 of sub-section Description. (Before Note that... .) Change wording of definition of attribute isDeterminate:Boolean to "If true, the modeler asserts that at most only one of concurrent tests will succeed and therefore the choice of the clause is deterministic." The multiplicity of the CompleteStructuredActivities association result:OutputPin[0..*] is not what is shown on fig 196. Also change the definition to reflect that the association is ordered and subsets output. Delete sub-section headers Notation, Presentation Option, and Examples are there are none. Suggest changing wording in sent 5 para 4 of sub-section semantics to "If the isDeterminate attribute has a true value, the modeler asserts that at most only one of concurrent test sections will yeild a test value (the predecessor relationship may be used to enforce this assertion)."

Resolution: see above
Revised Text: In Activities, ConditionalNode Description, second paragraph, last sentence, at beginning, add space before �Note that�. Editor�s note: fixed in formal copy edit Attributes (StructuredActivities), entry for isDeterminate, in description, remove �concurrently and therefore the choice of clause is deterministic�. Associations (CompleteActivities), entry for result, at the end of the description add �{subsets Action::output}�.
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Generalization is supported by merge (StructuredActivityNode appears in
CompleteStructuredActivities). Following resolution of 8493, the revised text removes
the word �concurrently� from the description of the entry for isDeterminate. Multiplicity
formats are consistent. Ordering of output is inherited, so is not stated here. Headers
issue is duplicate with 8155. The sentence in Semantics was corrected in 8493.

Issue 8236: Section: 12.3.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 179 does not support generalizations of CompleteActivities, CompleteStructuredActivities, or IntermediateActivities packages. Add OCL notation

Resolution:
Revised Text:
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Those packages are the ones merging ActivityEdge. OCL is duplicate with 6346.
Disposition: Closed, no change

Issue 8237: Section: 12.3.6 & 12.3.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I'm confused. Fig. 178 shows ActivityFinalNode as a child of ControlNode in the BasicActivities sub-package, but in fig. 183 it is a "grandchild" of ControlNode and a child of FinalNod in the IntermediateActivities sub-package. Can a concept be both a child and a grandchild of the same higher-level concept, in this case ControlNode?

Resolution:
Revised Text:
Actions taken:
February 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Yes, a class can have the same grandparent through more than one generalization path.
In this case, it is done because an intermediate class is not in one of the packages, while
its parent and child are.
Disposition: Closed, no change

Issue 8238: Section: 12.3.22 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL Notation to constraints. Typo - remove 2nd "a" from sent3 of para 2 of sub-section Notation. Delete sub-section headers Presentation Option and Style Guidelines as there are none.

Issue 8239: Section: 12.3.24 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change type font to italics on fig. 195. Change association handler:ExceptionHandler [0..1] so that fig. 197 and text agree. Add the subsets ownedElement note as shown in fig 197.

Resolution:
Revised Text: In Activities, Figure 195, make ExecutableNode abstract, including occurrences introduced by the resolution of issue 8740 (ConditionalNode and LoopNode test and bodies should be ExecutableNodes). In section 12.3.24, subsection Associations (ExtraStructuredActivities), replace: � handler : ExceptionHandler [0..*] A set of exception handlers that are examined if an uncaught exception propagates to the outer level of the executable node. With: � handler : ExceptionHandler [0..*] A set of exception handlers that are examined if an uncaught exception propagates to the outer level of the executable node {subsets Element::ownedElement}.
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8240: Section: 12.3.23 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add subsets note to association protectedNode:ExecutableNode[1..1] as shown on fig. 197. Add OCL notation to constraints. Under sub-section Presentation Option change "interrupting edge is a zig-zag adornment..." to "exception handler is a zig-zag adornment..." Delete sub-section heading Rationale as there is none. Typo - Under sub-section Changes from previous UML in para 2 put a space between first and second sentences.

Resolution: OCL is duplicate with 6346. Headers issue is duplicate with 8155.
Revised Text: In Activities, ExceptionHandler Associations, entry for protectedNode, at end of description add �{subsets Element::owner}�. Presentation Option, first sentence, replace �interrupting edge� with �exception handler�. Rationale, second paragraph, after first sentence, add space.
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8241: Section: 12.3.27 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to the constraint. In sub-section Semantics, last sent. of para 1 change "concurrency" to "mode." Typo - In sub-section Presentation Option, put a space after Figure 259. On Page 399, change figure reference number to 261. In fig. 261, chane <<concurrent>> to <<parallel>>.

Resolution: Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.
Revised Text: In Section 12.3.22, under Notation, in the 2 nd paragraph, 3 rd sentence, beginning �This case maps to a model containing a a merge node��, remove the second �a� before �merge node�. Editor�s note: The resolution above seems to be a copy-paste of the resolution to issue 8238. I made the changes indicated in the summary, since those were simple editorial changes.
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8242: Section: 12.3.28 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to the constraint

Resolution: See issue 6425 for disposition
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8243: Section: 12.3.30 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to the constraints

Resolution: See issue 6425 for disposition
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8245: Section: 12.3.38 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

I may be all wet (after all it is a Monday morning and raining here) but I think fig. 265 needs to be redrawn. The notation between the BuildComponent and InstallComponent activites is different than the notation between the InstallComponent and DeliverApplication activities yet the flow is basically the same. To agree with the left side of the flow between BuildComponent and InstallComponent activities, there should be a fork after the InstallComponent activity with an edge going to DeliverApplication activity and an edge going to a decisionNode. The decisionNode should have two edges exiting it. One labeled [more components to be installed] and going back to the InstallComponent activity; a second labeled [no more components to be installed] going to a Flow final node. The edge and the [no more components to be installed] label need to be removed from the edge going from the decisionNode to the DeliverApplication activity. Out of curiosity, why was a fork notation used and not the decisionNode with three control flow edges leading from it?

Resolution:
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

After the Build Component action has completed, the activity can in proceed to install the
component, and check to see if any further components need to be built. If there are no
more components to build, then the forked parallel flow terminates, but the activity
continues with the installation of any previously built components. If there are additional
components to build, they are built with the Build Component action and then sent to be
installed. The reason for a fork here is to allow additional components to be built while
previously built components are installed.
A fork cannot be included after the Install Component action as this would result in the
application being delivered after its first component was installed.
Disposition: Closed, no change

Issue 8247: Section: 12.3.31 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraints. Reword last sentence in last paragraph of sub-section Semantics. The entire sentence is confusing and unclear

Resolution: The missing OCL issue is a duplicate of 6425.
Revised Text: In Section 12.3.31, under Semantics, replace the last sentence: In addition, when an activity starts, control tokens are placed at actions and structured nodes that have no incoming edges, except if they are handler bodies (see �ExceptionHandler (from ExtraStructuredActivities)� on page 390) are fromActions of action input pins, or are contained in structured nodes. with: In addition, when an activity starts, a control token is placed at each action or structured node that has no incoming edges, except if it is a handler body (see �ExceptionHandler (from ExtraStructuredActivities)� on page 390), it is the fromAction of an action input pin (see �ActionInputPin (from StructuredActions)� on page 252), or it is contained in a structured node.
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8248: Section: 12.3.32 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation

Resolution: See issue 6425 for disposition
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8250: Section: 12.3.33 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided.

Resolution:
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

The order cancellation request example could be improved by better analysis, as well as
an indication of the activity involved in Cancel Order. It should be kept in mind that
Cancel Order is a fairly complex activity, involving process-based �compensation.�
Compensation would consist of processes such as requesting return of already-shipped
items, refunding payments, closing the order, and terminating the activity. So, most of the
improvements suggested in this issue would be handled instead within the Cancel Order
activity. Adding the suggested enhancements (or an activity diagram containing the
Cancel Order activity would indeed enhance the Process Order activity. However, in
doing so, it could detract from the clarity of the example�s primary propose: clearly
illustrate an example of using an InteruptableActivityRegion.
Disposition: Closed, no change

Issue 8252: Section: 12.3.34 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the package name IntermediateActivities to the first Associations sub-section. Add the subsets ownedElement statement (as shown in fig 193) to the association joinSpec:ValueSpecification[1..1]. Typo - remove the second a between containing and join in the 4th sent of the Notation sub-section 1st para. Change AcceptOrder behavior to SendInvoice behavior (as shown in fig 277) in the 1st sentence in the Examples sub-section. Add OCL notation to the constraints

Resolution:
Revised Text: Associations section of 12.3.34: Replace header Associations with Associations (IntermediateActivities) Editor�s note: the above change was not entered because it does not conform to the standard format Associations (CompleteActivities) section of 12.3.34: Replace � joinSpec : ValueSpecification [1..1] A specification giving the conditions under which the join will emit a token. Default is �and�. with � joinSpec : ValueSpecification [1..1] {subsets Element::ownedElement} A specification giving the conditions under which the join will emit a token. Default is �and�. Editor�s note: added constraint at the end of the text to conform to standard format Notation section of 12.3.34, 1 st paragraph, 4 th sentence: Replace This case maps to a model containing a a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram. with This case maps to a model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram. (Note: removed �a� between containing and join) Editor�s note: fixed in formal copy edit Examples section of 12.3.34, 1 st paragraph, 1 st sentence: Replace The example at the left of the figure indicates that a Join is used to synchronize the processing of the Ship Order and Accept Order behaviors. with The example at the left of the figure indicates that a Join is used to synchronize the processing of the Ship Order and Send Invoice behaviors. (Note: replaced �Accept Order� by �Send Invoice�) Constraints section of 12.3.34: Add OCL to constraints: [1] A join node has one outgoing edge. self.outgoing->size()=1 [2] If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow. (self.incoming.select( e | e.isTypeOf(ObjectFlow)->notEmpty() implies self.outgoing.isTypeOf(ObjectFlow)) and (self.incoming.select( e | e.isTypeOf(ObjectFlow)->empty() implies self.outgoing.isTypeOf(ControlFlow))
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8253: Section: 12.3.35 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Correct multiplicities of associations so that the figures (195 and 196) agree with text. Add subsets statments to descriptions as shown in fig. 96. Typo - 5th para, 1st sent of Semantic sub-section change "body sections has" to "body section has." Delete sub-sections Notation and Examples as there are none.

Resolution: Multiplicities are in consistent format. Headers issue is duplicate with 8155.
Revised Text: In Activities, LoopNode Assocations (CompleteActivities) Remove extra �(� in header. Editor�s note: note done, different convention used in the formal spec result entry, at end of description, add �{subsets Action::output}�. Editor�s note: note done, handled by 8255 loopVariable entry, at end of description, add �{subsets Element::ownedElement}�. Editor�s note: note done, handled by 8255 Semantics, fifth paragraph, first sentence, replace �body sections� with �body section�. Editor�s note: fixed in formal copy edit
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8254: Section: 12.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add sections for front end node and back end node as mentioned in LoopNode

Resolution:
Revised Text:
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue references p 415, which is the semantics of LoopNode, already describing front
end and back end nodes. This semantics is actually redundant with the semantics of
StructuredActivityNode, but that is a separate issue.
Disposition: Closed, no change

Issue 8255: Section: 12.3.35 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I forgot to mention that "ordered" needs to be added to the following associations: results:OutputPin[0..*], loopVariable:OutputPin[0..*], and loopVariableInput:InputPin[0..*] as shown in fig. 196.

Resolution: Also added subsets statements to results, loopVariable, and loopVariableInput.
Revised Text: Associations (CompleteStructuredActivities) section of 12.3.35: Replace � result : OutputPin [0..*] A list of output pins that constitute the data flow output of the entire loop. � loopVariable : OutputPin [0..*] A list of output pins owned by the loop that hold the values of the loop variables during an execution of the loop. When the test fails, the values are copied to the result pins of the loop. with � result : OutputPin [0..*] {ordered,subsets Action::output} A list of output pins that constitute the data flow output of the entire loop. � loopVariable : OutputPin [0..*] {ordered,subsets Element::ownedElement} A list of output pins owned by the loop that hold the values of the loop variables during an execution of the loop. When the test fails, the values are copied to the result pins of the loop. Editor�s note: added constraint at the end of the text to conform to standard format Replace � loopVariableInput : InputPin[0..*] A list of values that are copied into the loop variable pins before the first iteration of the loop. with � loopVariableInput : InputPin[0..*] {ordered,subsets Action::input} A list of values that are copied into the loop variable pins before the first iteration of the loop. Editor�s note: added constraint at the end of the text to conform to standard format
Actions taken:
February 7, 2005: received issue
August 23, 2006: closed issue

Issue 8256: Profiles:Extension End (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Profiles:Extension End - the spec needs to be clear on the behaviour of the
{required} property of an extension if the extending stereotype in question
has subclasses. Are those sub-stereotypes also required?

Resolution:
Revised Text: IsRequired is a property of "Extension", not "ExtensionEnd". But yes, we can be more specific. Revised Text: In 18.3.2 Extension � Semantics in ptc/04-10-02 and 13.1.2 in ptc/04-11-16: After 1 st paragraph (A required � isRequired is true.) Add If the extending stereotype has subclasses, then at one instance of the stereotype or one of its subclasses is required.
Actions taken:
February 8, 2005: received issue
August 23, 2006: closed issue

Issue 8257: Section: 12.3.37 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraints. In the Semantics (CompleteActivities) sub-section, third para change receiving to multireceiving and is to are. In Examples sub-section, the example describing fig. 286, last line indicates that the selection specifies that a query operatiion that takes an Order evaluates the customer object via the Order.customer:Party association. This is not what is diagrammed in the right side of fig. 286.

Resolution: OCL is duplicate with 6346.
Revised Text: In Activities, ObjectFlow Semantics, last paragraph, first sentence, replace �receiving is� with �multireceiving are�. Examples, paragraph above Figure 286, last sentence, replace �selection, then,� with �transformation�.
Actions taken:
February 8, 2005: received issue
August 23, 2006: closed issue

Issue 8258: Section: 12.3.38 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The multiplicity of association (CompleteActivities) inState:State[0..*] does not agree with fig. 189. Add OCL notation to constraint (BasicActivities) [1]. Add OCL notation to contraints (CompleteActivities. Add "(BasicActivities)" to the 1st Semantics sub-section

Resolution:
Revised Text:
Actions taken:
February 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The multiplicities �*� and �[0..*]� mean the same thing. Since ObjectNode is introduced
in BasicActivities, the header for that is not put in Semantics. The rest is duplicate with
6346.
Disposition: Closed, no change

Issue 8261: Section: 12.3.41 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The attribute effect:ParameterEffectKind[0..1] does not display this multiplicity in fig. 192. Reword the definition of attribute isStream:Boolean[1..1]=false to "Tells whether an input parameter may accept valuses or an output parameter post values while the behavior is executing." parameterSet:ParameterSet[0..*] listed as an attribute is an association. Please move it to the Association sub-section. The multiplicity for parameterSet:ParameterSet[0..*] does not agree with fig. 192. Add OCL notation to the constraints. Under sub-section Notation the last sent. says to "See notation for Operations." but gives no reference location. Is this supposed to be at page 105?

Resolution: see above
Revised Text: Change the multiplicity of parameterSet in fig. 192 from �*� to �0..*�. Editor�s note: the above change was not entered because it does not conform to the standard format and makes no semantic difference since * is equivalent to 0..*
Actions taken:
February 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

It�s not necessary to reword the definition of attribute isStream. The proposed rewording
is just another verbalism and doesn�t introduce any important information.

Issue 8262: Section: 12.3.43 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association condition:Constraint[0..*] does not have the same multiplicity as fig. 192. Also the fig. indicates that the association subsets ownedElement. Add OCL notation to constraints

Resolution:
Revised Text: Section 12.3.43, subsection Associations (CompleteActivities), replace: � condition : Constraint [0..*] Constraint that should be satisfied for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions and conditions on input parameter sets were satisfied. With: � condition : Constraint [0..*] Constraint that should be satisfied for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions and conditions on input parameter sets were satisfied. {subsets Element::ownedElement}.
Actions taken:
February 8, 2005: received issue
August 23, 2006: closed issue

Issue 8263: Section: 12.3.44 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add package name to first Constraint sub-section. Left fig of fig. 295 needs an "s" on end. Shouldn't exception handler edges also be used in figures 296 and 303? If not, please clarify that the execption pin notation takes the place of the notation for the exception handler notation.

Resolution: see above
Revised Text: In Activities, Pin, Notation, Figure 295, on the left, in the text underneath the subfigure, replace �end� with �ends�.
Actions taken:
February 9, 2005: received issue
August 23, 2006: closed issue

Discussion:

The first subsection is taken to be for the lowest package. Exception handlers are a
different construct from exception parameters. See Parameter and ExceptionHandler
classes in Activity chapter.

Issue 8264: UML 2 Super/templates/inexplicable constraint on defaults (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of TemplateParameter states that the parameter cannot own at the same time its parametered element and default element. The ownership of those two elements is mutually exclusive. It is also expressed as an OCL constraint. However, there is no justification offered in the spec for this constraint and one is not obvious. The constraint should be removed.

Resolution: Indeed, cannot see any justification for this. Remove the constraint.
Revised Text: On page 685 of ptc/04-10-02 remove constraint [2] in the Constraints sub-section of section 17.5.4.
Actions taken:
February 10, 2005: received issue
August 23, 2006: closed issue

Issue 8265: UML 2 super/templates/ (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of Classifier and ClassifierTemplateParameter indicates that there may be additional constraint placed on the parameter. Examples and notation also indicate that. However, there is no defined way to express that constraint in the metamodel (at the very least it is not obvious and is very open for interpretation). The metamodel must provide a meta-association from ClassifierTemplateParameter to Classifier to represent the constraining classifier.

Resolution: see pages 232/233 of ptc/2006-04-01
Revised Text:
Actions taken:
February 10, 2005: received issue
August 23, 2006: closed issue

Issue 8270: Section: 12.3.47 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fo the association executableNode:ExecutableNode[*] mention that it redefines containedNode as shown in diagram 195

Resolution: Also added ordered to the property string.
Revised Text: Associations section of 12.3.47: Replace � executableNode : ExecutableNode [*] An ordered set of executable nodes. with � executableNode : ExecutableNode [*] {ordered,redefines StructuredActivityNode::containedNode} An ordered set of executable nodes. Editor�s note: added constraint at the end of the text to conform to standard format
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8271: Section: 12.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Fig. 196 shows no relationship between concepts immediately under Action (StructuredActivityNode and ActivityEdge) and any of the other concepts in the diagram. There are no connecting lines. If this is truly the case, break this single diagram into two or, as I think (after reading section 12.3.47) there should be some relationship shown between the concepts on the right side of the diagram and those on the extreme left, add lines to show the appropriate relationships.

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Only direct generalizations are shown between metaclasses, so none are shown between
Action and ConditionalNode and LoopNode. The other relationships are in
StructuredActivities and are available by the package merge. In general the metamodel
diagrams are grouped by subject matter, including subject matter that might not be
completely interconnected.
Disposition: Closed, no change

Issue 8272: Section: 12.3.48 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

In sub-section Description, structured activity node is noted as possibly having pins in CompleteStructuredActivities but no pins show any relationship to StructuredActivityNode in fig. 196. The association variable:Variable[0..1] is diagrammed (fig. 195) as belonging to the StructuredActivities package which does not agree in multiplicity and which does indicate that ownedMember is subsetted. A third association is also diagrammed in fig. 195. The association activity:Activity[o..1]. The figure also shows that this association redefines Activity. Figure 196 shows an association of containedEdge:ActivityEdge[?..*]. The figure shows multiplicity as * but in too many cases this should be shown as 0..* In addition, fig. 196 indicates that this association redefined contaniedEdge. Add OCL notation to constraints. In 3rd para of sub-section Semantics, last sentence add the verb "are" between tokens and left. Under the sub-section notation change the word enclosed to enclosing and add the appropriate notation symbology as it is not found in the descriptions of the children of StructuredActivityNode (conditionalNode, loopNode, or sequenceNode as shown in fig. 195) or in section 12.4.

Resolution: see above
Revised Text: In Activities, StructuredActivityNode: Description, first paragraph, second sentence, replace "pins in CompleteStructuredActivities" with "pins when merged with CompleteActivities, or on specializations in CompleteStructuredActivities". Associations, entry for variable, at end of entry, add "Subsets Namespace::ownedMember.". Remove heading "Associations (StructuredActivities)". Associations, add entry: activity : Activity [0..1] Activity immediately containing the node. Redefines ActivityGroup::activity and ActivityNode::activity. Add heading "Associations (CompleteStructuredActivities)" with the entry: containedEdge : ActivityEdge [0..*] Edges immediately contained in the structured node (Redefines ActivityGroup::containedEdge). Semantics, third paragraph, last sentence, before "left", add "are". Editor�s note: the above was fixed in the formal copy edit Notation Replace "enclosed" with "enclosing". At end of first sentence, add ", see Figure ##" referring to a new figure inserted at the end of the Notation section: Figure ##: Notation for structured node �structured�
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

In StructuredActivityNode, the entry for association variable:Variable[0..*] has the
correct multiplicity and matches Figure 195.
Multiplicities * and [0..*] are equivalent, per resolution to issue 8258.
ExpansionRegion is a child of StructuredActivityNode and has notation.

Issue 8273: Section: 11.3.48 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Notation, say see fig. 307

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Figure 307 is an example, it uses the generic action notation in Activities, it does not
introduce new notation for UnmarshallAction.
Disposition: Closed, no change

Issue 8275: Section: 12.3.50 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add "See "ValuePin (from BasicAQctions)" on page 309." immediately under concept heading. Change None to No new under the sub-section Associations. Delete the word "these" in the 3rd sentence of sub-section Semantics. Delete sub-section Examples as there are none.

Resolution: Empty section issue is duplicate with 8231. Headers issue is duplicate with 8155.
Revised Text: In Activities, ValuePin After first sentence, add �See ValuePin (from BasicActions).�. Semantics Second sentence, replace �tostart� with �to start�. Editor�s note: fixed in formal copy edit Third sentence, delete �these�.
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Issue 8276: Section: 12.3.51 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-sections Associations and Constraints change none to no new

Resolution: See issue 8232 for disposition
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Issue 8277: Section: 12.3.52 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association activityScope:Activity[0..1] substes owner as indicated in fit. 195. Add OCL notation to Constraints. Type - lower case the second letter in the second sentence of sub-section Additional Operations.

Resolution: OCL is duplicate with 6346. Subsets addressed in issue 9000.
Revised Text: Additional operations, second sentence, replace first word with �Implementations�. Editor�s note: fixed in formal copy edit
Actions taken:

Issue 8279: Section: 12.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - remove the dash from between page and the number when referencing. ActivityNode Notation cell delete ExecutableNode and ControlNode as they just refer the reader elsewhere. ControlNode Notation cell delete FinalNode as it just refers reader elsewhere. Add ActivityNode and FlowNode. ExeceptionHandler Notation cell does not exactly agree with fig. 253. In fig. 253 the small square sits across the HandlerBodyNode instead of abutting it.

Resolution: see above
Revised Text: In Activities ExceptionHandler, Notation, Figure 253, the pin rectangle on the handler body should appear under the hander rectangle, as shown here: ExceptionType Protected Node HandlerBody Node Diagrams section, Remove an unneeded dashes in page references. Editor�s note: fixed in formal copy edit ExceptionType Protected Node HandlerBody Node
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Cells that refer to other cells are helpful to explain notation for abstract classes. There is
already an ActivityNode cell, and the metamodel has no FlowNode.

Issue 8280: Section: 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

General comments. Change the multiplicities on the figures to reflect 0..* instead of only *. Some of the figures show it the 0..* way but most do not. If the text lists associations as [0..*] the associated figures should agree. Add OCL notation where possible and where there is no OCL notation available so note it. Delete sub-section headings where there is nothing under them or state None. For specialized concepts, if there is no new information to impart change the word from none to the phrase no new if there was some information in the original concept description sub-section. Generalizations are often not diagrammed in the appropriate Abstract Syntax package diagrams. For instance, the concept ControlNode generalized ActivityNode (from BasicActivities. Even though ActivityNode (the parent) is found in other packages, ControlNode (the child) is not. Should mention be made that ControlNode generalizes ActivityNode from the StructuredActivities package when ContronNode isn't in this package? If so, explain more fully in the How to Read This Specification Section (6.5) about the direct generalizations of a concept being generalized to all packages to which the parent belongs. Where a generalization is diagrammed not all of the "from" packages are listed as indicated in the concept text. Add all package names to the parent namespace or use ellipses to indicate that the list is longer than the namespace allows.

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Multiplicities are in proper format. Empty section issue is duplicate with 8231. Headers
issue is duplicate with 8155. OCL is duplicate with 6346. The generalization
diagramming and class entries reflects package merge, as explained in updates from FTF,
such as FTF issue 6279.
Disposition: Closed, no change

Issue 8292: Section: 13.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous.

Resolution: see pages 240/241 of ptc/2006-04-01
Revised Text:
Actions taken:
February 16, 2005: received issue
August 23, 2006: closed issue

Issue 8293: Section: 12.3.46 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

For sub-sections Associations and Constraints change the None to No new.

Resolution: See issue 8231 for disposition
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8294: Section: 12.3.49 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Associations and Constraints change None to No new

Resolution: See issue 8232 for disposition
Revised Text:
Actions taken:
February 14, 2005: received issue
August 23, 2006: closed issue

Issue 8295: Section: 13.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters "that can be given" which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available.

Resolution: In the recent version of the specification, the specialization for context:BehavioredClassifier has already been added. The multiplicities mentioned above are all �*� which is equivalent to �0..*�. To correct the remaining mismatch between text and diagram:
Revised Text: In section 13.3.2, subsection �Associations�, add to the end of the text following bullet �redefinedBehavior: Behavior� the following: �(Subsets redefinedElement)� At the end of bullet �precondition: Constraint� replace �(Subsets Namespace::constraint and Constraint::context)� by �(Subsets Namespace::ownedRule)� At the end of bullet �postcondition: Constraint� replace �(Subsets Namespace::constraint and Constraint::context)� by �(Subsets Namespace::ownedRule)�
Actions taken:
February 17, 2005: received issue
October 27, 2008: closed issue

Discussion:

Issue 8297: Section: 13.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Multiplicities for the associations need to be added to the text for raisedException:Classifier[0..*], and changed in the associated diagrams to reflect the correct multiplicity (1 for method:Behavior (according to the text) and not * as shown in fig. 311 and 0..* for fig. 315). Unless "specializes" means the same thing as "redefines" change either the text for raisedException:Classifier from specializes to redefines or change fig 315. from redefines to specializes. Regardless, less confusion would occur if the text and the figure used the same word.

Resolution: see above
Revised Text: To avoid confusion, in Section 13.3.3, add �0..*� for all associations which do not have multiplicities shown. Editor�s note: I extended this fix to all associations in the entire section 13.3, not just 13.3.3
Actions taken:
February 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue text confuses the description of BehavioralFeature.behavior with a
specificaiaton of multiplicity.

Issue 8298: Section: 7.3.36 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

BNF of a operation defines name and type of a parameter as mandatory fields. But both are optional

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) On page 108 in the subsection describing the notation of Operation, replace the sentence: An operation is shown as a text string of the form: with the sentence: If shown in a diagram, an operation is shown as a text string of the form: Infrastructure (ptc/04-10-14) On page 158 in the subsection describing the notation of Operation, replace the sentence: An operation is shown as a text string of the form: with the sentence: If shown in a diagram, an operation is shown as a text string of the form:
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

The Notation for an operation only applies if the operation is actually shown (it is
optional as explained in the section describing the Presentation Options of Classifier on
page 53 of the superstructure. However, we can eliminate potential confusion by adding a
simple explanation.

Issue 8301: Section: 13.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Under sub-section Generalizations change "Class" to "Classifier." Figures use italics for displaying the concept name so you need to mention that BehavioredClassifier is an abstract class. Under sub-section Associations add package name BasicBehaviors before the first two associations. Add the multiplicity which should probably be [0..*] and if this is correct then change fig. 311 to agree with [0..*] or 1 as is currently indicated by the text. If the multiplicity is as indicated in fig. 311 (*), then change the text to agree. For the association ownedTrigger:Trigger[0..*], fig. 316 does not indicate this multiplicity. Make the two agree. Add OCL notation or a note that OCL can not supply notation. The sub-section Semantics describes two BehavioredClassifiers - an immediate event and an input event pool. Possibly consider making these children of BehavioredClassifiers or of Event (fig. 316), i.e. ImmediateEventOccurrence and InputEventPool, instead of just Event. If this is done then two additional concepts would need to be added.

Resolution: see above
Revised Text: Under sub-section Generalizations change "Class" to "Classifier." Under sub-section Associations add package name Basic Behaviors ? before the first two associations. For increased clarity, for associations without multiplicities, add �*� as multiplicity. Change �0..*� to �*�. Editor�s note: the above change was not entered because it does not conform to the standard format Constraints section of 13.3.4: Replace If a behavior is classifier behavior, it does not have a specification. with [1] If a behavior is classifier behavior, it does not have a specification. self.classifierBehavior.notEmpty() implies self.specification.isEmpty()
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

Multiplicity for ownedTrigger is given in Figure 316.
The semantics section does not describe two alternate kinds of Behaviored Classifiers ? ,
but two possible manifestations of the behavior, depending on the Trigger associated.

Issue 8302: Section: 13.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the specializes or subsets comment to the association to agree with fig. 317. Question: If the default value of a Boolean expression is true and its value changes to false would there be a corresponding changeExpression? To me the description and semantics imply that the default value for all Boolean expressions is set at false and this isn't true (e.g., MutliplicityElement attribute isUnique; Port attribute isService). Therefore, what happens when those values change?

Resolution: see above
Revised Text: At the end of the text for changeExpression, add �(Specializes Element::ownedElement.)�
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

As stated, the change event occurs only when the value of a Boolean expression changes
to true. This has nothing to do with what the default value for expressions is.
-- BranSelic - 20 May 2005
Change "." notation to "::" notation.

Issue 8303: Section: 13.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Description change "each of its instance" to "each of its instances." The multiplicity for the association ownedReception:Reception in the text does not agree with fig. 314. If it is [0..*} both text and fig. 314 need changing. Specializes Classifier.feature is not shown in fig. 314 as a specialization of Class but rather as a subset of Interface. Correct either the fig. 314 or text.

Resolution: see above
Revised Text: Under sub-section Description change "each of its instance" to "each of its instances." Editor�s note: fixed in formal copy edit For increased clarify, for associations without multiplicities, add �0..*� as multiplicity.
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

Specialization of feature is shown in Figure 314 as described in text.
-- BranSelic - 20 May 2005
change "*" to "0..*" in revised text.

Issue 8304: Section: 13.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 318 shows an association of specification:DurationInterval[1] that redefines specification. Add this to the text or delete the association from the figure. Delete the "." after "DurationConstaint in Figure 320 caption.

Resolution:
Revised Text: In Association sub-section, add: Specification: DurationInterval [1] The interval constraining the duration. Delete the "." after "DurationConstaint in the caption for Figure 320.
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Issue 8305: Section: 13.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Reword the last sentence under sub-section Semantics. Assuming is not good. State clearly that the ending point in time and the starting point in time would swap. Change "assuming" to "because." Under sub-section Notation, change "Often a Duration is a non-negative integer expression..." to "Often a Duration is an UnlimitedNatural number..." Use of the word "often" implies that the notation could be expresses as a negative integer which, for Duration is an impossibility (at least in our universe

Resolution:
Revised Text: Delete the second paragraph in the Semantics sub-section.
Actions taken:
February 22, 2005: receivd issue
August 23, 2006: closed issue

Issue 8306: Section: 13.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Describe more fully that DurationInterval defines the range between the minimum and maximum duration times allowed. To be consistent with other mutliplicities, show the multiplicities of the associations on fir. 318. Add comment that the associations redefine minimum and maximum as indicated by fig. 318. Sub-section Notation mentions DurationExpression but this concept is not defined. Add this as a concept.

Resolution: In the UML 2.2 specification, the diagram is now Figure 13.13. Multiplicities for min and max are shown on both the diagram and in the text. The redefinitions should be shown in the text. In the Notation section, DurationExpression should be Duration.
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Subclause 13.3.11, in the Associations section, at the end of the description for "min" add "(Redefines Interval::min)". At the end of the description for "max" add "(Redefines Interval::max)". In the Notation section, change "DurationExpression" to "Duration".
Actions taken:
February 22, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8307: Section: 13.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

To be consistent, add the multiplicity for duration:Duration[1] to figure 318. Also, fig. 318 indicates that the association redefines value. Please indicate this in the text. I am not familiar with BFN but should "<urationobservation>" be "<durationObservation>"?

Resolution: see above
Revised Text: In the specification of duration, add �(Specializes ValueSpecification::value.)� Editor�s note: change not inserted; superseded by 8894
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

The first sentence in the issue description is a duplicate.
-- BranSelic - 20 May 2005
the illegible part of the text said:
I am not familiar with BFN but should "" be ""?
(it was accidentally corrupted due to the OMG database software quirk which removes
text between angular brackets). I don't think that this correction is necessary.
also, changed dot notation to double-colon notation

Issue 8308: Section: 13.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation or a note that OCL is unable define a notation for the constraints.

Resolution: see above
Revised Text: In constraints section of 13.3.14: Add OCL to constraints: [1] A function behavior has at least one output parameter. self.ownedParameters->select(p| p.direction=#out or p.direction=#inout or p.direction=#return)->size() >= 1 Editor�s note: incorrect constraint uses old # notation; changed to OCL 2 notation and simplified [2] The types of parameters are all data types, which may not nest anything but other datatypes. def: hasAllDataTypeAttributes(d : DataType) : Boolean = d.ownedAttribute->forAll(a| a.type.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(a.type)) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(p)) Editor�s note: Not entered, because this is ancorrectly written OCL constraint; hasAllDataTypes should be an operation on something like an instance of data type; in OCL, operations are invoked on objects. A proper way to write this would likely be: (self.ownedParameters->notEmpty()) implies (self.ownedParameters->forAll(p| (p.type->notEmpty()) implies (p.type.oclIskKindOf(DatatType) and p.type.hasAllDataTypeAttributes())) Additional Operations The operation hasAllDataTypeAttributes returns true if the transitive closure of all attributes of the the data type are also kinds of DataType DataType::hasAllDataTypeAttributes () : Boolean; result = if (self.ownedAttribute->notEmpty()) then (self.ownedAttribute->forAll (a | a.type->notEmpty() implies a.type.hasAllDataTypeAttributes())) else Boolean::true
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

Regarding the solution below, what about recursive nesting level (e.g., the attributes of
the attributes)?
-- ThomasWeigert - 19 May 2005
Good question. I've changed the OCL slightly and introduced a recursive function. Please
check! I'm not sure what happens if d.ownedAttributes is a empty set? Does it evaluate to
true?
-- Tim Weilkiens - 20 May 2005
Fixed recursive function to work on the type of the ownedAttributes not the attributes
themselves. Fixed first constraint to test the size() of the select result.
-- PeteRivett - 28 Jun 2005

Issue 8309: Section: 13.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association multiplicity in the text does not agree with fig. 314. If multiplicity is [0..*], both text and figure need to be changed

Resolution: see above
Revised Text: For increased clarify, in 13.3.15, for associations without multiplicities, add �0..*� as multiplicity.
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

-- BranSelic - 20 May 2005
changed to 0..* as per guidelines

Issue 8310: Section: 13.3.17 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 318 shows the association specification:Interfal[1] that redefines specification. Add this to sub-section Associations in the concept since the concept is not as specialized

Resolution: This has already been resolved in UML 2.2. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
February 22, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8311: Section: 13.3.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The multiplicity of the attribute language:String[*] in the text does not agree with that shown in fig. 311. Change fig. 311 to agree with the text. Delete the sub-section heading Examples are there none.

Resolution: see above
Revised Text: In Figure 311, change multiplicity for language to �0..*�. IEditor�s note: fixed in formal copy edit n Section 13.3.19, delete sub-section �Examples�. Editor�s note: fixed in formal copy edit
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

-- BranSelic - 20 May 2005
changed to 0..*

Issue 8312: Section: 13.3.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to or a note that OCL can not define the constraints

Resolution: see above
Revised Text: Constraints section of 13.3.20: Change text of constraint [1] as follows and add OCL to constraints: [1] The behavior may only have return result parameters. self.behavior.notEmpty() implies self.behavior.ownedParameters->select(p|p.direction<>#return)- >isEmpty() [2] The behavior must have exactly one return result parameter. self.behavior.notEmpty() implies self.behavior.ownedParameter->select(p|p.direction=#return)->size() = 1
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

Did I understand it right that "The behavior must not have formal parameters." means
that there are no in,out,inout parameters?
-- Tim Weilkiens
What this means is that the Behavior that is at self.behavior must not have any parameter
other than return parameters.
Maybe the English text should be changed (there used to be an association
"formalParameter"). We probably should change the text to say that it should only have
return result parameters.
-- ThomasWeigert - 24 May 2005

Issue 8313: Section: 13.3.22 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to constraint [2] or the note that ICL notation is not definable

Resolution: see above
Revised Text: In Section 13.3.22., subsection "Constraints", delete constraint [2]. In Section 13.3.8., add subsection "Constraints" with the following constraint: [1] A passive class may not own receptions. not self.isActive implies self.ownedReception.isEmpty()
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

I propose to move the constraint to Class (from Communications) with the same text and
the OCL:
not self.isActive implies self.ownedReception.isEmpty()
It isn't easy to navigate from Reception to Class. It's possible to go via
Behavioral Feature ? ::method to Behavior and via Behavior::context to
Behaviored Classifier ? . Then checking if the Behaviored Classifier ? is a Class (downcast)
and evaluating the isActive property. So it's possible to define such a constraint, but it's
not nice. And I think it's the responsibility of Class and not of Reception.
-- TimWeilkiens
This is a good idea.
-- ThomasWeigert - 24 May 2005

Issue 8314: Section: 13.3.23 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Description change wording to the following: "A signal is a specification of a type of send request instances that communicated..." and "The data...are representedas attributes..."

Resolution:
Revised Text: In 13.3.23, change the subsection �Description� to the following: A signal is a specification of send request instances communicated between objects. The receiving object handles the received request instances as specified by its receptions. The data carried by a send request (which was passed to it by the send invocation occurrence that caused that request) are represented as attributes of the signal. A signal is defined independently of the classifiers handling the signal occurrence.
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Issue 8315: Section: 13.3.24 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 317 shows signal:Signal[1] as an association of SignalEvent, not an attribute. Either correct text or figure. Delete the "." leading the first paragraph under the sub-section Notation

Resolution: see above
Revised Text: see ptc/2006-04-01 p 258
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

It should be updated in the text to match the figure. I cannot see any leading �.� Under the
Notation sub-section (probably got confused with a smudge on the submitters screen

Issue 8316: Section: 13.3.26 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add package name SimpleTime to association when:TimeExpression[1]. Fig. 318 shows that this association redefines when. Add the association for the package Communications as shown in fig. 317. This is when:ValueSpecification[1] that subsets ownedElement.

Resolution: Resolved by resolution to issue 8894.
Revised Text:
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Issue 8317: Section: 13.3.27 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Description change "represent" to "represents." Under sub-section Notation, reword "Often a TimeExpression is a non-negative integer" to "Often a TimeExpression is an UnlimitedNatural number." Saying that often a TimeExpression is a non-negative integer implies that it may, at times, be a negative integer

Resolution: see ptc/2006-04-01 p 260
Revised Text:
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Issue 8318: Section: 13.3.28 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

To be consistent with other multiplicities on the figure, add the multiplicities for the associations. Also mention that each association redefines minimum or maximum

Resolution: see ptc/2006-04-01 p 261
Revised Text:
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Issue 8319: Section: 13.3.29 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

To be consistent with other multiplicities in fig. 318, add the association multiplicity to the figure. Mention that the association redefines value as shown in the figure. I am not familiar with BNF notation but should "<timeobservation>" be spelled "<timeObservation>?"

Resolution:
Revised Text:
Actions taken:
February 26, 2000: received issue
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

Most of this issue was resolved in the resolution to 8318. The capitalization of a BNF
entry is a matter of taste � no need to change it.
Disposition: Closed, no change

Issue 8320: Section: 13.3.30 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The generalization "Dependencies" is not listed in fig. 316 under NamedElement. Add this to the figure. The association port:Port[*] is not diagrammed anywhere. Either remove this association from the text or add it to a figure. The sub-section Changes from UML 1.x indicates that the corresponding metaclass was changed from Event but names listed in the BNF definition are all children or grandchildren of the metaclass Event in fig. 317. I believe something needs to change or be clarified but I don't know what.

Resolution: see above
Revised Text: In 13.3.30, subsection �Generalizations�, delete �Dependencies� from the list of generalizations for NamedElement. Editor�s note: This is not possible, since the wording here is automatically generated from the cross-reference. The cross-reference is merely a pointer and not a formal definition. Delete specification of association end "port" from sub-section �Associations�.
Actions taken:
February 22, 2005: received issue
August 23, 2006: closed issue

Discussion:

The port association was moved into the composite structure package. Regarding the
question as to the BNF, this is intended. The trigger references the specified event.

Issue 8322: Section: 13 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

General comments: Add OCL notation to the constraints where possible. If not possible state that OCL notation is not available for the constraint. Either delete sub-section headings where there is no data for the sub-section or add the word "None." Make certain that the multiplicities for the associations agree between the text and the associated figures. There is inconsistency in representation of 0..* on figures, sometimes the figures use * to mean 0..* (according to the text definitions) and then sometimes 0..* is used. Several times the figures will note that an association is a redefinition of or subsets a class but the text does not mention this. Be certain to add the appropriate statement to the text definition.

Resolution: See issue N/A for disposition
Revised Text:
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Issue 8323: Section: 14.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Multiplicity of the association does not agree with fig. 330. Change fig. to agree with text definition

Resolution:
Revised Text: Before (Section 14.3.2 page 507): behavior : Behavior [1] Behavior whose execution is occurring. New Text: behavior : Behavior [0..1] Behavior whose execution is occurring
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Issue 8324: Section: 14.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association operand:InteractionOperand[1..*] subsets ownedElement according to fig. 332. Please add appropriate specializes comment to text. Typo - In the last sentence of sub-section Semantics for Loop change wording from "The loop construct represent..." to "The loop construct represents..."

Resolution:
Revised Text: Before (Section 14.3.3 page 508 (referring to Figure 331, page 504)): operand: InteractionOperand[1..*] The set of operands of the combined fragment. New Text: operand: InteractionOperand[1..*] The set of operands of the combined fragment. Specializes Element::ownedElement. Editor�s note: replaced �specializes� with the correct �subsets� Before (Section 14.3.3 page 512) The loop construct represent a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations. New Text: The loop construct represents a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations. Editor�s note: the above was fixed in the formal copy edit
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Issue 8325: Section: 14.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Attribute sub-section heading needs to be changed to Associations. Fig. 331 shows message:NamedElement[0..*] as an association

Resolution:
Revised Text: Before (Section: 14.3.4, page 515): [Subsection heading �Attributes�] New text: [Subsection heading �Associations�] Editor�s note: also added an empty Attributes subsection
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8326: Section: 14.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 331 does not show package name for the generalization InteractionFragment. Typo - Change paragraph 3 of Notation to "A Continuation that is alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment."

Resolution: see above
Revised Text: Before (Section: 14.3.5, page 516) Continuations that are alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment. Revised Text: A Continuation that is alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment.
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Discussion:

For point a) above, there is nothing special with InteractionFragment. It is defined in
Interactions. No change should be done.
For point b) the suggested correction is correct.

Issue 8327: Section: 14.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

If DescriptionEvent has a constraint that no other OccurrenceSpecification may appear below the OccurrenceSpecification that references the DescructionEvent on a given Lifeline in an InteractionOperand then a similar constraint should be added to the CreationEvent. "No other OccurrenceSpecification may appear above an OccurrenceSpecification which references a CreaationEvent on a given Lifeline in an InteractionOperand."

Resolution: see above
Revised Text: Before (on 14.3.6 on page 518) Constraints No additional constraints. Revised text: Constraints [1] No other OccurrenceSpecification may appear above an OccurrenceSpecification which references a CreationEvent on a given Lifeline in an InteractionOperand.
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Discussion:

It seems reasonable that the Destruction Event and the Creation Event are symmetrical
and that the constraints are also symmetrical. There are, however, difficult to understand
how creation (and destruction) is meant to be modeled in the metamodel. The creation
used to be modeled by a message from the creator to the head of the created, but Creation
Events cannot appear as MessageEnds because it is not a subclass of MessageEvent.

Issue 8328: Section: 14.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Correct Semantics sub-section sentence to "An execution event represents the start or finish of the execution of an action or a behavior."

Resolution:
Revised Text: Before: Section 14.3.8 p. 520 An execution event represents the strart of finish of the execution of an action or a behavior. Revised text: An execution event represents the start or finish of the execution of an action or a behavior. Editor�s note: fixed in formal copy edit
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8329: Section: 14.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Under sub-section Notation, start 3rd paragraph with "For ExecutionSpecification..." In the last sentence of paragraph 3 of Notation write " "(and start and finish associations refer to the very same OccurrenceSpecification)."

Resolution:
Revised Text: Before: Section 14.3.10 p. 522 ExecutionSpecifications that refer to atomic actions such as reading attributes of a Signal (conveyed by the Message), the Action symbol may be associated with the reception OccurrenceSpecification with a line in order to emphasize that the whole Action is associated with only one OccurrenceSpecification (and start and finish associations refer the very same OccurrenceSpecification). Revised Text: For ExecutionSpecifications that refer to atomic actions such as reading attributes of a Signal (conveyed by the Message), the Action symbol may be associated with the reception OccurrenceSpecification with a line in order to emphasize that the whole Action is associated with only one OccurrenceSpecification (and start and finish associations refer to the very same OccurrenceSpecification).
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Issue 8330: Section: 14.3.3 & 14.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The Description for the concept Gate identifies the different roles gates play as formal, actual, and expression. Fig. 332 uses the terms formal and actual in the association names but not expression. I think expression is very descriptive and suggest changing the name of the association from cfragmentGateGate to expressionGate:Gate. This would require changing figure 332 and the text for CombinedFragment.

Resolution:
Revised Text:
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Discussion:

I agree with the comment of the issue. In early versions of the metamodel during the
submission period, the association had the name �expressionGate�, but it was deliberately
changed at some point. We find that this decision should not be reversed only for minor
explanatory reasons.
Disposition: Closed, no change

Issue 8331: Section: 14.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change wording of definitions for associations to: "The OccurrenceSpecification referenced that comes before the OccurrenceSpecification referenced by after" and "The OccurrenceSpecification referenced that comes after the OccurrenceSpecification referenced by before"

Resolution:
Revised Text: Change every instance of �referred� to �referenced� in the Associations section of 14.3.12.
Actions taken:
February 23, 2005: received issue
August 23, 2006: closed issue

Issue 8336: RemoveStructuralFeatureValueAction specification (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

According to the RemoveStructuralFeatureValueAction specification we always have to specify the value to remove. It is not possible to remove an element from a multi-valued structural feature just by specifying its number in the set and without specifying its value. It would be interesting to have this option.

Resolution: This is resolved by the resolution to Issue 9870. Disposition: Duplicate
Revised Text:
Actions taken:
February 24, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8337: Section: 14.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Both associations are shown in fig. 331 as "subsets ownedElement" so please add this specialization to the definition text or remove notes from the figure.

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

Having checked other places where the subset constraint has been used, there does not
seem to be any rule that this information should be repeated in the text. Rather I find the
opposite that it is not mentioned.
Disposition: Closed, no change

Issue 8338: Section: 14.3.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Separate the associations into appropriate packages which are identified. Multiplicity of association lifeline:LifeLine[0..*] is not diagrammed as 0..*. The association is diagrammed as subsets ownedMember. The association event:MessageEnd is not diagrammed anywhere. If such an association exists, it should probably be diagrammed in fig. 329. Association message:Message[*] subsets ownedMember in fig. 329. Association action:Action[*] subsets ownedElement in fig. 330. Typos - 2nd paragraph, pg 527, 2nd sent. should be "Similarly the deteailed actions...are often omited in Interactions,..." Delete the word "are" from 1st sent. of 3rd para under Notation

Resolution:
Revised Text: Revised Text: Here are the changes to be made: 1. Change the text to correspond to Figure 328, i.e. change multiplicity to lifeline:Lifeline[*] Editor�s note: not done; [0..*] is equivalent to [*] and both are used in the document. 2. Remove the association event:MessageEnd from the text (This was introduced during the FTF, but should not be there. 3. The subsets are in general not in the text and should be put in through a global action for putting such subsets in. Editor�s note: there is no such global issue; one should be raised. 4. Correct the �is� -> �are� mistake on page 527 as pointed out above.
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Issue 8339: Section: 14.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Separate the associations into packages. Add the specialization for subsets namespace to enclosingOperand:InteractionOperand[0..1] and subets ownedElement for enclosingInteraction:Interaction[0..1] as shown in the appropriate figures.

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

It is not clear what is meant by separating the associations into packages. Adding
specializations to the descriptions of the associations is not commonplace.
Disposition: Closed, no change

Issue 8340: Section: 14.3.16 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - 2nd sent. under sub-section Description change represent to represents. Add specialization notes to definitions for associations. Association fragment:InteractionFragment subsets ownedMember according to fig. 331 and is ordered. Typo - End the 2nd paragraph under sub-section Semantics with a period. Association guard:InteractionConstraint subsets ownedElement.

Resolution: see above
Revised Text: Before (14.3.16 page 530) An InteractionOperand represent one operand of the expression given by the enclosing CombinedFragment. Revised Text: An InteractionOperand represents one operand of the expression given by the enclosing CombinedFragment. Before (14.316 page 531) The seq operator is described in �CombinedFragment (from Fragments)� on page 507 Revised text: The seq operator is described in �CombinedFragment (from Fragments)� on page 507. [the difference is only the final punctuation mark!]
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

The specializations of associations are not normally mentioned in the text. Closed, no
change for them.
The typos were resolved.

Issue 8341: Section: 14.3.17 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change the name of this enumeration to InteractionOperatorKind and add "break" to the list of Literals in the text

Resolution: see above
Revised Text: Substitute: InteractionOperator by InteractionOperatorKind including in Figure 331. This should only be done with the class name, and should not affect attribute names. Before (14.3.17 page 531) Literals � alt, opt, par, loop, critical, neg, assert, strict, seq, ignore, consider Revised text: InteractionOperatorKind is an enumeration of the following literal values: � alt, opt, break, par, loop, critical, neg, assert, strict, seq, ignore, consider Editor�s note: not done, the problem above was already dealt with in the FTF copy edit. Before (14.3.17 page 532) The value of the InteractionOperand is given as text in a small compartment in the upper left corner of the CombinedFragment frame. Revised text: The value of the InteractionOperatorKind is given as text in a small compartment in the upper left corner of the CombinedFragment frame. [Notice that the last correction assumes that the name substitution has taken place first] Editor�s note: also added a corresponding change to item �operatorKind� in section 14.3.3 (Combinedfragment)
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

For the sake of uniform terminology the name change should be carried out. The last typo
correction in the resolution was found when considering this issue, but not really
mentioned by it.

Issue 8343: Section: 14.3.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change class name for the association selector to OpaqueExpression (as per fig. 328) or change class name on fig. 328. Interaction:Interaction[1] subsets namespace according to the fig. Mention the specialization in the text definition. Typo - First sent. of Semantics change "OccurrenceSpecification" to "OccurrenceSpecifications."

Resolution: see above
Revised Text: Before (14.3.19 page 536) � selector : Expression[0..1] If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set Revised text: � selector : ValueSpecification[0..1] If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set Before (14.3.19 page 537) The order of OccurrenceSpecifications along a Lifeline is significant denoting the order in which these OccurrenceSpecification will occur. Revised text: The order of OccurrenceSpecifications along a Lifeline is significant denoting the order in which these OccurrenceSpecifications will occur. [Only an �s� is added to the revised text to make the last OccurrenceSpecifications into plural.] Editor�s note: fixed in formal copy edit
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

The modeling of expressions and valuespecifications has changed since the typing of the
�selector� attribute. I believe the correct typing now should be ValueSpecification
because the selector in general refers to something that will yield a value at runtime.

Issue 8345: Section: 14.3.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to fig. 329 the association interaction:Interaction[1] subsets namespace and the association argument:ValueSpecification[*] is ordered and subsets ownedElement. Correct text to reflect fig. Constraint [3] change the last word from "Parameter" to "Argument." In sub-section Semantics, para. 4, delete the dash (-). Typo - First para., pg 540, put a space between "as" and "well" In sub-section Notation, begin a new paragraph with the second sent. of the current 3rd paragraph

Resolution: see above
Revised Text: Before (14.3.20 page 540) aswell Revised text as well Editor�s note: fixed in formal copy edit Before (14.3.20 page 539) A Message reflects either an Operation call and start of execution - or a sending and reception of a Signal. Revised text: A Message reflects either an Operation call and start of execution or a sending and reception of a Signal. Before (14.3.20 page 540) Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line. Revised text: Synchronous Messages typically represent operation calls and are shown with a filled arrow head. The reply message from an operation has a dashed line.
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

Resolved the typos. The extra information for the associations has not been customary to
include in the Interactions chapter.

Issue 8346: Section: 14.3.21 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Since the description say that a MessageEnd represents what can and not what must occur at the end of a message and fig. 329 shows the multiplicity of the association to be 0..1, change the multiplicity of messate:Message from [1] to [0..1].

Resolution: see above
Revised Text: Before (14.3.21 page 541): � message : Message [1] References a Message. Revised text: � message : Message [0..1] References a Message.
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

It is hard to think how one could legally have a dangling MessageEnd. The only
reasonable scenario that I can find is that it should be legal to have diagrams with gates
that are not yet attached. Semantically it does not make much sense, though. Still there is
now a discrepancy between the metamodel and the text and in this case the text should be
changed.

Issue 8347: Section: 14.3.21 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In sub-section Description, change enumerator name from MessageSort to MessageKind

Resolution: Notice that the Issue refers the wrong section. The correct section number is 14.3.22.
Revised Text: Before (14.3.22 page 542) MessageSort is an enumeration of the following values: � complete = sendEvent and receiveEvent are present Revised text: MessageKind is an enumeration of the following values: � complete = sendEvent and receiveEvent are present
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Issue 8348: Section: 14.3.24 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change the name of the enumeration list to MessageSortKind on fig. 329, as the section heading, and in sub-section Description

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

This issue is probably a call for more uniform terminology by always ending
enumerations in �-kind�, but I find this unnecessary.
Disposition: Closed, no change

Issue 8349: Section: 14.3.25 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept

Resolution: see above
Revised Text: all page numbers are from ptc/04-10-02 Page 455 figure 307 Change class name to OccurrenceSpecification Page 456 figure 308 Change class name to OccurrenceSpecification Editor�s note: The previous two changes were not made since the diagrams in question are informal diagrams that are not intended to correspond to actual metaclasses. In fact, keeping the name distinct is useful so that the informal diagrams are not confused with the actual metamodel diagrams. On the other hand, there were several additional references to EventOccurrence that were not part of this resolution that were added to the changes stemming from this resolution. Some of those were identified in the resolution to issue 8824, but were fixed under this issue number Page 476 Examples See example in Figure 320 where the TimeConstraint is associated with the duration of a Message and the duration between two OccurrenceSpecification. Editor�s note: the above change superseded by resolution 8894 UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 268 Page 489 Notation A TimeConstraint is shown as graphical association between a TimeInterval and the construct that it constrains. Typically this graphical association is a small line, e.g., between an OccurrenceSpecification and a TimeInterval. Editor�s note: the above change superseded by resolution 8894 Page 497 In this chapter we use the term trace to mean �sequence of event occurrences� which corresponds well with common use in the area of trace-semantics which is a preferred way to describe the semantics of Interactions. We may denote this by <eventoccurrence1, eventoccurrence2, ...,eventoccurrence-n>. We are aware that other parts of the UML language definition the term �trace� is used also for other purposes. Note � I think we can leave these instances as is. � Page 509 Parallel The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The OccurrenceSpecification of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved. A parallel merge defines a set of traces that describes all the ways that OccurrenceSpecification of the operands may be interleaved without obstructing the order of the OccurrenceSpecifications within the operand. � Weak sequencing is defined by the set of traces with these properties: 1. The ordering of OccurrrenceSpecifications within each of the operands are maintained in the result 3. OccurrenceSpecifications on the same lifeline from different operands are ordered such that an OccurrenceSpecification of the first operand comes before that of the second operand. � Page 510 The interactionOperator strict designates that the CombinedFragment represents a strict sequencing between the behaviors of the operands. The semantics of strict sequencing defines a strict ordering of the operands on the first level within the CombinedFragment UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 269 with interactionOperator strict. Therefore OccurrrenceSpecifications within contained CombinedFragment will not directly be compared with other OccurrrenceSpecifications of the enclosing CombinedFragment. � Page 528 The example in Figure 340 shows three messages communicated between two (anonymous) lifelines of types User and ACSystem. The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the opposite order of the sending OccurrenceSpecification. � Page 531 In Sequence Diagrams these InteractionFragments are ordered according to their geometrical position vertically. The geometrical position of the InteractionFragment is given by the topmost vertical coordinate of its contained OccurrenceSpecifications or symbols. [1] The guard must be placed directly prior to (above) the OccurrenceSpecification that will become the first OccurrenceSpecification within this InteractionOperand � Page 531, table 14 Change diagram name in the Frame row to OccurrenceSpecification Editor�s note: should be page 552. However, since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. � Page 557 Change two diagram call-outs to OccurrenceSpecification Change 3 class names to OccurrenceSpecification � Page 561 table 16 Change diagram name in the Frame row to OccurrenceSpecification Editor�s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. � Page 564 table 18 Change diagram name in the Frame row to OccurrenceSpecification Editor�s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 270 � Page 566 table 19 Change diagram name in the Frame row to OccurrenceSpecification � Page 776 Editor�s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. Delete EventOccurrence from index Disposition: Resolved
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

EventOccurrence does not appear in the MDL file. Change all instances of
EventOccurrence to OccurrenceSpecification. This appears to be related to Issues #6980
and 6682.

Issue 8350: Section: 14.3.26 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Place a period "." at the ent of i) and iii); In first line of Style guidelines sub-section, change "are" to "is."

Resolution:
Revised Text: Before (14.3.26 page 546) i) CombinedFragment covering L are matched with an extra-global CombinedFragment in D ii) An InteractionUse covering L are matched with a global (i.e. covering all Lifelines) InteractionUse in D. iii) A plain OccurrenceSpecification on L is considered an actualGate that must be matched by a formalGate of D Revised text: i) CombinedFragment covering L are matched with an extra-global CombinedFragment in D. ii) An InteractionUse covering L are matched with a global (i.e. covering all Lifelines) InteractionUse in D. iii) A plain OccurrenceSpecification on L is considered an actualGate that must be matched by a formalGate of D. [only two punctuation marks have been added � in the end of i) and iii) ] Editor�s note: fixed in formal copy edit Before (14.3.26 page 546) Style Guidelines The name of an Interaction that are involved in decomposition would benefit from including in the name, the name of the type of the Part being decomposed and the name of the Interaction originating the decomposition. Revised text: Style Guidelines The name of an Interaction that is involved in decomposition would benefit from including in the name, the name of the type of the Part being decomposed and the name of the Interaction originating the decomposition. Editor�s note: fixed in formal copy edit
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Issue 8351: Section: 14.3.29 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association invariant:Constraint[1] subsets ownedElement and association covered:Lifekube[1] redefines (not subsets/specializes) covered according to fig. 328. Typos - Last sentence of sub-section Semantics, change has to have and is to are.

Resolution: see above
Revised Text: Before (14.3.29 page 550) In other words all traces that has a StateInvariant with a false Constraint is considered invalid. Revised text: In other words all traces that have a StateInvariant with a false Constraint are considered invalid. Editor�s note: fixed in formal copy edit
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Discussion:

Subsetting is normally not mentioned in the association text in Interactions. The typos are
corrected below.

Issue 8352: Section: 14.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Be consistent in the use of the period (.) ending the statement in the reference column of the tables. Place a period at the end of the sentence under sub-section Graphic Paths, pages 554 and 561. First line, page 556 shange shows to show.

Resolution:
Revised Text: (14.4 pages 551++) Make sure that the explanation texts in each cell in the rightmost column of the tables end in a period. Editor�s note: fixed in formal copy edit Before (14.4 page 556) The sequence diagrams shown in Figure 346 shows a scenario where r sends m1 to s[k] Revised text: The sequence diagrams shown in Figure 346 show a scenario where r sends m1 to s[k]
Actions taken:
February 24, 2005: received issue
August 23, 2006: closed issue

Issue 8356: Section: 11.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The specification says: "If isReplaceAll is false and the structural feature is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the structural feature is unordered and UNIQUE, then adding an existing value has no effect."

Resolution:
Revised Text: In section 11.3.5, Semantics: Replace: If isReplaceAll is false and the structural feature is unordered and nonunique, then adding an existing value has no effect. with: If isReplaceAll is false and the structural feature is unordered and unique, then adding an existing value has no effect.
Actions taken:
February 25, 2005: received issue
August 23, 2006: closed issue

Issue 8357: Section: 12.3.4 (uml2-rtf)

Click here for this issue's archive.
Source: CEA (Dr. Gerard Sebastien, Sebastien.GERARD(at)cea.fr)
Nature: Revision
Severity: Minor
Summary:

p 346, keyword �singleExecution� is used for activities that execute as a single shared execution. p 347, keyword �singleCopy� is used in figure is used to specify single execution. Anyway use an uppercase for the first letter of the keyword, as done for Precondition and Postcondition.

Resolution: Pre and postconditions use lowercase first letter like all keywords, see Figure 207.
Revised Text: In Activities, Activity, Example, Figure 209, replace �singleCopy� with �singleExecution�. Editor�s note: fixed by 8502
Actions taken:
February 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8385: UML 2 Super / Components / realizingClassifier (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

InterfaceRealization is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that InterfaceRealization must have a "realizingClassifier", even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that InterfaceRealization has its own association end that serves a similar purpose called "implementingClassifier". But, this only makes sense for the case when the target of the realization is an Interface and not a Component. 

InterfaceRealization should not be forced to have a "realizingClassifier" attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., ComponentRealization) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1.

Resolution: This has already been resolved in 2.2. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
April 26, 2010: closed issue

Discussion:

Issue 8386: Section: 8.3.4 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head.

Resolution: This is a duplicate of part of 10651. Revised Text: None. Disposition: Duplicate.
Revised Text:
Actions taken:
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8387: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation).

Resolution: Discussion: This line is optional. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
February 27, 2005: received issue
October 27, 2008: closed issue

Discussion:

Issue 8401: Section: 15.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Typo - Delete the word "of" from the first sent. of sub-section Descriptions. Delete sub-section Attributes or state "None" instead of "No additional attributes." The multiplicities for the associations entry:Pseudostate[1..*] and exit:Pseudostate[1..*] don't agree with figure 354. Change the word "refreshens" to "references" in association definition for state:State[0..1]. In sub-section Semantics, last words of para 2, change "pseudo states" to "pseudostates." Under sub-section Presentation Options change Figure "362" to "361" in the para talking about entry point and change Figure "361" to "362" in the para talking about exit point. Just thought I'd mention that when I printed a hardcopy (PDF using Adobe Acrobat Reader 6.0), the submachine state symbol in fig. 359 had a bold outline and the entry circle is normal weight whereas the submachine state symbol line weight in figs. 360-362 are normal weight as is the example on pg, 638. The exit circle in fig. 360 and on pg. 638 is in bold line weight. There also appears to be a difference in the line weights in the softcopy version.

Resolution: see above
Revised Text: In the Attribute subsection of section 15.3.1, change the text "No additional attributes." to �None�. Editor�s note: The above change was not included in the updated spec since the �No additional attributes� format has been adopted as a standard throughout the document. In the Associations subsection of section 15.3.1, change the multiplicities for the items entry:Pseudostate and exit:Pseudostate from [1..*] to [*], as those associations are mutually exclusive. In the Associations subsection of section 15.3.1, for the item state:State[0..1] change the word "refreshens" to "references" In the Semantics subsection of section 15.3.1, 2nd paragraph, change "pseudo states" to "pseudostates." In the Presentation Options subsection of section 15.3.1, change Figure "362" to "361" in the paragraph talking about entry point and change Figure "361" to "362" in the paragraph talking about exit point. In fig. 359 change the submachine state symbol from a bold outline to normal. T in fig. 360 and on pg. 638 change the exit symbol from a bold outline to normal
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

No issue has been identified with the word �of� in the text � seemed to be overlooked by
the issue submitter - no change.

Issue 8402: Section: 15.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Fig. 354 shows the association owningState:State[*]. Please add this to the sub-section or delete it from the diagram. Also, explain how a state can have multiple final states as indicated by the multiplicity in the figure. In the sub-section Semantics, the first sentence seems to contradict constraint number [4]. Please clarify more fully how a final state may be entered if there can be no entry behavior.

Resolution: see above
Revised Text: The following constraints of section 15.3.2 shall be modified to have OCL specifications as follows: [2] A final state cannot have regions self.region->size() = 0 [3] A final state cannot reference a submachine self.submachine->isEmpty() [4] A final state has no entry behavior self.entry->isEmpty() [5] A final state has no exit behavior self.exit->isEmpty() [6] A final state has no state (doActivity) behavior self.doActivity->isEmpty()
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issues here are all misunderstandings of the submitter. The association owningState
in fig. 354 refers to the state constraint and not to FinalState. There is no issue with a
region to have more than a single FinalState instances. The fact they can be reduced to a
single instance doesn�t pose any semantic problem.
Also there is no contradiction between the constraint of FinalState not to be associated
with entry behavior definitions, with the fact that entering a FinalState has behavioral
implications.
However, some of this confusion stem from the lacking of OCLs in addition to English
text. Therefore the OCL shall be added.

Issue 8403: Section: 15.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "No additonal attributes." to "None."

Resolution:
Revised Text: In the Attributes subsection of section 15.3.3, change �No additional attributes� to �None�.
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8404: Section: 15.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - In sub-section Description, change "abide" to "abides." Under sub-section Attributes, change "No additonal attributes" to "None." According to fig. 357, associations specificMachine:ProtocolStateMachine[1] subsets source, subsets owner and generalMachine:ProtocolStateMachine[1] subsets target. Mention these specializations in the definitions. Change sent. under sub-section Constraints to "None."

Resolution:
Revised Text: In subsection Description of section 15.3.5, change "abide" to "abides." In subsection Attributes of section 15.3.5, change "No additional attributes" to "None." Editor�s note: above change not made because the former is the form used throughout the spec. In subsection Associations of section 15.3.5 add to specificMachine:ProtocolStateMachine[1] the description �subsets source, subsets owner� In subsection Associations of section 15.3.5 add to generalMachine:ProtocolStateMachine[1] the description �subsets target� In subsection Constraints of section 15.3.5, change "No additional constraints." to "None." Editor�s note: above change not made because the former is the form used throughout the spec.
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8405: Section: 15.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - For consistency, spell as "pre- and post-conditions" in the Semantics sub-section

Resolution:
Revised Text: Change the text in the Semantics subsection of section 15.3.5 from �pre and post conditions for the operations� to �pre- and post-conditions for the operations�.
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8406: Section: 11.3.42 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

In the ReplyAction specification, the association replyValue is specified as an OutputPin which is inconsistant with the specification of this association on Figure 152 (p 241) where it is specified as an InputPin to ReplyAction. The specification page 300 should be changed to InputPin instead of OutputPin.

Resolution: See issue 8197 for disposition
Revised Text:
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8407: Section: 15.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "No additional attributes" to "None." The association conformance:ProtocolConformance[*] subsets ownedElement. Please add a specialization statement to the definition. Fig. 357 shows another association: interface:Interface[0..1] that subsets namespace. Add to associations or delete from fig. Constraint [3] is missing two ending parantheses but they may be found in constraint [4] as it has two extra. Delete the very small dot in front of the list of specifications in sub-section Semantics. "Depending on the context" is confusing in light of constraint [1] and "or they can be different" needs further explanation. Totally reword and redefine this paragraph. I, unfortunately, don't know enough to help you further. Typos - Reword to "Protocol state machine interpretation can be: Change "sub-statemachines" to "sub-state machines" in first line of next to last para in sub-section Semantics. In last para of sub-section Semantics, last word of second sent. should be "machines."

Resolution:
Revised Text: Associations section: add to conformance:ProtocolConformance[*] � �Subsets Element::ownedElement.� Add an association entry: interface:Interface[0..1] specifies the namespace in which the protocol state machine is defined. Subsets NamedElement::namespace. Editor�s note: above item not entered, since this is a non-navigable association end. In fact, the interface entry should be removed since it cannot be referenced Constraints section: Add to Constraint [3] two ending parentheses to balance all opened ones so it terminates with �->isEmpty())))�. Semantics section: The redundant textual bullet (�.�) shall be removed in the front of the bulleted list in the beginning of the section Editor�s note: fixed in formal copy edit In the paragraph before last in semantics section change "sub-statemachines" to "sub-state machines" In last paragraph change last word of second sentence to "machines." Editor�s note: fixed in formal copy edit
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8408: Section: 15.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - "In a protocol state machine, several transitions can refer to the same operation as illustrated below." Change below to "Figure 366" as the figure is above the text in the current version. Para. above Unreferred Operations, change "stat" to "state." Association "\referred:Operation[0..*]" needs the slash direction changed to "/" and the multiplicity of fig. 357 doesn't agree with that listed in the text. Change "No additional attributes" to "None."

Resolution: Minor editorials
Revised Text: Associations section: Change "\referred:Operation[0..*]" to "/referred:Operation[*]" In the section tittled �Operations referred by several transitions� change "In a protocol state machine, several transitions can refer to the same operation as illustrated below." to �In a protocol state machine, several transitions can refer to the same operation as illustrated in figure 366�
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8409: Section: 15.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Change "Pseudostate are" to "Pseudostates are" in sub-section Description. Fig. 354 says that the association stateMachine:Statemachine[0..1] subsets namespace. Also correct "Statemachine" to S"tateMachine." Fig 354 also shows an association state:State[0..1] that subsets owner. Correct the number of parantheses for constraints [1], [4], and [6]. Bold the word "and" in constraint [3.

Resolution: Minor editorials � change following suggestions
Revised Text: In sub-section Description Change "Pseudostate are" to "Pseudostates are" Editor�s note: fixed in formal copy edit Associations: change stateMachine:Statemachine[0..1] to �stateMachine:StateMachine[0..1] Subsets NamedElement::namespace�. Add to state:State[0..1] �subsets Element::owner�. Editor�s note: there was no �state� entry � added; Constraints: Constraint [1] - remove redundant �(� after �implies� Constraint [3] - Bold the word "and" Constraint [4] � add ")� at the end Constraint [6] - .add ")� at the end
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8410: Section: 15.3.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Font style is not consistent in the list of literal values for PseudoStateKind. Delete sub-sections Attributes and Associations or change line to "None."

Resolution: Minor editorial � follow suggestions
Revised Text: Description section: fix font style to be consistent in the list of literal values for PseudoStateKind.
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Issue 8411: Section: 15.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete sub-section Attributes or change line to "None." Fig. 354 shows that association transition:Transition[*] subsets ownedMember as does association subvertex:Vertex[*]. Fig. 355 shows that association extendedRegion:Region[0..1] redefines redefinedElement and that association /redefinitionContext:Classifier[1] subsets redefinitionContext. Within subsections Additional constraints and Additional operations stateMachine often appears with a lower case "m." Typo - delete the apostrophy starting the sentence in Additional constraing [2].

Resolution: see above
Revised Text: Minor inconsistencies between abstract syntax and text within the metaclass region. Typos. The resolution is to flow the findings above regarding the region metaclass. Revised Text: sub-section Attributes (p 598) text shall be changed to "No additional attributes." Editor�s note: fixed in formal copy edit Sub-section associations: transition:Transition[*] shall be added {subsets Namespace::ownedMember} subvertex:Vertex[*] shall be added {subsets Namespace::ownedMember} extendedRegion:Region[0..1] add {redefines RedefinableElement::redefinedElement} Editor�s note: should be �subsets� instead of �redefines� /redefinitionContext:Classifier[1] add {subsets RedefinableElement::redefinitionContext}. Editor�s note: should be �redefines� instead of �subsets� (see issue 9188) subsection Additional constraints change all occurrences of statemachine to stateMachine (2 occurences in [1]) Editor�s note: changed capitalization to StateMachine instead (consistency) delete the apostrophy starting the sentence in Additional constraing [2]. Editor�s note: fixed in formal copy edit subsection Additional operations change statemachine to stateMachine (1 occurrence) Editor�s note: changed capitalization to StateMachine instead (consistency)
Actions taken:
February 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

Minor inconsistencies between abstract syntax and text within the metaclass region.
Typos. The resolution is to flow the findings above regarding the region metaclass.

Issue 8412: Specification: Action Semantics Section: 9.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 27 illustrates a directed association from JumpHandler to HandlerAction. Yet the documentation on page 115 says there is a reference from HandlerAction to JumpHandler (jumpHandler 1..1). Where is the association from HandlerAction to JumpHandler? The multiplicity at the (non-navigable) JumpHandler end of A_HandlerAction_JumpHandler is 0..*.

Resolution:
Revised Text:
Actions taken:
March 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

This refers to part of the metamodel and text that was rewritten in UML 2.
Disposition: Closed, no change

Issue 8413: Action Semantics Section: 9.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The JumpAction->Inputs section documents jumpOccurrence:RuntimeInstance[1..1]. The second sentence of the documentation contains a typo that makes the meaning of the documentation unclear. Please re-write the second sentence.

Resolution:
Revised Text:
Actions taken:
March 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue refers to UML 1.x. The JumpAction is replaced by RaiseExceptionAction in UML 2. The sentence
with the typo isn�t in the UML2 specification document.
Disposition: Closed, no change

Issue 8415: Section: 15.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

No mention of figures 387 and 390 are made in the text. Reference figure 387 on pages 600 (Composite state) and page 606 (Entering an orthogonal composite state). Reference figure 390 at end of paragraph 2 on page 613. Typos - In sentence under Exiting an orthogonal state, change "is" in last sentence to "are." - Under Composite state (pg 609) Upper case Decomposition compartment. - Page 606, Under Exiting non-orthogonal state, change "from a composite state..." to "from a simple composite state..." to agree with the line just above Simple state in sub-section Description on page 600. - Page 606, first paragraph, change "il defined" to "ill defined." - Page 612, under Examples, change "sub state machine" to "submachine state." - Page 614, first line, change "In Figure 391 this state machine" to "In Figure 391 the state machine of figure 389 an figure 390." - Page 614, first line of Rational change "Submachine states...has been..." to "State machines...have been...."

Resolution: Minor typos and consistency with figures.
Revised Text: In pages 600 (Composite state) in the paragraph on composite state, add after the first sentence: �In Figure 387, state CourseAttempt is an example of a composite state with a single region, where state �Studying� is a composite state that contains 3 regions�. page 613. change the 2 nd sentence to: �Entry and exit points may be shown on the frame or within the state graph. Figure 389 is an example of a state machine defined with an exit point shown within the state graph. Figure 390 shows the same state machine using a notation shown on the frame of the state machine.� - In sentence under Exiting an orthogonal state (p 606), change "is" in last sentence to "are." Editor�s note: fixed in formal copy edit - Under Composite state (pg 609) Upper case Decomposition compartment. Editor�s note: not done; this would make it inconsistent with other lists in the same section, which are not capitalized - Page 606, first paragraph, change "il defined" to "ill defined." Editor�s note: fixed in formal copy edit (as �ill-defined�) - Page 612, under Examples, change "sub state machine" to "submachine state." - Page 614, first line, change "In Figure 391 this state machine" to "In Figure 391 the state machine of figure 389 an figure 390." - Page 614, first line of Rationale, change "Submachine states...has been..." to "State machines...have been...." Editor�s note: fixed in formal copy edit
Actions taken:
March 1, 2005: received issue
August 23, 2006: closed issue

Issue 8416: Section: 15.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Attributes are derived and need this noted. Also add OCL notation to the derived attributes as per the "How to Read this Specification" (page 14)indicates will be done. isComposit=(region>1) - modified from page 14. isOrthogonal=(region>=2) ??? isSimple=((region=0) and (submachineState=0)) ??? isSubmachineState=(SubmachineState>0) I question the multiplicity of the association connection:ConnectionPointReference[*]. Shouldn't it be [0..*] because the association wouldn't exist if the state was simple or compound. Ths association also subsets ownedMember and that needs to be added to the definition. According to fig. 354, the multiplicity for connectionPoint:Pseudostate is 0..8 and this association subsets ownedElement. I question the multipliticy of the association deferrableTrigger:Trigger[*]. Do all state have MULTIPLE deferrable triggers? First paragraph on page 605 says "a state may specify a set or event types that may be deferred in that state." Associations doActivity:Behavior[0..1], entry:Behavior[0..1], and exit:Behavior[0..1] all subset ownedElement according to fig. 354. Association redefinedState:State[0..1] redefines redefinedElement. This needs stating in the definition. I question the multiplicity of region:Region[*]. If the state is a simple state it has no regions (page 600). Change the multiplicity to [0..*] here and in fig. 354. Association /redefinitionContext:Classifier[1] subsets redefinitionContext and needs mentioning in the definition. Add OCL notation to constraint [3]. OCL font format doesn't appear correct for constraint [4]. Constraint [7] repeats constraint [1] but is just worded and expressed slightly differently. Should bulleted statements on page 605 immediately above Entering a non-orthogonal state be added as constraints? Should an exit point be added to the ATM state machine in fig. 391?

Resolution:
Revised Text: (1) � Already fixed (2) � Accepted � text amended (3) � Accepted (4) � Accepted (5) � Accepted (6)- Accepted (7) � Accepted (8) � Accepted. (9) � Accepted (10) � Accepted. Constraint [1] is redundant and shall be deleted (11) � No. Those deal with dynamic semantics (12) � No, the ATM statemachine is consistent as it currently is in fig. 391 Revised Text: Change the multiplicity of the association connection:ConnectionPointReference[*] to [0..*] and add {subsets ownedMember}. Change the multiplicity for connectionPoint:Pseudostate to [0..*] and add �{subsets ownedElement}. Editor�s note: fixed by 8433 Change the multiplicity of deferrableTrigger:Trigger[*] to [0..*], both in association section and fig. 354 Editor�s note: figure not changed; * is used in the diagrams consistently Add to Associations doActivity:Behavior[0..1], entry:Behavior[0..1], and exit:Behavior[0..1] �{subset ownedElement}� Add to association redefinedState:State[0..1] �{redefines redefinedElement}�. Editor�s note: should be �subsets�; fixed by 9094 resolution Change the multiplicity of region:Region[*] to [0..*] also in abs. Syntax fig. 354. Editor�s note: figure not changed; * is used in the diagrams consistently Add to association /redefinitionContext:Classifier[1] �{subset redefinitionContext}� Editor�s note: should be �redefines; see 9094 resolution OCL [1] shall be removed. Add the following OCL notation to constraint [3]. self.isSubmachineState implies (self.connection->forAll (cp | cp.entry->forAll (p | p.statemachine = self.submachine) and cp.exit->forAll (p | p.statemachine = self.submachine))) OCL font format for constraint [4] shall be fixed: names regular tone and operators boldface.
Actions taken:
March 1, 2005: received issue
August 23, 2006: closed issue

Issue 8433: Section: 15.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension.

Resolution: see above
Revised Text: - Change sub-section Attributes to "None." Editor�s note: the above change was not entered because it does not conform to the standard format - Add to Association connectionPoint:Pseudostate[*] subsets ownedMember. - Add to section associations �submachineState:State[*] references the submachine (s) in case of a submachine state. Multiple machines are referenced in case of a concurrent state�. Editor�s note: the above change was not entered because the stated association end is non-navigable. (for good reason: just like a class, a state machine should not have to be changed each time it is referenced in some other state machine) - Add to Association extendedStateMachine:StateMachine[0..1] �subsets redefinedElement� Figure 355: the text of the association line extendedStateMachine is clipped. It shall say �extendedStateMachine {subsets redefinedElement}. Multiplicity shall be changed to [0..1] on both ends. Editor�s note: fixed in formal copy edit - Page 617 Paragraph above Run-to-completion and concurrency - change "... the invoked object complete..." to "...the invoked object completes..." - Page 619 7th para: change " while the source state and trigger is preserved." to " while the source state and trigger are preserved.� - Last paragraph under StateMachine - changed text to- State machine extension is an extension of 1.x. In 1.x, state machine generalization is only informally discussed as a non-normative practice.
Actions taken:
March 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

There are few items already fixed in the post FTF text. Revised text includes only those
not yet addressed.

Issue 8439: Appendix C.1 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

script is an artifact stereotype on compliance level L1. Artifact is an element on level L2. That's a mismatch.

Resolution: Indeed. The entry should be moved to compliance level L2.
Revised Text: Superstructure (ptc/04-10-02) Move the entry for �script� from table 25 on page 756 to table 26 on page 757 immediately following the entry for �realization�. Editor�s note: Superseded by the resolution to issue 8459.
Actions taken:
March 2, 2005: received issue
August 23, 2006: closed issue

Issue 8440: Section: Appendix A (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

A use case diagram is a structural diagram. Similar to operations in classes in shows the structure of the system services. Therefore a use case is a specialized Classifier and not Behavior like model elements of all other behavior diagrams (interaction, activity, and state machine).

Resolution:
Revised Text:
Actions taken:
March 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

The classification of diagrams is a fuzzy concept to start with and has no precise formal
meaning. While it is true that a use case diagram is, in essence a specialized class
diagram, most users expect it to be a behavioral diagram � because it deals with
functional requirements and because it has traditionally been classified in that category in
UML 1. Changing this at this point is likely to introduce confusion.
Disposition: Closed, no change

Issue 8443: Section: 15.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association guard:Constraint[0..1] subsets ownedElement. Need to add this to the definition. Association replacedTransition:Transition[0..1] redefined redefinedElement. Need to add this to the definition. Association /redefinitionContext:Classifier[1] subsets redefinitionContext. Need to add this to the definition. Also need to add OCL notation. Constraint [2] - delete last paranthesis. Add OCL notation or a note that OCL cannot express constraint [7]. Add OCL notation or a note that OCL cannot express Additional operation [1]. Typos - pg. 626, para 4, sent 2, add "s" to transition. - pg. 627, 1st bullet under sub-section Example, first sent, delete the final "s" in "states." Why aren't he bulleted statements under sub-section Enabled (compound) transitions constraints? The activities named in fig. 396 ("MinorReq = ID;" and "MajorReq = ID:") are not the same format as indicated in Table 20 ("MinorReq := Id;") - the colon is missing before the equal sign in the figure.

Resolution:
Revised Text: (1) Association end �guard: Constraint[0..1]� is shown as subsetting Element::ownedElement on figure 354 on page 575. Update as suggested. However, I noticed that in some portions of the spec, this is sometimes listed at the end of the definition without curly braces and italicization. Is there a preferred style for this? (2) Association end �redefinedTransition: Transition[0..1]� is shown redefining RedefinableElement::redefinedElement on figure 355 on page 576; Name of association is listed as �replacedTransition�; recommend changing association role name to �redefinedTransition� and wordsmithing �replacement� with �redefinition� in definition as appropriate. (3.1) Assocation end �/redefinitionContext: Classifier[1]� is shown redefining RedefinableElement::redefinitionContext� on figure 355 on page 576. Update as suggested. (3.2) OCL notation appears to be already present as constraint [8]. No update required. (4) Update as suggested. (5) Since each trigger is associated with an Event and Event is an abstract superclass, I�m not sure how to write an OCL expression for constraint [7] unless it was reworded. Since some Event subclasses do not have a signatures associated with them, not sure exactly what to do. What does it mean for �the signatures of these must be compatible�? Does that mean all triggers must be associated with the same event subtype and if so, the event subtypes must have signals with the same attribute types or operations with same parameter types? (6) Add OCL as suggested. (7) Update as suggested. (8) Update as suggested. (9) Not sure if enabled (compound transition) semantics should be described using constraints or not. (10) Update as suggested. Revised Text: Superstructure (ptc/04-10-02) (1) Page 624: Replace definition for association end �guard: Constraint[0..1]� (2 nd bullet): �A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed.� with: �{subsets Element::ownedElement} A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed.� Editor�s note: subsets constraint added at the end to conform to standard format OMG Issue No: 8443 Editor�s note: overridden by the resolution to 9196 (2) Page 624: Replace association �replacedTransition� end and definition: �� replacedTransition: Transition[0..1] The transition of which this is a replacement.� with: �� redefinedTransition: Transition[0..1] {redefines RedefinableElement::redefinedElement} The transition that is redefined by this transition.� Editor�s note: subsets constraint added (instead of redefines constraint) at the end to conform to standard format; this is modified to conform with the resolution to issue 9093 (3.1) Page 624: Replace definition for assocation end �/redefinitionContext: Classifier[1]� (7 th bullet): �References the classifier in which context this element may be redefined.� with: �{redefines RedefinableElement::redefinitionContext} References the classifier in which context this element may be redefined.� Editor�s note: subsets constraint added (instead of redefines constraint) at the end to conform to standard format (3.2) No change required. (4) Page 624: Replace OCL for constraint [2]: �(target.oclIsKindOf(Pseudostate) and target.kind = #join) implies (guard->isEmpty() and trigger->isEmpty()))� with: �(target.oclIsKindOf(Pseudostate) and target.kind = #join) implies (guard->isEmpty() and trigger->isEmpty())� (5) No change required at this time until text of constraint clarified. (6) Page 625: Add OCL for constraint [7]: �context Transition::isConsistentWith(redefinee : RedefinableElement): Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = (redefinee.oclIsKindOf(Transition) and let trans: Transition = redefinee.oclAsType(Transition) in ( source() = trans.source() and trigger() = trans.trigger() ) OMG Issue No: 8443 Editor�s note: the above change was not entered because it is not valid OCL and does not do what the constraint specifies (7) Page 626: Replace 4 th paragraph: �In a compound transition multiple outgoing transitions may emanate from a common junction point. In that case, only one of the outgoing transition whose guard is true is taken. If multiple transitions have guards that are true, a transition from this set is chosen. The algorithm for selecting such a transition is not specified. Note that in this case, the guards are evaluated before the compound transition is taken.� With: �In a compound transition multiple outgoing transitions may emanate from a common junction point. In that case, only one of the outgoing transitions whose guard is true is taken. If multiple transitions have guards that are true, a transition from this set is chosen. The algorithm for selecting such a transition is not specified. Note that in this case, the guards are evaluated before the compound transition is taken.� Editor�s note: fixed in formal copy edit (8) Page 627: Replace first bulleted item under Example� �� The common simple case: A transition t between two simple states s1 and s2, in a composite states. Here the least common ancestor of t is s, the main source is s1 and the main target is s2.� With: �� The common simple case: A transition t between two simple states s1 and s2, in a composite state. Here the least common ancestor of t is s, the main source is s1 and the main target is s2.� Editor�s note: fixed in formal copy edit (9) No change required at this time. (10) Page 631: Replace figure 395:
Actions taken:
March 3, 2005: received issue
August 23, 2006: closed issue

Issue 8444: Section: 15.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to the constraints or a note that OCL notation is unavailable for these constraints. Typos - first bullet of sub-section Semantics, change "occur" to "occurs." - second bullet of sub-section Semantics, cange "stat" to "state." If a transition of kind external leaves the border of the composite state, how can it end at the composite state itself? Please provide a figure to illustrate this.

Resolution: see above
Revised Text: (1.1) Page 634: Add OCL after constraint [1]: �kind=#local implies owner.source.isComposite� (1.2) Page 634: Add OCL after constraint [2]: �kind=#external implies owner.source.isComposite� Editor�s note: Both of these constraints are invalid (e.g., �owner� does not exist for TransitionKind, which is simply an Enumeration type) and should really be defined in Transition. I corrected the OCL for these constraints and also declared them in the context of Transition (the constraints really should be moved to Transition) (2.1) Page 634: Replace first bullet text under Semantics: �kind=internal implies that the transition, if triggered, occur without exiting or entering the source state. Thus, it does not cause a state change. This means that the entry or exit condition of the source state will not be invoked. An internal transition can be taken even if the state machine is in one or more regions nested within this state.� with: �kind=internal implies that the transition, if triggered, occurs without exiting or entering the source state. Thus, it does not cause a state change. This means that the entry or exit condition of the source state will not be invoked. An internal transition can be taken even if the state machine is in one or more regions nested within this state.� (2.2) Page 634: Replace second bullet text under Semantics: �kind=local implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite stat, and these will be exited and entered.� with: �kind=local implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered.�
Actions taken:
March 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

(1.1) Update as suggested.
(1.2) Update as suggested.
(2.1) Update as suggested.
(2.2) Update as suggested.
(3) Not sure what to do with this one. Is an illustration needed or is the definition
inconsistent with itself?

Issue 8445: Section: 15.3.16 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The multiplicities for the association definitions do not agree with those shown in fig. 354. Typo - Additional operation [1], change "sate" to "state." Question - Are the "?" and "-- no other valid cases possible" legal OCL notation?

Resolution: see pages 319/320 of ptc/2006-04-01
Revised Text:
Actions taken:
March 3, 2005: received issue
August 23, 2006: closed issue

Issue 8446: Section: 15.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Inconsistent in the spelling of pre- and post-condition vs pre condition and post condition. Other sections use pre- and post-condition. Association postCondition:Constraint[0..1] subsets ownedElement and preCondition:Constraint[0..1] subsets guard according to fig 357. Question: Why doesn't association postCondition:Constraint subset guard instead or inaddition to ownedElement? For other concepts where pre- and post-conditions exist, they both subset guard

Resolution: see above
Revised Text: (1) No change required until official style is determined. (2) Page 587: Replace definition for association end �postCondition: Constraint[0..1]� (1 st bullet at top of page): �Specifies the post condition of the transition which is the condition that should be obtained once the transition is triggered. This post condition is part of the post condition of the operation connected to the transition.� with: �{subsets Element::ownedElement} Specifies the post condition of the transition which is the condition that should be obtained once the transition is triggered. This post condition is part of the post condition of the operation connected to the transition.� Editor�s note: Put subsets constraint at the end of the text to conform to standard format (3) Page 587: Replace definition for association end �preCondition: Constraint[0..1]� (2 nd bullet at top of page): �Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation referred by the transition if any.� with: �{subsets Transition::guard} Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation referred by the transition if any.� (4) No change required.
Actions taken:
March 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

(1) I was able find places where �pre-condition�, �pre condition�, and �precondition�
(same for post) were used in Section 15. Not sure which format is considered official
style.
(2) Assocation end �postCondition: Constraint[0..1]� is shown subsetting
�Element::ownedElement� on figure 358 on page 577. Update as suggested.
(3) Assocation end �preCondition: Constraint[0..1]� is shown subsetting
�Transition::guard� on figure 358 on page 577. Update as suggested.
(4) I could not find any other references to pre- or post-conditions subsetting guard as
association ends.

Issue 8449: Should Profiles::Image be an Element? (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation. 

Recommendation: 

Make Profiles::Image a subclass of Element

Resolution: see pages 323/324 of ptc/2006-04-01
Revised Text:
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8451: OCL for Property::opposite() is incorrect: (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

 OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() 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 

Recommendation: 

Fix the operation definition.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) Replace the OCL constraint of constraint [1] for Property on page 126: opposite = if owningAssociation->notEmpty() and association.memberEnd-> size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->notEmpty() then otherEnd else Set{} endif else Set {} endif with the following constraint: 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 Infrastructure (ptc/04-10-14) Replace the OCL constraint of constraint [1] for Property on page 128: opposite = if owningAssociation->notEmpty() and association.memberEnd-> size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->notEmpty() then otherEnd else Set{} endif else Set {} endif with the following constraint: 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
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Yes, there is an error here (although the correction expression must use the �isEmpty()�
operation and not �empty()�)

Issue 8452: Remove redundant superclass for Element (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Abstractions::Comments::Comment is a subclass of Abstractions::Comments::Element which is a subclass of Abstractions::Ownerships::Element. The resolution to issue 6279 redefines package merges such that the Element superclass of Element should be removed. 

Recommendation: 

Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element

Resolution:
Revised Text: InfrastructureLibraray: In figure 20, Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element Remove the Generalizations subsection of section 9.4.1 Comment. Section 9.4.2, change section title from Element (as specialized) to Element.
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8453: Profiles::ExtensionEnd has wrong default multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default. 

Recommendation: 

Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd.

Resolution: OK, that is a more accurate specification.
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.3.3 ExtensionEnd, Attributes Replace No Additional Attribute By lower : integer = 0 redefines MultiplicityElement::lower This redefinition changes the default multiplicity of association ends, since model elements are usually extended by 0 or 1 instance of the extension stereotype. In Figure 446, Add as an attribute of ExtensionEnd lower {redefines lower}: integer = 0
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8454: Profiles::ObjectNode has wrong default multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

ObjectNode::upper should have default multiplicity unbounded (�*�) in order of object nodes to be multi-valued by default. 

Recommendation: 

Redefine inherited MultiplicityElement::upper to have default �*� in ObjectNode.

Resolution:
Revised Text:
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

ObjectNode is not a MultiplicityElement. The filer might be referring to Pin, but the
multiplicity of pins is specified in each action. The upperBound of object nodes defaults
to unlimited.
Disposition: Closed, no change

Issue 8455: Profiles::ObjectNode has wrong default multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

ObjectNode::upper should have default multiplicity unbounded (�*�) in order of object nodes to be multi-valued by default. 

Recommendation: 

Redefine inherited MultiplicityElement::upper to have default �*� in ObjectNode.

Resolution: See issue 8454 for disposition
Revised Text:
Actions taken:
August 23, 2006: closed issue

Issue 8456: UML 2 Super / Collaborations / improper subset (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets �Classifier::occurrence� and should subset �Classifier::collaborationUse�. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175. 

Recommendation: 

Change figure 100 as specified above. 

In the entry for Associations of Classifier on page 175, replace the parenthesized expression: 

        Subsets Classifier.occurrence 

By the expression: 

        Subsets Classifier.collaborationUse

Resolution: see above
Revised Text: Change �subsets occurrence� in Figure 100 by �subsets collaborationUse�. In Section 9.3.2, Associations, replace under representation �(Subsets Classifier.occurrence.�) by �(Subsets Classifier::collaborationUse.)�
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

-- BranSelic - 20 May 2005
changed to double-colon convention

Issue 8457: UML 2 Super / General / improper subsetting (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge. 

Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier {subsets classifier} 

Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization {subsets clientDependency} 

Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency} 

Recommendation: 

These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible.

Resolution: see pages 330 - 333 of ptc/2006-04-01
Revised Text:
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8458: UML 2 Super / General / missing merges (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Compliance level L3 references, but does not merge: 

Superstructure::Logical View::UML::CommonBehaviors 

Superstructure::Logical View::UML::CompositeStructures 

There are a number of diagrams in the UML2 Rose model that contain unlabeled dependencies between packages. In particular, Activities, Interactions, StateMachines, and UseCases have dependencies to CommonBehaviors that are unlabeled. See diagram UML/Behavior Packages and UML/UML Top-Level Packages. 

Since CommonBehaviors does not contain any classes, it does not necessarily need to be merged into any compliance level. Instead, the packages it contains are merged as needed. 

Recommendation: 

Remove all unlabeled dependencies between packages, or mark them as either package imports or package merges as needed.

Resolution: see above
Revised Text: Mark all unlabeled dependencies between packages as package imports in the UML2 metamodel and in figures: Figure 7 Figure 123 Figure 140 Figure 353 Figure 411 Figure 445 Editor�s note: added figure 11.11
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Since CommonBehaviors does not directly contain any classes, it does not necessarily
need to be merged into any compliance level. Instead, the packages it contains are
merged as needed. The package imports are ok because the are merged away in the
compliance levels.
UML2 models are CMOF models, and CMOF does not support dependencies. So all
unlabeled dependencies in the UML2 metamodel should be either package imports or
merges.

Issue 8459: UML 2 Super / Conformance / inconsistencies (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 

There are two fundamental inconsistencies in the way that conformance is defined: 
�        BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2. 
�        Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level. 

Recommendation: 

For the first item, move CommonBehaviors::Communications from L2 to L1 

For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4

Resolution: see pages 335 - 336 of ptc/2006-04-01
Revised Text:
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8460: UML 2 Super / Kernel / invalid restriction in isConsistentWith() (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

A derived union association end represents a union of all of its subsets. The leaf subsets clearly have to be non-derived. However, in operation Property::isConsistentWith(), defined on page 127 of ptc/-04-10-02, it is stated that a derived property cannot be redefined by a non-derived property. This means that all such subsets of derived unions will be incorrect. Clearly, this restriction should be removed. 

Recommendation: 

Remove the constraint: 

        (prop.isDerived implies isDerived) 

from the operation Property::isConsistentWith() (on pg. 127)

Resolution: see below
Revised Text: The leaf subsetting properties do not have to be non-derived, a derived property can contribute to a derived union. Such a leaf property would be calculated from, or essentially rename some other property or properties. But it does seem that a derived property should be able to be redefined as non-derived by some subclass. Revised Text: In section 7.3.44 of Superstructure, change Additional Operations [1] from: [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property. Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isDerived implies prop.isDerived) and (self.isComposite implies prop.isComposite)) To: [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isComposite implies prop.isComposite)) In section 11.3.5 of InfrastructureLibrary, change Additional Operations [1] from: [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if.specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined property is derived. Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isDerived implies prop.isDerived) and (self.isComposite implies prop.isComposite)) To: [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isComposite implies prop.isComposite))
Actions taken:
March 4, 2005: received issue
April 25, 2011: closed issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8461: UML 2 Super / Kernel / excessive restriction on redefinition (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In section 7.3.44 on pg. 130 of ptc/04-10-02 there is a constraint that states: �All redefinitions shall be made explicit with the use of a {redefines <x>} property string.� Unfortunately, this is violated in numerous places in the metamodel. This results in numerous inconsistencies in the metamodel. 

Recommendation: 

As a practical resolution with minimal impact, it is recommended that this restriction be removed. This means that the use of the same association end name for a given association end implies a redefinition of the corresponding association end in an ancestor class.

Resolution: see above
Revised Text: Change the last paragraph in section 7.3.44, subsection Notation from: All redefinitions shall be made explicit with the use of a {redefines <x>} property string. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other. to: All redefinitions should be made explicit with the use of a {redefines <x>} property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other. Editor�s note: This same change needs to be made in 11.3.3 on page 124 of the Infrastructure document (ptc/04-11-16)
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

For practical reasons, this restriction should be removed. This means that the use of the
same association end name for a given association end implies a redefinition of the
corresponding association end in an ancestor class. This is typical practice in most OO
programming languages.

Issue 8462: UML 2 Super / General / invalid subset rule too strict (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model. 

Recommendation: 

As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent

Resolution: see above
Revised Text: Superstructure: In section 7.3.44, change constraint [4] to: A redefined property must be inherited from a more general classifier containing the redefining property. if (redefinedProperty->notEmpty()) then (redefinitionContext->notEmpty() and redefinedProperty->forAll(rp| ((redefinitionContext->collect(fc| fc.allParents()))->asSet())-> collect(c| c.allFeatures())->asSet()-> includes(rp)) InfrastructureLibrary: Make the same change for constraint [5] in section 11.3.5. Editor�s note: The change was made to constraint [4] not constraint [5] (the latter is a mistake in the resolution)
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The UML2 specification current couples navigability and property ownership as
described in section 6.5.2. In addition, there is currently no notation for specifying
property ownership separate from navigability. Although section 6.5.2 may specify
useful defaults in the absence of anything specific from the modeler, this is not currently
part of the specification. As a result, any redefinition that changes navigability will also
change the property from an ownedAttribute of a class to/from an ownedEnd of an
Association. This will result in an invalid redefinition because the redefined property will
not be in a classifier that is a generalization of the classifier containing the redefining
property (the redefinition context).
In addition, even if there was notation that allowed the ownership to be specified
separately from the navigability, there are instances in the UML2 model where
navigability of the same property is redefined to be both navigable and non-navigable in
different subclasses which results in the property needing to be owned by an association
and class at the same time.
Constraint [4] in section 7.3.44 says a navigable property can only be redefined or
subsetted by a navigable property. There are many cases in the UML2 model where this
constraint is violated for subsetted properties contributing to derived unions. For
example, Element::/element is a navigable derived union which is redefined or subsetted
by many non-navigable and navigable non-derived properties. This results in many
invalid subsets because of changes in navigability in different subclasses for the same
inherited property.
However, the subsetting context for an association end is the classifier at the other end.
Constraint [3] says subsetting may only occur when the context of the subsetting property
conforms to the context of the subsetting property. That is, the subsetting context must be
the same or a subclass of the subsetted context. This is the case of all of the subsets in the
UML2 model as long as navigability is ignored. In theory, the subsetting context from a
non-navigable subsetted end would not be a property of a classifier inherited by the
context of the subsetting end. However, a property does know its association, so like
OCL, subsetting can be defined to be independent of navigability. It is not clear this is the
intent of the UML2 specification, but it is clearly used many times in the metamodel. Redefinitions must be stricter because the redefined property must not simply be
accessible, but must be a inherited. Fortunately there are no instances where redefinitions
change property ownership.
When an association generalizes another association and redefines its ends, the redefined
end must be accessible through the generalization. This means redefining and redefined
properties must be ownedEnds of the association or ownedAttributes of the participating
classes. Redefining ownership (either directly or indirectly by changing navigability with
default ownership) resulting in the redefined property no longer being a member of the
general classifier would result in an invalid redefinition.
As a result, constraint [4] in section 7.3.44 both over-constrains subsets and is
incomplete. It should state the redefined property must be inherited from a generalization
of the classifier containing the redefining property. This doesn�t apply to subsetting
because it�s not a redefinition. So constraint [4] should not reference subsetted properties.

Issue 8463: UML 2 Super / Common Behaviors / missing multiplicites (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In figure 318 on page 463, the multiplicities of DurationObservationAction::duration and TimeObservationAction::now are not specified. This results in violations of the redefinition rules for these association ends. 

Recommendation: 

Set the multiplicities for these association ends to 1, to conform to the multiplicity of WriteStructuralfeatureAction::value association end that they redefine

Resolution:
Revised Text: In figure 318 , set the multiplicities for DurationObservationAction::duration and TimeObservationAction::now to 1. Editor�s note: superseded by resolution to 8894
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8465: Section: 16.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Generalizations add the generalization "NamedElement (from Kernal)" on page xxx" (page 100 I believe). This generalization is diagrammed in fig. 401. Delete sub-section Attributes or change wording to "None."

Resolution: Indeed. This was a missed generalization.
Revised Text: see page 341 of ptc/2006-04-01
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8466: Section: 16.3.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Fig. 401 shows 2 associations: extend:Extend{*] and useCase:UseCase[1]. Define these in the sub-section Associations. Delete sub-section Attributes or change the wording to "None."

Resolution: see page 342 of ptc/2006-04-01
Revised Text:
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Issue 8467: Section: 16.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Add the generalization "NamedElement (from Kernal)" on page xxx (page 100 I believe). This generalization is shown in fig. 401 and mentioned in the Description sub-section. Delete sub-sections Attributes and Constraints or change wording to "None." In sub-section Semantics, I'm not certain that the following statement is reflected in fig. 401 "Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in iteself by dependent on the included parts to be meaningful. This is relfected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa." Reword 2nd sent of para 2, Semantics, to "All of the behavior of the included use case is executed...." or "The included use case behavior is executed at a single..."

Resolution: see above
Revised Text: In generalizations section of 16.3.5: Add �NamedElement (from Kernel) on page <ref>� Editor�s note: The above was already done by 8465 In semantics section of 16.3.5: Reword 2 nd sentence of 2 nd paragraph to �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.� (Note: Replaced 10 th word from �are� to �is�) Editor�s note: fixed in formal copy edit
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

Sub-section Attributes and Constraints are not empty. It seems that the submitter refers to
ptc/03-08-02.
Fig. 401 reflects the content of the quoted sentence as far as it is possible for a class
diagram.

Issue 8468: Section: 16.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete sub-section Attributes or change wording to "None." For the associations include:Include[*] and extend:Extend[*], the "Specialized Classifier.feature" is not shown in fig. 401. Add OCL notation to constraints [2] and [3] or indicate the OCL notation is not available. Add an ending ")" to Additional Operation OCL notation--one missing. Typo - 1st sent. of para 3 of Semantics, change "describe" to "Describes." There is no association or navigable link between UseCase and Actor shown in fig. 401. Add appropriate link(s).

Resolution: see above
Revised Text: In fig. 401 update the following association annotations: Assocation from UseCase to Extend: Replace +extend {subsets ownedMember} with +extend {subsets ownedMember,feature} Assocation from UseCase to Include: Replace +include {subsets ownedMember} with Editor�s note: not done because neither �extend� nor �include� are kinds of Features! These two changes are incorrect. In constraints section of 16.3.6: Replace [2] UseCases can only be involved in binary Associations. [3] UseCases can not have Associations to UseCases specifying the same subject. with [2] UseCases can only be involved in binary Associations. OCL not available. [3] UseCases can not have Associations to UseCases specifying the same subject. OCL not available. In additional operations section of 16.3.6: Add missing ")" at the end of the OCL expression.
Actions taken:
March 4, 2005: received issue
August 23, 2006: closed issue

Discussion:

The wording "No additional attributes. " in the attributes section is conform to our
decision. It warns readers that there may be associations involving this concept that are
defined somewhere else.
The typo change "describe" to "describes" is already done.
There is no need to define an association between UseCase and Actor. The relationship
between both elements in a user model is a common association that is defined between
their base class classifier.

Issue 8469: Section: 14.3.3 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Typo: Constraint 3 contains the word "IntectionFragment". Should be InteractionFragment

Resolution:
Revised Text: Before (14.3.3 page 508) [3] If the interactionOperator is break, the corresponding InteractionOperand must cover all Lifelines within the enclosing IntectionFragment. Revised text: [3] If the interactionOperator is break, the corresponding InteractionOperand must cover all Lifelines within the enclosing InteractionFragment. Editor�s note: fixed in formal copy edit
Actions taken:
March 5, 2005: received issue
August 23, 2006: closed issue

Issue 8470: Section: Actions (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Eran Gery, eran.gery(at)il.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Add actions for reading and writing parameter values, so flows are not required in structured activities

Resolution: Duplicate of issue 9247. Revised Text: None. Disposition: Duplicate
Revised Text:
Actions taken:
February 25, 2005: receievd issue
February 27, 2005: received issue
March 6, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8471: Decision node (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Decision node should be able to take decision based on input separate from the flow being routed

Resolution: Resolution: This issue is already resolved in UML 2.2 (see Issue 10815). Revised Text: None Disposition: Duplicate
Revised Text:
Actions taken:
March 6, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8472: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Object node should be a multiplicity element, and use multiplicity upper for upperbound

Resolution: Though seemingly small, this would actually be a significant change to the metamodel for activities and it would fundamentally change the current semantics for multiplicity of pins, which now only effect the execution of actions. If object node in general were made a multiplicity element, one would not only have to reconcile the current semantics of object node upper bound with the semantics of the multiplicity upper bound of a pin, one would also need to consider what the general semantics are for the multiplicity lower bound of an object node. This issue is thus considered strategic and out of scope for an RTF. Revised Text: None Disposition: Closed Out of Scope
Revised Text:
Actions taken:
March 6, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8476: Section: Common Behavior (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Common Behavior: why does Figure 326 refer to Signal from Communications, but not Operation form Communications? (it looks like Communications can refer to Kernel:Operations rather than defining its own).

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Communications, semantics and a semantic variation point are added to Operation.
Defining this semantics requires the presence of concepts that are introduced in
Commuincations. However, this semantics is not necessarily required for interactions,
and thus Operation::Kernel is referenced there.
Disposition: Closed, no change

Issue 8477: Section: Actions (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

Figure 141, remove import from IntermediateActions to Communications. Add an import from BasicActions to Communications

Resolution:
Revised Text: In Actions, package dependency diagram, Figure 141, remove import from IntermediateActions to Communications. Add an import from BasicActions to Communications.
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8478: ValueSpecificationAction, Attribute section, is missing the return pin (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

ValueSpecificationAction, Attribute section, is missing the return pin

Resolution:
Revised Text: In Activities, Actions, ValueSpecificationAction, Associations Editor�s note: changes made only to Actions � nothing to change in Activities In value entry, remove �{Specializes Action::output }�. Editor�s note: repeat of 8194 Add new entry: �result : OutputPin [1] Gives the output pin on which the result is put. (subsets Action::output)�
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed isuse

Issue 8481: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

<pre> ExceptionHandler, clarify working of constraint [1]: "[1] The exception body may not have any explicit input or output edges." It should say the exception handler and its input object node are not the source or target of any edge. </pre>

Resolution:
Revised Text: In Activities, ExceptionHandler, Constraints: Constraint 1, replace text with "The exception handler and its input object node are not the source or target of any edge." Add a new constraint after constraint 1: "An edge that has a source in an exception handler structured node must have its target in the handler also, and vice versa." Editor�s note: Made slight rewording change for readability
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8482: Section: Activities, ExpansionRegion (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

ExpansionRegion, clarify wording in description: expansion nodes are not input pins.

Resolution:
Revised Text: In Activities, ExpansionRegion, Description, first paragraph, third sentence, replace "input pins" with "inputs".
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8483: Section: Activities, ExpansionRegion (02) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

ExpansionRegion: remove "If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs." Inputs and outputs of expansion regions do not need to correspond, this was intended to refer to the pins that flows to the output. Add general constraints on types of source and targets of object flows rather than have the a special case for expansion nodes.

Resolution:
Revised Text: In Activities, ExpansionRegion, Description, second paragraph, remove first sentence (the one beginning "If an expansion region has outputs").
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8484: Section: Activities, ExpansionRegion (03) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

ExpansionRegion: require that all input collections have the same number of elements at runtime.

Resolution:
Revised Text: In Activities, ExpansionRegion, Semantics, first paragraph, second sentence, in parenthetical comment, add ", in which case the input expansion nodes must all have the same number of values at runtime"
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8485: Section: Activities, ExpansionRegion (04) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

In ExpansionRegion, clarify that that input pins on expansion regions (introduced by merge with CompleteStructuredActivities) provide values that are constant across the execution of the region, and that output pins are not allowed.

Resolution: see above
Revised Text: In Activities, ExpansionRegion, Description, last paragraph, add sentence at end: �Input pins, introduced by merge with CompleteStructuredActivities, provide values that are also constant during the execution of the region.�
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

Output pins are allowed on all structured nodes, with semantics specified at
StructuredActivityNode.

Issue 8486: Section: Activities, ExpansionRegion (05) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

<pre> In ExpansionRegion, clarify the interaction of elements from multiple input collections (ie, there is none). Clarify that the region operates on each collection in the specified mode. From Jim R: If there are N input collections (note there may also be plain scalar inputs, whose value remains constant in each of the executions), then one value from the same position in each of them represents a "slice". The slice is not actually formed into an object or a single value. The body of the region is executed once for each slice. Each of its pins gets the value from the given position in the corresponding input collection. Each execution is independent and concurrent, therefore the values from different positions do not interact. If the body interacts with an outside object, then there is a high possibility of conflict among the concurrent executions, so that is not usually recommened, although it is not forbidden by the UML2 rules. If it does happen, you can't assume any particular order of execution or even that two executions won't hit the same slot at the same time (in this, it is the same as all other uses of concurrency in UML). If each execution keeps to its own subset of values (for example, by indexing into a collection using the input position for that execution), then things might be OK; otherwise it's probably a real bad idea to use this construct. It works best when the computations are purely internal, in that case the concurrency poses no problems at all and permits total freedom in implementation; those kinds of computations are pretty common in practice. </pre>

Resolution: see above
Revised Text: In Activities, ExpansionRegion, Semantics, first paragraph: Second sentence, remove �(or once per element position, if there are multiple collections)�. Editor�s note: supersedes change made by 8484 After second sentence, insert new sentence, �If there are multiple inputs, a value is taken from each for each execution of the internals of the region.� Third sentence, remove �multiple�.
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

There is interaction of the inputs in stream and iteration modes. Clarification about
�slices� added below.

Issue 8487: ExpansionRegioin example, Figure 261: concurrent => parallel (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

ExpansionRegioin example, Figure 261: concurrent => parallel

Resolution:
Revised Text: In Activities, Figure 26, replace concurrent keyword with parallel. Editor�s note: Duplicate of 8241
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8488: Expansion region description (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Expansion region description: "The number of output collections at runtime can differ from the number of input collections." Drop "at runtime".

Resolution: The sentence is supposed to be about modeling time, rather than runtime.
Revised Text: In Activities, ExpansionRegion, Description, second paragraph, second sentence, remove "at runtime".
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8490: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Loop node owns output pins as loop input variables, but pins must be owned by actions under the input/output associations in UML 2 (not in UML 1.5).

Resolution: The filer is referring to the loop variable pins.
Revised Text: In Activities: Figure 196: on loopVariable association, remove composite aggregation and remove �subsets ownedElement�. on LoopNode::bodyOutput add {ordered} on Clause::bodyOutput, add {ordered } LoopNode, Association (CompleteActivities), in loopVariable entry, remove �owned by the loop�. Editor�s note: also, remove subsets constraint from �loopVariable� entry and add {ordered} to bodyOutput::LoopeNode and Clause::bodyOutput
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8491: Add constraint in LoopNode (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Add constraint in LoopNode that loop variable inputs should not have edges coming out of them. Otherwise, the value could leave the pin in the middle of the loop.

Resolution:
Revised Text: In Activities, LoopNode: Change heading "Constraints" to "Constraints (CompleteStructuredActivities)". Under the changed constraint heading, remove �None� and add new constraint: "Loop variable inputs must not have outgoing edges." Editor�s note: used conventional package subheading instead of bracketed heading specified above
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8493: Semantics of isAssured/isDeterminant in conditional node (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Semantics of isAssured/isDeterminant in conditional node, the phrase "concurrently yield a value" sounds it is referring to tests that complete at the same instant in time. Would be clearer to drop "concurrently", since it isn't the concurrency that isAssured/isDeterminant is concerned with, it's the results.

Resolution:
Revised Text: In Activities, ConditionalNode, Semantics, fourth paragraph, fifth sentence (the one beginning "If the isDeterminate attribute has a true value"), remove "concurrently".
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8494: Add constraints on conditional, loop, sequence to rule out node contents (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Add constraints on conditional, loop, sequence to rule out node contents that are not in the sequence, or clause, setup/body part

Resolution:
Revised Text:
Actions taken:
March 6, 2005: receievd issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

The setup/test/body parts of loop nodes and the test/body parts of conditional node clauses are defined only in terms of executable nodes. However, in general, one also wants to be able to have non-executable nodes, such as control nodes, within a loop or conditional node. These will be contents of the loop or conditional node, but not specified to be in any setup/test/body part. However, any executable nodes contained in a loop or conditional node should, indeed, be in a setup, test or body part within the loop or conditional node.
For sequence nodes, the SequenceNode::executableNode association redefines StructuredActivityNode::node, so a sequence node can only contain executable nodes.
Revised Text:
The constraints introduced in the resolution of Issues 8492 (for loop nodes) or 8495 (for conditional nodes) cover the resolution of this issue, too.
Disposition:	Closed, No Change

Issue 8496: Add constraints on conditional and loop nodes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Add constraints on conditional and loop nodes that decider is an output pin of an action in the test body, and that its type is boolean

Resolution:
Revised Text: In Activities, Clause: Add heading "Constraints" before Semantics. Add new constraint: "The decider output pin must be for the test body or a node contained by the test body as a structured node."
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8497: Add constraints on conditional and loop nodes (02) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Add constraints on conditional and loop nodes that body outputs are pins on action contained in the body part of the clauses

Resolution: see page 361 of ptc/2006-04-01
Revised Text:
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8498: Constrain conditional node to have body pins if there is a result pin. (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Constrain conditional node to have body pins if there is a result pin. Constrain to be of the same number and compatible types

Resolution: agreed
Revised Text: In Subclause 12.3.18 (ControlNode), add the following constraint: [2] Each clause of a conditional node must have the same number of bodyOutput pins as the conditional node has result output pins, and each clause bodyOutput pin must be compatible with the corresponding result pin (by positional order) in type, multiplicity, ordering and uniqueness.
Actions taken:
March 6, 2005: received issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8499: No notation (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

In ConditionalNode: "A notational gloss is provided for this frequent situation." There is no notation

Resolution:
Revised Text: In Activities, ConditionalNode, Description, next to last paragraph, remove last sentence (the one beginning "A notational gloss").
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8500: mustIsolate: (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics.

Resolution: see above
Revised Text: In Activities, StructuredActivityNode, Semantics, last paragraph, third sentence, replace �any action inside the node� with �the node�.
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

The text cited above from UML 1.5 appears in the Description section of UML 2
StructuredActivityNode (except for the example). The last paragraph of Semantics is
new to UML 2 and it worded incorrectly in one spot, as the submitter points out.

Issue 8502: Figure 209 of Activites (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Figure 209 of Activites, and entry in index: <<singleCopy>> should be replaced with <<singleExecution>>.

Resolution: In Activities, Activity, Figure 209, replace "singleCopy" with "singleExecution".
Revised Text:
Actions taken:
March 6, 2005: received issue
August 23, 2006: closed issue

Issue 8503: Clarify the semantics of minimum multiplicity > 0 for streaming parameters (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Clarify that the semantics of minimum multiplicity > 0 for streaming parameters that it is required sometime during execution

Resolution:
Revised Text: In Activities, Parameter, Semantics, third bulleted paragraph (the one beginning �Either all required�), after �finished� add �(output of required streaming parameters may be posted before execution finishes)�.
Actions taken:
March 7, 2005: received issue
August 23, 2006: closed issue

Issue 8506: Section: 17.2.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Change first sent. under sub-section Description to "...one or more information items circulates from its sources to its targets." Subject of phrase is singular (one or more) and needs the singular verb. Add OCL notation to the constraints or state that OCL notation is not available. Constraint [1] reads like an enumeration. Why is it not diagrammed showing an enumeration. Reword the except clause to "...and InstanceSpecification except when the classifier of the InstanceSpecification is a relationship (i.e., it represents a link)." Constraint [2] change "target" to "targets" and delete the prepositional phrase "if any." (Or explain how information can flow if there isn't at least one source and one target.)

Resolution: see above
Revised Text: (1) In " 17.2.1 InformationFlow � Description" Change: An Information Flow specifies that one or more information items circulate from its sources to its targets. Into An Information Flow specifies that one or more information items circulates from its sources to its targets. (2) In " 17.2.1 InformationFlow � Constraint" Change [1] The sources and targets of the information flow can only be of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link). Into [1] The sources and targets of the information flow can only be of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when the classifier of the InstanceSpecification is a relationship (i.e., it represents a link)." Editor�s note: done as part of 6446 (3) In " 17.2.1 InformationFlow � Constraint" Change [2] The sources and targets of the information flow must conform with the sources and targets or conversely the target and sources of the realization relationships, if any. Into [2] The sources and targets of the information flow must conform with the sources and targets or conversely the targets and sources of the realization relationships. (4) In 17.2.1 InformationFlow , constraints, add after the respective constraint descriptions the following OCL expressions [1] (self.source->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification))) and (self.target-> forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification))) [3] self.conveyed.represented->forAll(p | p->oclIsKindOf(Class) or oclIsKindOf(Interface) or oclIsKindOf(InformationItem) or oclIsKindOf(Signal) or oclIsKindOf(Component)) (5) In 17.2.2 InformationItem , constraints, add after the respective constraint descriptions the following OCL expressions [1] (self.represented.select(p | p->oclIsKindOf(InformationItem))->forAll(p | p.informationFlow.source->forAll( q | self.informationFlow.source->include(q) ) and p.informationFlow.target->forAll( q | self.informationFlow.target->include(q) ) )) and (self.represented->forAll(p | p->oclIsKindOf(Class) or oclIsKindOf(Interface) or oclIsKindOf(InformationItem) or oclIsKindOf(Signal) or oclIsKindOf(Component))) [2] self.generalization->isEmpty() and self.feature->isEmpty()
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

Globally OK, except the enumeration issue: we are talking about connected metaclasses,
enum is not suitable for this.

Issue 8507: Section: 17.2.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Not all of the sub-package names given in the sub-section Generalizations are shown in fig. 413. Add them or ellipses. Change capitalization of "information Item" and "Information Items" in sub-section Description to agree. If Information Item is an abstraction shouldn't the name appear in italics in fig. 413? Change last sent. of para 1, sub-section Description to "...for representing information in a very abstract way, one which cannot be instantiated." Change "taken" to "made" in first sent. of para 2 of Descriptions. Delete sub-section Attributes or change wording to "None." Add OCL notation to constraints [1] and [2] or a note that OCL notation is not available. Constraint [1] contains an enumeration list but this is not diagrammed as part of fig. 413. The constraint reads like a guard whose condition is that the InformationItem can only be of the enumerationKind listed in the constraint. Why not diagram it that way? Typos - 1st sent., Para 2 of sub-section Semantics, change "item" to "items." - 2nd sent., Para 3 of sub-section Semantics, reword to "specifying this detailed information belongs to the represented classifier." Question - Why is the multiplicity in fig. 418 0..1? Suggest removing all multiplicities from diag. 418 as they add nothing to it.

Resolution: see above
Revised Text: (1) Throughout section 17.2, ensure that the capitalization of �information item� and �information flow� are in lower case (except at the beginning of a sentence) : i.e. get rid of forms such as �information Item� or �Information Flow�. (2) In 17.2.2 Information Item � Description Change It is a kind of classifier intended for representing information at a very abstract way, which cannot be instantiated. Into It is a kind of classifier intended for representing information in a very abstract way, one which cannot be instantiated. Change One purpose of InformationItems is to be able to define preliminary models, before having taken detailed modeling decisions on types or structures. Into One purpose of InformationItems is to be able to define preliminary models, before having made detailed modeling decisions on types or structures. (3) In 17.2.2 Information Item � Semantics Change Information items can be decomposed into more specific information items, using representation links between them Into Information items can be decomposed into more specific information items using representation links between them Change Specifying these detailed informations belongs to the represented classifiers. Into Specifying this detailed information belongs to the represented classifier.
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

It is not necessary to add all the package names into figure 413. Not all the classes in that
list are actually superclasses of InformationItem (the list is simply a consequence of the
way that class names are cross-referenced in the document � the title of the section is
used rather than the name of the actual metaclass).
The Attributes section follows the convention used throughout the document. It should
not be removed.
Information Item is a concrete class. Part of this issue (constraints) overlaps with issue
8506 and will be treated there.
Figure 418 is an example of a model with associations and multiplicities. There is no
point to removing the multiplicities.

Issue 8508: Section: 17.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

If model is an abstraction of the physical system shouldn't the name in fig. 419 be in italics? Attribute viewpoint:String[*] does not have the same multiplicity as shown in fig. 419 which is the default multiplicity of [0..*] as indicated on page 14 of this document. Delete sub-sections Associations and Constraints or change the wording to "None." Add the word "open" between small and triangle in 1st sent. of Notation. Typo - 2nd sent of sub-section Notation, change "is" to "are."

Resolution: see page 371 of ptc/2006-04-01
Revised Text:
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Issue 8509: Section: 17.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

PprimitiveTypes strike me more as an enumeration or list than a package. Consider changing them to an enumeration or list. Boolean is derived from George Boole and is generally capitalized whenever used. Please be consistent in capitalization of "Boolean" when using the word as an adjective. Sometimes on page 673 it is capitalized ("The Boolean condition") but other times it is not ("boolean type," "boolean attribute," and "boolean expression"). Delete sub-sections Attributes, Associations, and Constraints or change the wording to "None.

Resolution:
Revised Text: Superstructure (ptc/04-10-02) Change all 11 incorrect spellings of �boolean� (with a lower-case �b�) to �Boolean� Infrastructure (ptc/04-10-14) Change all 8 incorrect spellings of �boolean� (with a lower-case �b�) to �Boolean�
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

Changing the primitive types to an enumeration list at this point would cause disruption
among the numerous implementations of UML tools.
The change to �None� is not in line with the default editing policy and will not be made.
The term Boolean should be spelled with a capital B and the change will be made
throughout the document for consistency.

Issue 8510: Section: 17.5.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delete sub-sections Attributes and Constraints or change wording to "None." Add the association owningDefault:TemplateParamenter[0..1] that subsets owner. Fig. 427 shows this.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) In Figure 427 on page 678, remove the ParameterableElement::owningDefault name from the diagram and the accompanying subsets constraint.
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The change to �None� is not in line with the default editing policy and will not be made.
The general rule is that non-navigable (and non-owned) association ends are not named
or documented in the spec.

Issue 8511: Section: 17.5.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Delete the sub-sections Attributes and Constraints or change the wording to "None." Association templateBinding:TemplateBinding[*] subsets Element::ownedElement according to fig. 428. Change wording in para 3, sent. 2 of sub-section Semantics to "...by expanding the templates to which it binds, since..." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateableElement but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred.

Resolution: see page 374 0f ptc/2006-04-01
Revised Text:
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8512: Section: 17.5.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add associaton owningSubstitution:TemplateParameterSubstitution[0..1] that subsets Element:owner as shown in fig. 428.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) In Figure 428 on page 679, remove the ParameterableElement::owningSubstitution name from the diagram and the accompanying subsets constraint.
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The general rule is that non-navigable (and non-owned) association ends are not named
or documented in the spec.

Issue 8513: Section: 17.5.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Delete sub-section Attributes or change wording to "None." Add that the association boundElement also subsets Element::owner as shown in fig. 428. Change the association name from "template":TemplateSignature to "signature" in the text or change fig. 428 association name from "signature" to "template." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateBinding but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred. Or change the name of Classifier to ClassifierTemplate and Package to PackageTemplate. If name change is made then change the names in all figures that contain these template names

Resolution: see page 376 of ptc/2006-04-01
Revised Text:
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Issue 8514: Section: 17.5.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure.

Resolution:
Revised Text:
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter seems to have missed the fact that a number of metaclasses are defined as
subclasses of ParameterableElement in this chapter, including Classifier (on page 689),
PackageableElement (page 696), Operation (pg. 704), and ConnectableElement (pg. 706).
Disposition: Closed, no change

Issue 8515: Section: 17.5.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure. Delete sub-section Attributes or change wording to "None." Typo - Delete the second word ("the") of the second para of Semantics.

Resolution: see above
Revised Text: In subsection Semantics of section 17.5.4 in ptc/04-10-02 on page 686, replace the phrase: Each the exposed element constrains the elements with the phrase: Each exposed element constrains the elements Editor�s note: fixed in formal copy edit
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

For the issue of subclasses of ParameterableElement, see the resolution to issue 8514.
The wording for Attributes is as per document convention and need not be changed.
The type should be fixed.

Issue 8516: Section: 17.5.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Delelte sub-section Attributes or change wording to "None." Change association name from "binding":Tto "templateBinding" to agree with fig. 428 or change fig. 428 association name from "templateBinding" to "binding."

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) Change the name of the association end :binding� for TemplateParameterSubstitution at the top of page 687 from �binding� to �templateBinding�.
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The change to �None� is not in line with the default editing policy and will not be made.
The role name must be corrected

Issue 8517: Section: 17.5.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Delete sub-section Attributes or change wording to "None." Change definition of association parameter:TemplateParameter to "The complete set of ordered formal template parameters for this template signature." This is indicated by fig. 427. I believe Constraint [2] should say "parameters are the owned parameter." Change wording of 2nd sent. of 2nd para of Semantics to "Either the parameter that owns the parametered element, or the element that is owned, directly or indirectly, but the template subclasses of TemplateSignature can add additional rules constraining what a parameter can reference in the context of a particular kind of template." I see no subclasses for TemplateSignature in the diagrams--just composite parts. The paragraph under ClassifierTemplates needs enhancement. What figure is being referenced? If it is fig. 429, that diagram does not support the text paragraph.

Resolution: see pages 379 - 380 of ptc/2006-04-01
Revised Text:
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Issue 8518: Section: 17.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In fig. 412 the PrimitiveTypes package is sitting alone with no dependencies or navigation lines yet it is on the same level as Kernal, BasicActivities, BasicInteractions, and InternalStructures. If all of the other packages don't import elements from PrimitiveTypes, I would suggest offsetting the PrimitiveTypes package or putting it in a separate figure. Question - Why not develop PrimitiveTypes as an enumeration with Boolean, Integer, String, UnlimitedNatural, and UserDefinedKind or UserDefinedList as the elements of the enumeration?

Resolution: see above
Revised Text: In figure 412 on page 665, remove the PrimitiveTypes package from the diagram
Actions taken:
March 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

The PrimitiveTypes package should not be in this diagram.
PrimitiveTypes are defined in the Infrastructure library and used at multiple metalevels.

Issue 8527: Section: 17.5.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The classifier for the association parameter:ParameterableElement[0..1] does not agree with fig. 429. The classifier is titled ClassifierTemplateParameter in the figure. In addition, the figure does not support that this association redefines ParameterableElement::parameter Fig. 413 shows an additional association: representation:InformationItem[*]. Please add this to the sub-section Typos - 2nd line, 1st para under Section, rewrite as "parameterable element so that a classifier can be exposed as a formal template paramenter, and provided as ...." - 1st line, under sub-section Description, put a comma after Kernal::Classifier. - 3rd line, 3rd para under sub-section Semantics insert the word "of" between "specialization" and "this anonymous." - Last sent., para 2 of Collaboration under sub-section Semantics, change the word "used" to something "identified" or "defined" or "decided." "We have used that..." is not very understandable. - Last para. of Collaboration under sub-section Semantics: change "produce" to "producer" and "NrokeredSale" to "BrokeredSale." Delete "And anyway," and change "Parameters, by the very nature..." to "Parameters, by their very nature..."

Resolution: see pages 382 - 383 of ptc/2006-04-01
Revised Text:
Actions taken:
March 9, 2005: received issue
August 23, 2006: closed issue

Issue 8528: Section: 17.5.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The redefines statement of association parameteredElement:Classifier[1] is not supported in fig. 429. Delete sub-section Constraints or change wording to "None." Change spelling of alloswSubstitutable to allowSubstitutable in 2nd sent. of last para of sub-section Notation.

Resolution: see page 384 of ptc/2006-04-01
Revised Text:
Actions taken:
March 9, 2005: received issue
August 23, 2006: closed issue

Issue 8529: Section: 17.5.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The classifier name for the association nameExpression: in fig. 438 is StringExpression not Expression as indicated by text. In addition, the figure indicates that nameExpression:StringExpression[0..1] subsets ownedElement. Typo - under sub-section Notation in para "With alias:" change "is" in the first sent. to "are."

Resolution: Indeed. These errors must be fixed.
Revised Text: Superstructure (ptc/04-10-02) (1) On page 699 replace: � nameExpression : Expression [0..1] The expression used to define the name of this named element. with: � nameExpression : StringExpression [0..1] The string expression used to define the name of this named element. Subsets Element::ownedElement. (2) On page 700, replace the phrase: With alias: Both the string expression and the alias is shown with the phrase: With alias: Both the string expression and the alias are shown
Actions taken:
March 9, 2005: received issue
August 23, 2006: closed issue

Issue 8530: Section: 17.5.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 438 shows an additional associaton: owningExpression:StringExpression[0..1] that subsets owner

Resolution: Indeed. This item needs to be added.
Revised Text: see page 386 of ptc/2006-04-01
Actions taken:
March 9, 2005: received issue
August 23, 2006: closed issue

Issue 8544: Section: 12 Activities (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Figure 178 and 183 there is two different inheritance relationships. In 178 the class ControlNode is a direct parent for classes ActivityFinalNode and InitialNode. These two classes are a direct descendant from FinalNode in figure 183. These introduce two different inheritance taxonomy with different meaning.

Resolution: See issue 8237 for disposition
Revised Text:
Actions taken:
March 11, 2005: received issue
August 23, 2006: closed issue

Issue 8587: Section: 17.5.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Be consistent with the capitalization of "Operation" in sub-section Semantics

Resolution: Indeed. Change the first case to lower case initial letter.
Revised Text: Superstructure (ptc/04-10-02) On page 703, in the first sentence of the Notation sub-section of Operation, replace the first use of the word �Operation� by the word �operation� (lower-case initial letter). Editor�s note: this seems to have been fixed in the formal copy edit, however, same change made for the first sentence of the �operation template parameters� sub-section following the above Notation subsection.
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8588: Section: 17.5.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

It is very confusing to have two very similar concepts with the same name (17.5.14 and 17.5.15). Could the two concepts be combined into one, combining figure 440 with 441 and the text? If not, consider changing the name of one of the concepts. Association parameter:ParameterableElement is not what is diagrammed in fig. 441. Instead fig. 441 shows parameter:OperationTemplateParameter[0..1] with no redefinition mentioned.

Resolution: see above
Revised Text: For the �parameter� association end item in the Associations section of Operation on page 704 change the type of the item from �ParameterableElement� to �OperationTemplateParameter�.
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Discussion:

The submitter seems to have missed the fact that this is a different merge increment of the
same concept in a different package. There is no need to rename the concept � it is the
same concept.

Issue 8589: Section: 17.5.16 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig 441 for the association parameteredElement:Operation[1] does not mention that the association redefines TemplateParameter::parameteredElement.

Resolution: see page 389 of ptc/2006-04-01
Revised Text:
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8590: Section: 17.5.17 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 442 does not show that the association parameter:ConnectableElementTemplateParameter redefines anything.

Resolution: See the discussion to issue 8528. We will add a clarification to the diagram.
Revised Text: see page 390 of ptc/2006-04-01
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8591: Section: 17.5.18 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 442 does not show that association parameteredElement:ConnectableElement redefines anything

Resolution: See the discussion on issue 8590.
Revised Text: See the resolution to issue 8590.
Actions taken:
May 9, 2000: received issue
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8592: Section: 17.5.19 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation to the constraint or a note that OCL notation is not available

Resolution: see page 392 of ptc/2006-04-01
Revised Text:
Actions taken:
May 3, 2000: received issue
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8593: Section: 17.5.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Resolution: This seems to be a leftover from a previous edit. Remove the association item.
Revised Text: Superstructure (ptc/04-10-02) On page 709, replace the item: � typeConstraint : Classifier[0..1] Optional specification of the type of the value. with: No additional associations. On page 710, replace the phrase: the name of the parameter is used instead of any symbol with the phrase: the name of the parameter is used where any symbol
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8595: Section: 18.1.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Requirement 4 - delete the "of" immediately preceding the word "specializations." - Requirement 9 - Change the word "constraint" to "constrain."

Resolution:
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In Profiles: 18.1.2, requirement 4 Change � (or any of specializations of � into � (or any specializations of � Editor�s note: fixed in formal copy edit In Profiles: 18.1.2, requirement 9 Change � should therefore not constraint � into � should therefore not constrain � Editor�s note: fixed in formal copy edit
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Issue 8596: Section: 18.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The definition of the attribute indicated that multiplicity may be [0..1], yet this is not supported by fig. 446 no by the association ownedEnd:ExtensionEnd[1]. Further, fig 446 does not indicate that the association ownedEnd:ExtensionEnd[1] redefines Association::ownedEnd. Additional Operations [3] says that a lower bound of 1 makes isRequired true, but the statement discussing attributes implies that the lower bound = upper bound. Shouldn't the Additional Operation [3] also indicate this? Notation in fig. 448 does not agree with the text description of the proper notation unless the notation for a MOF model is different than for UML in which case the text should explain that fig. 448 is not a UML notated diagram.

Resolution: see above
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In Figure 446, add to the ownedEnd role to ExtensionEnd {subsets ownedEnd} In 18.3.2 Profiles:Extension Associations, add to the ownedEnd description: Subsets Association::ownedEnd. In 18.3.2 Profiles:Extension Attribute, isRequired Replace "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd" In 18.3.2 Extension, Semantics, 3 rd paragraph Add, before "The MOF construct equivalent �" Interface is in this picture an instance of CMOF::Class and Home is an instance of CMOF::Stereotype.
Actions taken:
March 17, 2005: received issue
August 23, 2006: closed issue

Discussion:

I don't see why << the statement discussing attributes implies that the lower bound =
upper bound>>, may be it this has gone since.
Figure 448 is a perfectly viable UML or MOF diagram, explained in the semantics
before.

Issue 8598: Section: 18.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - remove the extra slash below line between Class and Extension in fig. 446

Resolution:
Revised Text:
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

The '/' indicates that the Association is derived so there is no reason to remove it. This is
official notation for a derived Assoaiction (see 2nd bullet on p39).
Disposition: Closed, no change

Issue 8599: Section: 18.3.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The derived attribute isRequired default multiplicity is not supported by fig. 446. Please verify all mutliplicities between fig 446 and text for this concept agree. The association ownedEnd:ExtensionEnd[1] does not show that it redefines ownedEnd in the fig.446. Statement under attributes implies that the lower and upper bound must = 1 but Additional Operations [3] does not suppport this. Fig. 448 notation does not agree with text. If MOF notation is different, then clarify.

Resolution: See issue 8453 for disposition
Revised Text:
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8600: Section: 18.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Typo - 3rd sent, 2nd para under Description, change "changed" to "change." Association type:Stereotype[1] does not show the redefines statement in fig. 446. Additional Operations [1] "which was 1" statement does not agree with the last statement under Description. Fig. 446 shows a directional arrow from ExtensionEnd to Stereotype. This disagrees with first sentence of paragraph 2 of Description.

Resolution: There is no disagreement with first sentence of paragraph 2 of Description.
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.3.3 ExtensionEnd: description, 2d paragraph Change � is not allowed to changed � into � is not allowed to change � Editor�s note: fixed in formal copy edit Profile : Fig 446 Add to the type -> Stereotype role : {redefines type} In ExtensionEnd, Association, type Add redefines TypedElement::type. In ExtensionEnd, Additional operations [1] Replace ", which was 1" By which normally, for MultiplicityElements, evaluates to 1 if empty.
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8601: Section: 18.3.6 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

ypos - Opening "(" dont agree with ")" for either constraint. Clarify the illustration of the first approach (examples in Fig. 450 and 451). It is still confusing. Typo - Under "Using XMI to exchange Profiles" last sentence of first para on pg 724, change "purpose" to "purposes." Last sentence on pg 726, change "and need to be...." to "and these constraints need to be..."

Resolution: It is unclear what approaches are being referred to in the second sentence. There are no figures 450 and 451.
Revised Text: In section 18.3.6, Constraints, change: [1] An element imported as a metaclassReference is not specialized or generalized in a Profile. self.metaclassReference.importedElement-> select(c | c.oclIsKindOf(Classifier) and (c.generalization.namespace = self or (c.specialization.namespace = self) )->isEmpty() [2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel. self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())-> union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty() To: [1] An element imported as a metaclassReference is not specialized or generalized in a Profile. self.metaclassReference.importedElement-> select(c | c.oclIsKindOf(Classifier) and (c.generalization.namespace = self) or (c.specialization.namespace = self) )->isEmpty() [2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel. self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()-> union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty() In the last sentence of the paragraph under figure 18.10, section 18.3.5, change: and need to be To and these constraints need to be
Actions taken:
March 18, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8602: Section: 18.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - under Associations change "is" to "are."

Resolution:
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.3.7 ProfileApplication:Associations Change � that is applied � to � that are applied �
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8603: Section: 18.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add OCL notation or a note that OCL notation is not available to Constraint [2]. Typo - Change "stereotypes is shown" to "stereotypes are shown" in 3rd line of 2nd para of Notation. - Change 3rd sent of 1st para below bullets under Icon presentation to "Some tools may use different images for the icon replacing the box." In fig. 447 lower case stereotypes "clock" and "creator, clock" to agree with naming convention and figs. 461 & 462. In para immediately following fig. 457, I believe the statement should be: "Note that the extensionEnd must be composite, and that the derived "isRequired" attribute in this case is false. Fig. 458 needs the derived slash infront of the isRequired attribute for :Extension. Typos - Lower case the stereostype name "clock" in sentence immediately fololowing fig. 458, immediately preceding fig. 460 and sentences preceding and following fig. 462. Lower case the stereotype name "creator" in the sentence following fig. 461.

Resolution: see above
Revised Text: Stereotypes are uppercased in the example, though the conventions is to lowercase them. But this is not an issue. Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.3.8 Stereotype, Constraints, on Constraint [2] Add OCL not available Editor�s note: the above change was not entered because it does not conform to the standard format (we leave such constraints empty) In Notation, 2d paragraph 3d line Change � Stereotypes is shown� to � Stereotypes are shown� Editor�s note: fixed in formal copy edit In Notation, "Icon presentation", 1 st paragraph under the bullets Change �Some tools may different images� to �Some tools may use different images� Editor�s note: fixed in formal copy edit In Stereotype, Examples, after fig 457 Change Note that the extension must be composite, and that the derived isRequired" attribute in this case is false To Note that the extensionEnd must be composite, and that the derived "isRequired" attribute in this case is false
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

Stereotypes are uppercased in the example, though the conventions is to lowercase them.
But this is not an issue.

Issue 8604: Section: 18.4 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Place a "." in the Reference cell for row Metaclass of table 23 and ProfileApplication of table 24

Resolution:
Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.4 Profile: diagrams Place a "." in the Reference cell for row Metaclass of table 23 and ProfileApplication of table 24 Editor�s note: fixed in formal copy edit
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8605: Section: 18 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

General comments - The format of the Generalizations statement is not the same as previous chapters. For sub-sections that are empty either delete them or change the wording to "None."

Resolution: See issue N/A for disposition
Revised Text:
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8606: Section: Appendix B (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - 2nd sent. of last para pg 745, rewrite as "...to indacate that it is a constructor..." - 3) under Notation Placement, delete the word "to." Check capitalization of keyword "buildcomponent" because pgs 771 and 777 spell it "buildComponent."

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) In table 1 on page 747, replace the word �buildcomponent� by the word �buildComponent�
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

The notion of a �constructor� is not a formal concept in UML. The recommended rewrite
is inappropriate.
Removing the words �used to� will not significantly change the readability of the spec �
not worth making the change.
Fix the spelling of buildComponent on page 747

Issue 8607: Section: Appendix B (02) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Table number does not fit with other tables in this Supersturcture and Appendixes. (Appendix C starts with Table 25.)

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) Change the table number of the UML Keywords from table 1 to table 25. Increase the number of all other tables following that (tables 25 through 34) by 1. Editor�s note: fixed in formal copy edit
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

Fix. It should be table 25 instead. Of course, this will change all the other table numbers
following it.

Issue 8608: Section: Appendix C Table 25 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Suggest that the column headings are found on each page of the table. Typos - In the description of <<focus>> capitalize the first "Auxiliary." - In the description of <<implementationClass>> capitalize the word "Class" when used following "Implementation" as indicated by the statement "The actual name of the stereotype is the same as the stereotype label except that the first letter of each is capitalized." (Assuming you meant the first letter of each word of each stereotype label.) - Ditto with "Model Library." - Ditto with "Type." - In the description of <<modelLibrary>> correct spelling of "inteded" to "intended."

Resolution: see page 405 of ptc/2006-04-01
Revised Text:
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8609: Section: Appendix C Table 26 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Column Description for <<realization>> Change spelling to <<implementationClass>> to agree with the spelling in <<type>>. It's unfortunate that the column Name breaks the stereotype label so that one can't tell if the stereotype lable is one or two words. - Description for <<specification>> change to "...such as attributes and methods which are useful..." Place column headings on all pages.

Resolution: see above
Revised Text: Superstructure (ptc/04-10-02) (1) Change the spelling of �implementation class� in the description for the �realization� entry in table 26 on page 757 to �implementationClass�. (2) Repeat the table heading row at the top of every page for all multi-page tables in the appendices. Editor�s note: Both of these were fixed in the formal copy edit
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

Agree to all recommended fixes. Can�t do much about the label being broken up across
two lines other than make the table horizontal, which will introduce other readability
problems. This is the only entry with the problem.

Issue 8610: Section: Appendix C Table 27 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Description column for <<systemModel>> Capitalize SystemModel when using the stereotype name. Is the description for <<metamodel>> worded correctly?

Resolution: agreed - fix
Revised Text: (1) In table 27 on page 759 in the description for the systemModel entry replace the word �systemModel� by the word �SystemModel�. (2) In table 27 on page 759, in the description for metamodel replace the sentence: A model of a model, that typically contains containing metaclasses. with the sentence: A model that specifies the modeling concepts for some modeling language (e.g., a MOF model).
Actions taken:
March 18, 2005: received issue
August 23, 2006: closed issue

Issue 8611: Section: 15.3.8 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Constraints 9 and 10 exclude composite states from using entry or exit points. Entry/exit points are allowed on composite states as mentioned on page 592 (see Issue 6075).

Resolution: Remove constraints [9] and [10] as entry/exit point are essentially allowed on any region.
Revised Text: Remove constraints [9] and [10] in page 591 alltogether
Actions taken:
March 19, 2005: received issue
August 23, 2006: closed issue

Issue 8612: Section: 15.3.8 (second issue) (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

"Entry actions of states entered on the path to the state represented by a deep history are performed." It's open which path is taken if there are more than one paths to the state.

Resolution: The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the innermost active states being reactivated (almost as though a transition is drawn directly from H* to the last active state). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)
Revised Text: Replace the text on page 550 in the definition of deep history from: Entry actions of states entered on the path to the state represented by a deep history are performed. To: Entry actions of states entered on the implicit direct path from the deep history to the innermost state(s) represented by a deep history are performed. The entry action is preformed only once for each state in the active state configuration being restored.
Actions taken:
March 19, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8613: Section: D.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

EJBService has incorrect stereotype name shown inside guillemets. In description for EJBBusiness, change "level methods" to "level method."

Resolution: agreed - fix
Revised Text: Superstructure (ptc/04-10-02) (1) in the stereotype entry for EJBService in table 29 on page 761, replace the word between guillemets �EJBRemote� with the word �EJBService�. (2) in the description for the EJBBusiness entry in table 29 on page 761 replace the phrase: instance-level methods that supports the buisness logic with the phrase: instance-level method that supports the business logic Editor�s note: the latter item was fixed in the formal copy edit
Actions taken:
March 21, 2005: received issue
August 23, 2006: closed issue

Issue 8614: Section: D.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Correct spelling of "oferred" in Description of COMInterface. Complete cells (Parent, Tage, and Constraints) for COMTLB

Resolution: agreed - fix
Revised Text: (1) In table 30 on page 762, in the entry for COMInterface, replace the word �oferred� by the word �offered�. Editor�s note: the above was fixed in the formal copy edit (2) In table 30 on page 762, in the entry for COMTLB, enter the string �N/A� in the Parent, Tags, and Constraints columns.
Actions taken:
March 21, 2005: received issue
August 23, 2006: closed issue

Issue 8615: Section: D.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Correct spelling of "oferred" to "offered" in Description of NETProperty. The Description of NETAssembly is an incomplete sentence that doesn't make a lot of sense. Rewrite

Resolution: agreed- fix
Revised Text: Superstructure (ptc/04-10-02) (1) In table 31 on page 762, in the entry for NETProperty, replace the word �oferred� by the word �offered�. (2) In table 31 on page 763, in the entry for NETAssembly, replace the entire current description with the following sentence: Indicates a .NET assembly, which is a runtime packaging entity for components and other type definitions. Editor�s note: fixed in the formal copy edit
Actions taken:
March 21, 2005: received issue
August 23, 2006: closed issue

Issue 8617: Section: E.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - Remove the extra space beginning the paragraphs of #4, 6, 9, 10, 11, 12, and 14. There is also an extra space in #10 in "sequence /communication."

Resolution: see page 412 of ptc/2006-04-01
Revised Text:
Actions taken:
March 21, 2005: received issue
August 23, 2006: closed issue

Issue 8619: Section: Appendix F (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The following classifiers show no inheritance hierarchy because the link (inheritance arrow) is missing: Classifier (from Templates), Classifier (from PowerTypes), Interface (from Communications), BehavioredClassifier (from Interfaces), Behavior (from CompleteActivities), Activity (from BasicActivities), Activity (from StructuredActivities), and Activity (from CompleteActivity). In addition, Classifier (from UseCases) and Classifier (from Dependencies) are just kind of sitting there without showing any inheritance. It is strange to see classifiers on a diagram with no relationships expressed.

Resolution: see above
Revised Text: Add the following to the end of the first (and only) paragraph in Appendix F The �classes� in this diagram that do not have superclasses are actually merge increments. Their superclasses can be inferred from any increment that actually has a superclass. Putting those in the diagram would not add any information but would simply clutter the diagram.
Actions taken:
March 21, 2005: received issue
August 23, 2006: closed issue

Discussion:

First of all, this diagram is just a convenience diagram that superimposes fragments from
a variety of other diagrams in the spec.
The �classes� in this diagram that do not have superclasses are actually merge
increments. Their superclasses can be inferred from any increment that actually has a
superclass. Putting those in the diagram would not add any information but would simply
clutter the diagram. It may be that the submitter is unaware of the package merge
mechanism, since the spec is full of diagrams that show such merge increments.

Issue 8668: UML 2 Super / Activities / missing subsets (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Activity::node, Activity::edge, and Activity::group do not subset Namespace::ownedMember, but  they should

Resolution:
Revised Text:
Actions taken:
April 26, 2010: closed issue

Discussion:

If activity nodes, edges and groups where owned members of an activity, then they would all be required to have names, and these names could be distinct. The default for distinguishability could be overridden for nodes, edges and groups, but then what would the purpose be for having them be owned members in the first place. Just because something is a named element in UML does not mean it has to be a member of a namespace.
Revised Text:
None
Disposition:	Closed, no change

Issue 8670: Section: 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

there should be a consistent convention as whether unused Paragraphs must be omitted or filled with ``None''. We suggest the first, and thus to delete the Paragraphs pp.110, 163, 216, 217, 220-262, 280, 285, 298, 301, 304, 311-320, 323, 331, etc.

Resolution: See issue 8155 for disposition
Revised Text:
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Issue 8671: Section 12 (02) (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

A section ``Use'' containing methodological indications about the use of the construct should be added. Currently, such remarks are randomly spread into ``Description'', ``Semantics'', etc.

Resolution: Discussion: UML is methodology independent; there should not be any methodological advice in the spec at all. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
April 5, 2005: received issue
October 27, 2008: closed issue

Issue 8672: Section 12 (03) (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

``Result pin'', ``Output pin'' or even ``Result output pin'' seem used interchangeably throughout the text. Replace by ``Output pin''.

Resolution:
Revised Text:
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

Cannot find the wording �result output pin� in chapter 12. The wording result pin is used.
A result pin is a special output pin, e.g. CallBehaviorAction has a property result of type
OutputPin. Therefore it is useful to use the term to stress the different usages of output
pins.
Disposition: Closed, no change

Issue 8673: Figure 179 (Control nodes) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 179 (Control nodes) is not a complete partition of ControlNode: ForkNode, JoinNode, etc. are missing.

Resolution: Resolution: This was resolved by the resolution to issue 7319 (during the UML 2.0 FTF), which added the FundamentalActivities package and resulted in changes to related diagrams. Revised Text: None Disposition: Duplicate
Revised Text:
Actions taken:
March 30, 2005:
April 5, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8674: text p.297 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The text p.297: [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. contains, I believe, the problems: 1. Flows need not be connected by input pins, so ``inputs'' must replace ``input pins''. 2. The current text implies that all offered tokens are consumed when an action starts, which is not intended, we believe (specially if two offers are incompatible). 3. ``precluding them from being consumed by any other actions'' does not belong here. We suggest: To start, the action must have at least one token per input. When starting, it accepts simultaneously exactly one token per input, then creates an action execution.

Resolution: see above
Revised Text: In Activities, Action, Semantics, item [1], third sentence, insert "object" before "flow".
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

Problem 1 is addressed in the resolution below. The sentence referred to in Problem 2
does not say that all offered tokens are consumed. More details of action execution are in
Activity:Parameter, as indicated at the end of the bulletted list. The phrase beginning
"precluding" in problem 3 is included to clarify the meaning and purpose of the execution
rule. The suggestion that exactly one token is taken per input is not true when the pin
mulitplicity maximum is greater than one, as explained in InputPin and OutputPin in
Actions chapter.

Issue 8675: Output tokens (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In: [4] The output tokens are now available Replace ``available'' by ``offered''

Resolution:
Revised Text:
Actions taken:
April 5, 2005: received issue
April 5, 2005: closed issue, duplicate of 8676

Issue 8676: output tokens (02) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In, e.g.: [4] The output tokens are now available Replace ``available'' by ``offered''. Also p.310, p.330, p.342, etc.

Resolution:
Revised Text:
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

It seems that the submitter refers to p. 337 instead of 297:
[4] When completed, an action execution offers object tokens on all its output pins and control
tokens on all its outgoing control edges (implicit fork), and it terminates. Exceptions to this are
listed below. The output tokens are now available to satisfy the control or object flow prerequisites
for other action executions.
The proposed rewording is just another verbalism and doesn�t introduce any important information.
There is no wording ��tokens are now available�� or similar on p. 310, 330, and 342.
Disposition: Closed, no change

Issue 8677: token movement (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The verbs ``flow'', ``pass'', ``traverse'' seem used interchangeably to describe token movement. I suggest to reserve ``flow'' for a complex path (So e.g. p.309 should be: ``Activity edges are directed connections, that is, they have a source and a target, along which tokens may {\bf pass}). , ``pass'' for an elementary move, and to replace ``traverse'' by ``pass''. (p.303, 304, 309, 310, etc.)

Resolution:
Revised Text: In Activities, Activity, Semantics, eighth paragraph (the one starting �Nodes and edges have token flow rules.�), before the seventh sentence (the one beginning �Since multiple edges�), add a new sentence: For brevity, the specification uses the terms "flow", "pass", "traverse" interchangeably in relation to tokens to mean offering tokens, and movement of tokens when offers are accepted..�.
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

The issue does not define "complex path". If this means a path of edges that has more
than two nodes, the issue does not explain benefit of distinguishing this case.

Issue 8678: UML 2 -- Need explanations of XMI structure and usage (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Appendix G is intended to contain the XMI for UML. However, there is no explanation of the meaning of its various parts, or its structure, or how it is to be used. This information should be included in the introduction to the XMI appendix in both the Infrastructure (Appendix A) and the Superstructure (Appendix G).

Resolution: see above
Revised Text: In Annex G, replace: UML 2.0 models are serialized in XMI 2.0 according to the rules specified by the proposed MOF 2.0 XMI specification (OMG document ad/2002-12-07). The XML schema for MOF 2.0 models that support the MOF 2.0 XMI specification is available in OMG document ad/2002-12-09. The XMI for serializing the UML 2.0 Superstructure as an instance of MOF 2.0 according to the rules specified by the proposed MOF2 XMI specification (available in OMG document ad/2003- 04-04). It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architecturally align and finalize the relevant specifications. with the following: UML 2.1 Superstructure models are serialized in XMI 2.1 according to the rules specified by the MOF 2.0/XMI Mapping Specification, v2.1 (OMG document formal/05-09-01). The XMI schema document for MOF 2.0 models that support the MOF 2.0 XMI specification is available in OMG document ad/05-05-12. As is common policy for OMG, the normative representation of MOF 2 and UML 2 models is an XMI file since this provides the level of complete and processable definition that is not always possible or practical across a set of diagrams. These XMI documents are all CMOF documents since all the MOF 2 and UML 2 metamodels are described using CMOF. The normative XMI document for Superstructure consists of a single XMI document that contains all of the packages described in the Superstructure specification organized the same as the specification. According to the UML 2 specification and the definition of PackageMerge semantics, XMI files containing package merges are semantically equivalent to the same XMI files with the package merges merged away. The UML 2 Superstructure normative model is expressed in this annex as an unmerged XMI document matching the rest of the specification. It is assumed that this XMI document will primarily be used to specify the normative packages and their contents, and will generally be used by tool vendors wishing to implement package merge and create either UML 2 compliance levels, or extensions thereof. The unmerged CMOF XMI document for UML is provided in OMG document ptc/06-01-04. The non-normative merged XMI documents for each compliance level are identified in Annex H. These documents will be useful for tool vendors wishing to validate instances of UML2 models for specific compliance levels against the XMI defining the contents of that compliance level. Add Annex H: UML2 Compliance Level XMI Documents The normative XMI document for UML2 Superstructure is given in Annex G. However, there are also non-normative convenience documents that will be quite useful to tool vendors. Consider compliance level L2. XMI documents that are representations of L2 UML2 models could be UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8678 Document ptc/06-01-01 Page 404 validated against the normative unmerged metamodel document which includes the packages for L2 (as well as the others). But these XMI documents have to be instances of the merged L2 metamodel and, since it is derived from the package merge rules, there is not a normative XMI file for this. To facilitate interoperability, and to eliminate the need for tool vendors to implement package merge in order to produce XMI metamodel documents for the UML2 compliance levels, the XMI documents for each compliance level are included in this annex. An XMI document for a compliance level is the XMI representation of the merged CMOF metamodel for that compliance level. XML uses XSD to validate instances of XML documents, and the MOF 2.0/XMI Mapping Specification, v2.1 specifies how these schema documents are derived for a given CMOF model. However, XSD cannot capture all of the structure, constraints, or semantics of a UML2 compliance level, so vendors may choose to use MOF reflection or XMI metamodel documents to provide more complete validation. The following convenience specifications are related to the UML2 Superstructure and are included in document ptc/06-01-04: � L0.cmof � LM.cmof � L1.cmof � L2.cmof � L3.cmof
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

XMI Serialization and Schema is no longer an Appendix in order to indicate it is a
normative section of the UML2 Superstructure specification.

Issue 8679: token (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"All tokens offered on the incoming edges are accepted." 1- The edges of of the terminated Activity or of the Activity Final Node? 2- In general, it is not possible to accept all tokens offered. For instance, a same token in an ObjectNode could cause two token offers throughtwo forks. Yet, only one of these offered tokens can be accepted, causing the other to be no longer offered. I suggest to delete this sentence.

Resolution: see above
Revised Text: In Activities, Semantics, eighth paragraph (the one starting �Nodes and edges have token flow rules.�), seventh sentence (eighth after resolution of issue 8677, the one beginning �Since multiple edges�), replace �node, token� with �node, the same token can be offered to multiple targets. However, a token can only be accepted at one target. This means�.
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

A token can be offered to multiple targets, but only accepts at one, as in Petri nets. This
is the why the Semantics section of Activities emphasizes the distributed and possibly
contentious aspects of the token movement rules. Added clarification to this paragraph
below.

Issue 8680: Section: 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Any object nodes declared as outputs are passed out of the containing activity." Only tokens can be passed, not nodes. I suggest: "The last token from each output Activity Parameter Node is offered on the corresponding output of the calling action."

Resolution:
Revised Text: In Activities, ActivityFinalNode, Semantics, sixth sentence (the one beginning �Any object nodes declared�), replace �Any object nodes declared as outputs� with �The content of output activity parameter nodes�.
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Issue 8681: add the rule of ``natural termination'' (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

I suggest to add the rule of ``natural termination'': An activity terminates when it has a token in each of its output Activity Parameter Nodes. This removes the need for Activity Final Nodes in most cases, and makes UML less error-prone, since it is an error to terminate without a token in each output Activity Parameter Node. It also makes the languages more consistent, since this rule is used for loops.

Resolution: see above
Revised Text: Section 12.3.4, Semantics, 6 th paragraph, starting with �Regardless�, at end of paragraph, add sentence: �See Parameter in Activities for more about how activities start and stop execution.�. Editor�s note: added full cross reference with hyperlink to above
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is already described in Activity:Parameter. The revision below gives forward
reference from Activity.

Issue 8683: ``conditional node or conditional node'' delete one. (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

``conditional node or conditional node'' delete one.

Resolution:
Revised Text: In Activities, Clause, Associations (CompleteStructuredActivities), entry for bodyOutput, remove �or conditional node�.
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

Issue 8685: Delete sentence (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

" One frequent case is a total ordering of clauses, in which case the result is determinate." The clauses themselves can be nondeterministic, making this sentence false (although the idea is clear). Delete.

Resolution: see above
Revised Text: In Activities, Section 12.3.17, Description, on p. 381, 2 nd paragraph, 4th sentence, replace �result� with: �clause execution order�. Editor�s note: should be a reference to 12.3.18 (not 12.3.17) Disposition: Resolved
Actions taken:
April 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

The cited sentence is referring to the order of the clause evaluation, not the execution
within each clause.

Issue 8687: rewording isuse? (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"When an execution of an activity makes a token available to the input of an expansion region, the expansion region consumes the token and begins execution." ``the input'' is ill-defined, since an expansion region has several inputs, see Examples in the same subsection. It should read: "When an execution of an activity makes a token available to each of the inputs of an expansion region (implicit join), the expansion region consumes these tokens and begins execution."

Resolution: Resolution: This should be merged with Issue 8725. Revised Text: None Disposition: Duplicate/merged
Revised Text:
Actions taken:
April 5, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8688: UML 2 Different constraints for Property in Super and Infra (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The Infrastructure has an additional constraint on Constructs::Property (pg. 128): 

   [2] A specialization of a composite aggregation is also a composite aggregation. 

that does not exist in the Superstructure. These two should be made consistent; either the constraint appears in both places or in neither.

Resolution: It appears a sentence was removed from superstructure but not InfrastructureLibarary. Revised Text: In section 11.3.5, subsection Constraints, change: [2] A specialization of a composite aggregation is also a composite aggregation.A multiplicity of a composite aggregation must not have an upper bound greater than 1. To: [2] A multiplicity of a composite aggregation must not have an upper bound greater than 1.
Revised Text:
Actions taken:
April 5, 2005: received issue
April 25, 2011: closed issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8689: editorial in section 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"... is eligible for execution when it receives control tokens from each of its predecessor clauses. " Should read ``a control token''

Resolution:
Revised Text:
Actions taken:
April 5, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

While this would be consistent, it does not seem important enough to make a change that could cause compatibility problems with UML 2.2.
Revised Text:	
None.
Disposition:	Closed, no change

Issue 8690: Section: 12.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

In figure 195, p332, StructuredActivityNode and Action inherit from ExecutableNode. In figure 196, p333, StructuredActivityNode inherits from Action. => StructuredActivityNode inherits two times of Action. A priori, you could delte the inheritance link between StructuredActivityNode and ExeutableNode in figure 195

Resolution:
Revised Text:
Actions taken:
April 7, 2005: received issue
August 23, 2006: closed issue

Discussion:

The two figures are in separate packages, StructuredActivities and
CompleteStructuredActivties. In StructuredActivities, StructuredActivityNode is not
supposed to be an Action, in CompleteStructuredActivties it is.
Disposition: Closed, no change

Issue 8696: policy to describe the Associations sub section of a meta class description (uml2-rtf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:

what is the official policy to describe the Associations sub section of a meta class description (using EBNF style):
 
/?<end-name> : <associated-class-name> : <cardinality> (= <DefaultValue>)? <FeaturesList>? <tab> <Description>

where:

<end-name> ::= String

<associated-class-name> ::= String

<cardinality> ::= [<n>, <m>]

<DefaultValue> ::= String

<FeaturesList> ::= {<Features>}

<Features> ::= <FeatureKind>} | {<FeatureKind>, <Features>

<FeatureKind> ::= subsets <property-name> | redefined <end-name> | union | ordered | bag | sequence | readOnly | unrestricted

<property-name> ::= String

<n> ::= Integer

<m> ::= Integer | *      and m >= n

<tab> is a tabulation
 
ps: ? means it is optional part.

Resolution:
Revised Text:
Actions taken:
April 12, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is an editing question and I don�t think this level of detail should go into section
6.5.1.
The following is the recommended format:
[/] <name> �:� <type> [<cardinality>]
<tab> <text-description> [�The default value is� <value> �.�]
[�Subsets� <Metaclass> �::� <property> [�and� <Metaclass> �::� <property> ]* �.� ]
Disposition: Closed, no change

Issue 8698: CombinedFragment Loop notation (uml2-rtf)

Click here for this issue's archive.
Source: Advanced Concepts Center, LLC (Mr. James A. Schardt, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

There seems to be some confusion about how to show the notation for the loop combinedFragment. Some tools show only the minint and maxint for the loop InteractionOperator but do not allow you to show the full specification in the InteractionOperand. This is a limitation that allows for the modeling of simple for loops without an additional guard to model do while and do until types of loop constructs. I would suggest the UML Superstructure 2.0 be updated with the following:

In Section 14.3.3 in Notation with header Loop:  
Place a simple example of a loop combined fragment with a InteractionOperand guard as well as a minint and maxint 
Add a paragraph that says something like, "In those cases where more control over the number of passes through the CombinedFragment is necessary use a separate InteractionConstraint. This InteractionConstraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing Loop InteractionOperand. If this separate InteractionConstraint is true, the loop continues, otherwise the loop terminates."

Resolution:
Revised Text: see pages 48 - 49 fof ptc/2009-09-07 for details
Actions taken:
April 21, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8705: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Notation section of component states that the relationship between realizing classifiers and the component is displayed by general dependencies. The specialized Realization states that it's notation is similar to the realization dependency. Change fig. 85: Replace dependency arrows by realization arrows (with triangular arrowhead).

Resolution: see page 50 of ptc/2009-09-07 for details
Revised Text: Replace the sentence above 8.10 that reads: "The internal classifiers that realize the behavior of a component may be displayed by means of general dependencies." by: "The internal classifiers that realize the behavior of a component may be displayed using realization arrows." Replace 8.10 by this:
Actions taken:
April 28, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8706: Profile Semantics, pag 723 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

"A reference metamodel typically consists of metaclasses that are either
imported or locally owned. All metaclasses that
are extended by a profile have to be members of the same reference
metamodel. A tool can make use of the information
about which metaclasses are extended in different ways, for example to
filter or hide elements when a profile is applied, ..."


The specification must be explicit about the  mechanism used to hide/filter
reference metamodel elements. The SysML Partners are trying to do exactly
this with SysML but it's not clear from the above paragraph or any other
part of the Profiles section how to do it.

Resolution: see above
Revised Text: In the Superstructure [Infrastructure] document (1) In 18.3.6 [13.1.6] in the Semantics subsection of Profile Replace: A tool can make use of the information about which metaclasses are extended in different ways, for example to filter or hide elements when a profile is applied, or to provide specific tool bars that apply to certain profiles. However, elements of a package or model cannot be deleted simply through the application of a profile. Each profile thus provides a simple viewing mechanism. with: The "metaclassReference" and "metamodelReference" associations specify both the filtering rules that can be used on a reference metamodel when the profile is applied, and the reference metamodel imported for extension. By definition, only the model elements instances of the metaclasses designated by these associations shall be accessible (visible) when the profile is applied, the other metaclasses instances being filtered out. The visible elements are instances of the metaclasses equal to or owned by the most detailed namespaces designated by the referenced elements ("metaclassReference" and "metamodelReference" associations): only the referenced elements which owned elements are not referenced are filtered (shown) by the profile. The "metaclassReference" and "metamodelReference" have the elementImport and packageImport semantics. The combination of both semantics allows specifying metaclasses that are imported (and possibly extended), and specifying those imported metaclasses that are hidden and those that are filtered (visible). When a modelElement is extended by a stereotype, it is by definition always visible even if the filtering rules hide its metaclass. In the example Figure XXX, myProfile imports myMetamodel. Metaclass1 is hidden, and Metaclass2 is visible. The application of myProfile to a model instance of myMetamodel will show instances of Metaclass2, and instances of Metaclass1 only when they are extended by an instance of myStereotype. The most common case is when a profile has just a metamodelReference association to a package. This specifies that the package is imported to be extended, and that all its metaclasses are visible. myProfile myStereotype myMetamodel Metacl ass1 Metaclass2 ass2 Metacl Metaclass1 myStereotype <<stereotype>> <<reference>> <<reference>> <<profile>> myProfile Figure XXXX � Specification of the accessible metaclasses If a profile P1 imports another profile P2, then all metaclassReference and metamodelReference associations will be combined at the P2 level, and the filtering rules applies on this union. UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8706 Document ptc/06-01-01 Page 412 The filtering rules defined at the profile level are just a hint for modeling tools, while a profile is applied to a model. The "isStrict" attribute on a profileApplication specifies that the filtering rules have to be applied strictly. If isStrict is true on a ProfileApplication, then no other metaclasses than the accessible one defined by the profile shall be accessible when the profile is applied on a model. This prohibits the combination of applied profiles that specify different accessible metaclasses. In addition to these import and filtering mechanisms, the profile designer can select its appropriate metamodel by selecting the appropriate subpackages, and using the package merge mechanism. For example, he can build a specific reference metamodel by merging UML2 superstructure packages and classes, and or import packages from one of the UML2 compliance packages (L0-L4) Editor�s note: I made some minor changes to the above text to increase clarity of this complex text. (2) In 18.2 [13.1] in the Abstract Syntax diagram in Fig 446 [109], Add to attribute isStrict:Boolean to the "ProfileApplication" metaclass in the metamodel (3) In 18.3.7 [13.1.7] in the Attributes subsection of ProfileApplication Replace No additional attributes with � isStrict: Boolean = false Specifies that the Profile filtering rules for the metaclasses of the referenced metamodel shall be strictly applied. See Profile:semantics for further details. (4) In section 18.4 [-- there is no Infrastructure equivalent of this section] "Diagrams" Add to the Notation table (Table 23) the following row ElementImport, Packaged Import <<reference>> See metaclasReference & metamodelReference on 18.3.6 Profile:Association Editor�s note: a corresponding change is also required in appendix B Disposition: Resolved
Actions taken:
April 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

After a teleconference on this subject, it has been agreed that the best approach is to base
the filtering mechanism on the Import facility.
We agreed on two approaches to specifying a reference metamodel:
Creating a new metamodel by importing/merging UML2 superstructure
packages/elements;
Importing a set of packages/elements from an existing UML compliance level;
The latter has the benefit that it's easy to state at a gross level what compliance level a
tool needs in order to support the profile.
It was agreed that Philippe would document these approaches as part of his response to
the issue Alan raised on profiles.
We agreed to add a new attribute 'isStrict:boolean', which if true indicated that in the user
model which applied the profile, only those reference metamodel metaclasses explicitly
imported into the profile could be used.
Philippe will also document this new property as part of his response to the issue I raised
on profiles.

Issue 8718: In Activities, Figure 176, Action should be abstract (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

In Activities, Figure 176, Action should be abstract

Resolution:
Revised Text: In Activities, Figure 176, make Action abstract.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8719: Semantics for instances applies to InstanceSpecification? (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Semantics for instances applies to InstanceSpecification? Clarify whether the semantics for instances specified in other chapters applies to InstanceSpecification. For example, will deleting an InstanceSpecification delete other instances it owns by association composition?

Resolution: see above
Revised Text: In the Semantics sub-section of InstanceSpecification on page 84 of the Superstructure spec [bottom of page 66 of the Infrastructure spec] add the following paragraph as the third paragraph in that sub-section It is important to keep in mind that InstanceSpecification is a model element and should not be confused with the dynamic element that it is modeling. Therefore, one should not expect the dynamic semantics of InstanceSpecification model elements in a model repository to conform to the semantics of the dynamic elements that they represent.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

I interpret this question as asking about the extent to which M0 semantics are reproduced
at M1. Instances of InstanceSpecifications are M1 entities but they model M0 entities at
some phase of execution (often referred to as �snapshots�). In general, these are two
distinct contexts with different sets of rules. M1 models really conform to MOF
semantics and not to M0 semantics.

Issue 8720: String is primitive but has structure. (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

String is primitive but has structure. Section 17.4 (PrimitiveTypes) has String, even though the definition of primitive type in Section 7.3.43 excludes any structure: "A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

Resolution: see above
Revised Text: In the Superstructure spec: Change the description of PrimitiveType in section 7.3.43 from: A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. to: A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. In the Infrastructure spec: Change the description of PrimitiveType in section 11.6.5 from: A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. to: A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

The key is the term �relevant substructure� above. That is, a PrimitiveType has no
substructure in the context of UML2. The sequence of characters in a String is not
exposed in any way in the UML2 metamodel.

Issue 8721: Client/supplier on dependencies (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Client/supplier on dependencies should specialize source/target inherited from directed relationship

Resolution: Resolution: Duplicate of 6405. Revised Text: None. Disposition: Duplicate
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8723: Disjointness should be independent of generalization (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Disjointness is applicable to classes that are not specializations of the same class. It should be independent of generalization

Resolution: Same as issue 8014 Revised Text: N/A Disposition: Duplicate
Revised Text:
Actions taken:
May 1, 2005: received issue
October 27, 2008: closed issue

Discussion:

Issue 8724: DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

Resolution: An ObjectNode is not a MultiplicityElement, and, therefore, it can have no uniqueness constraint to reverse. (There actually is such a constraint given for ObjectNode, but this is an error that should be corrected. See Issue 8891.) Revised Text: None Disposition: Close, no change
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8726: Element to Constraint navigation (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Element to Constraint navigation. The "constrainedElement" association between Constraint and Element is unidirectional from Constraint to Element. That means implementations are not required to provide efficient navigation from an element to the constraints on it. Can't see how an API could do without this.

Resolution: This is a duplicate of issue 8020 Revised Text: N/A Disposition: Duplicate
Revised Text:
Actions taken:
May 1, 2005: received issue
October 27, 2008: closed issue

Issue 8727: The create stereotype on Usage dependency (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

The create stereotype on Usage dependency. The create stereotype on Usage dependency is defined in standard stereotypes (Table 25) and in retired stereotypes (Table 28). It is used in Figures 103 and 121.

Resolution: Discussion: This issue was resolved in an earlier revision. The �create� stereotype is now defined in the table in appendix C section C.1. Disposition: Closed, no change
Revised Text:
Actions taken:
May 1, 2005: received issue
October 27, 2008: closed issue

Issue 8728: Solid triange notation for Association (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Solid triange notation for Association. Association, Examples, shows a solid triangle notation that is not mentioned in the notation section. It says it indicates the order of reading, but association generally don't have an order or reading, the end names express the order of reading. I thought it showed the order of the association ends (Association.memberEnd is ordered), because there's no other notation for that.

Resolution:
Revised Text:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

On page 39 of the spec in the Notation subsection of Association, the following text can
be found:
On a binary association drawn as a solid line, a solid triangular arrowhead next to or in
place of the name of the association and pointing along the line in the direction of one
end indicates that end to be the last in the order of the ends of the association. The arrow
indicates that the association is to be read as associating the end away from the direction
of the arrow with the end to which the arrow is pointing (see Figure 19).
This seems to state quite clearly what the notation means and also the rule by which the
direction of the arrow is determined.
See also the resolution to issue 8066.
Disposition: Closed, no change

Issue 8729: Multiple exception handlers (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Multiple exception handlers. Clarify that one exception handler is executed if multiple match, and it is undefined which

Resolution:
Revised Text: In Activities, ExceptionHandler, Semantics, first paragraph, add sentence just before the last one: "If there are multiple matches, exactly one handler catches the exception, but it is not defined which does."
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8730: Exceptions thrown across synchronous invocations (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Exceptions thrown across synchronous invocations. Clarify that exceptions are thrown across synchronous invocations, not asynchronous ones. Or introduce an attribute to tell whether it is thrown across call boundaries.

Resolution: see above
Revised Text: In Activities, ExceptionHandler, Semantics, second paragraph, add new sentences: "If the exception is not caught there, and the action that invoked the activity is asynchronous, the exception is lost, because the connection to the invoker is broken. If the action that invoked the activity is synchronous, the exception propagates up to that action. The process of exception propagation recurs until the exception is caught, or reaches the topmost level of the system." Editor�s note: It is not clear where this text is to be inserted. Inserted after the first sentence.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

In the semantics of ExceptionHandler, second paragraph, the first sentence describes the
propagation of the exception from the action in which it was raised to the activity
containing the action, and the second sentence describes what happens when the
exception reaches the topmost level of the system. It is missing the steps in between,
namely the propagation from the first activity to the action that invoked it, and the
recursion to the top level of the system. The revision below describes that process.

Issue 8731: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

In LoopNode, SetupPart/bodyPart should be setup/body to be consistent with Clause

Resolution: Revised Text: This is covered in the resolution to Issue 8686. Disposition: Merged
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8732: In Figure 210, put merge before Use Part to merge the incoming flows (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

In Figure 210, put merge before Use Part to merge the incoming flows

Resolution: see page 431 of ptc/2006-04-01
Revised Text:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8733: LoopNode should move rather than copy values to/from loop variables (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

LoopNode should move rather than copy values to/from loop variables. Otherwise, tokens will be dangling tokens. Same for ConditionalNode bodyOutput, etc.

Resolution:
Revised Text: In Activities, Clause, Associations (CompleteStructuredActivities) Remove double parentheses from header "(CompleteStructuredActivities)" Editor�s note: fixed in formal copy edit In bodyOutput entry, replace "copied" with "moved". LoopNode, Associations (CompleteStructuredActivities) Remove double parentheses from header "(CompleteStructuredActivities)" Editor�s note: fixed in formal copy edit In loopVariable entry, second sentence, replace "copied" with "moved". In bodyOutput entry, replace "copied" with "moved". In loopVariableInput entry, replace "copied" with "moved".
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed isuse

Issue 8734: Clarify first constraint on InputPin and OutputPin, move "only" to before " (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Clarify first constraint on InputPin and OutputPin, move "only" to before "when".

Resolution:
Revised Text: In Activities, InputPin and OutputPin, first constraint in each, move �only� to before �when�.
Actions taken:
May 1, 2005: recerived issue
August 23, 2006: closed issue

Issue 8735: The Syle Guidelines for Stereotype (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

The Syle Guidelines for Stereotype says "The values of an applied stereotype are normally not shown." This is application-dependent. Sentence should be removed

Resolution:
Revised Text: In 18.3.8, Stereotype, Style Guide. Delete The values of an applied stereotype are normally not shown. Editor�s note: The resolution does not mention it, but the same change should also be made in the Infrastructure in section 13.1.8
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8736: Actions, CallBehaviorAction, third sentence, (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Actions, CallBehaviorAction, third sentence, should be limited to synchronous calls

Resolution:
Revised Text: In section 11.3.9: Replace third sentence: The execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. with: For synchronous calls the execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. The action completes immediately without a result, if the call is asynchronous.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8737: ControlFlow (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

ControlFlow should say that if it targets an action, or control pin of action, then the action requires a control token to start executing

Resolution:
Revised Text:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is already stated in bullet [1] of the Semantics of Activities:Action, and in the
Semantics of Pin.
Disposition: Closed, no change

Issue 8738: StructuredActivityNode, Semantics, third paragraph, first sentence, (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

StructuredActivityNode, Semantics, third paragraph, first sentence, clarify that "attached" means input pin, output, or expansion nodes

Resolution: Resolution: The wording of this sentence has already been changed by the resolution to Issue 9855 to refer specifically to pins on a structured activity node. Expansion nodes only apply to expansion regions and are covered in that section. Revised Text: None. Disposition: Duplicate
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8739: ExpansionRegion (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

ExpansionRegion, clarify that tokens in input pins and expansion nodes are destroyed when the expansion node completes

Resolution:
Revised Text:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

In Activities, ExceptionRegion, Semantics, at end of section, add sentence in new
paragraph: "When expansion region is complete, tokens in input expansion node and pins
are removed."

Issue 8740: ConditionalNode and LoopNode test and bodies should be ExecutableNodes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

ConditionalNode and LoopNode test and bodies should be ExecutableNodes

Resolution:
Revised Text: In Activities, Figure 195, replace the two ActivityNode's at the bottom (the ones that are the test and body of Clause, and setupPart, bodyPart, and test of LoopNode) with ExecutableNode. Clause, Associations (StructuredActivities), in test and body entries, replace ActivityNode with ExecutableNode. Editor�s note: Changes made to two entries in Clause and three entries in LoopNode
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8741: In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirectional. What happens when these are merged in Figure 98?

Resolution: see pages 21 - 22 of ptc/2011-01-19
Revised Text:
Actions taken:
May 1, 2005: received issue
April 25, 2011: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8742: represents and occurrence keywords are switched (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

CollaborationUse, Presentation Options, first paragraph, the represents and occurrence keywords are switched

Resolution: This does not appear in 2.2. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8743: Clarify which classifier or operation this is referring to (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

CollaborationUse, Constraint 2: Clarify which classifier or operation this is referring to.

Resolution: There are several places in chapter 9 where the text refers to the possibility of a CollaborationUse being associated with an Operation. But there is nothing in the metamodel to support this. This issue is resolved by removing these statements from the text, and by clarifying the offending constraint. In 9.3.3, there is a paragraph that reads as follows: "A collaboration may be attached to an operation or a classifier through a CollaborationUse. A collaboration used in this way describes how this operation or this classifier is realized by a set of cooperating instances. The connectors defined within the collaboration specify links between the instances when they perform the behavior specified in the classifier. The collaboration specifies the context in which behavior is performed. Such a collaboration may constrain the set of valid interactions that may occur between the instances that are connected by a link." The placement of this paragraph is peculiar, because it appears under Collaboration, not CollaborationUse. The first two sentences of this paragraph are false, because they talk about attaching a CollaborationUse to an operation. The remainder of the paragraph appears to add no value to what has been already stated in the semantics of Collaboration. I propose to delete this paragraph.
Revised Text: Delete the paragraph in 9.3.3 that starts "A collaboration may be attached to an operation or a classifier through a CollaborationUse." Replace the text describing roleBinding, currently: "A mapping between features of the collaboration type and features of the classifier or operation. This mapping indicates which connectable element of the classifier or operation plays which role(s) in the collaboration. A connectable element may be bound to multiple roles in the same collaboration use (that is, it may play multiple roles)." By: "A mapping between features of the collaboration type and features of the owning classifier. This mapping indicates which connectable element of the classifier plays which role(s) in the collaboration. A connectable element may be bound to multiple roles in the same collaboration use (that is, it may play multiple roles)." Replace the second constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. by: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the owning classifier. Replace the first paragraph of CollaborationUse.Semantics, currently: "A collaboration use relates a feature in its collaboration type to a connectable element in the classifier or operation that owns the collaboration use." by: "A collaboration use relates a feature in its collaboration type to a connectable element in the classifier that owns the collaboration use."
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8744: CollaborationUse: Constraint 1, (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

CollaborationUse: Constraint 1, allows parameters from different operations to be coordinated. Is that intended?

Resolution: Discussion: This issue appears to refer to an earlier version of the specification. It is impossible to identify in the current version what this issue concerns. Disposition: Closed, no change
Revised Text:
Actions taken:
May 1, 2005: received issue
October 27, 2008: closed issue

Issue 8745: Section: Interactions (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Messages to self. Are curved arrows in interactions (sending to self) still supported in UML 2? See Figure 3-56 in UML 1.5 (doc.omg/org/formal/03-03-01). If not, how are messages to self shown?

Resolution: see above
Revised Text: Before (14.3.20 page 540) A message is shown as a line from the sender message end to the receiver message end. The form of the line or arrowhead reflect properties of the message: Revised text: A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Nothing in UML 2 prohibits sending a message to self. Implicitly such a situation is
regulated by the first constraint of Message. However, there are no examples, and it is not
explained in detail how the �line� depicting a Message may look. Messages to self will
probably be less frequent in UML 2 than in UML 1 since UML 2 sequence diagrams may
also have Actions on the lifeline. Such situations were often modeled as a message to self
in UML1.

Issue 8746: Clarify caption of Figure 56 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Clarify caption of Figure 56. The wording of caption of Figure 56 gives the impression that it is a general notation to provided/required interfaces, especially because it is in the Presentation Option section. Discussion during FTF was that this is only an example, rather than a general notation.

Resolution: see above
Revised Text: On page 89, replace the following paragraph just above figure 56: A set of interfaces constituting a protocol may be depicted as interfaces with associations between them (see Figure 56). with It is often the case in practice that two or more interfaces are mutually coupled through application-specific dependencies. In such situations, each interface represents a specific role in a multi-party �protocol�. These types of protocol role couplings can be captured by associations between interfaces as shown in the example in Figure 56.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Discussion:

Actually, this is a general method for denoting mutually dependent interfaces, although I
think a bit more clarification is needed so that this method is not confused with the
methods for specifying provided and required interfaces.

Issue 8747: Notation for connector end multiplicities. (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Notation for connector end multiplicities. Notation of ConnectorEnd, first paragraph says the multiplicities shown are the association multiplicities. What about the connector end multiplicities?

Resolution: Discussion: This issue has been fixed in the current version of the specification. Disposition: Closed, no change
Revised Text:
Actions taken:
May 1, 2005: received issue
October 27, 2008: closed issue

Issue 8749: ParameterSet, first line: "inputs or outputs". (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

ParameterSet, first line: "inputs *or* outputs".

Resolution:
Revised Text: In Activities, ParameterSet, first line, replace �inputs and outputs� with �inputs or outputs�.
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8750: External exceptions. (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. James Rumbaugh, rumbaugh(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

External exceptions. We need an interrupt message that asynchonously causes an exception for some other process/object. In examining real-world examples at IBM, I find we need that concept. And we need interrupts that allow the target process to clean itself up, not just die. This occurs in lots of real problems

Resolution: This can already be handled, at least for an asynchronously executing activity or state machine, by sending a signal to the behavior. A concurrent part of the activity or state machine can then receive the signal and interrupt the ongoing behavior, transitioning, if necessary, to some clean up behavior before terminating. In an activity this can be done using an interruptible region. In a state machine it can be used with a orthogonal region. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
May 1, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8752: Last element in transition BNF (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Last element in transition BNF should be <behavior-expression> instead of <activity-expression>. The term is used on the next side.

Resolution: Update as suggested.
Revised Text: Page 628: Replace BNF for transition notation: �<transition> ::= <trigger> [�,� <trigger>]* [�[� <guard-constraint>�]�] [�/� <activity-expression>]� With: �<transition> ::= <trigger> [�,� <trigger>]* [�[� <guard-constraint>�]�] [�/� <behavior-expression>]�
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8753: Page: 591 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

The semantics section describes that the transition from an initial pseudostate may have an action. There should be a constraint in the constraints section that actions are allowed, but no triggers and guards. Instead of action it should be named behavior.

Resolution: see page 442 of ptc/2006-04-01
Revised Text:
Actions taken:
May 1, 2005: received issue
August 23, 2006: closed issue

Issue 8759: OpaqueAction (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter 11.3.26 OpaqueAction is described as subclass of Pin. It 
> should be subclass of Action. 

That's a bug. Please raise an issue. 

> Can OpaqueAction be used as default Action type in Activity diagrams
> and be as replacement of old-style user defined ActionStates in UML 1.4? 

It sounds like you are asking for a new feature. I don't see that the RTF will accept this default. You can always do this woth a profile.

Resolution: see above
Revised Text: In OpaqueAction, Generalizations, replace "Pin" with "Action". Editor�s note: already fixed in 8171
Actions taken:
May 3, 2005: received issue
August 23, 2006: closed issue

Discussion:

None of the UML diagrams have a default element. Tools can adopt this convention as
needed

Issue 8760: Events in Sequence diagram (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

 MessageEnd are MessageOccurrenceSpecification that redefines "event"
> as MessageEvent. 
> DestructionEvent and CreationEvent are not subclasses of 
> MessageEvent, so can't be on message end, so how to map "create 
> message" and "destroy message"? 

This is an open item. The one thing that was highly contested in the FTF was that there be explicit create and destroy messages. So, they are no longer in MessageKind. 

> Also unclear how to map Reply 
> message, what kind of events should be in reply message ends? 

You should check with Oystein. 

> Events are owned by package, it's very uncomfortable (at least two 
> nesting levels from Interaction), it think they should be owned by 
> Interaction. 

No, because the whole idea of events is that they have to be shared by the sender's and reciever's behaviors. It makes little sense to define them in an Interaction.

Resolution: See issue 14629 for disposition
Revised Text:
Actions taken:
May 3, 2005: received issue
April 25, 2011: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8766: Section: 12.3.37 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Significant
Summary:

It's a common modeling scenario that an object flow with an outpin pin at the source must target an action directly (without a pin). For example a decision node with an incoming object flow - the object is necessary for the guard condition -, but one or more of the target actions don't need that object. Due to the constraint that object flows don't have actions at either end I must model an input pin. For example in case of a CallOperationAction an operation with an additional parameter must be defined even if I don't use it. It's just for modeling purposes. I've assumed before reading the constraint in the specification that an object flow can target an action directly. In that case it's semantic is the same as for the control flow. That works perfect for me. I would propose to weaken the constraint for object flows that actions as targets are allowed. The object token enables the action and gets lost. Any other solution with the same semantic is also acceptable.

Resolution: closed no change
Revised Text:
Actions taken:
May 5, 2005: received issue
August 23, 2006: closed issue

Discussion:

Use a control pin (Pin.isControl = true) on the target action. As described at Pin,
this allows a data/object token to act as control of action, rather than a data input.
If you don�t want the queuing effects of a pin on the target action, mark the pin at
the source action as having a control type (ObjectNode.isControlType). As
described at ObjectNode, you can a control flow coming out of the pin.

Issue 8768: Section: Classes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

Resolution: This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
May 5, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8769: Can't specify mutator semantics for derived properties (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is currently not possible to specify the effect of setting derived properties that are not read-only. As a result, derived properties are under-specified in the model because the semantics of updating them cannot be modeled or stated formally.

Resolution: see above
Revised Text: In the Superstructure spec: In the Semantics subsection of section 7.3.44 Property, change: If a property is derived, then its value or values can be computed from other information. Actions involving a derived property behave the same as for a nonderived property. Derived properties are often specified to be read-only (i.e. clients cannot directly change values). But where a derived property is changeable, an implementation is expected to appropriately change the source information of the derivation. The derivation for a derived property may be specified by a constraint. to: If a property is derived, then its value or values can be computed from other information. Actions involving a derived property behave the same as for a nonderived property. Derived properties are often specified to be read-only (i.e. clients cannot directly change values). But where a derived property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived property. The derivation for a derived property may be specified by a constraint. In the Infrastructure spec: In the Semantics subsection of section 11.3.5 Property, change: If a property is derived, then its value or values can be computed from other information. Actions involving a derived property behave the same as for a nonderived property. Derived properties are often specified to be read-only (i.e. clients cannot directly change values). But where a derived property is changeable, an implementation is expected to appropriately change the source information of the derivation. The derivation for a derived property may be specified by a constraint. to: If a property is derived, then its value or values can be computed from other information. Actions involving a derived property behave the same as for a nonderived property. Derived properties are often specified to be read-only (i.e. clients cannot directly change values). But where a derived property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived property. The derivation for a derived property may be specified by a constraint.
Actions taken:
May 6, 2005: received issue
August 23, 2006: closed issue

Discussion:

Neither MOF nor UML specify how non-derived properties are actually set. The intuitive
semantics is that assuming all property constraints are met, and in the absence of any
intervening change, getting a property after it has been set will result in the value that was
set, or a collection that has that value added or removed. Implementations may do
something quite different including dynamically allocating memory for the property�s
slot, and setting the value it that memory location.
For derived properties, there can be no implied meaning for getting or setting a property
as it depends on how the property is derived. CMOF and UML2 can specify the value of
a derived property by using a constraint that constrains the value based on how it could
be calculated from other values or operations. Implementations do not have to implement
the calculation as a constraint, but can easily know if an implementation matches the
constraint.
However, this is not the case for setting a derived property. Many derived properties will
be read-only because there is no way to know how to set other dependent properties
simply from the value of the derived property. For example, consider derived unions.
Attempting to add an element to a derived union cannot be allowed because there is not
enough information to know which subset the element should be added to. All derived
properties for which the effect of setting the value cannot be determined must be marked
as read-only in the model.
There are other cases where it is both possible to set derived values, and very convenient
to do so. For example, consider the problem of adding a superclass to a Kernel::Class.
This requires a number of actions:
1. Make sure the new superclass is not already a superclass of the class.
2. Create an instance of a Generalization.
3. Add the Generalization to the Class::generalization property.
4. Set the Generalization.general property to the superclass. These operations would have to be repeated every time a new superclass is added. It is
common practice to create convenience functions that encapsulate such common
behavior to reduce developer burden, code size, and the possibility for errors. However in
this case, we don�t need an operation because Kernel::Class already includes derived
property superClass. Setting this property could perform the actions above resulting in
the property meeting its constraints.
There is another reason that some derived properties must be settable. Some non-derived
properties are in lower compliance levels are redefined to be derived in higher
compliance levels. XMI instance documents for models at the lower compliance levels
may therefore include values for those properties, and the definition of compliance says
that an XMI document of a lower compliance level must be able to be read/loaded by a
higher compliance level without loss of data. This means the upper compliance level will
see values for derived properties in XMI files it is expected to load, and therefore would
need to know how to set them. For example, Constructs::Class has non-derived property
superClass which as described above is redefined to be derived from
Class::generalization in Kernel.
There is currently no place in the CMOF or UML2 metamodel for specifying mutator
semantics for derived properties. So there is no place to specify the four steps above for
setting Kernel::Class:/superClass, and therefore no way to reflectively or otherwise
generate mechanisms for reading or loading derived properties that redefine non-derived
properties.
However, there is actually no need to specify exact steps necessary to set a derived
property. All that is necessary is that an implementation must do whatever is necessary in
order for the constraints in the model to be valid when the derived property is set. This
allows much implementation flexibility for how properties are actually implemented.

Issue 8770: Section: Actions (uml2-rtf)

Click here for this issue's archive.
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Clarification
Severity: Minor
Summary:

The third sentence of the Actions chapter implies that most of the actions are specialization of the one that supports implementation-dependent semantics. Should be reworded.

Resolution:
Revised Text: In Actions, replace third sentence (the one beginning �The most basic action�) with �This chapter defines semantics for a number of specialized actions, as described below.�
Actions taken:
May 6, 2005: received issue
August 23, 2006: closed issue

Issue 8771: Section: Action/Activity (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

In the actions and activities chapters default values for attributes that are typed by ValueSpecifications use primitives for the default value. For example: 12.3.5 ActivityEdge, p. 352 Attribute weight has default value "1". Is that correct? What if the ValueSpecification is not computable or the value isn't typed by an Integer?

Resolution: Yes, this is correct. ValueSpecifications are used in these cases, because it is often desirable for the given value to be specified in the model as computed. The default values are to be interpreted as the corresponding LiteralValue for the given value (e.g., a LiteralUnlimitedNatural, in the case of weight). The type of value to which such a ValueSpecification must evaluate (e.g., UnlimitedNatural for weight) is given in the semantics for the construct. If the ValueSpecification is not computable or evaluates to a value of the incorrect type, then the model is ill-formed and has no meaning. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
May 9, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8772: Section: 11.3.48 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Semantic sections mentions the order of structural features of the specified classifier. The list of structural features is ordered for a class, but unordered for a classifier.

Resolution:
Revised Text: In Activities, UnmarshallAction, o Constraints o Constraint [4], replace "features" with "feature". Editor�s note: fixed in formal copy edit o Add constraint "unmarshallType must be a Classifier with ordered attributes" o Semantics, at end of first paragraph, add "The order of the values in an output pin are the same as the order of the corresponding structural features, if any".
Actions taken:
May 9, 2005: received issue
August 23, 2006: closed issue

Issue 8773: Page: 330 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Typo in fig. 192: Association from BehavioralFeature to Parameterset: should be ownedMember instead of ownedmember (uppercase).

Resolution: Discussion: This issue refers to an older version of the specification. It is fixed in the meantime. Disposition: Closed, no change
Revised Text:
Actions taken:
May 10, 2005: received issue
October 27, 2008: closed issue

Issue 8774: Notation of Attributes and Associations subsections (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.

Resolution: Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are: �h the use of * instead of 0..* -- simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open. �h The derivation specification already has another open issue. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 10, 2005: received issue
October 27, 2008: closed issue

Issue 8776: Section: 9.3.7 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

Second constraint: "If a connector end references both a role and a partWithPort, then the role must be a port that is defined by the type of the partWithPort." Since role has multiplicity 1..1 and partWithPort 0..1 the if condition is always true if a connector has a partWithPort. It'S sufficient to say "If a connector references a partWithPort,..."

Resolution: Agreed, this will make it easier to read.
Revised Text: In the text for the second constraint of Section 9.3.7, replace "If a connector end references both a role and a partWithPort, then the role must be a port that is defined by the type of the partWithPort" with "If a connector end references a partWithPort, then the role must be a port that is defined by the type of the partWithPort"
Actions taken:
May 11, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8777: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

There is a notational conflict in the white box view of a component. If a part is typed by a component the component symbol is shown in the upper right corner of the part rectangle. The same position is used to show the multiplicity of the part.

Resolution: The upper right corner of a connectable element could be used to denote the multiplicity. The same position is used to show the component symbol if the connectable element is typed by a component. It is also used by stereotype symbols. The presentation option for the multiplicity is in conflict with other standard UML notations. However it is only an option and not a mandatory presentation. Disposition: Closed, no change
Revised Text:
Actions taken:
May 12, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8778: Section: 8.3.1 Page: 156 ff (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Fig. 86, 87, and 89 have no dividing line between name compartment and internal view compartment

Resolution: Discussion: This dividing line is optional. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 12, 2005: received issue
October 27, 2008: closed issue

Issue 8781: Actions should be able to overlap partitions, to support multiple participa (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Actions should be able to overlap partitions, to support multiple participants

Resolution:
Revised Text: In Activities, ActivityPartition, Constraints, remove constraint [2] (the one beginning �No node or edge�).
Actions taken:
May 15, 2005: received issue
August 23, 2006: closed issue

Issue 8782: ExecutableNode should be abstract in Figure 195. It is in Figure 197. (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

ExecutableNode should be abstract in Figure 195. It is in Figure 197.

Resolution: See issue 8239 for disposition
Revised Text:
Actions taken:
May 15, 2005: received issue
August 23, 2006: closed issue

Issue 8784: MessageEnd (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

MessageEnd is MessageOccurrenceSpecification that redefines "event" as MessageEvent. 
DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"?

Resolution: see above
Revised Text: Change the association from MessageOccurrenceSpecification to MessageEvent over to become an association between MessageOccurrenceSpecification and Event. Add classes ReceiveSignalEvent and ReceiveOperationEvent to be replicas of SendSignalEvent and SendOperationEvent with the obvious modifications of semantics etc. Editor�s note: This resolution is unacceptably incomplete � it should not have gotten through the RTF process. Here is what was done by the editor: UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8784 Document ptc/06-01-01 Page 438 In Figure 14.2, add two new metaclasses ReceiveSignalEvent with a unidirectional association �signal� to Signal and ReceiveOperationEvent with a unidirectional association �operation� to Operation. (Multiplicity 1 in both cases.) In Figure 14.5 move MessageOccurrenceSpecification:;event from MessageEvent to Event. In the MessageOccurrenceSpecification, change the type of the �event� entry to �Event� and change the text to: �The event associated with the message occurrence. {Redefines ExecutionOccurrenceSpecification::event}. In the Description subsection replace the text �Specifies the occurrence of message events� with �Specifies the occurrence of events�. Add the following two entries: ReceiveOperationEvent (from BasicInteractions) Generalizations � MessageEvent (BasicInteractions) on page xxx Description This specifies the reception of an operation invocation event for a particular operation Attributes No additional attributes. Associations � operation::Operation[1] Specifies the operation associated with this event. Constraints No additional constraints. Semantics A receive operation event occurs when an operation invocation is received by the target object. Notation None Changes from previous UML New in UML 2. .ReceiveSignalEvent (from BasicInteractions) Generalizations UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8784 Document ptc/06-01-01 Page 439 � MessageEvent (BasicInteractions) on page xxx Description This specifies the reception of a signal event by the target. Attributes No additional attributes. Associations � signal::Signal [1] Specifies the operation associated with this event. Constraints No additional constraints. Semantics A receive signal event occurs when a signal is received by the target object. Notation None Changes from previous UML New in UML 2. Disposition: Resolved
Actions taken:
May 18, 2005: received issue
August 23, 2006: closed issue

Discussion:

There seems to be some problems with the typing of the MessageEvent.
If the explicit create and explicit destruct (from another lifeline) shall be understood as
messages, there is no way to model this in the metamodel.
Even worse probably that there does not seem to be any way to model a normal reception
of a message since the receiving event should be a MessageEnd - and then of course a
MessageOccurrenceSpecification which only refers to MessageEvents and there are only
two subclasses of MessageEvent and they are both on the sending side. This part of the
metamodel underwent a rather radical rewriting during the FTF due to harmonization of
the Event understanding across the different Behaviors. I was not involved during that
rewriting and there may be details here that have escaped my review today.
My simple attempt to fix it would be that MessageOccurrenceSpecification only requires
Event and not MessageEvent. Otherwise we should need some more restructuring of the
hierarchy of Events and also introduce a message event type for receiving messages. This
would in the long run be the better solution.

Issue 8785: Return message (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

How return message should be mapped into model? What kind of events are on message ends, how return values should be mapped? Should return values be arguments of message? How return message can be recognized in the model?
How variable assignment should be mapped and related with message?

Resolution: There has never been anything called a "return message", but the issue is probably about "reply message" which we had forgotten to give a messageSort, but that has been fixed. The other issues are related, but are also asking for clarification of metamodel encoding. This should eventually be picked up again if necessary during a major revision. Disposition: ClosedOutOfScope
Revised Text:
Actions taken:
May 18, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification.

Issue 8824: Obsolete term EventOccurrence still used in multiple places (uml2-rtf)

Click here for this issue's archive.
Source: CSC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Uncategorized Issue
Severity:
Summary:

1) 14.3.25 OccurrenceSpecification, the change in class name was from EventOccurrence to OccurrenceSpecification.  This change needs to be noted in this document.  Also, the reason why the change was made.
2) EventOccurrence is still being use in the toBefore and toAfter association descriptions of OccurrenceSpecification.
3) EventOccurrence is still be referenced in other areas: 
    a) in the last word of the Example text on page 476, 
    b) In the Notation text on Page 489, 
    c) In the fifth paragraph of the overview on Page 497
    d) Multiple times on Page 509 and 510
    e) First paragraph on Page 528
    f)  Multiple times on Page 531
    g) Multiple times on Fig. 347

Resolution: see pages 453 - 457 of ptc/2006-04-01
Revised Text:
Actions taken:
May 26, 2005: received issue
August 23, 2006: closed issue

Issue 8825: Incorrect Communication Domain Model (uml2-rtf)

Click here for this issue's archive.
Source: CSC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Uncategorized Issue
Severity:
Summary:

Fig. 308 does not contain the correct domain model.  The current model that
appears in Fig. 308 is a duplicate of Fig. 307.

Resolution: See issue 8292 for disposition
Revised Text:
Actions taken:
May 26, 2005: received issue
August 23, 2006: closed issue

Issue 8826: Section: 12 and 13 (uml2-rtf)

Click here for this issue's archive.
Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no)
Nature: Clarification
Severity: Minor
Summary:

Figure numbers 306,307,308,309 appear in both the Activities chapter (12) and the Common Behavior chapter (13)

Resolution: see above
Revised Text: On page 453, change the figure number of figure 306 to 310 and renumber all subsequent figures and update all corresponding textual references to these figures to reflect the new figure numbers.
Actions taken:
May 26, 2005: received issue
August 23, 2006: closed issue

Discussion:

There is a numbering problem with figures. In chapter 13, figure 306 on page 453 should
be numbered as figure 310; all subsequent figures and figure references must be updated
accordingly.

Issue 8845: p. 721: Allow stereotypes to have properties that are typed by metaclasses (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)
. Change paragraph 4 to:
"As part of a profile, it is not possible to have an association between two stereotypes or from a metaclass in the reference metamodel to a stereotype, although a unidirectional association from a stereotype to a metaclass, or equivalently typing a stereotype property by a metaclass, is allowed. The effect of new (meta) associations between stereotypes can be achieved in limited ways either by:"

Resolution: See issue 7756 for disposition
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Issue 8846: p. 728: New presentation options. Replace the following paragraph (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

2) p. 728: New presentation options. Replace the following paragraph:
"The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown."
with the following text:
"The values of a stereotype that has been applied to a model element can be shown in one of three ways:
�As part of a comment symbol tied to the symbol representing the model element 
�In compartments of a graphic node representing the model element.
�Above the name string within a graphic node or before the name string otherwise
In the case where a compartment or comment symbol is used, the user may elect to show the stereotype name in guillemets before the name string in addition to in the compartment or comment.
They are displayed as name/value pairs, thus:
	<namestring>'='<valuestring>
If a stereotype property is multi-valued then the valuestring is displayed as a comma-separated list:
	<valuestring>::=<value>{','<value>}
Certain values have special display rules:
�As an alternative to a name/value pair, when displaying the values of boolean properties diagrams may use the convention that if the namestring is displayed then the value is True, otherwise the value is False; 
�If the value is the name of a NamedElement then optionally its qualifiedName can be used.
If compartments are used to display stereotype values then an additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Any graphic node may have these compartments.
Within a comment symbol, or if displayed before/above the symbols's namestring, the values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.
When displayed in compartments or comment symbol at most one name/value pair can appear on a single line. When displayed above/before a namestring the name/value pairs are separated by semicolons and all pairs for a given stereotype are enclosed in braces."

Resolution: see pages 460 - 461 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Issue 8847: p. 729: Extend the Clock example to show metaclass property (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)3) p. 729: Extend the Clock example to show metaclass property and the use of Boolean. Replace Figure 456 with:

Resolution: see pages 462 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 3

Issue 8848: Make instance model consistent with new definition of Clock (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
4) p. 730: Make instance model consistent with new definition of Clock. Replace Figure 458 with:

Resolution: see page 463 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 4

Issue 8849: p. 731: Make this example consistent with the new definition of Clock (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Critical
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:	
5) p. 731: Make this example consistent with the new definition of Clock. Replace Figure 459 with:

Resolution: see pages 464 - 465 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 5

Issue 8850: p. 731: Make example consistent with new definition of Clock. (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
6) p. 731: Make example consistent with new definition of Clock. Replace Figure 461 with:

Resolution: See issue 8849 for disposition
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 6

Issue 8851: p. 732: Change example to be consistent with new definition of Clock (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
7) p. 732: Change example to be consistent with new definition of Clock. Replace figure 462 with:

Resolution: see pages 466 -467 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 7

Issue 8852: p. 732: Show examples of new stereotype notation (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
8) p. 732: Show examples of new stereotype notation. Add the following including new Figure 463:
"Finally, the two alternate notational forms are shown.  
- Other notational forms for showing values
AlarmClock is valid for OS version 1.1, is POSIX-compliant and it has a starting operation called Start. The compartment form of notation is shown on the left and the in-symbol form on the right (note that not all properties of Clock are shown on the right."

Resolution: see pages 468 - 469 of ptc/2006-04-01
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

see ftp://ftp.omg.org/pub/UML_2.0-rtf/Recommended-Changes-to-UML2-Profiles-050530.doc    item 8

Issue 8853: pp. 733-734: Add association as valid graphic path (uml2-rtf)

Click here for this issue's archive.
Source: Pivot Point (Mr. Cris Kobryn, )
Nature: Revision
Severity: Significant
Summary:

Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary: 	
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See 
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:	
9) pp. 733-734: Add association as valid graphic path. Add the following row to Table 24:

Unidirectional Association	 	See "Profile (from Profiles)" on page 720

Resolution:
Revised Text:
Actions taken:
June 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

These table only present new graphical features that are not already defined within the
constructs chapter. For example, no attributes are shown here, nor "import" dependencies.
There is no need to ad associations there.
Disposition: Closed, no change

Issue 8859: Section: 12.3.37 ObjectFlow (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

On page 418, Constraints (BasicActivities), you write: "[1] Object flows may not have actions at either end." In contrast, on page 420, Notation, the description of the upper right part of figure 281 is: "Two object flow edges linking object nodes and actions(!!)." After many cycles of re-reading the Activities chapter I got convinced that the constraint is really meant as-is. So, the notation mentioned above likely means the "standalone pin notation" from page 433. If so, you should make it very clear, that this notation maps to two Pin instances (one at either action) and ONE ObjectFlow instance in-between, in the model (just like the alternative notation in the same figure shows). In addition, you should add this clarification throughout the Activities chapter. In addition, on page 433, regarding the explanation of the standalone pin notation, you should add, that it maps to ONE object flow edge in-between the two pins, in the model.

Resolution:
Revised Text: In Activities: ObjectFlow, Notation Add after the current text, In Figure 281, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure. See discussion of Figure 294. Figure 281, in text in figure: Upper left, after �flow�, add �arrow�. Upper right, replace �edges� with �arrows�. Lower middle, replace �edge� with �arrow�. Pin, Notation, in paragraph above Figure 194, before �in the underlying model� add �and one object flow edge between them�.
Actions taken:
June 7, 2005: received issue
August 23, 2006: closed issue

Issue 8866: Section: Classes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Figure 28 (Examples of attributes) has a read-only, derived attribute. Read only attributes can't be changed after initialization, whereas the example implies this particular one can be changed due to derivation.

Resolution: close no change
Revised Text:
Actions taken:
June 10, 2005: received issue
April 25, 2011: closed issue

Discussion:

No issue. A read-only attribute can be derived (see semantics of Property).

Issue 8867: OpaqueAction (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

 should specialize input and output, so opaque actions can have pins.

Resolution: see page 471 of ptc/2006-04-01
Revised Text:
Actions taken:
June 14, 2005: received issue
August 23, 2006: closed issue

Issue 8876: Page: 369/370 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

The notation for activity partition allows to notate the specification of the dimension next to the appropriate dimension set. Dimension is a boolean property of an ActivityPartition. It is not clear where the specification of a dimension is stored in the model.

Resolution: An ActivityPartition with isDimension = true is the specification of the dimension, and the partions contained within it are the partitions in that dimension. The dimension name in the notation is the name of an ActivityPartition with isDimension = true. This can be clarified in the text.
Revised Text: In Section 12.3.10 (ActivityPartition), under Notation, replace the last sentence of the first paragraph with: The partitions within each dimension may be grouped into an enclosing activity partition with isDimension=true, whose name is the dimension name. Rather than being shown as a partition itself, however, the dimension is indicated by placing its name along side the set of partitions in the dimension, as shown in c), below.
Actions taken:
June 23, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

Issue 8878: Page: 532 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Associations section: Type of argument is InputPin. In fig. 333 the type is Action

Resolution: This seems to refer to the argument association of InteractionUse, as of the UML 2.0 Draft Adopted Specification (ptc-04-10-02). It was corrected as an editorial change in UML 2.1. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
June 23, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8891: Page: 423 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Second constraint of ObjectNode refers to property isUnique. ObjectNode has no such property. It's not a specialized MultiplicityElement

Resolution: this is correct
Revised Text: In Section 12.3.38 (ObjectNode), remove constraint [2].
Actions taken:
June 29, 2005: received issue
April 26, 2010: closed issue

Issue 8894: TimeExpression (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"?

Resolution: see pages 472 - 478 of ptc/2006-04-01
Revised Text:
Actions taken:
June 20, 2005: received issue
August 23, 2006: closed issue

Issue 8895: ObjectNode (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ObjectNode is abstract, so CentralBuffer or DataStore should be always used in Activity diagram. It is normal?
CentralBuffer and DataStore are described as "special cases of ObjectNodes", but simple ObjectNode can't exist.

Resolution: Yes, this is correct. ObjectNode is a general abstraction. Only its subclasses (which include ActivityParameterNode, InputPin and OutputPin, in addition to CentralBufferNode and DataStore) have concrete syntax and semantics. Revised Text: None Disposition: Close, no change
Revised Text:
Actions taken:
June 20, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8896: abstract Action in Activity diagram (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

4. The same situation is with abstract Action in Activity diagram. OpaqueAction also can't be used, because can't have Pins. 
How to draw "human friendly" action (activity)? The only way is to use CallBehaviorAction?

Resolution: See issue 8867 for disposition
Revised Text:
Actions taken:
June 20, 2005: received issue
August 23, 2006: closed issue

Issue 8900: Page: 157,162,163 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Significant
Summary:

Fig. 87, fig. 92, and fig.93 show composite structure diagrams with interfaces. For example fig 87; delegation connector from port to interface OrderEntry. How can a connector be linked to an interface?

Resolution: Figure 87 is now 8.12. Figure 92 is now 8.17. Figure 93 is now 8.18. I include figure 8.15 in this resolution to get a consistent overall picture. The solution is to allow connector lines to connect lollipops and sockets, and ball and socket notation, only when the interfaces are on a simple port. Then the connectors become a notational shorthand for actually connecting to the ports.
Revised Text: see pages 58 - 60 of ptc/2009-09-07 for details
Actions taken:
June 30, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8901: Page: 163 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

Fig. 93: The only message of the notation abstraction is that some components offer and some components require an interface. That the same as in a component diagram. Fig. 93 shows an internal view of a component. A composite structure diagram must show how the components are wired together. For examples that :BackOrder uses :Customer and NOT :Organization or vice versa. I propose to not use the notation abstraction.

Resolution: Introducing a minimalist resolution, to just fix the incorrectly used terminology.
Revised Text: On p.152, immediately after figure 8.17, add a subsection heading "Presentation Option". Replace the first paragraph after the caption for figure 8.17 by the following: "Where multiple components provide or require the same interface, a single symbol representing the interface can be shown, and lines from the components can be drawn to that symbol, indicating that this interface is either a required or provided interface for the components. This presentation option is applicable whether the interface is shown using "ball-and-socket" notation, as in figure 8.18 below, or just using a required or provided interface symbol.
Actions taken:
June 30, 2005: received issue
August 23, 2006: closed issue

Issue 8919: Section: 12.3.5 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Description
Section Associations (CompleteActivities): weight specifies the number of tokens instead of objects consumed from the source node on each traversal. It's a common property for object flow as well as for control flows.

Resolution:
Revised Text: In Activities, ActivityEdge, Associations (CompleteActivities), weight entry, replace �objects� with �tokens�.
Actions taken:
July 6, 2005: received issue
August 23, 2006: closed issue

Issue 8930: Section: 12.3.9 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Semantics section, last sentence: Recursive reference to semantics section of ActivityParameterNode.

Resolution:
Revised Text: In Activities, ActivityParameterNode, Semantics, last sentence, replace �ObjectNode, Action, and ActivityParameterNode� with �ObjectNode and Action�. Editor�s note: superseded by resolution to issue 8219
Actions taken:
July 18, 2005: received issue
August 23, 2006: closed isuse

Discussion:

Issue 8932: UML Superstructure / Actions / incorrect form for subsetting (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The Actions chapter uses the convention "Specialized from" in describing properties that are specialized in a metaclass, instead of the "Subsets " convention used throughout the rest of the document. The former should all be changed to follow the conventional form.

Resolution:
Revised Text: Change all occurrences of �specialized from� in association end description subsections of metaclasses in chapter 11 and chapter 12 to �subsets�, with the exception of SendObjectAction::request, which should replace �specialized from� with �redefines� Editor�s note: Except for the last item, the rest were done as part of various editorial fixes
Actions taken:
July 18, 2005: received issue
August 23, 2006: closed issue

Issue 8933: UML Superstructure / Actions / Missing package heading (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

In section 11.3.21, (Actions, LinkAction), the second constraitns section should include the phrase (CompleteActions) at the end

Resolution:
Revised Text: Replace the second Constraints subheading in section 11.3.21 with the heading Package CompleteActions and ensure numbering of subsequent constraints starts at the next sequence number from the previous constraint (i.e., [4]).
Actions taken:
July 18, 2005: received issue
August 23, 2006: closed issue

Issue 8935: UML2 issue: {unrestricted} described in text but not BNF (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In section 7.3.49 of Super, and 9.2.2 of Infra, {unrestricted} is given as a notation option: "A modifiable structural feature is shown using {unrestricted} as part of the notation for the structural feature."
However unrestricted is is not included in the BNF for Property (in 7.3.44).
It does not seem useful as a keyword since it is the default; nor is 'unrestricted' a very suggestive term for the meaning.
 
Proposed Resolution:
Delete the above sentence from 7.3.49 of Super, and 9.2.2 of Infra.

Resolution:
Revised Text: Delete the sentence A modifiable structural feature is shown using {unrestricted} as part of the notation for the structural feature. from section 7.3.49 of Super, and section 9.2.2 of Infra.
Actions taken:
July 19, 2005: received issue
August 23, 2006: closed issue

Issue 8938: Section: 15.3.14 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

BNF for transition specifies that a trigger is mandatory. That's not the case, e.g. for the initial state transition.

Resolution:
Revised Text: In the Notation subsection of Transition in section 15.3.14, replace the BNF expression: <transition> ::= <trigger> [�,� <trigger>]* [�[� <guard-constraint>�]�] [�/� <activity-expression>] with the expression: <transition> ::= [<trigger> [�,� <trigger>]*] [�[� <guard-constraint>�]�] [�/� <activity-expression>]
Actions taken:
July 22, 2005: received issue
August 23, 2006: closed issue

Issue 8939: Section: 12.3.18 and 12.3.35 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Add constraint to conditional and loop node that the result output pins have no outgoing edges

Resolution: see above
Revised Text: In Activities, ConditionalNode and LoopNode, in the Constraints sub-section, replace �None� with �[1] The result output pins have no incoming edges.�
Actions taken:
July 25, 2005: received issue
August 23, 2006: closed issue

Discussion:

Presumably the filer meant no incoming edges. Values from the output body pins are
moved to the result pins, and then flow out of the conditional node.

Issue 8945: Page: 420 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

In addition to the elided pins presentation add presentation option that pins can be omitted without a little box above the line.

Resolution: Without the little box, the object flow would look identical to a control flow between actions, which would be confusing. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
August 2, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8946: Section: 9.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

A Property is a ConnectableElement, which currently is (should be?) a TypedElement. The Description in 9.3.5 however states: "A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. Note on p.84 states: "When used to specify the existence of an entity in a modelled system, an instance specification represents part of that system." In 9.3.12. it says:"When an instance of the containing classifier is created, a set of instances corresponding to its properties may be created either immediately or at some later time. These instances are instances of the classifier typing the property. A property specifies that a set of instances may exist; this set of instances is a subset of the total set of instances specified by the classifier typing the property. A part declares that an instance of this classifier may contain a set of instances by composition." So, the concepts must be related. I propose that a ConnectableElement is a specialization of InstanceSpecification, not just a TypedElement. Current problems in practise: A TypedElement is not a PackageableElement and it thus cannot be imported in some other namespace. This makes is hard to create orthogonal views of architectures (e.g. logical vs. execution) in which 'roles' (parts!) are shared. On the other hand, using InstanceSpecifications instead of "Parts" makes it impossible to refer them in interactions. Besides, the meaning of an InstanceSpecification in the context of a classifier is unclear in contrast to the Property.

Resolution: Discussion: The concept of connectable element is not an instance specification, so it would be a mistake to make it a specialization of InstanceSpecification. As the issue also points out, doing so would cause problems with interactions (where connectable elements are heavily used) as well as with their meaning. The issue really at hand appears to be that ConnectableElements are not packageable elements. The reason is that they have really no meaning outside of the context of the classifier they are owned by and thus would not be packaged separately. Disposition: Closed, no change
Revised Text:
Actions taken:
August 2, 2005: received issue
October 27, 2008: closed issue

Issue 8947: Figure 430 references invalid metaclass (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 430 references an 'IntegerExpression' metaclass that doesn't exist. Either such a metaclass (and others for other kinds of expressions?) should be added, or the example should be changed to use a different type of expression.

Resolution:
Revised Text:
Actions taken:
August 2, 2005: received issue
August 23, 2006: closed issue

Discussion:

IntegerExpression in this example is not intended to be a metaclass but a user-defined
(M1-level) class.
Disposition: Closed, no change

Issue 8955: connection point reference (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is this known issue, that just one ConnectionPointReference can point into same connection point?
It's not possible to create two SubMachineStates with ConnectionPointReferences assigned with same StateMachine, because  meta Association between PseudoState (connection point) and ConnectionPointReference has multiplicity [0..1].
 
This destructs all concept of reusable StateMachines

Resolution:
Revised Text: In figure 15.2 of formal/05-07-04 change the multiplicity of the two association ends of the two associations from Pseudostate to ConnectionPointReference from �0..1� to �*�.
Actions taken:
August 10, 2005: received issue
August 23, 2006: closed issue

Issue 8956: UML 2 Classes Notation for association end ownership (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.0 has separated the concepts of navigability from association end ownership. However there is as yet no explicit notation for specifying who owns an association end. An explicit notation is required and, possibly, a set of default notational conventions for the most frequent cases.

Resolution: see pages 489 - 490 of ptc/2006-04-01
Revised Text:
Actions taken:
August 10, 2005: received issue
August 23, 2006: closed issue

Issue 8957: UML 2 XMI DTD requirement (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

In section 6.5.1 of both the RFP for the UML 2 Superstructure and the RFP for the UML 2 Infrastructure it is required that 

Proposals shall specify an XMI DTD for the UML metamodel.

This was based on the assumption that such schemas carry sufficient information for tool vendors to construct facilities for meaningful interchange of models. Unfortunately, due to the introduction of certain more complex features such as package merge in UML 2.0, these schemas are not sufficient. On the other hand, the XMI for the individual compliance levels (Lm, L0, L1, L2, and L3) is sufficient for the interchange objective. Therefore, instead of the XMI schemas, it is proposed to make the latter normative for the UML 2 Superstructure and Infrastructure specs.

Resolution: This is resolved by the resolution to 3898 and the explanatory text for 8678.
Revised Text:
Actions taken:
August 10, 2005: received issue
August 23, 2006: closed issue

Issue 8963: UML2 Navigability Impact on Tools (uml2-rtf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The notion of navigability for association ends may be interpreted as
limiting the ability of UML tools to traverse associations with
non-navigable ends.  However, discussion among RTF members indicates
that UML tools need not be specifically limited in their ability to
traverse non-navigable ends.  To prevent confusion about the impact of
non-navigable ends among tool developers studying the specification, the
ability of UML repositories and other tooling to ignore navigability
limitations should be explicitly stated.

Resolution:
Revised Text: Insert the following text in the Semantics subsection of section 7.3.3 of the superstructure document (formal/05-07-04) on page 38, just before the subsection �Semantic Variation Points� (also on page 115 of section 11.3.1 in the infrastructure document ptc/04-11-16): Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends.
Actions taken:
August 11, 2005: received issue
August 23, 2006: closed issue

Issue 8964: Interaction::lifeline should be ordered (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example).

Resolution:
Revised Text:
Actions taken:
August 12, 2005: received issue
October 27, 2008: closed issue

Discussion:

In the hopes of keeping notation consistent when displaying sequence diagrams, it is important to maintain lifeline order. Tim and others I totally agree. In my file discussing the issues on Interactions sent out one month ago, I said very much exactly the same thing: "It is in general not a good idea to introduce information in the metamodel to define aspects of the diagrams. I see no significant semantic reason for ordering lifelines. I would like to reject this." I was a little surprised that it was introduced into the draft ballot. I probably have missed some point in the procedure here. /Oystein Haugen Probably still responsible for Interactions Tim Weilkiens wrote: > ------------------ > Summary: > Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example). > > Discussion: > In the hopes of keeping notation consistent when displaying sequence diagrams, it is important to maintain lifeline order. > ------------------ > > My comment: > The order of lifelines has no semantic. It's a diagram layout issue and should not be present in the model. > I would propose to reject the issue. Otherwise several questions come up: > > - What is the semantical meaning of the order? > - How should a communication/timing/interaction overview diagram show the order? Disposition: Closed, no change

Issue 8966: Core::Constructs::Operation (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

This is a question or an issue for the UML 2.0 Superstructure and Infrastructure Revision Task Force (http://www.omg.org/issues/uml2-rtf.html An operation, e.g. Core::Constructs::Operation does no longer contain the isAbstract attribute (compared to UML version 1.5). I could not find a note in any of the classes within the inheritance hierarchy stating that this is a change to the 1.x versions. Was this attribute intentionally dropped for version 2.0? If yes, what is the suggested replacement?

Resolution: Discussion: This ability is still there, since the attribute isAbstract is inherited from BehavioralFeature (which is a superclass of Operation) as defined in CommonBehaviors. Disposition: Closed, no change
Revised Text:
Actions taken:
August 9, 2005: received issue
October 27, 2008: closed issue

Issue 8968: Page: 591,592 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Constraint 9 and 10 state that entry and exit points are only allowed in the topmost region of a statemachine. On page 592 the entry/exit point semantic describes that these points are also allowed on composite states (see also issue 6075). I think the constraints don't take into account that composite states are also allowed.

Resolution:
Revised Text: In section 15.3.8 in the Constraints section of Pseudostate, remove constraints [9] and [10]. Editor�s note: already removed by resolution to issue 8611
Actions taken:
August 17, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is left over from an old view that entry and exit points can only be defined on
submachines. This was changed in the FTF to allow composite states to have such points
as well, but these two constraints were not removed.

Issue 8970: Behavior (uml2-rtf)

Click here for this issue's archive.
Source: MID GmbH (Mr. Detlef Peters, d.peters(at)mid.de)
Nature: Clarification
Severity: Significant
Summary:

1) As a specialization of Class, Behavior (and its subclasses) may have properties (+ownedAttribute) and operations (+ownedOperation). Especially for operations, I can't see any use for it.
I propose to change the Superclass of Behavior from 'Class' to 'Classifier' and to add an explicit ownership of Properties, as already done for Signals.
2) The description and semantics of Behavior immediately refer to a context classifier. As a consequence, the composite relation to 'BehavioredClassifier' should be of multiplicity 1 instead of 0..1 so that a Behavior must always be owned by a BehavioredClassifier.

Resolution: 1) The rationale for allowing attributes and operations on behaviors is actually provided in Subclause 12.3.4 for activities. In part: "An activity execution, as a reflective object, can support operations for managing execution, such as starting, stopping, aborting, and so on; attributes, such as how long the process has been executing or how much it costs; and links to objects, such as the performer of the execution, who to report completion to, or resources being used, and states of execution such as started, suspended, and so on." The submitter may not agree with the need for this capability, or desire to use it, but it was specifically included in UML because there are some who do wish to use it. 2) A behavior may standalone without being owned by any other behaviored classifier. In this case the behavior is implicitly considered to be its own context when executed. Per the Semantics in Subclause 13.3.2: "When a behavior is instantiated as an object, it is its own context." Revised Text: None Disposition: Closed No Change
Revised Text:
Actions taken:
August 19, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8972: Page: 255 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

The specification says: "If isReplaceAll is false and the variable is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the variable is unordered and UNIQUE, then adding an existing value has no effect."

Resolution: agreed
Revised Text: In the UML 2.2 Superstructure (ptc/08-05-05), Subclause 11.3.6 (AddVariableValueAction), under Semantics, in the first paragraph, second sentence, change "non-unique" to "unique".
Actions taken:
August 22, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8973: Page: 346-347 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Figure 207 on page 346 depicts the symbol for an activity as a number of rectangle with rounded corners surrounding a number of action nodes which also are depticed as rectangles with rounded corner. The example (figure 209 on page 347) however, depicts the action nodes not as rectangles with rounded corners but more lika ovals (or rectangles with noticabely more rounded corners than previously). Which symbol is the correct one?

Resolution: The referenced figure is 12.33 in Section 12.3.4 of the UML 2.2 specification (ptc/08-05-05). The graphical variation in the action shape in subsequent diagrams does not seem unreasonable and the notation of an action within an activity is clearly given in Section 12.3.2. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
August 22, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 8976: UML 2 Super / Undocumented properties (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The following properties appear in the metamodel diagrams but are not documented in the spec: 

UML::Classes::Kernel::Property::class 
UML::Components::BasicComponents::Connector::contract 
UML::Components::BasicComponents::Realization::abstraction 
UML::Components::BasicComponents::Realization::realizingClassifier 
UML::Interactions::BasicInteractions::Lifeline::coveredBy

Resolution: see pages 494 - 495 of ptc/2006-04-01
Revised Text:
Actions taken:
August 25, 2005: received issue
August 23, 2006: closed issue

Issue 8978: UML2 should specify default property ownership for association ends (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML2 should define the defaults for property ownership and the explicit meaning of navigation notation. It should also provide notation for overriding these defaults in order to specify explicity the classifier that owns a property without relying on navigability. This recognizes a common notation practice and will result in predictable metamodel interchange. I general, the UML2 spec should attempt to avoid situations like the pair EF and IJ in figure 21, and instead use sensible defaults. If the default isn't what the model wants, then there should be notation to explicitly say what is needed. This will limit semantic variation points or unspecified notation meaning that may result in interchange and interoperability issues.

The diagram conventions used in Superstructure section 6.5.2 tie navigability and property ownership together in a manner that is consistent with the notaiton used in Basic and EMOF. However section 7.3.1 Notation for Association says:

Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
some of the arrows and crosses and just show exceptional situations:
� Show all arrows and x�s. Navigation and its absence are made completely explicit.
� Suppress all arrows and x�s. No inference can be drawn about navigation. This is similar to any situation in which
information is suppressed from a view.
� Suppress arrows for associations with navigability in both directions, and show arrows only for associations with oneway
navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation
at all; however, the latter case occurs rarely in practice.

This is fine, but given a UML2 diagram what are we to assume if all navigations are not explicit as in the first bullet? Wouldn't such such a model be ambiguous? Should UML2 specify which one of these conventions are implied by the notation? The last bullet represents common practice as well as the conventsions used in the UML2 specification. Perhaps the UML2 spec should to be specific about what the notation means and not leave this up to the reader.

Later in the spec (page 42) under Issue 6243, Figure 22 shows a class containing a property with non-primitive type and indicates this is an ownedAttribute of the class, and can be shown as an association too as described in Basic and EMOF. What it doesn't say is what the notation

by itself means. We know ClassA can navigate to b, but we don't know anything about who owns the properties and therefore where the ends go in an instance of the metamodel. Are they both ownedEnds of the Association? Is b an ownedAttribute of ClassA and a is an ownedEnd? Since there is currently no notation for specifying which classifier owns the properties, the notation should specify the default owners. Otherwise different tools may produce different XMI as it is not clear when a property on an association end is an ownedEnd of the association or an ownedAttribute of one of the associated classes.

The conventions in 6.5.2 should be the definitive notation for navigation arrows (with x on the ends options to make non-navigable explicit), and also specifies the default for property ownership. That is, the bullet lists in 7.3.1 should be replaced with those in 6.5.2 for association navigability and property ownership.

Then a notation should be specified for explicitly stating property ownership when the default is not appropriate.

Resolution:
Revised Text: The points raised by this issue have been addressed by resolutions to issues 8956 and 8963.
Actions taken:
August 26, 2005: received issue
August 23, 2006: closed issue

Issue 8987: Section: 6.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"�Part I. Structure� defines the static, structural constructs (e.g., classes, components, nodes artifacts) used in various structural diagrams, such as class diagrams, component diagrams, and deployment diagrams. Part II - �Behavior� specifies the dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. �Part ~~~~ I. Structure� defines auxiliary constructs ~~~~~~~~~~~~~~ (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods" The words underlined shoude be "Part III - Supplement.

Resolution:
Revised Text: Insert the correct hyperlink in the following sentence on page 15 of formal/07-11-02: �Part I. Structure� defines auxiliary constructs (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods. i.e., instead of �Part I. Structure� the correct link is �Part III. Supplement�.
Actions taken:
September 7, 2005: received issue
October 27, 2008: closed issue

Discussion:

There is a bad hyperlink in here that needs to be fixed.

Issue 8989: UML 2 Super / Collaboration use issues (01) (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

(1) All the dependencies in Figure 109 of ptc/04-10-02 are pointing in the wrong direction. Note that constraint [1] of CollaborationUse says: 
"All the client elements of a roleBinding are in one classifier and all supplier elements of a roleBinding are in one collaboration..." 

which implies that the supplier elements (the ends with the arrow, according to the notation subsection of Dependency) are the roles in the collaboration and the client elements are the parts that are playing specific roles of that collaboration. The figure actually shows the inverse of that.

Resolution: see page 498 of ptc/2006-04-01
Revised Text:
Actions taken:
September 22, 2005: received issue
August 23, 2006: closed issue

Issue 8990: UML 2 Super / Collaboration use issues (02) (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

2) The caption of Figure 106 still refers to "collaboration occurrence" (should be "collaboration use")

Resolution:
Revised Text: Change the word �occurrence� in the caption of figure 9.13 on page 168 of formal/05-07- 04 to �use�. Editor�s note: not done; superseded by the resolution to issue 6423
Actions taken:
September 22, 2005: received issue
August 23, 2006: closed issue

Issue 8993: UML 2 Super / miscellaneous figure-text discrepancies (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

There are a few discrepancies between the figures and the latest Superstructure text (formal/05-07-04) that need to be fixed: 

(1) figure 15.2 contains State::doAcvity -- it should be State::doActivity (the textual description of this item uses correct spelling) 

(2) resolutions to issues 6185 and 7342 indicate that Behavior::context should be derived and that it should subset "redefinitionContext". This needs to be fixed in figure 13.6. Also, the description in the text for this item on page 417 should be updated to show that "context" is derived ("/context"). 

(3) the association end Pseudostate::state shown in figure 15.2 is not documented. It should be.

Resolution: see pages 500 -501 of ptc/2006-04-01
Revised Text:
Actions taken:
September 22, 2005: received issue
August 23, 2006: closed issue

Issue 8996: Invalid stereotype in StandardProfile (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Page 671 (ormal/05-07-04),<< script>> is in StandardProfileL1, but its base element, Deployments::Artifact isn�t in L1.

Resolution: See issue 8459 for disposition
Revised Text:
Actions taken:
September 22, 2005: received issue
August 23, 2006: closed issue

Issue 9000: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

In Figure 195, subsetting opposite Variable should be of namespace, rather than owner

Resolution:
Revised Text: In Activities, Figure 195, on associations from Variable, on ends opposite Variable, replace �owner� with �namespace�. Variable, Associations: In scope entry, at end of description, add �(subsets NamedElement::namespace)�. In activityScope entry, at end of description, add �(subsets NamedElement::namespace)�.
Actions taken:
September 25, 2005: received issue
August 23, 2006: closed issue

Issue 9001: Section: Common Behavior (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Semantics of AnyReceiveEvent. The semantics of AnyReceiveEvent is in terms of state machines even though it is in Common Behavior. Should be defined independently of the kind of behavior using it.

Resolution: agreed
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Subclause 13.3.1, replace the Description with: A trigger for an AnyReceiveEvent is triggered by the receipt of any message that is not explicitly handled by any related trigger. Replace the Semantics with: A trigger for AnyReceiveEvent may be triggered by the receipt of any message (signal send or operation call). However, if there is a related SignalEvent or CallEvent trigger that specifically matches the message, then the AnyReceiveEvent trigger is not triggered by the message. Which other triggers are related to an AnyReceiveEvent trigger depends on the context of the trigger (in particular, see 12.3.2, "AcceptEventAction (from CompleteActions)", on page xxx and 15.3.14, "Transition (from BehaviorStateMachines)). In Subclause 11.3.2 AcceptEventAction, under Semantics, at the end of the second paragraph, add the sentence: If one of the triggers is an AnyReceiveEvent, and the event occurrence is for a message that is not matched by any specific SignalEvent or CallEvent trigger on the same action, then the event occurrence matches the AnyReceiveEvent (see also 13.3.1 "AnyReceiveEvent (from Communications)" on page xxx). In Subclause 15.3.14 Transition, under Semantics, "Enabled (compound) transitions", at the end of the second bullet, add the sentence: If one of the triggers is for an AnyReceiveEvent, then a signal or call event satisfies this trigger if there is no other signal or call event trigger on the same transition, or any other transition having the same source vertex as the transition with the AnyReceiveEvent trigger (see also 13.3.1 "AnyReceiveEvent (from Communications)" on page xxx).
Actions taken:
September 25, 2005: received isuse
April 26, 2010: closed issue

Issue 9003: Section: Classes (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Association.memberEnd should specialize Relationship:relatedElement. Programs accessing the repository with RelatedElement should get the elements being associated

Resolution:
Revised Text: Figure 7.12 - Classes diagram of the Kernel package Add {subsets relatedElements} to /endType role on association between Association and Type. 7.3.3 Association (from Kernel) Associations �h �E/ endType: Type [1..*] References the classifiers that are used as types of the ends of the association. Subsets Relationship:relatedElement
Actions taken:
September 25, 2005: received issue
October 27, 2008: closed issue

Discussion:

Association is relationship between two types, not properties, so �relatedElements� shall be Types. Association has special derived property for this purpose: � / endType: Type [1..*] References the classifiers that are used as types of the ends of the association. It shall subset Relationship:relatedElement

Issue 9004: Section: Classes (02) (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

raisedException in Figure 10, reused without specialization by Operation in Figure 11 (the entry for it in Operation says it is redefined), but redefined in Figure 315. Should it be a derived union in Figure 10?

Resolution: The specialization from A_raisedException_operation to A_raisedException_behavioralFeature comes as a result of L3 package merge. Derived union would make sense if raisedException had a subsetting relationship instead of a specialization refinement. (Note also that the redefinition of raisedException is now noted on the diagram for Operation. Also, the resolution of Issue 12558 removed the later BasicBehaviors::BehavioralFeature::raisedException.) Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
September 25, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9005: Section: Common Behavior (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Second paragraph of Semantics section of Trigger in Common Behavior is inconsistent with the first paragraph of p 605 in semantics of State. The semantics of Trigger does not accomodate deferred events.

Resolution: The noted paragraph in Trigger is not actually in conflict with deferred events. The semantics of Trigger states that once "an event is dispatched" it is "considered consumed" and is then "no longer available for processing". However, the semantics for deferred event under State says that "an event that does not trigger any transitions in the current state, will not be dispatched" if it is deferred. Therefore, there is no conflict with it being consumed only if it is actually dispatched. However, it would probably be helpful to clarify this under Trigger. Also, the semantic variation point on discarding an event if there is no appropriate trigger is not correct, since, for a transition even, at least, if the event is deferred it is not discarded, and if it is not deferred it is.
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Subclause 13.3.31, Trigger, under Semantics, at the end of the second paragraph, add: (Note that an event identified as deferred by a state that does not fire any trigger is not dispatched and is therefore never consumed; see 15.3.11, "State", on page xxx.) Under Semantic Variation Points, remove the second paragraph.
Actions taken:
September 25, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9006: Section: Actions (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Figure 143 should show MultiplicityElement as being from Kernel (the MDL file accidentally used a copy).

Resolution: Discussion: This issue was fixed in a previous revision. Disposition: Closed, no change
Revised Text:
Actions taken:
September 25, 2005: received issue
October 27, 2008: closed issue

Issue 9007: Section: Common Behaviors (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

In Description section of Common Behaviors, CallConcurrencyKind, how can "Multiple invocations of a behavioral feature" occuring simultaneously have a "first behavioral feature". Full text: "Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks."

Resolution: While nit-picking, the issue submitter is correct
Revised Text: In section 13.3.5, subsection �Description�, replace the second sentence of the second bullet �The others are blocked until the performance of the first behavioral feature is complete.� by �The others are blocked until the performance of the currently executing behavioral feature is complete
Actions taken:
September 25, 2005: received issue
October 27, 2008: closed issue

Issue 9010: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Clarify that multiple arrows coming out of an object-node-in-the-middle notation has the semantics of multiple edges coming out of an output pin.

Resolution:
Revised Text: In Activities, Pin, Notation, in paragraph under Figure 293, after third sentence, add new sentence �Multiple arrows coming out of a standalone pin rectangle is an optional notation for multiple edges coming out of an output pin.�.
Actions taken:
September 25, 2005: receive dissue
August 23, 2006: closed issue

Issue 9014: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Add constraint that incoming edges to input pins on structured activities must have sources outside the structured node. Add constraint that incoming edges to output pins on structured activities must have sources inside the structured node.

Resolution: agreed
Revised Text: In Section 12.3.48, under Constraints, add [2] The incoming edges of the input pins of a StructuredActivityNode must have sources that are not within the StructuredActivityNode. [3] The outgoing edges of the output pins of a StructuredActivityNode must have targets that are not within the StructuredActivityNode.
Actions taken:
September 25, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9023: 7.3.22 InstanceSpecification (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

on reading UML Superstructure I found a little mistake regarding chapter 
>7.3.22 InstanceSpecification. This inconsistency seems although to be 
>corrected within UML Infrasturcture.
>UML Superstructure, page 79, InstanceSepcification - Associations
>classifier : Classifier [0..*] ...
>
>UML Infrastructure, page 66, InstanceSpecification - Associations
>classifier : Classifier [1..*]
>
>I guess the specification within UML Infrasturcture is true. However I 
>hope to get some kind of confirmation from you (as I want to be sure).

Resolution: see page 504 of ptc/2006-04-01
Revised Text:
Actions taken:
September 28, 2005: received issue
August 23, 2006: closed issue

Issue 9077: Section: 14.4 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

The statement "Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions." is misleading. An Interaction Overview Diagram is not a special activity diagram. It just re-uses the activity notation.

Resolution:
Revised Text: In section 14.4 on page 488 of formal/05-07-04 remove the phrase are a variant of Activity Diagrams that from the second last sentence of the first paragraph in the section. Add the following parenthetical remarks just before the last sentence in that paragraph: (Overview diagrams have notational elements that are similar to certain elements used in Activity diagrams (flow lines, forks, joins, etc.). However, although the notation and the general purpose of these elements is the same in both cases, their detailed semantics are quite different and modelers should not interpret Overview diagrams as if they were Activity diagrams.)
Actions taken:
October 12, 2005: received issue
August 23, 2006: closed issue

Issue 9078: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In Activities, ExpansionRegion, Notation, first sentence, replace "stream" with "streaming".

Resolution: The sentence already has "streaming" (and has since UML 2.0). However, the literal in ExpansionKind is "stream", so perhaps the submitter intended to suggest replacing "streaming" by "stream". This would be consistent with using the literals from EnumerationKind for "parallel" and "iterative".
Revised Text: In Section 12.3.27 (ExpansionRegion), under Notation, in the first sentence replace "streaming" with "stream".
Actions taken:
October 14, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9080: UML2 Superstructure Fig 2.2 Incomplete (uml2-rtf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The current version of the UML 2 Superstructure specification
(formal/05-07-04) has a diagram for the (top-level) package merges
comprising L1 (Figure 2.2).  The packages that are shown as merged in
the diagram are: BasicActivities, BasicInteractions, Interfaces and
UseCases.  The definitional XML file for L1, however, actually merges
BasicActivities, BasicInteractions,  UseCases, Communicatiions and
InternalStructures

Resolution: This is resolved by the resolutions to issues 9180 and 8459 (ballot 12).
Revised Text:
Actions taken:
October 14, 2005: received issue
August 23, 2006: closed issue

Issue 9081: Section: 14.3.20 Message (from BasicInteractions) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

in 14.3.20 Message (from BasicInteractions) is described: "Object creation Message has a dashed line with an open arrow." the referenced example 14.11 on page 458 shows an object creation Message with a solid line and an open arrow.

Resolution: Discussion: The figure is all right, but dashed lines are sometimes printed as solid lines. The illustrations use Visio and sometimes the dashed lines are not easily distinguished. Disposition: ClosedNoChange
Revised Text:
Actions taken:
October 17, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9084: following imports from merged packages to unmerged packages should be remov (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML::Deployments::ComponentDeployments -> UML::CommonBehaviors 
UML::StateMachines::ProtocolStateMachines -> UML::CommonBehaviors 
UML::UseCases -> UML::CommonBehaviors 

UML::AuxiliaryConstructs::InformationFlows -> UML::CompositeStructures 
UML::AuxiliaryConstructs::Models -> UML::CompositeStructures 
UML::Classes::AssociationClasses -> UML::CompositeStructures 
UML::CommonBehaviors::Communications -> UML::CompositeStructures 
UML::Interactions::Fragments -> UML::CompositeStructures 
UML::StateMachines::BehaviorStateMachines -> UML::CompositeStructures 
UML::StateMachines::ProtocolStateMachines -> UML::CompositeStructures

Resolution: see above
Revised Text: Remove these imports from the source model. Editor�s note: No changes required to the spec, but only the metamodel
Actions taken:
October 19, 2005: receive disuse
August 23, 2006: closed issue

Discussion:

These imports are problematic because the resulting package will retain imports to these
(empty) packages after the merge has been processed. They appear to be left over from
earlier versions of the Rose model; none of them seem to appear in the specification text.

Issue 9085: body expression for Property::isConsistentWith(RedefinableElement) (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The body expression for Property::isConsistentWith(RedefinableElement) is incorrect; it should be: 

result = redefinee.oclIsKindOf(Property) and 
        let prop : Property = redefinee.oclAsType(Property) in 
        (prop.type.conformsTo(self.type) and 
                ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and 
                        ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and 
                                (self.isDerived implies prop.isDerived))

Resolution: see above
Revised Text: In Infrastructure, section 11.3.5, replace the OCL for additional operation [1] with this: Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isDerived implies prop.isDerived)) In Superstructure, section 7.3.44, replace the OCL for additional operation [1] with this: Property::isConsistentWith(redefinee : RedefinableElement) : Boolean pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = redefinee.oclIsKindOf(Property) and let prop : Property = redefinee.oclAsType(Property) in (prop.type.conformsTo(self.type) and ((prop.lowerBound()->notEmpty() and self.lowerBound()->notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and ((prop.upperBound()->notEmpty() and self.upperBound()->notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and (self.isDerived implies prop.isDerived))
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

The redefinee argument here actually refers to the redefining property, not the property
being redefined, so �prop� and �self� need to be swapped in the expression, as suggested.

Issue 9086: Rename Constraint::namespace (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Constraint::namespace (non-derived) invalidly redefines NamedElement::namespace (derived union). 

-> Rename Constraint::namespace to context, replace {redefines namespace, subsets context} with {subsets namespace} on it, and remove Constraint::context.

Resolution: see pages 510 - 512 of ptc/2006-04-01
Revised Text:
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Issue 9087: Rename Package::ownedMember (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Package::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union). 

-> Rename Package::ownedMember to packagedElement and replace {redefines ownedMember} with {subsets ownedMember}. Update all references to ownedMember (e.g. in sample profiles XMI) as appropriate.

Resolution: see above
Revised Text: see pages 513 - 523 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one. Also, since Namespace::ownedMember is a
derived union, owned rules are being excluded as owned members when it becomes non-derived
in the context of packages.

Issue 9088: Rename Component::ownedMember (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Component::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union). 

-> Rename Component::ownedMember to packagedElement and replace {redefines ownedMember} with {subsets ownedMember}. Update any references to ownedMember as appropriate.

Resolution: see above
Revised Text: see pages 524 - 525 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one. Also, since Namespace::ownedMember is a
derived union, owned rules, owned use cases, owned behaviors, owned triggers, owned
attributes, owned connectors, owned ports, owned operations, nested classifiers, and
owned receptions are being excluded as owned members when it becomes non-derived in
the context of components.

Issue 9089: Rename ActivityEdge::redefinedElement (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityEdge::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Rename ActivityEdge::redefinedElement to redefinedEdge, replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see pages 526 - 527 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9090: Rename ActivityNode::redefinedElement (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityNode::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Rename ActivityNode::redefinedElement to redefinedNode, replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see page 528 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9091: Replace {redefines redefinedElement} (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

StateMachine::extendedStateMachine (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see pages 530 -531 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9092: Replace {redefines redefinedElement} (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Region::extendedRegion (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see page 532 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9093: Replace {redefines redefinedElement} (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Transition::redefinedTransition (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see page 533 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9094: Replace {redefines redefinedElement} (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

State::redefinedState (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union). 

-> Replace {redefines redefinedElement} with {subsets redefinedElement}.

Resolution: see above
Revised Text: see page 534 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9095: Rename ActivityPartition::subgroup to subpartition (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityPartition::subgroup (non-derived) invalidly redefines ActivityGroup::subgroup (derived union). 

-> Rename ActivityPartition::subgroup to subpartition, replace {redefines subgroup} with {subsets subgroup}.

Resolution: see above
Revised Text: see pages 535 - 536 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9096: Change type of WriteStructuralFeatureAction::value (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

DurationObservationAction::duration (type Duration) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because Duration is not a specialization of InputPin. 

-> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

Resolution: see above
Revised Text: see pages 537 - 539 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

The type of WriteStructuralFeatureAction cannot be changed because it needs an input.
Thomas Weigert, October 31, 2005:
I suggest to resolve this by
(i) removing DurationObservationAction.value from figure 318 and remove the corresponding
passage from the Association section
(ii) add a constraint to DurationObservationAction
[1] DurationObservationAction.value.value must be a Duration
I think this is much cleaner as it (i) does not introduce a new metaclass and (ii) does not confuse
the pin with the value specification generating the value on the pin.
If we want, we can introduce a derived association "duration", which gives us the value
expression.
Please either
(i) in the constraint say that DurationObservationAction.value must be a ValuePin
or
(ii) redefine DurationObservationAction.value to go to a ValuePin in Fig 13.3. and add
corresponding text to Association subsection.

Issue 9097: Change type of WriteStructuralFeatureAction::value to ValueSpecification (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

TimeObservationAction::now (type TimeExpression) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because TimeExpression is not a specialization of InputPin. 

-> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

Resolution: see above
Revised Text: see pages 540 - 542 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

The type of WriteStructuralFeatureAction cannot be changed because it needs an input.
Thomas Weigert, October 31, 2005:
I suggest to resolve this by
(i) removing TimeObservationAction.value from figure 318 and remove the corresponding
passage from the Association section
(ii) add a constraint to TimeObservationAction
[1] TimeObservationAction.value.value must be a TimeExpression
I think this is much cleaner as it (i) does not introduce a new metaclass and (ii) does not confuse
the pin with the value specification generating the value on the pin.
If we want, we can introduce a derived association "now", which gives us the value expression.
Please either
(i) in the constraint say that TimeObservationAction.value must be a ValuePin
or
(ii) redefine TimeObservationAction.value to go to a ValuePin in Fig 13.3. and add corresponding
text to Association subsection.

Issue 9098: compliance levels L2 and L3 (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

In (merged) compliance levels L2 and L3, ExtensionEnd::lower (non-derived) invalidly redefines feature MultiplicityElement::lower (derived). 

-> Either remove this redefinition (of the default value) or add a Profiles package to UML and redefine ExtensionEnd::lower to be derived.

Resolution: see above
Revised Text: In the source model, add a subpackage named �Profiles� to the UML::AuxiliaryConstructs package. Add a class named �ExtensionEnd� to the new Profiles package. Add a derived attribute named �lower� to the new ExtensionEnd class with a default of 0. Create a package merge dependency between UML::AuxiliaryConstructs::Profiles and InfrastructureLibrary::Core::Profiles. Change the target of the package merge dependencies in compliance packages L2 and L3 from InfrastructureLibrary::Core::Profiles to UML::AuxiliaryConstructs::Profiles. Editor�s note: these are changes to the metamodel source; the external manifestation of these is covered by the resolution to issue 9182
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one. This redefinition was added by the RTF for
the purpose of overriding the default value for Property::lower (from 1 to 0).

Issue 9099: Rename InformationFlow::target (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

InformationFlow::target (non-derived) invalidly redefines DirectedRelationship::target (derived union). 

-> Rename InformationFlow::target to informationTarget and remove {redefines target}.

Resolution: see above
Revised Text: see pages 544 - 545 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9100: Rename InformationFlow::source (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

InformationFlow::source (non-derived) invalidly redefines DirectedRelationship::source (derived union). 

-> Rename InformationFlow::source to informationSource and remove {redefines source}.

Resolution: see above
Revised Text: see pages 546 - 547 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.

Issue 9103: Rename OpaqueAction::input to inputPin (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

OpaqueAction::input (non-derived) invalidly redefines Action::input (derived union). 

-> Rename OpaqueAction::input to inputPin.

Resolution: see above
Revised Text: see pages 548 - 549 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.
Conrad Bock, October 27, 2005:
Presumably this change should be made for output pins also. The
new name should be something like "inputValue" and "outputValue",
since the pin association are supposed to say something about the
expected inputs and outputs, rather than the target metaclassed,
which are alwasy the same.

Issue 9104: Rename LinkAction::input to inputPin (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

LinkAction::input (non-derived) invalidly redefines Action::input (derived union). 

-> Rename LinkAction::input to inputPin.

Resolution: see above
Revised Text: see page 550 - 551 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.
Conrad Bock, October 27, 2005:
Likewise, "inputPin" => "inputValue". Also the entry in the
LinkAction class description needs to be renamed.

Issue 9105: Make ActivityGroup::containedEdge a derived union (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityEdge::inGroup is a derived union but its opposite, ActivityGroup::containedEdge, is not. 

-> Make ActivityGroup::containedEdge a derived union. As a result, ActivityPartition::containedEdge and StructuredActivityNode::containedEdge will invalidly redefine ActivityGroup::containedEdge, so rename ActivityPartition::containedEdge to edge, rename StructuredActivityNode::containedEdge to ownedEdge, and replace {redefines containedEdge} with {subsets containedEdge} on both.

Resolution: see above
Revised Text: see pages 552 - 554 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

ActivityGroup::containedEdge should indeed be a derived union; the redefinitions are
invalid as per the consistency constraint � a non-derived property is inconsistent with a
derived one. Note also that ActivityPartition:edge should be multiplicity-many.

Issue 9106: Make ActivityGroup::containedNode a derived union (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityNode::inGroup is a derived union but its opposite, ActivityGroup::containedNode, is not. 

-> Make ActivityGroup::containedNode a derived union. As a result, ActivityPartition::containedNode, StructuredActivityNode::containedNode, and InterruptibleActivityRegion::containedNode will invalidly redefine ActivityGroup::containedNode, so rename ActivityPartition::containedNode to node, rename StructuredActivityNode::containedNode to ownedNode, rename InterruptibleActivityRegion::containedNode to node, and replace {redefines containedNode} with {subsets containedNode} on all three.

Resolution: see above
Revised Text: see pages 555 - 559 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

ActivityGroup::containedNode should indeed be a derived union; the redefinitions are
invalid as per the consistency constraint � a non-derived property is inconsistent with a
derived one. Note also that ActivityPartition:node should be multiplicity-many and that
SequenceNode::executableNode should be composite.

Issue 9107: Rename OpaqueAction::output to outputPin. (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

OpaqueAction::output (non-derived) invalidly redefines Action::output (derived union). 

-> Rename OpaqueAction::output to outputPin.

Resolution: see above
Revised Text: see pages 560 - 561 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

This redefinition is indeed invalid as per the consistency constraint � a non-derived
property is inconsistent with a derived one.
Conrad Bock, October 27, 2005:
Presumably this change should be made for output pins also. The
new name should be something like "inputValue" and "outputValue",
since the pin association are supposed to say something about the
expected inputs and outputs, rather than the target metaclassed,
which are alwasy the same.

Issue 9108: Rename ActivityGroup::activity to containingActivity (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

StructuredActivityNode inherits two properties with the same name, ActivityNode::activity and ActivityGroup::activity. 

-> Rename ActivityGroup::activity to containingActivity.

Resolution: see above
Revised Text: see pages 562 - 564 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

The property should indeed be renamed to resolve this conflict, otherwise the
distinguishable name constraint will be violated for StructuredActivityNode.
Conrad Bock, October 27, 2005:
To be consistent with the other end names, use "inActivity" rather
than "containingActivity".

Issue 9109: Component::realization should NOT be derived (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Component::realization should NOT be derived

Resolution: see above
Revised Text: see page 565 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Discussion:

Agreed, as this is the container for the realization relationships in which a component is
involved.

Issue 9110: Classifier::parameter, Operation::parameter, and ConnectableElement::parame (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Classifier::parameter, Operation::parameter, and ConnectableElement::parameter should be renamed to templateParameter (they redefine ParameterableElement::templateParameter) to make it clear that these are template parameters (in fact not related to the Parameter metaclass). ParameterableElement::owningParameter should also be renamed to owningTemplateParameter, for consistency.

Resolution: agreed
Revised Text: see page 566 - 569 of ptc/2006-04-01
Actions taken:
October 19, 2005: received issue
August 23, 2006: closed issue

Issue 9117: UML 2 issue: redefining isComposite on association ends (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The association ends IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be composite, since, redefining an isComposite = true property with one where isComposite = false causes problems in the XMI generation.   More on isComposite redefinition : 1) LinkEndCreationData::qualifier should be composite. 

2) It should be considered inconsistent for a non-composite property to redefine a composite property. The body expression for Property::isConsistentWith(RedefinableElement) should be updated as follows: 
This should probably be disallowed in general.

Resolution: see above
Revised Text: see page 571 - 573 of ptc/2006-04-01
Actions taken:
October 27, 2005: received issue
August 23, 2006: closed issue

Discussion:

Agreed � these properties are the containers for the constraints� specifications (as is the
case with Constraint::specification).
1) LinkEndCreationData will be addressed in a separate issue, 9123.
Conrad Bock, October 27, 2005:
I think LinkEndCreationData and QualifierValue
aren't supposed to be on this diagram:
- The associations to/from these aren't in the entries for
CreateLinkObjectAction of LinkEndCreationData,
- endData is inherited from CreateLinkAction and isn't changed.
- The qualifier association would clash with the one inherited from
LinkEndData in CompleteActivities. There is nothing in the spec on
why qualifier is specialized this way. - The multiplicity on qualifier would require qualifiers, even when
there aren't any.
I suppose this requires another issue.
2) The OCL should be updated as suggested.

Issue 9119: Realization classifier (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The Realization classifier should not be redefined in UML::Components::BasicComponents. In a component realization, the direction of the dependency is reversed, i.e. the client (source) of the dependency is the component abstraction and the supplier (target) of the dependency is the realizing classifier; this conflicts with other specializations of Realization (e.g. InterfaceRealization). 

-> A new specialization ('ComponentRealization') should be introduced instead, upon which the 'abstraction' and 'realizingClassifier' properties would be defined. This could be achieved by simply renaming Realization to 'ComponentRealization' in UML::Components::BasicComponents and adding a generalization from it to UML::Classes::Dependencies::Realization.

Resolution: see above
Revised Text: see pages 574 - 575 of ptc/2006-04-01
Actions taken:
October 26, 2005: received issue
August 23, 2006: closed issue

Discussion:

Agreed. Note that the lower bound of Realization::realizingClassifier is currently 1,
meaning that all interface realizations based on the current metamodel are effectively
invalid (because although they have an implementing classifier, they do not have a
realizing classifier since it is at the opposite end of the dependency).

Issue 9122: UML 2.1 Regressions (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following regressions were introduced in ballot 10: 

Issue 8134 

DeployedArtifact should NOT specialize Kernel::NamedElement since it already specializes Dependencies::NamedElement, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result). 

Issue 8136 

DeploymentSpecification should NOT specialize Artifacts::Artifact since it already specializes Nodes::Artifact, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result). 

Issue 8457 

The proposed new Figure 124 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Artifact (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 124 should be: 


 

The proposed new Figure 77 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Component (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 77 should be: 

 
Issue 8468 

UseCase::extend must NOT subset Classifier::feature because Extend is not a specialization of Feature. Likewise, UseCase::include must NOT subset Classifier::feature because Include is not a specialization of Feature.

Resolution: agreed
Revised Text: see pages 578 - 580 of ptc/2006-04-01
Actions taken:
October 27, 2005: received issue
August 23, 2006: closed issue

Issue 9123: Section: Actions, Figure 156 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Figure 156, I think LinkEndCreationData and QualifierValue aren't supposed to be on this diagram: - The associations to/from these aren't in the entries for CreateLinkObjectAction of LinkEndCreationData, - endData is inherited from CreateLinkAction and isn't changed. - The qualifier association would clash with the one inherited fromn LinkEndData in CompleteActivities. There is nothing in the spec on why qualifier is specialized this way. - The multiplicity on qualifier would require qualifiers, even when there aren't any.

Resolution:
Revised Text: In Actions, Figure 156, remove LinkEndCreationData and QualifierValue and the associations around LinkEndCreationData. Class entry for LinkEndCreationData, header, remove �, CompleteActions�.
Actions taken:
October 27, 2005: received issue
August 23, 2006: closed issue

Issue 9138: inconsistency wrt UML2 classifier behavior (uml2-rtf)

Click here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 13.6 - Common Behavior (page 412 of formal/05-07-04) shows BehavioredClassifier's ownedBehavior as a composition (black diamond) and it shows classifierBehavior as a directed association (no diamond).
 
no problem so far.
 
But then the figure also shows classifierBehavior subsets ownedBehavior, and the text says (page 420, section 13.3.4 BehavioredClassifer|Associations) that classifierBehavior specializes BehavioredClassifier.ownedBehavior).
 
If classifierBehavior is a specialization and the set of its instances is a subset, then the metaassociation denoting classifierBehavior should have the same association type as the superset, in other words for conssitency, both or neither should be black diamond. 
 
My assumption here is a form of the covariance thesis, a subset and specialization of a composition must also be a composition.

Resolution: In the UML 2.2 Specification, Behaviored::classifierBehavior is no longer specified in the text as "specializes BehavioredClassifier.ownedBehavior". Instead, it simply notes "subsets BehavioredClassifier::ownedBehavior", which is consistent with the diagram. The subset classifierBehavior association doesn't need to be composite, because it implies the superset ownedBehavior one (for the same behavior instance), which is composite, so composite semantics will apply anyway. Deleting an M1 classifier instance will delete the M1 behavior instance linked by the subset association, because that M1 classifier is also linked by the superset composite association. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
November 2, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9141: Section 8.3.2 sub-section "Notation" starting on page 149 (uml2-rtf)

Click here for this issue's archive.
Source: Cutter Information (Mr. Oliver Sims, osims(at)simsassociates.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue: 
The use of the keyword <<component>> on all diagrams in this section is inconsistent with standards used elsewhere in the spec (for example the notation shown in the Interfaces package). When a shape has the small component icon showing, the keyword is not required and arguably should not be shown. 
 
Rationale: 
The diagrams imply that both the icon and the keyword should always be shown. This is of course not the case. As it is, some tools vendors not only accept this incorrect implication but some have also mistaken the keyword for a stereotype. It would be much clearer if the keyword were only shown on component boxes that did NOT have the plug icon in them.  
 
Note that the notation shown on Page 152 (first page of section 8.4) is "correct" - i.e. much more appropriate, and less likely to mislead. On the other hand that shown on page 153 is "incorrect".

Resolution: The classifier notation of a component is defined showing the keyword "component" and optionally the component icon in the upper right corner. All examples in the component chapter of the UML 2.2. (ptc/2008-05-05) show the component with keyword and icon. However table 8.1 shows a component with an icon and without the keyword. This presentation option must be added to the component definition.
Revised Text: Section Notation, p. 151, first paragraph, add sentence at end of paragraph: If the icon symbol is shown, the keyword "component" could be hidden.
Actions taken:
September 10, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9142: Section 8 Issue - Component Realization-Classifier multiplicity (uml2-rtf)

Click here for this issue's archive.
Source: Cutter Information (Mr. Oliver Sims, osims(at)simsassociates.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue: The multiplicity on the relationship from Realization to Classifier is 1. This seems wrong - it should be 1 or more. 
 
Rationale: 
A component realization consisting of only a single classifier would be very odd - although not impossible for a Hello World component perhaps.

Resolution:
Revised Text: In document formal/07-11-02 on page145 change the diagram in Figure 8.2 with the following diagram: Also, on page 158, replace the following text � realizingClassifier : Classifier [1] A classifier that is involved in the implementation of the Component that owns this Realization. with the text: � realizingClassifier : Classifier [1..*] The classifiers that are involved in the implementation of the Component that owns this Realization.
Actions taken:
September 10, 2005: received issue
October 27, 2008: closed issue

Discussion:

The submitter seems to have missed the fact that it is possible to provide more than one ComponentRealization for a given Component. Nevertheless, it is useful to be able to model the case where a given Component might be realized by more than one implementation Classifier; i.e., by a combination of Classifiers. So, it is actually still useful to change this multiplicity to greater than 1. Change the multiplicity as per recommendation in the submission

Issue 9143: Section: 7.3.36 Operation (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The BNF for the textual specification of an operation does not allow one to specify the multiplicity of an operation's return type. The current BNF is [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] �{� <oper-property> [�,� <oper-property>]* �}�] It should allow the multiplicity to be specified in a manner similar to that for a property. For example: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] [�[� <multiplicity> �]�] �{� <oper-property> [�,� <oper-property>]* �}�]

Resolution:
Revised Text: In the Superstructure document (formal/07-11-02): Replace the following text on page 106: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] [�{� <oper-property> [�,� <oper-property>]* �}�]] with the following new text: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>][�[� <multiplicity> �]�] [�{� <oper-property> [�,� <oper-property>]* �}�]] In the Infrastructure document (formal/07-11-04): Replace the following text on page 154: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>] [�{� <oper-property> [�,� <oper-property>]* �}�]] with the following new text: [<visibility>] <name> �(� [<parameter-list>] �)� [�:� [<return-type>][�[� <multiplicity> �]�] [�{� <oper-property> [�,� <oper-property>]* �}�]]
Actions taken:
November 8, 2005: received issue
October 27, 2008: closed issue

Discussion:

The submitter is correct, since the return value is a kind of MultiplicityElement

Issue 9146: Section 7.2.1 of ptc/04-10-14 (uml2-rtf)

Click here for this issue's archive.
Source: Red Hat (Mr. John Verhaeg, jverhaeg(at)redhat.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 13 of section 7.2.1 of the "Unified Modeling Language (UML) Specification: Infrastructure" (ptc/04-10-14) states:
 
"There are minor differences in the design rationale for the other two packages."
 
There are actually 4 packages being discussed, with the first being PrimitiveTypes.  So, either "two" should be changed to "three" when referring to the "other" packages, or the two packages (amongst the "other" three being discussed) containing the "minor differences in design rationale" should be identified.

Resolution:
Revised Text: In the Infrastructure document (formal/07-11-04): On page 13, replace the text: There are minor differences in the design rationale for the other two packages. with the text: There are minor differences in the design rationale for the other three packages.
Actions taken:
November 10, 2005: received issue
October 27, 2008: closed issue

Discussion:

Yes, there are indeed 3 other packages

Issue 9172: Section: 15.3.15 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Given the current wording in the Constraints, Semantics, and Notation sections the "external" and "local" transition kind only applies to transitions with composite states as the source. This does then not leave any transition kind, except "internal", over for transitions with simple states or pseudostates as the source. As I understand it the "external" transition kind should also be available for transitions with simple states and pseudostates as the source. Thus, I think the constraint [2] should be removed and the wording in the Semantics and Notation sections should be changed to make it clear that the "external" transition kind is not reserved for transitions with composite states as the source.

Resolution: External transitions should be available for all vertices except entry points. Local transitions should be allowed for either composite states or entry points. Internal transitions must source/target a composite state, where source=target. The semantics and notation will need to be updated to slightly to reflect this change.
Revised Text: OCL contraint changes: section 15.3.15 page 589 (or 605 of 748) [1] A transition with kind local must have a composite state or an entry point as its source. context Transition inv: (kind = TransitionKind::local) implies ((source.oclIsKindOf (State) and source.oclAsType(State).isComposite) or (source.oclIsKindOf (Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint)) [2] A transition with kind external can source any vertex except entry points. context Transition inv: source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local) [3] A transition with kind internal must have a composite state as its source, and its source and target must be equal. context Transition inv: (kind = TransitionKind::internal) implies (source.oclIsKindOf (State) and source.oclAsType(State).isComposite and source = target) The notation section will change from Transitions of kind external will leave the border of the composite state and end at either a vertex outside the composite state or the composite state itself. Transitions of kind local will be on the inside of the frame of the composite state, leaving the border of the composite state and end at a vertex inside the composite state. Alternatively a transition of kind local can be shown as a transition leaving a state symbol containing the text "*." The transition is then considered to belong to the enclosing composite state. To be (same page as identified above) Transitions of kind external can target any vertex contained within or external to the source vertex. The part of the external transition closest to the source must be drawn outside of the source vertex border. In the case of an external self transition where the source is a state or exit point on the state, it may target the state itself or an entry point on the state and it will be drawn completely outside of the state border. All of the following transitions are external: Figure XXX - External Transitions Transitions of kind local will be on the inside of the frame of the composite state, leaving the border of the composite state, or one of its entry points, and end at a vertex inside the composite state. In the case of a local self transition, the target may be the source state itself, or an exit point on the source state. Alternatively a transition of kind local can be shown as a transition leaving a state symbol containing the text "*." The transition is then considered to belong to the enclosing composite state. All of the following transitions are local: Figure XXX - Local Transitions The semantics section will change from: kind=external implies that the transition, if triggered, will exit the composite (source) state. To be (same page) kind=external implies that the transition, if triggered, will exit the source vertex. Disposition: Resolved
Actions taken:
November 15, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:

see pages 68 - 71 of ptc/2009-09-07 for details

Issue 9179: Section: Appendix A: Diagrams (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

There's no diagram kind for deployment diagrams

Resolution:
Revised Text: In document formal/07-11-02 on page 683 insert the following bullet item in the list of frame names after the item ��component��: �h deployment Also, in the list of abbreviated forms, insert the following bullet item after the item ��cmp�� h dep (for deployment frames)
Actions taken:
November 26, 2005: received issue
October 27, 2008: closed issue

Discussion:

Agreed.

Issue 9180: UML 2.0 issue: Package Primitive Types not merged (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Package PrimitiveTypes is not merged into UML2 and there is no nsURI for InfrastructureLibrary. So there's no way to reference UML primitive types in any UML2 model including profiles. Resolve by merging PrimitiveType into L0.

Resolution:
Revised Text: se pages 582 - 583 of ptc/2006-04-01
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Issue 9181: UML 2.0 issue: Profile::ownedStereotype should be derived (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Profile::ownedStereotype should be derived (just like Package::/ownedType) from those ownedMembers which are Stereotypes.

Resolution:
Revised Text: see pages 584 of ptc/2006-04-01
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

Having Profile::ownedStereotype be non-derived will require tools to store a Stereotype
class in both the Profile::ownedStereotype and Package::ownedMember properties. This
would also have been the case for Package::ownedType merged from package Basic. But
this redundant information is removed by having Package::ownedType be derived from
Package::ownedMember where they type of the member is a Type or one of its
subclasses.

Issue 9182: UML 2.0: invalid package merge diagrams for compliance points (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

The diagrams in section 2 describing the compliance levels of UML 2, should show: 

(1) have a separate package for each level (instead of the "UML" package); e.g., L2 for level 2. 

(2) each package except L0 should also merge the package belonging to the immediately preceding level (e.g., L2 should merge package L1).

Resolution:
Revised Text: see pages 585 - 589 of ptc/2006-04-01
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

Note that this is related to issues 8459 and issue 9180.

Issue 9183: UML 2.0: separate profile application from profile importing (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Package::appliedProfile should not subset packageImport. Why not? A profile can be imported without being applied, but any applied profile is also implicitly imported in order to make the namespace visible. (The current assumption that a package import implies a profile application does not allow importing of profiles without application -- which might be required just for namespace purposes.) 

The simplest solution is to define ProfileApplication to be a subclass of DirectedRelationship with a meta-association (Profile::appliedProfile : Profile) indicating the applied profile

Resolution:
Revised Text: see pages 590 - 591 of ptc/2006-04-01
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

A profile can be imported without being applied in order to make its ownedMembers
visible without using fully qualified names, perhaps in an extending profile. An applied
profile should not be implicitly imported as applying multiple profiles to the same model
may result in name collisions.

Issue 9184: UML 2.0: CMOF/UML mixup for profiles (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

The end of the semantics section for Profiles informally describes a CMOF model equivalent to a Profile. This discussion in the spec about profiles and equivalent MOF metamodels could be confusing and potentially misleading. A profile is an instance of a UML2 model which is not a CMOF model. Therefore the MOF to XMI mapping rules do not apply for instances of a profile. The equivalent CMOF model is a means to explain and formalize how profiles are serialized and exchanged as XMI. The spec should make it clear that the equivalent MOF model is a model-to-model mapping being introduced as a means for describing how a profile is serialized and exchanged using XMI and how an XSD schema for validating instances of a profile is defined.

The mapping from a profile to a CMOF model is incomplete. For example, there is no statement that an instance of a stereotype maps to an instance of a CMOF::Class. This mapping needs to be completed; e.g., by direct reference

The Profile to CMOF mapping also needs to specify the XMI tags for persisting and exchanging profiles. According to the UML2 metamodel, instances of a Profile can't have Tags because an instance of a Profile is not a CMOF::Element, UML2 is not reflective. Tools will have to provide tag support for instances of stereotypes some other way. These properties can be left undefined and tools can provide values as needed. Another possible solution would be to specify how the XMI tag values and options for profile exchange would be defined, perhaps derived from other information in the profile. For example:
nsURI = http://<profilePackagePath>/schemas/<profileName>.xmi
nsPrefix = <profileName>
all others use the XMI defaults

Resolution:
Revised Text: In subsection �Using XMI to exchange Profiles� (section 18.3.6 in Superstructure (formal/05-07-04) and section13.1.6 in Infrastructure (ptc/04-11-16)), change the first and second sentences to: A profile is an instance of a UML2 metamodel, not a CMOF metamodel. Therefore the MOF to XMI mapping rules do not directly apply for instances of a profile. Figure 18.4 is an example of a mapping between a UML2 Profile and an equivalent CMOF model. This mapping is used as a means to explain and formalize how profiles are serialized and exchanged as XMI. Using this Profile to CMOF mapping, rules for mapping CMOF to XMI can be used indirectly to specify mappings from Profiles to XMI. In the mapping, a Profile maps to a CMOF Package. The Extension::metaclass Class, an instance of a MOF class, maps to itself. That is, a Class in the profile is also the same Class in the corresponding CMOF model, the identity transformation. A Stereotype maps to a MOF class with the same name and properties. The Extension maps to an Association as described in section 18.3.1, the Semantics subsection of Profile::Class. The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to the Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A recommended convention is: UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 9184 Document ptc/06-01-01 Page 580 � nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi where: o <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with . (dot) substituted for ::, and all other illegal XML QName characters removed, and o <profileName> is the name of the Profile. � nsPrefix = <profileName> � all others use the XMI defaults Editor�s note: Made a few editorial changes for readability Replace the example profile serialization starting on page 644 in Superstructure (formal/05-07-04) (page 175 in Infrastructure (ptc/04-11-16)) from <?xml version="1.0" encoding="UTF-8"?> <XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mof="http://schema.omg.org/spec/MOF/2.0" xmlns:uml="http://schema.omg.org/spec/UML/2.0"> <uml:Profile xmi:id="id1" name="HomeExample"> <ownedStereotype xsi:type="uml:Stereotype" xmi:id="id2" name="Home"> <ownedAttribute xmi:id="id3" name="base_Interface" association="id5" type=�id9�/> <ownedAttribute xmi:id="id4" name="magic" type=�id10�/> </ownedStereotype> <ownedMember xsi:type="uml:Extension" xmi:id="id5" memberEnd="id3 id6"> <ownedEnd xsi:type="uml:ExtensionEnd" name="extensionHome" xmi:id="id6" type="id2" association="id5" isComposite="true" lower="0"/> </ownedMember>  <metaclassReference xmi:id="id8"> <uml:elementImport xsi:type="uml:ElementImport" importedElement=�id9�/> </metaclassReference> </uml:Profile> <mof:Class xmi:id=�id9� href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> <mof:PrimitiveType xmi:id=�id10� href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/> <mof:Tag name="org.omg.xmi.nsURI" value="http://www.mycompany.com/schemas/HomeExample.xmi" element="id1"/> <mof:Tag name="org.omg.xmi.nsPrefix" value="HomeExample" element="id1"/> <mof:Tag name="org.omg.xmi.xmiName" value="base_Interface" element="id3"/> </XMI> to: <?xml version="1.0" encoding="UTF-8"?> <uml:Profile xmi:version="2.1" nsURI="http://HomeExample.xml" nsPrefix="HomeExample" xmlns:uml="http://schema.omg.org/spec/UML/2.0/uml.xml" xmi:id="id0" name="HomeExample" metamodelReference="id2"> <packageImport xmi:id="id2"> <importedPackage href= "http://schema.omg.org/spec/UML/2.0/uml.xml "/> </packageImport> <ownedMember xmi:type="uml:Stereotype" xmi:id="id3" name="Home"> <ownedAttribute xmi:type="uml:Property" xmi:id="id5" name="base_Interface" association="id6"> <type href="http://schema.omg.org/spec/UML/2.0/uml.xml #Interface"/> </ownedAttribute> <ownedAttribute xmi:type="uml:Property" xmi:id="id4" name="magic"> <type href="http://schema.omg.org/spec/UML/2.0/uml.xml #String"/> </ownedAttribute> </ownedMember> <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id4 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember> </uml:Profile> Editor�s note: changed references to 2.0 over to 2.1 Change the example XSD on page 645 in Superstructure (formal/05-07-04) (176 in Infrastructure (ptc/04-11-16)) from: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace = "http://www.mycompany.com/schemas/HomeExample.xmi" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://www.omg.org/spec/UML/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://schema.omg.org/spec/XMI/2.1" schemaLocation="XMI.xsd"/> <xsd:import namespace="http://schema.omg.org/spec/UML/2.0" schemaLocation="UML20.xsd"/> <xsd:complexType name="Home"> <xsd:choice minOccurs="0" maxOccurs ="unbounded"> <xsd:element name="base_Interface" type="xmi:Any"/> <xsd:element name="magic" type="xsd:string"/> <xsd:element ref="xmi:Extension"/> </xsd:choice> <xsd:attribute ref="xmi:id"/> <xsd:attributeGroup ref="xmi:ObjectAttribs"/> <xsd:attribute name="base_Interface" type="uml:Interface" <xsd:attribute name="magic" type="xsd:string" use="optional"/> use="optional"/> </xsd:complexType> <xsd:element name="Home" type="Home"/> </xsd:schema> to: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace = "http://www.mycompany.com/schemas/HomeExample.xmi" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://schema.omg.org/spec/UML/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://schema.omg.org/spec/XMI/2.1" schemaLocation="XMI.xsd"/> <xsd:import namespace="http://schema.omg.org/spec/UML/2.0" schemaLocation="UML20.xsd"/> <xsd:complexType name="Home"> <xsd:choice minOccurs="0" maxOccurs ="unbounded"> <xsd:element name="base_Interface" type="xmi:Any"/> <xsd:element name="magic" type="xsd:string"/> <xsd:element ref="xmi:Extension"/> </xsd:choice> <xsd:attribute ref="xmi:id"/> <xsd:attributeGroup ref="xmi:ObjectAttribs"/> <xsd:attribute name="base_Interface" type="uml:Interface" <xsd:attribute name="magic" type="xsd:string" use="optional"/> use="optional"/> </xsd:complexType> <xsd:element name="Home" type="Home"/> </xsd:schema> Editor�s note: changed references to 2.0 over to 2.1 Change the XMI serialization of the ClientPackage from: <?xml version="1.0" encoding="UTF-8"?> <XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://schema.omg.org/spec/UML/2.0 " xmlns:HomeExample="http://www.mycompany.com/schemas/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <ownedMember xsi:type="uml:Interface" xmi:id="id2" name="Client"/> <packageImport xsi:type="uml:ProfileApplication" xmi:id="id3"> <importedProfile href="HomeExample.xmi#id1"/> </packageImport> </uml:Package>  <HomeExample:Home base_Interface="id2" magic="1234"/> </XMI> to: <?xml version="1.0" encoding="UTF-8"?> <xmi xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://schema.omg.org/spec/UML/2.0 " xmlns:HomeExample="http://www.mycompany.com/schemas/HomeExample.x mi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="HomeExample.xmi#id0"/> </profileApplication> <ownedMember xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>  <HomeExample:Home base_Interface="id2" magic="1234"/> </xmi> Editor�s note: changed references to 2.0 over to 2.1 and added id for HomeExample:Home
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Issue 9185: UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

ownedMember xsi:type="uml:Stereotype" should be used in XMI instance documents instead of ownedStereotype xsi:type="uml:Stereotype" (especially if it becomes a derived subset).

Resolution:
Revised Text: In the example under Using XMI to exchange Profiles on page 644 in Superstructure (formal/05-07-04) (175 in Infrastructure (ptc/04-11-16)), change: <ownedStereotype xsi:type="uml:Stereotype" xmi:id="id2" name="Home"> <ownedAttribute xmi:id="id3" name="base_Interface" association="id5" type=�id9�/> <ownedAttribute xmi:id="id4" name="magic" type=�id10�/> </ownedStereotype> To: <packagedElement xsi:type="uml:Stereotype" xmi:id="id2" name="Home"> <ownedAttribute xmi:id="id3" name="base_Interface" association="id5" type=�id9�/> <ownedAttribute xmi:id="id4" name="magic" type=�id10�/> </packagedElement> Editor�s note: note done: this was already resolved by the resolution to 9184
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

See the resolution to issue 9183.

Issue 9186: UML 2.0: Inconsistencies in profile example XMI (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

In the Home Example for Profiles in chapter 18, the body of the text and the examples use different conventions for naming ExtensionEnds "base$Interface", "base_Interface", and "baseInterface" all appear in various places. The spec says it should be base$Interface (although this is not a valid identifier in many common programming languages including Java).

Resolution:
Revised Text: Section 18.3.2 Extension in Superstructure (formal/05-07-04) (13.1.3 in Infrastructure (ptc/04-11-16)), subsection Semantics, change: The name of the role of the extended metaclass is:�base$� extendedMetaclassName The name of the role of the extension stereotype is:�extension$� stereotypeName to: The name of the role of the extended metaclass is:�base_� extendedMetaclassName The name of the role of the extension stereotype is:�extension_� stereotypeName and change: self.baseInterface.ownedAttributes->size() = 0 to: self.base_Interface.ownedAttributes->size() = 0 In figure 18.4 in Superstructure (formal/05-07-04) (figure 111 in Infrastructure (ptc/04- 11-16)), change �base$Interface� to �base_Interface� and �extension$Home� to �extension_Home�.
Actions taken:
November 28, 2005: received issue
August 23, 2006: closed issue

Discussion:

In order to reduce the possibility of naming problems in various programming languages,
base_<extendedMetaclassName> and extension_<stereotypeName> should be used
throughout.

Issue 9187: UML 2.1 XMI Issue (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

uml::EncapsulatedClassifier::ownedPort should be derived (from the owned attributes that are instances of Port) so as to be consistent with Package::ownedType, Package::nestedPackage, and Profile::ownedStereotype (see issue 9181).

Resolution:
Revised Text: see page 598 of ptc/2006-04-01
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Issue 9188: uml::Extension::ownedEnd should not subset uml::Association::ownedEnd (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

uml::Extension::ownedEnd should not subset uml::Association::ownedEnd since it already (implicitly) redefines it. 

There should be a constraint that states that it is invalid for a property to subset a property with the same name.

Resolution:
Revised Text: see pages 599 - 600 of ptc/2006-04-01
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Discussion:

This error appears also in state machines figure 15.3.

Issue 9189: Artifact::fileName (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Artifact::fileName appears in the metamodel but is not documented in the specification.

Resolution:
Revised Text: On page 193 of the superstructure document (formal/05-07-04) in the Attributes subsection of Artifact (section 10.3.1) replace the word �filename� with the word �fileName�. Editor�s note: already done by 8132
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Issue 9190: Parameter::effect (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Parameter::effect is documented in the specification as having multiplicity 0..* (instead of 0..1 - this should have been addressed as part of Issue 8261).

Resolution:
Revised Text: In the Attributes subsection of parameter (section 12.3.41) replace the multiplicity of the �effect� item from [0..*] to [0..1]
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Issue 9191: Required attributes (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Required attributes (i.e. those with a lower bound greater than 0) without a specified default must either be assigned a default or made non-required (see below). There should also be a statement in the specification to the effect that attributes whose values are set to their default need not be serialized. 

uml::Artifact::fileName is required, default is <unspecified> 

uml::Behavior::isReentrant is required, default is <unspecified> 

uml::BehavioralFeature::concurrency is required, default is <unspecified> 
uml::BehavioralFeature::isAbstract is required, default is <unspecified> 

uml::Class::isActive is required, default is <unspecified> 

uml::CombinedFragment::interactionOperator is required, default is <unspecified> 

uml::Comment::body is required, default is <unspecified> 

uml::ConditionalNode::isAssured is required, default is <unspecified> 
uml::ConditionalNode::isDeterminate is required, default is <unspecified> 

uml::DeploymentSpecification::deploymentLocation is required, default is <unspecified> 
uml::DeploymentSpecification::executionLocation is required, default is <unspecified> 

uml::ElementImport::visibility is required, default is <unspecified> 

uml::ExpansionRegion::mode is required, default is <unspecified> 

uml::Expression::symbol is required, default is <unspecified> 

uml::GeneralizationSet::isCovering is required, default is <unspecified> 
uml::GeneralizationSet::isDisjoint is required, default is <unspecified> 

uml::LiteralBoolean::value is required, default is <unspecified> 

uml::LiteralInteger::value is required, default is <unspecified> 

uml::LiteralString::value is required, default is <unspecified> 

uml::LiteralUnlimitedNatural::value is required, default is <unspecified> 

uml::LoopNode::isTestedFirst is required, default is <unspecified> 

uml::Message::messageKind is required, default is <unspecified> 
uml::Message::messageSort is required, default is <unspecified> 

uml::Model::viewpoint is required, default is <unspecified> 

uml::OpaqueAction::body is required, default is <unspecified> 

uml::OpaqueBehavior::body is required, default is <unspecified> 

uml::OpaqueExpression::body is required, default is <unspecified> 

uml::PackageableElement::visibility is required, default is <unspecified> 

uml::PackageImport::visibility is required, default is <unspecified> 

uml::Pseudostate::kind is required, default is <unspecified> 

uml::State::isComposite is required, default is <unspecified> 
uml::State::isOrthogonal is required, default is <unspecified> 
uml::State::isSimple is required, default is <unspecified> 
uml::State::isSubmachineState is required, default is <unspecified> 

uml::StructuredActivityNode::mustIsolate is required, default is <unspecified> 

uml::TimeEvent::isRelative is required, default is <unspecified> 

uml::Transition::kind is required, default is <unspecified>

Resolution:
Revised Text: see pages 604 - 607 of ptc/2006-04-01
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Issue 9192: The following properties should not subset DirectedRelationship::source (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following properties should not subset DirectedRelationship::source since they subset Dependency::client, which already subsets DirectedRelationship::source: 

ComponentRealization::abstraction 
Deployment::location 
InterfaceRealization::implementingClassifier 
Substitution::substitutingClassifier

Resolution:
Revised Text: see pages 608 - 610 od ptc/2006-04-01
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Discussion:

This resolution is coordinated with the resolution to issue 9193.

Issue 9193: The following properties should not subset DirectedRelationship::target (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following properties should not subset DirectedRelationship::target since they subset Dependency::supplier, which already subsets DirectedRelationship::target: 

ComponentRealization::realizingClassifier 
Deployment::deployedArtifact 
InterfaceRealization::contract 
Manifestation::utilizedElement 
Substitution::contract

Resolution:
Revised Text: see page 611 of ptc/2006-04-11
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Discussion:

This resolution is coordinated with the resolution to issue 9192.

Issue 9194: Compliance package L2 does not merge StructuredActions in the metamodel (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Compliance package L2 does not merge StructuredActions in the metamodel. Also, CompleteActions (merged by L3) does not currently merge StructuredActions. 

In general, higher compliance levels should merge lower compliance levels; the merge relationships in the specification should be reorganized to reflect this.

Resolution: Resolved by the solution to issue 9182
Revised Text:
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Issue 9195: parameter of operation isRedefinitionContextValid() is inconistently named (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The parameter of operation isRedefinitionContextValid() is inconistently named in the specification, which in turn cause package merge problems (parameters do not match). The parameter should be consitently named 'redefined', and the OCL for the associated constraints updated accordingly.

Resolution:
Revised Text:
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Discussion:

This seems to be because the metamodel was using the old OCL that was fixed as part of
the resolution to issue 7054. That problem was fixed in the FTF.
Disposition: Closed, no change

Issue 9196: Transition guards cannot currently be evaluated because they have no contex (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Transition guards cannot currently be evaluated because they have no context. Transition should be made a specialization of Namespace and Transition::guard should subset Namespace::ownedRule

Resolution:
Revised Text: see ages 613 - 614 of ptc/2006-04-01
Actions taken:
November 29, 2005: received issue
August 23, 2006: closed issue

Discussion:

Indeed. Currently, Transition is only a subclass of NamedElement.

Issue 9197: Issue regarding "Action::effect : String" (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

What has become of the dropped property :  "Action::effect : String" ?  ( referenced in Ballot 7319 )

Resolution:
Revised Text:
Actions taken:
November 30, 2000: received issue
August 23, 2006: closed issue

Discussion:

This property was removed in the FTF..
Disposition: Closed, no change

Issue 9198: Behavior::context (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Behavior::context is derived (ensure that this is indicated in the diagram and the text); it should also be read-only.

Resolution:
Revised Text: see page 615 of ptc/2006-04-01
Actions taken:
December 1, 2005: received issue
August 23, 2006: closed isuse

Discussion:

This is because the context for a behavior has to be the BehavioredClassifier that owns it.
Also, a Behavior cannot change its context, which is why it is read only.

Issue 9224: StateMachine::extendedStateMachine should have a multiplicity of 0..*. (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

StateMachine::extendedStateMachine should have a multiplicity of 0..*. It currently does in the text, but it is shown with a multiplicity of 0..1 in Figure 15.3.

Resolution:
Revised Text: Change the multiplicity of StateMachine::extendedStateMachine in Figure 15.3 to 0..*
Actions taken:
December 8, 2005: received issue
August 23, 2006: closed issue

Discussion:

This is in reference to the possibility that a state machine may extend (i.e., inherit from)
more than one other state machine (see page 548 in the spec � last paragraph in the
StateMachine Extension subsection).

Issue 9232: Page: 161 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 9.7: property "representation" subsets "collaborationUse" not "occurrence"? "Classifier" has no property named "occurrence"!

Resolution: Discussion: This issue has already been fixed in the current version of the specification. Disposition: Closed, no change
Revised Text:
Actions taken:
December 12, 2005: received issue
October 27, 2008: closed issue

Issue 9233: On page 26, Figure 7.9 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

On page 26, Figure 7.9 there an association between 'Property' and 'Classifier'. The end 'classifier' is non-navigable. 'classifier' subsets 'redefinitionContext'. This means the following constraint of 'Property' is violated: subsettedProperty->exists(sp | sp.isNavigable()) implies isNavigable())

Resolution: The noted Property constraint is no longer present in the UML 2.2 specification. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
December 12, 2005: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9235: Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember" (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

Resolution: Discussion: This was resolved in some previous revision. Disposition: Closed, no change
Revised Text:
Actions taken:
December 12, 2005: received issue
October 27, 2008: closed issue

Issue 9241: Operation::ownedParameter should be ordered in XMI? (uml2-rtf)

Click here for this issue's archive.
Source: Fulcrum Analytics, Inc. (Mr. Richard Vermillion, rvermillion(at)fulcrumanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the latest XMI file (included as part of Ballot 12) the  
ownedParameter attribute of Core::Constructs::Operation redefines  
Core::Constructs::BehavioralFeature::ownedParameter -- I'm assuming  
that this redefinition is a result of the merge of Basic.


However, in Operation, the ownedParameter attribute is not ordered.


Since both BehavioralFeature::ownedParameter and  
Core::Basic::Operation::ownedParameter are ordered, it seems strange  
for Core::Constructs::Operation's not to be ordered.  A check of the  
drafts and ballots does not seem to address this issue or explain why  
it would be the case.  Is it a mistake?

Resolution: Infra::Core::{Basic,Constructs}::Operation::ownedParameter {isOrdered=true} in UML 2.2 CMOF. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
January 15, 2006: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 9243: XMI file: Core::Constructs::Operation::bodyCondition should have upper boun (uml2-rtf)

Click here for this issue's archive.
Source: Fulcrum Analytics, Inc. (Mr. Richard Vermillion, rvermillion(at)fulcrumanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the XMI file sent out with Ballot 12, the bodyCondition attribute  
of Core::Constructs::Operation has upper="*" when it should be  
upper="1".


See line 3009 of Infrastructure.cmof:


          <ownedAttribute xmi:type="cmof:Property" xmi:id="Core- Constructs-Operation-bodyCondition" name="bodyCondition" lower="0"  
upper="*" type="Core-Constructs-Constraint" association="Core- Constructs-A_bodyCondition_bodyContext" subsettedProperty="Core- Constructs-Namespace-ownedRule" isComposite="true"/>


In Superstructure, Classes::Kernel::Operation seems to correctly have  
an upper bound of 1 for bodyCondition.


Again, apologies for the late notice on this issues.  If there is a  
better way to report these, please let me know.  I'm sending them to  
the list because I assume some can be made as editorial changes by  
Bran, while others should be opened as new issues for UML 2.2.

Resolution: Infra::Core::Constructs::Operation::bodyCondition : Constraint[0..1] in UML 2.2 CMOF. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
January 16, 2006: received issue
April 26, 2010: closed issue

Issue 9249: 7.3.4 Association Class (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The specification should state when navigation between an association class and the endpoints of that association class are allowed. When there is an association class between two classes, OCL allows navigation between these classes and the association class itself (see Sections 7.5.4 and 7.5.5 of the OCL 2.0 specification ptc/2005-06-06). However, navigability in UML2 is defined with respect to the metaclass Property and the semantics describe navigability in terms of navigating across an association via a property, i.e., from one endpoint to the other (see the definition of isNavigable() in Section 7.3.44, subsection Additional Operations, and descriptions of navigability in sections 7.3.3 - Association, 7.3.7 - Class, and 7.3.44 � Property.) No mention of navigability to and from association classes is found in section 7.3.4 � Association Class, nor any place else in the specification. One simple possibility would be for navigation involving association classes to respect navigation between its endpoints. For example, if classes C1 and C2 are connected by an association class A, then if one can navigate from C1 to C2 (C1->C2), then one can navigate from C1 to A (C1->A) and from A to C2 (A->C2). Another simple possibility would be to always allow navigation from an association class to its endpoints while requiring navigation from an endpoint to the association class to respect navigability. For example, if the association is one-way navigable from C1 to C2 (C1->C2) then one could navigate from C1 to A (C1->A) and from A to C2 (A->C2) as above and, in addition, from A to C1 (A->C1). Anything more complex than these two simple alternatives requires deeper investigation into the semantics of the UML metamodel or even changing the metamodel. For example, the association ownedEnd: Property for Association in section 7.3.3 could subset Classifier::attribute instead of Classifier::feature. Or in the definition of Association Class in 7.3.4 one could allow the inherited associations ownedAttribute: Property and ownedEnd: Property to overlap, i.e., be non-disjoint, although this may have technical difficulties because these two associations are compositions.

Resolution:
Revised Text:
Actions taken:
January 19, 2006: received issue
April 25, 2011: closed issue

Discussion:

The specification states that an AssociationClass specializes both Class and Association. Therefore the rules for composition, navigability and property ownership for AssociationClass are the same as Association.
Disposition: Closed, no change

Issue 9337: 7.3.41 Parameter (from Kernel, AssociationClasses)" (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

Resolution:
Revised Text: In the Superstructure document (formal/07-11-02): On page 120, in the heading 7.3.41, replace the text: (from Kernel, AssociationClasses) with the text: (from Kernel)
Actions taken:
January 30, 2006: received issue
October 27, 2008: closed issue

Discussion:

The submitter is correct

Issue 9338: 7.3.41 Parameter (from Kernel, AssociationClasses)" (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

Resolution: This is an exact duplicate of issue 9337 Revised Text: N/A Disposition: Duplicate
Revised Text:
Actions taken:
October 27, 2008: closed issue

Issue 9341: reference to Figure 12.87 missing (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Last para on p385 starts: "Figure 12.86 shows a fragment of a Fast Fourier Transform (FFT) computation containing an expansion region. Outside the region, there are operations" - the reference should be to Figure 12.87

Resolution: agreed
Revised Text: In Section 12.3.27 (ExpansionRegion), in the paragraph immediately preceding Figure 12.87, first sentence, replace "Figure 12.86" with "Figure 12.87".
Actions taken:
January 24, 2006: received issue
April 26, 2010: closed issue

Issue 9352: UML 2 Superstructure / CommonBehaviors / Incorrect types in text (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

TimeConstraint::specification and DurationConstraint::specification properties are shown as having the wrong type in the text (the diagrams are OK). They should be TimeInterval and DurationInterval respectively.

Resolution: Resolution: This issue has been resolved in an earlier version of the specification. Disposition: Closed, no change
Revised Text:
Actions taken:
February 2, 2006: received issue
October 27, 2008: closed issue

Issue 9373: Use the new 'dot' notation in examples (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

Resolution: This is a duplicate of issue 9372
Revised Text:
Actions taken:
February 23, 2006: received issue
October 27, 2008: closed issue

Issue 9374: AssociationClass is severely underspecified (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is not at all clear which Properties will result on both the AssociationClass and the end Classes. The Semantics section of 7.3.4 says nothing more specific than "The semantics of an association class is a combination of the semantics of an ordinary association and of a class." - without saying anything about *how* they are combined. neither is there any indication as to how to access the attributes of the AssociationClass.
One specific issue is that the composition property is inherited twice: ownedEnd and ownedAttribute - with no redefinition or subsets relationship between them.
Neither is anything said about the effect of navigability.
 
Proposed resolution:
 
AssociationClass should redefine ownedNavigableEnd
 
In the example in 7.3.4 the following properties will result. C::P indicates here that C owns P via the Class:ownedAttribute property. In this case both ends are owned by the class not the association (though the absence of dots at the line ends would imply otherwise - the example should be redrawn).
Several extra properties are implied by the diagram and have to be implicitly created by the tool. These are marked !! below.
 
    Person::company: Company[1..*]  association=Job
    !!Person::job: Job[1..*]  // This then allows access to the properties of Job such as Salary. Note that Person::job.association isEmpty
 
    Company::person: Person[*] association=Job
    !!Company::job: Job[*] 
 
    Job::salary: Integer[1]
    !!Job::person: Person[1]
    !!Job::company: Company[1]
    Job.memberEnd=(Person::company, Company::person)
    Job.ownedEnd->isEmpty=true
    
There needs to be a discussion and clear rules for the invented names for the new properties and constraints to avoid clashes. Also need to address issues related to unions/subsets/redefines/navigability and their effect on the implicit properties.
 
Also there is a complication if the Association class itself has further associations: how in the metamodel are these Properties on t he AssociationClass distinguished from the 'main' Ends representing the line to which the AC is attached.

Resolution: For explanations, see "Changes from previous UML" below. The OCL in this resolution is written according to OCL 2.1 ptc-09-05-02. Where the changes in the revised text pertain to metaclasses in the superstructure merged from InfrastructureLibrary::Core::Constructs which is the resulting package of merging several package increments from InfrastructureLibrary::Core::Abstractions as specified in clause 11.2 of the UML 2.2 Infrastructure, then the revisions described below have to be similarly reflected in InfrastructureLibrary::Core::Constructs (i.e. the resulting metaclass) and in the metaclass increments merged from the sub-packages of InfrastructureLibrary::Core::Abstractions. The revised text clarifies that owned ends of an association class, as an association, are disjoint from owned attributes of that same association class.. Navigability for association classes is the same as associations. Navigation from instances of association classes to their end objects, and any other unaddressed aspects of the issue, will be refiled as a separate issue. This resolution includes an OCL constraint which depends on the OCL 2.1 revision: context AssociationClass self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) The meaning of this constraint is as follows: self.A_general_classifier::classifier This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*]. That is, it provides the set of classifiers that specialize 'self'. See 7.5.3 (Properties: AssociationEnds and Navigability), p. 18-19 in OCL 2.1 http://www.omg.org/cgi-bin/doc?ptc/09-05-02
Revised Text: In 7.3.3, replace the text describing Association, currently: "An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link." By: "An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end." In 7.3.3, replace the second constraint of Association, currently: "[1] An association specializing another association has the same number of ends as the other association. self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size())" By: "[1] An association specializing another association has the same number of ends as the other association. parents()->select(oclIsKindOf(Association)) ->forAll(p | p.memberEnd->size() = self.memberEnd->size())" In 7.3.3, replace the second constraint of Association, currently: "[2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end." By: "[2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end. Sequence{1..self.memberEnd->size()} ->forAll(i|self.general->select(oclIsKindOf(Association))->forAll(ga| self.memberEnd->at(i).type.conformsTo(ga.memberEnd->at(i).type)) " In 7.3.3, before the note in Association.Semantics, currently: "Note - For n-ary associations, the lower multiplicity of an end is typically 0. A lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends." insert the following paragraph: "The combination of constraints [1,2] above with the semantics of property subsetting and redefinition specified in 7.3.44 in constraints [3,4,5] imply that any association end that subsets or redefines another association end forces the association of the subsetting or redefining association end to be a specialization of the association of the subsetted or redefined association end respectively." In 7.3.3, remove the last semantic variation point in Association, currently: "o The interaction of association specialization with association end redefinition and subsetting is not defined." In 7.3.4, add new constraints at the end of AssociationClass.Constraints: [2] In a generalization hierarchy, the specializations of an AssociationClass must be a kind of AssociationClass. In particular, it is not allowed for a Class or an Association to specialize an AssociationClass. The following constraint navigates from the non-navigable end of the A_general_classifier association for the AssociationClass (self) to retrieve its specialized classifiers (A_general_classifier::classifier). self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) [3] The owned attributes and owned ends of an AssociationClass are disjoint ownedAttribute->intersection(ownedEnd)->isEmpty() In 7.3.4, replace the paragraph for AssociationClass.Description, currently: "In the metamodel, an AssociationClass is a declaration of a semantic relationship between Classifiers, which has a set of features of its own. AssociationClass is both an Association and a Class." By: " An AssociationClass is a declaration of a semantic relationship between Classifiers, which has a set of features of its own. AssociationClass is both an Association and a Class. An AssociationClass describes a set of objects that each share the same specifications of features, constraints, and semantics entailed by the AssociationClass as a kind of Class, and correspond to a unique link instantiating the AssociationClass as a kind of Association. An AssociationClass specifies a Class whose instances are in 1-1 correspondence with a semantic relationship that can occur between typed instances. An AssociationClass preserves the static and dynamic semantics of both an Association and of a Class." In 7.3.4, remove the subclause AssociationClass.Additional Operations, currently: "Additional Operations [1] The operation allConnections results in the set of all AssociationEnds of the Association. AssociationClass::allConnections ( ) : Set ( Property ); allConnections = memberEnd->union ( self.parents ()->collect (p | p.allConnections () )" In 7.3.4, at the end of the second paragraph of AssociationClass.Semantics, add: "Redefinition is applicable to an association class nested in the context of a classifier just as it is applicable to a nested class." In 7.3.4, at the end of AssociationClass.Semantics, replace the note, currently: Note - It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e., from the instance point of view, the multiplicity of the associations ends are '1.' By: An AssociationClass inherits the composite properties Class::ownedAttribute and Association::ownedEnd, which cannot share values. Values of ownedAttribute are properties that are attributes of the class, not ends of the association class owned through Association::ownedEnd. Values of Association::ownedEnd are the ends of the association owned by the association class, not attributes of the association class. This means the ends of the association class that it owns cannot be used to navigate from instances of the association class to the objects on their ends. As association ends, they can be used for navigation between end objects, as in all associations, depending on whether they are navigable, see Navigability in the semantics of Association in 7.3.3.. An object instance of an association class is in 1-1 correspondence with a unique link representing an instantiation of the association class as a kind of association. When one or more ends of the association class have isUnique=false, it is possible to have several links associating the same set of instances of the end classes. In such a case, the links of an association class instance carry their corresponding association class instance as their unique identifier apart from their end values. An association class cannot be the general classifier of an association or a class." In 7.3.4, in the AssociationClass.Notation subclause, add the following at the end of the first paragraph: Association end names appear in the same position as regular associations, not in the attribute compartment of the association class. In 7.3.4, after the AssociationClass.Notation subclause, add the following sub clause: "Changes from previous UML AssociationClass was underspecified in prior UML. The guiding principle used for improving the specification of association class is that of preserving the static and dynamic semantics of both associations and classes in clarifying the static and dynamic semantics of association class. This guiding principle has important implications on the changes made in this clause as explained below The changes are: 1) Constraint [1] in 7.3.3 Association changed to accommodate the fact that an AssociationClass can legitimately specialize a regular Class. 2) Constraint [2] in 7.3.3 Association has an OCL specification that applies for both Association and AssociationClass. 3) Two constraints are added to AssociationClass, the first for the allowed specializations of AssociationClasses, and the second for disjointness of ownedEnd and ownedAttribute. 4) The previous semantic variation point about the interaction between association specialization and association end redefinition and subsetting is removed because the semantics of subsetting and redefinition for association end properties have been sufficiently clarified. 5) The operation AssociationClass::allConnections() is removed, because it is redundant with constraints [1,2] specified in 7.3.3 for Association and constraints [3,4,5] specified in 7.3.44 for Property as explained in the semantics of 7.3.3 for Association. It also inadvertently removed ordering of association ends." Disposition: Resolved
Actions taken:
February 23, 2006: received issue
April 26, 2010: closed issue

Issue 9375: Section: 7.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Incorrect specification of association Class::nestedClassifier. The specification of the association Class::nestedClassifier, section 7.3.7, page 46 states that it subsets Element::ownedMember. The Class Element does not have an association ownedMember. Element does have an association ownedElement, but that is not likely correct because a nested classifier is really a namedElement. Most likely, Class::nestedClassifier should subset Namespace::ownedMember.

Resolution: See issue 10829 for disposition
Revised Text:
Actions taken:
February 23, 2006: received issue
April 25, 2011: closed issue

Issue 9395: Fig 12.10 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Fig 12.10 shows Activity.partition with multiplicity 1 but the text on page 329 shows [0..*].I suspect that the former is correct.

Resolution: This was resolved in the final resolution of issue 8208 in UML 2.1. (It was actually 0..* that was correct.) Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
February 23, 2006: received issue
April 26, 2010: closed issue

Issue 9398: UML 2/Templates -- single argument? (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

A TemplateParameterSubstitution corresponds to exactly one template parameter, but the metamodel allows multiple actual arguments to be supplied for the parameter. There does not seem to be any compelling reason for multiple arguments to be provided for a single template parameter in a substitution (nor are the semantics of this clearl). Therefore, the multiplicity of TemplateParameterSubstitution::actual and Template ParameterSubstitution::ownedActual should be restricted to [1].

Resolution:
Revised Text: Superstructure (ptc/07-02-05) On page page 624 section 14.5.5 Change: actual: ParameterableElement[1..*] �The elements that are the actual parameters for this substitution�. To: actual : ParameterableElement[1] �The element that is the actual parameter for this substitution� Change ownedActual : ParameterableElement[0..*] The actual parameters that are owned by this substitution. Subsets Element::ownedElement and actual. To: ownedActual : ParameterableElement[0..1] The actual parameter that is owned by this substitution. Subsets Element::ownedElement and actual. Change Semantics section on p.624 From: �A TemplateParameterSubstitution specifies the set of actual parameters to be substituted for a formal template parameter within the context of a template binding.� To: �A TemplateParameterSubstitution specifies the actual parameter to be substituted for a formal template parameter within the context of a template binding.� Section 15.5.5 Change: A template parameter substitution relates the actual parameter(s) to a formal template parameter as part of a template binding. To: A template parameter substitution relates the actual parameter to a formal template parameter as part of a template binding.
Actions taken:
February 24, 2006: received issue
October 27, 2008: closed issue

Discussion:

Possibly just change the multiplicities of TemplateParameterSubstitution::actual and ParameterSubstitution::ownedActual to [1] as mentioned above since it is unclear how substitutions involving multiple actual parameters for one formal parameter would work.

Issue 9407: UML2: No notation for BehavioredClassifier::ownedTrigger (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.

Resolution: Discussion: A classifier declares its �willingness� to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change
Revised Text:
Actions taken:
March 1, 2006: received issue
October 27, 2008: closed issue

Issue 9413: UML 2 Super / Composite Structure / ambiguous constraint (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

There is a constraint on page 159.: 

 [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port. 

The wording is quite unclear. Interfaces are not by themselves required or provided but relative to a port or a classifier. Also, it implies that it should be possible to draw a connector from an Interface to a Port. This constraint needs to be clarified and made more precise.

Resolution: Resolution: This is a duplicate of 7251 Revised Text: None. Disposition: Duplicate of 7251
Revised Text:
Actions taken:
, :
March 8, 2006: received issue
April 26, 2010: closed issue

Issue 9416: Section: 12.3.48 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

I've found a implicit constraint: Imagine - for example - a LoopNode. It's part of an activity partition called component1. Within the body of the loop node an action should be called that's part of another activity partition called component2 (It's a common scenario: a component calls another component from within a loop). However that's not allowed: the loop node is in partition component1 while a contained action is in partition component2. Is that right? If yes, I believe it should be allowed.

Resolution: It is not clear what the submitter means by a loop node "calling" an action. As a structured activity node, a loop node owns the actions within it. However, an activity partition references contained nodes and edges, but it does not own them. Therefore, it is allowable for the actions contained in a loop node to be in different partitions, if this is what is desired. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
March 14, 2006: received issue
April 26, 2010: closed issue

Issue 9464: UML 2 Super / Components / connectors to interfaces (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter 8 there are several references that indicate that a connector can be drawn between two or more interfaces. This is not possible, since an  interface is not a connectable element.

Resolution: Indeed so. The revised text below corrects this.
Revised Text: In 8.1 Overview, replace: "As a result, components and subsystems can be flexibly reused and replaced by connecting ("wiring") them together via their provided and required interfaces." by: "As a result, components and subsystems can be flexibly reused and replaced by connecting ("wiring") them together." In 8.3.1 Component, first paragraph, replace: "Larger pieces of a system's functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces" by: "Larger pieces of a system's functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring them together" In 8.3.1 Component, Description::BasicComponents, replace: "A component has a number of provided and required Interfaces, that form the basis for wiring components together, either using Dependencies, or by using Connectors." by "A component has a number of provided and required Interfaces." In 8.3.3, replace: "A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component's parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling. An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port." by "A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the realization of that behavior. It represents the forwarding of events (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. An assembly connector is a connector between two or more parts or ports on parts that defines that one or more parts provide the services that other parts use." Disposition: Resolved
Actions taken:
March 21, 2006: received issue
April 26, 2010: closed issue

Issue 9513: UML 2.2 RTF issue - line styles for profiles (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML stereotypes can have an associated icon. For shapes there are 2 options for applying the icon: display the icon in the top right of the standard UML shape, or completely replace the standard shape with the icon.
However for lines there is only the option of displaying the icon 'near' the standard UML representation of the line. This is somewhat clunky at best and limits the flexibility of profiles.
 
The equivalent of using the icon to replace the original UML shape would be to allow the specification of a new line style: the icon could be used to represent both ends and the middle - and the tool would repeat the middle section in order to create an actual line.

Resolution:
Revised Text:
Actions taken:
April 5, 2006: received issue
April 26, 2010: closed issue

Discussion:

Placing a small icon in the upper right corner of a figure, or replacing the whole figure with an icon is relatively simple to implement. The former case requires some real estate in the figure, but otherwise result in little customizations for tool vendors to display the icon. The later case requires some additional support by tool vendors to have lines connect on the edge of the shape icon. This is more difficult, and can be facilitated by users drawing shape icons that have a rectangular border. 

Using icons to generate different line styles would be a different story because of the problem of managing line routing, orthogonal lines, line intersections, line connections and endpoint decorations that are part of the line as specified by the notation for the metaclass being extended (e.g., arrow heads). Drawing lines from icon shapes may result in extensibility problems for tool vendors and strange usability issues for users. The problem could be significantly worse of the line had multiple stereotypes applied (but of course shapes have that problem too).
Disposition:	Closed, out of scope

Issue 9514: page 467, Section 13.3.24 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

On page 467, Section 13.3.24, a Signal is said to have one association:

    signal : Signal[1]                                  The signal that is associated with this event.

I don't understand this. A signal is associated with another signal? 
Which one? Why? Could that be incorrect? 

Perhaps a cut-and-paste error, because on the same page, Section 13.3.25, 
a SignalEvent is said to have one association:

   signal : Signal[1]                                  The specific signal that is associated with 
                                                                   this event.

Resolution: Duplicate of issue 9576
Revised Text:
Actions taken:
April 5, 2006: received issue
October 27, 2008: closed issue

Issue 9576: Section: 13.3.24 Signal (from Communications) (uml2-rtf)

Click here for this issue's archive.
Source: PostFinance (Karl Guggisberg, nobody)
Nature: Clarification
Severity: Minor
Summary:

Replace � signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal

Resolution:
Revised Text: In section 13.3.24, subsection �Assocations�, replace the single bullet by ownedAttribute The attributes owned by the signal (subsets Classifier::attribute, Namespace::ownedMember). This association is ordered.
Actions taken:
April 16, 2006: received issue
October 27, 2008: closed issue

Issue 9577: New Issue on multiple guillemot pairs for same element (uml2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 18.3.8 has the following paragraph:
�
Presentation Options If multiple stereotypes are applied to an element,
it is possible to show this by enclosing each stereotype name within a
pair of
guillemets and listing them after each other. A tool can choose whether it
will
display stereotypes or not. In particular, some tools can choose not to
display
�required stereotypes,� but to display only their attributes (tagged
values) if
any.
�


Annex B has the following paragraph:
�
If multiple keywords and/or stereotype names apply to the same model element,
they all appear between the same pair of guillemets, separated by commas:
��� <label> [�,� <label>]* ���
�


These two paragraphs seem to contradict each other, since the annex B does
not
allow multiple guillemet pairs for the same element, while 18.3.8 does.


Proposed Solution:
Add clarification that Both presentation options should be allowed.

Resolution:
Revised Text: If multiple keywords and/or stereotype names apply to the same model element, they all appear between the same pair of guillemets, separated by commas: To: If multiple keywords and/or stereotype names apply to the same model element, each stereotype may be enclosed in a separate pair of guillemets and listed one after the other. Alternatively they all appear between the same pair of guillemets, separated by commas:
Actions taken:
April 19, 2006: received issue
April 26, 2010: closed issue

Discussion:

Section 18.3.8 also provides a presentation option to show each stereotype in it own pair of guillements"

"
Presentation Options 
If multiple stereotypes are applied to an element, it is possible to show this by enclosing each stereotype name within a pair of guillemets and listing them after each other. A tool can choose whether it will display stereotypes or not. In particular, some tools can choose not to display "required stereotypes," but to display only their attributes (tagged values) if any. 
"

This is not consistent with Appendix B which only describes the comma-separated list in a single pair of guillemet

Issue 9578: assembly connectors (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 8.3.2
An assembly connector is a connector between two components that defines


that one component provides the services that another component
requires. An
assembly connector is a connector that is defined from a required
interface
or port to a provided interface or port.


All constraints are using terms "connector between Interface and Port"
also.
I suggest to change or remove this misleading text.


Agreed. This text is highly misleading in a number of ways:


(1) It suggests that connectors connect components. They actually connect
parts typed by components.


(2) It suggests that connectors connect interfaces -- which they do not
(because only connectable elements can be connected and interfaces are not
connectable elements).

Resolution: This complaint is handled by other resolutions, primarily 8900 and 9464. Revised Text: None. Disposition: Duplicate of 8900 and 9464.
Revised Text:
Actions taken:
April 20, 2006: received issue
April 26, 2010: closed issue

Issue 9598: ptc/06-01-02:14.3.14, Notation (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The following notation expression isn�t well formed:

<interactionconstraint> ::= [�[� (<Boolean-expression� | �else�) �]�]

Resolution:
Revised Text: In 14.3.14 in section Notation, substitute: <interactionconstraint> ::= ['[' (<Boolean-expression' | 'else') ']'] by <interactionconstraint> ::= '[' (<Boolean-expression> | 'else') ']'
Actions taken:
April 24, 2006: received issue
April 26, 2010: closed issue

Issue 9606: ptc/06-01-02:14.3.14, Notation (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:


The following notation expression isn�t well formed:

<interactionconstraint> ::= [�[� (<Boolean-expression� | �else�) �]�]

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
April 24, 2006: received issue
April 27, 2006: closed issue

Issue 9617: Section: 7.3.10 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

The description of Constraint mentions the xor-association that is predefined in UML. There's no place in the superstructure (and infrastructure) where that constraint is defined.

Resolution: Figure 7.34 shows an {xor} constraint attached to two associations, indicating an Account can be a property of Person or Corporation, but not at the same time. Section 7.3.10 Constraint references �xor� constraint as an example of a UML predefined constraint. The xor constraint is not explicitly defined in UML. Rather it is used as an example of a constraint between associations as in figure 7.34, and as an example of an expression in section 7.3.18. So the parenthetical remark about xor being an example of a UML predefined constraint in section 7.3.10 should be removed.
Revised Text: In section 7.3.10 of Superstructure, the Description subsection, change the second sentence from: Certain kinds of constraints (such as an association �xor� constraint) are predefined in UML, others may be user-defined. To: Certain kinds of constraints are predefined in UML, others may be user-defined. In section 9.6.1 of InfrastructureLibrary, the Description subsection, change the second sentence from: Certain kinds of constraints (such as an association �xor� constraint) are predefined in UML, others may be user-defined. To: Certain kinds of constraints are predefined in UML, others may be user-defined.
Actions taken:
May 2, 2006: received issue
April 25, 2011: closed issue

Issue 9619: Section: 9.3.13 - connectors (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Connectors cannot be properly represented in a UML model using only constructs available in Compliance Level 1. The Connector class is part of the InternalStructures package which is in Level 1. The class that can own Connectors is StructuredClassifier through the ownedConnector association. This class is also in Level 1 but is abstract. All non-abstract subclasses of StructuredClassifer (such as Collaboration and EncapsulatedClassifier) are in Level 2. Because of this there is no class that can own Connector instances in a model that uses only Level 1 constructs. Therefore Connectors can�t be used in a Level 1 compliant model

Resolution: Resolution: This was a decision made in the design of UML 2. A tool that wants to offer internal structure with only compliance level 1 would have to at least define a profile that introduces a concrete subtype of StructuredClassifier. Disposition: Closed, no change
Revised Text:
Actions taken:
May 8, 2006: received issue
October 27, 2008: closed issue

Issue 9622: the default for a Property should not be inconsistent with its type (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:


There should be a constraint on Property that the ValueSpecification used for its default should not conflict with its type.
In some cases, for example if an OpaqueExpression is used, then the type of the value cannot be determined. However if it can then it should not be inconsistent.
This would, for example require the default for a Integer-typed Property to be an instance of LiteralInteger and not LiteralString or any other LiteralX.

Resolution: resolved
Revised Text:
Actions taken:
May 2, 2006: received issue
April 25, 2011: closed issue

Issue 9706: Definition of stereotype placement requires a name (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 18.3.8, Notation states: "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element."
This is too specific and does not state how to notate an element which is unnamed (which could be addressed by referring to where the name *would* be) or has no name property defined: for example Comment (here a more creative approach is needed).

Resolution:
Revised Text: In section 18.3.8, the Notation section, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. To: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation.
Actions taken:
May 4, 2006: received issue
April 26, 2010: closed issue

Discussion:

Stereotype label positioning for comments is described in subsequent paragraphs.

Issue 9710: 11.3.26 OpaqueAction (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

11.3.26 OpaqueAction states it has a Generalization: "Pin (from BasicActions) on page 256." This doesn't make sense; pins and actions are very different things. I think figure 11.2 shows the intended Generalization: "Action (from BasicActions) on page 230."

Resolution: This was editorially resolved in UML 2.2. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
May 12, 2006: received issue
April 26, 2010: closed issue

Issue 9750: A notation for Trigger (uml2-rtf)

My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
In previous version of UML, it was clear in my head (it does no harm just this once  that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

Resolution: This issue is an identical duplicate, submitted by the same author, as issue 10777
Revised Text:
Actions taken:
May 18, 2006: received issue
October 27, 2008: closed issue

Issue 9806: General ordering cycles (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint preventing the definition of general ordering cycles (involving occurrence specifications), as there is with generalizations

Resolution:
Revised Text: In 14.3.12 before the section on Semantics add: Constraints: � An occurrence specification must not be ordered relative to itself through a series of general orderings. (In other words, the transitive closure of the general orderings is irreflexive.)
Actions taken:
June 6, 2006: received issue
April 26, 2010: closed issue

Issue 9807: Section: 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Fig. 8.12 shows delegate connectors that are directly connected with an interface. According to the metamodell that's not possible. A connector end can only be connected with connectable elements.

Resolution: Resolution: Resolved by the changes specified in 8168. Revised Text: None. Disposition: Duplicate of 8168.
Revised Text:
Actions taken:
June 7, 2006: received issue
April 26, 2010: closed issue

Issue 9808: Completion event modeling (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Completion events are an explicit concept in UML statecharts. However, there is no corresponding metaclass either in the Common Behavior section or in Statecharts. Since completion events trigger transitions, it may be necessary to have an explicit CompletionEvent metaclass. For instance, we may want to model an interaction in which execution occurrences are initiated by completion events.

Resolution: Requires the addition of a new meta class. This needs to be postponed to a later revision when we will have more time to investigate this proposal and its impacts. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
June 7, 2006: received issue
April 26, 2010: closed issue

Issue 9813: Section: 9.2 (uml2-rtf)

In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.

Resolution: Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change
Revised Text:
Actions taken:
June 9, 2006: received issue
October 27, 2008: closed issue

Issue 9814: Section: 9.3.11 (uml2-rtf)

Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."

Resolution: The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that �clarification� is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.
Revised Text: In 9.3.11, subsection �Semantics�, delete the last sentence of the first paragraph
Actions taken:
June 9, 2006: received issue
October 27, 2008: closed issue

Issue 9820: Section: Figure 14.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The editorial fix in Figures 14.5 is not carried out: OccurenceSpecification is still abstract, not concrete. Please note that there is no editorial fix planned for, or applied to Figures 14.3 and 14.4. However, in these figures OccurenceSpecification is also shown as abstract. All of the figures pertaining to the package BasicInteractions should at least show the same view of OccurenceSpecification

Resolution:
Revised Text: The problem is related to Figure 14.6 (probably a renumbering since the issue was filed). Please update Figure 14.6 such that OccurrenceSpecification appears as abstract (i.e. in italics)
Actions taken:
June 10, 2006: received issue
April 26, 2010: closed issue

Issue 9821: Section: 9.3.11 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Semantics of ports needs to be define with regard to interfaces having attributes and associations

Resolution: Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change
Revised Text:
Actions taken:
June 12, 2006: received issue
October 27, 2008: closed issue

Issue 9829: Section: 12.3.8 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Section Associations of ActivityNode: /inGroup:Group[0..*] Groups containing the node. should be /inGroup:ActivityGroup[0..*] Activity groups containing the node.

Resolution: agreed
Revised Text: In Subclause 12.3.8 (ActivityNode), under Associations, replace � /inGroup: Group [0..*] with: � /inGroup: ActivityGroup [0..*]
Actions taken:
June 19, 2006: received issue
April 26, 2010: closed issue

Issue 9830: Stereotype attributes inherited from Class (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

What is the interpretation of the various atttributes that Stereotype inherits from Class, such as "isLeaf" and "isAbstract"? Do they mean the same thing, or are they inapplicable, or subtly different?

Resolution:
Revised Text: In section 18.3.1, under Generalizations, change: o InfrastructureLibrary::Constructs::Class (merge increment) To: o Class In section 18.3.1, under Generalizations, remove: o InfrastructureLibrary::Constructs::Class (merge increment) At the end of the Semantics section in section 18.3.8, add the following paragraph: Stereotype specializes Class which may be merged with Class from InfrastructureLibrary and Superstructure in different UML2 compliance levels. This adds a number of additional properties to class such as isLeaf, isAbstract, and ownedAttributes needed to provide the properties of the stereotype. These properties have the same meaning in Stereotypes as they do in Class. Tool vendors may choose to support extensibility that includes owned operations and behaviors, but are not required to do so. Tools must however support Stereotype ownedAttributes.
Actions taken:
June 20, 2006: received issue
April 26, 2010: closed issue

Discussion:

In the absence of any further constraints, or semantic rules, properties inherited from Class by Stereotype mean the same thing as they do for Class.  However, the description section of Stereotype in section 18.3.8 only refers to stereotypes having properties. No where is the meaning of any inherited properties from Class mentioned. In fact, Profile does not actually inherit any properties from Class in the Profiles package since it defines its own Class metaclass which is merged with Class from other packages in the UML2 compliance levels. 

We could add ownedAttributes to the Class defined in the Profiles package, and indicate in a constraint that this is the only property that Stereotypes can have. But that not only breaks inheritance, it may be unnecessarily restrictive. Tool vendors may choose to support extensibility with stereotypes that have owned operations and behaviors as well as constraints. 

Note that unless package Profiles is merged with some package containing Class that has ownedAttribures, (e.g., EMOF, CMOF, InfractructureLibrary::Basic, etc.) stereotypes will not be able to have tagged values. Profiles defines its own Class which is intended to be merged with Class defined in other packages describing metaclasses that profiles could extend.

Issue 9831: UML 2: "isLeaf" (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The "isLeaf" attribute of Class implies that there cannot be any subclasses of a class, but there is no corresponding OCL constraint that enforces that. 

Also, "isLeaf" is only defined in the Superstructure  and not in the Infrastructure -- should it be defined in the Infrastructure as well?

Resolution: The meaning of the 'isLeaf' attribute changed from UML 1.x to UML 2.x In UML 1.5 (formal/03-03-01), 'isLeaf' is a property defined in two contexts: - In GeneralizableElement (see 2.5.2.23) where it "specifies whether the GeneralizableElement is a GeneralizableElement with no descendents. True indicates that it may not have descendents, false indicates that it may have descendents (whether or not it actuallyhas any descendents at the moment)" The fact that the UML 1.5 concept of a leaf in a generalization hierarchy has no equivalent in UML 2.2 has been raised as a separate issue from this - see issue 10515. - In Operation (2.5.2.30) where "if true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden)." The UML 1.5 concept of a non-overridable operation corresponds to the UML 2.2 of RedefinableElement::isLeaf (see 7.3.46) The second part of this issue, i.e., whether the UML 2.2 infrastructure (formal/09-02-04) needs a capability for modeling a specialization leaf in a redefinition hierarchy is a strategic issue out of scope for the UML2 RTF. See resolution to issue 12532 for the OCL constraint enforcing the meaning of isLeaf in the context of redefinitions. Disposition: Closed No Change
Revised Text:
Actions taken:
June 20, 2006: received issue
April 26, 2010: closed issue

Issue 9843: Figure 7.4 invalid redefines (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This contains an unnamed property that {redefines _namespace}. There is
no property _namespace and the redefining property should be should be
named.
In Infra there is no such redefinition in Figure 11.21- is it actually
needed?

Resolution:
Revised Text:
Actions taken:
June 27, 2006: received issue
April 25, 2011: closed issue

Discussion:

This appears to have been fixed in a previous edit. The text _namespace or redefines namespace does not anywhere in the specification.
Disposition: Closed, no change

Issue 9855: Section: Activities (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Minor
Summary:

StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".

Resolution: The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are �accessible� within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 12.3.48 (StructuredActivityNode), Semantics, Package CompleteStructuredActivities subheading, first sentence, replace �An object node attached to�� with �A pin of�.�
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9856: Section: Activities - Weight description (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Revision
Severity: Minor
Summary:

Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.

Resolution: Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 12.3.5 (ActivityEdge), under Associations, change the description of �weight� to: The minimum number of tokens that must traverse the edge at the same time. {Subsets Element::ownedElement}
Actions taken:
June 27, 2006: received isuse
October 27, 2008: closed issue

Issue 9857: Section: Activities - Weight notation (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Revision
Severity: Significant
Summary:

Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.

Resolution: Correct text as below
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 12.3.5 (ActivityEdge), Notation, Package CompleteActivities subheading, in the first paragraph (immediately before Figure 12.41), replace the sentences: The weight is a value specification that is a positive integer or null, which may be a constant. A weight of null is notated as �all.� with: The weight is a value specification, which may be a constant, that evaluates to a non-zero unlimited natural value. An unlimited weight is notated as �*�.
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9858: Section Activities: Default weight (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Revision
Severity: Significant
Summary:

Default weight. In Activities, ActivityEdge, Assocations, the default weight should be unlimited (*). For example, a ReadStructuralFeatureAction of a mult-valued attribute might produce multiple tokens, which flow to the input of an AddStructuralFeatureAction. Do not want the values to be input to separate executions of AddStructuralFeatureAction

Resolution: The spec says weight determines the minimum number of tokens that must traverse the edge (offers accepted by target) at the same time. And it requires any tokens offered above the minimum to be taken at the same time: When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once. So the default can remain 1 for the example. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9859: ReadLinkAction (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Revision
Severity: Minor
Summary:

ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.

Resolution: accepted
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 11.3.33 (ReadLinkAction), Semantics, second paragraph, after the third sentence, insert: The order of the retrieved values in the output pin is the same as the ordering of the values of the links.
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9860: Section: Activities - Pin ordering semantics (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Minor
Summary:

Pin ordering semantics. In Activities, InputPin, OutputPin, the semantics of ordering inherited from ObjectNode should be related to multiplicity ordering inherited from MultiplicityElement. For example, if an output pin of ReadStructuralFeatureAction has an object node ordering of FIFO, and the structural feature is ordered (which means the multiplicity ordering of the pin is also), then perhaps the multiple values posted by a single execution of the action should be drawn from the pin in the same order as in the structural feature. Since the action will post the values to the output pin at the same time, currently FIFO ordering on the pin will be indeterminant

Resolution: Add text below.
Revised Text: In the UML Superstructure specification, version 2.2 (formal/2009-02-02), Subclause 12.3.44 (Pin), Semantics, add as the second paragraph: Pin inherits both an ordering attribute from ObjectNode and an isOrdered attribute from MultiplicityElement (via Pin in BasicActions). The values of these attributes may be set independently. However, if isOrdered is true, then the ordering of values on the pin considered as a MultiplicityElement is considered to be the order in which the values were placed onto the pin (either by the result of an action or by an incoming flow). The value of the ordering attribute, however, determines the order in which values are taken from the pin. For example, if isOrdered is true and the ordering is FIFO, then values will be taken from the pin in the same order as the MultiplicityElement ordering. However, if the ordering is LIFO, then values will be taken from the pin in reverse order to the MultiplicityElement ordering. On the other hand, if isOrdered is false, then the order in which values are placed on the pin is indeterminate, and the effect of different orderings is not defined. Disposition: Resolved
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9861: Section: Activities - Preserving order of multiple tokens offered. (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Preserving order of multiple tokens offered. In Activities, ActivityEdge, when tokens are offered in groups, for example for weight greater than 1, if the source and target are pins, the multiplicity ordering of the source node, if any, should be preserved in the target node.

Resolution: The real issue is preserving the ordering of offers as made by the source, whether the source is a pin or not. The relationship of multiplicity ordering on pins to the ordering of offers is handled by the resolution to Issue 9860.
Revised Text: In the UML Superstructure specification, version 2.2 (formal/2009-02-02), Subclause 12.3.37 (ObjectFlow), Semantics, Package BasicActivities subheading, at the end of the first paragraph add: Tokens are offered to the target node in the same order as they are taken from the source. If multiple tokens are offered at the same time, then the tokens are offered in the same order as if they had been offered one at a time from the source. Under the Package CompleteActivities subheading, add as the first paragraph: If the source of the object flow has an ordering specified, then tokens from the source are offered to the object flow in that order and, consequently, are offered from the object flow to the target in the same order. (See ObjectNode (from BasicActivities, CompleteActivities) on page xxx for the semantics of the offering of tokens to an object flow.)
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9862: Section: Actions - InputPin semantics wording (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

InputPin semantics wording. In Actions, InputPin, Semantic, second sentence, replace "how many values" with "the maximum number of values that can be".

Resolution: accepted
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 11.3.19 (InputPin), Semantics, second sentence, replace ��how many values are�� with ��the maximum number of values that can be�.�
Actions taken:
June 27, 2006: received issue
February 13, 2009: closed issue

Issue 9863: Section: Actions - Output of read actions for no values (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Output of read actions for no values. In the various read actions (links, structural features, variables), what is the output when there are no values read? Is it a null token or no tokens at all?

Resolution: Suppose the result output pin of a read action is connected by an object flow to an action with an input pin with a multiplicity lower bound of zero. Assuming the second action has no other inputs or incoming control flows, it still will not fire unless it receives some token on its input pin (note that this semantic interpretation of enabled actions is explicit in the Foundational UML specification). Thus, if the read action produces no token in the case that no values are read, then the second action will not fire, even though its input is optional. In order to ensure that the second action can actually fire with no input values, it would be necessary to also model an explicit control flow from the read action to the second action, which is inconvenient and can lead to ordering and sequencing issues between control and object tokens in the case when the read action does produce values. On the other hand, if the read action produces a null token when no values are read, then this will be offered to the second action, which can accept it, since its input multiplicity allows the case of no values. The second action will thus fire with an empty input, as would be intuitively expected. Note that if the second action's input pin had a multiplicity lower bound greater than zero, the semantics would not be effected by the offering of a null token, since this still would not provide the minimum number of values required for the action to fire. Therefore, in the framework of the token offer semantics of activities, it makes the most sense for a read action to produce a null token when there are no values to read. Note that this is also consistent with the semantics for call actions implied by the statement in Subclause 12.3.41 that if, at the time an activity finishes execution, "some output parameter nodes are empty�they are assigned null tokens", in which case one would expect the null tokens to be offered by the corresponding output pins of a call action for the activity. That is, call actions should also offer null tokens in the case that an output has no values.
Revised Text: In the UML 2.2 Superstructure, Version 2.2 (formal/09-02-02), Subclause 11.3.33 (ReadLinkAction), Semantics, at the end of the first paragraph, add: Note that, if there are no matching links, then the action produces a single null token on its output pin. In Subclause 11.3.37 (ReadStructuralFeatureAction), Semantics, at the end of the paragraph, add: Note that, if there are no retrieved values (that is, the structural feature is empty), then the action produces a single null token on its output pin. In Subclause 11.3.38 (ReadVariableAction), Semantics, at the end of the paragraph, add: Note that, if there are no retrieved values (that is, the variable is empty), then the action produces a single null token on its output pin.
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9864: Section: Activities - Semantics of fork node wording (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")

Resolution: The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: �Tokens arriving at a fork are duplicated across the outgoing edges.� The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change
Revised Text:
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9865: Section: Activities - Multiple activity parameters nodes for a single inout (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.

Resolution: There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 12.3.9 (Activity Parameter Node), Constraints, add the following constraints: [6] A parameter with direction other than inout must have at most one activity parameter node in an activity. [7] A parameter with direction inout must have at most two activity parameter nodes in an activity, one with incoming flows and one with outgoing flows.
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9866: Section: Activities - Offer ordering on joins (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?

Resolution: According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: �Tokens are offered on the outgoing edge in the same order they were offered to the join.� Disposition: Closed, no change
Revised Text:
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9867: Section: Activities - Join node edge constraint (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).

Resolution: Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says �If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.� Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change
Revised Text:
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9868: Section: Activities - ForkNode semantics wording (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

ForkNode semantics wording. In semantics of ForkNode, the phrase "keep their copy in an implicit FIFO queue until it can be accepted by the target" should not be different from other situations of ordered offers to refusing targets. In particular, it should be refined to clarify that the acceptance of offers by a fork is the same as acceptance by object nodes in the sense that they can't be revoked once accepted, and that for the edges leading to refusing targets, the offers are standing along those edges in the order they were received.

Resolution: In general, the ForkNode semantics needs to be more carefully worded in terms of offers of tokens, rather than just the tokens themselves "arriving" at a fork node.
Revised Text: In Subclause 12.3.30 (ForkNode), replace the first paragraph under Semantics with: Tokens that arrive at a fork node are duplicated across the outgoing edges of the node. Specifically, tokens offered to a fork node are offered to all outgoing edges of the node. If at least one of these offers is accepted, the offered tokens are removed from their source and a copy of the tokens traverse each edge for which the offer was accepted. Any offer that was not accepted on an outgoing edge due to the failure of the target to accept it remains pending on that edge and may be accepted by the target at a later time. These edges effectively accept a separate copy of the offered tokens, and offers made to the edges stand to their targets in the order in which they were accepted by the edge (first in, first out). This is an exception to the rule that control nodes cannot hold tokens if they are blocjed from moving downstream (see Activity (from BasicActivities, CompleteActivities, FundamentalActivities, StructuredActivities) on page 315). Note that any outgoing edges that fail to accept an offer due to the failure of a guard do not receive copies of those tokens.
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9869: Section: Activities - Output pin semantics clarification (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Output pin semantics clarification. The current semantics for Action says it won't complete without the output pins having the minimum number of tokens, as specified by the minimum multiplicity. It should be clarified that the output values are not put in the output pins until it the action completes, so the tokens already in the output pins are not included in meeting the minimum multiplicity.

Resolution: agreed
Revised Text: In Subclause 11.3.27 (OutputPin), replace the paragraph under Semantics with: For each execution, an action cannot terminate itself unless it can put at least as many values on its output pins as required by the lower multiplicity on those pins. The values are actually put in the pins once the action completes. Values that may remain on the output pins from previous executions are not included in meeting this minimum multiplicity requirement. An action may not put more values in an output pin in a single execution than the upper multiplicity of the pin. Disposition: Resolved
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9870: Actions on non-unique properties with location specified (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

Actions on non-unique properties with location specified. Clarify what happens in the actions applying to non-unique features / association ends when they specify location and an existing value (eg, RemoveStructuralFeature and Destroy actions) if the value to be acted on is not at the position specified.

Resolution: Currently, the WriteStructuralFeatureAction and WriteVariableAction superclasses specify a required value input pin, so all kinds of write structural feature actions must have such a pin in all cases. However, when a removeAt pin is required for a RemoveStructuralFeatureValueAction or RemoveVariableValueAction (that is, when the feature or variable is ordered and non-unique and isRemoveDuplicates is false), the expectation is that whatever value is at the given position is removed. Having to provide any value at all is counterintuitive. If the value is ignored, then it is pointless. If the value has to be the same as the value at the given position, then it is extremely inconvenient and redundant to have to read the value at that position just to remove it! Therefore, the remove value actions should not have a value input pin in the case they are required to have a removeAt pin. This means that the value input pin should be optional in the write action superclasses, but should then be constrained to be required for the add value actions.
Revised Text: In the UML 2.2 Superstructure, Version 2.2 (formal/09-02-02), Subclauses 11.3.55 (WriteStructuralFeatureAction), under Associations, change the multiplicity of "value" to "[0..1]". Under Constraints, change the OCL for the first constraint to: self.value -> notEmpty() implies self.value.type = self.structuralFeature.featuringClassifier In Subclause 11.3.56 (WriteVariableAction), under Associations, change the multiplicity of "value" to "[0..1]". Under Constraints, change the OCL for the first constraint to: self.value -> notEmpty() implies self.value.type = self.variable.type In Subclauses 11.3.5 (AddStructuralFeatureValueAction) and 11.3.6 (AddVariableValueAction), add the following constraint: [2] A value input pin is required. self.value -> notEmpty() In Subclause 11.3.41 (RemoveStructuralFeatureValueAction), replace the Description with the following: One value is removed from the set of values contained in the specified structural feature. The value to be removed may be specified either explicitly or, in the case of an ordered, non-unique feature, by giving a specific position at which the value is to be removed. It is also possible to specify the removal of all duplicate values. Replace the constraint with the following: [1] Actions removing a value from ordered non-unique structural features must have a single removeAt input pin and no value input pin if isRemoveDuplicates is false. The removeAt pin must be of type Unlimited Natural with multiplicity 1..1. Otherwise, the action has a value input pin and no removeAt input pin. if not self.structuralFeature.isOrdered or self.structuralFeature.isUnique or isRemoveDuplicates then self.removeAt -> isEmpty() and self.value -> notEmpty() else self.value -> isEmpty() and self.removeAt -> notEmpty() and self.removeAt.type = UnlimitedNatural and self.removeAt.lowerValue() = 1 and self.removeAt.upperValue() = 1 endif In Subclause 11.3.42 (RemoveVariableValueAction), replace the constraint with the following: [1] Actions removing a value from ordered non-unique variables must have a single removeAt input pin and no value input pin if isRemoveDuplicates is false. The removeAt pin must be of type Unlimited Natural with multiplicity 1..1. Otherwise, the action has a value input pin and no removeAt input pin. if not self.variable.isOrdered or self.variable.isUnique or isRemoveDuplicates then self.removeAt -> isEmpty() and self.value -> notEmpty() else self.value -> isEmpty() and self.removeAt -> notEmpty() and self.removeAt.type = UnlimitedNatural and self.removeAt.lowerValue() = 1 and self.removeAt.upperValue() = 1 endif In Figure 11.7, change the multiplicity on the value end of the association from WriteStructuralFeatureAction to InputPin to "0..1". In Figure 11.18, change the multiplicity on the value end of the association from WriteVariableAction to InputPin to "0..1".
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9871: Section: Activities - isSingleExecution default (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.

Resolution: This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change
Revised Text:
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9872: Section: Activities -StartClassifeirBehaviorAction and classifier behaviors (uml2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Enhancement
Severity: Minor
Summary:

StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.

Resolution:
Revised Text: Add StartObjectBehaviorAction to Figure 11.13 In Section 11.3.16 CreateObjectAction, under Semantics, at the end, add the following paragraph: If the classifier being instantiated is a Behavior, then the instantiated object is an execution of that behavior. However, this execution does not actually start immediately on instantiation. Rather, it must be explicitly started using a StartObjectBehaviorAction. In Section 12.3.4 Activity, under Semantics, fourth paragraph (the one starting ��An activity with a classifier context��), replace ��is invoked when�� with ��can be invoked after��. Add the following section to Chapter 11: 11.3.XX StartObjectBehaviorAction (from CompleteActions) Generalizations �h ��CallAction (from BasicActions)�� on page xxx Description StartObjectBehaviorAction is an action that starts the execution either of a directly instantiated behavior or of the classifier behavior of an object. Argument values may be supplied for the input parameters of the behavior. If the behavior is invoked synchronously, then output values may be obtained for output parameters. Attributes No additional attributes Associations �h object: InputPin[1..1] Holds the object which is either a behavior to be started or has a classifier behavior to be started. (Subsets Action::input) Constraints [1] The type of the object input pin must be either a Behavior or a BehavioredClassifier with a classifier behavior. [2] The multiplicity of the object input pin must be [1..1]. [3] The number and order of the argument pins must be the same as the number and order of the in and in-out parameters of the invoked behavior. Pins are matched to parameters by order. [4] The number and order of result pins must be the same as the number and order of the in-out, out and return parameters of the invoked behavior. Pins are matched to parameters by order. [4] The type, ordering, and multiplicity of an argument or result pin must be the same as the corresponding parameter of the behavior. Semantics A StartObjectBehaviorAction invokes an instantiated behavior or the classifier behavior of the input object. If the input object is an instantiated behavior that is not already executing, then it begins executing. If the input object has a classifier behavior that is not already executing, then it is instantiated and started. In either case, if the invoked behavior has already been initiated, then the action has no effect. Note that, if the input object is not an instantiated behavior, then it must have a classifier behavior. If the input object is an instantiated behavior, then it may also have a classifier behavior, which is also started. If this classifier behavior itself has a classifier behavior, then this is also recursively started, and so on. As a kind of CallAction, a StartObjectBehaviorAction must also provide argument values for all the in and inout parameters of the invoked behavior. Argument values provided on the input pins are available to the execution of the invoked behavior. If the invoked behavior is started asynchronously, StartObjectBehaviorAction completes after the behavior starts. If the invoked behavior is started synchronously, StartObjectBehaviorAction completes after the behavior does, and if the behavior has output parameters, then values produced for those parameters during execution are available on the result output pins of the action.
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Discussion:

The starting of execution of behaviors, and the passing of parameter values to them when they start executing, is currently inconsistent. If StartClassifierBehaviorAction is changed to allow parameter values to be passed in, then it should also be possible to do this consistently when starting other behaviors. The following analysis and proposed resolution is based on work on the Semantics of a Foundational Subset for Executable UML Models submission. The following is a summary of the current semantics related to behavior invocation, as given in the UML 2 superstructure specification. Classifier behaviors:
�h When a classifier with a classifier behavior is instantiated, the classifier behavior does not start executing. It must be started using the start classifier behavior action. While this is not explicit in the spec, presumably this invocation is asynchronous.
�h There is no way to specify the values for parameters of a classifier behavior. Presumably, this is consistent with the idea that a classifier behavior is meant to be run asynchronously, but there is nothing in the superstructure spec that prevents them from having parameters. They are just not usable.
Standalone behaviors:
�h A behavior is a kind of class, therefore it is possible to instantiate a behavior, say using a create object action. The semantics in the superstructure imply that a behavior starts executing when instantiated. While this is not explicit in the spec, presumably this invocation is asynchronous -- otherwise the create object action would not complete until the behavior execution terminated, and one could never get a reference to the instantiated object while the execution was actually going on.
�h A behavior can be called either synchronously or asynchronously via a call behavior action. This implicitly instantiates the behavior to execute it, but there is no way to get a reference to the executing behavior instance. This means that, if the behavior is called asynchronously, there would be no way to send a signal to the executing behavior (except, perhaps, by the roundabout means of having the behavior autonomously send a reference to itself to some other object). Values for the parameters of a behavior can be specified if the behavior is invoked via a call behavior action, and values can be returned by the behavior, but not if it is instantiated directly.
To more consistently handle behavior execution:
�h When a behavior is directly instantiated by a create object action, it does not immediately start executing. (Or, put another way, its execution is in a "suspended" state.)
�h The start classifier behavior action is replaced by a "start object behavior" action which has two differences from the current start classifier behavior action.
o The type of the object input pin can either be a classifier with a classifier behavior or a behavior. In the former case, the action starts the classifier behavior of the input object. In the latter case, the action starts the execution of the input behavior object itself. In both cases, the invocation is asynchronous, so the action immediately returns once the behavior execution starts.
o The action has input pins to provide values for all input parameters (if any) of the behavior being invoked. The invocation can be synchronous or asynchronous, with output pins for output parameters for synchronous invocation and with output parameters ignored for asynchronous invocations.
(Note that, for upward compatibility, the current start classifier behavior action is also retained.)

Issue 9873: Section: Common Behavior - isReentrant should default to true (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Revision
Severity: Minor
Summary:

isReentrant should default to true

Resolution: Having isReentrant default to false, as it currently does, means that, by default, there can be no concurrent invocations of a behavior, nor can a behavior be recursive. This does not seem to be the normal expectation of modelers when they model the invocation of behavior. Rather, the expected default it that behaviors are reentrant-with the ability to declare them not to be if that makes sense. On the other hand, it is often the case that, within an activity modeling, for example, a business or manufacturing process, an action invoking a behavior may be locally non-reentrant, in the sense that one invocation must complete before a new one can begin, because there is only a single performer to carry out the action. However, this case is more specifically addressed by Issue 6111. Once this is resolved at the local level, the default for the "global" isReentrant property on Behavior can be allowed to default to true, while "local" reentrancy for actions defaults to false.
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Subclause 13.3.2 Behavior, under Attributes, in the description of isReentrant, change "Default value is false." to "Default value is true." In Figure 13.6, add "= true" to the end of "isReentrant: Boolean" in the class box for Behavior. Disposition: Resolved
Actions taken:
June 27, 2006: received issue
April 26, 2010: closed issue

Issue 9875: Section: Activities - Action semantic clarification (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Clarification
Severity: Minor
Summary:

Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".

Resolution: accepted
Revised Text: In the UML Superstructure specification, version 2.1.1 (formal/2007-02-03), Section 12.3.2 (Action), Semantics, bullet [1], after �offered� insert �all necessary�.
Actions taken:
June 27, 2006: received issue
October 27, 2008: closed issue

Issue 9877: Notation for stereotypes on Comments and other elements (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 18.3.8, Notation, states "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. "  However several elements do not have names - for example Comment and LiteralString (the ODM Profile does define stereotypes on the latter).
 
SysML contains the following. 
A comment note box may contain stereotype keywords or icons even though Comment is not a named element. UML specifies placement of a stereotype keyword relative to the name of the element. SysML makes explicit that they may appear inside a comment box as well. The stereotype keywords, if present, should appear prior to the comment text. The stereotype properties, if present, should appear after the comment text. The typical placement of stereotype icons is in the upper-right-hand corner of the containing graphical node. 
This approach should be used by UML and generalized for other non-named elements

Resolution: Duplicate of 9706
Revised Text:
Actions taken:
June 29, 2006: received issue
April 26, 2010: closed issue

Issue 9890: Clarify isRequired (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

18.3.2 the description for isRequired, while technically correct, is somewhat terse and does not make clear that the references to 'multiplicity are to the lower and upper properties of ExtensionEnd

Resolution:
Revised Text: In section 18.3.2, change: Indicates whether an instance of the extending stereotype must be created when an instance of the extended class is created. The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd; a multiplicity of 1 means that isRequired is true, but otherwise it is false. Since the default multiplicity of an ExtensionEnd is 0..1, the default value of isRequired is false. To: Indicates whether an instance of the extending stereotype must be created when an instance of the extended class is created. The attribute value is derived from the value of the lower property of the ExtensionEnd referenced by Extension::ownedEnd; a lower value of 1 means that isRequired is true, but otherwise it is false. Since the default value of ExtensionEnd::lower is 0, the default value of isRequired is false.
Actions taken:
July 6, 2006: received issue
April 26, 2010: closed issue

Issue 9891: ExtensionEnd description refers to old use of navigability (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

18.3.3 second paragraph of description uses the old definition of navigability as implying property ownership

Resolution:
Revised Text: In the second paragraph of the description subsection in section 18.3.3, change: An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier. Since a profile is not allowed to change the referenced metamodel, it is not possible to add properties to the extended classifier. As a consequence, an ExtensionEnd can only be owned by an Extension. To: An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier.
Actions taken:
July 6, 2006: received issue
April 26, 2010: closed issue

Issue 9963: No default value specified for Generalization::isSubstitutable (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

No default value specified for Generalization::isSubstitutable. 
This is the only Boolean attribute in the whole specification without a default value

Resolution: For consistency and correctness, add a default value as the summary mentions.
Revised Text: Superstructure (ptc/07-02-05) On page page 71 Change: isSubstitutable: Boolean [0..1] Indicates whether the specific classifier can be used wherever the general classifier can be used. If true, the execution traces of the specific classifier will be a superset of the execution traces of the general classifier. To: isSubstitutable: Boolean [0..1] Indicates whether the specific classifier can be used wherever the general classifier can be used. If true, the execution traces of the specific classifier will be a superset of the execution traces of the general classifier. The default value is true.
Actions taken:
July 25, 2006: received issue
October 27, 2008: closed issue

Issue 10000: Missing inheritance in 9.3.12 (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

Resolution: The submitter is correct; see revised text.
Revised Text: In section 9.3.12 Property, subsection Generalizations, insert as second bullet �Connectable element (from InternalStructures)�
Actions taken:
July 26, 2006: received issue
October 27, 2008: closed issue

Issue 10004: Section: 9.13 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

MultiplicityElement is derived from itself

Resolution:
Revised Text:
Actions taken:
July 27, 2006: received issue
April 25, 2011: closed issue

Discussion:

This is not shown figure 7.5. Perhaps this is from an old version where MultiplicityElement inherited from the same class in a different package representing a merge increment.
Disposition: Closed, no change

Issue 10005: Section: 9.10.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Wrong definition of value association: value : InstanceSpecification [*] should be: value : ValueSpecification [*]

Resolution: This appears to have been fixedin Superstructure, The text �value: InstanceSpecification� does not appear in the specification. The property value is typed by ValueSpecification in Superstructure.
Revised Text: In Section 9.10.3 of InfrastructureLibrary, change: value : InstanceSpecification [*] The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element.ownedElement. To: value : ValueSpecification [*] The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element.ownedElement.
Actions taken:
July 28, 2006: received issue
April 25, 2011: closed issue

Discussion:

Issue 10006: Section: 9.19.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Wrong definition of hasVisibilityOf() Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()->collect(c | c.member)->includes(n) ... if (self.inheritedMember->includes (n)) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true ... should be: if (not self.inheritedMember->includes (n)) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true

Resolution: There is more wrong than suggested in the issue. If you work through the logic of hasVisbilityOf, you end up with a tautology as demonstrated by Ed with the following argument: To determine if a.hasVisibilityOf(n) is true, assuming n is private, we need to be able to deduce that (including the proposed change) if (not a.inheritedMember->includes(n)) then false else true is true, under the constraint that a.inheritedMember->includesAll(a.inherit(a.parents()->collect(p | p.inheritableMembers(a))) where p.inheritableMembers(a) = p.member->select(m | a.hasVisibilityOf(m)) Clearly, given the above constraint, not a.inheritedMember->includes(n) is true if not (a.inherit(a.parents()->collect(p | p.member->select(m | a.hasVisibilityOf(m)))->includes(n)) This, in turn, is equivalent to not (a.parents().member->includes(n) and a.hasVisibilityOf(n) and a.inherit(n)) The conclusion so far is, therefore, that a.hasVisibilityOf(n) is true if the above expression is false, that is, if a.parents().member->includes(n) and a.hasVisibilityOf(n) and a.inherit(n) implies a.hasVisibilityOf(n) Now, if either a.parents().member->includes(n) or a.inherit(n) are false, then the antecedent in the above implication is false, which means that a.hasVisibilityOf(n) must be false. On the other hand, if both a.parents().member->includes(n) and a.inherit(n) are true, then the implication reduces to the tautology a.hasVisibilityOf(n) implies a.hasVisibilityOf(n) which is true whether or not a.hasVisibilityOf(n) is true. However, it is not apparent why if (not a.inheritedMember->includes(n)) is needed at all. If we simply define hasVisibilityOf as n.visibility <> private, i.e. members are visible in a child if they are not private, we remove the tautology and simplify the logic.
Revised Text: In section 7.3.8 Classifier, subsection Additional Operations, change: [5] The query hasVisibilityOf() determines whether a named element is visible in the classifier. By default all are visible. It is only called when the argument is something owned by a parent. Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()->collect(c | c.member)->includes(n) if (self.inheritedMember->includes(n)) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true to: [5] The query hasVisibilityOf() determines whether a named element is visible in the classifier. It is only called when the argument is something owned by a parent. Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()->collect(c | c.member)->includes(n) hasVisibilityOf = (n.visibility <> #private)
Actions taken:
July 28, 2006: received issue
April 25, 2011: closed issue

Issue 10007: Section: 9.16.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Double declaration: RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; RedefinableElement::isRedefinitionContextValid (redefined:RedefinableElement):Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)) ) Is the "isRedefinitionContexValid" declaration redundant?

Resolution: Appears to have already been fixed. See Additional Operation [2] in section 7.3.46. Editorial note: However the fix has not been applied to Infrastructure.
Revised Text: In section 9.16.1 of InfrastructureLibrary, change: [2] The query isRedefinitionContextValid() specifies whether the redefinition contexts of this RedefinableElement are properly related to the redefinition contexts of the specified RedefinableElement to allow this element to redefine the other. By default at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element. RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; RedefinableElement::isRedefinitionContextValid (redefined:RedefinableElement):Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)) ) To: [2] The query isRedefinitionContextValid() specifies whether the redefinition contexts of this RedefinableElement are properly related to the redefinition contexts of the specified RedefinableElement to allow this element to redefine the other. By default at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element. RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)))
Actions taken:
July 28, 2006: received issue
April 25, 2011: closed issue

Issue 10044: Profile Structure Diagrams are missing from Annex A (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).
 
Proposed resolution:
 For clarity use the term 'Profile Diagram in section 18.4
 Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

Resolution:
Revised Text: In document formal/07-11-02 replace figure A.5 on page 684 with the following figure: <see ptc/2008-06-03 p 41> Also, on page 684 replace the sentence: The constructs contained in each of the thirteen UML diagrams is described in the Superstructure clauses as indicated below. with the sentence: The constructs contained in each of the UML diagrams is described in the Superstructure clauses as indicated below. Finally, on page 685 add the following hyperlinked bullet item with a pointer to Chapter 18: �h Profile Diagram �V ��Profiles��on page 651.
Actions taken:
July 31, 2006: received issue
October 27, 2008: closed issue

Discussion:

Agreed with proposed resolution.

Issue 10045: 11.3.47 on StructuralFeatureAction (and related sections on subclasses) (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Consider a link object that is an instance of an association 
> class that _owns_ its ends. In this case, according to the 
> metamodel, it is the _association class_ that is the 
> featuring classifier of the end properties (owningAssociation 
> subsets featuringClassifier). The properties of the object 
> input pin of a StructuralFeatureAction are determined by the 
> featuring classifier of the feature, which would imply that 
> the object being accessed in the case of an owned feature of 
> an association class is the link object that is the instance 
> of that association class.
> 
> BUT, the semantics of StructuralFeatureAction say that "If 
> the structural feature is an association end, then actions on 
> the feature have the same semantics as actions on the links 
> that have the feature as an end. See specializations of 
> StructuralFeatureAction" -- which is consistent with your 
> claims. This is an inconsistency in the spec. For the 
> semantics to work correctly, the syntactic constraints (on 
> typing of the object, visibility,
> etc.) would have to be adjusted for the case of an 
> association end owned by an association class.

Resolution: (Note that the StructuralFeatureAction subclause is numbered 11.3.48 in Version 2.2.) The issue summary states that "the properties of the object input pin of a StructuralFeatureAction are determined by the featuring classifier of the feature." However, the specification does not actually formally require this. Rather, Subclause 11.3.48 includes instead the following constraint: [2] The type of the object input pin is the same as the classifier of the object passed on this pin. This statement is actually tautological if the normal typing rules are enforced, and does not place any constraint on the relationship of the type of the object input pin and the featuring classifier of the feature. The intent really is that a StructuralFeatureAction for a structural feature that is an association end have the same semantics as for the appropriate link action. The ownership of the association end should not matter. For example, this allows a ReadStructuralFeatureAction to be used to read the navigable opposite end of a binary association, whether that end is owned by the opposite end type or owned by the association itself (in which case the ReadStructuralFeatureAction acts like a ReadLinkAction). This way, the action does not have to be changed just because the model may be updated to change the end ownership - the ability to read the end depends only on its navigability. If this is clarified and formalized in the specification, then the above issue becomes moot.
Revised Text: In the UML 2.2 Superstructure, Version 2.2 (formal/09-02-02), Subclause 11.3.48 (StructuralFeatureAction), under Description, replace the second sentence with: The type of this pin is either the classifier that owns the specified structural feature or, if the structural feature is an owned end of a binary association, the type of the opposite end of the association. The multiplicity of the pin is 1..1. Replace Constraints [2] and [3] with: [2] The structural feature must either be owned by the type of the object input pin, or it must be an owned end of a binary association with the type of the opposite end being the type of the object input pin. self.structuralFeature.featuringClassifier->includes(self.object.type) or self.structuralFeature.opposite.type = self.object.type [3] The multiplicity of the object input pin must be 1..1. self.object.lowerBound()=1 and self.object.upperBound()=1 Under Semantics, replace the second paragraph with: The structural features and associations of an object may change over time due to dynamic classification. However, the type of the object input pin of a structural feature action is identified as a single classifier, and it is assumed that the object passed to the action is classified by that classifier directly or indirectly. The structural feature is referred to as a user model element, so it is uniquely identified, even if there are other structural features of the same name on other classifiers.
Actions taken:
July 25, 2006: received issue
April 26, 2010: closed issue

Issue 10076: Section: 14.3.20 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

My question regards the following: Syntax for the Message name is the following: <messageident> ::= ([<attribute> �=�] <signal-or-operation-name> [�(� [<argument> [�,�<argument>]* �)�] [�:� <return-value>]) | �*� <argument> ::= (<[parameter-name> �=�] <argument-value>) | (<attribute> �=� <out-parameter-name> [�:� <argument-value>] | � -� First, I see a typo in the argument definition where the beginning of the definition should read as follows (Note the first square bracket and less than symbol): <argument> ::= ([<parameter-name> �=�] Second, I would like clarification on this item. From the definition it seems that I cannot specify a message by just showning the parameters. For example, if I have a class that has an operation of setFoo(int value): void, I cannot have a message of the method and its parameters, for example, "setFoo(value)". It would look like this instead "setFoo(value=)" according to the definition in the specification. To me this just doesn't seem right to have this hanging equal sign. There are other examples, pages 458 and 491 for example, that show a parameter without the equals sign. Could someone clarify this for me?

Resolution: Discussion: This issue seems to have been fixed already. Disposition: ClosedNoChange
Revised Text:
Actions taken:
April 26, 2010: closed issue

Issue 10080: Section: 11.3.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The grammar below is wrong, because there is no rule for the non-terminal <prop-property>. <prop-modifier> should be used instead. <property> ::= [<visibility>] [�/�] <name> [�:� <prop-type>] [�[� <multiplicity> �]�] [�=� <default>] [�{� <prop-property > [�,� <prop-property >]* �}�]

Resolution:
Revised Text:
Actions taken:
August 2, 2006: received issue
April 25, 2011: closed issue

Discussion:

Appears to have already been fixed. The text prop-property does not appear in the specification, and the grammar is as described in the resolution. See section 7.3.44, the Notation subsection.
Disposition: Closed, no change

Issue 10081: Section: 13.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The body property of OpaqueBehavior (as well as OpaqueExpression and OpaqueAction) should be declared not unique. The OpaqueBehavior can be used to store user code and the given language that it was written in. The specifiction identifies the lists of languages and bodies to be ordered (and by default unique). It makes sense for the list of languages to be uniuqe, but not the bodies. For example, consider the user has written the same code but in 2 different languages (say c and c++, or written an identical comment in c and c++ and java). Currently the UML specification disallows one to have the same body even though it may semantically make sense in both languages

Resolution: Agreed. In addition, the body and language attributes should be ordered
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Figure 13.6, in the class box for OpaqueBehavior, after "body: String [*]", add "{nonunique, ordered}" and after "language: String [*]" add "{ordered}". In Subclause 13.3.20 OpaqueBehavior, under Attributes, after "body: String [*]", add "{nonunique, ordered}" and after "language: String [*]" add "ordered". In Figure 7.6, in the class box for OpaqueExpression, after "body: String", add "[*] {nonunique, ordered}" and after "language: String" add "[*] {ordered}". In Subclause 7.3.35 OpaqueExpression, under Attributes, after "body: String [0..*]", add "{nonunique, ordered}" and after "language: String [0..*]" add "{ordered}". In Figure 11.2, in the class box for OpaqueAction, after "body: String", add "[*] {nonunique, ordered}" and after "language: String" add "[*] {ordered}". In Subclause 11.3.26 OpaqueAction, under Attributes, in "body: String [0..*] {ordered}" replace "{ordered}" with "{nonunique, ordered}".
Actions taken:
August 2, 2006: received issue
April 26, 2010: closed issue

Issue 10082: Section: 15.3.8 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?

Resolution: The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)
Revised Text: Replace the text on page 550 in the definition of Shallow history from: Entry actions of states entered on the path to the state represented by a shallow history are performed. To be: The entry action of the state represented by the shallow history is performed.
Actions taken:
April 26, 2010: closed issue

Discussion:

Issue 10083: proper content for Figure 13.8 (uml2-rtf)

Click here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML 2.1 spec, 06-04-02, has lost the proper content for Figure 13.8, by duplicating the content of Figure 13.7 again and labeling it 13.8.  See pages 442 and 443 as paginated in the pdf, 462 and 463 as paginated by Adobe in onscreen display.
 

above from the 06-04-02 spec, below from the 05-07-04 spec

Resolution: Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:

Issue 10087: Figure 7.31 (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 7.31 shows the association-like notation for attributes. However this still sues the navigability arrow in the 'old' way. It would be consistent to use the new 'dot' notation to show the class owning the property representing the attribute.

Resolution:
Revised Text: see page 28 of ptc/2011-01-19
Actions taken:
August 7, 2006: received issue
April 25, 2011: closed issue

Issue 10144: redefined properties (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

I believe that Port should subset Property::redefinedProperty to include Ports since Ports are Properties

Resolution: agreed
Revised Text: In the metamodel and in figure 9.4, Port::redefinedPort should subset redefinedProperty. In 9.3.11, in the specification of redefinedPort, replace (Subsets Element::redefinedElement) by (Subsets Property::redefinedProperty)
Actions taken:
August 28, 2006: received issue
April 26, 2010: closed issue

Issue 10145: 12.3.26 ExpansionNode (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

Specify constraint that a expansion node can have a regionAsInput and a regionAsOutput, but not both at the same time.

Resolution: agreed
Revised Text: In Subclause 12.3.26 (ExpansionNode), at the end, add: Constraints [1] One of regionAsInput or regionAsOutput must be non-empty, but not both.
Actions taken:
August 1, 2006: received issue
August 4, 2006: received issue
August 28, 2006: received issue
April 26, 2010: closed issue

Issue 10146: 12.3.27 ExpansionRegion (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Typo in paragraph Presentation options on page 385: insert blank between "12.85" and "maps".

Resolution: This seems to have already been corrected in UML 2.2 as an editorial change. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
August 28, 2006: received issue
April 26, 2010: closed issue

Issue 10147: UML 2 state machines / entry point outgoing transitions (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

In section 15.3.8 of the of the UML spec 06-04-02.pdf on page 563 it says: 

An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region. 

I believe that the intent was to say "at most a single transition", since it is possible that no transition exists as well as having multiple outgoing transitions (with guards) in each region.

Resolution: It is correct that entry points do not 'have' to have an outgoing transition. Updating the text is appropriate.
Revised Text: In section 15.3.8 (Pseudostate) under Semantics, replace text that currently says: An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region. By An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has at most a single transition to a vertex within the same region
Actions taken:
August 30, 2006: received issue
April 26, 2010: closed issue

Issue 10151: UML 2: Semantics of isOrdered need to be clarified (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Text should read something like:

                isOrdered : Boolean     For a multivalued multiplicity, this
attribute specifies whether the values in an instantiation of this
element are maintained in the order that they where insertedsequentially
ordered. Default is false.

Resolution: Actually, the original description is more general, since the ordering can be based on different ordering criteria, not just based on the order of insertion. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
September 1, 2006: received issue
October 27, 2008: closed issue

Issue 10347: Section: 17.5 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Is it possible in UML 2.0 specification to define a formal template parameter, for which the actual parameter to be given during parameter substitution is not a classifier but an instance of a specific classifier (more precisely, an instance of a specific class). If this is possible, what should be the type of the parameterable element exposed by the formal template parameter?? Does it have to be of type InstanceSpecification (or even ValueSpecification) to indicate that we are expecting an Object as actual parameter?? Moreover, what should be the type of the parameterable element to be exposed as actual parameter to indicate that we are providing a specific instance or value?? Finally what should be the proper notation for such template parameter to make the distinction with classifier template parameter??

Resolution: InstanceSpecification is not a ParameterableElement, so it cannot be used as a TemplateParameter. Providing a specific instance to a part would be done by assignment, not template bindings. See WriteStructuralFeatureAction. Revised Text: Disposition: Closed, no Change
Revised Text:
Actions taken:
September 15, 2006: received issue
April 26, 2010: closed issue

Issue 10351: Section: 12.3.2 Action (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

Semantics, rule [2] "If multiple control tokens are available on a single edge, they are all consumed." How does this rule fit to the rule that the default weight of an edge is 1. If multiple control tokens are available only one of them can traverse the edge to the target node

Resolution:
Revised Text:
Actions taken:
September 19, 2006: received issue
April 25, 2011: closed issue

Discussion:

The weight of an edge does not limit the number of tokens that can flow on an edge. It only determines the minimum number of tokens that must be accepted by the target of an edge before any tokens traverse the edge. This semantics has been clarified in UML 2.3 by the resolution to Issue 13898. As stated in Subclause 12.3.5 of the UML 2.3 specification: �When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once. The minimum number of tokens must be accepted by the target for any tokens to traverse the edge.� Thus, if the weight is one, then only one token needs to be accepted at the target, at which time all offered tokens are allowed to traverse the edge. If the weight is greater than 1, then the target must accept at least that weight for any tokens to flow at all. If the target does not accept enough tokens, then the first part of rule [2] is not satisfied: �When an action accepts the offers for control and object tokens�" and the action cannot execute. However, the spec indicates that all offered control tokens are accepted, so all will flow and be consumed when the action executes.
Disposition: Closed, no change

Issue 10354: issue regarding required and provided interfaces (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

There appears to be an issue with required and provided interfaces of Components in the UML2 Super Structure specification 2006-04-02  section 8.3.1., p.151 . 

In the OCL and the paragraph discussing required and provided interfaces there is no mention of inheriting provided or required interfaces from the supertypes of the component. 
Should we also consider required or provided interfaces of inherited ports? 
Should we also consider supertypes of realizing classifiers? 

The fact that Components don't consider supertypes is contrary to how Ports get required and provided interfaces on p187.  Ports consider supertypes of the classifiers that type them when collecting required and provided interfaces.

Resolution:
Revised Text: Superstructure (ptc/07-02-05) On page 147 Change: /provided: Interface[*] The interfaces that the component exposes to its environment. These interfaces may be Realized by the Component or any of its realizingClassifiers, or they may be the Interfaces that are provided by its public Ports. The provided interfaces association is a derived association: context Component::provided derive: let implementedInterfaces = self.implementation->collect(impl|impl.contract) and let realizedInterfaces = RealizedInterfaces(self) and let realizingClassifierInterfaces = RealizedInterfaces(self.realizingClassifier) and let typesOfRequiredPorts = self.ownedPort.provided in (((implementedInterfaces->union(realizedInterfaces)->union(realizingClassifierInterfaces))-> union(typesOfRequiredPorts))->asSet() To: /provided: Interface[*] The interfaces that the component exposes to its environment. These interfaces may be Realized by the Component or any of its realizingClassifiers, or they may be the Interfaces that are provided by its public Ports. The provided interfaces association is a derived association: context Component::provided derive: let implementedInterfaces : Set(Interface) = self.implementation->collect(impl|impl.contract), realizedInterfaces : Set(Interface) = RealizedInterfaces(self) , realizingClassifiers : Set(Classifier) = Set{self.realizingClassifier}->union(self.allParents().realizingClassifier) , allRealizingClassifiers : Set(Classifier) = realizingClassifiers->union(realizingClassifiers.allParents()) , realizingClassifierInterfaces : Set(Interface) = allRealizingClassifiers->iterate(c; rci : Set(Interface) = Set{} | rci->union(RealizedInterfaces(c))) , ports : Set(Port) = self.ownedPort->union(allParents.oclAsType(Set(EncapsulatedClassifier)).ownedPort) , providedByPorts : Set(Interface) = ports.provided in ( (implementedInterfaces->union(realizedInterfaces)->union(realizingClassifierInterfaces) )->union(providedByPorts) )->asSet() Change: /required: Interface [*] The interfaces that the component requires from other components in its environment in order to be able to offer its full set of provided functionality. These interfaces may be Used by the Component or any of its realizingClassifiers, or they may be the Interfaces that are required by its public Ports. The required interfaces association is a derived association: context Component::required derive: let usedInterfaces = UsedInterfaces(self) and let realizingClassifierUsedInterfaces = UsedInterfaces(self.realizingClassifier) and let typesOfUsedPorts = self.ownedPort.required in ((usedInterfaces->union(realizingClassifierUsedInterfaces))-> union(typesOfUsedPorts))->asSet() To: The interfaces that the component requires from other components in its environment in order to be able to offer its full set of provided functionality. These interfaces may be Used by the Component or any of its realizingClassifiers, or they may be the Interfaces that are required by its public Ports. The required interfaces association is a derived association: context Component::required derive: let usingInterfaces : Set(Interface) = self.implementation->collect(impl|impl.contract), usedInterfaces : Set(Interface) = UsedInterfaces(self) , realizingClassifiers : Set(Classifier) = Set{self.realizingClassifier}->union(self.allParents().realizingClassifier) , allRealizingClassifiers : Set(Classifier) = realizingClassifiers->union(realizingClassifiers.allParents()) , realizingClassifierInterfaces : Set(Interface) = allRealizingClassifiers->iterate(c; rci : Set(Interface) = Set{} | rci->union(UsedInterfaces(c))) , ports : Set(Port) = self.ownedPort->union(allParents.oclAsType(Set(EncapsulatedClassifier)).ownedPort) , usedByPorts : Set(Interface) = ports.provided in ( (usingInterfaces->union(usedInterfaces)->union(realizingClassifierInterfaces) )->union(usedByPorts) )->asSet() Superstructure 07-02-05 P.148 :: semantics section: Third paragraph should be changed From: The required and provided interfaces of a component allow for the specification of structural features such as attributes and association ends, as well as behavioral features such as operations and events. A component may implement a provided interface directly, or, its realizing classifiers may do so. The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time. To: The required and provided interfaces of a component allow for the specification of structural features such as attributes and association ends, as well as behavioral features such as operations and events. A component may implement a provided interface directly, or, its realizing classifiers may do so, or, they may be inherited. The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time.
Actions taken:
September 19, 2006: received issue
October 27, 2008: closed issue

Discussion:

When considering required and provided interfaces also include:
- provided interfaces of all parents of each realizing classifier
- interfaces from inherited ports, not only those directly owned by the component.
- Interfaces from supertypes.

Issue 10356: Page 60 of the pdf (uml2-rtf)

Click here for this issue's archive.
Source: Queen's Unioversity (Prof. Juergen Dingel, dingel(at)cs.queensu.ca)
Nature: Uncategorized Issue
Severity:
Summary:

Page 60 of the pdf (41 in the doc), right above Figure 7.19: 
- replace "also shows umambiguously that end B is owned by BinaryAssociationAB"
 by "also shows umambiguously that endB is owned by BinaryAssociationAB"

Resolution: The is a space between end and B. end B should be endB.
Revised Text: In section 7.3.3 Association, just above figure 7.19, change: this diagram also shows unambiguously that end B is owned by BinaryAssociationAB. To: this diagram also shows unambiguously that endB is owned by BinaryAssociationAB.
Actions taken:
September 20, 2006: received issue
April 25, 2011: closed issue

Issue 10379: Section: 7.3.38 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

visibility default value cannot be false

Resolution: See issue 10831 for disposition
Revised Text:
Actions taken:
October 30, 2006: received issue
April 25, 2011: closed issue

Issue 10383: Section: 13.3.25 (uml2-rtf)

Click here for this issue's archive.
Source: Bergson Technology (Mr. Marc Hamilton, m.hamilton(at)bergson.nl)
Nature: Enhancement
Severity: Significant
Summary:

SignalEvent notation interpretes Signal as an Operation. Details: A SignalEvent is associated to a Signal. The notation of SignalEvent contains an <assignment-specification> that consists of a list of <attr-name>. Quote: "<attr-name> is an implicit assignment of the corresponding parameter of the signal to...". Signal is however a Classifier and has no parameters. Either Signal should be an Operation or the notation of SignalEvent must utilize the explicit assignment of "corresponding attributes of the signal". In the latter case, this assignment should include the attribute name of the signal since the attributes of a Classifier are not ordered.

Resolution: The issue is correct. What is meant was the attributes of the signal
Revised Text: In section 13.3.25, subsection �Notation�, change the first bullet after �where:� to �<attr-name> is an implicit assignment of the corresponding attributes of the signal to an attribute (with this name) of the context object owning the triggered behavior.� And change the second bullet to �<assignment-specification> is optional and may be omitted even if the signal has attributes.�
Actions taken:
October 6, 2006: received issue
October 27, 2008: closed issue

Issue 10441: UML2: ReadSelfAction with a context cannot access behavior owned attributes (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.36 ReadSelfAction, Semantics indicates ReadSelfAction returns the context classifier for a behavior if the behavior has a context, otherwise it returns the behavior itself. This special case should be removed. ReadSelfAction should always result in the behavior. Otherwise if a behavior has a context classifier, there is no action available to access the structural features of the behavior. Having ReadSelfAction always result in the Behavior provides access to both the Behavior's ownedAttributes as well as those of the context classifier. If ReadSelfAction is the context classifier, then only its properties can be accessed.

Resolution: Resolution: Duplicate of issue 8016. Revised Text: None. Disposition: Duplicate
Revised Text:
Actions taken:
November 5, 2006: received issue
April 26, 2010: closed issue

Issue 10469: Figure 13.8 shows the wrong diagram (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

diagrams for UML 2.1.1 - Figure 13.8 shows the wrong diagram

Resolution: Discussion: This was fixed in an earlier release. Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
November 22, 2006: received issue
October 27, 2008: closed issue

Issue 10498: Section: 15 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The subject of my thesis is "UML MODEL REFACTORING USING GRAPH TRANSFORMATION" and I'm trying to represent UML models using graphs. I have read the "UML 2.0 Superstructure Specification" document and I can't exactly understand which is the region the transitions belong to. On page 553 it defines the container association as "Designates the region that owns this transition.". On page 529 it defines the transition association as "The set of transitions owned by the region. Note that internal transitions are owned by a region, but applies to the source state." I have taken a look to the previous UML specification version. Regions were not present and it defined the relationship between StateMachine and Transition as "Associates the StateMachine with its Transitions. Note that internal Transitions are owned by the State and not by the StateMachine. All other Transitions which are essentially relationships between States are owned by the StateMachine. Multiplicity is '0..*'. " Is it correct if I suppose that all the transitions, excluded internal transitions, are contained by the top-level region? Thank you.

Resolution: The owner of a transition does not imply any semantics; therefore a specific owner will not be defined. It is suggested that the LCA of the source and target is used, but it can really be any region that is directly or indirectly owned by the state machine context. This resolution also affects the constraint on internal transitions sourcing a composite state. Because the internal transition can be owned by any region (and not necessarily a region that belongs to the source state) the restriction that a state must be composite to have internal transitions is unnecessary. Therefore this needs to be corrected as well.
Revised Text: Add as the last paragraph in the Composite Transitions section (pg 598/748): The owner of a transition is not explicitly constrained, though the region must be owned directly or indirectly by the owning state machine context. A suggested owner of a transition is the LCA of the source and target vertices. OCL contraint changes: section 15.3.15 page 589 (or 605 of 748) From: [3] A transition with kind internal must have a composite state as its source, and its source and target must be equal. context Transition inv: (kind = TransitionKind::internal) implies (source.oclIsKindOf (State) and source.oclAsType(State).isComposite and source = target) To: [3] A transition with kind internal must have a state as its source, and its source and target must be equal. context Transition inv: (kind = TransitionKind::internal) implies (source.oclIsKindOf (State) and source = target) Remove from 15.3.10, on page 572/748, under Associations, the text: Note that internal transitions are owned by a region, but applies to the source state.
Actions taken:
November 30, 2006: received issue
April 26, 2010: closed issue

Issue 10513: Section: 13.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

In the UML Superstructure 2.1 available in the download section, the picture 13.8 is the same as the picture 13.7, in the page 463 of the document. The picture 13.8 should be explaining about the classes "Behavior" and "Constraint", as shown in the UML Superstructure 2.0 version.

Resolution: Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
December 15, 2006: received issue
October 27, 2008: closed issue

Issue 10515: Section: 7 (uml2-rtf)

Click here for this issue's archive.
Source: Paranor AG (Dr. Earl D. Waldin, )
Nature: Revision
Severity: Significant
Summary:

The property isLeaf as inherited by Class from RedefinableElement deals with the concept of redefinition in the context of a classifier. The concept of "this class cannot be subclassed" is missing from UML 2.0 and the current version of UML 2.1. In UML 1.4, the isLeaf property is present in two contexts: Operation and GeneralizableElement. The former refers to the concept of redefinition while the later refers to the concept of subclassing. In UML 2.1, isLeaf from RedefinableElement corresponds to the former. There is nothing corressponding to the later. It is clear from the UML 2.1 specification that redefinition of Classes is related to nesting. In the association class->nestedClassifier between Class and Classifier in Figure 7.12, the source end subsets redefinitionContext. The current constraints for RedefinableElement, Classifier and Class give the following interpretation. Let A be a class with nested class A1, B a class with nested class B1, and B be a subclass of A. Then B1 can redefine A1 as long as A1 has isLeaf = false and A1's visibility is not private. B1 can subclass A1 regardless of the the value of isLeaf on A1. In short, subclassing and redefinition are two separate, orthogonal concepts. The concept of isLeaf for subclassing is not present in UML 2.1.

Resolution: In UML 1.5, isLeaf is used in 3 contexts, not two: UML 1.5's Operation::isLeaf and Reception::isLeaf in UML 2 correspond to the concept of a redefinable element that cannot be further redefined. UML 1.5's GeneralizableElement::isLeaf in UML 2 corresponds to the concept of a classifier that cannot be further specialized in a generalization hierarchy. There are several options to add this capability in UML 2 and the two that are least disruptive to the UML 2 specification are: a) Rename RedefinableElement::isLeaf to RedefinableElement::isFinal Add Classifier::isLeaf b) Keep RedefinableElement::isLeaf Add Classifier::isFinal c) Keep RedefinableElement::isLeaf Add Classifier::isFinalSpecialization Option (a) would break compatibility with UML 2.2 in a really bad way because the original meaning of "isLeaf" is now "isFinal" and there is a completely different meaning assigned to "isLeaf". Option (b) preserves the UML 2 meaning of "isLeaf" but adds support for the UML 1.x notion of a classifier that cannot be specialized in a generalization hierarchy. However, option (b) creates possible confusion for end users in distinguishing the purpose of isLeaf vs. isFinal. Option (c) provides the same advantages as option (b) in addition to providing end users a clue about the role of isLeaf vs. isFinalSpecialization. Since option (b,c) represent an upwardly compatible change w.r.t. UML2.2, it is preferred to option (a) which would not only break compatibility with UML 2.2 but also create a lot of confusion in comparing UML 2.2 vs. UML 2.3 models. The rest of this resolution follows option (c). Add a property 'isFinalSpecialization' to a Classifier which is the basis for expressing taxonomic relationships among general and specific classifiers. Specify a package merge transformation for merging Classifier::isFinalSpecialization according to the principle that a resulting classifier is final if either matching classifier is final.
Revised Text: In 7.3.8 (Classifier), add a new attribute: o isFinalSpecialization: Boolean If true, the Classifier cannot be specialized by generalization. Note that this property is preserved through package merge operations; that is, the capability to specialize a Classifier (i.e., isFinalSpecialization =false) must be preserved in the resulting Classifier of a package merge operation where a Classifier with isFinalSpecialization =false is merged with a matching Classifier with isFinalSpecialization =true: the resulting Classifier will have isFinalSpecialization =false. Default is false. In 7.3.8 (Classifier), add a new constraint: [5] The parents of a classifier must be non-final. self.parents()->forAll(not isFinalSpecialization) In 7.3.40 (PackageMerge), "General package merge rules", rename rules 7 to 10 as 8 to 11 and insert a new rule 7 for merging the 'isFinalSpecialization' attribute as shown below: 6. For all matching classifier elements: if both matching elements are abstract, the resulting element is abstract; otherwise, the resulting element is non-abstract. 7. For all matching classifier elements: if both matching elements are final specializations, the resulting element is a final specialization; otherwise, the resulting element is a non-final specialization. 8. For all matching elements: if both matching elements are not derived, the resulting element is also not derived; otherwise, the resulting element is derived. 9. For all matching multiplicity elements: the lower bound of the resulting multiplicity is the lesser of the lower bounds of the multiplicities of the matching elements. 10. For all matching multiplicity elements: the upper bound of the resulting multiplicity is the greater of the upper bounds of the multiplicities of the matching elements. 11. Any stereotypes applied to a model element in either a merged or receiving element are also applied to the corresponding resulting element.
Actions taken:
December 19, 2006: received issue
April 26, 2010: closed issue

Issue 10521: AcceptCallAction has not operation (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In UML2, AcceptCallAction isA AcceptEventAction --> trigger: Trigger --> event: CallEvent --> operation: Operation. In the notation, there's the accept call action in an activity which has a name, and an operation provided by the performer. In the metamodel, this would mean that a Trigger and Event would have to be created to connect an operation to an AcceptCallAction. This is overkill resulting in a complex metamodel and extra work for modelers to create Trigger and Event model elements that are not needed. 

AcceptCallAction should have an operation: Operation property directly. Then a <<trigger>> keyword should be used to indicate the operation is implemented with an AcceptCallAction rather than a method Behavior

Resolution: The proposed change would, indeed, simplify the model, but it would be inconsistent with AcceptCallAction being, syntactically and semantically, a subclass of AcceptEventAction. AcceptCallAction is just a special case of triggering based on a call event, with some syntactic conveniences. Any complexity of the metamodel should be hidden by proper tool support. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
December 11, 2006: received issue
April 26, 2010: closed issue

Issue 10526: UML 2 Superstructure/Components/overly stringent constraints (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declartion of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.

Resolution: Resolution: Resolved by 7248-7251. Revised Text: None Disposition: Duplicate of 7248 - 7251
Revised Text:
Actions taken:
December 13, 2006: received issue
April 26, 2010: closed issue

Issue 10529: Section: 14.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The Notation of the InteractionConstraint is incorrect. A character after "Boolean-expression" should be > not �. AS-IS: <interactionconstraint> ::= [�[� (<Boolean-expression� | �else�) �]�] TO-BE: <interactionconstraint> ::= [�[� (<Boolean-expression> | �else�) �]�]

Resolution: See issue 9598 for disposition
Revised Text:
Actions taken:
December 19, 2006: received issue
April 25, 2011: closed issue

Issue 10530: Section: 14.3.10 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Old name, "ExecutionOccurences", of "ExecutionSpecification" is still used in the document. Line 14 of the page 465: "*ExecutionOccurences* are represented ..." Line 22 of the page 465: "Overlapping *execution occurrences* on the same lifeline ..." Description of Figure 14.15 of the page 465: "Overlapping *execution occurrences*" Line 18 of the page 463: "An ExecutionEvent models the start or finish of an *execution occurrence*."

Resolution:
Revised Text: In 14.3.10 please substitute (please also note the single "r" in the word) ExecutionOccurence by ExecutionSpecification In 14.3.8 please substitute An ExecutionEvent models the start or finish of an execution occurrence. by An ExecutionEvent models the start or finish of an execution specification. In 14.3.10 please substitute two occurrences of execution occurrence by execution specification
Actions taken:
December 19, 2006: received issue
April 26, 2010: closed issue

Issue 10536: A_end_role should not be bidirectional (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The A_end_role association between ConnectableElement and ConnectorEnd should not be bidirectional - it's unreasonable to expect that a connectable element be changed in order to connect it to another connectable element, considering that the connectable element(s) could be in a different model from the connector. There should perhaps be a separate, derived ConnectableElement::end property instead

Resolution:
Revised Text: Superstructure (formal/2007-11-02) Page 163: Figure 9.3 - Connectors, the �end� association end should have �/� in front to indicate derived. Page 174: Replace: end: ConnectorEnd Denotes a connector that attaches to this connectable element. With: /end: ConnectorEnd Denotes a connector that attaches to this connectable element. Derived in the following way: context ConnectableElement::end derive : ConnectorEnd.allInstances()-> select(e | e.role=self)
Actions taken:
December 21, 2006: received issue
April 26, 2010: closed issue

Discussion:

ConnectableElement and ConnectorEnd are related via a bi-directional association: (ConnectableElement::end � ConnectorEnd::role). The ends of the association are concrete (non-derived). This means setting one end of such association also sets the opposite end. This poses no problem if both ends of the association are co-located in the same resource. However, in the context of structure inheritance, more specifically when the structure of a classifier is inherited by a specializing classifier, it can happen that a new connector is added to the specialized classifier, whose one or both connector ends point to roles from the general classifier. Furthermore, if the specialization occurs in resource B that is different (common case) than resource A with the general classifier, this can lead to resource A changing unnecessarily due to adding the connector. Two possible solutions to this problem: 1) redefine the roles of the general classifier that are connected to/from by a connector in the specialized classifier 2) make the ConnectableElement:end collection derived (and non-ordered). Solution 1 has efficiency implications (memory cost of the redefinition). As such, solution 2 seems like a more favorable alternative and the derivation can easily be specified in OCL.

Issue 10537: A_outgoing_source and A_incoming_target should not be bidirectional (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The A_outgoing_source and A_incoming_target associations between Vertex and Transition should not be bidirectional - it's unreasonable to expect that a vertex be changed in order to create a transition to another vertex, considering that the vertices could be in a different model from the transition (especially in the context of state machine refinement). Note that since pseudostates are not redefinable, there is currently no way to redefine a transition that has a pseudostate as its source/target. There should perhaps be separate, derived Vertex::outgoing and Vertex::incoming properties instead.

Resolution:
Revised Text: Superstructure (formal/2007-11-02) Page 525: Figure 15.2 - the State machine, the outgoing/incoming association ends should have �/� in front to indicate derived. Page 580: Replace : outgoing: Transition[0..*] Specifies the transitions departing from this vertex. With: /outgoing: Transition[0..*] Specifies the transitions departing from this vertex. Derived in the following way: context Vertex::outgoing derive : Transition.allInstances()-> select(t | t.source=self) Page 580: Replace : incoming: Transition[0..*] Specifies the transitions entering this vertex. With: /incoming: Transition[0..*] Specifies the transitions entering this vertex. Derived in the following way: context Vertex::incoming derive : Transition.allInstances()-> select(t | t.target=self)
Actions taken:
December 21, 2006: received issue
April 26, 2010: closed issue

Discussion:

Vertex and Transition are related via two bi-directional associations: (Transition::source � Vertex::outgoing) and (Transition::target � Vertex::incoming). The ends of the two associations are concrete (non-derived). This means setting one end of such association also sets the opposite end. This poses no problem if both ends of the association are co-located in the same resource. However, in the context of Behavior redefinition, more specifically when a state-machine of a classifier is redefined in the context of a specializing classifier, it can happen that a new transition is added to the redefined state machine, whose one or both vertices belong to the state-machine of the general classifier. Furthermore, if the redefinition occurs in resource B that is different (common case) than resource A with the general context, this can lead to resource A changing unnecessarily due to adding the transition. Two possible solutions to this problem: 1) redefine the vertices of the general state machine that are connected to/from by a transition in the specialized state machine 2) make the Vertex:outgoing and Vertex:incoming collections derived. Solution 1 is problematic since a) Pseudo-states, which can be source/target of a transition, are not redefinable elements and b) redefining a state just for adding a transition (common) has efficiency implications (memory cost). As such, solution 2 seems like a more favorable alternative and the derivation can easily be specified in OCL.

Issue 10590: UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

One of the constraints for this element is:

�[2] The InteractionUse must cover all Lifelines of the enclosing Interaction that appear within the referred Interaction.�

This needs to be rephrased I think � I don�t see how Lifelines can �appear� in more than one Interaction.

Resolution:
Revised Text: In 14.3.18 rephrase Constraint [2] to the following: [2] The InteractionUse must cover all Lifelines of the enclosing Interaction that represent the same properties as lifelines within the referred Interaction.
Actions taken:
January 12, 2007: received issue
April 26, 2010: closed issue

Issue 10591: UML 2.1 Spec, Interactions: 14.3.18 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

I don�t understand why the type of the property �InteractionUse.argument� is Action; I think that there at least needs to be some explanation.

 

Also, looking at the syntax for �InteractionUse� in the Notation section:

 

�<name> ::=[<attribute-name> �=� ] [<collaboration-use> �.�] <interaction-name> [�(� <io-argument> [�,� <io-oargument>]* �)�] [�:� <return-value> <io-argument> ::= <in-argument> | �out� <out-argument>]

 

 The <attribute-name> refers to an attribute of one of the lifelines in the Interaction.�

 

How does the reference to the attribute get stored in the model?

 

Finally in Fig 14.18, I don�t see how the notation for the described InteractionUse can be produced from the syntax above, particularly the first part: �:xx.xc=�

Resolution: Arguments of InteractionUse shall be ValueSpecifications, as arguments of Message. Furthermore introduce a couple of extra attributes/associations to cover the information not easily found today. Finally fix the BNF of the concrete textual syntax by a concluding �]?
Revised Text: Change Figure 14.9 InteractionUses (the metamodel) Replace Action metaclass box with ValueSpecification as the end of the InteractionUse::arguments property. Add also constraint {subsets ownedElement} to this association role. Add a composition from InteractionUse to ValueSpecification with 0..1 multiplicity and role name �returnValue? and constraint {subsets ownedElement}. Multiplicity is 0..1 on the owning end. Add a unidirectionally navigable association from InteractionUse to Property with 0..1 multiplicity and role name �returnValueRecipient? on the Property end, and with * multiplicity at the InteractionUse end. Change text in 14.3.18 InteractionUse, Associations: From: � argument:Action[*] The actual arguments of the Interaction. To: � argument:ValueSpecification[*] The actual arguments of the Interaction. Add specifications of the new associations as follows: returnValue:ValueSpecification [0..1] The value of the executed Interaction returnValueRecipient:Property [0..1] The recipient of the return value. Add the following constraints: [5] The returnValueRecipient must be a Property of a ConnectableElement that is represented by a Lifeline covered by this InteractionUse. [6] The type of the returnValue must correspond to the type of the returnValueRecipient. In section on Notation: Fix the BNF syntax for the concrete textual syntax by moving the concluding �]? from after the final <out-argument> one line up to after <return-value>
Actions taken:
January 12, 2007: received issue
April 25, 2011: closed issue

Discussion:

Issue 10636: ReplyAction::replyValue type is incorrct (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.43 shows the replyValue attribute of ReplyAction is of type OutputPin. It is shown as InputPin in figure 11.12. The type should be InputPin in section 11.3.43

Resolution: Resolution: This was editorially corrected in UML 2.1. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
January 30, 2007: received issue
April 26, 2010: closed issue

Issue 10643: Section: 13 SimpleTime (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue

Resolution: Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change
Revised Text:
Actions taken:
February 5, 2007: received issue
October 27, 2008: closed issue

Issue 10650: Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions) (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

About "8784 - add ReceiveOperationEvent and ReceiveSignalEvent metaclasses" issue, the "ReceiveSignalEvent" (14.3.28 p522) metaclass seems to have the same meaning as "SignalEvent" (13.3.25 p468) and is then redundant. This issue should be resolved by either: - detailing the differences between ReceiveSignalEvent and SignalEvent - removing the ReceiveSignalEvent metaclass

Resolution: See issue 14629 for disposition
Revised Text:
Actions taken:
February 6, 2007: received issue
April 25, 2011: closed issue

Issue 10651: Page: 155, 162 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the notation for ComponentRealization on section 8.3.4 (page 162), it is stated that a ComponentRealization is notated in the same way as a realization dependency, "i.e., as a general dashed line with an open arrow-head". This contradicts the notation presented for Realization in section 7.3.45 (page 133), where it is stated that "A Realization dependency is shown as a dashed line with a triangular arrowhead at the end". If the notation of section 8.3.4 is indeed in error, Figure 8.10 (page 155) should be corrected to use triangular arrowheads, since it is a representation of the realization of a complex component.

Resolution: Resolution: This is a duplicate of 11007 (incorrect arrowhead in text) and 8705 (incorrect fig 8.10). Revised Text: None. Disposition: Duplicate of 8705 and 11007
Revised Text:
Actions taken:
February 6, 2007: received issue
April 26, 2010: closed issue

Issue 10655: UML2: Behavior without a specification should not be a classifier behavior (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 13.3.3, in the description of Behavior::specification says: "If a behavior does not have a specification, it is directly associated with a classifier (i.t., it is the behavior of the classifier as a whole." 

This appears to be incorrect. Assuming the "associated classifier" is the context Classifier: a Behavior might not be an ownedBehavior of any Classifier and has no context. For example, and Activity in a Package. Such a Behavior could not have a specification, but is not the behavior of any associated classifier. 

An ownedBehavior of a context Classifier can be explicitly designated as the behavior of the classifier using the BehavioredClassifier::classifierBehavior property. So there should be no need to define implicit classifier behaviors. 

Finally, a BehavioredClassifier might contain any number of ownedBehaviors that factor out reusable, private functions that are used in the implementations of other ownedBehaviors. These behaviors could be invoked using CallBehaviorActions and do not need specification operations. These behaviors would need a parameter for self if they need to refer to information in the context classifier.

Resolution: The issue correctly points to that the text in Behavior::specification is misleading
Revised Text: In section 13.3.2, subsection �Associations�, in the bullet for �specification�, replace the last sentence �If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole).� by �A behavior does not need to have a specification, in which case it either is the classifer behavior of a BehavioredClassifier or it can only be invoked by another behavior of the classifier
Actions taken:
February 9, 2007: received issue
October 27, 2008: closed issue

Issue 10731: Uses notation "Subsets Element::ownedElement" and similar (uml2-rtf)

Click here for this issue's archive.
Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu)
Nature: Clarification
Severity: Minor
Summary:

Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.

Resolution: Discussion: In one of the earlier revisions, the decision was made to use the �::� operator as a qualifier and not the �.� operator. Disposition: Closed, no change
Revised Text:
Actions taken:
February 14, 2007: received issue
October 27, 2008: closed issue

Issue 10775: section 13.3.2 � doc ptc/2006-04-02, v.2.1 (uml2-rtf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Pr. Dr. Fran�ois Terrier, francois.terrier(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:

 Issue a: ) in behaviour description (section 13.3.2 � doc ptc/2006-04-02, v.2.1) precise more formally and explicitely which elements can have behaviors, and how the behavior context is defined.

 

Typically clarification should say something like:

- [A] Any subclasses of BehavioredClassifier (that is: Collaboration, Class, Actor, UseCase) can have a Behavior and its context is defined through the �context� association

- [B] Any subclasses of BehavioralFeature (that is: xxx to be listed xxx) can have a Behavior and its context is defined through the �specification� association

- [C] Additionally, Transitions and States can have a Behavior and its context is defined by the first BehavioredClassifier reached through their �owned� relation

                        - [D] A Behavior can stand alone and be its own context (e.g. as equivalent to a C/C++ program)

� Is it here necessary to add a context association from the Behavior to itself�? or should we consider that in this case it is always owned by a modelling element (eg a package) that defines its context� and should we explicitly define to which kind of element this can be considered and add these elements to the list of the [C] situation ?

Resolution: Discussion: The issue is somewhat confusing in its wording when it asks what �elements can have behaviors�. In one reading, only BehavioredClassifier can have behaviors. Probably the issue means to ask what �elements can own behaviors�. It would be not in the style of the UML specification to summarize in a central location such information, as this would conflict with the object-oriented style of the specification, or it would cause a maintenance difficulty. Behavior::context clearly defines how the context object is determined, independent of the type of behavior or its owner. Disposition: Closed, no change
Revised Text:
Actions taken:
February 15, 2007: received issue
October 27, 2008: closed issue

Issue 10776: consistent descriptions of semantics of event consumption needed (uml2-rtf)

make consistent the descriptions of semantics of event consumption in section 13.3.4 and in section 13.3.2

Resolution: Section 13.3.2 is generic and does not define details of the semantics of event consumption. In fact it states that this is handled by BehavioredClassifier, section 13.3.4. I do not see any inconsistency between these two sections. Disposition: Closed, no change
Revised Text:
Actions taken:
February 15, 2007: received issue
October 27, 2008: closed issue

Discussion:

Issue 10777: A notation for Trigger (uml2-rtf)

My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
In previous version of UML, it was clear in my head (it does no harm just this once  that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

Resolution: Discussion: There is no notation for trigger independent of its specific notation in a behavioral feature. (Note that this notation reduces to the specific notation for the associated event.) For example, in state machines, a notation is defined for representing triggers on states or transitions. Disposition: Closed, no change
Revised Text:
Actions taken:
February 15, 2007: received issue
October 27, 2008: closed issue

Issue 10783: Section: 7.3.32 (uml2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Revision
Severity: Significant
Summary:

It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".

Resolution:
Revised Text: In the UML2.1.2 Superstructure document (formal/07-11-02) make the following changes: On Page 95, revise the following section: Constraints These constraints must handle situations where the upper bound may be specified by an expression not computable in the model. [1] A multiplicity must define at least one valid cardinality that is greater than zero. upperBound()->notEmpty() implies upperBound() > 0 [2] � � [7] � Remove constraint [1]. Renumber the subsequent constraints [2]-[7] to be [1]-[6]. On Page 96, Semantics section, add this paragraph at the end (directly before start of Notation section): The MultiplicityElement can define [0..0] multiplicity. This restricts cardinality to be 0 � i.e., forces it to be empty. This is useful in the context of generalizations - to further restrict the cardinalities constrained in more general classifier. This applies to (but is not limited to) redefining properties, existing in base classifiers. In the UML2.1.2 Infrastructure document (formal/07-11-04) make the following changes: On page 65, revise the following section: Constraints These constraint must handle situations where the upper bound may be specified by an expression not computable in the model. In this package such situations cannot arise but they can in subclasses. [1] A multiplicity must define at least one valid cardinality that is greater than zero. upperBound()->notEmpty() implies upperBound() > 0 [2] � [3]� Remove constraint [1]. Renumber the subsequent constraints [2]-[3] to be [1]-[2]. On Page 66, Semantics section, add this paragraph at the end (directly before start of Notation section): The MultiplicityElement can define [0..0] multiplicity. This restricts cardinality to be 0 � i.e., forces it to be empty. This is useful in the case of generalization - to further restrict the cardinalities constrained in more general classifier. This applies to (but is not limited to) redefining properties, existing in base classifiers.
Actions taken:
February 21, 2007: received issue
October 27, 2008: closed issue

Discussion:

This is a controversial issue, having arguments both in favor of and against it. Arguments for: Such a change would be useful in certain cases, especially when modeling multiplicities in generalization hierarchies - to further restrict the cardinalities constrained in more general classifier. E.g. redefine property, existing in base class, to not occur, in the case of association generalization (as stated by Mr. Bernard in the submission), in package merges etc. Also such constructs are sometimes used in other domains (especially data-oriented domains). For example IMM working group at OMG was recently working on XML schema profile. And XML schemas have a concept, very similar to [0..0] multiplicity. Attribute multiplicities in XML schemas can be optional|required|prohibited which would map very directly to UML profile (if this resolution were accepted): optional=[0..1] required=[1..1] prohibited=[0..0] XML schema elements can also have multiplicities of minOccurs=maxOccurs=0. There are 3 main objections (strongest first): 1) The need to have [0..0] multiplicities often indicates that there is an error in generalization, so user should restructure the generalization hierarchy, so that [0..0] multiplicity is not needed. [citing Bran Selic]: In OO programming we had a name for this way of using inheritance: we called it "reverse inheritance". In reverse inheritance, you defined all possible attributes in the superclass, and then excluded specific ones in different subclasses as appropriate. This is a classical example of an anti-pattern. �. My argument is simple: why make something a multiplicity element if you are going to give it an upper bound of 0? The only answer I can come up with is: because I made a mistake in my generalization.
The critique is quite valid. Often (but not always!) this is indication of bad generalization. For this I included a special admonishing statement in the semantics section so that modelers use this feature sparingly. However there are cases when it is necessary and not indication of something bad. Also modelers often have to work with predefined generalization hierarchies (e.g. provided by the library), and they can only specialize the provided classes. So editing upper levels of generalization hierarchy is not an option for them. 2) Instead of changing the spec we can tell modelers to use constraints in the case where [0..0] multiplicity is needed. This one is easily refuted by noting that most of the UML features can be considered �structured constraints in disguise�. Consider, e.g. Classifier::isAbstract flag. We could entirely get rid of it, and say to the modelers - express the fact that your classifier is abstract by using a constraint. Also Generalizations between classifiers? constraint on sets of instances. Multiplicities of properties? constraint on cardinality of slots. Types of properties? constraint on values of slots Association? constraint between roles of 2 ends. The list can go on and on. But it is much easier for the modeler to simply set a flag isAbstract=true than to use constraint. It is also easier to read for the other people and also easier for modeling tools to recognize the situation and give additional support for the user (e.g. drawing abstract classifiers slightly differently). And since specifying multiplicity is a structured way to specify cardinality constraint, this should also be the way to specify this constraint in the case of [0..0]. Model transformation tools also have easier time, when commonly used constraints are specified in a structured way (i.e. as metaproperties). Constraints in UML are mostly free-form. If user expresses his constraint that multiplicity is [0..0] using English constraint, transformation tool is completely out of luck. Even if he expresses this constraint in OCL, there is no easy way for the transformation tool to guess what some particular OCL constraint is describing. 3) This change is too dangerous (because it cuts very deeply into the infrastructure) to introduce it in UML2.2 release and should be deferred to UML3. Also this can affect already existing tools/profiles/metamodels. This objection too can be refuted quite well. This change will probably only cause problems for old tools handling new models. Here are 4 cases occurring: Old tools will be able to handle old models as they always did. New tools (that support multiplicity [0..0]) will be able to handle old models (since these do not contain [0..0] multiplicities, only usual multiplicities) New tools will be able to handle new models (since they are aware that multiplicities can be [0..0]). Some old tools will not be able to handle new models (since they are not aware that there can be [0..0] multiplicities) So this is the most benign scenario. New tools, claiming support for UML2.2, will be fully capable of handling both UML2.1 and UML2.2 models. Older tools, claiming support for UML2.1, will be capable of handling UML2.1 models for sure, and some UML2.2 models (which do not use [0..0] multiplicity). Also UML2.2 is quite big release - it is not a microrelease (like UML2.1.1->UML2.1.2) but mini release. And this is just a small change � no new structures introduced, just one constraint lifted.

Issue 10788: Ptc/06-04-02/Pg 188 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Where the spec currently says:

 

�If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.�

 

Consider whether this should in fact be defined as a semantic variation point.

Resolution: Resolution: The dynamic semantics of a port, when it is typed by a class, is already a semantic variation point. Most of the text above is an example, rather than a definition of behavior. The only normative text above is that the interaction point object will be an instance of the type of the port, if the port is typed by a class. That aspect is currently used by tools to give dynamic semantics to ports in a domain-specific manner. If such is not desired, the modeler can always close the semantic variation point as to the meaning of this construct to behave as desired, e.g., to reduce to the case where the type of the port is an interface. Disposition: Closed, no change
Revised Text:
Actions taken:
February 27, 2007: received issue
October 27, 2008: closed issue

Issue 10789: Port.provided:Interface (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

ptc/2006-04-02/p187.

 

The spec for Port.provided:Interface says: �References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface.�

 

This would seem to indicate that a Port typed by an Interface cannot have more than one provided interface. Clarify that this was the intention, or fix if not.

Resolution: I cannot see how it can mean anything else. This specification was modified in the resolution to 13080 and the meaning is clear there. Revised Text: Disposition: Closed, no change.
Revised Text:
Actions taken:
February 27, 2007: received issue
April 26, 2010: closed issue

Issue 10802: Section: 17/17.5.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Missing constraint for template binding in classifier context There seems to be an omitted constraint for template binding in the context of the classifier metaclass on page 667. Indeed, there is no restriction to the kind of template element to which a classifier can be bound. For example, nothing forbids a class to be bound to a data type or association or even an operation defined as template. There is a need for a constraint similar to the one defined on page 57, where it is stated that a classifier can only specialize classifiers of a valid type. Something like, self.templateBinding -> forAll(tb | self.oclIsKindOf(tb.signature.template.oclType)) Note that the variable oclType is not a valid OCL expression, even though it is referenced more than once in the UML Superstructure document (e.g definition of maySpecializeType on page 58). We therefore here assume that the oclType expression returns the associated metatype of the uml element to which it is applied. Thanks in advance for any feedback Jean-Fr�d�ric Etienne

Resolution: This is covered in constraint [1] of TemplateParameterSubstitution, section 17.5.5. Revised Text: Disposition: Closed, no Change
Revised Text:
Actions taken:
March 5, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 10814: Section: Composite Structures (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

Figure 9.4 duplicates 9.3

Resolution: Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
March 10, 2007: received issue
October 27, 2008: closed issue

Issue 10815: Flowing data into decision input behaviors (uml2-rtf)

Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
Sections: 12.3.22, DecisionNode

(This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

Background

There is no direct way to flow a supporting value into the decision input behavior of a decision node.

Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior -- but this seems awfully round about!

Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

Proposal

Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.

Resolution: Adopt as proposed
Revised Text: In Figure 12.9, add a decisionInputFlow association between DecisionNode and ObjecFlow: In Section 13.3.22, under Description, replace the text with: A decision node accepts tokens on an incoming edge and presents them to multiple outgoing edges. Which of the edges is actually traversed depends on the evaluation of the guards on the outgoing edges. Under Associations, add: �h decisionInputFlow : ObjectFlow [0..1] An additional edge incoming to the decision node that provides a decision input value. Under Constraints, replace both constraints with: [1] A decision node has one or two incoming edges and at least one outgoing edge. [2] The edges coming into and out of a decision node, other than the decision input flow (if any), must be either all object flows or all control flows. [3] The decisionInputFlow of a decision node must be an incoming edge of the decision node. [4] A decision input behavior has no output parameters, no in-out parameters and one return parameter. [5] If the decision node has no decision input flow and an incoming control flow, then a decision input behavior has zero input parameters. [6] If the decision node has no decision input flow and an incoming object flow, then a decision input behavior has one input parameter whose type is the same as or a supertype of the type of object tokens offered on the incoming edge. [7] If the decision node has a decision input flow and an incoming control flow, then a decision input behavior has one input parameter whose type is the same as or a supertype of the type of object tokens offered on the decision input flow. [8] If the decision node has a decision input flow and an second incoming object flow, then a decision input behavior has two input parameters, the first of which has a type that is the same as or a supertype of the type of the type of object tokens offered on the non-decision input flow and the second of which has a type that is the same as or a supertype of the type of object tokens offered on the decision input flow Under Semantics, add, at the end: If there is a decision input flow, but no decision input behavior, then it is the tokens offered on the decision input flow that are made available to the guard on each outgoing edge to determine whether the offer on the regular incoming edge is passed along that outgoing edge. If there is a decision input behavior and a decision input flow, the token offered on the decision input flow is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is an object flow). Decision nodes with the additional decision input flow offer tokens to outgoing edges only when one token is offered on each incoming edge. Under Notation: Add, at the end of the first paragraph: A decision input flow is specified by the keyword �decisionInput� annotating that flow. Replace the first sentence of the second paragraph with: A decision node must have one non-decision input activity edge entering it and one or more edges leaving it. It may also have a second decision input flow entering it, which must be marked �decisionInput�. The functionality of a decision node and a merge node can be combined by using the same node symbol, as illustrated at the right side of the figure below. At most one of the incoming flows may be annotated as a decision input flow. This case maps to a model containing a merge node with all the incoming edges shown in the diagram, except a decision input flow, and one outgoing edge to a decision node that has any decision input flow and all the outgoing edges shown in the diagram. This assumes the UML 2.0 Diagram Interchange standard support of the interchange of diagram elements and their mapping to model elements.
Actions taken:
March 9, 2007: received issue
October 27, 2008: closed issue

Issue 10816: Setting structural features of a data type (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

(This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

Background:

Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

Proposed resolution:

Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

(Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored -- though it might sometimes be convenient even in this case for "chaining" actions on an object.)

Resolution:
Revised Text: In Figure 11.7, add associations from WriteStructuralFeatureAction and ClearStructuralFeatureAction to OutputPin: <see ptc/2008-06-03 p 58> In Section 11.3.12, under Associations, replace ��No additional associations�� with: �h result : OutputPin[0..1] Gives the output pin on which the result is put. (Subsets Action::output) Under Constraints, replace ��No additional constraints�� with: [1] The type of the result output pin is the same as the type of the inherited object input pin. result->notEmpty() implies self.result.type = self.object.type [2] The multiplicity of the result output pin must be 1..1. result->notEmpty() implies self.result.multiplicity.is(1,1) Under Semantics, add the following paragraph: If a result output pin is provided, then the input object, as modified, is placed on the output pin. If the input object is actually a data value, then a copy of the input data value is placed on the output pin, but with the appropriate structural feature cleared. In Section 11.3.54, under Associations, add: �h result : OutputPin[0..1] Gives the output pin on which the result is put. (Subsets Action::output) Under Constraints, add: [3] The type of the result output pin is the same as the type of the inherited object input pin. result->notEmpty() implies self.result.type = self.object.type [4] The multiplicity of the result output pin must be 1..1. result->notEmpty() implies self.result.multiplicity.is(1,1) Under Semantics, replace ��None.�� with: A write structural feature action operates on a structural feature of an object to modify its values. The semantics of this modification depend on the specific kind of structural feature action. However, in all cases, if a result output pin is provided, then the input object, as modified, is placed on the output pin. If the input object is actually a data value, then a copy of the input data value is placed on the output pin, but with the appropriate structural feature modified.
Actions taken:
March 9, 2007: received issue
October 27, 2008: closed issue

Discussion:

As proposed, except that the new output pin is optional for ClearStructuralFeatureAction and WriteStructuralFeatureAction. This allows existing uses of these actions to be upward compatible with the revised abstract syntax.

Issue 10818: Section: 12.3.30 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figur 12.95 - Fork node example has an error. Instead of: |--> Fill Order Fill Order -->| |--> Send Invoice It should be: |--> Ship Order Fill Order -->| |--> Send Invoice

Resolution: agreed
Revised Text: In Section 12.3.30 (ForkNode), Figure 12.95, the top action on the right should have the name "Ship Order".
Actions taken:
March 13, 2007: received issue
April 26, 2010: closed issue

Issue 10819: Diagram metaclass shall be introduced and shall be subclass of Element (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Diagram metaclass shall be introduced and shall be subclass of Element, because every tool need to add Diagrams into packages (and uses hacks to do that) , Dependencies between diagrams is usable also. Stereotypes for diagrams are also used and even represented in DiagramFrame notation

Resolution: Discussion: This is definitely outside the scope of an RTF. However, it is also very much against one of the fundamental architectural principles of UML, that the abstract and concrete syntaxes are to be kept distinct. For instance, it should be possible to provide a UML concrete syntax that is completely textual and, hence, has no notion of diagram. Finally, the question of defining concrete syntaxes for MOF-based modeling languages and the issue of how these relate to the models themselves is being addressed by a separate RFP (the �Diagram Definition RFP�). Disposition: Closed, no change
Revised Text:
Actions taken:
February 23, 2007: received issue
October 27, 2008: closed issue

Issue 10820: ConnectorEnd shall have references to provided or required interfaces (uml2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ConnectorEnd shall have references to provided or required interfaces. It helps to use assembly connectors in composite structure diagrams between parts and ports, connector will be able to display two compatible interfaces using "ball in socket" notation. 
Now it is impossible to implement that, because there are no references to interfaces.

Resolution: Resolution: There are two problems with this issue: (a) The ball-and-socket notation is unique to the components chapter, so this issue cannot be resolved in general for ConnectorEnd, but would have to be addressed specifically in the components chapter by introducing a subtype of ConnectorEnd. More importantly, though, (b) connectors do not have a semantic relation to interfaces. They connect ports or parts based on their compatability. The compatability between interfaces is a derived notation, and does not require metamodel support. Disposition: Closed, no change
Revised Text:
Actions taken:
February 23, 2007: received issue
October 27, 2008: closed issue

Issue 10826: Repr. of applied stereotypes and their properties insufficiently described (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Significant
Summary:

Issue: UML representation of applied stereotypes and their properties is
insufficiently described
   Nature: Clarification
   Severity: Significant
   Summary:


      1. In the Superstructure spec 2.1.1, it is not clearly stated what an
         applied stereotype is in terms of metaclasses. The spec talks
         about "instance of a Stereotype", but it fails to sufficiently
         clarify the so-called meta-level crossing, i.e. the fact that an
         instance of the Stereotype metaclass at the same time is a new
         metaclass. The description of Stereotype says in the Semantics
         section: "An instance “S” of Stereotype is a kind of (meta) class
         ". I think "a kind of" as well as putting "(meta)" in parenthesis
         is confusing. I suggest to say: "An instance “S” of the Stereotype
         metaclass is itself a metaclass.".  Also, the text currently does
         not describe what the name and particularly the namespace of the
         metaclass corresponding to the instance of the Stereotype
         metaclass would be. Because of the current uncertainty, UML tools
         have taken different (and incompatible) interpretations on how an
         applied stereotype should be represented in terms of UML
         metaclasses.


      2. It is not described currently how any property values of applied
         stereotypes are represented in terms of instances of metaclasses.
         When looking at generated XMI, it seems that this representation
         is quite different from Property metaclass instances that are
         ownedAttributes of user model classes, so there is a need to
         clarify this. Because of the current uncertainty, UML tools have
         taken different (and incompatible) interpretations on how these
         values should be represented in terms of UML

Resolution:
Revised Text: In the Semantics subsection of section 18.3.8, change the first sentence of the second paragraph from: An instance "S" of Stereotype is a kind of (meta) class. To: An instance "S" of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. . Add the following paragraph to the end of the same Semantics subsection: A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names.
Actions taken:
March 17, 2007: received issue
April 26, 2010: closed issue

Discussion:

1.	The spec should not have to describe the namespace for a Stereotype since it is a PackageableElement (a Namespace) contained in a Package or Profile, the same as any other packageable element.
2.	A Stereotype is a metaclass extending another metaclass. Therefore its properties are not ownedAttributes of a Class at the M1 level. Indeed, stereotypes can be applied to metaclasses that don't have ownedAttributes such as State. Therefore, the properties of the stereotype are at the M2 level and should be "displayed" along with other attributes at the M2 level. These attributes are displayed using the UML2 notation. No notation is specified for displaying stereotype properties. Rather the notation is given by the notation for the extended metaclass. It would be difficult to specify a notation that would apply to any metaclass being extended because it is impossible to predict what the notation for that metaclass might be and therefore how the additional properties should be displayed. It is therefore left to tool vendors to determine how these properties are displayed using property pages, some advanced properties page, or some other technique. Since these stereotype properties don't appear on diagrams, there is no notation interoperability issue. And since the stereotype properties are exchanged using XMI in a standard way, there is not interchange interoperability problem.

Issue 10828: Figure 7.14: "Type" does not show its inheritance from "PackageableElement" (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Minor
Summary:

 In the Superstructure spec 2.1.1, in figure 7.14, the "Type"
      metaclass is shown right below the "PackageableElement" metaclass,
      but without any inheritance arrow between them. This is not wrong,
      since a class diagram is not obliged to show all existing
      relaitonships.


      However, it would ease the understanding and be consistent if in this
      case, the inheritance arrow between these two metaclasses was shown
      in that figure.

Resolution: Discussion: This strikes me as a matter of taste; someone else might object to the generalization being shown in this diagram since it would clutter the diagram. Disposition: Closed, no change
Revised Text:
Actions taken:
March 17, 2007: received issue
October 27, 2008: closed issue

Discussion:

Issue 10829: Usage of "Element::ownedMember" (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Significant
Summary:

 In the Superstructure spec 2.1.1, there are a few occurences where an
      association end "ownedMember" in metaclass "Element" is referenced.
      This should be changed to reference the end "ownedElement" instead.


      The places I found, are:
         "Class::nestedClassifier"
         "Enumeration::ownedLiteral"
         "DataType::ownedAttribute"
         "DataType::ownedOperation"

Resolution: According to the metamodel diagrams, {subsets ownedMember} would refer to the closest inherited ownedMember attribute which would be Namespace, not Element. For example, see figure 7.12. Change all references of Element::ownedMember to Namespace::ownedMember.
Revised Text: In Superstructure: In Section 7.3.7 Class, association nestedClassifier, change Element::ownedMember to Namespace::ownedMember. In Section 7.3.11 DataType, association ownedAttribute, change Element::ownedMember to Namespace::ownedMember. In Section 7.3.11 DataType, association ownedOperation, change Element::ownedMember to Namespace::ownedMember. In Section 7.3.16 Enumeration, association ownedLiteral, change Element::ownedMember to Namespace::ownedMember. In InfrastructureLibrary: In Section 11.6.1 DataType, association ownedAttribute, change Element::ownedMember to Namespace::ownedMember. In Section 11.6.1 DataType, association ownedOperation, change Element::ownedMember to Namespace::ownedMember. In Section 11.6.2 Enumeration, association ownedLiteral, change Element::ownedMember to Namespace::ownedMember.
Actions taken:
March 17, 2007: received issue
April 25, 2011: closed issue

Issue 10830: "Constraint::context" is marked as derived in the metaclass description (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Significant
Summary:

In the Superstructure spec 2.1.1, the description of the "context"
      association end in metaclass "Constraint" has the leading slash,
      marking it as derived. This is probably wrong. Besides not making
      much sense for this end to be derived, the following places support
      the view that "context" is meant to be non-derived:
         - The text in the description of the "context" end does not state
         from what or how the end would be derived.
         - In the UML Metamodel CMOF files, the end is not defined to be
         derived.
         - In figure 7.7, the "context" end is shown as non-derived.


      The description of the "context" end in the Superstructure spec
      should be changed to remove the derived-mark (leading slash) from it.

Resolution: Constraint::context is not derived in the metamodel. See figure 7.7. This is already correct in InfrastructureLibrary.
Revised Text: In section 7.3.10 Constraint, Associations, change ? / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace. To: ? context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace.
Actions taken:
March 17, 2007: received issue
April 25, 2011: closed issue

Discussion:

Issue 10831: "PackageableElement::visibility" uses "false" as default value (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Significant
Summary:

 In the Superstructure spec 2.1.1, the description of
      "PackageableElement::visibility" says: "Default value is false."
      However, "false" is not a valid value for the type "VisibilityKind".


      I suggest that the default visibility be defined as "public". While
      it may make sense for properties in a class to be private by default,
      this is not the case for packageable elements, here it makes way more
      sense to have a public default. The description should be changed
      accordingly.


      Second, the UML Metamodel CMOF files define metaclass
      "PackageableElement" to be a specialization of metaclass
      "NamedElement" without redefining "visibility". However, the
      metaclass description in the superstructure spec does redefine
      "visibility". The CMOF files should be adjusted to make the same
      redefinitions the description makes.

Resolution: Regarding the first point,.PackageableElement::visibility already has �public? as a default value in the normative CMOF models, so the description in the spec text needs to be corrected as suggested in the issue. Regarding the second point, PackageableElement::visibility in the CMOF models already redefines NamedElement::visibility, matching the spec doc, so no change is needed.
Revised Text: In UML Superstructure 2.3, clause 7.3.38 (PackageableElement), under Attributes: Change: � visibility: VisibilityKind [1] Indicates that packageable elements must always have a visibility (i.e., visibility is not optional). Redefines NamedElement::visibility. Default value is false. To: � visibility: VisibilityKind [1] Indicates that packageable elements must always have a visibility (i.e., visibility is not optional). Redefines NamedElement::visibility. Default value is public.
Actions taken:
March 17, 2007: received issue
April 25, 2011: closed issue

Issue 10832: Section: 15.3.12 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The problem is with the definition of the ancestor query on page 559. I believe that the algorithm, as stated, determines whether s1 is an ancestor of s2, not whether s2 is an ancestor of s1.

Resolution: This method is testing that s2 is nested within s1, and such s1 would be the ancestor. The method description is therefore wrong and needs to be fixed as suggested. Furthermore, the check that s1 has a container has no bearing on whether s2 is contained within it. And the parameters of the function accept states but we are passing the container which will be a region.
Revised Text: On page 573 (589/748) of section 15.3.12, replace [2] The query ancestor(s1, s2) checks whether s2 is an ancestor state of state s1. With [2] The query ancestor(s1, s2) checks whether s1 is an ancestor state of state s2. Change OCL method to be: context StateMachine::ancestor (s1 : State, s2 : State) : Boolean result = if (s2 = s1) then true else if (s2.container->isEmpty() or not s2.container.owner.oclIsKindOf(State)) then false else (ancestor(s1, s2.container.owner)) endif
Actions taken:
March 16, 2007: received issue
April 26, 2010: closed issue

Issue 10930: Section: 18.3.8 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

The description how values of a stereotyped element can be shown offers three ways. But all of them requires a graphical node. There is no description how to show the values of a stereotyped element that has no graphical notation, e.g. an attribute

Resolution: Resolution: Duplicate of 9877
Revised Text:
Actions taken:
March 20, 2007: received issue
April 26, 2010: closed issue

Issue 10959: Section: 15.3.14 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

On page 569 in section 15.3.4 (Transitions), constaint # 5 identifies which outgoing transitions, given their source pseudostates, may not have triggers: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() This OCL is incorrect since transitions leaving either a Junction Point, Initial State or a Join should not have triggers. The given OCL specifies the inverse - that only those pseudostates may have triggers. One contradiction to the above OCL exists on page 537 in section 15.3.8 (Pseudostates), constraint #9: [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard. (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty()) Furthermore, transitions leaving a fork are also not allowed triggers (constraint #1), so this could also be contained in the transition's OCL constraint (#5). Therefore the OCL for constraint #5 should be written as: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind = #junction) or (source.kind = #join) or (source.kind = #initial) or (source.kind = #fork)) implies trigger->isEmpty()

Resolution: Text has already been fixed in the UML 2.2 specification to be [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate). (source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty() which resolves the above issue Revised Text: N/A Disposition: ClosedNoChange
Revised Text:
Actions taken:
April 18, 2007: received issue
April 26, 2010: closed issue

Issue 10960: Section: 13.3.24 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Anders Ek, nobody)
Nature: Clarification
Severity: Significant
Summary:

There is an association defined for the Signal metaclass as follows: signal: Signal [1] The signal that is associated with this event. It is unclear what this associaiton is intended to represent. Should this association really be there?

Resolution: Disucssion: Duplicate of 9576. Disposition: Duplicate
Revised Text:
Actions taken:
April 19, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 10966: drawing a frame to represent Combined Fragment or an Interaction Occurrence (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

I seem to remember that when drawing a frame to represent a Combined Fragment or an Interaction Occurrence there is a notation that indicates whether a given lifeline overlapped by the frame is actually covered by the fragment/occurrence or not. I believe that it hinged on whether the frame obscured the lifeline or not. However, I can't find reference to it in the spec. It would be good to have this notation described with an example, to avoid different vendors inventing their own notations.

Resolution: Discussion: It is correct that there is no such notation suggested in the standard. The ITU standard Z.120 has a specific notation for lifelines that are not covered by a combined fragment, but we have not included that in UML 2. The reason, I believe, is that it is basically a matter of taste whether you want to include as covered in a combined fragment a lifeline that has no internal fragments (such as occurrence specifications). Disposition: Closed, no change
Revised Text:
Actions taken:
April 22, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 10967: description of 14.3.24 MessageSort (from BasicInteractions) - typo (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

On page 495, in the description of 14.3.24 MessageSort (from BasicInteractions) , the definition of  createMessage seems not to start on a new line, instead following straight on from the definition of asynchSignal

Resolution:
Revised Text: In 14.3.24 insert a line break directly before "createMessage" in bullet point #3 such that there is a new bullet point on createMessage Disposition: Resolved
Actions taken:
April 22, 2007: received isuse
April 26, 2010: closed issue

Issue 10992: UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 9.4 in formal/07-02-05 is a duplicate of figure 9-3. There should be a different diagram in place of figure 9-4 that shows the ports metamodel.

Resolution: Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
May 8, 2007: received issue
October 27, 2008: closed issue

Issue 11003: page 449 chapter 13.3.24 (Signal (from Communications) (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

there is a mistake in document formal/07-02-03 (UML Superstructure,
v2.1.1) on page 449 chapter 13.3.24 (Signal (from Communications)). A
Signal does not have an association to a signal of type Signal. It is
probably a mix-up with SignalEvent

Resolution: Discussion: Duplicate of issue 10960 Revised Text: N/A Disposition: Duplicate
Revised Text:
Actions taken:
May 14, 2007: received issue
October 27, 2008: closed issue

Issue 11004: Section: 9.3.8 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog

Resolution: Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change
Revised Text:
Actions taken:
May 14, 2007: received issue
October 27, 2008: closed issue

Discussion:

Issue 11007: Wrong notation description (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). ", BUT 
A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element

Resolution: agreed
Revised Text: In document formal/07-11-02 replace the following sentence on page 158: A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). with the following sentence: A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with hollow triangle as an arrowhead).
Actions taken:
May 16, 2007: received issue
October 27, 2008: closed issue

Issue 11008: Wrong subsets (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). 

ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation).

Required changes:

"abstraction" must subset "supplier" and "realizingClassifier" must subset "client".

Resolution: Section 7.3.45 does indeed make it clear that the specification is the supplier and the implementation is the client. The implementation depends upon the specification; the specification does not depend upon the implementation.
Revised Text: In section 8.3.2 Associations, replace: � abstraction : Component [0..1] The Component that own this Realization and which is implemented by its realizing classifiers.{Subsets Element::owner, DirectedRelationship::source, Dependency::client} � realizingClassifier : Classifier [1..*] A classifier that is involved in the implementation of the Component that owns this Realization. {Subsets Dependency::supplier, DirectedRelationship::target}. by: � abstraction : Component [0..1] The Component that own this Realization and which is implemented by its realizing classifiers.{Subsets Element::owner, Dependency::supplier} realizingClassifier : Classifier [1..*] A classifier that is involved in the implementation of the Component that owns this Realization. {Subsets Dependency::client}.
Actions taken:
May 16, 2007: received issue
April 26, 2010: closed issue

Issue 11054: Section 18.3.1 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

18.3.1 � Class claims that it is a merge increment on InfrastructureLibrary::Constructs::Class, when in fig 18.1 it seems that Profile merely imports Constructs rather than merging it.

Resolution: Duplicate of 9830
Revised Text:
Actions taken:
May 24, 2007: received issue
April 26, 2010: closed issue

Discussion:

Class is actually defined in package Profiles and is describe as a merge increment not in relationship to Constructs, but in relationship to UML2 compliance levels (or other metamodels) that package Profiles is merged with. That is, class Class in Profiles is not complete and is expected to merged with a more complete definition of Class in some other package. For example, Class does not include the ownedAttributes needed for the properties of a Stereotype.

The generalization in section 18.3.1 should be removed as this generalization only occurs depending on what package Profiles is merged with. This is done in the resolution of issue 9830

Issue 11067: Section: 9 Composite Structures / Port notation (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Clarification
Severity: Minor
Summary:

It is unclear if it is allowed to show the provided and required interfaces of a port in a composite structure diagram (ball and socket notation). That notation is already used for example in SysML. However I can't find the definition of it.

Resolution: Ball and socket notation is only allowed for Components. Revised Text: Disposition: Closed, no change.
Revised Text:
Actions taken:
May 25, 2007: received issue
April 26, 2010: closed issue

Issue 11069: Section: 12.3.41 Streaming parameters for actions (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Semantics, 2nd paragraph about streaming: "Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning." Since an action represents a single step and is atomic. I think it is not possible that an atomic action comsumes further parameters during execution.

Resolution: The stated issue presumes that action execution is atomic, which is not necessarily the case, and is certainly not the case for a call action to a behavior with streaming parameters. The whole point of streaming parameters is the semantics given in the quoted sentence, and they would be useless if this was not possible. However, the quoted sentence is poorly worded, since it is behaviors that have parameters and are invoked, not actions. This may be causing the confusion and should be corrected.
Revised Text: In Section 12.3.41 (Parameter), under Semantics, replace the second paragraph with: Streaming parameters give a behavior access to values passed from its invoker while the behavior is executing. Values for streaming parameters may arrive anytime during the execution of the behavior, not just at the beginning. Multiple values may arrive through a streaming input parameter during a single behavior execution, not just at the beginning, and multiple values may be posted to a streaming output parameter during the execution, not just at the end. When a behavior is invoked from an action, the action continues to execute while the invoked behavior executes. Tokens offered to input pins corresponding to streaming input parameters of the behavior are consumed by the action and passed to the executing behavior as they arrive, and values posted to streaming output parameters are offered on the corresponding output pins. In effect, streaming parameters give the invoked behavior access to token flows in the context of the invoking action, while it is executing. In addition to the execution rules given at Action, the following rules also apply to invoking a behavior with streaming parameters:
Actions taken:
May 25, 2007: received issue
April 26, 2010: closed issue

Issue 11076: Behaviors Owned by State Machines (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

State and Transition currently own the behaviors that they invoke. This is very restrictive because it makes it impossible to reuse Behaviors across state machines, or even across transitions and states.

 

Consider allowing States and Transitions to merely reference behaviors rather than owning them.

Resolution: Interesting idea, but it's too large a change to be considered for the current RTF. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated. Revised Text: N/A Disposition: Closed, out of scope
Revised Text:
Actions taken:
May 25, 2007: received issue
April 26, 2010: closed issue

Issue 11087: Section: 9.3.11 p 182 (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.

Resolution: Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change
Revised Text:
Actions taken:
May 31, 2007: received issue
October 27, 2008: closed issue

Discussion:

Issue 11089: "representation" (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

 
Classifier from Kernel packages has "representation" property of type InformationItem.
Classifier from Collaborations package has "representation" property of type CollaborationUse.
 
After package merge these properties conflict, one of them shall be renamed.

Resolution:
Revised Text: In Figure 17.2. �The contents of the information flow package�, delete the role name �representation� at the information item end of the association between information item and Classifier.
Actions taken:
June 5, 2007: received issue
October 27, 2008: closed issue

Discussion:

In fact, it is debatable whether Kernel::Classifier has a property �representation�. This property is shown in the metamodel in the information flows package, but that package does not define that property for an extension of classifier. So while the metamodel shows this property, the specification text does not. Further, this property is on the non-navigable end, and is not used in the text or in the constraints. Therefore, I recommend that this role name is deleted from the metamodel. There will be no adverse effects. If this property is desired, it would have to be much better supported (i.e., a subclass of Kernel::Classifier would have to be introduced here and that metaassociation would have to be added to that new classifier). At that point, a proper, non-conflicting name can be introduced. Note that it would not be wise to change the name in Collaboration, as it was inherited from UML 1 and thus is probably in wider use than the newly introduced name.

Issue 11090: information flow source and target (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.1.1 includes fix - "source" and "target" of InformationFlow are renamed to "informationSource" and "informationTarget".
These changes are made in diagrams, but not in text under InformationFlow chapter (17.2.1).

Resolution:
Revised Text: In section 17.2.1, Associations, change: � target : NamedElement [1..*] Defines to which target the conveyed information items are directed. {Subsets DirectedRelationship::target} � source : NamedElement [1..*] Defines from which source the conveyed information items are initiated. {Subsets DirectedRelationship::source} To: � informationTarget : NamedElement [1..*] Defines to which target the conveyed information items are directed. {Subsets DirectedRelationship::target} � informationSource : NamedElement [1..*] Defines from which source the conveyed information items are initiated. {Subsets DirectedRelationship::source} In that same section, Constraints change: [1] The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e., it represents a link). (self.source->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification))) and (self.target-> forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification))) To: [1] The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e., it represents a link). (self.informationSource->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification))) and (self.informationTarget-> forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or oclIsKindOf(UseCase) or oclIsKindOf(Artifact) or oclIsKindOf(Class) or oclIsKindOf(Component) or oclIsKindOf(Port) or oclIsKindOf(Property) or oclIsKindOf(Interface) or oclIsKindOf(Package) or oclIsKindOf(ActivityNode) or oclIsKindOf(ActivityPartition) or oclIsKindOf(InstanceSpecification)))
Actions taken:
June 6, 2007: received issue
April 26, 2010: closed issue

Issue 11109: Section: 11.4 Classifiers Diagram (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In "Figure 11.16 - The Classifiers diagram of the Constructs package", the end of the association between Classifier and Feature are named as "/featuringClassifier" and "/feature". But in "11.4.1 Classifier" the Assciations part illustrates the feature without slash. Also, in "11.4.2 Feature" the featuringClassifier is demonstrated without slash neither. According to UML series specifications, "/featuringClassifier" and "/feature" are different from "featuringClassifier" and "feature".

Resolution: Figure 7.10 indicates that Classifier::/feature and Feature::/featuringClassifier are both derived unions. Classifier:: /feature is shown as derived in section 7.3.8 where it is described. Feature::/featuringClassifier is shown as derived in section 7.3.19 where it is described. So there are no issues for Superstructure
Revised Text: In section 11.4.1 of InfrastructureLibrary, change: feature : Feature [*] Redefines the corresponding association in Abstractions. Subsets Namespace::member and is a derived union. Note that there may be members of the Classifier that are of the type Feature but are not included in this association (e.g., inherited features). To: /feature : Feature [*] Redefines the corresponding association in Abstractions. Subsets Namespace::member and is a derived union. Note that there may be members of the Classifier that are of the type Feature but are not included in this association (e.g., inherited features). In section 11.4.2, change: featuringClassifier : Classifier [1..*] Redefines the corresponding association in Abstractions. This is a derived union. To: /featuringClassifier : Classifier [1..*] Redefines the corresponding association in Abstractions. This is a derived union
Actions taken:
June 22, 2007: received issue
April 25, 2011: closed issue

Issue 11114: Section: 11.4 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

The derivation of Classifier.inheritedMember is incorrect: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) The "collect" in that should be "select". I'd also appreciate it if someone could tell me why the spec does not match the l3-merged.cmof here, and particularly, whether the transformation of the above into a query/derivation (by removal of the includesAll) was intentional in the l3-merged.cmof, or just some accident which suggests that the l3-merged.cmof is not up-to-date with the specification .pdf.

Resolution: See issue 15267 for disposition
Revised Text:
Actions taken:
June 29, 2007: received issue
April 25, 2011: closed issue

Issue 11160: Namespace URI for Standard Profile(s) (uml2-rtf)

Click here for this issue's archive.
Source: Eclipse Foundation (Mr. Kenneth Hussey, kenn.hussey(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML (Superstructure) specification does not define the namespace URI for the standard profile(s) - it should. Note that the currently recommended convention (from p. 703, section 18.3.6 of 07-02-03) for such URIs is 

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

Resolution:
Revised Text: Add the following paragraph after the third paragraph in Annex C: The namespace for the standard profile is: http://schema.omg.org/spec/UML/2.3/schemas/StandardProfileL2.xmi http://schema.omg.org/spec/UML/2.3/schemas/StandardProfileL3.xmi Different versions of this standard profile are created for the L2 and L3 compliance levels.
Actions taken:
July 18, 2007: received issue
April 26, 2010: closed issue

Discussion:

The namespace for UML is not actually defined in the UML specification. A namespace is implied in the XMI examples in section 18.3.6. No target namespace is defined in the XMI documents published for UML2.

Issue 11162: Section: 13.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

In, "Table 12.1 - Graphic nodes included in activity diagrams," the 'Notation' entry for 'ActivityNode' should exclude "ExecutableNode" (unless such an entry is added--or found elsewhere).

Resolution: agreed
Revised Text: In Section 12.4 (Diagrams), Table 12.1, ActivityNode row, Notation column, change "See ExecutableNode, ControlNode, and ObjectNode." to "See ControlNode and ObjectNode."
Actions taken:
July 18, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 11164: Section: 9 composite structures (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 9.3 : Is it riht that a connector can hold more than 2 ConnectorEnds? It is stated that it can hold: 2..*

Resolution: Discussion: Yes, it is possible that a connector have more than 2 ends, in case it is an n-way connector. Disposition: Closed, no change
Revised Text:
Actions taken:
July 20, 2007: received issue
October 27, 2008: closed issue

Issue 11201: Section: 14.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the Notation part of CombinedFragment, in the part 'Presentation Options for �coregion area"' the text refers to Figure 14.12 for an example of a coregion. However, on Figure 14.12 there is no coregion. The reference should be changed to Figure 14.22

Resolution:
Revised Text: In 14.3.3 substitute the reference to Figure 14.12 by Figure 14.22
Actions taken:
July 26, 2007: received issue
April 26, 2010: closed issue

Issue 11239: composite values (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.1.1
 
Problem:
 
Duration value and TimeExpression value can't be owned by Duration or TimeExpression.
 
 
Solution:
 
Make Duration "expr" and TimeExpression "expr" properties composite. 
Change Figure 13.13 SimpleTime to reflect these ownerships.

Resolution:
Revised Text: Change Figure 13.13 SimpleTime to reflect these ownerships. Correct association between TimeExpression and ValueSpecification. Correct association between Duration and ValueSpecification.
Actions taken:
August 1, 2007: received issue
October 27, 2008: closed issue

Discussion:

Make Duration "expr" and TimeExpression "expr" properties composite

Issue 11240: defaultClassifier of ClassifierTemplateParameter (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem:

"defaultClassifier" of ClassifierTemplateParameter shall redefine "default" of TemplateParameter and restrict type to Classifier.

"default" shall be not accessible in ClassifierTemplateParameter.

Resolution:

Add {redefines default} to end of "defaultClassifier"property description in chapter 17.5.8 ClassifierTemplateParameter

Add {redefines default} in metamodel association. Unfortunately diagram of abstract syntax of ClassifierTemplateParameter is not included into 17.5 Templates chapter.

It should be added also.

Resolution: Remove this redundant association
Revised Text: Change Figure 17.18 - Classifier Templates. Remove association between Classifier and ClassifierTemplateParameter. Remove "defaultClassifier" property description from chapter 17.5.8 ClassifierTemplateParameter
Actions taken:
August 1, 2007: received issue
October 27, 2008: closed issue

Discussion:

Remove this redundant association

Issue 11243: constraining Classifiers (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.
 
Resolution:
 
17.5.8
Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].

Resolution:
Revised Text: 17.5.8 ClassifierTemplateParameter, Associations section, change text to: �h constrainingClassifier : Classifier [0..*] The classifiers that constrain the argument that can be used for the parameter. If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted; otherwise, it must be either this classifier or one of its subclasses. If this property is empty, there are no constraints on the classifier that can be used as an argument. Change Figure 17.18 - Classifier Templates: Change multiplicity of ��constrainingClassifier�� role on association between Classifier and ClassifierTemplateParameter
Actions taken:
August 6, 2007: received issue
October 27, 2008: closed issue

Discussion:

Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].

Issue 11244: RedefinableTemplateSignature (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

RedefinableTemplateSignature::classifier owns this template signature, so it shall redefine inherited TemplateSignature::template, because it is used for the same purpose and subsets Element::owner.

Resolution:
Revised Text: In figure 17.18, add {redefines template, subsets owner} to Property RedefinableTemplateSignature::classifier and update the diagram. In section 17.5.9, Associations, change: � classifier : Classifier[1] The classifier that owns this template signature. Subsets RedefinableElement::redefinitionContext and Template::templatedElement. To: � classifier : Classifier[1] The classifier that owns this template signature. Redefines TemplateSignature::template. Subsets RedefinableElement::redefinitionContext, Template::templatedElement, Element::owner.
Actions taken:
August 7, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 11265: Any ownedBehavior should be able to have AcceptEventAction (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.

Resolution:
Revised Text: In section 13.3.31 Trigger, subsection �Semantics�, replace the 3rd sentence of the 2nd paragraph �An event is dispatched when it is taken from the input pool and either directly causes the occurrence of a behavior or are delivered to the classifier behavior of the receiving object for processing.� by �An event is dispatched when it is taken from the input pool and is processed by the classifier.�
Actions taken:
August 9, 2007: received issue
October 27, 2008: closed issue

Discussion:

AcceptEventActions would be part of the classifer behavior (remember, not all classifier behavior are state machines) or part of other behaviors owned by the classifier. Either case is covered by above. However, to modification below is proposed as more general and apparently less limiting.

Issue 11268: Section: 12.3.1 AcceptEventAction (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Figures 12.25-27 show examples of the AcceptEventAction. The actions have an outpin pin which can be omitted in the diagram. But the target actions should show the input pins, e.g. action "Cancel order" needs an input pin "Cancel order request".

Resolution: The referenced diagrams are correct as drawn when the edges are interpreted as control flows rather than data flows. Revised Text: None Disposition: Closed, no change
Revised Text:
Actions taken:
August 10, 2007: received issue
April 26, 2010: closed issue

Issue 11286: first constraint for CombinedFragment (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The first constraint for CombinedFragment:

�[1] If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand.� ..

should also include the assert operator.

Resolution:
Revised Text: In 14.3.3 Section Constraints please substitute: If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand. by If the interactionOperator is opt, loop, break, assert or neg, there must be exactly one operand.
Actions taken:
August 21, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 11343: Section: 18.3.6 Profile (from Profiles) (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the first serialization example, the memberEnd refers to property 'id4' and 'id5'. This would lead to 2 inconsistencies: 1. the 'id7' is in ownedEnd, but not in memberEnd. This contradicts the subset defined in chapter 7.3.3. 2. there are two candidates for the derived 'metaclass' attribute of 'Extension': id4.type and id5.type. This contradicts the definition in chapter 18.3.2. Instead it should refer to id7 and id5. The correct XMI file excerpt looks like that: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember>

Resolution:
Revised Text: In section 18.3.6, change the paragraph just before the first XMI example on page 674 from: Figure 18.5 To: Figure 18.6. In the first XMI example, change: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id4 id5"> To: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5">
Actions taken:
September 12, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 11400: Change multiplicity of ClassifierTemplateParameter role (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem:
The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters. 
 
Solution:
Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates

Resolution:
Revised Text: Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates
Actions taken:
September 13, 2007: received issue
October 27, 2008: closed issue

Discussion:

Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier

Issue 11401: Figure 14.5 - Messages. (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem:
Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.
 
Solution:
Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.

Resolution:
Revised Text: Change multiplicity [0..1] to [0..2] of MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages
Actions taken:
September 13, 2007: received issue
October 27, 2008: closed issue

Discussion:

Change multiplicity from [0..1] to [0..2].

Issue 11407: context of Constraint (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Context of the Constraint is described as derived property
 
� / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace. 
 
However it is not derived in Figure 7.7 - Constraints diagram of the Kernel package.
 
So should it be derived or not? One of these places shall be fixed.

Resolution: See issue 10830 for disposition
Revised Text:
Actions taken:
September 14, 2007: received issue
April 25, 2011: closed issue

Issue 11409: TimeEvent (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

TimeEvent has "when" property for time value. 
 
13.3.27 TimeEvent 

� when: TimeExpression [1] Specifies the corresponding time deadline. 

 
However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.
 
 
Model shall correspond to text, so Figure 13.13 shall be fixed.

Resolution:
Revised Text: [Change metamodel in figure 13.13 to have TimeEvent::when point to TimeExpression]
Actions taken:
September 14, 2007: received issue
October 27, 2008: closed issue

Discussion:

Issue 11414: Incorrect word renders sentence meaningless: Chap. 12.3.41 (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Incorrect word renders sentence meaningless: Chap. 12.3.41, "Parameter (from CompleteActivities)" Section "Semantics", 1st paragraph, Beginning of last sentence: Suggestion: Replace: "Arrange for separate executions of the activity to use separate executions of the activity..." by: "Arrange for separate invocations of the activity to use separate executions of the activity..."

Resolution: agreed
Revised Text: In Section 12.3.41 (Parameter), under Semantics, first paragraph, last sentence, replace "Arrange for separate executions of the activity�" by "Arrange for separate invocations of the activity�".
Actions taken:
September 17, 2007: received issue
April 26, 2010: closed issue

Issue 11503: Section: Composite Structures/Abstract syntax (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.

Resolution: withdrawn, this issue has been resolved
Revised Text:
Actions taken:
September 20, 2007: received issue
September 21, 2007: closed issue

Issue 11524: Figures 9.4 identical to figure 9.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors

Resolution: Discussion: Fixed in an earlier release Revised Text: N/A Disposition: Closed, no change
Revised Text:
Actions taken:
September 28, 2007: received issue
October 27, 2008: closed issue

Issue 11625: Section: 7.3.7 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.

Resolution: This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate
Revised Text:
Actions taken:
October 22, 2007: received issue
October 27, 2008: closed issue

Issue 11630: Section: 7.3.33 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 7.15 - Contents of Dependencies package There is a rolename supplierDependency that it not defined in �7.3.33 for NamedElement.

Resolution: supplierDependency is a non-navigable end and, therefore, cannot be owned by NamedElement. Per the usual style in the UML specification document, non-owned ends are not listed in the documentation for a class. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
October 23, 2007: received issue
April 26, 2010: closed issue

Issue 11646: StructuredActivityNode [UML 2.1.1] (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

StructuredActivityNode, based on both common sense and its semantics, requires input and output pins. However StructuredActivityNode::input and StructuredActivityNode::output, both inherited from Action are derived unions and so cannot be used directly. StructuredActivityNode::result is a concrete property but has a special meaning.

 

What is needed is some solution that subsets StructuredActivityNode::input and StructuredActivityNode::output but can be used to describe input and output pins of StructuredActivityNode.

Resolution: The semantics of StructuredActivityNode does, indeed, talk specifically about pins on such nodes. Further, having pins on StructuredActivityNodes is assumed as being allowed in and is required by the Java to UML activity model mapping in the Foundational UML specification. The submitter is correct, however, that the abstract syntax model itself does not seem to explicitly support this.
Revised Text: In Subclause 12.3.48 StructuredActivityNode, under Associations, at the beginning, add: Package StructuredActivities At the end add: Package CompleteStructuredActivities � structuredNodeInput: InputPin [0..*] Input pins for this structured activity node. {Subsets Action::input} � structuredNodeOutput: OutputPin[0..*] Output pins for this structured activity node. {Subsets Action::output} In Subclause 12.3.18 ConditionalNode, under Associations, in the description of result, replace "{Subsets Action::output}" with "{Redefines StructuredActivityNode::structuredNodeOutput}". Under constraints, add: [2] A conditional node has no input pins. In Subclause 12.3.35 LoopNode, under Association, in the description of result, replace "{Subsets Action::output}" with "{Redefines StructuredActivityNode::structuredNodeOutput}". In the description of loopVariableInput, replace "{Subsets Action::input}" with "{Redefines StructuredActivityNode::structuredNodeInput}. In Figure 12.22, add a unidirectional composition association from StructuredActivityNode to UML::Actions::BasicActions::InputPin with end name "structuredNodeInput", multiplicity 0..* and the annotation "{subsets input}", and add a unidirectional composition association from StructuredActivityNode to UML::Actions::BasicActions::OutputPin with end name "structuredNodeOutput:, multiplicity 0..* and the annotation "{subsets output}". In the association ends ConditionalNode::result and LoopNode::result, replace the annotation "subsets output" with "redefines structuredNodeOutput". In the association end LoopNode::loopVariableInput, replace the annotation "subsets input" with "redefines structuredNodeInput".
Actions taken:
November 8, 2007: received issue
April 26, 2010: closed issue

Discussion:

Issue 11657: UML2 issue: ProfileApplication treated as Import (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 13.1.6, figure 13.11  (of Infra) and  18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement �(since profile application is a kind of import)�. However this is not the case: ProfileApplication only inherits from DirectedRelationship. 

To achieve the end effect of the example there seem to be two alternatives:

a)      Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions. 

b)      Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.

 

This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.

Resolution: ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.
Revised Text: see pages 132 - 134 of ptc/2009-09-07 for details
Actions taken:
November 20, 2007: received issue
April 26, 2010: closed issue

Issue 11828: Figure 7.6 (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 7.6 should show properties body and language of OpaqueExpression as multivalued i.e. [0..*].

Resolution:
Revised Text:
Actions taken:
December 17, 2007: received issue
April 25, 2011: closed issue

Discussion:

It is in the current 2.3 specification. See figure 7.6 in Superstructure, figure 11.4 in InfrastructureLibrary.
Disposition: Closed, no change

Issue 12161: UML2: Missing ActionOutputPin (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML2 Activities support two different approaches for exchanging data between actions: "push semantics" of token passing over ObjectFlows and "pull semantics" of typical programming languages using ActionInputPins or ValuePin. The fromAction of an ActionInputPin could be a ValueExpression that references a Variable of the Activity or StructuralFeature of the context Classifier. However, support for pull semantics is incomplete. The first issues is 9247 where there is no ReadParameterAction or WriteParameterAction to support pull semantics for Activity Parameters. These Actions should be provided so that ActivityParameterNodes are only needed for ObjectFlows allowing the Activity Parameters to be directly referenced for pull semantics. This would also allow Parameters, Variables and StructuralFeatures to be all handled the same way.

Resolution: Despite the misleading title, this issue appears to be essentially a duplicate of issues 9247 and 8470. It looks like the text in this issue was just introductory to that of issue 12162, and was incorrectly made an issue of its own. Revised Text: None. Disposition: Duplicate
Revised Text:
Actions taken:
January 7, 2008: received issue
April 26, 2010: closed issue

Issue 12169: Regarding the quote on p128 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the 2.1.1 specification (070205): 

        Regarding the quote on p128: 
"All redefinitions should be made explicit with the use of a {redefines <x>} property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other." 


        I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model. 
This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts. 

Two features of the same kind  defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

Resolution:
Revised Text: Superstructure (formal/2007-11-02) Page 128: Replace: All redefinitions should be made explicit with the use of a {redefines <x>} property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other. With: Feature redefinitions can either be explicit with the use of a {redefines <x>} property string on the feature or implicit by having a feature with the same name to another feature in one of its owning classifier.s generals. In both cases, the redefined feature must conform to the compatibility constraint on redefinitions (e.g.,. the type of the feature must be a subtype of the feature.s type in the general context).
Actions taken:
January 8, 2008: received issue
October 27, 2008: closed issue

Discussion:

Clarify the semantics of explicit/implicit redefinition of features in classifiers

Issue 12170: section 15.3.14 Transition :: Constraints (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732  section 15.3.14 Transition :: Constraints)): 
[5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() 

This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers.  As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

Resolution:
Revised Text: Superstructure (formal/2007-11-02) Page 571: Replace: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() With: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty()
Actions taken:
January 8, 2008: received issue
October 27, 2008: closed issue

Issue 12224: Datatypes in UML profiles (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

--------------------------------------------------------------------------------
Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by
the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
the other class/metaclass
(a little side note - I am not sure if this passage is correct - ???metalevel mixing??? but this is irrelevant for the issue I am describing)

--------------------------------------------------------------------------------
I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

#1 Enumerations
#2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
e.g.

#3 Completely new primitive types, e.g. Double
#4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
e.g.

#1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
#2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

What I am worried about is #3 and #4.
#3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
serialized into the XMI.
Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
to be written into the XMI.

#4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

--------------------------------------------------------------------------------
So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
semantic variation points or compliance levels here?

Resolution:
Revised Text: In the third paragraph under Figure 18.8, change "isStric" to "isStrict". After the fourth paragraph, (before the paragraph starting with "Stereotypes can participant in associations.), add the following paragraph: A Profile can define Classes, DatatTypes, PrimitiveTypes and Enumerations as well as Stereotypes since Profiles imports Constructs. However, these types can only be used as the type of properties in the profile, they cannot be used as types in models the profile is applied to since they apply at the meta-model level, not the model level. It is however possible to define these types in separate packages and import them as needed in both profiles and models in order to use them for both purposes.
Actions taken:
February 14, 2008: received issue
April 26, 2010: closed issue

Discussion:

Serialization of Classes, DataTypes, PrimitiveTypes and Enumerations in profiles is defined as the serialization of the equivalent MOF type. There should be no additional extensions or special cases required. 

For item #3 above, MOF provides the ability, via a tag, to nominate an XSD datatype for serializing a new PrimitiveType.

Issue 12236: Table 8.2 (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Table 8.2 should contain graphic paths for - delegate connector - component realization

Resolution: Table 8.2 shows the assembly connector which is an element of a composite structure diagram. But table 8.2 denotes elements of a structure diagram. A table for composite structure diagram elements that are specific for components is missing. The heading of table 8.2 is incorrect. The table doesn't show nodes, but paths.
Revised Text: Change Table 8.2: - Change heading to: Graphic paths included in structure diagrams - Move assembly connector row to table 8.3. - Add new row: o Path type: Component realization o Notation: <insert appropriate notation> o Reference: See "ComponentRealization" Add new Table 8.3 with same columns as Table 8.2. - Add new heading: Graphic paths included in composite structure diagrams - Change row assembly connector: Column Reference: Change "See "assembly connector"" to "See "Connector"" - Add new row: o Path type: Delegate connector o Notation: <insert appropriate notation> o Reference: See "Connector"
Actions taken:
February 19, 2008: received issue
April 26, 2010: closed issue

Issue 12241: The semantics of an assembly connector remains unspecified (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

The semantics of an assembly connector remains unspecified: it is not possible to understand which port is the source and which port is the target of the data that are meant to "flow" at run-time on the assembly. The specification indeed refer to "required port" to express the semantics of a connector, but the concept of "required port" doesn't exist in UML. The real problem is the following: it is not possible to specify which interfaces provided/required by a port are involved in an assembly. A possible solution could be: - Have a port typed to an interface - Specify if the interface is provided or required using a tag (in a way similar for the direction of SysML FlowPort)

Resolution: I am not sure that this is really a semantics question. If the semantics are in doubt, that is an issue about connectors in general. I believe this is actually the issue about the ball and socket notation, which is resolved by the changes specified in 8168 and 8900, by restricting the notation to parts with simple ports. Revised Text: None. Disposition: Duplicate of 8168 and 8900.
Revised Text:
Actions taken:
February 20, 2008: received issue
April 26, 2010: closed issue

Issue 12259: The list of literal described for the ennumeration MessageSort is not compl (uml2-rtf)

The list of literal described for the ennumeration MessageSort is not complete according to it sdescription as shown in figure 14.5.

Resolution:
Revised Text:
Actions taken:
March 4, 2008: received issue
April 25, 2011: closed issue

Discussion:

This has already been fixed.
Disposition: Closed, no change

Issue 12261: Comments owned by Packages (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Significant
Summary:

A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

Resolution: Discussion: It is not quite right to say that �a package can only own packageable elements�. The spec only says that �Only packageable elements can be owned members of a package.� That is, any owned members of the package, considered as a namespace, must be packageable elements � this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.
Revised Text:
Actions taken:
March 5, 2008: received issue
October 27, 2008: closed issue

Issue 12262: Comments owned by Packages (02) (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

Resolution:
Revised Text: Attribute section of Comment (section 7.3.9, page 57): Remove text �multiplicity� in front of the attribute body
Actions taken:
March 5, 2008: received issue
October 27, 2008: closed issue

Discussion:

The title of the issue is a copy&paste error and misleading

Issue 12263: description of MessageOccurenceSpecification (uml2-rtf)

The description of MessageOccurenceSpecification defines a property called event. It is useless, because MessageOccurenceSpecification inherits from OccurenceSpecification that already owns this property, as denoted in the figure 14.5.

Resolution: See issue 14629 for disposition
Revised Text:
Actions taken:
March 5, 2008: received issue
April 25, 2011: closed issue

Issue 12266: PackageableElement (from Kernel), subsection: "Attribute" (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

section: PackageableElement (from Kernel), subsection: "Attribute" is writen "Default value is false." that it cannt has that value because its type is VibilityKind and can only has one of its enumerated value.

Resolution: See issue 10379 for disposition
Revised Text:
Actions taken:
March 8, 2008: received isse
April 25, 2011: closed issue

Issue 12278: UML 2.1.2:18.3.5 Package (from Profiles) (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

18.3.5 Package (from Profiles)

 

Description

A package can have one or more ProfileApplications to indicate which profiles have been applied.

Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.�

 

A Profile is a subclass of InfrastructureLibrary::Constructs::Package, which cannot own ProfileApplications and so you can�t apply a profile to a profile.

Resolution: Profiles does subclass Constructs::Package, but when Profiles is merged with Kernel::Classes::Package in UML compliance level L3, Package gets the ability to have applied profiles, as does its subclass, Profile. So whether a profile can be applied to a profile depends on what Profiles is merged with. Note that Profiles cannot stand alone, with just an import of Constructs since it defines Class as a merge increment (in order to add extensions). Profiles::Class has no ownedAttributes, so without a merge, Stereotypes would not be able to have Properties. However, applying a profile to a profile would extend the extensibility mechanisms of UML in non-standard ways that would not be supported by most tools. This would limit interoperability and break model interchange. So it should not be possible to apply a profile to another profile. Disposition: Closed, no change.
Revised Text:
Actions taken:
March 14, 2008: received issue
April 26, 2010: closed issue

Discussion:

Issue 12284: A final node that returns to the caller but leaves alive any parallel flow (uml2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Clarification
Severity:
Summary:

The regular ActivityFinalNode stops all possible parallel flows in the activity before 
returning to the caller. 
There are some cases where it would be interesting to have a variant of this behavior 
which would allow returning immediately but without affecting the execution of any 
parallel flow. 

A use case for this "soft return" construct: An application process a user "search" request. 
When it founds a first set of results  it returns immediately the response to the user but it 
the meantime continues looking for another set of requests to anticipate possible additional 
request from the user, without loosing the context of the user request. 

For this use case we will use the "soft return" final node to return when finding the first 
set of responses and will use a FlowFinalNode at the end of a parallel branch looking for 
additional responses. 
For sure, it is always possible to encode this use case differently, but such new kind of 
final node would allow to model the intended behavior more directly. 

Rq: What would happen if a "soft return" is reached after a "soft return" already happened: 
I guess the semantics would be to behave as a FlowFinalNode (cannot return twice). 
And what if a "regular" ActivityFinalNode is reached after a "soft return": I guess all 
existing parallel are stopped but there is no return to the caller (since already returned).

Resolution: A behavior that is initially invoked via a synchronous call does not have its own thread of control, so it would be a fundamental semantics change to somehow allow it to continue executing after returning from the call. Fortunately, however, the functionality desired by the submitter can be easily achieved using existing UML mechanisms, by first starting the activity asynchronously, either as a classifier behavior or as a standalone behavior execution. Such an executing activity can then accept client requests using an accept event action and respond to them without terminating, as the submitter envisions. The activity can even accept a synchronous call via an accept call action and reply using a reply action, without terminating. In this case, the reply action acts, in effect, as the "soft return" suggested by the submitter. Revised Text: None Disposition: Closed No Change
Revised Text:
Actions taken:
March 18, 2008: received issue
April 26, 2010: closed issue

Issue 12383: Section: 7.3.10/Associations (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Please explain why constrainedElement has to be an ordered set and not a set

Resolution:
Revised Text:
Actions taken:
April 16, 2008: received issue
April 16, 2008: lose issue, duplicate of 12382

Issue 12384: Section: 7.3.10/Associations - insert reference (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

�Certain kinds of constraints (such as an association �xor� constraint) are predefined in UML� Please insert a reference to the document containing the predefined constraints

Resolution: See issue 9617 for disposition
Revised Text:
Actions taken:
April 16, 2008: received issue
April 25, 2011: closed issue

Issue 12385: Section: 12.3.8/Generalizations (uml2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Nature: Clarification
Severity: Minor
Summary:

ActivityNode need not specialize �NamedElement (from Kernel, Dependencies)� because is specializes ��RedefinableElement (from Kernel)� which in turn specializes �NamedElement (from Kernel, Dependencies)�.

Resolution:
Revised Text:
Actions taken:
April 16, 2008: received issue
April 25, 2011: closed issue

Discussion:

The two generalizations of ActivityNode actually happen in different merge increments. ActivityNode specializes only NamedElement, not RedefinableElement, in FundamentalActivities (see Figure 12.2). The generalization to RedefinableElement is only added in BasicActivities (see Figure 12.4).
Disposition: Closed, no change

Issue 12432: Section: 7.3.7 and 8.3.1 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

Resolution: This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership. We can resolve these by adding two constraints to Component: � A Component's nestedClassifier collection is always empty. � If a Component is nested in a Class, then its packagedElement collection is empty.
Revised Text: In 8.3.1 Constraints, add the following: [1] A component cannot nest classifiers. self.nestedClassifier.isEmpty() [2] A component nested in a Class cannot have any packaged elements. (not self.class.isEmpty()) implies self.packagedElement.isEmpty()
Actions taken:
May 9, 2008: received issue
April 26, 2010: closed issue

Issue 12433: Section: Activities: Modifications to the approved resolution of 10815 (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Modifications to the approved resolution of 10815. It should use a different keyword for decision input flows than the existing one for decision input behaviors. It should include an update to the notation figure, and to the keyword index.

Resolution: Revise the resolution to 10815 as suggested
Revised Text: In the revised text of 10815 Replace the reference to �Section 13� with �Section 12�. Replace the keyword �decisionInput� with �decisionInputFlow� throughout. In the next-to-last paragraph (which is one sentence), remove �the first sentence of�. The resolution is intended to replace a whole paragraph. In the last paragraph, second sentence, at end, add �as shown at the bottom of the figure below�. At the end of the revised text, add the text and figure below: In Figure 12.76 (Decision node notation), at the bottom add, in the same scale as the rest of the figure: �decisionInputFlow�... After the above, add the text below: In Annex B (Keywords), In numbered list for Notation Placement,: After the entry for �dashed-line label�, insert a new entry ��line label� means that the keyword is used as a label on some line.� At the end, add a new entry ��note label� means that the keyword is used in a note symbol.� In Table B.1 - UML Keywords, before the row for �delegate�, add two more rows as shown: decisionInput Activities Comment annotatedElement.decisionInput.name = body, or annotatedElement.decisionInput.body = body (for opaque behaviors), or annotatedElement.decisionInput.com ment.body = body decisionInputFlow Activities ActivityEdge target.decisionInputFlow = self line label
Actions taken:
May 9, 2008: received issue
October 27, 2008: closed issue

Issue 12492: Port (uml2-rtf)

for Port, there is a constraint that say :

 

[1] The required interfaces of a port must be provided by elements to which the port is connected.

 

I believe that ports are connected by delegation connector, this constraint may not be checked!

 

Am I right?

Resolution: You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.
Revised Text: In 9.3.11 Port, delete constraint [1] and renumber the other constraints accordingly.
Actions taken:
May 15, 2008: received issue
April 26, 2010: closed issue

Issue 12532: definition of RedefinableElement::isLeaf (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Version of Spec:  2.1.1 2007--2-05, Section 7.3.46 p.130 

The definition of RedefinableElement::isLeaf indicates that "If the value is true, then it is not possible to further specialize the RedefinableElement".    However there is no explicit constraint that actually enforces this (at least none that I could find).   I believe that  a constraint should be created to address this.

Resolution: This issue is not a duplicate of issue 9831 which is closely related to issue 10515.
Revised Text: In 7.3.46 (RedefinableElement): Change: isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false. To: isLeaf: Boolean Indicates whether it is possible to further redefine a RedefinableElement. If the value is true, then it is not possible to further redefine the RedefinableElement. Note that this property is preserved through package merge operations; that is, the capability to redefine a RedefinableElement (i.e., isLeaf=false) must be preserved in the resulting RedefinableElement of a package merge operation where a RedefinableElement with isLeaf=false is merged with a matching RedefinableElement with isLeaf=true: the resulting RedefinableElement will have isLeaf=false. Default value is false. Add the constraint: [3] A redefinable element can only redefine non-leaf redefinable elements. self.redefinedElement->forAll(not isLeaf) In 7.3.40 (PackageMerge): Under "Property Rules"; CONSTRAINTS, remove: 4. Any redefinitions associated with matching properties must not be conflicting. Under "General package merge rules"; CONSTRAINTS, add: 8. Any redefinitions associated with matching redefinable elements must not be conflicting. Under "Property Rules"; TRANSFORMATIONS, remove: 6. For matching properties: different redefinitions of matching properties are combined conjunctively. Under "General package merge rules"; TRANSFORMATIONS, add: 11. For matching redefinable elements: different redefinitions of matching redefinable elements are combined conjunctively. 12. For matching redefinable elements: if both matching elements have isLeaf=true, the resulting element also has isLeaf=true; otherwise, the resulting element has isLeaf=false.
Actions taken:
June 17, 2008: received issue
April 26, 2010: closed issue

Issue 12556: Section: 7.3.35 (uml2-rtf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity: Significant
Summary:

In order to be complinat with the semantics, "body" and "language" properties of an OpaqueExpression shall be ordered

Resolution:
Revised Text:
Actions taken:
June 25, 2008: received issue
April 25, 2011: closed issue

Discussion:

They are in the 2.3 specification. See figure 7.6 and section 7.3.35 of Superstructure, figure 11.4 of InfrastructureLibrary.
Disposition: Closed, no change

Issue 12557: The behavior of an OpaqueExpression should itself be opaque (uml2-rtf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity: Significant
Summary:

The behavior of an OpaqueExpression should itself be opaque

Resolution: Under Subclause 13.3.21, it says that the extension to OpaqueExpression "Provides a mechanism for precisely defining the behavior of an opaque expression." It is hard to see how one can precisely define behavior, if the behavior is itself opaque. Indeed, specifying the behavior of an OpaqueExpression with, say, an activity is the only way to model an expression in UML in terms of executable actions, so this should not be precluded. Revised Text: None. Disposition: Closed No Change
Revised Text:
Actions taken:
June 25, 2008: received issue
April 26, 2010: closed issue

Issue 12558: Section: 13.3.23 (uml2-rtf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity: Significant
Summary:

The multiplicity of the "signal" property of a Reception is [0..1]. What's the semantic of a Reception that would be associated with no signal?

Resolution: Areception should be required to specify a signal.
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Figure 13.9, on the association end Reception::signal, change the multiplicity 0..1 to 1. In Subclause 13.3.23 Reception, under Associations, change "signal: Signal [0..1]" to "signal: Signal [1]".
Actions taken:
June 25, 2008: received issue
April 26, 2010: closed issue

Issue 12564: Section: 13.3.3 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Problem 2 2.1 Relation raisedException of Operation and BehavioralFeature classes not consistently set (CommonBehaviors/Communications) (L2 compliance). Operation (Classes/Kernel) (L1 compliance level ) inherits from BehavioralFeature (Classes/Kernel) (L1) and redefines raisedException to Type. On that level there is no problem. But in CommonBehaviors/Communications BehavioralFeature redefines raisedExceptions to point to Classifier. As a result Operation points to Type, while BehavioralFeature to Classifier. Classifier is more specific than Type (Classifier inherits from Type) +++++++++++++++++++++++++++++++++++++++++++ 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: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

Resolution: There does not seem to be any reason for Communications::BehavioralFeature to have a raisedException attribute. It is not used anywhere in Communications. Kernel::BehavioalrFeature already has a raisedException property that will be included when the BehavioralFeature merge increments are actually merged.
Revised Text: In the UML 2.2 Specification (formal/09-02-02), Figure 13.10, remove the association raisedException and the symbol for Classifier. In Subclause 13.3.3 BehavioralFeature, under Associations, remove the heading "Package Communications" and the bullet for raisedException.
Actions taken:
July 10, 2008: received issue
April 26, 2010: closed issue

Issue 12565: Section: 12.2 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Problem 1 Some classes in certain packages are abstract, while they are not in packages that are on a higher (or the same) compliance level. 1.3. Pin in Activities/BasicActivities (L1 compliance level) (Fig. 12.4 p.299 ) and Activities/CompleteActivities (L3) (Fig.12.16 p. 305) are not abstract, while in they are in package ActionsBasicActions (L1) (Fig. 11.3 p. 221) ++++++++++++++++++++++++++++++++++++++++++ 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: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

Resolution: agreed
Revised Text: In the UML 2.3 Superstructure Specification, in Figures 12.4 and 12.16, show the class Pin as being abstract (italicized), and make the classes BasicActivities::Pin and CompleteActivities::Pin abstract in the normative metamodel.
Actions taken:
July 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Issue 12583: OCL 2.0 8.2 Real (uml2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL reuses Boolean, Integer, String, UnlimitedNatural from UML Infrastructure.


OCL uses Real in a very similar fashion, but there is no corresponding
definition of Real in either OCL or UML Infrastructure.

Resolution: The primitive type �Real� needs to be added to the PrimitiveTypes package for consistency with the OCL Real type. �Real� has also been defined separately by SysML and MARTE specifications and the new Diagram Definition Submission, so adding it to the PrimitiveTypes package will encourage reuse. Another argument for adding a primitive type �Real� is that there is currently no normative way to notate real numerals in UML models. So, even if some model library adds a �Real� primitive type, there is technically still no normative way to write a literal for that type in a UML model. This suggests the need for a Real Literal definition as well. (Note that the revised text below presumes the resolution to Issue 13993.)
Revised Text: see pages 38 - 40 od prc/2011-01-19
Actions taken:
July 19, 2008: received issue
October 16, 2009: Transferred to UML2 RTF and MOF 2.2 RTF
April 25, 2011: closed issue

Discussion:

This is an issue for UML2 Infrastructure and MOF
Disposition:	Transferred to UML2 RTF and MOF 2.2 RTF

Issue 12587: UML2: Need a better mechanism for integrating UML2 Profiles (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

UML2 Superstructure specifies how to define a Profile, how Profiles can reference other Profiles through PackageImport and ElementImport, and how one stereotype could extend another through generalization/specialization. However, this is insufficient for profile integration as it results in too much coupling between profiles. What is needed is a more flexible mechanism for integrating UML2 profiles.

For example, both UPDM and SysML are UML2 profiles. UPDM would like to reuse certain stereotypes from SysML in order to provide effective integration in cases where consumers want to use both. However, UPDM would also like to be able to stand alone in cases where SysML isn't needed. The problem is how to model the overlapping stereotypes and classes without creating coupling that would require all applications of the UPDM profile to also require an application of SysML.

Consider a concrete example of overlap between the profiles, the stereotype ViewPoint. Both UPDM and SysML have a similar concept of ViewPoint, for similar purposes. However, each has its own specializations of ViewPoint, and possibly associations between ViewPoint and other stereotypes. There are a number of approaches for handling this overlap, but none are adequate or practical.

1. Profile refactoring: Each profile could factor its stereotypes into packages, and arrange the navigability of its associations to decouple its stereotypes in order to support anticipated reuse. This is what UML2 did, quite unsuccessfully, with the Abstractions packages. This isn't practical because 1) no existing profiles do it, 2) it is impossible to anticipate all the possible reuse opportunities and to design a profile to support them, and 3) it is sometimes impossible to define the associations between stereotypes to ensure the necessary decoupling.

2. Use ElementImport to select only the stereotypes you need, then subclass to minimize the coupling: This can work, but it results in complex profiles with possibly a lot of subclasses simply to integrate with other profiles. For example, UPDM couldn't use ViewPoint directly, it would have to create a subclass, either coming up with a new name, or putting its ViewPoint in a different Package so that it wouldn't collide with SysML. This is confusing, and results in stereotypes with either the same meaning but different names, or two stereotypes with the same name in different packages. This also requires both profiles to exist, even though the both don't need to be applied. This is again an undesirable side-effect of too much coupling.

Both of these approaches end up inhibiting profile integration and reuse resulting in limited integration between OMG submissions. UPMS had wanted to include integrations with many other submissions including RAS, BPDM, BPMN, ODM, QoS, and BMM. However we could not determine a practical way to do this with current technologies and did not include many of these integrations because of the resulting risk, complexity and coupling. This is a particular problem when we consider the OMG specifications, profiles, and metamodels in an enterprise architecture context where the relationships between the parts are critical to delivering value.

UML2 provides a solution to this problem for extensions created using MOF metamodels to model capabilities. PackageMerge can be used to merge metaclasses with the same name from different capabilities in order to mixin their capabilities. What is needed is a similar capability for UML2 profiles.

A proposed solution would be to extend UML2 Profiles to include similar merge semantics when multiple profiles containing the same classes or stereotypes are applied to the same model. When a Profile is applied to a Package, the Classes and Stereotypes in the Profile would be merged with Classes and Stereotypes of other Profiles that have already been applied. The rules for PackageMerge can be used to define how this merge is done as they already apply to Class, and can equally apply to Stereotype which is a specialization of Class. Conflicts resulting from the merge could be considered defects against the profiles that could be handled in an RTF.

Consider the same example above; both UPDM and SysML define ViewPoint.

3. Profile Merge: The UPDM submitters would be careful to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM conuld extend ViewPoint with additional properties and associations for its purposes. The UPDM submission could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling or need for SysML. Later on, another user could decide to apply SysML to the same model in order to use its modeling capabilities. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Similarly, users could have started with SysML and later applied UPDM to achieve the same effect.

This is a significant change to UML2, but may be an urgent issue due to the number of other profiles and submissions looking for a solution to this problem.

Resolution:
Revised Text: In section 18.3.6, just before the subsection "Using XMI to exchange Profiles" add the following subsection (at the same heading level): Integrating and extending Profiles Integrating and extending existing profiles can result in improved reuse, better integration between OMG specifications, and less gaps and overlaps between metamodel extensions. There are a number of ways to create, extend and integrate profiles. These are described briefly in this section in order to foster better profile integration and reuse. The simplest form of profile integration is to simply apply multiple profiles to the same model. This requires no integration between the profiles at all. Such profiles might be designed to complement each other, addressing different concerns. It is also possible to one profile to reuse all of or parts of another, and to extend existing profiles. Like any other class, Stereotypes can be defined in packages or profiles that can be factored for reuse. These stereotypes can be directly reused through PackageImport or ElementImport in other profiles. Importing profiles can also use Generalizations to extend referenced and reused stereotypes for their unique purposes. However, referencing stereotypes in other packages and profiles can sometimes result in undue coupling. This is because the referenced stereotypes may be associated with other stereotypes resulting in the need for the referencing profile to include large, perhaps unpredictable parts of the referenced profile in order to maintain semantic consistency. This can lead to unexpected burden on profile implementers and users because more is reused than intended resulting in coupling complex profiles together so they cannot be easily reused separately. PackageMerge can be used to address this problem. A profile can define stereotypes that intentionally overlap with stereotypes in another profile. The profiles can be designed in such a way that they can stand alone. But they can also be merged together using PackageMerge to create a new profile that combines the capabilities of both. Vendors and users can then decide whether to apply one profile or the other, or the merged profile to get capabilities resulting from the combination of two or more profiles. For example, The UPDM profile could integrate with SysML to reuse stereotypes such as Requirement and ViewPoint. UPDM could be designed to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM could extend ViewPoint with additional properties and associations for its purposes. The UPDM specification could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling with, or need for SysML. UPDM could then provide another compliance point that merges with the SysML profile resulting in stereotypes Requirement and ViewPoint having the capabilities of both profiles. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Users who want UPDM with SysML would then apply this merged profile.
Actions taken:
July 24, 2008: received issue
April 26, 2010: closed issue

Discussion:

PackageMerge is complex to define, understand and implement. Requiring tool vendors to support package merge, and for users to understand the results of package merge on profile application may be difficult and unadvisable. 

However, there is no reason that package merge can be used to merge profiles with overlapping stereotypes to create a new merged profile that users can apply. This is already supported by UML2 and requires no change. The only implementation of package merge needed is one to create the merged profile, an implementation is not needed in every tool that supports profile application. 

Using package merge has the disadvantage that users can't apply one profile, then decide later to apply another and have the stereotypes be automatically merged. This limits profile reuse somewhat, but is a reasonable compromise. Future versions of UML may address more flexible approaches to profile integration. But this may have to be done in the context of better integration between MOF and UML extensibility mechanisms and is out of scope for an RTF.

Issue 12775: Section: 9.3.8 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is an association of EncapsulatedClassifier (9.3.8) ownedPort which is derived and subsets Class::ownedAttribute. The problem I have is that I don't see how ownedPort can subset Class::ownedAttribute. I don't see an inheritance path from EncapsulatedClassifier to Class. Also, which Class is it referring to? Class (from Kernel), Class (from StructuredClasses), etc. This problem exists for all "subsets" statements in the specification. Thank you.

Resolution: It should in fact refer to StructuredClassifier::ownedAttribute
Revised Text: In section 9.3.8, Associations o /ownedPort: Port [0..*] The set of port attributes owned by EncapsulatedClassifier. (Subsets Class::ownedAttribute) Replace "Subsets Class::ownedAttribute" by "Subsets StructuredClassifier:ownedAttribute".
Actions taken:
August 14, 2008: received issue
April 26, 2010: closed issue

Discussion:

Issue 12781: Incorrect OCL expression for constraint [1] on BehavioredClassifier (uml2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Source:  UML 2.2 Superstructure document and XMI


http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12 

Nature: incorrect OCL constraint


Summary:


The following constraint on BehavioredClassifier (13.3.4) is incorrectly specified:


[1] If a behavior is classifier behavior, it does not have a specification.
self.classifierBehavior->notEmpty() implies self.specification->isEmpty()       

Discussion:


self.specification does not resolve to any attribute of BehavioredClassifier.
self.classifierBehavior resolves to a Behavior which can have 0 or 1 BehavioralFeature specification.
Hence, the correct OCL navigation expression should be self.classifierBehavior.specification instead of self.specification.


Revised Text:

Change the specification of the constraint to the following:

[1] If a behavior is classifier behavior, it does not have a specification.
self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()

Change the Superstructure XMI accordingly.

Resolution: agreed
Revised Text: In the UML 2.2 Specification (formal/09-02-02), in Subclause 13.3.4 BehavioredClassifier, change the OCL for Constraint [1] to: self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()
Actions taken:
August 15, 2008: received issue
April 26, 2010: closed issue

Issue 12792: figure 13.12 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the latest 2.2 version of the UML spec,  there was a change for issue :  11409 - redirect TimeEvent::when to TimeExpression (from ValueSpecification).     
In the resolution to that issue, figure 13.13 (p427)  was properly updated but it looks like figure 13.12 has a problem in that the association from TimeEvent should go to TimeExpression

Resolution: At first it seems like this would be any easy resolution - just update Figure 13.12. The problem is that the Event classes in Figure 13.12, including TimeEvent, are in the CommonBehaviors::Communications package, which is merged in at L1, while TimeExpression is in CommonBehaviors::SimpleTime, which is merged in at L2. Thus, having TimeEvent associated with TimeExpression - which is actually the case in the metamodel - causes a problem in the construction of L1 (which causes issues with the generation of XMI for L1). Now, one possibility would be to make the TimeEvent class in SimpleTime a merge increment. But the merging of typed elements has the constraint (see 7.3.40): "Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same." While not entirely clear, the implication is that the resulting type is the common supertype. In this case, TimeEvent::when has type ValueSpecification in Communications and type TimeExpression, a subclass of ValueSpecification, in SimpleTime. The common superclass is thus ValueSpecification - but if you end up with TimeEvent::when having type ValueSpecification in the merged L2, then there isn't much point in typing it as TimeExpression in SimpleTime! Another possibility would be to leave the type of TimeEvent::when as ValueSpecification, which would allow a TimeExpression to be used when SimpleTime is included at L3. But this was explicitly changed in the UML 2.2 RTF, indicating a strong desire that the type of TimeEvent::when be TimeExpression (which does make some sense). It also doesn't seem to be a good idea to merge SimpleTime into L1 instead of L2, just to be able to have TimeExpression available for TimeEvent. So, the proposed resolution is that TimeEvent be moved into SimpleTime. This means that time events would only be allowed at L2, not L1. But since state machines aren't included until L2 and accept event actions not until L3, it seems unlikely that this would be a real problem.
Revised Text: Remove TimeEvent from Figure 13.12 and from the package CommonBehaviors::Communications. Add it to package CommonBehaviors::SimpleTime and show the attribute "isRelative: Boolean = false" in the class box for TimeEvent on Figure 13.13.
Actions taken:
August 19, 2008: received issue
April 26, 2010: closed issue

Issue 12794: Property � Additional Operations, page 127. (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Property � Additional Operations, page 127.

 

In the description of �isConsistentWith� �

 

�[1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property.�

 

The last word, �property�, should be �derived�.

Resolution:
Revised Text:
Actions taken:
August 21, 2008: received issue
April 25, 2011: closed issue

Discussion:

No longer applicable. See resolution to 8460 where the last part of this sentence is removed. It is ok for a non-derived property to redefine a derived property as no capability is lost.
Disposition: Closed, no change

Issue 12833: Clarification on use of Profiles. (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Clarification
Severity:
Summary:

 would like to get some clarification on the use of Profiles. 

Although it does not explicitly state this in the UML superstructure specification, there seems to be an implication that only Profiles should actually own Stereotype.   The fact that Stereotype can be owned by any Package seems to be an unintended side effect of inheritance.    Is it true that the only feature intended to own a  Stereotype is Profile::ownedStereotype  ? 

If it is true that *only* Profile can own a Stereotype, then it makes working with profiles with many stereotypes somewhat unruly (consider having 50 stereotypes).   It would be nice to be able to group stereotypes within nested packages under a profile.   

 Nesting profiles within profiles does not seem like an appropriate solution since: in order to satisfy constraint [2] in 18.3.6 the nested profile would also have to reference a metamodel; inconvenient.     And, how would users use such a profile?   Would they apply each nested profile separately?  This seems to raise more problems than it solves. 


Either way, I would suggest that the spec. should provide some rules or guidelines in this area.

Resolution:
Revised Text: see pages 153 - 155 of ptc/2009-09-07 for details
Actions taken:
September 4, 2008: received issue
April 26, 2010: closed issue

Discussion:

Stereotypes currently cannot be contained in (nested) packages, they must be contained in profiles or nested profiles. This because the derived association ownedStereotype has multiplicity 1 on the Profile end. The reason for this restriction is likely that packages cannot specify the metaclass and/or metamodel references necessary to define what the stereotypes might extend. The names of stereotypes or classes in a parent profile are not visible to a profile nested in that parent profile without a PackageImport. And the metaclassReferences and metamodelReferences of a parent profile are also not visible it its nested profiles or packages. 

However, there are many reasons for allowing stereotypes to be in packages or nested packages:
Namespace management for large profiles
Complexity management and separation of concerns in large profiles
Reuse of stereotypes in other profiles
These features are needed to support large profiles and profile reuse that may be beyond what was originally envisioned for profiles, but has none the less become common practice. To support these functions, stereotypes should be allowed in packages, and the metamodel and/or metaclass references for a stereotype should be derived from its directly or indirectly containing profile.

Issue 12843: Typo 9.3.13 p190 (uml2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

ownedAttribute : Property[0..*]
References the properties owned by the classifier. (Substes StructuredClassifier:: role,
Classifier.attribute...
~~~~~~~~~~~~~~~~~~~~
Classifier::attribute?

Resolution:
Revised Text: In 9.3.13, replace Classifier.attribute by Classifier::attribute
Actions taken:
September 8, 2008: received issue
April 26, 2010: closed issue

Issue 12848: TYPO p.54 Additional Operations (uml2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

[3] The query allParents() gives all of the direct and indirect
ancestors of a generalized Classifier.
Classifier::allParents(): Set(Classifier);
allParents = self.parents()->union(self.parents()->collect(p |
p.allParents())


It seems to be lack of the last parenthesis.

Resolution: Indeed, there is a missing closing parenthesis.
Revised Text: In section 7.3.8, of the Superstructure replace: allParents = self.parents()->union(self.parents()->collect(p | p.allParents()) with: allParents = self.parents()->union(self.parents()->collect(p | p.allParents())) Also, in section 9.19.1, of the Infrastructure replace: allParents = self.parents()->union(self.parents()->collect(p | p.allParents()) with: allParents = self.parents()->union(self.parents()->collect(p | p.allParents()))
Actions taken:
September 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Issue 12851: p269-p270 Constraint (uml2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

[2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in


"AssociationEnd" -> "Propertye"


[3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
270 UML Superstructure Specification, v2.2
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in


"AssociationEnd" -> "Propertye"


[4] The open end must be navigable.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in


"AssociationEnd" -> "Propertye"


[5] Visibility of the open end must allow access to the object performing the action.
let host : Classifier = self.context in
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in


"AssociationEnd" -> "Propertye"

Resolution: See issue 6462 (resolved in UML 2.3) for disposition
Revised Text:
Actions taken:
September 12, 2008: received issue
April 25, 2011: closed issue

Discussion:

Issue 12985: Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

Resolution: The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.
Revised Text: In 8.3.1 Component, Description::BasicComponents, replace: "A provided Interface is one that is either implemented directly by the component or one of its realizingClassifiers, or it is the type of a provided Port of the Component. A required interface is designated by a Usage Dependency from the Component or one of its realizingClassifiers, or it is the type of a required Port." by "A provided Interface is one that is either realized directly by the component or one of its realizingClassifiers, or it is provided by a public Port of the Component. A required interface is designated by a Usage Dependency from the Component or one of its realizingClassifiers, or it is required by a public Port."
Actions taken:
October 23, 2008: received issue
April 26, 2010: closed issue

Issue 13080: New proposal for conjugate types for ports (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

Is this acceptable?

Resolution: This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive. But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces. For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted. This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient. However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types. Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.
Revised Text: In figure 9.4, and the model, merge the following into the definition of the Port metaclass: Add the following to the Attributes of Port (9.3.11): � isConjugated: Boolean Specifies the way that the provided and required interfaces are derived from the Port's Type. The default value is false. Alter the definitions of required and provided under Associations of Port (9.3.11) to the following: /required: Interface [*] References the interfaces specifying the set of operations and receptions that the classifier expects its environment to handle via this port. This association is derived according to the value of isConjugated. If isConjugated is false, required is derived as the union of the sets of interfaces used by the type of the port and its supertypes. If isConjugated is true, it is derived as the union of the sets of interfaces realized by the type of the port and its supertypes, or directly from the type of the port if the port is typed by an interface. /provided: Interface [*] References the interfaces specifying the set of operations and receptions that the classifier offers to its environment via this port, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived according to the value of isConjugated. If isConjugated is false, provided is derived as the union of the sets of interfaces realized by the type of the port and its supertypes, or directly from the type of the port if the port is typed by an interface. If isConjugated is true, it is derived as the union of the sets of interfaces used by the type of the port and its supertypes. Delete the following text from 9.3.11: "The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port." Under the Notation section of 9.3.11, after the sentence "The type of a port may be shown following the port name, separated by colon (":")" add "When isConjugated is true for the port, the type of the port is shown with a tilde "~" prepended". Replace figure 9.16 with this: Above figure 9.16, replace the text starting "Figure 9.16" with "Figure 9.16 shows the notation for ports. On the left figure, p is a port on the Engine class. The provided interface of port p is powertrain and the required interface is feedback. The multiplicity of p is 1, its type is also powertrain, and isConjugated is false. On the right figure, e is a port of the class Wheel, which also has the type powertrain and isConjugated set to true."
Actions taken:
November 6, 2008: received issue
April 26, 2010: closed issue

Discussion:

Issue 13081: New proposal for conjugate types for ports (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is this acceptable?

Resolution: This is a verbatim duplicate of 13080 which I will address soon. Revised Text: None. Disposition: Duplicate.
Revised Text:
Actions taken:
April 26, 2010: closed issue

Discussion:

Issue 13083: UML 2.2 superstructure section 9.3.11 page 184: Port.isService (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of Port.isService appears to be redundant with the concept of public/private visibility.  Is it valid for an isService=true Port to be private, or for an isService=false Port to be public?  What about protected and package visibility for Ports?

Resolution: Resolution: From Bran Selic: Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific -- in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside. It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering. If you remove this capability, you will certainly invalidate a lot of models based on this notion. Revised Text: None. Disposition: Closed, no change.
Revised Text:
Actions taken:
November 17, 2008: received issue
April 26, 2010: closed issue

Issue 13137: Section: 7.3.39 PackageImport (from Kernel) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is some obvious copy/paste error: "Presentation options As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace..." This 7.3.39 section is about package import - not element import - so that sentence should look like: "As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace..."

Resolution:
Revised Text: In section 7.3.39 of Superstructure, subsection Presentation options, change the first paragraph from: As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace. To: As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace. In section 11.7.5 of InfrastructureLibrary, subsection Presentation options, change the first paragraph from: As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace. To: As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace.
Actions taken:
December 3, 2008: received issue
April 25, 2011: closed issue

Issue 13140: Semantics of Ports in Components and CompositeStructures are incompatible (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as �interaction point objects� typed by the type of the port.  Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply.    The sentence from 8.3.1  �The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time� clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects.  These contradictions should be resolved

Resolution: Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted. The remainder of the issue can be handled by some explanatory text as proposed below.
Revised Text: In 8.3.1 Attributes, replace the definition of isIndirectlyInstantiated. Original: isIndirectlyInstantiated : Boolean {default = true} The kind of instantiation that applies to a Component. If false, the component is instantiated as an addressable object. If true, the Component is defined at design-time, but at run-time (or execution-time) an object specified by the Component does not exist, that is, the component is instantiated indirectly, through the instantiation of its realizing classifiers or parts. Several standard stereotypes use this meta attribute (e.g., "specification", "focus", "subsystem"). Replace by: isIndirectlyInstantiated : Boolean {default = true} The kind of instantiation that applies to a Component. If false, the component is instantiated as an addressable object. If true, the Component is defined at design-time, but at run-time (or execution-time) an addressable object specified by the Component does not exist. Instead, the runtime behavior of the component and its ports can be completely inferred from the runtime behavior of its realizing classifiers or parts. Several standard stereotypes use this meta attribute (e.g., "specification", "focus", "subsystem").
Actions taken:
December 4, 2008: received issue
April 26, 2010: closed issue

Issue 13146: UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL definitions of how Component.provided and Component.required are still invalid, even though they were altered in 2.2.  The subexpressions self.implementation and self.realizingClassifier, which appear in both derivations, are not valid: there are no such properties on Component.

Resolution: It seems that the first "let" clause of each constraint is supposed to do what the second "let" actually does. So we'll delete the first one.
Revised Text: Replace the constraints in 8.3.1 by the following: /provided: Interface [*] The interfaces that the component exposes to its environment. These interfaces may be Realized by the Component or any of its realizingClassifiers, or they may be the Interfaces that are provided by its public Ports. The provided interfaces association is a derived association: context Component::provided derive: let realizedInterfaces : Set(Interface) = RealizedInterfaces(self) , realizingClassifiers : Set(Classifier) = Set{self.realizingClassifier}-> union(self.allParents().realizingClassifier), allRealizingClassifiers : Set(Classifier) = realizingClassifiers-> union(realizingClassifiers.allParents()) , realizingClassifierInterfaces : Set(Interface) = allRealizingClassifiers-> iterate(c; rci : Set(Interface) = Set{} | rci->union(RealizedInterfaces(c))) , ports : Set(Port) = self.ownedPort-> union(allParents.oclAsType(Set(EncapsulatedClassifier)).ownedPort) , providedByPorts : Set(Interface) = ports.provided in realizedInterfaces->union(realizingClassifierInterfaces) ->union(providedByPorts)-> asSet() o /required: Interface [*] The interfaces that the component requires from other components in its environment in order to be able to offer its full set of provided functionality. These interfaces may be Used by the Component or any of its realizingClassifiers, or they may be the Interfaces that are required by its public Ports. The required interfaces association is a derived association: context Component::required derive: let usedInterfaces : Set(Interface) = UsedInterfaces(self) , realizingClassifiers : Set(Classifier) = Set{self.realizingClassifier}-> union(self.allParents().realizingClassifier) , allRealizingClassifiers : Set(Classifier) = realizingClassifiers-> union(realizingClassifiers.allParents()) , realizingClassifierInterfaces : Set(Interface) = allRealizingClassifiers-> iterate(c; rci : Set(Interface) = Set{} | rci->union(UsedInterfaces(c))) , ports : Set(Port) = self.ownedPort-> union(allParents.oclAsType(Set(EncapsulatedClassifier)).ownedPort) , usedByPorts : Set(Interface) = ports.required in usedInterfaces->union(realizingClassifierInterfaces) ->union(usedByPorts)->asSet()
Actions taken:
December 5, 2008: received issue
April 26, 2010: closed issue

Issue 13147: UML 2.2 figure 8.10 has arrows the wrong way around (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The dependencies in 8.10 should surely point from the Component (the client) to the realizing Classifiers (the suppliers).  Also there is a redundant sentence �Alternatively, they may be nested within the component shape� above that figure which is repeated below.

Resolution: The first part of this issue is wrong (see resolution to 11008 for explanation). The notation for the diagram is wrong which will be fixed by 10651. The second part is correct.
Revised Text: Delete the following redundant sentence that appears immediately above figure 8.10: "Alternatively, they may be nested within the component shape."
Actions taken:
December 5, 2008: received issue
April 26, 2010: closed issue

Issue 13149: Section: 14.3.24 MessageSort (from BasicInteractions) (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"MessageSort is an enumeration of the following values: ... � asynchSignal - The message was generated by an asynchronous send action.createMessage - The message designating the creation of another lifeline object." The "createMessage" should be on a separate line: � asynchSignal - The message was generated by an asynchronous send action. � createMessage - The message designating the creation of another lifeline object.

Resolution:
Revised Text:
Actions taken:
December 9, 2008: received issue
April 25, 2011: closed issue

Discussion:

This has already been fixed.
Disposition: Closed, no change

Issue 13254: Notation for ExecutionSpecification (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Notation for ExecutionSpecification is described as: "Notation ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see �Lifeline (from BasicInteractions, Fragments)� on page 500). We may also represent an ExecutionSpecification by a wider labeled rectangle, ..." It seems that "ExecutionOccurences" above is typo as this paragraph is about ExecutionSpecifications, and thus text should read as: "Notation ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline ..."

Resolution:
Revised Text:
Actions taken:
January 14, 2009: received issue
April 25, 2011: closed issue

Discussion:

This has already been fixed.
Disposition: Closed, no change

Issue 13291: Instance modeling does not take into account stereotypes properties (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Instance modeling does not take into account stereotypes properties. 

Assume I create a stereotype that I apply to some Class.   That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class. 

I believe I should be able to create a slot for 'p' and assign some value to it. 

Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification.  The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

Resolution: withdrawn by issue submitter
Revised Text:
Actions taken:
January 15, 2009: received issue
January 20, 2009: closed issue

Issue 13306: Packaging Issues with Stereotype Extension (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section: 18.3.2 (Extension)

 

Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

 

However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

 

UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

Resolution: The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly. A couple of decisions need making about this metamodel, which we?ve discussed extensively in email: 1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package. 2. Do we apply any stereotypes such as �metamodel� or �metaclass� in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use �metamodel�. Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: �A Class that is extended by a Stereotype may be extended by the optional stereotype �metaclass� ��
Revised Text: Make the following revisions for Superstructure: In 18.1.1, replace this sentence: �Thus, in this clause, when we mention �Class,� in most cases we are dealing with the meta-metaclass �Class� (used to define every meta class in the UML superstructure specification (Activity, Class, State, Use Case, etc.).� By the following: �In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF. Thus when defining a UML profile, the profile?s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel merged at the highest level of compliance, L3, defined in UML whose xmi serialization is listed in Appendix H. This approach allows defining a UML profile for arbitrary subsets of the UML at lower levels of compliance, which can be further restricted using constraints defined in the profile.� In 18.1.2, delete this sentence, because it adds no value and is likely to confuse: �Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages.� In 18.3.5 Semantics, replace this: �The association �appliedProfile� between a package and a profile crosses metalevels: It links one element from a model (a kind of package) to an element of its metamodel and represents the set of profiles that define the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links between them.� By this: �The association �appliedProfile� between a package and a profile conceptually crosses metalevels: It links one element from a model (a kind of package) to an element of its metamodel and represents the set of profiles that define the extensions applicable to the package. In order to represent this conceptual crossing of metalevels, the UML metamodel is available as an instance of UML.� In 18.3.8 Semantics, replace �A stereotype is a limited kind of metaclass that cannot be used by itself� by �A stereotype is like a limited kind of metaclass that cannot be used by itself�, and �An instance �S� of Stereotype is a kind of metaclass that extends other metaclasses� by �An instance �S� of Stereotype is like a kind of metaclass that extends other metaclasses�. In Annex H, add the following normative document: ? http://www.omg.org/spec/UML/<version number>/UML.xmi (where <version number> is the date-based version number associated with UML 2.4) Make the following revisions for Infrastructure: In clause 13, second paragraph, replace this sentence: �Thus, in this clause, when we mention �Class,� in most cases we are dealing with the meta-metaclass �Class� (used to define every meta class in the UML superstructure specification (Activity, Class, State, Use Case, etc.).� By the following: �In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF. Thus when defining a UML profile, the profile?s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel merged at the highest level of compliance, L3, defined in UML whose xmi serialization is listed in Appendix C. This approach allows defining a UML profile for arbitrary subsets of the UML at lower levels of compliance, which can be further restricted using constraints defined in the profile.� In clause 13, third paragraph, delete this sentence, because it adds no value and is likely to confuse: �Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages.� In 13.1.5 Semantics, replace this: �The association �appliedProfile� between a package and a profile crosses metalevels: It links one element from a model (a kind of package) to an element of its metamodel and represents the set of profiles that define the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links between them.� By this: �The association �appliedProfile� between a package and a profile conceptually crosses metalevels: It links one element from a model (a kind of package) to an element of its metamodel and represents the set of profiles that define the extensions applicable to the package. In order to represent this conceptual crossing of metalevels, the UML metamodel is available as an instance of UML.� In 13.1.8 Semantics, replace �A stereotype is a limited kind of metaclass that cannot be used by itself� by �A stereotype is like a limited kind of metaclass that cannot be used by itself�, and �An instance �S� of Stereotype is a kind of metaclass that extends other metaclasses� by �An instance �S� of Stereotype is like a kind of metaclass that extends other metaclasses�. Add a new Annex C as follows: �Annex C: UML XMI Documents (normative) UML defined in UML: ? http://www.omg.org/spec/UML/<version number>/UML.xmi� (where <version number> is the date-based version number associated with UML 2.4)
Actions taken:
January 20, 2009: received issue
April 25, 2011: closed issue

Issue 13327: P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo (uml2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

Regarding UML 2.2 Superstructure


P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences


ExecutionOccurences
             ~~

Resolution:
Revised Text:
Actions taken:
January 23, 2009: received issue
April 25, 2011: closed issue

Discussion:

This has already been fixed.
Disposition: Closed, no change

Issue 13330: Allowing multiple Associations in a Package with the same name (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I had a recent �argument� with Steve Cook on his blog. There is a lot of confusion with regards to whether there can be multiple Associations with the same name in a Package. Steve made the valid point that Association does not redefine �isDistinguishableFrom�, which it gets from being a NamedElement. This is overridden for BehavioralFeature, but not for Association, thus based on that rule from NamedElement, I assume that there may not be multiple Associations with the same name (including empty) in a Package.

However, I came across the following cases that seem to ignore this notion:

1) In the rules for PackageMerge (7.3.40), they allow for the ability to have multiple Associations with the same name by taking into account their member ends: �Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties).�

2) The MOF 2.0 XMI file almost never names its� Associations, thus having many Associations with the same name.

3) The UML 2.1.1 Superstructure XMI file also has multiple associations with the same name. As an example, see the package with id �AuxiliaryConstructs-Templates�. It owns 3 associations with the name �A_templateParameter_parameteredElement� (ids �A_templateParameter_parameteredElement�, �A_templateParameter_parameteredElement.1� and �A_templateParameter_parameteredElement.2�).

Is it intended that multiple Associations with the same name be allowed in a Package or not? If not, then we need to fix Superstructure, MOF, and we can also relax the PackageMerge rule for Associations. If we do allow it, then we should add a new redefinition of �isDistinguishableFrom� for Association that specifies a similar rule to the one described in PackageMerge, that an Association type is distinguishable from another Association if the set of its name and the names of all its member ends is not equal to the corresponding set of the other Association.

Resolution: A redefine of isDistinguishableFrom for Association is not desired. As such, the PackageMerge rule for Association, which implies the possibility of multiple Associations in a Package with the same name, including if they have no name, provided their member ends differ in some way, is to be amended as it can result in ill-formed merged Packages. This is supported by the following 2 constraints: 1. MOF 2.0 Specification, under section "12.4 EMOF Constraints" there is the following constraint (which would be violated if the Associations have no name): "[3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool)." 2. In "9.14.2 Namespace" of the UML 2.1.2 Infrastructure Specification there is the following constraint (which would be violated if the Associations have the same name): "[1] All the members of a Namespace are distinguishable within it." As such, explicit rules are also to be added to PackageMerge requiring well-formedness of the merged Package. The XMI elements cited as examples of clashing Association names are to be renamed.
Revised Text: 1. In the Superstructure specification document, for "7.3.40 PackageMerge (from Kernel)": a. Under "Association Rules", Change the rule that says "Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties). These rules are in addition to regular property rules described above." To "Elements that are a kind of Association match by name and metatype." b. Under "Package Rules", before the heading "TRANSFORMATIONS:" CONSTRAINTS: 1) All classifiers in the merged package must have a non-empty qualified name and be distinguishable in the merged package. 2) All classifiers in the receiving package must have a non-empty qualified name and be distinguishable in the receiving package. 2. In the Infrastructure specification document, for "11.9.3 PackageMerge" a. Under "Association Rules", Change the rule that says "Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties). These rules are in addition to regular property rules described above." To "Elements that are a kind of Association match by name and metatype." b. Under "Package Rules", before the heading "TRANSFORMATIONS:" insert the following: CONSTRAINTS: 1) All classifiers in the merged package must have a non-empty qualified name and be distinguishable in the merged package. 2) All classifiers in the receiving package must have a non-empty qualified name and be distinguishable in the receiving package. 3. In Superstructure.xmi, make the following changes: a. For element with id="AuxiliaryConstructs-Templates-A_templateParameter_parameteredElement" change name to "AuxiliaryConstructs-Templates-A_classifier_templateParameter_parameteredElement". Show the association name label in Figure 17.18 b. For element with id="AuxiliaryConstructs-Templates-A_templateParameter_parameteredElement.1" change name to "AuxiliaryConstructs-Templates-A_operation_templateParameter_parameteredElement". Show the association name label in Figure 17.29 c. For element with id="AuxiliaryConstructs-Templates-A_templateParameter_parameteredElement.2" change name to "AuxiliaryConstructs-Templates-A_connectableElement_templateParameter_parameteredElement". Show the association name label in Figure 17.30
Actions taken:
November 27, 2008: received issue
April 26, 2010: closed issue

Issue 13476: UML 2: conflicting specifications for how to calculate context for a Behavior (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to 13.3.2 context is calculated as follows:  �If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships.�  Also according to 13.3.2 �When a behavior is instantiated as an object, it is its own context.�  These two statements are contradictory.

Resolution: The second quoted sentence is confusing, though the intended meaning is not contradictory with the calculation of the context classifier. The intent is that, when a Behavior without a context classifier is instantiated then, at runtime, the behavior instance acts as its own context object, even though it is not its own context classifier.
Revised Text: In Section 13.3.2, replace the last sentence under Semantics with: A behavior that is not owned, directly or indirectly, by a behaviored classifier will not have a context classifier. However, such a behavior may still be instantiated and executed as an object in its own right. In this case, the behavior instance acts as its own context object (for the purposes of event pooling, etc.), even though the behavior itself has no context classifier.
Actions taken:
February 9, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 13477: default multiplicty of association ends are defined more than one (uml2-rtf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity:
Summary:

In the infrastructure 6.2.1 it says

 

If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.

 

 

However, in 

8.3.3 Associations 

The opposite ends of associations connected to the class are also listed in the same way. The sub clause states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is �*� (default in UML).

 

 

It appears that the default is 1 and the default is also * which is confusing. 

 

 

I believe it should be clarified something like this. 

 

When an association is shown as an attribute/property, the default multiplcity is the same as the default attribute/property multiplictty (1)

When an assocation or attribute is shown as a association (that is, on the end of a line), the default multiplicity should be (*)

Resolution: The default multiplicity is always 1. This text appears only in the section describing the structure and conventions used by the specification itself. Superstructure has the following similar text: The �Attributes� sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*. Which is inconsistent with the Infrastructure text for Attributes: The multiplicity of the attribute is suppressed it defaults to �1? (default in UML). In practice both documents are now explicit about all association multiplicities, and suppress only attribute multiplicities of [1].
Revised Text: Replace Infrastructure section 8.3.3 by the following: The member ends of associations connected to the class are also listed in the same way. The sub clause states if the property is derived, or if it subsets or redefines another end. Replace the following in Superstructure 6.4.1 Specification Format: The �Attributes� sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*. By: The �Attributes� sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 1..1 (the default in UML).
Actions taken:
February 11, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 13659: Figure 12.95 - "Fork node example" (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Figure 12.95 - "Fork node example" shows "Fill Order" twice, while it should show - as explained right above - that when "Fill Order" is completed, "Ship Order" and "Send Invoice" get control.

Resolution: See issue 10818 (resolved in UML 2.3) for disposition
Revised Text:
Actions taken:
March 5, 2009: received issue
April 25, 2011: closed issue

Issue 13660: Table 12.1 - "Graphic nodes included in activity diagrams", (uml2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Table 12.1 - "Graphic nodes included in activity diagrams", the row "ActivityNode" states: "See ExecutableNode, ControlNode, and ObjectNode." But the "ExecutableNode" row is missing in the table. The action needed is to insert another row in the table for "ExecutableNode" with smth like "See Action, StructuredActivityNode". But the "StructuredActivityNode" row is not present in the table as well. So insert another row for "StructuredActivityNode" with notation taken from p.419, Figure 12.133 "Notation for structured nodes".

Resolution: See issue 11162 (resolved in UML 2.3) for disposition
Revised Text:
Actions taken:
March 6, 2009: received issue
April 25, 2011: closed issue

Issue 13661: Generalizations" for StructuredActivityNode on p. 417 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Generalizations" for StructuredActivityNode on p. 417 include: � Action � ActivityGroup � ExecutableNode � Namespace but "Figure 12.21 - Structured nodes" on page 313 shows StructuredActivityNode and Action as siblings (generalization for both is ExecutableNode). So either "Action" should be removed from Generalizations for StructuredActivityNode on p. 417 or the diagram on p. 313 to be updated to show different relations between these nodes.

Resolution:
Revised Text:
Actions taken:
March 6, 2009: received issue
April 25, 2011: closed issue

Discussion:

StructuredActivityNode specializes ExecutableNode but not Action at the level of StructuredActivities. However, the generalization to Action is added in CompleteStructuredActivities. This is shown in Fig 12.22.
Disposition: Closed, no change

Issue 13718: Section 12.3.48 on page 412 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. James Bruck, jbruck(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Spec. version 2.2 ptc/2008-05-xx   

Regarding section 12.3.48 on page 412,     I believe that both  StructuredActivityNode::node and StructuredActivityNode::edge should also subset Namespace::ownedElement.

Resolution: Agreed, except that the reference would normally be to just Element::ownedElement, especially since this is inherited from multiple immediate superclasses of StructuredActivityNode.
Revised Text: In the UML 2.3 Superstructure Specification, in Subclause 12.3.48 StructuredActivityNode, under Associations, in the description of �node�, change �{Subsets ActivityGroup::containedNode)� to �{Subsets ActivityGroup::containedNode, Element::ownedElement}�. In Subclause 12.3.8 ActivityNode, under Associations, in the description of �inStructuredNode�, change �{Subsets ActivityNode::inGroup)� to �{Subsets ActivityNode::inGroup, Element::owner}�. Also update Figure 12.21 to show both these changes. In Subclause 12.3.48 StructuredActivityNode, under Associations, in the description of �edge�, change �{Subsets ActivityGroup::containedEdge)� to �{Subsets ActivityGroup::containedEdge, Element::ownedElement}�. In Subclause 12.3.5 ActivityEdge, under Associations, in the description of �inStructuredNode�, change �{Subsets ActivityEdge::inGroup)� to �{Subsets ActivityEdge::inGroup, Element::owner}�. Also update Figure 12.22 to show both these changes.
Actions taken:
March 13, 2009: received issue
April 25, 2011: closed issue

Issue 13852: Section: Fig. 7.15: subsets at wrong side (uml2-rtf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

Subsets target and subsets source at the associations from Dependency to NamedElement are at the wrong side. They are property strings of the association ends supplier and client.

Resolution:
Revised Text: see pages 51 - 52 of ptc/2011-01-19
Actions taken:
April 2, 2009: received issue
April 25, 2011: closed issue

Issue 13898: what's the difference > between weight=1 and weight=*? (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

I agree with the resolution, but I > ask myself what's the difference > between weight=1 and weight=*? Edge weight controls how many offers must be accepted by the target of the edge for any tokens to traverse the edge at the same time ("the minimum number of tokens that must traverse the edge at the same time."). The default weight=1 lets just one offer be accepted for a token to traverse (all tokens might be offerred to the ObjectFlow, but it's OK if only one is accepted, it traverses). Weight=2 requires two to be accepted, or none traverse. Weight = * requires all tokens currently at the source to be accepted for any to traverse. If for some reason the target of the ObjectFlow can't accept all the tokens required by the weight (maybe the target is full), the object flow can't accept any. In the example Ed was concerned with, there's no reason for the target of an ObjectFlow to reject offers, so weight=1 causes all the tokens at the source to move at once, as if weight=*. Weight=* gives a different execution of the join in Figure 12.45 than weight=1 (refered to in the Semantics of ActivityEdge). Normally the join would take one token from Bids For Proposal when the Ready to Award Bid event occurs (or at least I thought it would, the join semantics isn't clear on that I notice), but with weight=*, the join must take all the tokens in Bids For Proposal. The semantics of weight=* is slightly bent, because you would think it means an infinite number of tokens must traverse at the same time. It actually means whatever number of tokens are at the source must traverse at the same time (it's using "*" like a wildcard instead of infinity, not so good). The wording of the paragraph in Semantics of ActivityEdge could be improved if you'd like to file issue. In particular: - Where it says "When the minimum number of tokens are offered" it should say "accepted" instead of "offered". - The sentence starting "An unlimited weight" should continue "means that all the tokens at the source must be accepted for any of them to traverse the edge". Conrad

Resolution: Clarify that weight gives the minimum number of tokens that must be accepted by the target of an ActivityEdge for any tokens to traverse the edge, and that weight=UnlimitedInteger means the minimum number of tokens is the number currently at the source of the ObjectFlow.
Revised Text: In Activities, ActivityEdge, Semantics, Package Complete Activities, first paragraph: After the fifth sentence (the one starting "When the minimum number"), insert a new sentence "The minimum number of tokens must be accepted by the target for any tokens to traverse the edge." In the eighth sentence (the one starting "An unlimited weight"), replace the portion of the sentence starting at "are" with "must be accepted by the target for any of them to traverse the edge".
Actions taken:
April 25, 2009: received issue
April 26, 2010: closed issue

Discussion:

Issue 13914: Clarify that input pins do not accept more tokens than their actions can immediately consume (uml2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Clarify that input pins do not accept more tokens than their actions can immediately consume

Resolution: The Activities, (12.3.2) Action, Semantics, item 1, says The object flow prerequisite is satisfied when all of the input pins are offered all necessary tokens and accept them all at once, precluding them from being consumed by any other actions. This ensures that multiple action executions competing for tokens do not accept only some of the tokens they need to begin, causing deadlock as each execution waits for tokens that are already taken by others. The "necessary tokens" in the first sentence above are the ones needed to execute the actions (meeting the minimum multiplicity), but should include any additional ones offered up the maximum multiplicity. Only these are accepted by the input pins, then immediately consumed by the action. The second sentence gives the motivation, which is to avoid having tokens in input pins that are not immediately consumed. This would prevent those tokens from being used to execute other actions, potentially creating deadlock or starvation. Deadlock is discussed more in issue 7221 of the UML 2.0 FTF report (http://doc.omg.org/ptc/04-10-01).
Revised Text: In Activities, 12.3.2 (Action), Semantics: In first paragraph, as modified by issue 8861, at end of next to last sentence (the one beginning "The action begins execution"), add "allowed by input pin multiplicity". Further down In item [1] , second sentence, after "necessary tokens" insert ", as specified by their minimum multiplicity,". After "all at once" insert "up to their maximum multiplicity". Last sentence, after "This ensures" replace the rest of the sentence with "input pins on separate actions competing for the same tokens do not accept any the action cannot immediately consume, causing deadlock or starvation as actions wait for tokens taken by input pins of other actions but not used." Further down in Item [2], as modified by Issue 8861, Last sentence, replace "can be" with "are". Add additional sentence at end of the same paragraph: "For structured actions, tokens can remain on input pins during action execution, otherwise they are immediately removed from the input pins by the action execution." In 12.3.32 (Input Pin), Semantics, Insert as separate paragraph at the beginning "Input pins cannot accept more tokens than are consumed by their action during its execution. For structured actions, tokens can remain on input pins during the action execution, otherwise they are removed from the input pins and immediately removed by the action execution." In the first sentence (current one), replace "See" with "Also see". Insert period at end.
Actions taken:
May 4, 2009: received issue
April 26, 2010: closed issue

Issue 13943: Activity groups should be named (uml2-rtf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Activity groups should be named. Interruptible Regions in particular. Nodes, Edges, and some Activity Groups are already named, such as Activity Partitions.

Resolution: Activity Groups specialize NamedElement intead of Element.
Revised Text: In Activities, Abstract Syntax, Figure 12.3 - Fundamental groups, Replace UML::Classes::Kernel::Element with UML::Classes::Kernel::NamedElement. Figure 12.10 - Partitions, remove UML::Classes::Kernel::NamedElement as generalization of ActivityPartition. Activity Group, Generalizations, replace Element with NamedElement, and appropriate cross reference. Activity Partition, Generalizations, remove NamedElement.
Actions taken:
May 31, 2009: received issue
April 26, 2010: closed issue

Issue 13991: Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Salman Qadri, Salman.Qadri(at)mathworks.com)
Nature: Uncategorized Issue
Severity:
Summary:

In UML, Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace, just like Operation-class and Operation-datatype. This is needed since the opposite of Operation-interface, which is �Interface-ownedOperation� subsets �Classifier-feature� and �Namespace-ownedMember�.

Resolution: This issue affects the XMI and the specification document of the UML2 superstructure.
Revised Text: In clause 7.1, Figure 7.16 of the Superstructure specification document, replace the annotation on the 'interface' member end of the association between Operation & Interface, currently: {subsets redefinitionContext} by: {subsets redefinitionContext, namespace, featuringClassifier} In the Superstructure XMI, extend the property subsets of UML::Classes::Interfaces::Operation::interface, currently: UML::Classes::Kernel::RedefinableElement::redefinitionContext by adding the following properties: UML::Classes::Kernel::Feature::featuringClassifier UML::Classes::Kernel::NamedElement::namespace
Actions taken:
June 15, 2009: received issue
April 26, 2010: closed issue

Issue 13993: UML 2.2 Issue - availability of PrimitiveTypes for UML models (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The introduction to section 17.4 states the following:

A number of primitive types have been defined for use in the specification of the UML metamodel. These include 

primitive types such as Integer, Boolean, and String. These types are reused by both MOF and UML, and may potentially 

be reused also in user models.

However the XMI for UML provides the definitions only as CMOF types not as UML types � so they cannot reliably/interchangeably be used/reused or referenced from user models. There would also need to be a normative URI defined for them.

Resolution: Indeed for better interchange of UML user models, there needs to be a normative PrimitiveTypes package (with a normative URI) with the common primitive types that can be referenced by UML XMI documents. Additionally, since such primitive types are also needed by almost all CMOF-based metamodels, a PrimitiveTypes CMOF package is needed. Unfortunately, the PrimitiveTypes package provided in the InfrastructureLibrary is meant to be package merged vs. referenced by metamodels. Since only few metamodels merge it (still resulting in private copies), the rest duplicate these primitive types in their context. This resolution proposes moving the PrimitiveTypes package out of InfrastructureLibrary.cmof and into its own independent package (PrimitiveTypes.cmof). This package can then be referenced instead of copied (through package merge) by metamodels. Additionally, the package can also be exported in UML XMI as PrimitiveTypes.xmi, to be referenced by user models.
Revised Text: see pages 53 - 60 of ptc/2011-01-19
Actions taken:
June 15, 2009: received issue
April 25, 2011: closed issue

Issue 14021: UML2: error in definition of Class::nestedClassifier (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Class::nestedClassifier currently reads:

 

nestedClassifier: Classifier [*] References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember

 

Element::ownedMember does not exist.  It should say Subsets Namespace::ownedMember.

Resolution: See issue 10829 for disposition
Revised Text:
Actions taken:
June 23, 2009: received issue
April 25, 2011: closed issue

Issue 14027: Semantics of the AddVariableValueAction (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the Semantics of the AddVariableValueAction there is a line stating: "If isReplaceAll is false and the variable is unordered and non-unique, then adding an existing value has no effect." I find this statement in correct and in conflict with the semantics defined in multiplicity element. multiplicityElement.ordered -> Specifies whether the values are inserted in a certain position which can be identified by an Integer. This has no influence whatsoever on WHAT values can be added to a variable. multiplicityElement.unique -> An instance (of any type) cannot appear more than once in the collection of values. addVariableValueAction.isReplaceAll -> Specifies if all the previous values are removed before inserting the new ones. This does have influence on WHAT values can be added to a variable. Therefore if the addVariableValueAction is true then the input collection only needs to be evaluated. Else the input collection and the existing values need to be cheked. If the variable IS unique then it must be ensured that the add operation does not put the same instance more than once in the variable. This means that input collection will be merged with the existing values collection (empty collection if isReplaceAll==true) and then the repeated isntances will be removed. If the variable IS NOT unique then there is no need to check anything. Having repeated values in an unordered collection might have sense, for example to execute an algorithm to retrieve the number of times a user has logged in.

Resolution: duplicate of issue # 8972
Revised Text:
Actions taken:
June 24, 2009: received issue
July 7, 2009: closed issue

Issue 14062: UML 2 chapter 17: template model cannot represent templates parameterized by value types (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In a programming language such as C# it is common, in libraries, to create parameterized types such as List<T>, which can be instantiated as List<Foo>, List<int>, List<Boolean> and so on.

 

UML templates do not permit the equivalent.  The parameters of a template are all instantiated objects of a known concrete metaclass.  It is therefore invalid for parameter-kind  (17.5.4) to be an abstract metaclass, such as Type. This is a very severe limitation when trying to map UML to C#.

Resolution: withdrawn by submitter, duplicate of 13257
Revised Text:
Actions taken:
July 8, 2009: received issue
July 8, 2009: closed issue

Discussion:

Issue 14063: remove StructuredActivities::ActivityGroup (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that �simple� structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a �procedural� style of the use of actions (along with the use of variables, sequence nodes and value pins).

It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don�t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2.

Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn�t seem to add anything. And, as you note, StructuredActivityNode doesn�t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!).

So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup � it is probably more than should be done �editorially�. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn�t actually hurt anything in the end.

Resolution: See issue 15264 for disposition
Revised Text:
Actions taken:
July 7, 2009: received issue
April 25, 2011: closed issue

Issue 14092: Ambiguity in the names of the stereotypes in the standard profiles (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: UML Superstructure, v2.2

Section: Annex C, Standard Profiles

 

It is not clear what the names actually are of the stereotypes in the standard profiles of UML. The stereotypes are listed in Annex C as they would be applied (using guillemet notation). However, Subclause 18.3.8 has the style guideline: �The first letter of an applied stereotype should not be capitalized.�  Due to the above style guideline, this leaves it ambiguous as to whether the actual stereotype model element is named �metaclass� or �Metaclass�. This affects XMI serialization of an application of the stereotype, because the XML element for the stereotype should use the actual stereotype model element name. 

 

Indeed, as a classifier, the normal practice would be for its name to be capitalized but it would then still be allowable to display this on the diagram using a lower case letter, as in �metaclass�. Unfortunately, there is no normative XMI for the standard profiles, so there is currently no way to resolve this based on the normative standard.

Resolution: The resolution is to provide normative XMI for the standard profiles, and to fix up the document accordingly. In order to do this properly we need to resolve 13306 by shipping a normative version of the UML metamodel expressed in UML. Having done this we can resolve 14092 by shipping standard profiles that refer to this normative UML metamodel. We change the convention so that references to stereotypes are shown with upper case letters, and change all the examples accordingly, fixing errors as we go. We permit lower case references but remark that they are stylistically obsolete.
Revised Text: see pages 61 - 67 of ptc/2011-01-19
Actions taken:
July 22, 2009: received issue
April 25, 2011: closed issue

Issue 14114: Remove InputPint from StructuredActivities (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

My inclination would be to remove StructuredActivities::InputPin, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2."

Resolution: Make InputPin only coming from CompleteStructuredActivities (and remove it from StructuredActivities in the metamodel). Then, for OutputPin sections add "Package CompleteStructuredActivities" as a subheading for the constraint (and move it in the metamodel to the counterparts in that package).
Revised Text: In Section 12.3.40, Constraints, add the following heading before the constraint: Package CompleteStructuredActivities In Section 12.3.32: - In the title, after "InputPin" add "(from CompleteStructuredActivities). - After the first paragraph add: Generalization "InputPin (from Basic Actions)" on page 268 (merge increment) In Figures 12.22, change the uses of UML::Actions::BasicActions::InputPin to UML::Activities::CompleteStructuredActivities::InputPin (but shown with an unqualified name).
Actions taken:
July 27, 2009: received issue
April 26, 2010: closed issue

Issue 14115: Need to copy down merged content to make constraints parse in receiving package (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Currently in the metamodel:

1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::attribute 

2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else.

A question: is the subsetting in 1 valid? 

The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::attribute is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. 

So to make things consistent, as Nic said, we should:

- Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier
- Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. 

in addition:

- don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures?
- Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration".
- So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. "

Resolution: For chapter 8, this resolution incorporates part of the resolution from the accepted resolution 7364, but modifies it in order to copy down the merged class and features required for the OCL constraint to parse in the context of the receiving package. For chapter 9, it sorts out InternalStructures::Classifier, which was introduced according to this "copy down" principle, but is not documented properly. Also Collaborations::Classifier inherits more than is necessary, so to simplify the overall documentation of Classifier in chapter 9, we can make both InternalStructures::Classifier and Collaborations::Classifier just specialize Kernel::Namespace.
Revised Text: Changes in Chapter 8 In the model (figure 8.3) show /kind: connectorKind as derived, with multiplicity [1]. Copy required classes and features into the package BasicComponents so that figure 8.3 looks like this (without the red): Under 8.3.3 BasicComponents::Connector::Associations, introduce: end: ConnectorEnd [2..*] See 9.3.6. Under 8.3.3 Description, insert the word "derived" before the phrase "connector kind attribute". Under 8.3.3 Connector Attributes, Package BasicComponents, replace: � kind : ConnectorKind Indicates the kind of connector. By: � /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(UML::CompositeStructures::Ports::Port) and e.partWithPort->isEmpty() and not e.role.oclAsType( UML::CompositeStructures::Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Introduce a new section 8.3.4 as follows: 8.3.4 ConnectorEnd (from BasicComponents) Generalizations o "ConnectorEnd (from Ports)" on page 176 (merge increment) Description See 9.3.7. Associations � role: ConnectableElement [1] See 9.3.7 � partWithPort: Property [0..1] See 9.3.7. Renumber the current 8.3.4 ConnectorKind as 8.3.5. Changes in Chapter 9 We make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, and make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. Do this in figure 9.2 by reorganizing the figure so that Classifier appears once only. Also in figure 9.2 and the model show a unidirectional association between InternalStructures::Classifier and Kernel::Feature, and make ownedConnector subset InternalStructures::Classifier::feature: (Note: This assumes that merging a navigable end with a non-navigable end results in a navigable end). Also in figure 9.2 and the model make InternalStructures::Classifier specialize Kernel::Namespace, to make the appearances of "subsets ownedMember" valid. Change figure 9.7 and the model so that Collaborations::Classifier only specializes Kernel::Namespace. Replace the first part of 9.3.2 (up to the Semantics section) with the following: 9.3.2 Classifier (from InternalStructures, Collaborations) Generalizations o "Namespace (from Kernel)" on page 99 Description Package Collaborations Classifier is extended with the capability to own collaboration uses. These collaboration uses link a collaboration with the classifier to give a description of the workings of the classifier. Associations Package InternalStructures o /attribute: Property [*] See 7.3.8. o / feature : Feature [*] See 7.3.8. Package Collaborations o collaborationUse: CollaborationUse References the collaboration uses owned by the classifier. (Subsets Element::ownedElement) o representation: CollaborationUse [0..1] References a collaboration use which indicates the collaboration that represents this classifier. (Subsets Classifier::collaborationUse) In section 9.3.13, Generalizations, change generalization from: o "Classifier (from Kernel, Dependencies, PowerTypes)" on page 52 to o Error! Reference source not found.
Actions taken:
July 27, 2009: received issue
April 26, 2010: closed issue

Discussion:

When the metamodel defines a package (the receiving package) that merges others (the merged packages), although the contents of the merged packages are included in the receiving package from a semantic point of view, they are not syntactically available in the receiving package, and so expressions such as OCL and subsetting constraints cannot be parsed in the receiving package.  In order to resolve this we introduce the convention that those classes and features of the merged packages required to enable constraint parsing in the receiving package should be copied into the metamodel of the receiving package, and documented in the text describing the receiving package, where descriptions for the copied classes and features are not copied, but consist simply of cross references such as "see 9.3.6".
This convention is introduced by changes to chapters 8 and 9 in the resolution to this issue.

Issue 14116: Propagate RTF 2.3 changes to Infrastructure (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Some of the resolutions that affected the superstructure doc in RTF 2.3 also have implications for Infrastructure. Please do the proper changes to Infrastrcture to keep the two documnets in sync"

Resolution: This is confirmed. All the relevant changes are proposed below.
Revised Text: Changes by issue 8601: In section 13.1.6, Constraints, change: [1] An element imported as a metaclassReference is not specialized or generalized in a Profile. self.metaclassReference.importedElement-> select(c | c.oclIsKindOf(Classifier) and (c.generalization.namespace = self or (c.specialization.namespace = self) )->isEmpty() [2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel. self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())-> union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty() To: [1] An element imported as a metaclassReference is not specialized or generalized in a Profile. self.metaclassReference.importedElement-> select(c | c.oclIsKindOf(Classifier) and (c.generalization.namespace = self) or (c.specialization.namespace = self) )->isEmpty() [2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel. self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()-> union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty() In the last sentence of the paragraph under figure 13.10, section 13.1.5, change: and need to be To and these constraints need to be Changes by issue 9706: In section 13.1.8, the Notation section, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. To: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation. Changes by issue 9830: At the end of the Semantics section in section 13.1.8, add the following paragraph: Stereotype specializes Class which may be merged with Class from InfrastructureLibrary in different usages of Core::Profiles. This adds a number of additional properties to class such as isAbstract and ownedAttributes needed to provide the properties of the stereotype. These properties have the same meaning in Stereotypes as they do in Class. Tool vendors may choose to support extensibility that includes owned operations and behaviors, but are not required to do so. Tools must however support Stereotype ownedAttributes. Changes by issue 9890: In section 13.1.2, change: Indicates whether an instance of the extending stereotype must be created when an instance of the extended class is created. The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd; a multiplicity of 1 means that isRequired is true, but otherwise it is false. Since the default multiplicity of an ExtensionEnd is 0..1, the default value of isRequired is false. To: Indicates whether an instance of the extending stereotype must be created when an instance of the extended class is created. The attribute value is derived from the value of the lower property of the ExtensionEnd referenced by Extension::ownedEnd; a lower value of 1 means that isRequired is true, but otherwise it is false. Since the default value of ExtensionEnd::lower is 0, the default value of isRequired is false. Changes by issue 9891: In the second paragraph of the description subsection in section 13.1.3, change: An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier. Since a profile is not allowed to change the referenced metamodel, it is not possible to add properties to the extended classifier. As a consequence, an ExtensionEnd can only be owned by an Extension. To: An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. Changes by issue 11343: In section 13.3.6, change the paragraph just before the first XMI example from: Figure 13.5 To: Figure 13.6. In the first XMI example in section 13.1.6, change: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id4 id5"> To: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> Changes by issue 11657: Change Figure 13.11 from: To: Change the second paragraph under figure 13.11 from: If the profile Manufacturer is later applied to a package, then the types from Types are also available for use in the package to which the profile is applied (since profile application is a kind of import). This means that for example the class JavaInteger can be used as both a metaproperty (as part of the stereotype Device) and an ordinary property (as part of the class TV). Note how the metaproperty is given a value when the stereotype Device is applied to the class TV. To: If the profile Manufacturer is later applied to a package, then the types from Types are not available for use in the package to which the profile is unless package Types is explicitly imported. This means that for example the class JavaInteger can be used as a metaproperty (as part of the stereotype Device) but not as an ordinary property (as part of the class TV) unless package Factory also imports package types. Note how the metaproperty is given a value when the stereotype Device is applied to the class TV. Change the last sentence of the first paragraph in the Semantics subsection of section 13.1.7 from: If a profile that is being applied depends on other profiles, then those profiles must be applied first. To: Applying a profile means recursively applying all its nested and imported. Stereotypes imported from another profile using ElementImport or PackageImport are added to the namespace members of the importing profile. Stereotypes that are public namespace members of a profile may be used to extend the applicable model elements in packages to which the profile has been applied. At the end of the Semantics subsection of section 13.1.7, just before the Note, add the following paragraphs: A nested profile can be applied individually. However, the nested profile must specify any required metaclass and/or metamodel references if it contains any stereotypes and may use PackageImport to indicate other dependent packages. Metaclass and/or metamodel references are not inherited from a containing profile. ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Changes by issue 12224: After the fourth paragraph under Figure 18.8, (before the paragraph starting with "Stereotypes can participant in associations.), add the following paragraph: A Profile can define Classes, DatatTypes, PrimitiveTypes and Enumerations as well as Stereotypes since Profiles imports Constructs. However, these types can only be used as the type of properties in the profile, they cannot be used as types in models the profile is applied to since they apply at the meta-model level, not the model level. It is however possible to define these types in separate packages and import them as needed in both profiles and models in order to use them for both purposes. Changes by issue 10826: In the Semantics subsection of section 13.1.8, change the first sentence of the second paragraph from: An instance "S" of Stereotype is a kind of (meta) class. To: An instance "S" of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. . Add the following paragraph to the end of the same Semantics subsection: A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names. Changes by issue 12587: In section 13.1.6, just before the subsection "Using XMI to exchange Profiles" add the following subsection (at the same heading level): Integrating and extending Profiles Integrating and extending existing profiles can result in improved reuse, better integration between OMG specifications, and less gaps and overlaps between metamodel extensions. There are a number of ways to create, extend and integrate profiles. These are described briefly in this section in order to foster better profile integration and reuse. The simplest form of profile integration is to simply apply multiple profiles to the same model. This requires no integration between the profiles at all. Such profiles might be designed to complement each other, addressing different concerns. It is also possible to one profile to reuse all of or parts of another, and to extend existing profiles. Like any other class, Stereotypes can be defined in packages or profiles that can be factored for reuse. These stereotypes can be directly reused through PackageImport or ElementImport in other profiles. Importing profiles can also use Generalizations to extend referenced and reused stereotypes for their unique purposes. However, referencing stereotypes in other packages and profiles can sometimes result in undue coupling. This is because the referenced stereotypes may be associated with other stereotypes resulting in the need for the referencing profile to include large, perhaps unpredictable parts of the referenced profile in order to maintain semantic consistency. This can lead to unexpected burden on profile implementers and users because more is reused than intended resulting in coupling complex profiles together so they cannot be easily reused separately. PackageMerge can be used to address this problem. A profile can define stereotypes that intentionally overlap with stereotypes in another profile. The profiles can be designed in such a way that they can stand alone. But they can also be merged together using PackageMerge to create a new profile that combines the capabilities of both. Vendors and users can then decide whether to apply one profile or the other, or the merged profile to get capabilities resulting from the combination of two or more profiles. For example, The UPDM profile could integrate with SysML to reuse stereotypes such as Requirement and ViewPoint. UPDM could be designed to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM could extend ViewPoint with additional properties and associations for its purposes. The UPDM specification could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling with, or need for SysML. UPDM could then provide another compliance point that merges with the SysML profile resulting in stereotypes Requirement and ViewPoint having the capabilities of both profiles. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Users who want UPDM with SysML would then apply this merged profile. Changes by issue 12833: Change figure 13.2 from: To: In Section 13.1.1 Class, under Generalization, replace o InfrastructureLibrary::Constructs::Class (merge increment) with o Classifier on page xxx In Section 13.1.2 Extension, under Generalization, replace o InfrastructureLibrary::Constructs::Association with o Association on page xxx In Section 13.1.3 ExtensionEnd, under Generalization, replace o InfrastructureLibrary::Constructs::Property with o Property on page xxx In Section 13.1.4 Image, under Generalization, refer to Element (from Constructs rather than from Basic) In Section 13.1.5 Package, under Generalization, replace o InfrastructureLibrary::Constructs::Package (merge increment) with o Namespace on page xxx In Section 13.1.6 Profile, under Generalization, replace o InfrastructureLibrary::Constructs::Package with o Package (from Profiles) on page xxx In Section 13.1.7 ProfileApplication, under Generalization, replace o InfrastructureLibrary::Constructs::Core::DirectedRelationship with o DirectedRelationship on page xxx In Section 13.1.7 Profile, under Generalization, replace o InfrastructureLibrary::Constructs::Class (merge increment) with o Class (from Profiles) on page xxx In Section 13.1.8 Stereotype, under Associations, add: o /profile : Profile [1] The profile that directly or indirectly contains this stereotype. In Section 13.1.6 Profile, remove Association: o /ownedStereotype: Stereotype [*] References the Stereotypes that are owned by the Profile. Subsets Package::packagedElement In Section 13.1.5 Package, add Association o /ownedStereotype: Stereotype [*] References the Stereotypes that are owned by the Package. Subsets Package::packagedElement Add the additional operations (before the Semantics part): Additional Operations [1] The query allApplicableStereotypes() returns all the directly or indirectly owned stereotypes, including stereotypes contained in sub-profiles. Package::allApplicableStereotypes(): Set(Stereotype) result = self.ownedStereotype->union(self.ownedMember-> select(oclIsKindOf(Package)).oclAsType(Package).allApplicableStereotypes()->flatten())->asSet() [2] The query containingProfile() returns the closest profile directly or indirectly containing this package (or this package itself, if it is a profile). Package::containingProfile():Profile result = if self.oclIsKindOf(Profile) then self.oclAsType(Profile) else self.namespace.oclAsType(Package).containingProfile() endif In Section 13.1.8, Stereotype, add the constraint: [3] A stereotype must be contained, directly or indirectly, in a profile. profile = self.containingProfile() Add the additional operation (before the Semantics part): Additional Operations [1] The query containingProfile returns the closest profile directly or indirectly containing this stereotype. Stereotype::containingProfile():Profile containingProfile = self.namespace.oclAsType(Package).containingProfile() Change the third paragraph of the Semantics part from: Any model element from the reference metamodel (any UML model element) can be extended by a stereotype. For example in UML, States, Transitions, Activities, Use cases, Components, Attributes, Dependencies, etc. can all be extended with stereotypes. To: Any metaclassReference or model element from the metamodelReference of the closest profile directly or indirectly containing a stereotype can be extended by the stereotype. For example in UML, States, Transitions, Activities, Use cases, Components, Attributes, Dependencies, etc. can all be extended with stereotypes if the metamodelReference is UML. A stereotype may be contained in a package in which case the metaclass and/or metamodel references available for extension are those of the closest parent profile containing the package. Changes by issue 6681: In clause 11.6.1 (DataType), under "Semantics", replace the second and third paragraphs, currently: All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Instances of a data type that has attributes (i.e., is a structured data type) are considered to be the same if the structure is the same and the values of the corresponding attributes are the same. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. With: All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be equal if the structure is the same and the values of the corresponding attributes are equal. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Changes by issue 12532: In 11.4.4 RedefinableElement.Description, replace the last sentence of the Description paragraph, currently: It adds a specialization from Constructs::NamedElement. with: It adds a specialization from Constructs::NamedElement and the capability for indicating whether it is possible to further redefine a RedefinableElement. In 11.4.4 RedefinableElement.Attributes, replace the paragraph, currently: No additional attributes with: isLeaf: Boolean Indicates whether it is possible to further redefine a RedefinableElement. If the value is true, then it is not possible to further redefine the RedefinableElement. Note that this property is preserved through package merge operations; that is, the capability to redefine a RedefinableElement (i.e., isLeaf=false) must be preserved in the resulting RedefinableElement of a package merge operation where a RedefinableElement with isLeaf=false is merged with a matching RedefinableElement with isLeaf=true: the resulting RedefinableElement will have isLeaf=false. Default value is false. In 11.4.4 RedefinableElement.Constraints, replace the paragraph, currently: No additional constraints with: [1] A redefinable element can only redefine non-leaf redefinable elements self.redefinedElement->forAll(not isLeaf) In 11.9.3 PackageMerge: Under "Property Rules"; CONSTRAINTS, remove: 4. Any redefinitions associated with matching properties must not be conflicting. Under "General package merge rules"; CONSTRAINTS, add: 8. Any redefinitions associated with matching redefinable elements must not be conflicting. Under "Property Rules"; TRANSFORMATIONS, remove: 6. For matching properties: different redefinitions of matching properties are combined conjunctively. Under "General package merge rules"; TRANSFORMATIONS, add: 11. For matching redefinable elements: different redefinitions of matching redefinable elements are combined conjunctively. 12. For matching redefinable elements: if both matching elements have isLeaf=true, the resulting element also has isLeaf=true; otherwise, the resulting element has isLeaf=false. Changes by issue 10515: In 11.4.1 Classifier.Description, replace the last sentence of the first paragraph, currently: It adds specializations from Constructs::Namespace and Constructs::Type. with: It adds specializations from Constructs::Namespace and Constructs::Type and the capability to specify that a classifier cannot be specialized by generalization. In 11.4.1 Classifier.Attributes, replace the paragraph, currently: No additional semantics with: o isFinalSpecialization: Boolean If true, the Classifier cannot be specialized by generalization. Note that this property is preserved through package merge operations; that is, the capability to specialize a Classifier (i.e., isFinalSpecialization =false) must be preserved in the resulting Classifier of a package merge operation where a Classifier with isFinalSpecialization =false is merged with a matching Classifier with isFinalSpecialization =true: the resulting Classifier will have isFinalSpecialization =false. Default is false. In 11.4.1 Classifier.Constraints, replace the paragraph, currently: No additional constraints with: [1] The parents of a classifier must be non-final. self.parents()->forAll(not isFinalSpecialization) In Figure 11.6, show 'isFinalSpecialization' in the Classifier box. In 11.9.3 PackageMerge, "General package merge rules", rename rules 7 to 10 as 8 to 11 and insert a new rule 7 for merging the 'isFinalSpecialization' attribute as shown below: 6. For all matching classifier elements: if both matching elements are abstract, the resulting element is abstract; otherwise, the resulting element is non-abstract. 7. For all matching classifier elements: if both matching elements are final specializations, the resulting element is a final specialization; otherwise, the resulting element is a non-final specialization. 8. For all matching elements: if both matching elements are not derived, the resulting element is also not derived; otherwise, the resulting element is derived. 9. For all matching multiplicity elements: the lower bound of the resulting multiplicity is the lesser of the lower bounds of the multiplicities of the matching elements. 10. For all matching multiplicity elements: the upper bound of the resulting multiplicity is the greater of the upper bounds of the multiplicities of the matching elements. 11. Any stereotypes applied to a model element in either a merged or receiving element are also applied to the corresponding resulting element. Changes by issue 9374: In 11.3.1, replace the text describing Association, currently: An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link. By: An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end. In 11.3.1, replace the first constraint of Association, currently: [1] An association specializing another association has the same number of ends as the other association. self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size()) By: [1] An association specializing another association has the same number of ends as the other association. parents()->select(oclIsKindOf(Association)).oclAsType(Association)-> forAll(p | p.memberEnd->size() = self.memberEnd->size()) In 11.3.1, replace the second constraint of Association, currently: [2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end. By: [2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end. Sequence{1..self.memberEnd->size()}-> forAll(i | self.general->select(oclIsKindOf(Association)).oclAsType(Association)-> forAll(ga |self.memberEnd->at(i).type.conformsTo(ga.memberEnd->at(i).type))) In 11.3.1 Association.Semantics, replace paragraphs 4 to 8, currently: A navigable end of an association means that it is intended to be traversed at runtime from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. This is independent of ownership of the end. Associations can have navigable ends regardless of how many ends they have. Implementations can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object. Traversal of an n-ary association towards a navigable end requires that objects first be identified for the remaining n-1 ends. The result of traversal is a collection of objects for the navigable end derived from links in which the other n-1 objects participate. For binary associations n=2, in which case traversal proceeds from one object at the other end to a collection of objects at the navigable end. The multiplicity of the association end constrains the size of this collection. If the end is marked as ordered, this collection will be ordered. If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements. An end of one association may be marked as a subset of an end of another in circumstances where (a) both have the same number of ends, and (b) each of the set of types connected by the subsetting association conforms to a corresponding type connected by the subsetted association. In this case, given a set of specific instances for the other ends of both associations, the collection denoted by the subsetting end is fully included in the collection denoted by the subsetted end. An end of one association may be marked to show it redefines an end of another in circumstances where (a) both have the same number of ends, and (b) each of the set of types connected by the redefining association conforms to a corresponding type connected by the redefined association. In this case, given a set of specific instances for the other ends of both associations, the collections denoted by the redefining and redefined ends are the same. Associations may be specialized. The existence of a link of a specializing association implies the existence of a link relating the same set of instances in a specialized association. With the following paragraph from UML 2.2 superstructure, currently: For an association with N ends, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the association end constrains the size of this collection. If the end is marked as ordered, this collection will be ordered. If the end is marked as unique, this collection is a set; otherwise, it allows duplicate elements. In 11.3.1 Association.Semantics, before the fourth paragraph from the last, currently: For n-ary associations, the lower multiplicity of an end is typically 0. A lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends. insert the following paragraph: The combination of constraints [1,2] above with the semantics of property subsetting and redefinition specified in 11.3.5 in constraints [3,4,5] imply that any association end that subsets or redefines another association end forces the association of the subsetting or redefining association end to be a specialization of the association of the subsetted or redefined association end respectively. In 11.3.1, remove the last semantic variation point in Association, currently: The interaction of association specialization with association end redefinition and subsetting is not defined. Changes by issue 10081: In the UML 2.2 Infrastructure Specification (formal/09-02-04), in Figure 9.20, in the class box for OpaqueExpression, after "body: String [*]", add "{nonunique, ordered} and after "language: String [*]", add "{ordered}". In Figure 11.4, in the class box for OpaqueExpression, after "body: String", add "[*] {nonunique, ordered}" and after "language: String" add "[*] {ordered}". In Subclause 9.8.2, OpaqueExpression, under Attributes, change "body: String [0..*] {ordered}", to "body: String [0..*] {nonunique, ordered}".
Actions taken:
July 27, 2009: received issue
April 26, 2010: closed issue

Discussion:

Issue 14123: Remove redundantant constraint [2] in 7.3.4 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Actually, reading 7.3.8 Classifier [8], I realize that the constraint in the resolution 9374 is superfluous since [8] already prevents a Class from specializing an AssociationClass or an Association from specializing an AssociationClass.

So, the options are:

1) leave the constraint editorially fixed as we did and file an issue to remove it at the next RTF
2) cancel the editorial fix and editorially remove the (superfluous) constraint from 9374

Either way is fine with me but I think that option (2) is better than (1)."

Resolution:
Revised Text: In section 7.3.4, constraints, remove constraint [2] which reads: [2] In a generalization hierarchy, the specializations of an AssociationClass must be a kind of AssociationClass. In particular, it is not allowed for a Class or an Association to specialize an AssociationClass. The following constraint navigates from the non-navigable end of the A_general_classifier association for the AssociationClass (self) to retrieve its specialized classifiers (A_general_classifier::classifier). self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass))
Actions taken:
July 28, 2009: received issue
April 26, 2010: closed issue

Discussion:

This constraint is indeed covered by constaint [3] in 7.3.8 Classifier, so it is redundant.

Issue 14135: Difference between OCL and text in constraint [2] of 15.3.15 (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Constraint [2] in 15.3.15 says:

[2] A transition with kind external can source any vertex except entry points.
context Transition inv: 
source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local)

- Is the text and OCL saying that same thing? I think the text is saying "A implies not B", while the OCL is saying "B implies C", where:

A : kind = TransitionKind::external
B : source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint
C: kind = TransitionKind::local (this is not the oppsite of "A" as there is a third kind of transition "internal")

Resolution: This constraint should be fixed to match the text.
Revised Text: In 15.3.15, constraints, change the OCL of constraint [2] to : context Transition inv: (kind = TransitionKind::external) implies not (source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint)
Actions taken:
July 28, 2009: received issue
April 26, 2010: closed issue

Discussion:

Issue 14228: Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith' (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Salman Qadri, Salman.Qadri(at)mathworks.com)
Nature: Uncategorized Issue
Severity:
Summary:

The body of the �Core-Constructs-Operation-isConsistentWith� Operation in Infrastructure.xmi uses an attribute called �formalParameter�, which does not exist in the metamodel:

 

result = (redefinee.oclIsKindOf(Operation) and&#xA;    let op: Operation = redefinee.oclAsType(Operation) in&#xA;        self.formalParameter.size() = op.formalParameter.size() and&#xA;        self.returnResult.size() = op.returnResult.size() and&#xA;        forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and&#xA;        forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))&#xA;)

 

We should instead borrow the body from Superstructure.xmi which does not have that problem:

 

result = (redefinee.oclIsKindOf(Operation) and&#xA;let op: Operation = redefinee.oclAsType(Operation) in&#xA;self.ownedParameter.size() = op.ownedParameter.size() and&#xA;forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type))&#xA;)

Resolution: Resolve discrepancies for RedefinableElement amongst the following artifacts: - Infrastructure document (clause 11.4.4) - Superstructure document (clause 7.3.46) - Infrastructure XMI: Core::Constructs::RedefinableElement - Superstructure XMI: Classes::Kernel::RedefinableElement Resolve discrepancies for Operation::isConsistentWith amongst the following artifacts: - Infrastructure document (clauses 11.3.4 & 11.8.2) - Superstructure document (clause 7.3.36) - Infrastructure XMI: Core::Constructs::Operation - Superstructure XMI: Classes::Kernel::Operation
Revised Text: a) RedefinableElement In the Infrastructure specification document, replace the Constraint paragraph in 11.4.4, currently: [1] A redefinable element can only redefine non-leaf redefinable elements self.redefinedElement->forAll(not isLeaf) By the following constraints copied from the superstructure document in 7.3.46: [1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the redefinition contexts for each redefined element. self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e)) [2] A redefining element must be consistent with each redefined element. self.redefinedElement->forAll(re | re.isConsistentWith(self) [3] A redefinable element can only redefine non-leaf redefinable elements self.redefinedElement->forAll(not isLeaf) In the Infrastructure specification document, before the 'Semantics' paragraph in 11.4.4 RedefinableElement, insert the following 'Additional Operations' paragraph: [1] The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is possible, whether redefinition would be logically consistent. By default, this is false; this operation must be overridden for subclasses of RedefinableElement to define the consistency conditions. RedefinableElement::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = false [2] The query isRedefinitionContextValid() specifies whether the redefinition contexts of this RedefinableElement are properly related to the redefinition contexts of the specified RedefinableElement to allow this element to redefine the other. By default at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element. RedefinableElement::isRedefinitionContextValid(redefined: RedefinableElement): Boolean; result = self.redefinitionContext->exists(c | c.allParents()->includesAll(redefined.redefinitionContext)) In the Infrastructure XMI, add an unnamed constraint to InfrastructureLibrary::Core::Constructs::RedefinableElement::isConsistentWith according to the precondition for RedefinableElement::isConsistentWith above with the following body: redefinee.isRedefinitionContextValid(self) In the Infrastructure XMI, replace the body of the constraint InfrastructureLibrary::Core::Constructs::RedefinableElement::isRedefinitionContextValid::spec, currently: result = self.redefinitionContext->exists(c | redefined.redefinitionContext->exists(r | c.allParents()->includes(r))) with: result = self.redefinitionContext->exists(c | c.allParents()->includesAll(redefined.redefinitionContext)) b) Operation::isConsistentWith In the Infrastructure specification document, replace the description and OCL specification of the operation 'isConsistentWith' in clause 11.8.2 under 'Additional Operations', currently: [1] The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from 'isConsistentWith()', as for example, users may define a query named 'isContravariantWith()'. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type)) ) By the following description copied from the superstructure document & the corrected OCL specification: [1] The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op : Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(i).type)) In the infrastructure XMI, replace the body of the constraint InfrastructureLibrary::Core::Constructs::Operation::isConsistentWith::spec, currently: result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.formalParameter.size() = op.formalParameter.size() and self.returnResult.size() = op.returnResult.size() and forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type)) ) By: result = redefinee.oclIsKindOf(Operation) and let op : Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(i).type)) In the superstructure document, replace the OCL specification of the operation 'isConsistentWith' in clause 7.3.36 under 'Additional Operations', currently: Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) isConsistentWith = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type)) ) By: Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op : Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(i).type)) In the superstructure XMI, replace the body of the constraint UML::Classes::Kernel::Operation::isConsistentWith::spec, currently: result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type)) ) By: result = redefinee.oclIsKindOf(Operation) and let op : Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(i).type))
Actions taken:
August 27, 2009: received issue
April 26, 2010: closed issue

Issue 14235: Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Salman Qadri, Salman.Qadri(at)mathworks.com)
Nature: Uncategorized Issue
Severity:
Summary:

In Superstructure.xmi (2.3):

 

Classes-Interfaces-Interface-ownedAttribute has a one-directional association to Classes-Kernel-Property and subsets Classes-Kernel-Namespace-ownedMember. Adding an instance of a merged Property to Interface-ownedAttribute would fail to populate the �owner� or �namespace� attributes of the Property (because the only slots are �class� and �datatype�).

 

This is inconsistent in 2 ways:

1)      The merged Property has the slots �class� and �datatype�, but there is no slot for �interface�.

2)      Compare this to a merged Operation, which has �class�, �datatype� as well as �interface� (from Classes-Interfaces-Operation-interface). Also, Classes-Interfaces-Interface-ownedOperation has a bidirectional association with Classes-Interfaces-Operation-interface, which also feels at odds with Classes-Interfaces-Interface-ownedAttribute.

3)      Since Classes-Interfaces-Interface-ownedAttribute explicitly subsets �Classes-Kernel-Namespace-ownedMember�, we would expect that the association to �Classes-Kernel-NamedElement-namespace� should produce a result. However since �namespace� is a derived-union with no slots that accept an �Interface�, this remains empty (and consequently so does �owner� even though the Property IS being owned by an Interface).

 

I would like to suggest the following:

1)      Add a cmof:Class �Classes-Interfaces-Property� to the package �Classes-Interfaces� as an �ownedMember� and change the �type� of �Classes-Interfaces-Interface-ownedAttribute� to �Classes-Interfaces-Property�.

2)      Add a cmof:Property �Classes-Interfaces-Property-interface� as an �ownedAttribute� of �Classes-Interfaces-Property�. This attribute should be 0..1 with the type �Classes-Interfaces-Interface� and should subset �Classes-Kernel-RedefinableElement�, �Classes-Kernel-Feature-featuringClassifier� and �Classes-Kernel-NamedElement-namespace�. Its� association should be �Classes-Interfaces-A_interface_ownedAttribute�.

3)      Modify �Classes-Interfaces-A_interface_ownedAttribute� to have the member ends be �Classes-Interfaces-Property-interface� and �Classes-Interfaces-Interface-ownedAttribute�.

Resolution: This inconsistency issue is substantiated as explained; the suggestion amounts to repairing Classes::Interfaces as a package merge extension of Classes::Kernel. In fact, the "copy-down" suggested in item (2) is implicitly shown in the fact that 'Property' like all of the other metaclasses defined in the Classes::Interfaces package are unqualified whereas the other metaclasses defined but not copied in this package are fully qualified.
Revised Text: In Figure 7.16 of the Superstructure specification, do the following changes: 1- Add class Intefacess::Property that subclasses Kernel::StructuralFeature 2- Redirect the 'ownedAttribute' association from currently Kernel::Property to Interfaces::Property 3- Delete Kernel::Property from diagram 4- Make the 'interface' end of the association navigable and show the end label. In clause 7.3.44 (Property) in the Superstructure specification: Change the clause heading from 7.3.44 Property (from Kernel, AssociationClasses) to: 7.3.44 Property (from Kernel, AssociationClasses, Interfaces) Under Associations, add the following to the bottom of the list: Package Interfaces o interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace and Feature::featuringClassifier Edit the following association currently: o datatype : DataType [0..1] The DataType that owns this Property. Subsets NamedElement::namespace, Feature::featuringClassifier, and Property::classifier. To o datatype : DataType [0..1] The DataType that owns this Property. Subsets NamedElement::namespace, Feature::featuringClassifier. And this association currently: o class : Class [0..1] References the Class that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier to o class : Class [0..1] References the Class that owns the Property. Subsets NamedElement::namespace and Feature::featuringClassifier In clause 6.4.1, change bullet 8 in the conventions currently The "Associations" sub clause lists all the association ends owned by the concept. The format for these is the same as the one for attributes described above. Association ends that are specializations or redefinitions of other association ends in superclasses are flagged appropriately. For example: olowerValue: ValueSpecification[0..1] {subsets Element::ownedElement} The specification of the lower bound for this multiplicity. To The "Associations" sub clause lists all the association ends owned by the concept. Note that this sub clause does not list the association-owned association ends. The format for concept-owned association ends is the same as the one for attributes described above. Association ends that are subsets or redefinitions of other association ends owned by super type concepts are appropriately noted in the text. Note that this association end notation specifically excludes the notation for the subsetting or redefinition of association-owned association ends. For example: olowerValue: ValueSpecification[0..1] {subsets Element::ownedElement} The specification of the lower bound for this multiplicity.
Actions taken:
August 28, 2009: received issue
April 26, 2010: closed issue

Discussion:

Issue 14258: Japan Superstructure PAS Ballot Comments - comment 1 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Japan will approve this DIS if the TH comments will accept.

Resolution: The TH comments (OMG Issues 14271 - JP14, 14274 - JP17) were accepted in the approved resolutions for UML 2.3. See resolutions to OMG Issues 14271 and 14274 Revised Text: Disposition: Duplicate of 14271 and 14274
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14259: Japan Superstructure PAS Ballot Comments - comment 2 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

ISO standard documents are described with "shall", "should" and "may".	

Define this standard with "shall", "should" and "may".

Resolution: specification uses RFC 2119 Terminology
Revised Text: Replace the current section 5 in the superstructure with the following new section: "5 Notational Conventions The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may" in this specification are to be interpreted as described in RFC 2119." Add the following reference to the normative references - section 3 (superstructure): "RFC2119, http://ietf.org/rfc/rfc2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997."
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14260: Japan Superstructure PAS Ballot Comments - comment 3 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The format of normative references doesn't meet ISO format.
	
Write reference like as follow if you refer OMG's documents
IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

Resolution: add references with full text.
Revised Text: In superstructure, replace the list of references by the following list: - ISO/IEC 19505-1 , Information technology - OMG Unified Modeling Language (OMG UML) Version 2.1.2 - Part 1: Infrastructure - OMG Specification formal/2009-07-11, UML Infrastructure, v2.3 - OMG Specification ptc/09-05-02, Object Constraint Language, v2.1 - OMG Specification formal/06-01-01, Meta Object Facility (MOF) Core, v2.0 - OMG Specification formal/07-12-01, Meta Object Facility(MOF) 2.0 XMI Mapping Specification, v2.1.1 - OMG Specification formal/06-04-04 , UML 2.0 Diagram Interchange
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14261: Japan Superstructure PAS Ballot Comments - comment 4 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

JP4	3		GE	The following standard must be refer.
- XMI ISO/IEC19503
- MOF ISO/IEC19502
- OCL 2.0	ISO/IEC 19502:2005  Information technology -- Meta Object Facility (MOF)
ISO/IEC 19503:2005  Information technology -- XML Metadata Interchange (XMI)
OCL 2, OMG, available at
<http://www.omg.org/spec/OCL/2.0/PDF>

Resolution: Issue 14260 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.
Revised Text: Add the following note to end of section 3 of superstructure: "Note: UML 2 is based on a different generation of MOF and XMI than that specified in ISO/IEC 19502:2005 Information technology -- Meta Object Facility (MOF) ISO/IEC 19503:2005 Information technology -- XML Metadata Interchange (XMI) which are compatible with ISO/IEC 19501 UML version 1.4.1."
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14262: Japan Superstructure PAS Ballot Comments - comment 5 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

JP5	4,5		GE	There is no terms, definitions and symbols.
	
Remove the clause "4 Terms and definitions" and "5 Symbols".

Resolution: Leave section 4 for future revisions to add terms and definitions. Issue 14259 replaces section 5 with a new Notational Conventions section. see Issue 14259 (JP 2) resolution. Revised Text: Disposition: Duplicate of 14259
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14265: Japan Superstructure PAS Ballot Comments - comment 8 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

GT	Distinction between normative and informative part is unclear.	

Make distinction between normative and informative part.

Resolution: Ensure that all annexes are labled as "normative" or "informative" All statements in the body of the spec (unless explicitly stated as informative) are considered as normative. The formal semantics of use of term "may" from resolution to Issue 14259 (jp 2) clarifies its use as in normative statements. Eg: In Section "Notation" in 7.3.3 Association" the sentence: "Users may conceptualize the dot as showing that the model includes a property of the type represented by the classifier touched by the dot." is a normative statement.
Revised Text: add the centered line (informative) Immediately after title to annex D
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14266: Japan Superstructure PAS Ballot Comments - comment 9 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

GE	All the heading should be numbered as subclauses or itemized as lists. 	

Follow Directives part2 5.2.

Resolution: There are a large number of Bold headings in the document, which are not numbered. Many OMG specs do this, and it was used in ISO/IEC 19501. Changing the spec at this time to give each one of these Bold headers their own subsection number. e.g., sec 7.3.3 has sub headings "Generalization" , "Description" etc., is too large too large an undertaking to incorporate into version 2.3 of UML. Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:

Issue 14267: Japan Superstructure PAS Ballot Comments - comment 10 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

TL	It is unclear whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.	

State clearly whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

Resolution: RTF does not see why Japan thinks the names might be anything but normative - they are in Annex A clearly marked as Normative. Resolution to Issue 14265 (JP 8) results in all annexes being labeled as normative or informative. Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
September 2, 2009: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Issue 14268: Japan Superstructure PAS Ballot Comments - comment 11 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

12.4, 		E	There is no subheading representing a particular diagram.	

Add subheading "Activity Diagram".

Resolution: Since the section 12 is titled Activities, it serves as the context for sub-section 12.4 Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14269: Japan Superstructure PAS Ballot Comments - comment 12 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

15.4		E	There is no subheading representing a particular diagram.	

Add subheading "State Machine Diagram"

Resolution: Since the section 15 is titled "State Machines", it serves as the context for sub-section 15.4. Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14270: Japan Superstructure PAS Ballot Comments - comment 13 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

16.4		E	There is no subheading representing a particular diagram.	

Add subheading "Use Case Diagram".

Resolution: Since the section 16 is titled "Use Cases", it serves as the context for sub-section 16.4 Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14271: Japan Superstructure PAS Ballot Comments - comment 14 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

17.3.1	1st paragrap, Semantics section. (There are several "physical" in the section)	TH	According to the standard, "Model" is restricted to "physical system". However, It is required to apply to conceptual/logical system. 	

Remove "physical". Otherwise, add "conceptual/logical" before "system".

Resolution: agreed to remove prefix "physical" before "system" in Section 17.3.1, para 1
Revised Text: Change "physical system" to "system" everywhere the two words are used together in the superstructure.
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14272: Japan Superstructure PAS Ballot Comments - comment 15 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Fig. 13.15, 13.17, 14.12, 14.16~31, �, 16.10	E	The annotations with red characters and a red arrow which outside the framework are not parts of example.  They are class names and/or their attributes. Also, the arrow symbol is  same as UML notation.  Thus,  those annotations lead misunderstand.	
*Add annotation convention to somewhere.
* Unify the arrow symbol, someone are white hatching, others are red hatching.

Resolution: Suggest adding description of red annotations to section 5, Notational Conventions.
Revised Text: In the new Section 5: Notational Conventions (from issue resolution to 14259): Place the following subsection before the text regarding RFC 2119: "5.1 Keywords for Requirement statements" Add the following new subsection "5.2 Annotations on Example Diagrams Some of the diagram examples in this specification include explanatory annotations, which should not be confused as being part of the formal UML graphical notation. In these cases, the explanatory text originates outside the UML diagram boundary, and has an arrow pointing at the feature of the diagram which is being explained by the annotation. The color rendition of this spec shows these annotations in red."
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14273: Japan Superstructure PAS Ballot Comments - comment 16 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Table 16.1	E	Many people may misunderstand the annotations inside table 16.1 are notations of graphical nodes.	Remove annotations inside table 16.1.

Resolution: Resolution: add explanation of annotations. Revised Text: See Issue 14272 revision, which adds explanation of graphical annotations. Disposition: Duplicate of 14272
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14274: Japan Superstructure PAS Ballot Comments - comment 17 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex I		TH	This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.	Remove Annex I or make it informative Annex.

Resolution: agreed, Annex I is no longer in UML 2.3 Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14275: Japan Superstructure PAS Ballot Comments - comment 18 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex J		GE	This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as only OMG document but not ISO standard.
	Remove Annex J.

Resolution: Resolution: Agree, this annex is no longer in UML 2.3 Revised Text: Annex J already removed in UML 2.3. Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14276: Japan Superstructure PAS Ballot Comments - comment 19 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex K		GE	Acknowledgements are not normative specification. . Leave them as only OMG document but not ISO standard.	Remove Annex K.

Resolution: Acknowledgements are now in Section 6.5. Needs to be removed from ISO spec. remove section 6.5 from ISO spec and OMG spec for consistency.
Revised Text: Remove section 6.5
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14277: Japan Superstructure PAS Ballot Comments - comment 20 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Part I, II, III,, IV	GE	This is a multipart standard, use of  "Part I, II, III, IV" make confusion. Delete unnecessary Part IV and Make others rewrite as clauses.	7. Structure, 12 Behavior, 19 Supplement and renumber other clauses.

Resolution: Agree to change word "Part" to "Sub Part" throughout document.
Revised Text: Change : "Part I" to "Subpart I" "Part II" to "Subpart II" "Part III" to "Subpart III" in section 6.4, and in the existing three Part I, Part II, and Part III headers of the document
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14278: Japan Infrastructure PAS Ballot Comments - comment 1 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Japan will approve this DIS if the TH comment will accept.

Resolution: Revised Text: See resolution to OMG Issues 14283 Disposition: Duplicate of 14283
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14279: Japan Infrastructure PAS Ballot Comments - comment 2 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

GE	ISO standard documents are described with "shall", "should" and "may".	

Define this standard with "shall", "should" and "may".

Resolution: specification uses RFC 2119 Terminology
Revised Text: Replace the current section 5 with the following new section: "5 Notational Conventions The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may" in this specification are to be interpreted as described in RFC 2119." Add the following reference in the normative references - section 3: - RFC2119, http://ietf.org/rfc/rfc2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997.
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14280: Japan Infrastructure PAS Ballot Comments - comment 3 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

GE	The format of normative references doesn't meet ISO format.
	
Write reference like as follow if you refer OMG's documents
IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

Resolution: add references with full text.
Revised Text: In Infrastructure, replace the list of references by the following list: - ISO/IEC 19505-2 , Information technology - OMG Unified Modeling Language (OMG UML) Version 2.1.2 - Part 2: Superstructure - OMG Specification ptc/09-05-02, Object Constraint Language, v2.1 - OMG Specification formal/06-01-01, Meta Object Facility (MOF) Core, v2.0 - OMG Specification formal/07-12-01, Meta Object Facility(MOF) 2.0 XMI Mapping Specification, v2.1.1 - OMG Specification formal/06-04-04 , UML 2.0 Diagram Interchange
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14281: Japan Infrastructure PAS Ballot Comments - comment 4 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

GE	The following standard must be refer.
- XMI ISO/IEC19503
- MOF ISO/IEC19502	ISO/IEC 19502:2005  Information technology -- Meta Object Facility (MOF)
ISO/IEC 19503:2005  Information technology -- XML Metadata Interchange (XMI)

Resolution: Issue 14280 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.
Revised Text: Add note to the end of normative references - section 3: "Note: UML 2 is based on a different generation of MOF and XMI than that specified in ISO/IEC 19502:2005 Information technology -- Meta Object Facility (MOF) ISO/IEC 19503:2005 Information technology -- XML Metadata Interchange (XMI) which are compatible with ISO/IEC 19501 UML version 1.4.1."
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14282: Japan Infrastructure PAS Ballot Comments - comment 5 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

4,5		GE	There is no terms ,definitions and symbols.
	
Remove the clause "4 Terms and definitions" and "5 Symbols".

Resolution: Resolution: Leave section 4 for future revisions to add terms and definitions. Issue 14279 replaces section 5 with a new Notational Conventions section. see Issue 14279 (JP 2) resolution. Revised Text: Disposition: Duplicate of 14279
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14284: Japan Infrastructure PAS Ballot Comments - comment 7 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex D		GE	This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG only document.
	
Remove Annex D from ISO standard.

Resolution: Resolution: Agree, this annex is no longer in UML 2.3. Revised Text: Disposition: Closed, No Change
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14285: Japan Infrastructure PAS Ballot Comments - comment 8 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex E		GE	Acknowledgements are not normative specification. 

Leave them as OMG only document.	Remove Annex E from ISO standard.

Resolution: Acknowledgements are now in Section 6.3. However agree should be removed from ISO spec.
Revised Text: Remove section 6.3
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14286: Japan Infrastructure PAS Ballot Comments - comment 9 (uml2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Part I, II, III	GE	This is a multipart standard, use of  "Part I, II, III" make confusion. Delete Part III and Make others rewrite as clauses.	7. General Introduction, 10 Infrastructure Library, and renumber other clauses. Also, delete Part III page.

Resolution: Agree to change word "Part" to "Sub Part" throughout document.
Revised Text: Change : "Part I" to "Subpart I" "Part II" to "Subpart II" "Part III" to "Subpart III" in section 6.2, and in the existing three Part I, Part II, and Part III headers of the document
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14287: Duplicate association in normative UML 2.3 superstructure file (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

What state is UML 2.3 in with respect to filing issues? 

In particular, there is a duplicate association name in the Superstructure Library normative XMI file for UML 2.3 that was detected by my CMOF Import:

Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.
Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.

I checked the XMI file and, yes, the association is duplicated

Resolution: This issue is covered by the resolution to 13330 Revised Text: Disposition: Duplicate of 13330
Revised Text:
Actions taken:
September 2, 2009: received issue
April 26, 2010: closed issue

Issue 14355: Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2 (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Salman Qadri, Salman.Qadri(at)mathworks.com)
Nature: Uncategorized Issue
Severity:
Summary:

The MOF 2.0 Specification section 12.4 states that "Names are required for all Types and Properties". We should ensure that all Properties in the UML xmi files have names, preferably the same as the ones that were already there in UML 2.1.1 (this is a regression). An example is:


" Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.xmi (2.3) and " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.cmof (2.2) have no names. But " Classes-Interfaces-A_interface_ownedAttribute-interface" in Superstructure.cmof (2.1.1) has names.

Resolution: The UML 2.1.1 XMI files are fully compliant with the quoted constraint that "Names are required for all Types and Properties". The UML 2.3 XMI files; however, no longer have names for several association end properties (298 in the in Superstructure.xmi; 55 in the Infrastructure.xmi). Most of these association end properties are in fact owned ends of their respective associations. These ownedEnds are MOF Properties that had names in UML 2.1.1. We consider this to be a regression, and we are to repair all such ownedEnds by restauring their name according to the naming convention specified in clause 6.4.2 that was used to name the corresponding association. In addition, we will ensure that there are no other Types or Properties that have no name. In Superstructure.xmi (2.3), there are 5 Associations which also must be given names. This is an XMI-only change. The OCL query used to find associations with unnamed association ends using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following: let As : Collection(Association) = self.allOwnedElements() ->select(oclIsKindOf(Association)).oclAsType(Association) in As->select(a|a.member->exists(name->isEmpty())) ->sortedBy(qualifiedName).qualifiedName The OCL query used to report unnamed associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following: let As : Collection(Association) = self.allOwnedElements() ->select(oclIsKindOf(Association)).oclAsType(Association) in As->select(a|a.name->isEmpty())->collect(a|Tuple{ pkg=a.namespace.qualifiedName, end1_type=a.member->asSequence()->at(1).oclAsType(Property).type.name, end1_name=a.member->asSequence()->at(1).oclAsType(Property).name, end2_type=a.member->asSequence()->at(2).oclAsType(Property).type.name, end2_name=a.member->asSequence()->at(2).oclAsType(Property).name}) The OCL query used to verify that all occurrences of unnamed association ends are in fact owned ends of their associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following: let As : Collection(Association) = self.allOwnedElements()->select(oclIsKindOf(Association)).oclAsType(Association) in As->select(a|a.member->exists(name->isEmpty())) ->forAll(a|a.member->one(m|m.name->isEmpty() and m.oclAsType(Property).association->notEmpty()))
Revised Text: a) The following 298 associations in the Superstructure.xmi (2.3) have at least one unnamed association end property which must be given proper names according to the convention for naming associations in 6.4.2; the IDs of these associations & their association ends must be regenerated. 1.) UML::Actions::BasicActions::A_action_input 2.) UML::Actions::BasicActions::A_action_output 3.) UML::Actions::BasicActions::A_argument_invocationAction 4.) UML::Actions::BasicActions::A_behavior_callBehaviorAction 5.) UML::Actions::BasicActions::A_context_action 6.) UML::Actions::BasicActions::A_inputValue_opaqueAction 7.) UML::Actions::BasicActions::A_operation_callOperationAction 8.) UML::Actions::BasicActions::A_outputValue_opaqueAction 9.) UML::Actions::BasicActions::A_result_callAction 10.) UML::Actions::BasicActions::A_signal_sendSignalAction 11.) UML::Actions::BasicActions::A_target_callOperationAction 12.) UML::Actions::BasicActions::A_target_sendSignalAction 13.) UML::Actions::BasicActions::A_value_valuePin 14.) UML::Actions::CompleteActions::A_classifier_readExtentAction 15.) UML::Actions::CompleteActions::A_classifier_readIsClassifiedObjectAction 16.) UML::Actions::CompleteActions::A_collection_reduceAction 17.) UML::Actions::CompleteActions::A_end_readLinkObjectEndAction 18.) UML::Actions::CompleteActions::A_newClassifier_reclassifyObjectAction 19.) UML::Actions::CompleteActions::A_object_readIsClassifiedObjectAction 20.) UML::Actions::CompleteActions::A_object_readLinkObjectEndAction 21.) UML::Actions::CompleteActions::A_object_readLinkObjectEndQualifierAction 22.) UML::Actions::CompleteActions::A_object_startClassifierBehaviorAction 23.) UML::Actions::CompleteActions::A_object_startObjectBehaviorAction 24.) UML::Actions::CompleteActions::A_object_unmarshallAction 25.) UML::Actions::CompleteActions::A_oldClassifier_reclassifyObjectAction 26.) UML::Actions::CompleteActions::A_qualifier_linkEndData 27.) UML::Actions::CompleteActions::A_qualifier_qualifierValue 28.) UML::Actions::CompleteActions::A_qualifier_readLinkObjectEndQualifierAction 29.) UML::Actions::CompleteActions::A_reclassifyObjectAction_object 30.) UML::Actions::CompleteActions::A_reducer_reduceAction 31.) UML::Actions::CompleteActions::A_replyToCall_replyAction 32.) UML::Actions::CompleteActions::A_replyValue_replyAction 33.) UML::Actions::CompleteActions::A_result_acceptEventAction 34.) UML::Actions::CompleteActions::A_result_createLinkObjectAction 35.) UML::Actions::CompleteActions::A_result_readExtentAction 36.) UML::Actions::CompleteActions::A_result_readIsClassifiedObjectAction 37.) UML::Actions::CompleteActions::A_result_readLinkObjectEndAction 38.) UML::Actions::CompleteActions::A_result_readLinkObjectEndQualifierAction 39.) UML::Actions::CompleteActions::A_result_reduceAction 40.) UML::Actions::CompleteActions::A_result_unmarshallAction 41.) UML::Actions::CompleteActions::A_returnInformation_acceptCallAction 42.) UML::Actions::CompleteActions::A_returnInformation_replyAction 43.) UML::Actions::CompleteActions::A_trigger_acceptEventAction 44.) UML::Actions::CompleteActions::A_unmarshallType_unmarshallAction 45.) UML::Actions::CompleteActions::A_value_qualifierValue 46.) UML::Actions::IntermediateActions::A_association_clearAssociationAction 47.) UML::Actions::IntermediateActions::A_classifier_createObjectAction 48.) UML::Actions::IntermediateActions::A_destroyAt_linkEndDestructionData 49.) UML::Actions::IntermediateActions::A_endData_createLinkAction 50.) UML::Actions::IntermediateActions::A_endData_destroyLinkAction 51.) UML::Actions::IntermediateActions::A_endData_linkAction 52.) UML::Actions::IntermediateActions::A_end_linkEndData 53.) UML::Actions::IntermediateActions::A_first_testIdentityAction 54.) UML::Actions::IntermediateActions::A_inputValue_linkAction 55.) UML::Actions::IntermediateActions::A_insertAt_addStructuralFeatureValueAction 56.) UML::Actions::IntermediateActions::A_insertAt_linkEndCreationData 57.) UML::Actions::IntermediateActions::A_object_clearAssociationAction 58.) UML::Actions::IntermediateActions::A_object_structuralFeatureAction 59.) UML::Actions::IntermediateActions::A_removeAt_removeStructuralFeatureValueAction 60.) UML::Actions::IntermediateActions::A_request_sendObjectAction 61.) UML::Actions::IntermediateActions::A_result_clearStructuralFeatureAction 62.) UML::Actions::IntermediateActions::A_result_createObjectAction 63.) UML::Actions::IntermediateActions::A_result_readLinkAction 64.) UML::Actions::IntermediateActions::A_result_readSelfAction 65.) UML::Actions::IntermediateActions::A_result_readStructuralFeatureAction 66.) UML::Actions::IntermediateActions::A_result_testIdentityAction 67.) UML::Actions::IntermediateActions::A_result_valueSpecificationAction 68.) UML::Actions::IntermediateActions::A_result_writeStructuralFeatureAction 69.) UML::Actions::IntermediateActions::A_second_testIdentityAction 70.) UML::Actions::IntermediateActions::A_signal_broadcastSignalAction 71.) UML::Actions::IntermediateActions::A_structuralFeatureAction_structuralFeature 72.) UML::Actions::IntermediateActions::A_target_destroyObjectAction 73.) UML::Actions::IntermediateActions::A_target_sendObjectAction 74.) UML::Actions::IntermediateActions::A_value_linkEndData 75.) UML::Actions::IntermediateActions::A_value_valueSpecificationAction 76.) UML::Actions::IntermediateActions::A_value_writeStructuralFeatureAction 77.) UML::Actions::StructuredActions::A_exception_raiseExceptionAction 78.) UML::Actions::StructuredActions::A_fromAction_actionInputPin 79.) UML::Actions::StructuredActions::A_insertAt_addVariableValueAction 80.) UML::Actions::StructuredActions::A_removeAt_removeVariableValueAction 81.) UML::Actions::StructuredActions::A_result_readVariableAction 82.) UML::Actions::StructuredActions::A_value_writeVariableAction 83.) UML::Actions::StructuredActions::A_variable_variableAction 84.) UML::Activities::BasicActivities::A_parameter_activityParameterNode 85.) UML::Activities::BasicActivities::A_redefinedEdge_activityEdge 86.) UML::Activities::BasicActivities::A_redefinedNode_activityNode 87.) UML::Activities::CompleteActivities::A_action_localPostcondition 88.) UML::Activities::CompleteActivities::A_action_localPrecondition 89.) UML::Activities::CompleteActivities::A_condition_parameterSet 90.) UML::Activities::CompleteActivities::A_inState_objectNode 91.) UML::Activities::CompleteActivities::A_joinSpec_joinNode 92.) UML::Activities::CompleteActivities::A_ownedParameterSet_behavior 93.) UML::Activities::CompleteActivities::A_ownedParameterSet_behavioralFeature 94.) UML::Activities::CompleteActivities::A_selection_objectFlow 95.) UML::Activities::CompleteActivities::A_selection_objectNode 96.) UML::Activities::CompleteActivities::A_transformation_objectFlow 97.) UML::Activities::CompleteActivities::A_upperBound_objectNode 98.) UML::Activities::CompleteActivities::A_weight_activityEdge 99.) UML::Activities::CompleteStructuredActivities::A_bodyOutput_clause 100.) UML::Activities::CompleteStructuredActivities::A_bodyOutput_loopNode 101.) UML::Activities::CompleteStructuredActivities::A_loopVariableInput_loopNode 102.) UML::Activities::CompleteStructuredActivities::A_loopVariable_loopNode 103.) UML::Activities::CompleteStructuredActivities::A_result_conditionalNode 104.) UML::Activities::CompleteStructuredActivities::A_result_loopNode 105.) UML::Activities::ExtraStructuredActivities::A_exceptionInput_exceptionHandler 106.) UML::Activities::ExtraStructuredActivities::A_exceptionType_exceptionHandler 107.) UML::Activities::ExtraStructuredActivities::A_handlerBody_exceptionHandler 108.) UML::Activities::IntermediateActivities::A_activityEdge_guard 109.) UML::Activities::IntermediateActivities::A_decisionInputFlow_decisionNode 110.) UML::Activities::IntermediateActivities::A_decisionInput_decisionNode 111.) UML::Activities::IntermediateActivities::A_partition_activity 112.) UML::Activities::IntermediateActivities::A_represents_activityPartition 113.) UML::Activities::StructuredActivities::A_clause_body 114.) UML::Activities::StructuredActivities::A_clause_conditionalNode 115.) UML::Activities::StructuredActivities::A_clause_test 116.) UML::Activities::StructuredActivities::A_decider_clause 117.) UML::Activities::StructuredActivities::A_decider_loopNode 118.) UML::Activities::StructuredActivities::A_executableNode_sequenceNode 119.) UML::Activities::StructuredActivities::A_loopNode_bodyPart 120.) UML::Activities::StructuredActivities::A_loopNode_setupPart 121.) UML::Activities::StructuredActivities::A_test_loopNode 122.) UML::AuxiliaryConstructs::InformationFlows::A_conveyed_informationFlow 123.) UML::AuxiliaryConstructs::InformationFlows::A_informationSource_informationFlow 124.) UML::AuxiliaryConstructs::InformationFlows::A_informationTarget_informationFlow 125.) UML::AuxiliaryConstructs::InformationFlows::A_realizingActivityEdge_informationFlow 126.) UML::AuxiliaryConstructs::InformationFlows::A_realizingConnector_informationFlow 127.) UML::AuxiliaryConstructs::InformationFlows::A_realizingMessage_informationFlow 128.) UML::AuxiliaryConstructs::InformationFlows::A_represented_representation 129.) UML::AuxiliaryConstructs::Templates::A_actual_templateParameterSubstitution 130.) UML::AuxiliaryConstructs::Templates::A_constrainingClassifier_classifierTemplateParameter 131.) UML::AuxiliaryConstructs::Templates::A_default_templateParameter 132.) UML::AuxiliaryConstructs::Templates::A_extendedSignature_redefinableTemplateSignature 133.) UML::AuxiliaryConstructs::Templates::A_formal_templateParameterSubstitution 134.) UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature 135.) UML::AuxiliaryConstructs::Templates::A_nameExpression_namedElement 136.) UML::AuxiliaryConstructs::Templates::A_ownedActual_templateParameterSubstitution 137.) UML::AuxiliaryConstructs::Templates::A_ownedDefault_templateParameter 138.) UML::AuxiliaryConstructs::Templates::A_parameter_templateSignature 139.) UML::AuxiliaryConstructs::Templates::A_signature_templateBinding 140.) UML::Classes::Dependencies::A_contract_substitution 141.) UML::Classes::Dependencies::A_mapping_abstraction 142.) UML::Classes::Interfaces::A_contract_interfaceRealization 143.) UML::Classes::Interfaces::A_interface_ownedAttribute 144.) UML::Classes::Interfaces::A_interface_redefinedInterface 145.) UML::Classes::Interfaces::A_nestedClassifier_interface 146.) UML::Classes::Kernel::A_annotatedElement_comment 147.) UML::Classes::Kernel::A_classifier_instanceSpecification 148.) UML::Classes::Kernel::A_constrainedElement_constraint 149.) UML::Classes::Kernel::A_definingFeature_slot 150.) UML::Classes::Kernel::A_endType_association 151.) UML::Classes::Kernel::A_general_classifier 152.) UML::Classes::Kernel::A_general_generalization 153.) UML::Classes::Kernel::A_importedElement_elementImport 154.) UML::Classes::Kernel::A_importedMember_namespace 155.) UML::Classes::Kernel::A_importedPackage_packageImport 156.) UML::Classes::Kernel::A_inheritedMember_classifier 157.) UML::Classes::Kernel::A_instance_instanceValue 158.) UML::Classes::Kernel::A_member_namespace 159.) UML::Classes::Kernel::A_mergedPackage_packageMerge 160.) UML::Classes::Kernel::A_navigableOwnedEnd_association 161.) UML::Classes::Kernel::A_opposite_property 162.) UML::Classes::Kernel::A_raisedException_behavioralFeature 163.) UML::Classes::Kernel::A_raisedException_operation 164.) UML::Classes::Kernel::A_redefinedClassifier_classifier 165.) UML::Classes::Kernel::A_redefinedElement_redefinableElement 166.) UML::Classes::Kernel::A_redefinedOperation_operation 167.) UML::Classes::Kernel::A_redefinedProperty_property 168.) UML::Classes::Kernel::A_redefinitionContext_redefinableElement 169.) UML::Classes::Kernel::A_relatedElement_relationship 170.) UML::Classes::Kernel::A_source_directedRelationship 171.) UML::Classes::Kernel::A_subsettedProperty_property 172.) UML::Classes::Kernel::A_superClass_class 173.) UML::Classes::Kernel::A_target_directedRelationship 174.) UML::Classes::Kernel::A_type_operation 175.) UML::Classes::Kernel::A_type_typedElement 176.) UML::CommonBehaviors::BasicBehaviors::A_behavior_opaqueExpression 177.) UML::CommonBehaviors::BasicBehaviors::A_behavior_ownedParameter 178.) UML::CommonBehaviors::BasicBehaviors::A_behavioredClassifier_ownedBehavior 179.) UML::CommonBehaviors::BasicBehaviors::A_classifierBehavior_behavioredClassifier 180.) UML::CommonBehaviors::BasicBehaviors::A_context_behavior 181.) UML::CommonBehaviors::BasicBehaviors::A_postcondition_behavior 182.) UML::CommonBehaviors::BasicBehaviors::A_precondition_behavior 183.) UML::CommonBehaviors::BasicBehaviors::A_redefinedBehavior_behavior 184.) UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression 185.) UML::CommonBehaviors::Communications::A_changeExpression_changeEvent 186.) UML::CommonBehaviors::Communications::A_event_trigger 187.) UML::CommonBehaviors::Communications::A_operation_callEvent 188.) UML::CommonBehaviors::Communications::A_ownedReception_class 189.) UML::CommonBehaviors::Communications::A_ownedReception_interface 190.) UML::CommonBehaviors::Communications::A_ownedTrigger_behavioredClassifier 191.) UML::CommonBehaviors::Communications::A_reception_signal 192.) UML::CommonBehaviors::Communications::A_signal_signalEvent 193.) UML::CommonBehaviors::SimpleTime::A_event_durationObservation 194.) UML::CommonBehaviors::SimpleTime::A_event_timeObservation 195.) UML::CommonBehaviors::SimpleTime::A_expr_duration 196.) UML::CommonBehaviors::SimpleTime::A_expr_timeExpression 197.) UML::CommonBehaviors::SimpleTime::A_max_durationInterval 198.) UML::CommonBehaviors::SimpleTime::A_max_interval 199.) UML::CommonBehaviors::SimpleTime::A_max_timeInterval 200.) UML::CommonBehaviors::SimpleTime::A_min_durationInterval 201.) UML::CommonBehaviors::SimpleTime::A_min_interval 202.) UML::CommonBehaviors::SimpleTime::A_min_timeInterval 203.) UML::CommonBehaviors::SimpleTime::A_observation_duration 204.) UML::CommonBehaviors::SimpleTime::A_observation_timeExpression 205.) UML::CommonBehaviors::SimpleTime::A_specification_durationConstraint 206.) UML::CommonBehaviors::SimpleTime::A_specification_intervalConstraint 207.) UML::CommonBehaviors::SimpleTime::A_specification_timeConstraint 208.) UML::CommonBehaviors::SimpleTime::A_when_timeEvent 209.) UML::Components::BasicComponents::A_contract_connector 210.) UML::Components::BasicComponents::A_provided_component 211.) UML::Components::BasicComponents::A_realizingClassifier_componentRealization 212.) UML::Components::BasicComponents::A_required_component 213.) UML::Components::PackagingComponents::A_component_packagedElement 214.) UML::CompositeStructures::Collaborations::A_classifier_representation 215.) UML::CompositeStructures::Collaborations::A_collaborationRole_collaboration 216.) UML::CompositeStructures::Collaborations::A_collaborationUse_classifier 217.) UML::CompositeStructures::Collaborations::A_roleBinding_collaborationUse 218.) UML::CompositeStructures::Collaborations::A_type_collaborationUse 219.) UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd 220.) UML::CompositeStructures::InternalStructures::A_end_connector 221.) UML::CompositeStructures::InternalStructures::A_ownedAttribute_structuredClassifier 222.) UML::CompositeStructures::InternalStructures::A_ownedConnector_structuredClassifier 223.) UML::CompositeStructures::InternalStructures::A_part_structuredClassifier 224.) UML::CompositeStructures::InternalStructures::A_redefinedConnector_connector 225.) UML::CompositeStructures::InternalStructures::A_role_structuredClassifier 226.) UML::CompositeStructures::InternalStructures::A_type_connector 227.) UML::CompositeStructures::InvocationActions::A_onPort_invocationAction 228.) UML::CompositeStructures::InvocationActions::A_port_trigger 229.) UML::CompositeStructures::Ports::A_encapsulatedClassifier_ownedPort 230.) UML::CompositeStructures::Ports::A_partWithPort_connectorEnd 231.) UML::CompositeStructures::Ports::A_provided_port 232.) UML::CompositeStructures::Ports::A_redefinedPort_port 233.) UML::CompositeStructures::Ports::A_required_port 234.) UML::Deployments::Artifacts::A_manifestation_artifact 235.) UML::Deployments::Artifacts::A_nestedArtifact_artifact 236.) UML::Deployments::Artifacts::A_ownedAttribute_artifact 237.) UML::Deployments::Artifacts::A_ownedOperation_artifact 238.) UML::Deployments::Artifacts::A_utilizedElement_manifestation 239.) UML::Deployments::Nodes::A_deployedArtifact_deployment 240.) UML::Deployments::Nodes::A_deployedElement_deploymentTarget 241.) UML::Deployments::Nodes::A_nestedNode_node 242.) UML::Interactions::BasicInteractions::A_action_actionExecutionSpecification 243.) UML::Interactions::BasicInteractions::A_action_interaction 244.) UML::Interactions::BasicInteractions::A_argument_message 245.) UML::Interactions::BasicInteractions::A_behavior_behaviorExecutionSpecification 246.) UML::Interactions::BasicInteractions::A_connector_message 247.) UML::Interactions::BasicInteractions::A_event_executionOccurrenceSpecification 248.) UML::Interactions::BasicInteractions::A_event_occurrenceSpecification 249.) UML::Interactions::BasicInteractions::A_executionSpecification_finish 250.) UML::Interactions::BasicInteractions::A_executionSpecification_start 251.) UML::Interactions::BasicInteractions::A_execution_executionOccurrenceSpecification 252.) UML::Interactions::BasicInteractions::A_generalOrdering_interactionFragment 253.) UML::Interactions::BasicInteractions::A_invariant_stateInvariant 254.) UML::Interactions::BasicInteractions::A_lifeline_represents 255.) UML::Interactions::BasicInteractions::A_message_messageEnd 256.) UML::Interactions::BasicInteractions::A_operation_receiveOperationEvent 257.) UML::Interactions::BasicInteractions::A_operation_sendOperationEvent 258.) UML::Interactions::BasicInteractions::A_receiveEvent_message 259.) UML::Interactions::BasicInteractions::A_selector_lifeline 260.) UML::Interactions::BasicInteractions::A_sendEvent_message 261.) UML::Interactions::BasicInteractions::A_signal_receiveSignalEvent 262.) UML::Interactions::BasicInteractions::A_signal_sendSignalEvent 263.) UML::Interactions::BasicInteractions::A_signature_message 264.) UML::Interactions::Fragments::A_argument_interactionUse 265.) UML::Interactions::Fragments::A_cfragmentGate_combinedFragment 266.) UML::Interactions::Fragments::A_formalGate_interaction 267.) UML::Interactions::Fragments::A_guard_interactionOperand 268.) UML::Interactions::Fragments::A_interactionUse_actualGate 269.) UML::Interactions::Fragments::A_lifeline_decomposedAs 270.) UML::Interactions::Fragments::A_maxint_interactionConstraint 271.) UML::Interactions::Fragments::A_message_considerIgnoreFragment 272.) UML::Interactions::Fragments::A_minint_interactionConstraint 273.) UML::Interactions::Fragments::A_operand_combinedFragment 274.) UML::Interactions::Fragments::A_refersTo_interactionUse 275.) UML::StateMachines::BehaviorStateMachines::A_deferrableTrigger_state 276.) UML::StateMachines::BehaviorStateMachines::A_doActivity_state 277.) UML::StateMachines::BehaviorStateMachines::A_effect_transition 278.) UML::StateMachines::BehaviorStateMachines::A_entry_connectionPointReference 279.) UML::StateMachines::BehaviorStateMachines::A_entry_state 280.) UML::StateMachines::BehaviorStateMachines::A_exit_connectionPointReference 281.) UML::StateMachines::BehaviorStateMachines::A_exit_state 282.) UML::StateMachines::BehaviorStateMachines::A_guard_transition 283.) UML::StateMachines::BehaviorStateMachines::A_redefinedState_state 284.) UML::StateMachines::BehaviorStateMachines::A_redefinedTransition_transition 285.) UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region 286.) UML::StateMachines::BehaviorStateMachines::A_region_extendedRegion 287.) UML::StateMachines::BehaviorStateMachines::A_stateMachine_extendedStateMachine 288.) UML::StateMachines::BehaviorStateMachines::A_state_redefinitionContext 289.) UML::StateMachines::BehaviorStateMachines::A_transition_redefinitionContext 290.) UML::StateMachines::BehaviorStateMachines::A_trigger_transition 291.) UML::StateMachines::ProtocolStateMachines::A_generalMachine_protocolConformance 292.) UML::StateMachines::ProtocolStateMachines::A_preCondition_protocolTransition 293.) UML::StateMachines::ProtocolStateMachines::A_protocol_port 294.) UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition 295.) UML::UseCases::A_addition_include 296.) UML::UseCases::A_condition_extend 297.) UML::UseCases::A_extendedCase_extend 298.) UML::UseCases::A_ownedUseCase_classifier All of the above are ownedEnd Properties. There were zero such cases in 2.1.1. b) The following 55 associations in the Infrastructure.xmi (2.3) at least one unnamed association end property which must be given proper names according to the convention for naming associations in 6.4.2; the IDs of these associations & their association ends must be regenerated. 1.) InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature 2.) InfrastructureLibrary::Core::Abstractions::Comments::A_annotatedElement_comment 3.) InfrastructureLibrary::Core::Abstractions::Constraints::A_constrainedElement_constraint 4.) InfrastructureLibrary::Core::Abstractions::Constraints::A_member_namespace 5.) InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier 6.) InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_generalization 7.) InfrastructureLibrary::Core::Abstractions::Instances::A_classifier_instanceSpecification 8.) InfrastructureLibrary::Core::Abstractions::Instances::A_definingFeature_slot 9.) InfrastructureLibrary::Core::Abstractions::Instances::A_instance_instanceValue 10.) InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_namespace 11.) InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement 12.) InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement 13.) InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship 14.) InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship 15.) InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship 16.) InfrastructureLibrary::Core::Abstractions::Super::A_classifier_inheritedMember 17.) InfrastructureLibrary::Core::Abstractions::Super::A_general_classifier 18.) InfrastructureLibrary::Core::Abstractions::TypedElements::A_type_typedElement 19.) InfrastructureLibrary::Core::Basic::A_annotatedElement_comment 20.) InfrastructureLibrary::Core::Basic::A_opposite_property 21.) InfrastructureLibrary::Core::Basic::A_raisedException_operation 22.) InfrastructureLibrary::Core::Basic::A_superClass_class 23.) InfrastructureLibrary::Core::Basic::A_type_typedElement 24.) InfrastructureLibrary::Core::Constructs::A_annotatedElement_comment 25.) InfrastructureLibrary::Core::Constructs::A_constrainedElement_constraint 26.) InfrastructureLibrary::Core::Constructs::A_endType_association 27.) InfrastructureLibrary::Core::Constructs::A_general_classifier 28.) InfrastructureLibrary::Core::Constructs::A_importedElement_elementImport 29.) InfrastructureLibrary::Core::Constructs::A_importedMember_namespace 30.) InfrastructureLibrary::Core::Constructs::A_importedPackage_packageImport 31.) InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier 32.) InfrastructureLibrary::Core::Constructs::A_member_namespace 33.) InfrastructureLibrary::Core::Constructs::A_mergedPackage_packageMerge 34.) InfrastructureLibrary::Core::Constructs::A_navigableOwnedEnd_association 35.) InfrastructureLibrary::Core::Constructs::A_opposite_property 36.) InfrastructureLibrary::Core::Constructs::A_raisedException_behavioralFeature 37.) InfrastructureLibrary::Core::Constructs::A_raisedException_operation 38.) InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement 39.) InfrastructureLibrary::Core::Constructs::A_redefinedOperation_operation 40.) InfrastructureLibrary::Core::Constructs::A_redefinedProperty_property 41.) InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement 42.) InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship 43.) InfrastructureLibrary::Core::Constructs::A_source_directedRelationship 44.) InfrastructureLibrary::Core::Constructs::A_subsettedProperty_property 45.) InfrastructureLibrary::Core::Constructs::A_superClass_class 46.) InfrastructureLibrary::Core::Constructs::A_target_directedRelationship 47.) InfrastructureLibrary::Core::Constructs::A_type_operation 48.) InfrastructureLibrary::Core::Constructs::A_type_typedElement 49.) InfrastructureLibrary::Profiles::A_appliedProfile_profileApplication 50.) InfrastructureLibrary::Profiles::A_icon_stereotype 51.) InfrastructureLibrary::Profiles::A_metaclassReference_profile 52.) InfrastructureLibrary::Profiles::A_metamodelReference_profile 53.) InfrastructureLibrary::Profiles::A_ownedEnd_extension 54.) InfrastructureLibrary::Profiles::A_ownedStereotype_profile 55.) InfrastructureLibrary::Profiles::A_type_extensionEnd All of the above are ownedEnds. The names of the ownedEnds will be generated as the lowercase version of the name of the Type of each ownedEnd. c) In Superstructure.xmi (2.3) the following Associations will be named as follows and their id's regenerated: 1.) Tuple{pkg = 'UML::Components::BasicComponents', end1_type = 'ConnectorEnd', end1_name = 'end', end2_type = 'Connector', end2_name = ''} To be consistent with Figure 8.3 in the UML 2.3 document: => change end2_name='connector' and show the name of this association end on figure 8.3 => make the association named 'A_end_connector' 2.) Tuple{pkg = 'UML::Components::BasicComponents', end1_type = 'Property', end1_name = 'partWithPort', end2_type = 'ConnectorEnd', end2_name = ''} To be consistent with Figure 8.3 in the UML 2.3 document: => change end2_name='connectorEnd' and show the name of this association end on figure 8.3 => make the association named 'A_partWithPort_connectorEnd' 3.) Tuple{pkg = 'UML::Activities::CompleteStructuredActivities', end1_type = 'OutputPin', end1_name = 'structuredNodeOutput', end2_type = 'StructuredActivityNode', end2_name = ''} To be consistent with Figure 12.22 in the UML 2.3 document: => change end2_name='structuredActivityNode' and show the name of this association end on figure 12.22 => make the association named 'A_structuredNodeOutput_structuredActivityNode' 4.) Tuple{pkg = 'UML::Activities::CompleteStructuredActivities', end1_type = 'InputPin', end1_name = 'structuredNodeInput', end2_type = 'StructuredActivityNode', end2_name = ''} To be consistent with Figure 12.22 in the UML 2.3 document: => change end2_name='structuredActivityNode' and show the name of this association end on figure 12.22 => make the association named 'A_structuredNodeInput_structuredActivityNode' 5.) Tuple{pkg = 'UML::Components::BasicComponents', end1_type = 'ConnectableElement', end1_name = 'role', end2_type = 'ConnectorEnd', end2_name = ''} To be consistent with Figure 8.3 in the UML 2.3 document: => change end2_name='connectorEnd' and show the name of this association end on figure 8.3 => make the association named 'A_role_connectorEnd'
Actions taken:
September 4, 2009: received issue
April 26, 2010: closed issue

Issue 14429: UML 2.3 draft, 11.3.1 - AcceptCallAction (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The text of the description is contradictory. The first sentence says:

 

�AcceptCallAction is an accept event action representing the receipt of a synchronous call request. ....� 

 

In the second paragraph it says:

 

This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

 

Although the description states twice that it is for the receipt of synchronous calls it then goes on to describe its use for asynchronous calls.

Resolution: Accept call actions are intended to receive synchronous calls, however they will, indeed, also accept asynchronous calls, but, as already noted in the spec, no reply will be sent in such cases. The description could be better worded to make this clear without sounding contradictory.
Revised Text: In Subclause 11.3.1, under Description, remove the work �synchronous" from the first sentence. Replace the second paragraph with the following: This action is primarily intended to for synchronous calls, though it will also accept asynchronous calls to its referenced operation. If it is used to handle an asynchronous call, then a reply action may still be executed on the return information produced by the accept call action, but the reply action will complete immediately with not effect.
Actions taken:
September 22, 2009: received issue
April 25, 2011: closed issue

Issue 14448: UML 2.3: Errors in example serialization for Profiles in Chapter 18 (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are many errors in the example XMI serialization for the profile and the profile application and the xsd  in section 18.3.6:

 

The UML namespaces (in the definitions and the hrefs) refer to version 2.0 (and in some places inconsistently to 2.1) and should be correct for the current version

The profile definition is missing a definition of a namespace and prefix for xmi

The ownedMember tag should be packagedElement to be consistent with how superstructure is serialized.

The isComposite, lower and upper tags are not valid in a superstructure serialization (and upper is not valid in an infrastructure serialization).

Resolution: The examples are corrected to follow the rules. We remove the schema example altogether because it presupposes that we are publishing an XML Schema for UML, and we are not doing so. The text just preceding the schema example is incomprehensible and unnecessary so is deleted.
Revised Text: Replace the text in 18.3.6 starting �The first serialization below �� and finishing �</xsd:schema>� by the following: <replacement> The first serialization below shows how the model in Figure 18.6 on page 659 (instance of the profile and UML2 metamodel) can be exchanged. Note that [version number] is a placeholder for the published normative version number of the referenced normative UML specification, which follows the format YYYYMMDD. <?xml version="1.0" encoding="UTF-8"?> <uml:Profile xmi:version="2.1" xmlns:xmi=http://schema.omg.org/spec/XMI/2.1 xmlns:cmof=http://schema.omg.org/spec/MOF/2.0/cmof.xml xmlns:uml=http://www.omg.org/spec/UML/[version number] xmi:id="id0" name="HomeExample" metamodelReference="id2"> <packageImport xmi:id="id2"> <importedPackage href="http://www.omg.org/spec/UML/[version number]/UML.xmi#_0"/> </packageImport> <packagedElement xmi:type="uml:Stereotype" xmi:id="id3" name="Home"> <ownedAttribute xmi:type="uml:Property" xmi:id="id5" name="base_Interface" association="id6"> <type href="http://www.omg.org/spec/UML/[version number]/UML.xmi#Interface"/> </ownedAttribute> </packagedElement> <packagedElement xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" aggregation="composite"> </ownedEnd> </packagedElement> <cmof:Tag name="org.omg.xmi.nsPrefix" value="HomeExample"/> <cmof:Tag name="org.omg.xmi.nsURI" value="http://HomeExample/20101201/HomeExample.xmi"/> </uml:Profile> </replacement> Replace the text below figure 18.9 and commencing �Now the XMI code �� by the following: <replacement> Now the XMI below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the �HomeExample� schema, if the tool does not have this profile definition. <?xml version="1.0" encoding="UTF-8"?> <xmi xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://www.omg.org/spec/UML/[version number]" xmlns:HomeExample="http://HomeExample/20101201/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="http://HomeExample/20101201/HomeExample.xmi#id0"/> </profileApplication> <packagedElement xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>  <HomeExample:Home xmi:id= "id4" base_Interface="id2"/> </xmi> </replacement>
Actions taken:
October 5, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 14554: Interface-redefinedInterface should subset Classifier-redefinedClassifier (uml2-rtf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Salman Qadri, Salman.Qadri(at)mathworks.com)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2.3 and earlier, Interface-redefinedInterface subsets RedefinableElement-redefinedElement. However, since Interface specializes Classifier, the property should subset Classifier-redefinedClassifier instead, which will in turn subset RedefinableElement-redefinedElement

Resolution: It is legal for Interface::redefinedInterface to have a subset relation with Classifier::redefinedClassifier, even if the latter is not a derived union. Such a relation simply means that, even though there are two distinct associations, any redefinedInterface must also be a redefinedClassifier � but that there may be redefinedClassifiers (of an interface) that are not redefinedInterfaces. Of course, if it is desired that an interface only be able to redefine another interface, then the simplest thing to do would be to just add a constraint to Interface that all redefinedClassifiers must be interfaces. Actually, the proper way to do this is to redefined the OCL operation RedefinableElement::isConsistentWith. On the other hand, if we make redefinedClassifier a derived union, then we also need to add non-derived subsetting associations to all the subclasses of Classifier, not just Interface. And this would result in a definite semantics change. For example, right now a class can, seemingly, realize any classifier. RedefinableElement::isConsistentWith is false by default, and needs to be �must be overridden for subclasses of RedefinableElement to define the consistency conditions�. Class and Interface would therefore need to override isConsistentWith in order to define the meaning of redefinition of specific kinds of classifiers. Redefinition of classifiers was introduced in order to allow behaviors, which are Classifiers, to redefine other behaviors. This is possibly a bigger problem. The model for redefinable elements sets up a relatively simple but quite flexible mechanism for establishing the consistency of the redefinition of various kinds of elements. But this simply has not been used properly in the specification of most kinds of redefinable elements. However, section 7.3.24 does have a simpler error, redefinedInterface cannot subset Element::redefinedElement since it doesn?t exist. See figure 7.9 and figure 7.16. Rather than address the meaning of interface redefinition in this resolution, the error should be corrected so that at least the redefineInterface contributes to a valid subset as suggested in the issue.
Revised Text: In figure 7.16, change association end Interface::redefinedInterface {subsets redefinedElement} to redefinedInterface {subsets redefinedClassifier}. In section 7.3.24, change: ? redefinedInterface: Interface (References all the Interfaces redefined by this Interface. (Subsets Element::redefinedElement) To: ? redefinedInterface: Interface References all the Interfaces redefined by this Interface. (Subsets Classifier::redefinedClassifier)
Actions taken:
October 12, 2009: received issue
April 25, 2011: closed issue

Issue 14565: typo in new attribute name (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

The new 2.3 spec contains typo (double i) in new attribute name:
 
iisLocallyReentrant : Boolean = false  
 
In Subclause 12.3.2 Action, under Attributes.

Resolution: agreed
Revised Text: In the UML 2.3 Superstructure Specification, Subclause 12.3.2 Action, under Attributes, change �iisLocallyReentrant� to �isLocallyReentrant�
Actions taken:
October 15, 2009: received issue
April 25, 2011: closed issue

Issue 14569: Constraint [1] for WriteStructuralFeatureAction is incorrect (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: UML Superstructure (formal/09-02-02)

Subclause: 11.3.55

 

The OCL for constraint [1] of WriteStructuralFeatureAction incorrectly constraints the type of the value pin of the action to be the featuring classifier of the structural feature being written to. The type of the value should actually be the same as the type of the structural feature. It is the object pin which should be constrained to have a featuring classifier as its type � but this constraint is own the parent StructuralFeatureAction class, not on WriteStructuralFeatureAction itself. The correct OCL is:

 

self.value->notEmpty() implies self.value.type = self.structuralFeature.type

 

(The possibility of self.value being empty is due to the resolution of Issue 9870 in UML 2.3.)

Resolution: agreed
Revised Text: In Subclause 11.3.55, WriteStructuralFeatureAction, replace the constraint [1] with: [1] The type of the value input pin is the same as the type of the structural feature. self.value->notEmpty() implies self.value.type = self.structuralFeature.type
Actions taken:
October 16, 2009: received issue
April 25, 2011: closed issue

Issue 14570: Constraint [3] on TestIdentityAction is incorrect (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: UML Superstructure (formal/09-02-02)

Subclause: 11.3.49 TestIdentityAction

 

Constraint [3] for TestIdentityAction is:

 

[3] The type of the result is Boolean. 

self.result.type.oclIsTypeOf(Boolean) 

 

While the English statement expresses the correct intent, the OCL is wrong. As written, the OCL requires that the type of the object referenced by the type property of the OutputPin be Boolean. But this is, of course, impossible, since the type of OutputPin::type is the metaclass Type, and any value for this property must be for an instance of a concrete subclass of type, such as Classifier or PrimitiveType. Boolean, on the other hand, is represented as an instance of the metaclass PrimitiveType. That is, the OCL for this constraint is confusing metalevels.

 

The OCL should really be something like:

 

self.result.type = PrimitiveType instance representing Boolean

 

However, unless some sort of standard way to reference the M1 instance representing Boolean within the UML metamodel, it is unclear how to formally write �PrimitiveType instance representing Boolean�.

Resolution: agreed
Revised Text: In Subclause 11.3.49, TestIdentityAction, remove the OCL for constraint [3] and replace the text with: [3] The type of the result is the UML standard primitive type Boolean. (This is not directly representable in OCL at the metamodel level.)
Actions taken:
October 16, 2009: received issue
April 25, 2011: closed issue

Issue 14613: UML2 - non-unique association names in L3.merged.cmof (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think the rules say that associations should be uniquely named in a package.  L3.merged has three non-unique association names:

 

A_outgoing_source

A_realization_abstraction

A_templateParameter_parameteredElement

Resolution: See issues 14287 and 14632 for disposition
Revised Text:
Actions taken:
November 4, 2009: received issue
April 25, 2011: closed issue

Issue 14627: UML2: Incomplete definition for Activity.structuredNode (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Currently the sentence is incomplete:

 

/structuredNode : StructuredActivityNode [0..*] Top-level structured nodes in the activity. Subsets

 

It should subset node and group (according to the diagram).

Resolution: agreed
Revised Text: In the UML 2.3 Superstructure Specification, Subclause 12.3.4 Activity, under Associations, Package StructuredActivities, in the descriptions of structuredNode, change �Subsets� to �{Subsets Activity::node, Activity::group}�.
Actions taken:
November 13, 2009: received issue
April 25, 2011: closed issue

Issue 14629: UML 2 Events referred to by OccurrenceSpecifications should be optional (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2, every OccurrenceSpecification must be associated with an Event.  The Event in turn should have a name and an owning package.  But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications.

 

This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model.  This simply consumes memory footprint without providing any user value.

                                                                        

If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects.  Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1.

Resolution: The Events that are only defined for Interactions are superfluous and is removed. The necessary information is in the Signal or Operation designated by the signature property of Message together with the MessageKind and MessageSort properties. In UML 2.3 the signature attribute is derived, in this revision it is changed to non-derived.
Revised Text: (notice that all references are to the section numbering from UML 2.3 superstructure) Model changes and their derived figure changes: Delete the following classes: ExecutionEvent, CreationEvent, SendOperationEvent, SendSignalEvent, ReceiveOperationEvent, ReceiveSignalEvent Delete the association from OccurrenceSpecification to Event. Delete the association from ExecutionOccurrenceSpecification to ExecutionEvent (actually follows by necessity when ExecutionEvent is removed) Modify the association from ExecutionOccurrenceSpecification to ExecutionSpecification such that the multiplicity at the ExecutionOccurrenceSpecification is 0..2 Modify the association from Message to NamedElement with role �signature? such that it is no longer derived and readOnly. The Figures are affected as follows: Figure 14.2 is removed Figure 14.3 should add DestructionOccurrenceSpecification as a specialization of OccurrenceSpecification. Figure 14.5: The class Event and its association should be removed. The association from Message to NamedElement (�signature?) should not be derived. Figure 14.6: Change multiplicity on back end of the �execution? association. Remove ExecutionEvent and its association from ExecutionOccurrenceSpecification. (Follows automatically from model changes) Text changes in the 14.3 Class Descriptions: The following sections are removed, and subsequently sections must be renumbered: 14.3.6 CreationEvent, 14.3.8 ExecutionEvent, 14.3.27 ReceiveOperationEvent, 14.3.28 ReceiveSignalEvent, 14.3.29 SendOperationEvent, 14.3.30 SendSignalEvent. Individual changes in the class descriptions: In class 14.3.20 Message: The following text should be replacing the description of the signature association: The signature of the Message is the specification of its content. It refers either an Operation or a Signal. The first constraint should read: [1] If the sendEvent and the receiveEvent of the same Message are on the same Lifeline, the sendEvent must be ordered before the receiveEvent. Add a new constraint (adapted from the deleted CreationEvent) [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. The last three paragraphs of the Semantics section should read (the last paragraph should be eliminated): When a Message represents an Operation, the arguments of the Message are the arguments of the Operation. When a Message represents a Signal, the arguments of the Message are the attributes of the Signal. Under Notation, under the line of �Object creation Message� another line should be included: Object deletion Message should end in a DestructionOccurrenceSpecification. For class 14.3.7 DestructionEvent: Rename the class DestructionEvent to DestructionOccurrenceSpecification and replace the name everywhere in the description of 14.3.7. Replace �DestructionEvent� with �DestructionOccurrenceSpecification� also in Table 14.1 and Table 14.6 (3 mentions in total). In section on Generalizations ? �OccurrenceSpecification (from BasicInteractions)� on page TBD with the appropriate reference to page. The Section Constraints should read: [1] No other OccurrenceSpecifications on a given Lifeline in a given InteractionOperand may appear below a DestructionOccurrenceSpecification. In class 14.3.9 ExecutionOccurrenceSpecification In section Associations, Remove the event association. In class 14.3.23 MessageOccurrenceSpecification: In section Associations Remove the event association. Therefore the section should read: No additional associations. In class 14.3.25 OccurrenceSpecification In section Associations Remove the event association. Replace twice in 14.3.25 �EventOcurrences� by �OccurrenceSpecifications�. (This is an old spelling mistake.)
Actions taken:
November 6, 2009: received issue
April 25, 2011: closed issue

Issue 14630: Some owned operations with OCL expression bodies but without their "isQuery" set to "true" (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

A body condition is specified for operation '<Operation> ConnectableElement::end () : ConnectorEnd [0..*]', but it is not a query.
A body condition is specified for operation '<Operation> Vertex::incoming () : Transition [0..*]', but it is not a query.
A body condition is specified for operation '<Operation> Vertex::outgoing () : Transition [0..*]', but it is not a query.

**This is a metamodel only fix

Resolution: All additional operations in the UML metamodel are queries and as such must be marked with isQuery = true in the metamodel
Revised Text: Change UML 2.3 Superstructure.cmof as follows: Set [isQuery = true] for the following operations: - InternalStructures::ConnectableElement::end() - BehaviorStateMachine::Vertex::incoming() - BehaviorStateMachine::Vertex::outgoing()
Actions taken:
November 12, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 14631: All enumertion literals in the model have their "classifier" collections empty (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

All enumertion literals in the model have their "classifier" collections empty (i.e do not contain the corresponding enumertion)

This issue also existed in UML 2.1.1. To fix, I can add the enumeration to the "classifier" collection of the literals. But, shouldn't EnumertionLiteral have redefined "classifier" and made it derived from "enumeration" association end?

**This is a metamodel only fix

Resolution: The �classifier? association is inherited by EnumerationLiteral from InstanceSpecification in the UML spec, not in the MOF spec, which the UML metamodel is an instance of. Therefore, the enumeration literals in UML should not have this property. However, in the UML spec, an enumeration literal?s classifier should always be set to the enumeration owning it. Therefore, �classifier? should be redefined to be a derived association end that gets it value from the �enumeration? property of enumeration literal, which should also be made non-optional, since an enumeration should not be owned by anything other than an enumeration.
Revised Text: see pages 83 - 84 of ptc/2011-01-19
Actions taken:
November 18, 2009: received issue
April 25, 2011: closed issue

Issue 14632: Associations with same name that live in different packages violate unique name constraint (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some associations that have the same name, but exist in different packages in the unmerged model, show up together in the merged model violating the unique name constraint

BasicActivities::A_outgoing_source (Figure 12.5) and BehaviorStateMachines::A_outgoing_source (Figure 15.2). 
BasicActivities::A_incoming_target (Figure 12.5) and BehaviorStateMachines::A_incoming_target(Figure 15.2). 
BasicComponents::A_realization_abstraction (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction (Figure 17.2)

One way to fix that is to rename the associations to avoid the name collission, for example:

BasicActivities::A_outgoing_source_node and BehaviorStateMachines::A_outgoing_source_vertex
BasicActivities::A_incoming_target_node and BehaviorStateMachines::A_incoming_target_vertex
BasicComponents::A_realization_abstraction_component (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction_flow (Figure 17.2)

** This fix affects the respective figures to show the non-default association names explicitly

Resolution: Agree to the suggestion given in the issue.
Revised Text: Change UML 2.3 Superstructure.cmof as follows: - Rename: BasicActivities::A_outgoing_source To: BasicActivities::A_outgoing_source_node - Rename: BehaviorStateMachines::A_outgoing_source To: BehaviorStateMachines::A_outgoing_source_vertex - Rename: BasicActivities::A_incoming_target To: BasicActivities::A_incoming_target_node - Rename BehaviorStateMachines::A_incoming_target To: BehaviorStateMachines::A_incoming_target_vertex - Rename: BasicComponents::A_realization_abstraction To: BasicComponents::A_realization_abstraction_component - Rename: InformationFlow::A_realization_abstraction To: InformationFlow::A_realization_abstraction_flow Display the name labels for the changed associations (above) in Figure 8.2, Figure 12.5, Figure 15.2, and Figure 7.2 of UML 2.3 Superstructure spec doc.
Actions taken:
November 12, 2009: received issue
April 25, 2011: closed issue

Issue 14633: Attributes without a type (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Profiles::ExtensionEnd::lower is not typed (should have been of type Integer)

** This fix is only in the metamodel

Resolution: As suggested, set the type of �lower? to Integer
Revised Text: In UML 2.3 Infrastructure.cmof, set the type of Profiles::ExtensionEnd::lower to �PrimitiveTypes::Integer?
Actions taken:
November 12, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 14634: Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

a) StructuredActivities::StructuredActivityNode (specializes FundamentalActivities::ActivityGroup) with the following errors:
StructuredActivities::StructuredActivityNode::activity redefines StructuredActivities::ActivityGroup::inActivity
StructuredActivities::StructuredActivityNode::node subsets StructuredActivities::ActivityGroup::containedNode

b) IntermediateActivities::Activity (does not specialize any other class), with the following errors
IntermediateActivities::Activity::group subsets Kernel::Element::ownedElement (notice that IntermediateActivities::Activity::partition subsets IntermediateActivities::Activity::group)

c) IntermediateActivities::ActivityGroup (does not specialize any other class), with the following errors
IntermediateActivities::ActivityGroup::inActivity subsets Kernel::Element::owner

d) IntermediateActivities::ActivityPartition (specializes IntermediateActivities::ActivityGroup), with the following errors
IntermediateActivities::ActivityPartition::subpartition subsets FundamentalActivities::ActivityGroup::subgroup
IntermediateActivities::ActivityPartition::superPartition subsets FundamentalActivities::ActivityGroup::superGroup (also notice the capitaliation diff between subpartitiion and superPartiion)

e) CompleteActivities::InterruptibleActivityRegion (specializes BasicActivities::ActivityGroup), with the following errors
CompleteActivities::InterruptibleActivityRegion::node subsets CompleteActivities::ActivityGroup::containedNode

f) Interfaces::Property (specializes Kernel::StructuralFeature), with the following errors
Interfaces::Property::interface subsets Kernel::A_attribute_classifier::classifier

** Fixes for those require fixing the spec and metamodel

Resolution: These problems are a consequence of improper understanding and documentation of package merge. a). The problem is caused because StructuredActivities::StructuredActivityNode inherits from FundamentalActivities::ActivityGroup, not StructuredActivities::ActivityGroup. Although according to the text the latter does not exist, it is actually present in the UML 2.3 metamodel. (See also 15264). The resolution is to inherit from the local ActivityGroup. Researching this also shows that the spec document is already quite seriously adrift from the metamodel. Although this will be fixed in UML 2.5, this resolution takes some steps to fix it. b) The problem is caused because IntermediateActivities::Activity has no base class. The resolution is to remove the subset assertion from IntermediateActivities::Activity::group. Since the subset is correctly declared in FundamentalActivities, it is reintroduced by the merge. c) The problem and resolution are analogous to (b). d) The problem is that the subsetted properties are those in FundamentalActivities, not those in IntermediateActivities. This is like (a). e) The problem is that InterruptableActivityRegion inherits from BasicActivities::ActivityGroup, not CompleteActivities::ActivityGroup. We make it inherit from the latter. f) The problem is that the Property defined in Interfaces is not related to Classifier, so there is no /attribute association to subset. We create a local Classifier and copy down the association.
Revised Text: a). In figure 12.21, show StructuredActivityNode inheriting from the unqualified ActivityGroup, not FundamentalActivities::ActivityGroup. In the heading of 12.3.7, change ActivityGroup (from BasicActivities, FundamentalActivities) to ActivityGroup (from BasicActivities, FundamentalActivities, IntermediateActivities, StructuredActivities, CompleteActivities, CompleteStructuredActivities) [Note: this reflects what was already there in UML 2.3] Under the Associations section of 12.3.7, change Package FundamentalActivities to Package FundamentalActivities, IntermediateActivities, and remove ContainedNode from the list of properties under this heading. [Note: this reflects what was there in UML 2.3 and also puts subGroup and superGroup into IntermediateActivities, which is needed to resolve (d) below]. Under the Associations section of 12.3.7, add a new section Package FundamentalActivities, IntermediateActivities, StructuredActivities, CompleteActivities and put ContainedNode back into this section. [Note: this reflects what was already there in UML 2.3] Under the Associations section of 12.3.7, change Package BasicActivities to Package BasicActivities, IntermediateActivities, CompleteStructuredActivities [Note: this reflects the packages in which ContainedEdge was actually defined in in 2.3] b) Remove the subsets assertion in the metamodel from IntermediateActivities::Activity::group. No changes are needed to diagrams or text. [Note: we observe in passing and without fixing it that the documentation of properties under Activity does not properly reflect the packaging in the 2.3 metamodel.] c) Remove the subsets assertion in the metamodel from IntermediateActivities::ActivityGroup::inActivity. No additional changes are needed to diagrams or text. [Note: the text from (a) above has reorganized the documentation for ActivityGroup. But it does not reflect the fact that group subsets ownedElement in FundamentalActivities and not IntermediateActivities. Realizing what would be needed to document this subtle distinction accurately as a set of edits to 2.3 is a vivid reminder of why we need to abolish package merge.] d) In the metamodel, introduce subGroup and superGroup into IntermediateActivities::ActivityGroup, so that figure 12.10 becomes legal. No additional changes are needed to diagrams or text. e) In the metamodel, add an inheritance between CompleteActivities::InterruptableActivityRegion and CompleteActivities::ActivityGroup. Change figure 12.20 to show InterruptableActivityRegion inheriting from an unqualified ActivityGroup. f) Introduce a metaclass Classifier to the package UML::Classes::Interfaces. Make Interface inherit from it in addition to Kernel::Classifier. Copy down the A_attribute_classifier association into the Interfaces package. Make Interface::ownedAttribute subset the local Classifier::attribute. In figure 7.16, make Interface inherit from unqualified Classifier as well as Kernel::Classifier, and show the /attribute association between unqualified Classifier and Property. In 7.3.8 change Classifier (from Kernel, Dependencies, PowerTypes) to Classifier (from Kernel, Dependencies, PowerTypes, Interfaces).
Actions taken:
November 12, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 14638: Some associations in the normative XMI has one memberEnd (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The problems regarding some associations with one memberEnd actually started in the "unmerged" model but show themselves in the "merged" model.

In 2.3, we added copy-down merge increments for some associations, in particular we added:

a- InternalStructures::A_feature_classifier (Figure 9.2) as a merge increment for Kernel::A_feature_featuringClassifier (Figure 7.10)
b- BasicComponents::A_role_connectorEnd (Figure 8.3) as a merge increment for InternlStructures::A_end_role (Figure 9.3)
c- BasicComponents::A_end_connector (Figure 8.3) as a merge increment for InternalStructures::A_end_connector (Figure 9.3)

The problem in (a) and (b) is that the merge-increment association has a different name than the original association, thus the package merge algorithm could not match them by name and they ended up both in the merged model. Since the navigable ends of those associations still have similar names, they were matched and merged in their respective Classes but their "association" references were set to the merge-increment associations, leaving the original association with only one reference in their "memberEnd" collections.

Trying to rename the merge increment associations in (a) and (b) similar to the original associations (by renaming the non-navigable ends and also switching the order of memberEnds references in (b)) and re-performing the package merge, the associations got matched up and only one association in each case ended up in the merged model, as expected. However, the merge algorithm could not merge the non-navigable ends of the merge increment associations with their corresponding navigable ends in the original associations (due to a bug in the algorithm implementation I think), which should have resulted in keeping only the navigable ends, so both ends showed up in the merged model and the "memberEnd" collections had 3 references. To fix that temporarily (until the bug is fixed), I manually deleted the extraneous non-navigable ends from the resulting associations in the merged model.

**These fixes affect Figures 9.2 and 8.3 to show the names of the non-naviagle ends

The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, I just had to put the "aggregation" and "multipclity" of the merge increment similar to the original.

Resolution: As suggested by the issue, for cases (a) and (b), both the original and the copy down association need to have the same association names, same role names and same role navigability/ownership, in order for package merge to merge them into �one� association in the target package. The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, the "aggregation" and "multiplicity" of the role in the merge increment association should be similar to the original.
Revised Text: see pages 93 - 95 of ptc/2011-01-19
Actions taken:
November 12, 2009: received issue
April 25, 2011: closed issue

Discussion:

Issue 14926: is composite, but does not subset ownedElement (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

I tried to collect critical metamodel implementation issues we have in our tool.

Critical means that every time we must do changes in metamodel to be able to implement it.

I believe, Eclipse UML2 implementation has exactly same issues.

 

Issues may be devided into such groups:

 

1. Properties which are composite, but do not subset ownedElement. Our solution - subset ownedElement

2. Properties which are composite and subset other composite non-derived property. Our solution - make it non-composite as element can't be owned in two places

 

 

I'm not sure all issues are reported, could someone help me manage that and check if all these are really must-be-fixed bugs?

Most of these issues may be verified by running automatic script on metamodel file.

 

See details below:

1) is composite, but does not subset ownedElement


Duration::expr:ValueSpecification [0..] is composite, but not ownedElement
 LinkEndData::qualifier:QualifierValue [0..*] is composite, but not ownedElement
 LinkAction::endData:LinkEndData [2..*] is composite, but not ownedElement
 TimeExpression::expr:ValueSpecification [0..] is composite, but not ownedElement
 ValuePin::value:ValueSpecification [1] is composite, but not ownedElement
 State::deferrableTrigger:Trigger [0..*] is composite, but not ownedElement
 CreateLinkAction::endData:LinkEndCreationData [2..*] is composite, but not ownedElement
 StructuredActivityNode::edge:ActivityEdge [0..*] is composite, but not ownedElement
 ValueSpecificationAction::value:ValueSpecification [1] is composite, but not ownedElement
 AcceptEventAction::trigger:Trigger [1] is composite, but not ownedElement
 DestroyLinkAction::endData:LinkEndDestructionData [2..*] is composite, but not ownedElement
 Stereotype::icon:Image [0..*] is composite, but not ownedElement
 TimeEvent::when:TimeExpression [1] is composite, but not ownedElement
 InteractionUse::argument:Action [0..*] is composite, but not ownedElement
 SequenceNode::executableNode:ExecutableNode [0..*] is composite, but not ownedElement
 Transition::trigger:Trigger [0..*] is composite, but not ownedElement
 StructuredActivityNode::node:ActivityNode [0..*] is composite, but not ownedElement

Resolution: This issue affects the Model Interchange Working Group (MIWG). Issue 1 is accepted: All properties which are composite, are made to subset ownedElement. Issue 2 is not accepted. It is acceptable for a composition to subset another composition. This does not lead to an element being owned in two places; it leads to an element being owned in one place by two links.
Revised Text: Clause 11 In figure 11.3, add {subsets ownedElement} to ValuePin::value. In 11.3.51, add �{Subsets Element::ownedElement}� to the description of value. In figure 11.8, add {subsets ownedElement} to LinkAction::endData. In 11.3.21, add �{Subsets Element::ownedElement}� to the description of endData. In figure 11.11, add {subsets ownedElement} to ValueSpecificationAction::value. In 11.3.52, add �{Subsets Element::ownedElement}� to the description of value. In figure 11.12, add {subsets ownedElement} to AcceptEventAction::trigger. In 11.3.2, add �{Subsets Element::ownedElement}� to the description of trigger. In figure 11.14, add {subsets ownedElement} to LinkEndData::qualifier. In 11.3.23, add �{Subsets Element::ownedElement}� after �List of qualifier values.� for the association qualifier. Clause 12 In figure 12.21, add {subsets ownedElement} to StructuredActivityNode::node. In 12.3.48, under association node, change �Subsets ActivityGroup::containedNode� to �Subsets ActivityGroup::containedNode and Element::ownedElement� In figure 12.22, add {subsets ownedElement} to StructuredActivityNode::edge. In 12.3.48, under association edge, change �Subsets ActivityGroup::containedEdge� to �Subsets ActivityGroup::containedEdge and Element::ownedElement� Clause 13 In figure 13.13, add {subsets ownedElement} to Duration::expr. In 13.3.9, add {Subsets Element::ownedElement} after �The value of the Duration� for the association expr. In figure 13.13, add {subsets ownedElement} to TimeExpression::expr. In 13.3.28, add {Subsets Element::ownedElement} after �The value of the time expression� for the association expr. In figure 13.13, add {subsets ownedElement} to TimeEvent::when. In 13.3.27, add {Subsets Element::ownedElement} after �Specifies the corresponding time deadline� for the association when. Clause 14 In figure 14.9, add {subsets ownedElement} to InteractionUse::argument. In 14.3.18, add {Subsets Element::ownedElement} to the description of argument. Clause 15 In figure 15.2, add {subsets ownedElement} to State::deferrableTrigger and to Transition::trigger. In 15.3.11, add {Subsets Element::ownedElement} to the description of deferrableTrigger. In 15.3.14, add {Subsets Element::ownedElement} to the description of trigger Clause 18 In figure 18.2, add {subsets ownedElement} to Stereotype::icon. In 18.3.8, add {Subsets Element::ownedElement} to the description of icon. Infrastructure Clause 13 In figure 13.2, add {subsets ownedElement} to Stereotype::icon. In 13.1.8, add {Subsets Element::ownedElement} to the description of icon. Add all of these subsetting constraints to the metamodel.
Actions taken:
January 7, 2010: received issue
April 25, 2011: closed issue

Issue 14931: remove BehavioredClassifier::ownedTrigger (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

can someone explain what is the purpose of "ownedTriggers" in BehavioredClassifier (page 435 of UML 2.3 spec) and how it should be used?
There is nothing in the spec about it. The description is : "References Trigger descriptions owned by a Classifier".
 
If it is intended to be container (or filter) of event types which can be consumed by this classifier behaviors, maybe it should be derived (from all owned behaviors)? 
The samantics section talks about "event pool" of the object at runtime, is it related?

Resolution: In general, the event pool of an object holds events that may be dispatched to triggers of that object. However, those triggers are generally part of a state machine or activity related to the object (either as its type or as a classifier behavior of its type). The specification does not describe what the semantics of dispatching an event directly to an ownedTrigger is, since there is not response behavior associated with such triggers. And a trigger directly owned by a behaviored classifier cannot also be owned in the normal way by a state machine or activity. Indeed, it is not clear that owned triggers have any purpose in UML 2 as it stands, and their inclusion without any explicit semantics is confusing. Therefore, it is agreed that BehavioredClassifier::ownedTrigger should be removed.
Revised Text: In Figure 13.11, remove BehavioredClassifier and Classifier from the diagram, and remove the association between BehavioredClassifier and Trigger from both the diagram and the metamodel. In Subclause 13.3.4 BehavioredClassifier, under Associations, remove the heading Package Communications and the entry for ownedTrigger.
Actions taken:
January 8, 2010: received issue
April 25, 2011: closed issue

Issue 14960: UML is vague about which Element should own Comments (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

For example, if a comment appears on a Class diagram for a Package and is attached to one of the classes then should it be owned by the Class or the Package?

What if there is no Package shown and it is attached to several Classes from multiple Packages?

Resolution:
Revised Text:
Actions taken:
January 12, 2010: received issue
April 25, 2011: closed issue

Discussion:

A Comment can be owned by any Element, and can annotate any number of other elements. UML does not specify any notation that distinguishes the element that owns a comment from the elements it might annotate since only annotation notation is supported.
When a Comment is created, it must be (eventually) owned by some Element, or it would not be part of the Model. Since there is no notation for specifying comment ownership, different tools might take a different approach to ownership. Some might set the ownership to the first element that the comment annotates. Others might set the ownership to the element the Comment is placed in when it is initially created, before being attached.
There is a potential issue that different tools placing the comment in different owners would result in model interchange issues since the XMI would be different. But this is not actually the case. Regardless of what owner a tool uses for a Comment, any other importing tool should use the same owner, and preserve it on XMI export. The fact that two tools result in different XMI does not mean the XMI is invalid.
I do not see this as a spec issue; UML intentionally avoids imposing methodological rules. It seems that the choice of which element owns a given comment is one that should be left up to the modeler.
If the issue is one of not being able to tell in a diagram which element owns a particular comment (e.g., it seems to be �floating� unattached in some diagram), then the tool can help by making this information visible in its browser or by responding to a query.
Disposition: Closed, no change

Issue 14961: Unclear constraint on stereotype associations (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

18.3.3 Semantics contains the following:

�Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is 

owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by 

the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than 

the other class/metaclass.�

However this is not represented in a formal Constraint and the last sentence in particular is not relevant to associations between 2 stereotypes.

Resolution: The offending paragraph is actually in 18.3.6, not 18.3.3 as stated in the issue. There are two aspects to the resolution: rewording of the paragraph, and adding a formal constraint. The paragraph is clearly (through the repeated use of the word �opposite�) intended to convey that stereotypes can participate in binary associations. This is consistent with the corresponding limitation in MOF. The rewording recognizes this.
Revised Text: Replace the offending paragraph in 18.3.6 by the following: �Stereotypes can participate in binary associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass.� Add the following constraints under 18.3.8 Stereotype � Constraints: [3] Stereotypes may only participate in binary associations. ownedAttribute->select( not association->isEmpty())-> collect(association)-> forAll(memberEnd->size() = 2) [4] Where a stereotype?s property is an association end, and the other end is not a stereotype, the other end must be owned by the association itself. ownedAttribute->select(not association->isEmpty() and not type.OclIsKindOf(Stereotype))-> forAll(opposite.owner = association)
Actions taken:
January 12, 2010: received issue
April 25, 2011: closed issue

Issue 14963: Context of a behavior owned as a nested classifier (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

Subclause: 13.3.2 Behavior

 

Since a behavior is a classifier, and a class is a behaviored classifier, it is possible for a class to own a behavior either as an ownedBehavior (inherited from BehavioredClassifier), or as a nestedClassifier (defined specifically for Class). The intended semantics of nestedClassifier is simply that a classifier is a member of the owning class as a namespace. On would not expect this to imply the additional semantics given later for owned behaviors.

 

However, the derivation for Behavior::context is based on the ownership of the behavior, directly or indirectly, by a behaviored classifier, regardless of how this ownership happens. Thus it would seem that a behavior owned as a nestedClassifier would have the owning class as its context, even though it is not an ownedBehavior. It would seem better to have behaviors owned as nestedClassifiers not have the owner as a context, allowing normal visibility rules to apply for access from within the behavior to elements of its owning namespace

Resolution: See issue 14964 for disposition
Revised Text:
Actions taken:
January 12, 2010: received issue
April 25, 2011: closed issue

Issue 14964: Definition of Behavior::context is not correct (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

Subclause: 13.3.2 Behavior

 

Behavior::context is a derived association, with its derivation given by: 

 

�If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships. For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine.�

 

However, an entry behavior is owned by a state which is owned by a region which must be owned (directly or indirectly) by a state machine. But a state machine is a behavior, which is a class, which is a behaviored classifier. Therefore, by the given algorithm, it is the state machine that is the context of the entry behavior, not the owner of the state machine, even if the state machine is a classifier behavior.

 

This is a serious problem, since the definition for Behavior::context further says �The features of the context classifier as well as the elements visible to the

context classifier are visible to the behavior.� And it is generally assumed in state machine modeling that an entry behavior in a state machine that is a classifier behavior has visibility to the elements of the owner of the state machine. Similarly, the semantics of a read self action is determined by the context of the activity that contains that action, and if that activity is the entry behavior of a state machine that is a classifier behavior, then the result of this action should be the owner of the state machine, not the state machine.

 

In summary, the second sentence given in the first quote above seems to be the true intent of Behavior::context. The first sentence should be changed to:

 

�To determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.�

Resolution: Agreed, except that a slight change to the proposed text will also resolve Issue 14963
Revised Text: In Subclause 13.3.2, under Associations, in the description of �context�, replace the sentence �If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships.� with: A Behavior that is directly owned as a nestedClassifier does not have a context. Otherwise, to determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.
Actions taken:
January 12, 2010: received issue
April 25, 2011: closed issue

Issue 14977: Matching subsettting across association ends (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

What�s our position about matching subsetting across association ends?  I�m looking, for example, at the property Extend::Extension.  This subsets source; but its other end subsets ownedMember.  This clearly implies that Extend::Extension also subsets namespace (and owner); and the ownerMember end should also subset ownedElement.

 

There are plenty of examples of this all over the spec.

 

It would be nice to get this right for 2.4.  Is this something we�ve already identified?

Resolution: The following OCL query is designed to find all associations that have asymmetric subsetting of their association ends: https://dev.enterprisecomponent.com/repository/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/associationsWithAsymmetricSubsetting.ocl For the UML 2.4 metamodel created from the UML 2.3 metamodel, this query found 182 cases of asymmetric subsetting. Here is a proof that subsetting is symmetric (refer to fig 16.2 for the example, but the proof applies to any example): Consider UseCase u and Extend e, such that u ? e.extension. Then e ? u.extend [because of association invariant: c2 ? c1.p implies c1 ? c2.(p.opposite)] It is given that e ? u.ownedMember [ because extend subsets ownedMember ] Therefore u ? e.namespace [ because of association invariant ] Hence u ? e.extension implies u ? e.namespace, i.e. extension subsets namespace. For a redefined association end, the redefinition means that the same set of links are traversed by the redefining property as the redefined property. The same set of links is a special case of subsetting, and the argument then follows as for subsetting. (See 14993 which is resolved as a duplicate of this). Where classes and associations have needed to be copied down into a package in order to enable these changes, it has been done. We minimize changes to the current specification diagrams and text by applying the following rules: - Where a subsetted property is owned by an association, it is not shown in either diagram or text. - Where a subset constraint can be deduced, it does not need to be shown in the diagrams or text. - Redundant subsetted properties whose presence can be inferred from others, that are currently in the diagrams and/or text, are left there. We anticipate that a future version of UML may apply different conventions to its diagrams to make it simpler to reason about property subsetting. The vast majority of the changes involved in this resolution only occur in the metamodel and XMI, where missing subset constraints have been introduced. In a few cases documented in this resolution, changes are needed to the diagrams and text to show where metaclasses and/or associations are introduced into a package to make the model merge correctly. Changes are also needed to the diagrams and text wherever a material �subsets� statement is absent.
Revised Text: see pages 106 - 136 of ptc/2011-01-19
Actions taken:
January 14, 2010: received issue
April 25, 2011: closed issue

Issue 14993: UML 2: property redefinitions should be symmetric across associations (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

When one end of an association is redefined in the metamodel, the other end should be redefined as well.  Otherwise the semantics are ill-defined.

Resolution: See issue 14977 for disposition
Revised Text:
Actions taken:
January 20, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15006: serialization of a profile should always include the nsURI and nsPrefix tags (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML Superstructure Specification (in Subclause 18.3.6) says that the

serialization for a profile "should" (not "shall") specify the values for the

nsURI and nsPrefix XMI tags and makes recommendations for what these values

should be. However, this is not normative and "the exact specification of these

tags is a semantic variation point".

 

For the purposes of maximizing successful interchange, however, the

serialization of a profile should always include the nsURI and nsPrefix tags,

set as recommended in the specification. The serialization of any application

of such a profile must then use the recommended forms for the URI and namespace

prefix for any stereotype applications.

Resolution: The offending paragraph is altered to make the nsURI and nsPrefix tags mandatory. Also phrases such as �CMOF package corresponding to the� is deleted because we are not serializing a CMOF package; we are serializing a profile as a UML model. We do not make the format of the tags mandatory, because organizations are at liberty to create their own formats for proprietary profiles, as long as they follow XMI rules. The XMI examples are modified to be up to date and to follow the rules, in resolution 14448.
Revised Text: Replace the following paragraph in 18.3.6: <start> The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to the Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A recommended convention is: nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with . (dot) substituted for ::, and all other illegal XML QName characters removed, and � <profileName> is the name of the Profile, � nsPrefix = <profileName>, � all others use the XMI defaults. <end> By the following: <start> The serialization of the Profile shall also include values for CMOF Tags in order to control the XMI generation. OMG normative profiles, such as those described in Annex H, follow an OMG normative naming scheme. For non-standard profiles a recommended convention is: nsURI = http://<profileParentQualifiedName>/<version>/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with / (forward slash) substituted for ::, and all other illegal XML QName characters removed, � <version> is a version identifier (note that for OMG normative profiles this is a date in the format YYYYMMDD) � <profileName> is the name of the Profile, nsPrefix = <profileName>. <end>
Actions taken:
January 25, 2010: received issue
April 25, 2011: closed issue

Issue 15125: UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XMI for A_redefinitionContext_redefinableElement is this:

 

<ownedMember xmi:type="cmof:Association" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier" name="A_redefinedClassifier_classifier" memberEnd="Classes-Kernel-Classifier-redefinedClassifier Classes-Kernel-A_redefinedClassifier_classifier-classifier"> 
        <ownedEnd xmi:type="cmof:Property" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier-classifier" name="classifier" type="Classes-Kernel-Classifier" upper="*" lower="0" owningAssociation="Classes-Kernel-A_redefinedClassifier_classifier" association="Classes-Kernel-A_redefinedClassifier_classifier"/> 
</ownedMember>

 

In the spec, classifier is shown as {subsets redefinitionContext}.  This is missing from the XMI.

Resolution: See issue 14977 for disposition
Revised Text:
Actions taken:
March 10, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15126: UML2.3 definition of Classifier::hasVisibilityOf is circular (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

If we consider class A inherits from class B, and we have an instance of A called a, and a property in B called p.  Let�s calculate the visibility of p in a, assuming p is private.  I�m doing substitutions, a bit loosely, but you�ll get the point.

 

a::hasVisibilityOf(p) : Boolean  if (a.inheritedMember->includes(p)) then hasVisibilityOf = false else hasVisibilityOf = true 

-> we need to calculate a.inheritedMember

 

a.inheritedMember->includesAll(a.inherit( {B.inheritableMembers(a) } ))

-> we need to calculate B.inheritableMembers(a)

 

B.inheritableMembers(a) = {p}->select(m | a.hasVisibilityOf(m))  �. a.hasVisibilityOf(p)

-> we are in a loop!

Resolution: See issue 10006 for disposition
Revised Text:
Actions taken:
March 10, 2010: received issue
April 25, 2011: closed issue

Issue 15128: Association owned derived union (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Maged Elaasar, melaasar(at)ca.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is it really illegal to define a non-navigable association-owned property as derived union?

When I try that I invalidate the following constraint in section 7.3.44 the metamodel:

[6]Only a navigable property can be marked as readOnly.
isReadOnly implies isNavigable()

Why "efficiency of access" (as implied by navigability) restrics read-only access?

One way to get around that is to make the property owned in the "navigableOwnerEnd" vs. "ownedEnd" of the association? do we have any precedence of doing that in an abstract syntax?

Resolution: This constraint seems to be an old constraint from UML 1.x when navigability meant the same as ownership of property. It is not consistent with the meaning of navigability now, which is about �efficiency of access�.
Revised Text: In UML Superstructure 2.3, clause 7.3.44 (Property), under Constraints: Remove: [6]Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() In UML Infrastructure 2.3, clause 11.3.5 (Property), under Constraints: Remove: [6]Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable()
Actions taken:
March 22, 2010: received issue
April 25, 2011: closed issue

Issue 15136: MessageEvents (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Could you guys shed some light in this area?
Every tool vendor has different ideas (and implementation) what event types should be used at message ends for call message, reply message, create message or destroy message.

Resolution: See issue 14629 for disposition
Revised Text:
Actions taken:
March 9, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15208: Invalid type for Slot.value (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

For Slot there is:


value : InstanceSpecification [*]


when it should be

value : ValueSpecification [*]

Resolution: See issue 10005 for disposition
Revised Text:
Actions taken:
April 19, 2010: received issue
April 25, 2011: closed issue

Issue 15209: Invalid type for NamedElement.namespace (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

For NamedElement there is:


namespace: NamedElement [0..1]


when it should be

namespace: Namespace [0..1]

Resolution:
Revised Text:
Actions taken:
April 19, 2010: received issue
April 25, 2011: closed issue

Discussion:

It is Namespace in 2.3 so must have been fixed earlier.
Disposition: Closed, no change

Issue 15263: UML 2 issue - misleadingly named associations (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The association between Package and Stereotype called �A_ownedStereotype_profile� is misleadingly named.  It should be called �A_ownedStereotype_package�.

 

The association between BehavioredClassifier and Behavior called �A_ownedParameter_behavioredClassifier� is misleadingly named. It should be called �A_ownedBehavior_behavioredClassifier�.

Resolution: Make the changes as suggested.
Revised Text: There is no change to the text or diagrams. The A_ownedStereotype_package association now appears in the Infrastructure::Profiles metamodel. The A_ownedBehavior_behavioredClassifier association now appears in the CommonBehavior metamodel.
Actions taken:
May 25, 2010: received issue
April 25, 2011: closed issue

Issue 15264: Resolution to issue 14063 (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Accepted resolution in UML 2.4 Ballot 8 for issue 14063 has a problem because ActivityGroup::inActivity needs to refer to StructuredActivities::Activity

Resolution: The accepted resolution for 14063 in Ballot 8 states the following: �In the UML 2.3 Superstructure Specification, Subclause 12.2 Abstract Syntax, in Figures 12.21 and 12.22, replace the unqualified ActivityGroup classes on the diagrams with the qualified UML::Activities::FundamentalActivities::ActivityGroup class. Remove the StructuredActivities::ActivityGroup and CompleteStructuredActivities::ActivityGroup classes from the metamodel.� The problem is that ActivityGroup in StructuredActivities refers, via its property inActivity, to Activity in StructuredActivities. Removing StructuredActivities::ActivityGroup deprives this property of a home. Hence we need to reinstate the copies of ActivityGroup. Then we also need to copy down Action into CompleteStructuredActivities, and its associations input and output, so that the structuredNodeInput {subsets input} and structuredNodeOutput { subsets output} work correctly, i.e. subset the correct types of InputPin and OutputPin. Note than none of this will have any effect on the merged definition of UML.
Revised Text: Reinstate the metaclass ActivityGroup to be as it was in UML 2.3, i.e. reverse the effects of 14063: leave ActivityGroup in both StructuredActivities and CompleteStructuredActivities. In figure 12.22, replace the qualified UML::Actions::BasicActions::Action class with an unqualified Action class. Show compositions Action::/input * {readOnly, union} and Action::/output *{readOnly, union} on 12.22, with opposite non-navigable ends called action 0..1, targeting InputPin and OutputPin respectively. Add an Action class to CompleteStructuredActivities in the metamodel, and add the compositions to InputPin and OutputPin to the same package. Change the title of 12.3.2 to be: 12.3.2 Action (from CompleteActivities, FundamentalActivities, StructuredActivities, CompleteStructuredActivities) Under the Associations section of 12.3.2 add a new subsection as follows: Package CompleteStructuredActivities ? /input : InputPin [*] The ordered set of input pins connected to the Action. ? /output : OutputPin [*] The ordered set of output pins connected to the Action.
Actions taken:
May 25, 2010: received issue
April 25, 2011: closed issue

Issue 15265: UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine.  In particular, Behavior::redefinedBehavior should subset Classifier::redefinedClassifier, not Element::redefinedElement; and StateMachine::extendedStateMachine should subset Classifier::redefinedClassifier, not Element::redefinedElement.  These are exactly analogous to the problem raised in issue 14554.

Resolution: Make the suggested changes.
Revised Text: In figure 13.6 change {subsets redefinedElement} to {subsets redefinedClassifier}. In 13.3.2 Behavior::redefinedBehavior, change Subsets RedefineableElement::redefinedElement to Subsets Classifier::redefinedClassifier. In figure 15.3 change {subsets redefinedElement} to {subsets redefinedClassifier}. In 15.3.12 StateMachine::extendedStateMachine, change Subsets RedefineableElement::redefinedElement to Subsets Classifier::redefinedClassifier.
Actions taken:
May 25, 2010: received issue
April 25, 2011: closed issue

Issue 15266: Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied. (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:


13330, resolved in UML 2.3, was not correctly applied to the specification diagrams. The following instructions were not carried out: 

Show the association name label in Figure 17.18

Show the association name label in Figure 17.29

Show the association name label in Figure 17.30

 

Perhaps as a consequence of this, 14287 in 2.4 should have been resolved as a dup of 13330, not as an inconsistent set of changes.

Resolution: Do not make the changes to association names as proposed in 13287. Instead, leave the names as resolved in 13330 and in the UML 2.3 metamodel. Show the names in the diagrams as specified by 13330.
Revised Text: Show the association name label in Figure 17.18 A_classifier_templateParameter_parameteredElement Show the association name label in Figure 17.29 A_operation_templateParameter_parameteredElement Show the association name label in Figure 17.30 A_connectableElement_templateParameter_parameteredElement
Actions taken:
May 26, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15267: UML2 Issue: OCL in resolution 11114 is incorrect (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL is the resolution is:

self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

It has two problems:

1- It is missing a closing ")" needed to balance the brackets, correcting this yields

self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))))

2- the "collect" operation above returns a Bag, and since "inherit" operation expects a Set as input, the cast "toSet()" is needed, correcting this yields:

self.inheritedMember->includesAll(self.inherit( self.parents()->collect(p | p.inheritableMembers(self))->asSet() ))

Resolution: As the summary says
Revised Text: Replace the Classifier constraint in both infrastructure (9.19.1 constraint [3]) and superstructure (7.3.8 constraint [4]) by self.inheritedMember->includesAll(self.inherit( self.parents()->collect(p | p.inheritableMembers(self))->asSet() ))
Actions taken:
May 26, 2010: received issue
April 25, 2011: closed issue

Issue 15269: UML 2.3, Figure 18.1 (uml2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2.3, Figure 18.1 shows that InfrastructureLibrary::Profiles imports InfrastructureLibrary::Core::Constructs; however, this relationship should be a merge, not an import because:
1) the InfrastructureLibrary::Profiles package adds merge increments to several metaclasses from Core::Constructs, e.g., Class, Package.
2) the InfrastructureLibrary::Profiles package copies metaclasses from Core::Constructs without adding any content, e.g., NamedElement.


Although UML merges Profiles at L2, the use of (1) and (2) requires a package merge relationship betwen Profiles & Constructs to reflect the intended semantics of merge increment for (1) and copy-down for (2).


Resolution:


Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in:
- figure 13.1 of the infrastructure specification
- the infrastructure metamodel
- figure 18.1 of the superstructure specification.

Resolution: as suggested
Revised Text: Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in: - figure 13.1 of the infrastructure specification - the infrastructure metamodel - figure 18.1 of the superstructure specification.
Actions taken:
May 27, 2010: received issue
April 25, 2011: closed issue

Issue 15281: 'false' is not a member of VisibilityKind (uml2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

under Attributes -
visibility: VisibilityKind [1]
Default value is false.

'false' is not a member of VisibilityKind. I assume 'private' is intended, though I notice some tools have gone for 'public'.

Resolution:
Revised Text:
Actions taken:
June 7, 2010: received issue
April 25, 2011: closed issue

Discussion:

See issue 10379 for disposition

Issue 15369: UML 2.4: Add Property::isId (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

Regardless of MOF, it is a fundamental capability missing from UML in being able to model various data structures for languages such as SQL and XML Schema which all have the notion of identifier.

Although MOF restricts classes to have only one Property with isId = true, for generality the proposal does not restrict this in UML.

 

Should this issue be applied to UML, a mirror issue will be applied to MOF.

 

Proposed Resolution:

Superstructure

Add the following to the Attributes section of 7.3.44, Property:

isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

 

Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading �Package AssociationClasses�:

A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included. 

 

Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property:

�redefines� <property-name> | �ordered� | �unique� | �nonunique� | <prop-constraint>

            With:

�redefines� <property-name> | �ordered� | �unique� | �nonunique� | �id� | <prop-constraint>

            Add the following line before that defining <prop-constraint>:

�         id means that the property is part of the identifier for the class

 

Update Figure 7.12 to include isID : Boolean[0..1] in class Property

 

Update the definition of the attribute �qualifiedName� in section 7.3.33, NamedElement, from:

/ qualifiedName: String [0..1]  

            To:

/ qualifiedName: String [0..1]  {id}

 

Infrastructure

Add the following to the Attributes section of 10.2.5, Property:

isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

 

Add the following to the end of the Semantics section of 10.2.5, Property:

A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included. 

 

Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property:

�redefines� <property-name> | �ordered� | �unique� | <prop-constraint>

            With:

�redefines� <property-name> | �ordered� | �unique� | �id� | <prop-constraint>

Add the following line before that defining <prop-constraint>:

�         id means that the property is part of the identifier for the class

 

 

Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property

Resolution: Add the proposed property.
Revised Text: Superstructure Add the following to the Attributes section of 7.3.44, Property: ? isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class. Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading �Package AssociationClasses?: A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included. Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property: �redefines? <property-name> | �ordered? | �unique? | �nonunique? | <prop-constraint> With: �redefines? <property-name> | �ordered? | �unique? | �nonunique? | �id? | <prop-constraint> Add the following line before that defining <prop-constraint>: ? id means that the property is part of the identifier for the class Update Figure 7.12 to include isID : Boolean[0..1] in class Property Infrastructure Add the following to the Attributes section of 10.2.5, Property: ? isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class. Add the following to the end of the Semantics section of 10.2.5, Property: A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included. Add the following to the Attributes section of 11.3.5, Property: ? isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class. Add the following to the end of the Semantics section of 11.3.5, Property: A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included. Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property: �redefines? <property-name> | �ordered? | �unique? | <prop-constraint> With: �redefines? <property-name> | �ordered? | �unique? | �id? | <prop-constraint> Add the following line before that defining <prop-constraint>: ? id means that the property is part of the identifier for the class Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property
Actions taken:
July 13, 2010: received issue
April 25, 2011: closed issue

Issue 15370: UML 2.4: Add package:URI (uml2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

Regardless of MOF, it has been requested that UML have ability to uniquely reference external elements in order to support:

Federated models

References to libraries of datatypes

Profiles

At the moment, although XMI does support such references, there is no way in the model itself, to specify the URI that should be used.

This has been a specific problem for Profile definition where there is no standard way in UML to specify the URI to be used for XMI interchange.

 

Proposed Resolution:

Superstructure

Add the following to the Attributes section of 7.3.77, Package:

URI: String [0..1] {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique 

identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

.

Add the following to the end of the Semantics section of 7.3.77, Package:

The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .

 

Add the following to the end of the Notation section of 7.3.77, Package:

The URI for a Package may be indicated with the text {uri=<uri>} following the package name.

 

            Update Figure 7.63 to add the following under the word Types in the middle package example:

                                    {uri=http://www.abc.com/models/Types}

 

Update Figure 7.14 to include URI: String {id} in class Package

 

            Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows:

Replace:

The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to 

Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

recommended convention is:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi 

where:

�  <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

(dot) substituted for ::, and all other illegal XML QName characters removed, and

� <profileName> is the name of the Profile,

� nsPrefix = <profileName>,

� all others use the XMI defaults.

With:

For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The  name attribute of the Profile is used for the nsPrefix in XMI.

 

Infrastructure

Add the following to the Attributes section of 11.9.2, Package:

URI: String [0..1] {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique 

identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

.

Add the following to the end of the Semantics section of 11.9.2, Package:

The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .

 

Add the following to the end of the Notation section of 11.9.2, Package:

The URI for a Package may be indicated with the text {uri=<uri>} following the package name.

 

            Update Figure 11.27 to add the following under the word Types in the middle package example:

                                    {uri=http://www.abc.com/models/Types}

 

Update Figure 11.26 to include URI: String {id} in class Package

 

            Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows:

Replace:

The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to 

Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

recommended convention is:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi 

where:

�  <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

(dot) substituted for ::, and all other illegal XML QName characters removed, and

� <profileName> is the name of the Profile,

� nsPrefix = <profileName>,

� all others use the XMI defaults.

With:

For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The  name attribute of the Profile is used for the nsPrefix in XMI.

Resolution: Add the proposed property.
Revised Text: Superstructure Add the following to the Attributes section of 7.3.77, Package: URI: String [0..1] {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules. Add the following to the end of the Semantics section of 7.3.77, Package: The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted). Add the following to the end of the Notation section of 7.3.77, Package: The URI for a Package may be indicated with the text {uri=<uri>} following the package name. Update Figure 7.63 to add the following under the word Types in the middle package example: {uri=http://www.abc.com/models/Types} Update Figure 7.14 to include URI: String {id} in class Package Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows: Replace: The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A recommended convention is: nsURI = http://<profileParentQualifiedName>/<version>/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with (dot) substituted for ::, and all other illegal XML QName characters removed, and � <profileName> is the name of the Profile, � nsPrefix = <profileName>, � all others use the XMI defaults. With: For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. [Note: by default the name attribute of the Profile is used for the nsPrefix in XMI but this can be overridden by the CMOF tag org.omg.xmi.nsPrefix]. OMG normative profiles, such as those described in Annex H, follow an OMG normative naming scheme for URIs. For non-standard profiles a recommended convention is: uri = http://<profileParentQualifiedName>/<version>/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with / (forward slash) substituted for ::, and all other illegal XML QName characters removed, � <version> is a version identifier (note that for OMG normative profiles this is a date in the format YYYYMMDD), � <profileName> is the name of the Profile, � nsPrefix = <profileName> Infrastructure Add the following to the Attributes section of 10.4.1, Package: URI: String [0..1] {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules. . Add the following to the end of the Semantics section of 10.4.1, Package: The URI can be specified to provide a unique identifier for a Package. Add the following to the Attributes section of 11.9.2, Package: URI: String [0..1] {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules. . Add the following to the end of the Semantics section of 11.9.2, Package: The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles. It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted). Add the following to the end of the Notation section of 11.9.2, Package: The URI for a Package may be indicated with the text {uri=<uri>} following the package name. Update Figure 11.27 to add the following under the word Types in the middle package example: {uri=http://www.abc.com/models/Types} Update Figure 11.26 to include URI: String {id} in class Package Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows: Replace: The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A recommended convention is: nsURI = http://<profileParentQualifiedName>/<version>/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with (dot) substituted for ::, and all other illegal XML QName characters removed, and � <profileName> is the name of the Profile, � nsPrefix = <profileName>, � all others use the XMI defaults. With: For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. [Note: by default the name attribute of the Profile is used for the nsPrefix in XMI but this can be overridden by the CMOF tag org.omg.xmi.nsPrefix]. OMG normative profiles, such as those described in Annex H, follow an OMG normative naming scheme for URIs. For non-standard profiles a recommended convention is: uri = http://<profileParentQualifiedName>/<version>/<profileName>.xmi where: � <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with / (forward slash) substituted for ::, and all other illegal XML QName characters removed, � <version> is a version identifier (note that for OMG normative profiles this is a date in the format YYYYMMDD), � <profileName> is the name of the Profile, � nsPrefix = <profileName>
Actions taken:
July 13, 2010: received issue
April 25, 2011: closed issue

Issue 15378: UML 2.4: Inconsistent rendering of OCL in UML metamodel (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature:
Severity:
Summary:

This is a UML 2.4 issue please:

 

Inconsistent rendering of OCL in UML metamodel.

 

According to the conventions mostly applied in the UML metamodel, the specifications of the body conditions of operations have the form �result = <OCL expression>� and the operation is specified to have a return parameter named �result�.  Invariants, pre- and post-conditions, on the other hand, are simply Boolean expressions with no �result = �.  Note that many invariants are specified in OCL as �true�, being placeholders for invariants that are currently only specified in text.  There are some placeholder operations, for which the specification should be �result = <default value for the type of result>�, i.e. result = false, result = 0, or result = null.

 

Applying these conventions consistently will greatly enable future generation of specification documents.  This means making the following changes:

 

All operations in the metamodel should be changed to have a return parameter named �result�.

 

The following operation and constraint specifications should be changed as indicated by -changeto-:

 

InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf()

    �hasVisibilityOf = (n.visibility <> VisibilityKind::private)�   -changeto- �result = (n.visibility <> VisibilityKind::private)�

 

InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember()

    �self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet()))� -changeto- �result = self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet())�

 

UML::Classes::Kernel::Classifier::hasVisibilityOf()

    �hasVisibilityOf = (n.visibility <> VisibilityKind::private)�   -changeto- �result = (n.visibility <> VisibilityKind::private)�

 

UML::Classes::Kernel::Classifier::inheritedMember()

    �self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet()))� -changeto- �result = self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet())�

 

UML::Classes::Kernel::OpaqueExpression::value()

    �true� -changeto- �result = 0�

 

UML::Classes::Kernel::VisibilityKind::bestVisibility()

    �pre: not vis->includes(#protected) and not vis->includes(#package)� -changeto- �not vis->includes(#protected) and not vis->includes(#package)�

 

UML::Deployments::ComponentDeployments::DeploymentSpecification

  �result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))�  -changeto- �self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))�

 

UML::Deployments::Nodes::CommunicationPath

   �result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))� -changeto- �self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))�

 

UML::Interactions::Fragments::InteractionUse

   Two placeholder invariants specified as �N/A� �changeto- �true�

 

UML::StateMachines::BehaviorStateMachines::StateMachine::LCA()

   �true� � changeto- �result = null�

Resolution: Agree to the changes proposed in the summary, except for OpaqueExpression::value() and StateMachine::LCA(). For these operations the result is undefined so it is incorrect to return a defined result. Instead a body of true is actually correct: it is logically equivalent to result=result.
Revised Text: No changes are required to the specification diagrams. In Infrastructure 11.3.3 Classifier, change Constraint[3] from: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) to: inheritedMember = self.inherit(self.parents()->collect(p | p.inheritableMembers(self)) In Superstructure 7.3.8 Classifier, change Constraint[4] from: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) to: inheritedMember = self.inherit(self.parents()->collect(p | p.inheritableMembers(self)) In Superstructure 10.3.5 DeploymentSpecification constraint [1], change: self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment)) to: self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment)) (remove the redundant �.?). In the metamodel, change the name of the return parameter of ALL operations to be �result�. In the metamodel, make the following changes to operation bodies: InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf() Change �hasVisibilityOf = (n.visibility <> VisibilityKind::private)� to �result = (n.visibility <> VisibilityKind::private)� InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember() Change �self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet()))� to �result = self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet())� UML 2.4 RTF Disposition: Resolved OMG Issue No: 15378 Document ptc/2010-12-14 Page 156 UML::Classes::Kernel::Classifier::hasVisibilityOf() Change �hasVisibilityOf = (n.visibility <> VisibilityKind::private)� to �result = (n.visibility <> VisibilityKind::private)� UML::Classes::Kernel::Classifier::inheritedMember() Change �self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet()))� to �result = self.inherit(self.parents()->collect(p|p.inheritableMembers(self))->asSet())� In the metamodel, make the following changes to preconditions: UML::Classes::Kernel::VisibilityKind::bestVisibility() Change �pre: not vis->includes(#protected) and not vis->includes(#package)� to �not vis->includes(#protected) and not vis->includes(#package)� In the metamodel, make the following changes to invariants: UML::Deployments::ComponentDeployments::DeploymentSpecification Change �result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))� to �self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))� UML::Deployments::Nodes::CommunicationPath Change �result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))� to �self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))� UML::Interactions::Fragments::InteractionUse Change two placeholder invariants specified as �N/A� to �true�
Actions taken:
July 21, 2010: received issue
April 25, 2011: closed issue

Issue 15429: "isStatic" property of Feature no longer appears in any diagram (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

I noticed that the "isStatic" property of Feature no longer appears in any diagram. There may be others missing meta-attributes, but this is the one I detected. I realize that the XMI is the definitive spec of the metamodel, but, nonetheless, I think that the diagrams should be complete and not partial. Diagrams are for human readers and XMI for machines (unless, of course, you are Pete Rivett -- just kidding, Pete!).

Also, I am disappointed that you retained the practically useless notion of navigability in the metamodel, even though we now have the dot notation supported in diagrams. Given the fact that navigability is a run-time concept, I see no value in keeping it in the metamodel, which is, after all, a static definition. (But, I am pretty sure I will now be deluged with people who will try to convince me that navigability arrows are still useful (my response: no, they are not).)

Perhaps the "isStatic" problem can be fixed as an editorial fix prior to the meeting?

Resolution: Show the isStatic property. In addition, this is a systematic error, and there are other cases where the metamodel has content that does not show on any diagram.
Revised Text: Change diagrams 7.9 and 7.10 to show isStatic : Boolean as an attribute of Feature. Change diagram 7.11 to show the properties of Parameter: / default: String [0..1], direction: ParameterDirectionKind = in, and defaultValue, an association to ValueSpecification.
Actions taken:
August 25, 2010: received issue
April 25, 2011: closed issue

Issue 15438: xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element (uml2-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element. Was it intentional that the current UML format XMI files use MOF/2.4 and
XMI/2.4 in their namespaces, even though these namespaces won't actually be correct? There is also an error in the structure of the .xmi files. A non xmi:XMI root element has been used that includes a cmof:Tag element, which is incorrect. The following files are affected:
10-08-17.xmi
10-08-18.xmi
10-08-22.xmi
10-08-23.xmi
10-08-27.xmi
10-08-28.xmi
10-08-29.xmi
L0.merged.xmi
L1.merged.xmi
L2.merged.xmi
LM.merged.xmi


Example:
==> LM.merged.xmi <==
       </ownedComment>
     </ownedLiteral>
   </packagedElement>
   <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </uml:Package> Should be:
==> LM.merged.xmi <==
         </ownedComment>
       </ownedLiteral>
     </packagedElement>
   </uml:Package>
   <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </xmi:XMI>


I've also just noticed that the most recent package resolution added a property named "URI" rather than "uri", which is inconsistent with the old MOF property and is slightly unusual capitalisation for a property.
However that's a minor point.

Resolution: It was intentional to use the 2.4 namespaces, see 15530. Publish all of the xmi files that include cmof:Tag elements with a top-level XMI tag. Leave the property named URI as it is. Fix the profile XMI examples to conform to the normative specs.
Revised Text: In Infrastructure Annex A: XMI Serialization and Schema, delete all lines that refer to tag �org.omg.xmi.nsURI�. In Superstructure Annex G: XMI Serialization and Schema, delete the line that refers to tag �org.omg.xmi.nsURI�. If 15530 passes, when publishing all of the normative and non-normative files as specified by resolution 15530, publish all of them that include mofext:Tag elements with a top-level XMI tag. If 15530 does not pass, publish those normative XMI files that include cmof:Tag elements with a top-level XMI tag. If 15530 passes, in infrastructure 12.1.7 and superstructure 18.3.7, change the paragraph and the XMI example that starts: The first serialization below shows how the model in Figure 18.6 on page 676 (instance of the profile and UML2 metamodel) can be exchanged. Note that [version number] is a placeholder for the published normative version number of the referenced normative UML specification, which follows the format YYYYMMDD. <?xml version="1.0" encoding="UTF-8"?> <uml:Profile xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmlns:uml="http://www.omg.org/spec/UML/[version number]" xmi:id="id0" name="HomeExample" metamodelReference="id2"> To instead start: The first serialization below shows how the model in Figure 18.6 on page 676 (instance of the profile and UML2 metamodel) can be exchanged. Note that [UML version number], [MOF version number] and [XMI version number] are placeholders for the published normative version numbers of the referenced normative UML, MOF and XMI specifications respectively, which follow the format YYYYMMDD. <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmlns:xmi="http:// www.omg.org/spec/XMI/[XMI version number]" xmlns:mofext="http://www.omg.org/spec/MOF/[MOF version number]" UML 2.4 RTF Disposition: Resolved OMG Issue No: 15438 Document ptc/2010-12-14 Page 160 xmlns:uml="http://www.omg.org/spec/UML/[UML version number]"> <uml:Profile xmi:id="id0" name="HomeExample" metamodelReference="id2" URI="http://HomeExample/20101201/HomeExample.xmi"> And end: </uml:Profile> <mofext:Tag name="org.omg.xmi.nsPrefix" value="HomeExample"/> </xmi:XMI> And in the same places, change the XMI example: <?xml version="1.0" encoding="UTF-8"?> <xmi xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://www.omg.org/spec/UML/[version number]" xmlns:HomeExample="http://HomeExample/20101201/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="http://HomeExample/20101201/HomeExample.xmi#id0"/> </profileApplication> <packagedElement xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>  <HomeExample:Home xmi:id= "id4" base_Interface="id2"/> </xmi> To: <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmlns:xmi="http:// www.omg.org/spec/XMI/[XMI version number]" xmlns:uml="http://www.omg.org/spec/UML/[UML version number]" xmlns:HomeExample="http://HomeExample/20101201/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="http://HomeExample/20101201/HomeExample.xmi#id0"/> </profileApplication> <packagedElement xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>  <HomeExample:Home xmi:id= "id4" base_Interface="id2"/> </xmi:XMI> If 15530 does not pass, in infrastructure 12.1.7 and superstructure 18.3.7, change the XMI example that starts: <?xml version="1.0" encoding="UTF-8"?> <uml:Profile xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" UML 2.4 RTF Disposition: Resolved OMG Issue No: 15438 Document ptc/2010-12-14 Page 161 xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmlns:uml="http://www.omg.org/spec/UML/[version number]" xmi:id="id0" name="HomeExample" metamodelReference="id2"> To instead start: <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmlns:uml="http://www.omg.org/spec/UML/[UML version number]"> <uml:Profile xmi:id="id0" name="HomeExample" metamodelReference="id2" URI="http://HomeExample/20101201/HomeExample.xmi"> And end: </uml:Profile> <cmof:Tag name="org.omg.xmi.nsPrefix" value="HomeExample"/> </xmi:XMI> And in the same places, change the XMI example: <?xml version="1.0" encoding="UTF-8"?> <xmi xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://www.omg.org/spec/UML/[version number]" xmlns:HomeExample="http://HomeExample/20101201/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="http://HomeExample/20101201/HomeExample.xmi#id0"/> </profileApplication> <packagedElement xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>  <HomeExample:Home xmi:id= "id4" base_Interface="id2"/> </xmi> To: <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://www.omg.org/spec/UML/[UML version number]" xmlns:HomeExample="http://HomeExample/20101201/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="http://HomeExample/20101201/HomeExample.xmi#id0"/> </profileApplication> <packagedElement xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package> UML 2.4 RTF Disposition: Resolved OMG Issue No: 15438 Document ptc/2010-12-14 Page 162  <HomeExample:Home xmi:id= "id4" base_Interface="id2"/> </xmi:XMI>
Actions taken:
August 26, 2010: received issue
April 25, 2011: closed issue

Issue 15439: UML2.4: StandardProfileL2 & L3 are incomplete as delivered (uml2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

1) the deliverables below are not well formed; each of StandardProfileL2 and StandardProfileL3 below is missing a reference to the UML2.4 metamodel as a PackageImport element.


Filename: StandardProfileL2.xmi
Description: This file contains the XMI of the UML v2.4 Standard Profile L2 as an instance of UML 2.4 using XMI 2.1.
Doc Number (if any): ptc/2010-08-22
Normative: Yes
Dependencies: UML.xmi
URL: http://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi


 
Filename: StandardProfileL3.xmi
Description: This file contains the XMI of the UML v2.4 Standard Profile L3 as an instance of UML 2.4 using XMI 2.1.
Doc Number (if any): ptc/2010-08-23
Normative: Yes
Dependencies: UML.xmi
URL: http://www.omg.org/spec/UML/20100901/StandardProfileL3.xmi


2) the inventory is missing the StandardProfileL2 & StandardProfileL3 as an instance of UML2.4 using XMI2.4.


The artifacts on the UML2.xRTF SVN for StandardProfileL2/L3 as UML2.4/XMI2.4 have the same problem as the artifacts in (1).

Resolution: agreed
Revised Text: If 15530 passes, publish the standard profiles as MOF2.4/XMI2.4 as per resolution 15530. In any case, in both profiles include the PackageImport reference to the UML metamodel
Actions taken:
August 30, 2010: received issue
April 25, 2011: closed issue

Issue 15526: Missing subsetting of redefinitionContext by Property::owningAssociation (uml2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: UML Superstructure version 2.4 (ptc/2010-08-02)

Subclause: 7.3.45 Property

 

In Subclause 7.3.45, the description of Property::owningAssociation indicates that it subsets RedefinableElement::redefinitionContext. However, this is not shown in Figure 7.12. This subsetting relationship is necessary if an owned end of an association is to be able to redefine the ends of parent associations.

 

Since this is a metamodel error, it should be fixed in UML 2.4.

Resolution: agreed
Revised Text: Show Property::owningAssociation subsetting RedefinableElement::redefinitionContext in figure 7.12. Make the corresponding metamodel change.
Actions taken:
September 14, 2010: received issue
May 12, 2011: closed issue

Issue 15529: The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake.  It specified deleting the import from InfrastructureLibrary::Core::Abstractions to PrimitiveTypes.  This is incorrect.  Instead it should have specified retargeting the import from InfrastructureLibrary::Core::Abstractions to the new PrimitiveTypes package, to be consistent with the new figure 7.3.

Resolution:
Revised Text: Where the current resolution to 13993 says this: 2- Delete the following relationships from the models: UML::Classes::Kernel::<PackageMerge to PrimitiveTypes> L0::<PackageMerge to PrimitiveTypes> LM::<PackageMerge to PrimitiveTypes> InfrastructureLibrary::Core::Abstractions::<PackageImport to PrimitiveTypes> 3- Change the following PackageImport relations to point to the new PrimitiveTypes InfrastructureLibrary::Core::Profiles::<PackageImport to PrimitiveTypes> InfrastructureLibrary::Core::Constructs::<PackageImport to PrimitiveTypes> InfrastructureLibrary::Core::Basic::<PackageImport to PrimitiveTypes> Instead apply the following change: 2- Delete the following relationships from the models: UML::Classes::Kernel::<PackageMerge to PrimitiveTypes> L0::<PackageMerge to PrimitiveTypes> LM::<PackageMerge to PrimitiveTypes> 3- Change the following PackageImport relations to point to the new PrimitiveTypes InfrastructureLibrary::Core::Profiles::<PackageImport to PrimitiveTypes> InfrastructureLibrary::Core::Constructs::<PackageImport to PrimitiveTypes> InfrastructureLibrary::Core::Basic::<PackageImport to PrimitiveTypes> InfrastructureLibrary::Core::Abstractions::<PackageImport to PrimitiveTypes>
Actions taken:
September 16, 2010: received issue
April 25, 2011: closed issue

Issue 15530: UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format.

Resolution: Remove all of the cmof files from the published set of artifacts for UML 2.4. Instead, publish the following normative artifacts in MOF2.4/XMI2.4 format: Infrastructure.xmi Superstructure.xmi L0.xmi L1.xmi L2.xmi L3.xmi LM.xmi PrimitiveTypes.xmi UML.xmi (the merged L3 model) StandardProfileL2.xmi StandardProfileL3.xmi Also publish the following non-normative artifacts in MOF2.4/XMI2.4 format: L0.merged.xmi LM.merged.xmi L1.merged.xmi L2.merged.xmi Change all references to MOF 2 and XMI 2 in the specification text accordingly.
Revised Text: In Infrastructure and Superstructure: In section 3, normative references, change the bullet points that refer to MOF: ? OMG Specification formal/06-01-01, Meta Object Facility (MOF) Core, v2.0 changes to: ? OMG Specification formal/??-??-??, Meta Object Facility (MOF) Core, v2.4 and ? OMG Specification formal/07-12-01, Meta Object Facility(MOF) 2.0 XMI Mapping Specification, v2.1.1 changes to: ? OMG Specification formal/??-??-??, Meta Object Facility(MOF) 2.4 XMI Mapping Specification, v2.4 In section 6.1: Architectural Alignment and MDA Support, replace MOF 2.0 by MOF 2 (two occurrences). In Infrastructure: In Annex A: XMI Serialization and Schema, replace MOF 2.0 by MOF 2 (two occurrences). In Annex B: Support for Model Driven Architecture, replace MOF 2.0 by MOF 2 (two occurrences). In Superstructure: In Annex G: XMI Serialization and Schema, replace this sentence: UML 2 Superstructure models are serialized in XMI 2.1 according to the rules specified by the MOF 2.0/XMI Mapping Specification, v2.1 (OMG document formal/05-09-01). By this: UML 2 Superstructure models are serialized in XMI 2 according to the rules specified by the MOF 2 XMI Mapping Specification. Also in Annex G, replace MOF 2.0 by MOF 2. In Annex H: UML Compliance Level XMI Documents, replace the following sentence: XML uses XSD to validate instances of XML documents, and the MOF 2.0/XMI Mapping Specification, v2.1 specifies how these schema documents are derived for a given CMOF model. By this: XML uses XSD to validate instances of XML documents, and the MOF 2 XMI Mapping Specification specifies how these schema documents are derived for a given CMOF model. Change the list of Associated Normative Machine-Readable Files on the title page of the Infrastructure specification to list the following files: PrimitiveTypes.xmi Infrastructure.xmi L0.xmi LM.xmi UML 2.4 RTF Disposition: Resolved OMG Issue No: 15530 Document ptc/2010-12-14 Page 170 Change the list of Associated Normative Machine-Readable Files on the title page of the Superstructure specification to list the following files: PrimitiveTypes.xmi Infrastructure.xmi Superstructure.xmi L0.xmi L1.xmi L2.xmi L3.xmi LM.xmi UML.xmi StandardProfileL2.xmi StandardProfileL3.xmi Change the list of normative files listed in Superstructure Annex H to be URLs for the list of files above. Change the list of non-normative files listed in Superstructure Annex H to be URLs for the following: L0.merged.xmi LM.merged.xmi L1.merged.xmi L2.merged.xmi
Actions taken:
September 16, 2010: received issue
April 25, 2011: closed issue

Issue 15560: Message's signature is still derived property (in text only): (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

/signature:NamedElement[0..1] The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

Resolution: This is as a result of an incomplete application of resolution 14629, which was formulated slightly ambiguously.
Revised Text: In figure 14.4 remove the {readOnly} adornment for signature. In the metamodel set ReadOnly on Message::signature to false. In 14.3.18 replace /signature by signature by removing the leading /.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15561: DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

That means, it can't be set as message end of delete message (message with "cross" sign at end). Critical bug I think

Resolution: The following existing text describes the notation: The form of the line or arrowhead reflects properties of the message: � � Object deletion Message should end in a DestructionOccurrenceSpecification. This clearly implies that a DestructionOccurrenceSpecification must be a possible message end, so the issue is correct.
Revised Text: In the metamodel (BasicInteractions), make DestructionOccurrenceSpecification inherit from MessageOccurrenceSpecification, not OccurrenceSpecification. Remove DestructionOccurrenceSpecification from figure 14.2. Change figure 14.5 so that DestructionOccurrenceSpecification inherits from MessageOccurrenceSpecification. Change 14.3.6 Generalizations from �OccurrenceSpecification (from BasicInteractions)� on page 512 to �MessageOccurrenceSpecification (from BasicInteractions)� on page [XXX � currently 511].
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15562: DestructionOccurenceSpecification text in Semantics still refers to events (uml2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

 DestructionOccurenceSpecification text in Semantics still refers to events:
 "A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. "

Resolution: It should not refer to events.
Revised Text: Replace the semantics text in 14.3.6 that reads: A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. By A DestructionOccurrenceSpecification represents the destruction of the instance described by the lifeline that contains it.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15563: Association-owned association end name changes (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Kernel & Infrastructure:

 

A_member_namespace => A_member_memberNamespace

Change the association-owned association end from 'namespace' to 'memberNamespace'

 

Interactions::BasicInteractions

 

Change: 

A_sendEvent_message => A_sendEvent_endMessage

A_receiveEvent_message => A_receiveEvent_endMessage

 

 + association-owned association end: 'message' => 'endMessage'

Resolution: The reason for the first change can be understood by looking at figure 7.4. This shows importedMember subsets member. The other end of this association, non-navigable and un-named on the diagram, is called namespace in the metamodel. This needs, by symmetry, to subset the other end of the association A_member_namespace. That cannot be called namespace, because of the constraint �A Property cannot be subset by a Property with the same name�. Hence we change its name to member_Namespace, and change the association name to follow the convention. The second change is for similar reasons. It is actually reflected in the current figure 14.4 but the association name has not been changed to match, and the change has not been introduced in any existing resolution.
Revised Text: In the metamodel: Change A_member_namespace => A_member_memberNamespace Change the association-owned association end from 'namespace' to 'memberNamespace' Change A_sendEvent_message => A_sendEvent_endMessage Change A_receiveEvent_message => A_receiveEvent_endMessage Change the association-owned association end: 'message' => 'endMessage' In the specification: Show endMessage {subsets message} in figure 14.4 opposite sendEvent and receiveEvent.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15564: Fix 14977 vs. 14638 (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is an inconsistency between 14977 and 14638 that results in inconsistent association end subsets due to incomplete copy-down from Kernel to InternalStructures.

The resolution is to introduce 2 new generalizations

Resolution: The generalizations that need to be added are between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. This enables the ends of A_ownedConnector_structuredClassifier to subset all the things they need to, especially redefinitionContext/redefinableElement. This becomes obvious when you look at the draft figure 9.2. The root cause of this was an attempt to apply both 14638 and 14977 which led to the error.
Revised Text: Add generalizations between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. Show these generalizations on figure 9.2.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15565: Fix association end multiplicities (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

InfrastructureLibrary::Profiles::A_metamodelReference_profile::profile from [1] to [0..1]

InfrastructureLibrary::Profiles::A_metaclassReference_profile::profile from [1] to [0..1]

 

CompleteStructuredActivities::A_structuredNodeInput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

CompleteStructuredActivities::A_structuredNodeOutput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

Resolution: The first change is needed because otherwise a PackageImport and an ElementImport must be owned by a profile, which is bad. The second change is needed because otherwise InputPins and OutputPins must be the inputs and outputs of StructuredActivityNode (fig 12.22), which is also bad.
Revised Text: Make the changes to the metamodel proposed in the summary. Change Infrastructure figure 12.2, Superstructure figure 18.2, and Superstructure figure 12.22 accordingly.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15566: Association conflicts with MemberEnds IsDerived flags (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML::CompositeStructures::InternalStructures::A_feature_featuringClassifier

UML::Activities::FundamentalActivities::A_subgroup_superGroup

UML::Activities::FundamentalActivities::A_containedNode_inGroup

UML::Activities::CompleteStructuredActivities::A_containedEdge_inGroup

UML::Activities::StructuredActivities::A_containedNode_inGroup

UML::Activities::CompleteActivities::A_containedNode_inGroup

UML::Activities::IntermediateActivities::A_subgroup_superGroup

UML::Activities::IntermediateActivities::A_containedEdge_inGroup

UML::Activities::IntermediateActivities::A_containedNode_inGroup

 

InfrastructureLibrary::Core::Abstractions::Constraints::A_ownedMember_namespace

InfrastructureLibrary::Core::Abstractions::Classifiers::A_feature_featuringClassifier

InfrastructureLibrary::Core::Abstractions::Namespaces::A_ownedMember_namespace

InfrastructureLibrary::Core::Abstractions::Ownerships::A_ownedElement_owner

Resolution: These are associations with both ends derived. There is a MOF constraint: An Association is derived if all its Properties are derived. Hence all of these associations should be marked as derived. In addition, there is currently inconsistency elsewhere in the metamodel about which associations should be marked as derived. For example, A_redefinitionContext_region, with derived=false, and A_redefinitionContext_state, with derived=true. These are obviously inconsistent. In order to correct this we?ll apply the following additional constraint: ? An association in which all navigable (class-owned) ends are derived is derived The reasoning behind this is as follows. If you take the meaning of an association to be a set of links, and the meaning of an association end to be a set of instances of the type at the end of the association, then �derived� means that these sets can be calculated from other information. The other ingredient is whether the set can be altered �by hand�, as it were: and I am assuming that non-navigable ends cannot be altered by hand, i.e. they do not correspond to a settable API on a class. I don?t believe there is anything formal to substantiate this assumption, but it seems to be current practice for the metamodel to be constructed according to it. In this sense, all non-navigable ends are �derived�, whether you say so or not. The following are violations of this additional constraint: InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature InfrastructureLibrary::Core::Abstractions::Constraints::A_member_memberNamespace InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_memberNamespace InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship InfrastructureLibrary::Core::Abstractions::Super::A_inheritedMember_classifier InfrastructureLibrary::Core::Constructs::A_attribute_classifier InfrastructureLibrary::Core::Constructs::A_endType_association InfrastructureLibrary::Core::Constructs::A_importedMember_namespace InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier InfrastructureLibrary::Core::Constructs::A_member_memberNamespace InfrastructureLibrary::Core::Constructs::A_opposite_property InfrastructureLibrary::Core::Constructs::A_parameter_behavioralFeature InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship InfrastructureLibrary::Core::Constructs::A_source_directedRelationship InfrastructureLibrary::Core::Constructs::A_target_directedRelationship InfrastructureLibrary::Core::Constructs::A_type_operation InfrastructureLibrary::Profiles::A_ownedStereotype_owningPackage InfrastructureLibrary::Profiles::A_profile_stereotype UML::Actions::BasicActions::A_input_action UML::Actions::BasicActions::A_output_action UML::Activities::CompleteStructuredActivities::A_input_action UML::Activities::CompleteStructuredActivities::A_output_action UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature UML::AuxiliaryConstructs::Templates::A_redefinitionContext_redefinableElement UML::Classes::Interfaces::A_attribute_classifier UML::Classes::Kernel::A_attribute_classifier UML::Classes::Kernel::A_classifier_enumerationLiteral UML::Classes::Kernel::A_endType_association UML::Classes::Kernel::A_general_classifier UML::Classes::Kernel::A_importedMember_namespace UML::Classes::Kernel::A_inheritedMember_classifier UML::Classes::Kernel::A_member_memberNamespace UML::Classes::Kernel::A_opposite_property UML::Classes::Kernel::A_parameter_behavioralFeature UML::Classes::Kernel::A_redefinedElement_redefinableElement UML::Classes::Kernel::A_redefinitionContext_redefinableElement UML::Classes::Kernel::A_relatedElement_relationship UML::Classes::Kernel::A_source_directedRelationship UML::Classes::Kernel::A_superClass_class UML::Classes::Kernel::A_target_directedRelationship UML::Classes::Kernel::A_type_operation UML::CommonBehaviors::BasicBehaviors::A_context_behavior UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression UML::Components::BasicComponents::A_provided_component UML::Components::BasicComponents::A_required_component UML::CompositeStructures::InternalStructures::A_attribute_classifier UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd UML::CompositeStructures::InternalStructures::A_part_structuredClassifier UML::CompositeStructures::InternalStructures::A_role_structuredClassifier UML::CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier UML::CompositeStructures::Ports::A_provided_port UML::CompositeStructures::Ports::A_required_port UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_transition UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition
Revised Text: In the metamodel, mark all of the associations listed in the summary above, and in the second list under Resolution, as derived.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15567: Redefinition of association-owned ends requires association generalization (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are 21 examples of association generalizations that need to be introduced in order to make association-owned end redefinition valid

Resolution: The redefinition context for an association-owned end is the association itself. Hence in order for redefinition of such ends to be well-formed, the associations must participate in appropriate generalizations. Here are the problematic redefinitions: redefiningElement = A_specification_timeConstraint::timeConstraint redefinitionContext = A_specification_timeConstraint redefinedElement = A_specification_intervalConstraint::intervalConstraint redefinedContext = A_specification_intervalConstraint redefiningElement = A_specification_intervalConstraint::intervalConstraint redefinitionContext = A_specification_intervalConstraint redefinedElement = A_specification_owningConstraint::owningConstraint redefinedContext = A_specification_owningConstraint redefiningElement = A_specification_durationConstraint::durationConstraint redefinitionContext = A_specification_durationConstraint redefinedElement = A_specification_intervalConstraint::intervalConstraint redefinedContext = A_specification_intervalConstraint redefiningElement = A_request_sendObjectAction::sendObjectAction redefinitionContext = A_request_sendObjectAction redefinedElement = A_argument_invocationAction::invocationAction redefinedContext = A_argument_invocationAction redefiningElement = A_representation_classifier::classifier redefinitionContext = A_representation_classifier redefinedElement = A_collaborationUse_classifier::classifier redefinedContext = A_collaborationUse_classifier redefiningElement = A_redefinitionContext_transition::transition redefinitionContext = A_redefinitionContext_transition redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement redefinedContext = A_redefinitionContext_redefinableElement redefiningElement = A_redefinitionContext_state::state redefinitionContext = A_redefinitionContext_state redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement redefinedContext = A_redefinitionContext_redefinableElement redefiningElement = A_redefinitionContext_region::region redefinitionContext = A_redefinitionContext_region redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement redefinedContext = A_redefinitionContext_redefinableElement redefiningElement = A_preCondition_protocolTransition::protocolTransition redefinitionContext = A_preCondition_protocolTransition redefinedElement = A_guard_transition::transition redefinedContext = A_guard_transition redefiningElement = A_ownedStereotype_owningPackage::owningPackage redefinitionContext = A_ownedStereotype_owningPackage redefinedElement = A_packagedElement_owningPackage::owningPackage redefinedContext = A_packagedElement_owningPackage redefiningElement = A_ownedDefault_templateParameter::templateParameter redefinitionContext = A_ownedDefault_templateParameter redefinedElement = A_default_templateParameter::templateParameter redefinedContext = A_default_templateParameter redefiningElement = A_ownedAttribute_structuredClassifier::structuredClassifier redefinitionContext = A_ownedAttribute_structuredClassifier redefinedElement = A_role_structuredClassifier::structuredClassifier redefinedContext = A_role_structuredClassifier redefiningElement = A_ownedActual_templateParameterSubstitution::templateParameterSubstitution redefinitionContext = A_ownedActual_templateParameterSubstitution redefinedElement = A_actual_templateParameterSubstitution::templateParameterSubstitution redefinedContext = A_actual_templateParameterSubstitution redefiningElement = A_min_timeInterval::timeInterval redefinitionContext = A_min_timeInterval redefinedElement = A_min_interval::interval redefinedContext = A_min_interval redefiningElement = A_min_durationInterval::durationInterval redefinitionContext = A_min_durationInterval redefinedElement = A_min_interval::interval redefinedContext = A_min_interval redefiningElement = A_max_timeInterval::timeInterval redefinitionContext = A_max_timeInterval redefinedElement = A_max_interval::interval redefinedContext = A_max_interval redefiningElement = A_max_durationInterval::durationInterval redefinitionContext = A_max_durationInterval redefinedElement = A_max_interval::interval redefinedContext = A_max_interval redefiningElement = A_endData_destroyLinkAction::destroyLinkAction redefinitionContext = A_endData_destroyLinkAction redefinedElement = A_endData_linkAction::linkAction redefinedContext = A_endData_linkAction redefiningElement = A_endData_createLinkAction::createLinkAction redefinitionContext = A_endData_createLinkAction redefinedElement = A_endData_linkAction::linkAction redefinedContext = A_endData_linkAction redefiningElement = A_classifier_enumerationLiteral::enumerationLiteral redefinitionContext = A_classifier_enumerationLiteral redefinedElement = A_classifier_instanceSpecification::instanceSpecification redefinedContext = A_classifier_instanceSpecification redefiningElement = A_classifierBehavior_behavioredClassifier::behavioredClassifier redefinitionContext = A_classifierBehavior_behavioredClassifier redefinedElement = A_ownedBehavior_behavioredClassifier::behavioredClassifier redefinedContext = A_ownedBehavior_behavioredClassifier
Revised Text: In the metamodel, make each of the associations labeled as redefinitionContext in the above list be a specialization of the corresponding association labeled as redefinedContext.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15568: Derived properties that are not marked read-only (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only.  There are 24 exceptions to this convention.

Resolution: Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent. Vertex::outgoing Vertex::incoming Stereotype::profile (Infra fig 12.2, Super fig 18.2) Property::opposite (Super fig 7.12) Property::isComposite (Super fig 7.12) Property::default (Super fig 7.12) Parameter::default (Super fig 7.11) Package::ownedType (Infra fig 11.26, Super fig 7.14) Package::ownedStereotype (Infra fig 12.2, Super fig 18.2) Package::nestedPackage (Infra fig 11.26, Super fig 7.14) Operation::upper (Super fig 7.11) Operation::type (Super fig 7.11) Operation::lower (Super fig 7.11) Operation::isUnique (Super fig 7.11) Operation::isOrdered (Super fig 7.11) MultiplicityElement::upper MultiplicityElement::lower EnumerationLiteral::classifier (Super fig 7.13) EncapsulatedClassifier::ownedPort Connector::kind (Super fig 8.3) ConnectableElement::end (Super fig 8.3) Classifier::general Class::superClass (Super fig 7.12) ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense. Another reason not to make them all readonly is the following paragraph in Superstructure 2.3: ��Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.�� This implies that properties writable at L0 should be writeable at L3. The properties affected by this are: Property::opposite Property::isComposite Property::default Parameter::default Package::ownedType Package::nestedPackage MultiplicityElement::upper MultiplicityElement::lower Classifier::general Class::superClass We are allowed by the notation not to show {readOnly} on the diagrams. We will show {readOnly} on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ��all or nothing�� rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.
Revised Text: In the metamodel (Superstructure and Infrastructure), mark the following derived properties as read only and show them on the diagrams where indicated: Vertex::outgoing Vertex::incoming Stereotype::profile (Infra fig 12.2, Super fig 18.2) Package::ownedStereotype (Infra fig 12.2, Super fig 18.2) Operation::upper (Super fig 7.11) Operation::type (Super fig 7.11) Operation::lower (Super fig 7.11) Operation::isUnique (Super fig 7.11) Operation::isOrdered (Super fig 7.11) EnumerationLiteral::classifier (Super fig 7.13) EncapsulatedClassifier::ownedPort Connector::kind (Super fig 8.3) ConnectableElement::end (Super fig 8.3) ExtensionEnd::lower (Infra fig 12.2, Super fig 18.2)
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15569: Multiplicity Element Is MultiValued With Default Value (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

This applies to DurationObservation::firstEvent[0..2] default = true, and DurationConstraint::firstEvent[0..2], defaultValue = true. This conflicts with CMOF constraint [9] Multivalued properties cannot have defaults, and is also meaningless because firstEvent size is constrained to be 0 or 2.

Resolution: Remove the default as it violates a CMOF constraint
Revised Text: In the superstructure metamodel, remove the default values from CommonBehaviors::SimpleTime::DurationObservation::firstEvent and DurationConstraint::firstEvent. Change figure 13.13 accordingly. In 13.3.10 delete the sentence �Default value is true applied when constrainedElement[i] refers an element that represents only one time instant.� In 13.3.12 delete the sentence �Default value is true applied when event[i] refers an element that represents only one time instant.�
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15570: InstanceValue has no type (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are many cases where the default value of a property is represented by an InstanceValue, which is a TypedElement, but has no type.  These types should be inserted.

Resolution: In fact there are four cases where this is true for an InstanceValue that refers to an EnumerationLiteral. Other cases are instances of LiteralInteger, LiteralBoolean, etc and it seems completely redundant to mark the type of these as Integer, Boolean etc. UML::Classes::Kernel::Property::aggregation UML::Classes::Kernel::Parameter::direction UML::Activities::CompleteActivities::ObjectNode::ordering InfrastructureLibrary::Core::Constructs::Parameter::direction
Revised Text: In the metamodel, set the types of the default values of the following properties as follows: UML::Classes::Kernel::Property::aggregation Default=InstanceValue, type = AggregationKind UML::Classes::Kernel::Parameter::direction Default=InstanceValue, type = ParameterDirectionKind UML::Activities::CompleteActivities::ObjectNode::ordering Default=InstanceValue, type = ObjectNodeOrderingKind InfrastructureLibrary::Core::Constructs::Parameter::direction Default=InstanceValue, type = ParameterDirectionKind
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15571: Parameter have Effects (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

These are attributes in the metamodel, but are not included in MOF 2.4, so should be removed.

Resolution: Here are the parameters that have effect set in the metamodel. Parameter::effect is defined with multiplicity [0..1], and in metamodels should be set to null. UML::Classifier::maySpecializeType::c UML::Classifier::inheritableMembers::c UML::Property::isAttribute::p UML::Region::isRedefinitionContextValid::redefined UML::State::isRedefinitionContextValid::redefined UML::Component::usedInterfaces::classifier UML::Component::realizedInterfaces::classifier UML::StateMachine::isRedefinitionContextValid::redefined UML::RedefinableElement::isRedefinitionContextValid::redefined
Revised Text: In the metamodel, set all of the parameters listed above to have effect=null.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15572: EnumerationHasOperations : UML::VisibilityKind::bestVisibility (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is disallowed by MOF. [8] Enumerations may not have attributes or operations.  This operation is not used � remove it.

Resolution: Agreed: the operation is defined in both Infrastructure 9.21.2 (and index) and Superstructure 7.3.56 but is not used anywhere.
Revised Text: Infrastructure 9.21.2 � remove the entire Additional Operations section. Ensure bestVisibility does not appear in the index. Superstructure 7.3.56 - remove the entire Additional Operations section. Ensure bestVisibility does not appear in the index. Metamodel: Delete the bestVisibility operation from Abstractions::Visibilities::VisibilityKind, InfrastructureLibrary::Constructs::VisibilityKind, and UML::Classes::Kernel::VisibilityKind
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15573: The metamodel contains instances of Model (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

InfrastructureLibrary and UML are instances of Model, and MOF does not include Model.

Resolution: Change Models to Packages
Revised Text: In the metamodel, change the following elements from Model to Package: InfrastructureLibrary UML
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15574: Give all constraints unique names within their context. (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Several constraints have no names.  A couple of constraints have different names in different merge increments, but are the same constraint: 

UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,

UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization

Resolution: Here are the constraints with no names. UML::Transition::isConsistentWith:: UML::RedefinableTemplateSignature::isConsistentWith:: UML::RedefinableElement::isConsistentWith:: UML::Property::isConsistentWith:: UML::Package::makesVisible:: UML::Operation::isConsistentWith:: UML::OpaqueExpression::value:: UML::OpaqueExpression::isPositive:: UML::OpaqueExpression::isNonNegative:: UML::MultiplicityElement::isMultivalued:: UML::MultiplicityElement::includesMultiplicity:: UML::MultiplicityElement::includesCardinality:: UML::Classifier::inheritableMembers:: UML::Classifier::hasVisibilityOf:: These are all preconditions of operations. All of the bodies are named �spec� so I propose that all of the preconditions are named �pre�. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition.
Revised Text: In the metamodel (in all of Infrastructure Abstractions, Constructs and Superstructure where they apply), name all of the preconditions of the operations listed above as �pre�. In Kernel, delete the incorrect un-named postcondition on Classifier::inheritableMembers(). In Kernel::Classifier, rename generalization_hierarchies to no_cycles_in_generalization In Kernel::Constraint, rename not_applied_to_self to not_apply_to_self
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15575: Change all properties typed by data types to aggregation=none (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no semantic for making a property with a data type composite, so remove these markings

Resolution: UML::OpaqueAction::language UML::OpaqueAction::body UML::OpaqueBehavior::language UML::OpaqueBehavior::body UML::OpaqueExpression::language UML::OpaqueExpression::body
Revised Text: In the metamodel, set all of these properties wherever they occur (Abstractions, Constructs and Superstructure) to have aggregation=none.
Actions taken:
September 22, 2010: received issue
April 25, 2011: closed issue

Issue 15664: Property::isID should not be optional (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Property::isID should not be optional�.  The summary is �Property::isID should have multiplicity 1..1 and default value = false.  There is no additional useful semantic provided by making it optional

Resolution: agreed
Revised Text: Revise resolution 15369 to apply the following changes instead of the similar ones specified in 15369. Other changes specified in 15369 still apply. Superstructure Add the following to the Attributes section of 7.3.44, Property: ? isID: Boolean - True indicates this property can be used to uniquely identify an instance of the containing Class. Default value is false. Update Figure 7.12 to include isID : Boolean = false in class Property Infrastructure Add the following to the Attributes section of 10.2.5, Property: ? isID: Boolean - True indicates this property can be used to uniquely identify an instance of the containing Class. Default value is false. Add the following to the Attributes section of 11.3.5, Property: ? isID: Boolean - True indicates this property can be used to uniquely identify an instance of the containing Class. Default value is false. Update Figures 10.3 and 11.5 to include isId : Boolean=false in class Property
Actions taken:
September 28, 2010: received issue
April 25, 2011: closed issue

Issue 15669: UML state machines: inconsistent subset of StateMachine::extendedStatemachine (uml2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 15265 proclaimed that StateMachine::extendedStatemachine should subset Classifier::redefinedClassifier. However, while the text entry for this field does this, the diagram in Figure 15.3 subsets Behavior::redefinedBehavior instead. It seems that the fix was not applied properly. Note that Behavior::redefinedBehavior is not a derived union property, so Figure 15.3 is just plain wrong -- although it could be argued that the proper fix is to make it a derived union and have StateMachine::extendedStatemachine redefine Behavior::redefinedBehavior

Resolution: Figure 15.3 (referring to the version of 2.4 published in September 2010) is not wrong � it is valid for a property to subset a non-derived one. However the semantic question here is what exactly extendedStateMachine is supposed to mean that cannot be accomplished by using redefinedBehavior. It is wrong, however, in the sense that resolution 15265 was not correctly or consistently applied. At this point we need at least to make the resolution consistent. I propose to do this by making extendedStateMachine redefine behavior::redefinedBehavior, having the effect that only a state machine may redefine a state machine.
Revised Text: Relative to UML 2.3: In the metamodel change StateMachine::extendedStateMachine from {subsets redefinedElement} to {redefines CommonBehaviors::BasicBehavior::Behavior::redefinedBehavior}. In figure 15.3 change {subsets redefinedElement} to {redefines redefinedBehavior}. In 15.3.12 StateMachine::extendedStateMachine, change Subsets RedefineableElement::redefinedElement to Redefines Behavior::redefinedBehavior.
Actions taken:
September 30, 2010: received issue
April 25, 2011: closed issue

Issue 15762: Problem with ExtensionEnd::lower (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0.  The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent.  The same is true in 2.3.

 

This seems to be a significant issue with regard to profile interchange, so I�d like to fix it in 2.4. Juergen, could we have an issue number please?

 

Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

 

MultiplicityElement::/lower is marked as derived.  It does not have a default value. Instead, there is a derivation constraint:  

 

lower = lowerBound(); and operation

 

lowerBound()  = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

 

In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0.  What is this supposed to mean?  If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived.  But it does not.  So there is no well-defined derivation.

 

If we regarded the derivation in MultiplicityElement to be somehow �inherited� across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower. 

 

I think to fix this what we ought to do is the following.   Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

 

lower = lowerBound(); and 

 

lowerBound()  = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

 

This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal. 

 

<packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

      <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

   </ownedEnd>

</packagedElement>

Resolution: After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources: - the fact that it is derived is from AuxiliaryConstructs::Profiles - the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement - the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound(). However, the [0..1] multiplicity of lower() � the operation which gives the derivation for ExtensionEnd::/lower in the metamodel � conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement � it represents a �widening� of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.
Revised Text: In figure 18.2 show /lower: Integer[0..1] = 0 { redefines lower } In section 18.3.3 change the definition of lower, which currently reads thus: ? lower : integer = 0 This redefinition changes the default multiplicity of association ends, since model elements are usually extended by 0 or 1 instance of the extension stereotype. {Redefines MultiplicityElement::lower} to: ? /lower : integer [0..1] = 0 This redefinition changes the default multiplicity of association ends, since model elements are usually extended by 0 or 1 instance of the extension stereotype. The value of lower is derived from the redefined lowerBound() operation, via a constraint inherited from MultiplicityElement. {Redefines MultiplicityElement::lower} In section 18.3.3 change the signature of lowerBound(), which currently reads thus: ExtensionEnd::lowerBound() : Integer; to: ExtensionEnd::lowerBound() : Set(Integer); In the metamodel, change the multiplicities of the results of all of the following operations to be [0..1]: InfrastructureLibrary::Profiles::ExtensionEnd::lowerBound(); MultiplicityElement::lower(), lowerBound(), upper(), upperBound(); ValueSpecification::integerValue(), booleanValue(), realValue(), stringValue(), unlimitedValue();
Actions taken:
October 19, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15778: Fix minor inconsistencies between infrastructure specification document & metamodel (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description: To ensure that the UML2.4 metamodel is consistent with the specification document, the following inconsistencies must be resolved:

 

1) NamedElement::qualifiedName()

 

InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement::qualifiedName()

? this corresponds to 9.14.1 constraint [2]  -- OK

 

InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

? no description of this in clause 11 for Core::Constructs -- OK per current conventions that clause 11 does not duplicate the constraints/operations from the merged increments shown in 11.2

 

For the superstructure:

? the description in super 7.3.34 constraint [2] is copied from 9.14.1 constraint [2] ? OK

? UML::Classes::Kernel::NamedElement::qualifiedName() is missing ? not OK per current conventionss that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

 

Resolution:

               In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

 

2) DataType::inherit()

 

? No description anywhere of InfrastructureLibrary::Core::Constructs::DataType::inherit() in infra 11.6.1 or super 7.3.11

? UML::Classes::Kernel::DataType::inherit() is missing ? not OKK per current conventions that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

 

Resolution:

 

1.a) figure 11.2 is only in the document, the package merge relationships are not in the infrastructure at all.

 

? add the relationships as described in infra 11.2

? add a package merge relationship from Core::Constructs to Core::Abstractions::Element, which other merge increments in Core::Abstractions import. 

 

2) DataType::inherit()

 

In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()

 

In Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section:

 

Additional Operations 

[1] The inherit operation is overridden to exclude redefined properties. 

DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);

inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))->select(redefinedElement->includes(inh)))

Resolution: The issue summary is a bit garbled, but here is a summary of what it proposes, in order to make the metamodel and specification document consistent. In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName() In the metamodel change infrastructure figure 11.2 so that Constructs does not merge Basic, and instead Constructs does merge Core::Abstractions::Elements. The merge to Basic is conceptually flawed because Basic has a different and conflicting definition and semantics for Operation. Note that these merges remain purely conceptual � they are not explicit in the metamodel. In the metamodel, delete the association Core::Abstractions::BehavioralFeatures::A_parameter::behavioralFeature, because if this association was actually merged according to figure 11.2 it would be an orphaned derived union, with no subsets in the metamodel. In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit() In Infrastructure 11.6.1 and Superstructure 7.3.11, add the following section: Additional Operations [1] The inherit operation is overridden to exclude redefined properties. DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement); inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))->select(redefinedElement->includes(inh)))
Revised Text: In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName() In the metamodel delete Core::Abstractions:: BehavioralFeatures::A_parameter::behavioralFeature. In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit() In Infrastructure figure 11.2, delete the merge from Constructs to Basic and add a merge from Constructs to Elements. In Infrastructure figure 9.4 delete the association BehavioralFeature::/parameter. Also delete the corresponding section 9.1.1 Associations. In the specifications Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section: Additional Operations [1] The inherit operation is overridden to exclude redefined properties. DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement); inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))->select(redefinedElement->includes(inh)))
Actions taken:
October 25, 2010: received issue
April 25, 2011: closed issue

Issue 15779: Be explicit that type does not need to be set for LiteralBoolean etc. (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Today we are inconsistent in the metamodel about whether the type of a LiteralBoolean value is set or not.  Some are; most are not, and there is no guidance in the spec about which is correct.  Since the type is completely obvious, we can be explicit about this:

 

LiteralBoolean

 

Constraints:

 

[1] Since the type of a LiteralBoolean is by definition a Boolean, it would be redundant to specify the type explicitly.

type->isEmpty()

 

LiteralInteger

 

Constraints:

 

[1] Since the type of a LiteralInteger is by definition an Integer, it would be redundant to specify the type explicitly.

type->isEmpty()

 

LiteralReal

 

Constraints:

 

[1] Since the type of a LiteralReal is by definition a Real, it would be redundant to specify the type explicitly.

type->isEmpty()

 

LiteralString

 

Constraints:

 

[1] Since the type of a LiteralString is by definition a String, it would be redundant to specify the type explicitly.

type->isEmpty()

 

LiteralUnlimitedNatural

 

Constraints:

 

[1] Since the type of a LiteralUnlimitedNatural  is by definition an UnlimitedNatural, it would be redundant to specify the type explicitly.

type->isEmpty()

Resolution: After discussion the RTF resolved that making changes of this kind to the spec is too controversial. Instead, we simply go through the metamodel making sure that all instances of subtypes of LiteralSpecification have their type set to null, in order to make the metamodel consistent.
Revised Text: No changes to the spec. In the metamodel, for all instances of subclasses of LiteralSpecification, set their type property to null.
Actions taken:
October 25, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15873: UML 2.4: �Figure 7.31 shows the dot at the wrong end.� (uml2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity: Significant
Summary:

UML 2.4: �Figure 7.31 shows the dot at the wrong end.�  From: Pete Rivett [mailto:pete.rivett@adaptive.com] 
Sent: 14 December 2010 17:50
To: Steve Cook
Cc: Maged Elaasar; andrew@omg.org
Subject: RE: New notation for attribute

No it did not come from me: I think it was Jim or Bran or Ed (see attached).

However attached is an updated figure I drew from scratch.

Pete

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: Tuesday, December 14, 2010 4:44 AM
To: Pete Rivett
Cc: Maged Elaasar; Andrew Watson (andrew@omg.org)
Subject: RE: New notation for attribute

Pete � I believe you made that figure.  Is it possible to supply a correct one?

From: Pete Rivett [mailto:pete.rivett@adaptive.com] 
Sent: 13 December 2010 20:10
To: Ed Seidewitz; Steve Cook; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure.

In terms of the concepts, it seems that navigability is the thing we should lose � specifically for metamodeling.

What does it mean to say that it�s not possible (�efficiently�) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information?

That�s not to say navigability has no value for other types of model. I don�t feel qualified to comment. Clearly some people like it.

However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) � since it�s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability.

This will make no difference at all to the XMI for model interchange � since it�s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5.

Pete

From: Ed Seidewitz [mailto:ed-s@modeldriven.com] 
Sent: Monday, December 13, 2010 10:21 AM
To: Steve Cook; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

Steve �

I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the �dot on the wrong end� is the right way to show an attribute using �association-like notation�, which will just cause even more confusion!

As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don�t think it has), I don�t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved!

-- Ed

--------------------------------------------------------------------------------

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: Monday, December 13, 2010 1:09 PM
To: Ed Seidewitz; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

I�ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly.  No normal user of UML cares a fig about this stupid dot.  It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML.

The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example.

I don�t believe that this is an editorial change.  I think we deserve to be embarrassed by it for a good few months.  Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5.

-- Steve

From: Ed Seidewitz [mailto:ed-s@modeldriven.com] 
Sent: 13 December 2010 17:55
To: Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

Bran �

You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 �to show dot-notation�. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??).

In any case, I think the intention was that this notation alternative look exactly like association notation � that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue.

-- Ed

--------------------------------------------------------------------------------

From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic
Sent: Monday, December 13, 2010 12:42 PM
To: Ed Seidewitz
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: Re: New notation for attribute

???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention).

Ugh! Overloading notations is a bad idea.

Cheers...Bran

On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz <ed-s@modeldriven.com> wrote:

Bran �

I don�t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association.

-- Ed

--------------------------------------------------------------------------------

From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic
Sent: Monday, December 13, 2010 12:14 PM
To: Steve Cook
Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org

Subject: Re: New notation for attribute

Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong?

In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above).

Cheers...Bran

On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook <Steve.Cook@microsoft.com> wrote:

I believe this option is already there: see figure 7.31.

From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] 
Sent: 11 December 2010 11:59
To: BERNARD, Yves
Cc: uml2-rtf@omg.org
Subject: Re: New notation for attribute

Yves,

This idea makes sense as part of the Diagram Definition for UML. 

- Nicolas.

On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote:

According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:

Capability to get a modular diagram thanks to the �link notation�
Capability to show the aggregation kind

However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

Resolution: Replace the offending diagrams.
Revised Text: see pages 209 - 210 of ptc/2011-01-19
Actions taken:
December 14, 2010: received issue
April 25, 2011: closed issue