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 4110: Semantics of firing compound transitions still appears to be circular (uml2-rtf)

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

In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

On page 2-173 of 2.12:

*** The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

[...]

Once a transition is enabled and is selected to fire, the following steps are carried out in order:

� The main source state is properly exited.

� Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

� If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

� The main target state is properly entered. ***

This is certainly much better than 1.3. But I still find it difficult to follow:

Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
December 7, 2000: received 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 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 4932: Starting state machine (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:

[Steve Mellor] The action semantics has an action that starts a state
machine.  The state machine starts in some known initial (pseudo-)state.

There are many cases where one wants to initialize a state
machine so that starts in a specified (non-initial) state.

Therefore the StartStateMachineAction needs to accept a state
(possibly multi-leveled) as an input.  The state machine will 
not execute any procedures or actions until after the state 
machine is in the target state and then detects an event.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
March 5, 2002: received issue
October 22, 2002: deferred issue

Discussion:

Application: restoring state.
Requires static specification of state, so complexity will be the same
  as having transitions to each state, and sending an event.
Would make a dependence of actions on state machines.
Similar problems with restoring attribute values, etc, of objects.
Requires tracking and restoring execution execution.
Too much for FTF to do consistently [Action Semantics FTF]:
Application: restoring state.
Requires static specification of state, so complexity will be the same as having transitions
to each state, and sending an event.
Would make a dependence of actions on state machines.
Similar problems with restoring attribute values, etc, of objects.
Requires tracking and restoring execution execution.
Too much for FTF to do consistently
[UML 2 FTF]
There is too much debate around this for the FTF to resolve. The use case is to bring up a
software system that is embedded in a larger physical system. The embedded system has
objects reflecting the state of the physical objects. The filer would like to start the
software system by instantiating classes, with the new instance reflecting the state of the
physical objects. Using triggers/guards on constructor inputs makes too cumbersome a
model.
There was some concern about referring to states from actions outside the object.
However, states are not always internal. There was also concern that the details of
restarting an application are not properly part of modeling. However, modeling is not
limited to a particular level of implementation. There was debate on whether entry points
could be used for the applications, but in any case, the action would need to refer to a
state.

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 5107: Starting a state machine (uml2-rtf)

Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description:
The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

Syntactically, we have the following:

o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts.

o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

o The definition of the stereotype <<create>> is (p. 2-149):

"Create is a stereotyped call event denoting that the instance receiving
that event has just been created. For state machines, it triggers the
initial transition at the topmost level of the state machine (and is the
only kind of trigger that may be applied to an initial transition)."

Thus, a "creation event" MUST be a call event.

o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

Recommendation:

1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

3. Change well-formedness rule [5] to exclude the top initial pseudo-state.

4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature.

5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
April 4, 2002: received 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 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 5886: behaviour of the shallow history state and deep history state (uml2-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Significant
Summary:

In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state.

Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. � Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
March 21, 2003: received 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 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 5977: saying {nonunique} on one end of a binary association is meaningless (uml2-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

Also, saying {nonunique} on one end of a binary association is
meaningless by the current rules, because the other end remains {unique} by
default, so no duplicate links would be allowed

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
June 19, 2003: received 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 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 6071: Conditional Node and Loop Node notation missing (uml2-rtf)

Click here for this issue's archive.
Source: CA Technologies (Mr. Andrew John Haigh, andrew.haigh(at)ca.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

In 03-07-06 there was notation for conditional nodes and loop nodes for activities. These are missing in 03-08-02. Makes taking the certification difficult

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 21, 2003: received 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 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 6083: More examples (uml2-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. James J. Odell, email(at)jamesodell.com)
Nature: Clarification
Severity: Minor
Summary:

The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received issue

Discussion:

This is indeed a reasonable request and additional examples would indeed be helpful.
However, since it is not a critical issue or an inconsistency in the spec itself, the issue is
deferred to an RTF.

Issue 6086: More explanation needed on Figure 339 (uml2-rtf)

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

The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received 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 6088: Parameterization of lifelines (uml2-rtf)

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

In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 29, 2003: received issue

Discussion:

This is a feature enhancement and, therefore, outside of the scope of an FTF,
whose purpose is to fix inconsistencies and add clarifications. 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 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 6114: State extension (uml2-rtf)

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

State should be an extension of type rather than object node.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:

This requires more discussion on what should be specifiable as a type, and
layering the state machine model (issue 7555). 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 6126: Target pin notation (uml2-rtf)

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

On CallOperationAction, etc, how do you tell graphically which pin is
the target?

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:

This is does not affect usage or implementability enough for the FTF to address. 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 6137: Promote local conditions to ExecutableNode (uml2-rtf)

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

Promote local precondition to ExecutableNode.  There might be other
associations on Action that should be at ExecutableNode

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:

It may be that local preconditions should apply to object nodes also. Postpone
for discussion in RTF. 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 6150: 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: Significant
Summary:

Provide a notation for a behavior used as a method of an operation

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 30, 2003: received issue

Discussion:

OMG Issue No: 6150
NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
It is probably worthwhile to define a graphical syntax representing
BehavioralFeature.method. This could take the form of either
� showing the name of the instance of Behavior which is the method along in the
compartment where the behavioral feature is exhibited
� having a graphical link between the behavioral feature and a symbol representing
the behavior instance (similar to how it is shown that a CollaborationOccurrence
represents a Classifier (see Figure 106).
The downside of either is that users typically don�t think of the behavioral feature and the
behavior as separate things and usually would not dream of naming the behavior (of
course, this is not required). In particular, if the behavior is described by a body string a
convenient way of showing that body string with the behavioral feature would be desired.
Today tools typically use the property sheet for the behavioral feature to show the
associated behavior. There are already different vendor specific solutions for some
behaviors as methods. We need to gain better experience before standardizing as solution.
Disposition: Deferred It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either . showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited . having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don.t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. The situation has not changed from the discussion in 2003. There have been no new developments in tool specific notations for method, nor have there been further requests for such notation. However, the issue seems still relevant. Therefore, the suggestion is to defer further. Revised Text: N/A Disposition: Deferred

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

Click here for this issue's archive.
Source: Simula Research Laboratory (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: Simula Research Laboratory (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: Simula Research Laboratory (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: Simula Research Laboratory (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 6200: UML 2 Super/Metamodel/redefinition and substitutability (uml2-rtf)

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

Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
September 7, 2003: received issue

Discussion:

Indeed. However, this is a serious and contentious theoretical issue and it�s resolution is
beyond the scope of the FTF. Fortunately, the specific issue with state machines has been
eliminated by the resolution to issue 6185. 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 6201: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" (uml2-rtf)

Click here for this issue's archive.
Source: Simula Research Laboratory (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: Simula Research Laboratory (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: Simula Research Laboratory (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 6346: Activity OCL (uml2-rtf)

Click here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Revision
Severity: Significant
Summary:

Not all the constraints in the Activities section have corresponding OCL
specifications. These should be added

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received issue

Discussion:

This is does not affect usage or implementability enough for the FTF to address,
and is a very large and time-consuming change. 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 6353: Deployment a 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:

If Artifact and Node are classifiers, why is deployment a dependency?
Then runtime artifacts cannot be deployed to runtime nodes.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received issue

Discussion:

Run-time artifacts can be deployed to runtime models, but the type consistency
is not formally guaranteed (that is, if Artifact A is deployed to Node B, then
instances of A are deployed to instances of B, but there is no �instantiation� of the
deployment relationship).
In order to formalize the instantiation aspect, Deployment would need to be
modeled as a subtype of Association. This solution has been touched on in the
submission process as a simplification and tightening of the model but requires
some time to work out and bed down, as it would be a non-trivial change. Hence,
it would be best tackled in an RTF process. Note (if this solution direction is
accepted) that the notation would need to be changed to not use a dependency,
but rather an association (possibly with keyword <<deploy>>).

Issue 6368: Join nodes that destroy tokens (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 if join nodes optionally destroyed tokens not accepted,
especially when using join expressions.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
October 20, 2003: received 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 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 6395: UML 2 Super / State machines / Transition triggers cannot be redefined (uml2-rtf)

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

Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed

Resolution:
Revised Text:
Actions taken:
October 31, 2003: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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

Click here for this issue's archive.
Source: Simula Research Laboratory (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: Simula Research Laboratory (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 6409: UML 2 Super/Interactions/missing OCL constraints (uml2-rtf)

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

Not all the constraints in the Interactions section (14.3). They should  be added

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 3, 2003: received issue

Discussion:

These constraints should definitely be added. This should be done in an RTF. 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 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 6430: UML2 super/ad-03-04-01/Derived attributes and associations (uml2-rtf)

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

Issue:  There are many places where the specification indicates that an
attribute or association is derived, but does not state how it is derived;
that is, the specification does not state, in English or in OCL, how to
compute the derivation.


Recommendation: Specify, in English and OCL, how to compute the derivations
of all derived attributes and associations.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 4, 2003: received issue

Discussion:

These specifications should definitely be added. This should be done in an RTF. 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 6433: 03-04-01 Chap 2 p. 112/Components: Different ways to wire components (uml2-rtf)

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.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 6441: Integration between behavioral "sublanguages": Interactions and Activities (uml2-rtf)

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

Although both Sequence Diagrams and Activity Diagrams have
added many advanced features in UML 2, these features appear to have been
added independently, so that they appear as two separate behavioral
languages. Consider improving the integration between them by supporting the
following:
a) Allow for an activity in an activity diagram to represent an invoked
operation in a message on a sequence diagram.
b) Allow for interaction diagram notations to be applied to activity
diagrams, such as the use of references, alternates, and gates.
c) Clarify that time and other constraints can be applied to an activity
diagram in a manner similar to how they are applied to sequence diagrams.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 6, 2003: received issue

Discussion:

This issue is part of a much larger discussion that cannot be handled by one working
group alone. In fact this issue has to be covered in face-to-face meetings resulting in a
commitment to unify the language even further. It is still an important topic and an
obvious desire for many of us for the future. 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 6445: Clarification of use case semantics (uml2-rtf)

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

Use cases and associated sequence and activity diagrams are
widely used by systems engineers to specify the functionality of the system,
and describe the interaction between the system and the actors. However,
there is much confusion regarding use case semantics. Consider the following
recommendations to clarify use case semantics:
a) Establish an explicit representation to depict the relationship between a
use case and its realization as a sequence diagram, activity diagram, etc.
In addition, allow for a similar representation to show the relationship
between an included/extended use case, and the interaction fragments which
realize the included/extended use case.
b) Clarify the relationship between a use case (solid oval) and a
collaboration (dashed oval), and determine whether they can represent the
same or a similar concept.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 6, 2003: received issue

Discussion:

UML already supports this capability since it allows a classifier (in this case a use case)
to have associated a number of behaviors that are in some ways related to the classifier
(e.g., they may represent realizations of the classifier in some way, or illustrations of
specific executions related to the classifier, etc.) However, the proposed resolutions are
asking for a specialization of these general (meta)associations that would have special
realization semantics. Such semantics might prove to be tricky to define in the case of use
cases, and require some study (i.e., what does it mean for a behavior to �realize� a use
case? Is it just an illustration of one possible realization or is it more general?) These are,
in effect, requirements for new modeling features and, therefore, fall outside the scope of
an FTF or RTF. This should be the subject of a separate RFP.

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: Simula Research Laboratory (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 6452: UML 2 Super / Missing OCL constraints (uml2-rtf)

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

In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:

These constraints should definitely be added. This should be done in an RTF. defer 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 6455: instantiations of Classifiers (uml2-rtf)

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

7 and 14:  "An instance specification is a model element that represents an instance in a modeled system." [7.7.1]  There are no objects in a UML 2 model, but only models of objects, that is, instance specifications.  The instantiation of a UML class is not in the model, but in the modeled system.  At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution:  Abandon the idea that there are no objects in a model.  Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model.  Likewise for an association and its links, and so on.


This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.


It is consistent with the existence of power types in the language.


It is consistent with the MOF specification of meta-layers.


It removes the conflation of the type conformance and instatiation relationships with the representation relationship.  It reduces the meanings conflated into 'instance of' by one.



Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received 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 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: Simula Research Laboratory (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 6462: UML 2 Issue: AssociationEnd (uml2-rtf)

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

PROBLEM STATEMENT
In UML 1 the navigability of an association end was specified by the
meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
meta-attribute dissapears, and AssociationEnd is substituted by Property. We
know whether an association end is navigable by the following rule: if the
property is owned by a class, it represents a navigable end; if the property
is owned by an association, it represents a non-navigable end (see
Superstructure, p. 89). However, references to old metaclass AssociationEnd
and old meta-attribute isNavigable still appear in the Spec in several
places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
245). 

PROPOSED SOLUTION
Add derived meta-attribute /isNavigable to metaclass Property.
Eliminate references to AssociationEnd.

Resolution: Resolution: As of UML 2.2, in the Superstructure (ptc/08-05-05), this has been mostly corrected. isNavigable is now an additional operation on Property. However, some OCL constraints in AssociationClass and ReadLinkAction still referemce AssociationEnd. There is also still one reference to AssociationEnd in the Infrastructure text (ptc/ 08-05-04, Subclause 8.1).
Revised Text: In the UML 2.2 Superstructure specification (ptc/08-05-05): In Subclause 7.3.4 (AssociationClass), Constraint [1] text, change "AssociationEnds" to association ends. In Subclause 11.3.33 (ReadLinkAction), in the OCL for Constraints [2] to [5], change "AssociationEnd" to "Property". In the UML 2.2 Infrastructure specification (ptc/08-05-04), Subclause 8.1, the last sentence of the last paragraph, change "AssociationEnd" to "Property".
Actions taken:
November 7, 2003: received issue
February 18, 2005: moved from infrastructure

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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

Click here for this issue's archive.
Source: Simula Research Laboratory (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 6464: UML 2 Issue: isUnique (uml2-rtf)

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

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

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

This has implications, for example, for the property strings that can be
placed near the association ends ({ordered}, {bag}, {seq}). According to the
table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
the opposite end must be a Set or an OrderedSet, too; and if one end is a
Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

PROPOSED SOLUTION
Explain this in the Spec.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6466: UML 2 Issue: Qualified pathnames (uml2-rtf)

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

PROBLEM STATEMENT
The notation for qualified names is double-colon ('::'). However, the Spec
always and everywhere uses a different notation: instead of
"Kernel::Comment", "Comment (from Kernel)". 

PROPOSED SOLUTION
Use the standard notation for qualified names.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6470: Section 7.11.2 Association (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:

What is the sematics of an association with neither end navigable? Provide an example of when this might be used. (C to D page 85).

Resolution:
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6487: Conditions for parameter sets (uml2-rtf)

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

Selection behavior on object nodes should be changed to allow execution
at insertion time, keeping the queue

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:

This issue should be titled �Selection behavior�..
Requires more discussio n on how to express sorting procedures in the model. 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 6489: Ports in Protocol State Machines (uml2-rtf)

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

Protocol machines should not have ports in them.  It should be an
extension in the ports package.  Otherwise there is a backwards
dependency onto composite structure.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 7, 2003: received issue

Discussion:

Statemachines already depend on ports via triggers, so the proposed change will not
remove the dependency. Furthermore, creating a dependency from composite structures
to statemachines would create a more serious layering problem. Therefore, resolving this
dependency requires a non-trivial restructuring that shall be done by an RTF at this point.

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: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.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: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.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 6495: ptc-03-09-15/Separate classification and generalization in Core::Basic (uml2-rtf)

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

Issue: One of the main requirements for a core that can be reused by CWM
hinges on whether it is possible to reuse the abstract syntax that supports
classification and supports having properties (or features), without pulling
in generalization constructs.  U2P�s Core::Basic package, upon which EMOF is
based, does not appear to adequately separate these concerns.


The most abstract level of Core::Basic's inheritance hierarchy at which the
ability to have properties appears is in the Class metaclass.  But Class
also carries the �baggage� of a definition of superclass.


The Core::Abstractions package does appear to adequately separate these
concerns.  It does so by defining a simple Classifier in the
Core::Abstractions::Classifiers package that supports features but not
generalization.  The Core::Abstractions::Super package defines another
Classifier metaclass that subclasses
Core::Abstractions::Classifiers::Classifier and adds support for
generalization.


Presumably, then, the intent is that CWM metamodels that support
classification and properties but not generalization can reuse
Core::Abstractions::Classifiers::Classifier.  However, Core::Basic does not
reuse either of these basic definitions of Classifier from
Core::Abstractions, and EMOF is based on Core::Basic.  Thus, if a CWM
metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
share a common definition of Classifier with EMOF.  That could mean that a
metamodel expressed solely via EMOF will not be able to be the source or
target in a unified approach to transformations.  This is not a problem for
CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
are based on Core::Abstractions.


Recommendation: Solving the problem for EMOF would require some refactoring
of Core::Basic to separate concerns between classification and
generalization.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.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 6497: ptc-03-09-15/Need for examples to include instance models (uml2-rtf)

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

Issue and Recommendation: In general the specification of the Core would
benefit from instance diagrams accompanying example models, especially in
cases where there is significant change from UML 1.x.  An instance diagram
accompanying an example model would show how the model instantiates the
elements of metamodel.  This will contribute to a greater level of common
understanding among readers of the specification and thus will help ensure
interoperability.


For example, consider Figure 3-23 from the submission document and which
defines the abstract syntax for the elements of the
Core::Constructs::Constraints package.  Despite the existence of
accompanying explanatory text, the distinction between the Namespace that
owns a Constraint and the Namespace that provides the context for a
Constraint may be difficult for the reader to grasp completely.  Figures
3-24, 3-25, and 3-26 from the submission document, respectively, provide
example models.  An instance diagram for at least one of the examples that
shows how the elements of the example model instantiate elements of
Core::Constructs::Constraints would go a long way toward preventing
misunderstandings.  Such misunderstandings would compromise
interoperability, since there is a high probability (in my opinion) that
different implementers would render models to XMI differently.


This example is only one of many that I could cite from the submission where
examples *plus* associated instance diagrams would be beneficial.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6498: ptc-03-09-15/Explain the new association modeling constructs (uml2-rtf)

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

Issue: The Core�s abstract syntax makes heavy use of new association
modeling constructs.  Two of them in particular may be unfamiliar to many
who read the submission:
�       Subsets
�       Derived unions


The submission provides only a brief explanation of these two new
constructs, which I quote below:


"A navigable property may be marked as a subset of another, as long as the
owner of the subsetting property is the same as or a specialization of the
owner of the subsetted property. In this case, the collection associated
with an
instance of the subsetting property must be included in (or the same as) the
collection associated with the corresponding instance of the subsetted
property.


A property may be marked as being a derived union. This means that the
collection of values denoted by the property in some context is derived by
being the strict union of all of the values denoted, in the same context, by
properties defined to subset it. If the property has a multiplicity upper
bound of 1, then this means that the values of
all the subsets must be null or the same."


Recommendation: Since these constructs are so heavily used to define the
Core itself, it would be useful for the submission to provide some overall
guidance on how to use them.  Providing rationale for why specific ones are
chosen in specific places in the definition of the Core would be an
effective way of disseminating understanding of these constructs and
understanding of the Core as well.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 6616: UML Superstructure FTF : isRoot property disappeared (uml2-rtf)

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

The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.


On page 399 FAS: section 13.3.4


The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.


On page 86 FAS section 7.8.3 RedefinableElement:


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.


But no  mention of isRoot....

Resolution:
Revised Text:
Actions taken:
November 14, 2003: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6624: freeing namespace (uml2-rtf)

Click here for this issue's archive.
Source: XTG, LLC (Mr. Joaquin Miller, )
Nature: Uncategorized Issue
Severity:
Summary:

I know ODP is <adjective>, so i'd like to add mention of a couple of other places where we will find name space standing on its own, and not conflated with package or other container.


An IETF namespace is exactly "a set of terms usable as names."


As Karl reminded me, a C++ name space is also "a set of terms usable as names," declared with the keyword 'namespace' and used with the keywords 'using namespace' (providing a naming context) or with the scope operator, '::' (converting a simple name to a name that is an identifier).


[Unlike most Java tools, there is no requirement that the things in a C++ namespace all be in any particular container.  Karl tells me that C++ programmers he works with don't like the way Java tools insist that a package-cum-namespace be identified with a directory that contains all elements of that package.  (Of course, tools that do that are following "the extremely simple example" in The Java Language Specification.  Sometimes the effect of simple examples on the future of the world.)  It can be fine to have such simplifications in a programming language, but it's good to have more flexibility in models.]


C++ also provides a form for aliases:
    namespace new_name = current_name ;


Still more flexible is that other approach, which in addition to distinguishing name space from naming context, also allows the same item to have fully qualified names from different namespaces.  If that's in MOF, let's use it.  (Is that accomplished the relaxing, which MOF 2 package import provides?  (If i import C from Pa into Pb, can i identify it with 'Pb::C'?))


If not, let's put it there.


Seems to me to be easy to accomplish, if Namespace is first class.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
November 17, 2003: received issue

Discussion:

This is a significant change at the core of the metamodel and requires further study. 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 6630: UML 2 Super / Classes / dependencies should be unidirectional (uml2-rtf)

Click here for this issue's archive.
Source: Simula Research Laboratory (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: Simula Research Laboratory (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 6645: UML 2.0 Superstructure Kernal/Packages (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  Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement.  But is incorrectly changed from a derived union to NON Derived.  If it is intended to be non derived the property string subsets on all the other members are in error.

 

ownedMember for a Package should be a derived union subset by the following Properties:

ownedType

nestedPackage

ownedRule

 

An OCL equivalent would be as follows:

 

ownedMember=ownedType->union(nestedPackage)->union(ownedRule)

Resolution:
Revised Text:
Actions taken:
October 1, 2003: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 6681: UML2 Super/Kernel Classes (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:

section 7.11 Does Property.aggregation have meaning for properties typed by
value types, (Data Type and subtypes)?

Resolution: The short answer is yes. This question pertains to the case where two conditions hold: 1) a Property is owned by a classifier via ownedAttribute, 2) the type of the ownedAttribute property is a kind of DataType According to the semantics of DataType (7.3.11), the instances of a data type are identified only by their value. The meaning of Property.aggregation for a datatype property owned by a classifier is subject to several factors, including: - the precise semantics of shared aggregation (AggregationKind 7.3.2) - the meaning of composition for such a property which "indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts)" (AggregationKind 7.3.2) - any restrictions on the capabilities of datatypes (DataType 7.3.11) A datatype instance may consume some storage in which case the concept of aggregation may be useful to clarify the storage management implications of a datatype property to its owning classifier in the composite aggregation case. The precise semantics of shared aggregation is explicitly acknowledged as a semantic variation point. Any restriction on the capabilities of datatypes must be compatible with the fact that two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that "The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers)" (note the "many-to-one correspondence).
Revised Text: n subclause 7.3.11 (DataType), under "Semantics", replace the first sentence of the second paragraph: 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 have 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. 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.
Actions taken:
December 8, 2003: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 6878: UML 2 Infrastructure / rule for redefinition of Property (uml2-rtf)

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

The isConsistentWith() query defined on Property implies that in order for a property redefinition to be logically consistent, the redefining property must be derived if the redefined property is derived. Are these the correct semantics for redefinition? There are cases in the metamodel where this constraint is violated (e.g. Package::ownedMember is not derived, but it redefines derived property Namespace::ownedMember). If there is to be a constraint on redefinition, perhaps it makes more sense the other way around, i.e. a redefining property must be non-derived if the redefined property is non-derived.

Resolution:
Revised Text:
Actions taken:
January 2, 2004: received issue
February 18, 2005: moved from infrastructure

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6921: Inheritance of 'Enumerations' is not detailed (uml2-rtf)

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

Inheritance of 'Enumerations' is not detailed with repsect to their (ordered) owned 'EnumerationLiteral's. 

Proposed resolution: Add a constraint to restrict Enumerations to be unable to inherit from each other (at least favored in MOF) or specify how Literals are ordered.

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 6922: Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R (uml2-rtf)

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

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment). 

Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

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

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 6927: UML 2 Super / Interactions / Ambiguous diagram tags (uml2-rtf)

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

Diagrams have a frame and a tag that describes the kind of diagram. Most diagrams correspond to a portion of the metamodel, and in most cases there is a one-to-one correspondence between metamodel chapters and diagram types, although variants are allowed for special cases (such as 'package').  There are four kinds of diagrams showing interactions, each with its own unique contents and syntax: sequence diagrams, communications diagrams, interaction overview diagrams, and timing diagrams.  Unlike the difference between class diagrams and package diagrams, for example, each of these is very different in appearance and content from the others, even though they allegedly all map to the same interaction model (which might be dubious in practice, given the very different content, but that's another matter).  However, the examples all use the same tag, 'sd', for all of the kinds of interaction diagram. Clearly 'sd' is an abreviation for 'sequence diagram' and it is inappropriate for the other types.  (The fact that it is an English-language abreviation is another problem that we will let pass for now.)  It would seem that each kind of diagram should have its own tag, given that they have different syntax and usage. For example, we could use 'sd', 'cd', 'iod', and 'td' if we wish to keep the same abbreviated format. But in any case the tags  should be different and they should be descriptive of the diagram, not the underlying modeling chapter. (The official tag for interaction diagrams as a group is 'interaction', not 'sd' (page 589), so 'sd' is already descriptive of just one variant.) 

If the argument is that you can tell apart the different variants of interaction diagram by looking at them, that argument would apply with even more force to the diagrams for different kinds of models, such as class diagrams, state machine diagrams, etc., so we wouldn't need tags at all. (Which may be true, and users will probably not bother most of the time, but let's at least get it right in the standard.)

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
January 23, 2004: received issue

Discussion:

While this is possibly a reasonable suggestion, it does not represent either a consistency
fix or a clarification and is more appropriately resolved in some future revision. This is an overall discussion and not only for Interactions. The question is about two
different aspects:
1. What should the tab keyword indicate?
a. the type of diagram
b. the object defined by the diagram
c. irrelevant, the tab is only for naming

Issue 6975: missing illustrations of graphical paths for create and destroy 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:

Table 15 does not include illustrations for 
  - create message (a graphical path flowing into a Lifeline head). 
  - create message to lost
  - create message from found


More illustrations need to be added to Table 15 as the new sorts of messages are added, for example:
  - synch and async create
  - synch and async destroy

Resolution:
Revised Text:
Actions taken:
February 16, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7051: StateMachine - Constraints (uml2-rtf)

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

"[1] The classifier context of a state machine cannot be an interface" 

should be: 

[1] The context classifier of a state machine cannot be an interface. not redefinitionContext.oclIsKindOf(Interface) 


"[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioral feature." 

should be: 

[2] The context classifier of the method state machine of a behavioral feature must be one of the classifier that features the behavioral feature 

-- note that a behavorial feature can be associated with 1..* -- classifiers if self.specification->notEmpty() then self.specification.featuringClassifier->includes(redefinitionContext) endif 

"[3] The connection points of a state machine are pseudostates of kind entry point or exit point." 

should be: 

[3] The connection points of a state machine are pseudostates of kind entry point or exit point. connectionPoint->forAll(cp | cp.kind = #entryPoint or cp.kind = #exitPoint ) 

"[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points." 

should be: 

[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points. self.specification->notEmpty() implies ( self.connectionPoint->forAll(cp | not (cp.kind = #entryPoint or cp.kind = #exitPoint) ) )

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
February 29, 2004: received issue

Discussion:

The OCL was left out of the final adopted specification and needs to be inserted.
However, the OCL constraints recommended above are mostly incorrect. Instead, the
following OCL expressions need to be inserted for constraints [1] through [4] of
StateMachine on page 490 respectively:
?? context->notEmpty() implies not
context.oclIsKindOf(Interface)
?? specification->notEmpty() implies
(context->notEmpty() and
specification->featuringClassifier->
exists (c | c = context))                                                                                                                                ?? connectionPoint->forAll
(c | c.kind = #entryPoint or c.kind = #exitPoint)
?? specification->notEmpty() implies
connectionPoint->isEmpty()

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 7223: Questions about DataTypes and generalization (uml2-rtf)

Click here for this issue's archive.
Source: Red Hat (Mr. Randall M. Hauch, rhauch(at)redhat.com)
Nature: Uncategorized Issue
Severity:
Summary:

I have a few questions regarding section 7.12 entitled "Kernel - the
DataTypes Diagram" in the final adopted Superstructure spec (03-08-02).


DataType specializes Classifier, and as such it also inherits the ability to
have generalization relationships with other Classifiers.  Classifier has an
additional operation 'maySpecializeType(Classifier):boolean' that is
described/defined as follows:


"The query maySpecializeType() determines whether this classifier may have a
generalization relationship to classifiers of
the specified type. By default a classifier may specialize classifiers of
the same or a more general type. It is intended to be
redefined by classifiers that have different specialization constraints."
(p. 63)


with the OCL:


        Classifier::maySpecializeType(c : Classifier) : Boolean;
        maySpecializeType = self.oclIsKindOf(c.oclType)


DataType, nor its subtypes PrimitiveType and Enumeration, defines no
additional constraints or additional operations.  These additional
constraints are executed/applied in the UML2 metamodel (rather than in a
UML2 model), correct?  If so, then this implies that a DataType may
specialize another DataType, Classifier, Namespace, Type, etc., but that
DataType may not specialize PrimitiveType or Enumeration.  Please correct me
if I'm interpreting this incorrectly.


Consider an example with:
*       a PrimitiveType named "string"
*       a PrimitiveType named "float"
*       a DataType named "InternationalPrice" that specializes "float" and
adds a new attribute/property called "currency" of type "string"


The "InternationalPrice" DataType is conceptually a qualified type, meaning
it is a float plus a qualifier of the value.  Examples of instances would be
{426.36, "US Dollars"}, {401.23, "Euros"}, {749.42, "Yen"}.


If my interpretations of the Superstructure spec are correct, then this
example cannot be modeled using UML2.  And, in fact, the specification would
actually allow me to create a new PrimitiveType named "double" that actually
specializes my "InternationalPrice" DataType (since DataType is a supertype
of PrimitiveType).  My thought is that this is either a issue with the
'maySpecializeType' operation or it is an issue with DataType, PrimitiveType
and Enumeration not being properly constrained.

Resolution:
Revised Text:
Actions taken:
April 6, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 7227: UML2 Super/Deployment/inheritance (uml2-rtf)

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

Deployment should not be a Dependency
Section 10.3.4, figure 126 show the Deployment subclass of Dependency
with location subsetting client and deployedArtifact subsetting
supplier.
This means in effect that a Node is deemed dependent on the Artifacts
that are deployed to it which seems to me the wrong way round if
anything.


Since it is not really true either that an Artifact is dependent on the
Node it is deployed to, it does not seem sensible for Deployment to
inherit from Dependency at all: it should inherit directly from
DirectedRelationship.


[Aside: Figure 126 shows 'subsets source' and 'subsets target' which is
not reflected in section 10.3.4. I had assumed that Dependency would
itself specify client and supplier to subset/redefine source and target
but this oddly appears not to be the case]

Resolution:
Revised Text:
Actions taken:
April 11, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 7229: UML2 Super/Deployments/Manifestation (uml2-rtf)

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

Manifestation should inherit from Realization


In Section 10.3.10 and Figure 124 it would make more sense for
Manifestation to inherit from Realization rather than directly from
Abstraction. The semantics of Realization are described as "A
Realization signifies that the client set of elements are an
implementation of the supplier set,.." which surely includes
manifestation. 
The spec also states that Realization may be used to model
transformations, which fits with the example given in Manifestation:
"<<tool generated>> and <<custom code>> might be two manifestations for
different classes".


BTW There is a missing word in the description of Manifestation "A
manifestation is the concrete physical of one or more model elements by
an artifact."

Resolution:
Revised Text:
Actions taken:
April 11, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7254: completion transitions (uml2-rtf)

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

Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors.

Resolution:
Revised Text:
Actions taken:
April 21, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 7255: Priority of the joint transition (uml2-rtf)

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

The specification says that: "The priority of joined transitions is based on the priority of the transition with the most transitively nested source state". Suppose that a join transition is has two transitions with source states at the same depth, but in two different regions. How is is established which of the two transition defines the priority of the join transition?. Notice that, depending on which transition is choosen, different other transitions might be allowed or disallowed to be fired. Some possible anwers are: - Any of the two transitions can be chosen statically. (i.e. the priority of the join transition always remains the same). - Any of the two transitions can be chosen, and the choice truly, completely nondeterministic (hence possibly dynamic) I.e. the priority of the join transitions can change each time the join transition is fired.

Resolution:
Revised Text:
Actions taken:
April 21, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7329: large overlap between structural features and variables (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:

There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
May 9, 2004: received issue

Discussion:

This is indeed the case but the issue needs to be addressed in greater depth since it is at
the core of the semantics of UML, and is out of scope of an FTF. 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 7337: inconsistency in the action model (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: Critical
Summary:

There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
May 15, 2004: received issue

Discussion:

Two comments on the issue text:
"there are other links in the model, such as those due to Connectors". The links
established due to connectors are just links any other (link = an instance of an
association).
"or one should generalize the link actions to apply to liks identified by any
StructuralFeature". Links cannot be identified by structural features that are not
association ends, because there are no links in that case.
In separate discussion with the filer, there was concern that structural feature were not
well enough defined to have actions defined on them. Structural feature inherits from
TypedElement, which provides a way to map to instances of a type, as explained in the
entry for Kernel::TypedElement. The structural feature actions provide the results of this
mapping, as explained in the semantics of StructuralFeature.
The filer would like this issue held for further discussion.

Issue 7338: metaattribute isReadOnly (uml2-rtf)

The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

Resolution:
Revised Text:
Actions taken:
May 15, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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

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 7372: surface notation for state machines (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 surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

Resolution:
Revised Text:
Actions taken:
May 24, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7398: Provide exception handling for all behaviors. (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:

UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.

Resolution:
Revised Text:
Actions taken:
May 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 7400: AssociationClass (uml2-rtf)

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

The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing.

Resolution:
Revised Text:
Actions taken:
May 31, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7620: Coupling between StateMachines and Activities (uml2-rtf)

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

As I was reading through the text of issue 6114 it dawned on me that there is a needless and problematic coupling between state machines and activities. Namely, in figure 187, there is an association from ObjectNode to State, presumably to deal with the old "object in state" idea. This is similar to the coupling that was attempted but rejected in the Interactions chapter.

While it may look attractive to have a formal link to the idea of State from state machines, there are two serious problems that make this much more trouble than it's worth:

(1) The notion of "object state" -- as seen by users/manipulators of that object -- could be completely different from the implementation state of that object. This is the old principle of hiding implementation. Viewed from the outside, an invoice object may be in the "Paid" state, but this does not necessarily mean that the object has such a state in its implementation. In fact, there is no guarantee that the implementation will be based on state machines at all. Of course, you can say that this is a reference to some kind of external state machine view of an object -- which sounds reasonable, but here is where the second problem comes in:

(2) State in the UML 2.0 spec comes with a sh..load of baggage: in effect, the whole state machine kit and caboodle. It's not very modular, and, unless you use profiles to shear away all the stuff that you don't want (which is about 99% of state machines machinery), you will force vendors who innocently just want to support the simple idea of "object in state" to implement all of state machines.

Like I say, the feature doesn't look worth it. Let your State concept be a simple name. My guess is that most users who want to use this feature don't even want to know what a state machine is (the concept of states is not necessarily linked to state machines!).

So, my suggestion is that in figure 187, you simply provide a subclass of ObjectNode called ObjectInState and give it a "stateName" attribute and you will get what 95% of your users want. Tying state machines to activities for that one little feature seems overkill.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
August 4, 2004: received issue

Discussion:

This is deferred for the same reasons as 6114. 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 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 7910: isComposite inconsistency in UML 2.0 and MOF 2.0 (uml2-rtf)

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

The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: -- isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. -- However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()->isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

Resolution:
Revised Text:
Actions taken:
November 15, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7952: Alternative entry and exit point notation is ambiguous (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:

Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

Resolution:
Revised Text:
Actions taken:
November 29, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7969: Section: 9.14.1 (uml2-rtf)

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

The allOwnedElements query (defined in Core::Abstractions::Ownerships) operates by recursing downward through the ownership hierarchy. Its OCL implementation looks like this: Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) In the absence of sophisticated optimization, this query is only guaranteed to terminate if the ownership hierarchy is non-circular. The ownership hierarchy is guaranteed to be circular by constraint [1] (An element may not directly or indirectly own itself). But the OCL description of constraint [1] is written in terms of the allOwnedElements() query: not self.allOwnedElements()->includes(self) If a modeling tool were to be written based on these rules in a straightforward way, it would never be able to detect a violation of constraint [1]. Instead it would go into infinite recursion while trying to check the constraint. Proposed solution: Add the following operation to 9.14.1: [3] The query isCircularlyOwned walks the chain of direct and indirect owners of an element, checking whether the chain contains any circularities, or any of the elements in the set prohibitedElements. Element::isCircularlyOwned(prohibitedElements: Set(Element)): Boolean; isCircularlyOwned = if owner->isEmpty() then false else if prohibitedElements->including(self)->includes(owner) then true else owner.isCircularlyOwned(prohibitedElements->including(self)) And change constraint [1] to: [1] An element may not be directly or indirectly owned by itself. not self.isCircularlyOwned(Set{})

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
December 5, 2004: received issue

Discussion:

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: Simula Research Laboratory (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 7993: Use case extension inconsistencies (uml2-rtf)

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

According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
Therefore it seems that the Extend.extendedCase property is redundant and should be derived.
 
Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}.
 
 
Proposed resolution
-----------------------------
 
1) Update Figure 401 to replace +extendedCase by +/extendedCase
 
2) Update Figure 401 to replace +useCase by +useCase {subsets owner}.
 
3) Section 16.3.3 Extend: update the Associations section to replace:
extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

by

/extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
No additional associations
 
by
 
useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)

Resolution:
Revised Text:
Actions taken:
December 20, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 7997: Too much navigability from Generalizations (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:

This is a significant issue with the Superstructure, Classes chapter, PowerTypes package, impacting implementability and consistency between products at different levels of conformance to UML 2.

I propose to simplify the abstract syntax to specify a one way arrow navigating a one-many metassociation from GeneralizationSet to Generalizations that belong to that set. The problem here is very much the same as the problem with dependency, but in a different part of the metamodel.

Figure 18, The contents of PowerTypes package shows a many-many navigable association between GeneralizationSet.generalization and Generalization.generalizationSet.

Problems with this:

1. only 1-way navigation is desired. As toolvendor I don't want to update the Generalization to have any info wrt what if any GeneralizationSets it belongs to. As a user, I do not want the generalization relationship itself, which is very simple in a UML Level 1 product, to be muddied with extra info in a UML product that goes beyond Level 1 by adding support for PowerSets.

2. only 1-many cardinality is desired. Although not navigable, a mapping from generalization to the generalization set is still provided in the metamodel, in a conceptual sense.

Point 2 is consistent with thinking of the specialization classifier in the generalization as being an instance of more than one powertype, because this classifier is just a participant in the generalization, it is the generalization that we want to have a mapping to at most one powertype. The scope of the required change is limited to the text and diagram specifying this metasssociation of GeneralizationSet.

Resolution:
Revised Text:
Actions taken:
December 22, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8012: Section: Classes, Behavior (uml2-rtf)

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

There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

Resolution:
Revised Text:
Actions taken:
December 29, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8014: Disjointness should be independent of generalization (uml2-rtf)

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

Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8016: Action for retrieving activity instance (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:

Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

Resolution: ReadSelfAction does this for behaviors that have no context object. The next RTF can either modify ReadSelfAction or add a new action to handle the case of a behavior with a context object. This is needed for reflective applications cited in the specification, see the semantics of Activity. Disposition: Deferred
Revised Text:
Actions taken:
December 30, 2004: received 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 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, antoine.lonjon(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 8020: constrainedElement direction (uml2-rtf)

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

constrainedElement direction The association between Constraint and Element named "constrainedElement" is unidirectional from Constraint to Element. This means implementations are not required to provide efficient navigation from an element to the constraints on it. Since the constraints of a model element are part of the definition of that element, the required navigation should at least be from the element to the constraint.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8022: Derived union 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:

Derived union notation Why is the semantics and notation for subsetting/redefinition in Association, while derived union is in Property?

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8023: Association specialization 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:

Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean?

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8024: End objects of a link In the semantics of AssociationClass (uml2-rtf)

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

End objects of a link In the semantics of AssociationClass, it says: 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". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8026: Contextualized attribute values Figures 121 (uml2-rtf)

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

Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8034: Notation for classifierBehavior (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 classifierBehavior metaassociation (Figure 311).

Resolution:
Revised Text:
Actions taken:
December 30, 2004: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8071: ClassifierInState not supported in UML2.0 ? (uml2-rtf)

Click here for this issue's archive.
Source: GOO Tech (Mr. Birol Berkem, birol.berkem(at)goobiz.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.
 
Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

Resolution: This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance.
Revised Text: In Subclause 12.3.38, under "Changes from Previous UML" add the following sentence at the end of the paragraph: Use of the inState association replaces ClassifierInState in UML 1.5 for activity modeling.
Actions taken:
January 4, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8077: Properties on Association for end objects (uml2-rtf)

Click here for this issue's archive.
Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm(at)johndeere.com)
Nature: Revision
Severity: Significant
Summary:

The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

Resolution:
Revised Text:
Actions taken:
January 5, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8087: All sections (uml2-rtf)

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

With the new format of putting all of the diagrams at the beginning of the chapters, I am finding it very difficult to determine which diagram goes with what sub-section. Add references in the text to the diagram most applicable to the descriptions/definitions

Resolution:
Revised Text:
Actions taken:
January 14, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8101: Clarify the differences between redefining element and redefined element. (uml2-rtf)

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

Clarify the differences between redefining element and redefined element.

Resolution:
Revised Text:
Actions taken:
January 20, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8102: Multiple typos in ptc/04-10-02 (uml2-rtf)

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

Multiple typos (If you don't want them submitted this way, I'll complete an issue for each.) section 6.34 page 11 Delete word �to� in �The read/write actions can also be used to by one�� section 7.3.3 page 38 Delete word �If� in the Note �If the lower multiplicity for an end of�� Section 7.3.5 page 46 Correct typo �pr� to �or� in ownedParameter:Parameter[*] Section 7.3.11 page 60 Change �has� to �have� in 2nd para 2nd sentence �Instances of a data type that �has��� Instances is the subject of the sentence Section 7.3.11 page 61 Add word �to� to Notation sentence 6 �In this case, cone or more arrows with their tails on the clients are connected �to� the tails�� Section 7.3.20 page 71 Change �is� to are in generalizationSet �Designates a set in which instances of Generalization �are� considered members.� The verb refers to the subject of the which clause (instances). Section 7.3.21 page 83 Change �is� to �if� in last sentence of section �Or, �if� a new subclass�� Section 7.3.32 page 97 Change �These constraint� to �These constraints� Section 7.3.32 page 98 Delete word �is� in 2nd sentence of Notation �In general, the notation will include a multiplicity specification shown as�� Section 7.3.37 page 111 Change �is� to �are� in 4th paragraph of Semantics �The public contents of a package are�� Subject of the sentence is contents not package. Section 7.3.49 page 135 and page 136 (Description) Change verb �specify� to �specifies� in �A structureal feature is a typed feature of a classifier that specifies the structure�� Section 7.3.49 page 137 Change verb from �signifies� to signifying� in 1st sentence of Decsription Section 7.3.53 page 139 Delete word �of� in 1st sentence of Semantics

Resolution:
Revised Text:
Actions taken:
January 21, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8111: Section: 9.3.4 (uml2-rtf)

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

OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints

Resolution:
Revised Text:
Actions taken:
January 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8113: Section: 9.3.6 (uml2-rtf)

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

Need OCL notation for Constraints. Correct page reference number for StructuredClassifier

Resolution:
Revised Text:
Actions taken:
January 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8114: Section: 9.3.7 (uml2-rtf)

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

Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added.

Resolution:
Revised Text:
Actions taken:
January 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8126: Section: 9.3.11 (uml2-rtf)

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

According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints

Resolution:
Revised Text:
Actions taken:
January 25, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8142: Section: 10.3.11 (uml2-rtf)

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

Need to write the info for the Changes from previous UML section or remove it

Resolution:
Revised Text:
Actions taken:
January 26, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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: Simula Research Laboratory (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 8246: namespace (uml2-rtf)

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

The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

Resolution:
Revised Text:
Actions taken:
February 5, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8249: Section: 12.3.33 (uml2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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:
Revised Text:
Actions taken:
February 7, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8260: Section: 12.3.40 (uml2-rtf)

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

Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation

Resolution: Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it - and, since it merges it, cannot reference elements from it.
Revised Text: In Section 12.3.40: - In the title, after "OutputPin" add "(from CompleteStructuredActivities, StructuredActivities). - After the first paragraph add: Generalization "OutputPin (from Basic Actions)" on page 268 (merge increment) In Figures 12.21 and 12.22, change the uses of UML::Actions::BasicActions::OutputPin to UML::Activities::CompleteStructuredActivities::OutputPin (but shown with an unqualified name).
Actions taken:
February 8, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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: Simula Research Laboratory (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: Simula Research Laboratory (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 8274: UML2/Infra section 11.6.2/ Enumerations should not have attributes (uml2-rtf)

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

11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).
 
Proposed resolution:
Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8278: section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification (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 Super (but not Infra) EnumerationLiteral inherits from InstanceSpecification.
This allows a single Enumeration value e.g. 'private' or 'red' to have many slots (InstanceSpecification.slot).
Moreover it allows the value to have many classifiers (InstanceSpecification.classifier) independently of the Enumeration that owns the EnumerationLiteral - it does not make any sense to have this redundant property.

All that is needed surely is a value: so if anything EnumerationLiteral should inherit from ValueSpecification. However this still inherits too much: for example an EnumerationLiteral should be owned only by its Enumeration and so should not inherit from PackageableElement as does ValueSpecification. Furthermore inheriting from TypedElement seems to introduce capability that is not catered for in the notation etc: if anything the underlying type for an Enumeration should be specified at the Enumeration not the EnumerationLiteral level (which would allow the different alternatives for an Enumeration to have different types).

The only useful capability on EnumerationLiteral is that it should have a name (which is all that Infrastructure allows), and optionally a value. The latter should be specified in the same way as the default value of a Property.

Proposed resolution:
EnumerationLiteral should inherit only from NamedElement.
It should have an optional property:
value:ValueSpecification [0..1]

The Notation section should describe how to indicate the value, which should be the same as for the default value of a Property

Resolution:
Revised Text:
Actions taken:
February 14, 2005: received issue
February 14, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8332: inconsistent description (uml2-rtf)

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

There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8335: ReadStructuralFeatureAction (uml2-rtf)

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

This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8342: Section: 14.3.18 (uml2-rtf)

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

Second sentence in sub-section Description is missing a word. "...the contents of the referred Interaction xxx [from?? to??] where the InteractionUse is." Change the class name of the association argument:InputPin[*] either on fig 333 to InputPin or to Action in the text. Class name in fig. 333 is Action. This association is also shown in the figure as ordered. Association actualGate:Gate[*] subsets ownedElement. Mention specialization in definition of the association. I'm confused between the BNF use of io-argument and your use of argument. If the name of the association is "io-argument" as indicated by BNF and Issue 1751, should the name on the diagram and in the sub-section Associations be changed to io-argument? Also, para 2 on og 534 italizes argument instead of io-argument. Typo - Second sent. on pg. 534 needs a space between "explained" and "in."

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8353: Section: 14 (uml2-rtf)

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

Add Ocl notation to constraints where possible or note that OCL notation is not possible. Page numbers of odd numbered pages are not in the same place as the are for other chapters. Move them to the lower right corner. Delete sub-section headings where the sub-section contains no information or state "None." If a concept is not "(as specialized)" and there are no atttributes, associations, etc. write "None" instead of "No additional xxx." Not all of the figures contain package names for the generalized parents. Add as many of these as possible or use the ellipses as appropriate.

Resolution:
Revised Text:
Actions taken:
February 24, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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: Simula Research Laboratory (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 8414: Section: 14 (uml2-rtf)

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

How to show class operation calls in interaction diagrams? A discussion in the umlforum list came to the conclusion that the name in the lifeline header should be the class name. In that case it is not possible to differentiate between "ClassName" only and "RoleName" only. Besides the notational problem I can't see how a class operation call could fit into the interaction meta-model. However it is necessary to show such a call. It's a typical part of an interaction.

Resolution: Disposition: Deferred to UML 2.4 RTF
Revised Text:
Actions taken:
March 1, 2005: received issue

Discussion:

The issue here is to be able to describe calls on static methods. Sequence diagrams in
UML 2 do not cover this. It is possible to suggest that the lifeline header text be
augmented by the possibility to write class as a keyword before the class name. This
would indicate that the lifeline represents the imaginary object performing static methods
of that class. There will, however, be cascading effects on static requirements since this
lifeline does not have any counterpart in the composite structure of the enclosing
classifier. For reasons of time pressure, we suggest to defer.

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 8447: Section 15 (uml2-rtf)

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

General comments - Delete sub-sections tat are empty or state "None." If class is not "as specialized' do not say "No additional xxxx" but rather "None" or delete the sub-section. Add OCL notation or a note that OCL notation is not available for constraints and/or additional operations and/or derived attributes where appropriate.

Resolution:
Revised Text:
Actions taken:
March 3, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8450: Default values for ValueSpecification are not specified properly (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 are a few cases when the default is documented as a ValueExpression, as follows: 
-        JoinNode.joinSpec = {default value is" and"} 
-        ActivityEdge.guard= {default value is "true"} 

These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification. 

They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be: 

        +guard = LiteralBoolean(true) 

The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true. 

Recommendation: 

Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends.

Resolution:
Revised Text:
Actions taken:
March 4, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8464: Section: 16.3.1 (uml2-rtf)

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

Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

Resolution:
Revised Text:
Actions taken:
March 4, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8473: Activities section (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:

Add presentation option for multiple object flows between two actions, shown as one line.

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8474: 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:

Enumeration should have a constraint that the classifier of its literals is the enumeration

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8475: Section: Interactions (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: What object receives SendEvent, etc? Affects how AcceptEventAction is used

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8479: Section: Activities - clarification (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 the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

Resolution: The clarification that is required is on Constraint [3] of Section 12.3.23 ExceptionHandler (in UML 2.2, ptc/08-05-05). Note that, as stated in the issue, the constraint can only be formalized within the Activities clause for structured nodes, because, before merging with BasicActions, only structured nodes are modeled as having output pins.
Revised Text: In Section 12.3.23, replace Constraint [3] with: [3] If the protected node is a StructuredActivityNode with output pins, then the exception handler body must also be a StructuredActivityNode with output pins that correspond in number and types to those of the protected node.
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8480: Section: Activities : Why is exception type needed? (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 ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8489: ExpansionRegion (behavior in the shorthand 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 ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

Resolution: The shorthand notation does not actually require that the behavior have exactly one return parameter. However, it should be clarified that the expansion nodes shown in the shorthand notation should correspond one to one to the input and output pins of the behavior.
Revised Text: In Section 12.3.27 (ExpansionRegion), under Notation, at the end of the paragraph immediately preceding Figure 12.83, add: In the shorthand notation, there must be one input expansion node corresponding to each in or inout parameter of the behavior (which must have at least one such parameter) and one output expansion node corresponding to each out or inout parameter of the behavior.
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8492: Section: Activities, 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:

In LoopNode, setup, test, and body parts should be owned by the loop node (they were owned by clauses of loop node, which were owned by the loop node).

Resolution: The setup, test and body parts of a loop node should all identify nodes that are contained within the loop node. Such nodes are already owned by the loop node via the node association inherited from StructuredActivityNode. However, a constraint needs to be added to ensure this containment, and to ensure that any all executable nodes contained in the loop node are, indeed, in the setup, test or body parts.
Revised Text: In Section 12.3.35 (LoopNode), under Constraints, before the existing constraints, add: Package StructuredActivities [1] The union of the ExecutableNodes in the setupPart, test and bodyPart of a LoopNode must be the same as the subset of nodes contained in the LoopNode (considered as a StructuredActivityNode) that are ExecutableNodes.
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8495: Add constraints on ConditionalNode (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 ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

Resolution: Agreed that nodes in the test and body part of the clauses of a conditional node must be owned by the conditional node and that these parts should be disjoint.
Revised Text: In Section 12.3.17 (Clause), under Constraints (Package StructuredActivities) add: [2] The test and body parts must be disjoint. In Section 12.3.18 (ConditionalNode), under Constraints, before the existing constraint, add: Package StructuredActivities [1] The union of the ExecutabledNodes in the test and body parts of all clauses must be the same as the subset of nodes contained in the ConditionalNode (considered as a StructuredActivityNode) that are ExecutableNodes. [2] No ExecutableNode may appear in the test or body part of more than one clause of a conditional node. Package CompleteStructuredActivities
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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 8501: SequenceNode should have way to set output pins in CompleteStructured (uml2-rtf)

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

SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

Resolution:
Revised Text:
Actions taken:
March 6, 2005: received issue

Discussion:

Disposition:	Deferred to UML 2.4 RTF

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::paramete