Issues for Mailing list of the Unified Modeling Language 2.5 (UML) Finalization Task Force

To comment on any of these issues, send email to uml25-ftf@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 17581: Conformance point (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Title: Conformance point
Where: section 2
Nature of Issue: Revision
Severity of Issue: Significant
Full Description of the Issue:
* Dependencies among conformance points are not stated in all the case. Particularly, when they are no dependency, this need to be pointed out. 
* I don't understand the last paragraph which seems nevertheless to open a door to the most permissive conformance point ever read: does that say that if a vendor don't want to do everything s/he just have to state so and this is good? As a UML tool users, I cannot imagine this.
* "Where the UML specification provides options for a conforming tool, these are explicitly stated in the specification": such options should also be gathered in this section for clearness.
* What is the status of the section 6 wrt conformance and particularly 6.3 about UML semantics? At least, add a reference to 6.3 in the "Semantic conformance" bullet and in section 6 specify which chapter is informative and which is normative

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17582: Clarification on the semantics of UML (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of UML
Where: section 6.3.1
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
It is not clear form the text:
* What is the 'state' of an object/individual?
* Are events and behavior 'objects'? Ie are they described by classifiers?
Are classifiers also objects? Ie can a classifier describe another classifier?

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17583: Clarification on the semantics of Multiplicities (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of Multiplicities
Where: section 7.5.3
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
Multiplicitie: both ValueSpecification should be of the same type and of a type which has a total ordering defined on it and upper should be superior to lower.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17584: Clarification on the semantics of Parameters (uml25-ftf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of Parameters
Where: section 9.4.3
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
the 'effect' on a Parameter is not multiple but couldn't a parameter be read *and* updated or created?

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17585: Clarification on the semantics of Properties (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of Properties
Where: section 9.5.3
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
* AgregationKind: "if a composite instance is deleted, all of its parts are normally deleted" what does mean 'normally'? Which other case could arise? 
* Does the definition of "composite" imply that an element can't be part of two composite instances in the same time? If yes, it should be stated so.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17586: Clarification on the semantics of Connectors within Structured Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of Connectors within Structured Classifiers
Where: section 11.2.3
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17587: Clarification on the semantics of ports in Encapsulated Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of ports in Encapsulated Classifiers
Where: section 11.3.2
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).
* The concept of 'side' of a port is not explained enough, depending if it is a port or a port on a part.
* "if there is  a Connector attached to only one side of a Port, any requests arriving this Port will be lost" does it also stand for port which are not 'on a part'? Because in that case, the Port is an external boundary and a Connector may only be inside the Encapsulated Classifiers, may it not?

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17588: Clarification on the aim of Collaborations (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the aim of Collaborations
Where: section 11.7
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
"It (purpose of Collaborations) is intended as a means for capturing standard design patterns": could you please elaborate on this because this is not trivial. An example would also be welcomed.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17589: Clarification on the semantics of inheritance between use cases (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of inheritance between use cases 
Where: section 18
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
It appears in figure 18-11 as it is implied by the abstract syntax that inheritance among use cases is possible. The semantics of such an inheritance needs to be described.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17590: Clarification on the semantics of Manifestation (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Title: Clarification on the semantics of Manifestation 
Where: section 19.3.3
Nature of Issue: Clarification
Severity of Issue: Minor
Full Description of the Issue:
The semantics of Manifestation is not defined in 19.3.3.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17592: Declassifying of Annex D (uml25-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Title: Declassifying of Annex D 
Where: Annex D
Nature of Issue: Revision
Severity of Issue: Minor
Full Description of the Issue:
This annex is too poor (only sequence diagrams are dealt with) to be called 'normative'.

Resolution:
Revised Text:
Actions taken:
September 13, 2012: received issue

Issue 17596: How to model a transition to history pseudostates in two orthogonal regions? (uml25-ftf)

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

A transition that terminates on the outside edge of a composite state is called a default entry. In this case, the default entry rule is applied e. g. the transition originating from the initial pseudostate is performed. If the most recently active substate prior to this entry shall become the active substate, the transition must be drawn to a history pseudostate. Page 564 clearly states this. 


Next, the composite state is extended to an orthogonal state with two regions. Both regions contain a history pseudostate. A transition shall fork to both history states. I thought this is easy to model by introducing a fork pseudostate in the transition and drawing two outgoing transitions from the fork to the history pseudostates. 


This is obviously not the case as constraints rule 3 on page 582 states: "A fork segment must always target a state. (source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (target.oclIsKindOf(State))"


It is also mentioned at other locations that an outgoing transition of a fork pseudostate must target a state. Pseudostates are not allowed as targets of outgoing transitions from a fork pseudostate. 


I am confused by this rule. My question is: How do I have to model a transition ending on the history states in two orthogonal regions?

Thanks for your kind advice.

Resolution:
Revised Text:
Actions taken:
September 17, 2012: received issue

Issue 17600: Four typos (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

1. 13.4 Classifier Descriptions, Association Ends, p315
"Behaviosr" -> "Behavio(u)r"


2. 7.4.3 Semantics, Namespaces, p32
"A namespace may also import NamedElements ...". "namespace" should be capitalised ("Namespace").


3. 7.8 Classifier Descriptions, ElementImport [Class], Attributes, p49
"whetherthe" -> "whether the".


4. 9.9 Classifier Descriptions, Operations, p165
"is the same or a subtype as" -> "is the same or a subtype of".

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17601: Missing word in section 7.4.3, "Semantics" (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

"associated whose subexpressions"

There's clearly a word missing between "associated" and "whose".

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17602: PDF links to Primitive Types don't work (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

The comprehensive hyperlinks in the PDF version of the specification are useful when reading it online. However, the links for the Primitive types (Boolean, Integer, String, Real, UnlimitedNatural) don't work.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17603: Fuzzy diagrams (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

When viewed at high magnification (e.g. 500%), most of the diagrams in the PDF are quite fuzzy, and are clearly bitmaps. If possible, please regenerate them as vector diagrams.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17604: Suggested improvements to conformance section (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

p15: "A conforming UML 2.5 tool shall be able to load and save XMI in UML 2.4.1 format as well as UML 2.5 format." It would be worth inserting a reference to Annexe E (p 784) which gives a rationale for this conformance requirement.

p15: "A tool demonstrating diagram interchange conformance can import and export conformant DI ..." Similarly, it would be worth inserting a reference here to Annexe B (p736) on UML Diagram Interchange.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17605: Semantic conformance implies Abstract Syntax conformance (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

The conformance statement notes that "Model interchange conformance implies abstract syntax conformance" and "Diagram interchange conformance implies both concrete syntax conformance and abstract syntax conformance". 

As far as I can tell, Semantic conformance implies Abstract Syntax conformance. For consistency, this could also be noted.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17606: Further clarify Element ownership constrains (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:


13. p26: "Every Element in a model must be owned by some other Element of that model ..." 

"Some" could perhaps be more precisely stated - "Every Element in a model is owned by exactly one other Element of that model ..."

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17607: Clarify ownership vs. membership for NamedElements (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:


"A namespace may also import NamedElements from other Namespaces, in which case these, along with the ownedMembers, are members of the importing Namespace."


A sentence clarifying ownership vs. membership for NamedElements would be useful. As far as I can tell, every NamedElement is owned by the Namespace in which it was created, but is a member of both its owning Namespace and every Namespace into which it has been successfully imported.

(However, where a NamedElement is a PackageableElement, importing it creates an ElementImport which becomes a member of the Namespace instead, to allow for the possibility of aliasing of the PackageableElement's name.)

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17608: Same name" vs. "indistinguishable name" (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

" ...it also excludes PackageableElements that would have the same name as each other when imported."


Surely this should say " ... it also excludes PackageableElements that would have indistinguishable names when imported."

(See discussion of Namespace semantics on p33).

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17609: Clarify aliasing in Namespaces (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

A couple of sentences explaining aliasing in Namespaces would be useful in the Namespace semantics section (7.4.3).

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17610: ElementImport semantics (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

"An ElementImport identifies an Element in a different Namespace, and allows the Element to be referenced using its name without a qualifier in the Namespace owning the ElementImport."


Firstly, different to what?


Secondly, "its name" is confusing, since the name may be changed via aliasing.

I think this should be rewritten as: "An ElementImport identifies a NamedElement in a Namespace other than the one that owns it, and allows that NamedElement to be referenced using an unqualified name in the Namespace owning the ElementImport."

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17611: Consistent use of "conforms to" vs. "is a subtype of" (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

"The query conformsTo() gives true for a Type that conforms to another."


While the OCL throughout the text does indeed use the conformsTo() operation, the textual descriptions alongside the OCL mix references to "conformance" with references to "one Type being a subtype of another".


For clarity, I suggest that either all these uses of "subtype" in the text are replaced by references to "conforms to" or (less preferable), some text is included in this description on p65 to say that "subtype" is a synonym for "conforms to".

It might also be useful to include some words about type conformance in the very-short description of the Semantics of Types in section 7.5.3 (p37).

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17612: isConsistentWith() definition broken (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

The definition of "isConsistentWith(redefinee : RedefinableElement) : Boolean" is broken in at least two ways.


Firstly, the OCL includes the term "op.ownedParameter->at(1)" which should presumably be "op.ownedParameter->at(i)" (substitute letter "i" for digit "1"). 


Secondly, the OCL and textual definition say that each parameter is checked for conformance in the same direction, regardless of whether they're "in" or "out" parameters.


To deliver a safe substitutability (aka conformsTo) relationship, the "in" parameters of the substituting operation must conform to the "in" parameters of the substituted operation, but the "out" parameters must conform in the opposite direction (i.e. "out" parameters of the substituted operation conform to the "out" parameters of the substituting operation).


Since "inout" parameters pass parameters in both directions, they must conform in both directions simultaneously (which is a good definition of being "the same type").

Correcting the first bug is trivial. However, unless the second bug is also corrected, the given definition of isConsistentWith() will flag many type-safe substitutions as "not consistent", and many unsafe substitutions as "consistent". It *must* be corrected.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17613: Inconsistent approach to type conformance (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

The specification makes inconsistent statements about checking that communication between objects takes place according to the parameters of the communication mechanisms used.

1. In some places the specification says that UML does not attempt to define a type-safe conformance relationship:

1.1 On p128, in Semantics of Operations, it says:

"Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, such rules for type conformance are intentionally not specified."

1.2 On p308-309 it says:

"A method of an Operation shall have Parameters corresponding to the Parameters of the Operation. ... The data values associated with a request - input Operation parameter values or Signal attribute values - are then passed to a method invoked due to the request via the method parameters. ...

However, no one approach is defined for matching the Parameters of the method to the Parameters of the BehavioralFeature. Possible approaches include exact match (i.e., the type of the corresponding Parameters, order, must be the same), co-variant match (the type of a Parameter of the method may be a subtype of the type of the Parameter of the BehavioralFeature), contra-variant match (the type of a Parameter of the method may be a supertype of the type of the Parameter of the BehavioralFeature), or a combination thereof."

2. On the other hand, in several places the specification *does* try to define rules for type conformance, with varying levels of success:

2.1 On p158 isConsistentWith is defined on operations, apparently in an attempt to test whether a operation can be redefined in a type-safe way. While the isConsistentWith semantics are broken on at least two counts (see separate issue report), this is an attempt to define a rule for type conformance on operations (albeit with a different name).

2.2 p187: "By declaring a Reception associated to a given Signal, a Classifier specifies that its instances will be able to receive that Signal, or a subtype thereof, and will respond to it with the designated Behavior." i.e. Signals must be passed in a type-conformant way.

2.3 p252: "A Port may be redefined when its containing EncapsulatedClassifier is specialized. The redefining Port may have additional Interfaces to those that are associated with the redefined Port or it may replace an Interface by one of its subtypes." Again, this is type conformance on Ports. There's similar language for redefining Connectors in a type-conformant way on p248.

2.4 p424: "If the ObjectNode is untyped then the Parameters shall also be untyped. Otherwise, the input Parameter shall have either the same type as or a supertype of the ObjectNode, while the output Parameter shall have either the same type or a subtype of the ObjectNode." Again, this is type-conformant.

Conclusion - there are several places where UML *does* intentionally define rules for type conformance. For consistency, either these type conformance rules should be removed or (preferably), the unhelpful statements (1.1 & 1.2 above) that UML does not enforce type conformance should be removed, and replaced by appropriate definitions of type conformance on Operations (perhaps based on a debugged version of isConsistentWith).

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17614: Superfluous word on p309 (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:


"(i.e. the type of the corresponding Parameters, order, must be the same)"

The word "order" and the two commas are superfluous.

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issuye

Issue 17615: "Object identity" undefined (uml25-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

UML semantics depend on "object identity", an undefined concept

The rearrangement of UML concepts in dependency order, to minimise forward references, is nicely done in this specification. It highlights how careful UML is about defining all the concepts it uses (with the exception of the primitive types in Section 21, which are explicitly imported into the language).

However, the term "object identity" is explicitly or implicitly used in a few places in the specification, but never defined. Worse, its introduction leads to undefined semantics for part of the language.

1. References to the undefined concept "object identity".

1.1 p38 "That is, no two values in the collection may be equal, where equality of objects (instances of Classes) is based on object identity ..."

1.2 p184 "A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."

This is an implicit reference to Class instances being identified by something other than their value (presumably their "object identity"). However, we search in vain for the corresponding text in the section on the semantics of Class to tell us how Class instances are identified.

1.3 p488 "A TestIdentityAction is an action that tests if the two values given on its InputPins are identical objects ...

If an object is classified solely as an instance of one or more Classes, then testing whether it is the "same object" as another object is based on the identity of the object ..."

2. Undefined semantics as a result

2.1 p488 "The result of a TestIdentityAction for objects that are classified by both Classes and DataTypes, or by other kinds of Classifiers, is not defined, but, in all cases the Action produces a Boolean result."

Conclusion
----------
Either the specification should define "object identity" (although this would still leave TestIdentityAction undefined under some circumstances), or (preferably) this undefined, implementation-level concept should be replaced by a definition of equality grounded in the equality of Primitive Types (with equality on all other Types being recursively defined in terms of equality on Primitive types).

Resolution:
Revised Text:
Actions taken:
September 19, 2012: received issue

Issue 17746: Issue for UML 2.5 FTF against Clause 9: Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 9.6.4.  There is no notation for raisedException.  Can we add a notation?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17747: Section 11.2.4 clarification - Clause 11: Structured Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Clarification
Severity:
Summary:

Section 11.2.4 says “Detail may also be shown within the part box indicating specific values for Properties of the part’s type when instances corresponding to the Property are created.”  What does this mean?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17748: Section 11.3.4 isService clarification - Clause 11: Structured Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.4 says “A Port of an EncapsulatedClassifier is shown as a small square symbol”.   Does this perhaps only apply to Ports for which isService is true?  The definition of isService would certainly seem to imply that a Port marked with isService = false would not appear on parts, for example.  RSA hides the port when you make isService = false.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17749: Section 11.5. - Clause 11: Structured Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.5.4 says “Generalizations between Associations can be shown using a generalization arrow between the Association symbols”.  What about shared target style and generalization sets? Is a conforming tool required to do these for association generalizations?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17750: Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

 

Section 11.7 has no content or notation for template Collaborations.  There was material in UML 2.4 section 17.4.7 about these.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17751: UML 2.5 FTF issues for Clause 18: UseCases (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The condition of an Extend is a Constraint.  What are its constrainedElements?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17752: Minor vs Major revision (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Current text: 
“Version 2.5 is a minor revision to the UML 2.4.1 specification. It supersedes formal/2011-08-06”

However, in 6.1 Specification Simplification, we have the following text. 
This specification has been extensively re-written from its previous version to make it easier to read by removing redundancy and increasing clarity. In particular, the following major changes have been made since UML 2.4.1: 

Notice that it identifies major changes

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17753: Missing Table of Figures, Table of Tables - Location: TOC p 10 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17754: Capture Submitters, Supporters, etc (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

If section 0 is going away at some time, don't we still need to capture the submitters, supporters, and friends.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17755: Impact of merging profiles isn't small (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

While the L3 profile only contained 3 stereotypes, that doesn't make this change small and by implication trivial. My expectation was that it should be trivial for tools to migrate 2.4.1 models to 2.5. However if both L2 and L3 profiles are applied to a package, this isn't the case and it isn't clear how any associated data should be merged. I understand the motivation for combining the profiles, but I don't think this should happen in 2.5.

There is no mention of this migration issue in Annex E, which suggests that merely changing the version numbers is sufficient.

Proposed Resolution:

Continue to have separate profiles in 2.5 and consider merging them with full migration information in future UML version.
Source: dave.hawkins@oracle.com

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17756: Conformance definitions ? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

current text: “
A detailed definition of ways in which UML tools can be made conformant with this specification. 

As there is no separate conformance level, it appears that there is only one “way” to be conformant. Perhaps the whole sentence should be scratched.

Clause 2 covers types of conformance not ways of conformance. so perhaps there is just a mismatch of terminology

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17757: DI Conformance implies Model Interchange Conformance (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Doesn’t DI conformance imply MI conformance?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17758: ISO version of UML 2? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Though it might be ok to mention that we are not based on the 19502:2005 technology, recently ISO/IEC have accepted UML 2.4.1, and that is more important to be mentioned. I don’t remember the correct document #.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17759: Keyword Usage (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

In the referenced document title, the terms OPTIONAL, REQUIRED, RECOMMENDED, and NOT RECOMMENDED are also defined. Our documents also use some of these terms. Is the usage of these terms conformal to RFC 2119?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17760: List attributes whose ordered property has change in UML 2.5 (uml25-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

Summary: As an aid to tool vendors, can properties whose {ordered} status has been changed be identified in the text or listed here?
Proposed Resolution:  Add described text.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17761: Show how UML is a MOF metamodel (uml25-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

We often say something like "UML is a MOF metamodel" or similar.  It would be useful, I think, to show somewhere, perhaps in this subsection, exactly how that happens.  For example, UML Classifier is an instance of MOF Classifier (right?), but nowhere do we actually SHOW how this happens. I think it would be instructive to show the general audience explicitly how this happens.
Proposed Resolution:  Add described text.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17762: Section Unbalanced (uml25-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

The section needs some introductory material. What's here is good, useful and interesting stuff, but its purpose and why it's located at this point in the spec is not sufficiently motivated.  The material presented is also somewhat unbalanced.  For example, §6.3.1 calls out three model element categories: Classifiers, Events, and Behaviors.  Then §6.3.3 contains some nice text on semantics of Behaviors, but nothing further is said about Classifiers or Events. Suggest some text for the two missing categories should be added -- if they are important enough to mention, they deserve discussion.
Proposed Resolution:  Add described text.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17763: Incarnation ? (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Delete "within an incarnation"  This is confusing

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17764: Within the System (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Change 'within a system' to 'to one or more objects'. This will be consistent with the references to objects in the other two bullets in this section. Also, the event may have a consequence outside the system.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17765: Modeling Individuals (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Why is instance specification not included?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17766: UML Semantics (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

The UML semantics are defined in the UML spec. This is confusing.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: reeived issue

Issue 17767: Two categories is not enough (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity:
Summary:

Using only 2 semantic categories forces Use Cases into the Behavioral semantics category, which is not appropriate by the definition. An additional category of Intentional, Goal, or Requirement Semantics is needed to cover the Use cases. This is supported by the Use Cases clause not being in the behavior section of the document.

Making this change will probably required changes to the diagram of diagrams in Appendix A and Figure 6.1 below. However as these are only explanatory (not normative) they should not impact users, except to make it more understandable.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17768: Semantics Areas section not clear (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

Figure 6.1 gives some semantic areas and the following paragraphs are intended to describe them. I don't think this is done terribly clearly. In particular the specific terms given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base);  it's not clear what the middle area actually is as the diagram doesn't name it; and the structure of the paragraphs doesn't match the areas.

The middle paragraph, "The base behavioral...", is particularly unclear - I don't think the second clause of the first sentence actually makes sense. It also includes a 'Note' that isn't really a note at all since it gives a fundamental property of the behavioral semantics.

Proposed Resolution:

Add titles to the diagram to identify the areas, perhaps on the right hand side:
Higher-level formalisms
Base behavioral semantics
Structural semantics

Make each paragraph correspond exactly to an area in the diagram. This largely means that the middle paragraph should be rewritten to include the actions text and object communication information. (Why not just call the *-Object Behavior Base, "Object Communication"?)

Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17769: Figure 6.1 does not relate to rest of Specification (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

Many of the items given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base);  

Proposed Resolution:
Redo diagram using items from the specification or explicitly correlate the items to areas within the spec.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17770: Sentence does not make sense (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

Sentence beginning paragraph 
The base behavioral semantics of UML builds on this structural foundation, addressing both the basic framework of the execution of behaviors and such execution may result….

The use of both in this sentence prepare the reader for two semi-parallel items. The sentence does not have such. 

Proposed Resolution:
Redo sentence to discuss the behavioral section of the diagram Figure 6.1

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17771: Extraneous Note (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Note starting 
Note that this framework only deals with event-driven,…

This note interrupts the explanation of the diagram and side-tracks it, and is essentially irrelevant to the main topic. 

Proposed Resolution:
Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17772: Definition of invariant condition (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Critical
Summary:

This is not the normal interpretation of invariant conditions, and I believe it has no support in UML 2.4.1. The typical definition for invariant condition is that it must be true (it must hold) whenever it is checked, pre, post, and during. However, it need not hold while the object is not at a stable point and not query-able (not inspectable), but it must be true when and if the condition can be checked (by normal means). In an environment with multi-threading, this is often done with locks of some sort.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17773: What type of slash? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

This is a good place to show if it’s a forwards or backwards slash

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17774: How does dot notation work (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Does the Dot indicate the owning side or the non-owning side? Some clarification is needed here.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17775: Add reference to association notation section (uml25-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

Suggest adding a reference to the section where association end notations are discussed.  When I got to figure 7.1, I realized that no one had yet told me what a ball or a colored diamond on an association end meant. I don't think we can assume that readers will necessarily have enough past history with UML to know all of this stuff without the spec being explicit.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17776: Owning Comments (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

All comments should be owned.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17777: Root Abstract Syntax missing adornments/metamodel incorrect (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

The ends "relationship", "directedRelationship" (x2) should all be {readOnly, union}. This appears to be wrong in the metamodel.

Proposed Resolution:

Update metamodel.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17778: Descendants rather than specializations (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The Elements and Relationships sections both use the term "Descendants". Surely the term used here should be Specializations? I suspect this may be more widespread than just this section (7.2.4 contains another example).

Proposed Resolution:

Use specialization rather than descendants.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17779: Owning Comments (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

If every Element in a model must be owned by some other Element of that model, with the exception of the top-level Packages of the model, then all Comments, as Elements, must be owned. The Root diagram has ownership for comments being optional, owningElement [0..1]

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17780: Owning Rules (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint that all Elements are owned, except the top element.
Also, the text refers to models and packages, yet these are not defined yet. Perhaps there should be forward reference to model, and the reference to package should be deleted.
Source: Sandy Friedenthal
Discussion:
Are root packages required to be "models"?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17781: Can Comments own comments? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Does this mean that Comments can own Comments?  It looks like Comments can annotate Comments, which is not a problem. Can Comments own anything else?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17782: Bound Element Semantics overly specific (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

Point 2 ("If the copy...") seems to be overly specific for this section. Shouldn't this information be part of the Generalization and Operation semantics?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17783: Template Notation example (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

This could really do with a graphical example.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17784: Namespace Abstract Syntax incorrect (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

memberNamespace should be readOnly and union. This appears to be wrong in the metamodel.

Proposed Resolution:

Update metamodel.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17785: Clarification of imports (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Type: Clarification of imports
The following are not obvious: 
1) Can a non-package namespace, such as a class, have a package 
import relationship to a package? From the metamodel yes

2) Can a namespace, of any type,  do a element import of a package?
From the metamodel yes

3) Can a package do an element import of a attribute?
From the metamodel yes

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17786: Note refers to an undiscussed concept (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The sentence "Note that the set..." talks about unqualified names, but there isn't any discussion of what those actually are so the note seems rather out of place.

Proposed Resolution:

Change sentence to simply describe the use of unqualified names rather than being a confusing note.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17787: Missing word (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

"In a template ..., a NamedElement may have an associated ? whose..."

Is this supposed to be StringExpression?

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17788: Packageable Elements and Imports (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Why not separate this into two sections. One on packageable elements and the other on imports. They are distinct concepts and belong in distinct subclauses. Under the packageable element subclause, note that elements that are not packageable are generally  owned by a type/classifier, such as behavioral and structural features.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17789: Packageable Elements and Imports (02) (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

an a package, being a packageable element, be a TemplateParameter? This needs to be explained.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17790: ElementImport cannot be further imported (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

An imported Element that is publicly visible can be further imported...using either ElementImports..."

While this is true for PackageImports, it isn't for ElementImports. The ElementImport directly references the PackageableElement so other ElementImports are irrelevant

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17793: Imports (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

The meaning of access should be described above under the import section

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17794: Incorrect text describing diagram elements (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

"the<RresourceKind>
"theFacilitySpecification
theQualificaion
are all not in the diagram

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17795: Missing TypedElement (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Should this figure include a reference from MultiplicityElement to TypedElement, since MultiplicityElement constrains the numbers of values of the TypedElement

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17796: Missing TypedElement - use of the term constrained seems to be circular (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

use of the term constrained seems to be circular. Perhaps delete 'constrained to be'.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17797: Confusing description of types (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The description of types isn't terribly clear. There are several uses of "this" and "represents" that aren't clear. The third sentence, "Values..." uses "element" and seems to be repeating the second sentence.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17798: Unclear description of multiplicities (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The first paragraph talks about "cardinalities", but it isn't really clear to which set this cardinality refers. I think the first two paragraphs need to be reworded to talk about a collection of values before talking about cardinalities.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17799: While-->And (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Too much emphasis on contrast

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17800: Missing OCL (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

No OCL for the rules for calculating the lower value of a multiplicity as given in text in 7.5.4 Notation / Multiplicity Element

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17801: inconsistent spacing on diagram (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

First attribute
purchase : Purchase [*]….
Second attribute
account: Account [0..5]

Inconsistent space between name and “:” distracts from message of diagram
Source: Michael Jesse Chonoles

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17802: Missing a (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Ms. Dominique Poudret, dominique.poudret(at)oracle.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

"attached to set" should read "attached to a set"

Proposed Resolution:

Add the missing "a".

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17804: Instantiate Dependency (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Shouldn't the Car class depend on the CarFactory class? (as the text states)  It doesn't seem like the instance of CarFactory depends on instance of Car which the figure suggest

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17805: Use of the diamond symbol (?)needs to be explained (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Place in the material explaining the format of the spec.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17806: Single and set of aren't really parallel (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Original:
	that a single or a set of model Elements requires 

Proposed Resolution:
	that a single model Element or a set of model Elements requires

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17807: Inconsistent use of (s) (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

Sometimes a property with upper bound > 1 is referred to as having "Elements", for example, and sometimes "Element(s)". Dependency::client, Dependency::supplier, DirectedRelationship::source, DirectedRelationship::target all use the latter whereas ElementElement::ownedComments and Constraint::constrainedElements use the former. I'm sure there are many other examples. I think the former is better stylistically. (For what it's worth, Oracle's corporate documentation standards regard the use of parenthesized plurals as bad practice.)

Proposed Resolution:

Consistently use plurals rather than plural(s).

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17808: Excessive null checks (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

There are lots of checks for whether lowerBound() and upperBound() are null in various operations. However when would either of those operations return null? And if either of them did, wouldn't it just be invalid?

Source: dave.hawkins@oracle.com

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17809: allNamespace description doesn't match OCL (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

The allNamespaces operation is described as "working outwards." However the OCL uses the prepend operation, which produces a sequence that works inwards.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17810: Sentence difficult to read (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Current Text
The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package. 
	
Rewrite using simple sentences

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17811: It seems to me that a relationship requires a minimum of two relatedElements (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

It seems to me that a relationship requires a minimum of two relatedElements

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17812: TypedElement description could be expanded (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The description of TypedElement should say something about it representing values, which the Type description implies.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17813: Generalization Relationship to itself? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Generalization Relationship: 
A subclass of the owning package, 
or a superclass of the owning package or
Does the owning package have a generalization relationship to itself?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17814: Negatively phrased sentence (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Is there some way of saying this clearly?

Outside the nearest enclosing Package, a NamedElement marked as having package visibility is not visible. Only NamedElements that are not owned by Packages can be marked as having package visibility

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17815: Need table correlating Literals with symbols (+,-,#,~) (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. John Watson, john_watson2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

There does not seem to be anywhere where there is any coorelation between the symbols and their meaning. If anything, it would be useful here. 

Throughout the document, readers are referred to 7.4 (where the enumerations) is defined, but that doesn’t help us to know what +, - … mean.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17816: Optional String Multiplicity (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Why is the multiplicity for String include 0, but the multiplicities for the other literals do not? LiteralString should be as optional as LiteralBoolean

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17817: Default value for LiteralString (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

Why does LiteralString have no default value? suggest the Empty string. Discussion: 
If the answer to this relates to problem 8.001, then a detailed explanation is required in the spec.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17818: Default value for LiteralReal (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Why does LiteralReal have no default value?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17820: LiteralNull semantics (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

This makes no sense to me. The absence of a value is modeled by the absence of a value, particularly given that UML provides no CollectionTypes to model the multiplicity of values.If the upper bound is one, then LiteralNull could possibly be an alternative to a Literal'NotNull', but it isn't an empty set. If the upper bound is greater than one, how are any of the values really represented in UML?If LiteralNull is to be an optional value, it should derive from LiteralBoolean, LiteralReal. etc.

Suggest delete LiteralNull or redefine it solely for use as the '0' of a [0..1] multiplicity.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17821: String concrete syntax is missing (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Specifying a Concrete Syntax requires just that. It must provide a solution to expressing all characters in a predictable fashion. So given the constraint of "..." encapsulation, how are internal " represented? How are Unicode and newlines expressed? Suggest reusing the OCL 2.3 clarification of backslashes. The concrete syntax comprises a sequence of zero or more characters or escape sequences surrounded by single quote characters. The [B] form with adjacent strings allows a long string literal to be split into fragments or to be written across multiple lines.[A] StringLiteralExpCS ::= #x27 StringChar* #x27
[B] StringLiteralExpCS[1] ::= StringLiteralExpCS[2] WhiteSpaceChar* #x27 StringChar* #x27

where

StringChar ::= Char | EscapeSequence

WhiteSpaceChar ::= #x09 | #x0a | #x0c | #x0d | #x20

Char ::= [#x20-#x26] | [#x28-#x5B] | [#x5D-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

EscapeSequence ::= '\' 'b' -- #x08: backspace BS
| '\' 't' -- #x09: horizontal tab HT
| '\' 'n' -- #x0a: linefeed LF
| '\' 'f' -- #x0c: form feed FF
| '\' 'r' -- #x0d: carriage return CR
| '\' '"' -- #x22: double quote "
| '\' ''' -- #x27: single quote '
| '\' '\' -- #x5c: backslash \
| '\' 'x' Hex Hex -- #x00 to #xFF
| '\' 'u' Hex Hex Hex Hex -- #x0000 to #xFFFF

Hex ::= [0-9] | [A-F] | [a-f]

A minor change could share the syntax definition and define the body as above prohibiting un-escaped usage of the character used as the surrounding quotes.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17822: Unlimited Natural (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

'unlimited' is called 'infinity' in UML 2.4, 'unlimited' in OCL, 'unbounded' in Section 21.The comment that 'unlimited' is not 'infinity' does not make any sense to me. If it is unlimited then any value from 0 all the way to infinity is permissible, so the upper bound is indeed infinity.

Suggest the mathematically consistent 'infinity' and remove the note.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17823: Notation: Real (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

The wording for Real allows '000.9' and '+.9' as valid numbers. Permitting redundant leading zeroes is undesirable given the usage of leading zero as octal in some languages. Permitting the omission of a leading zero is also undesirable. The equivalent wording in OCL 2.3 is better but not perfect. "A real literal consists of an integer part, a fractional part and an exponent part. The exponent part consists of either the letter 'e' or 'E', followed optionally by a '+' or '-' letter followed by an exponent integer part. Each integer part consists of a sequence of at least one of the decimal digit characters. The fractional part consists of the letter '.' followed by a sequence of at least one of the decimal digit characters. Either the fraction part or the exponent part may be missing but not both."UML and OCL should have compatible definitions.

What is the concrete syntax for +/- infinity?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17824: BNF rules allow for a real 0 (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

BNF rules allow for a real “0”

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17825: Past vs Present (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

specify computed values is a past tense potentially implying an already computed value. Suggest either specify computable values or specify computation of values

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17826: {ordered} at wrong end (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

{ordered} on wrong end of StringExpression.subExpression

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17827: Plural headers when class name is singular (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Title is plural, class name is singular. Should be singular to give clear PDF bookmarks

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17828: Semantics Clarification (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

What are the relative semantics of 'symbol' and 'name'? What are the relative semantics of 'type'?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17829: Orphan Title (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Orphan title. Use Keep with Next style

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17830: set - > list (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

concatenating a set of substrings. concatenating a list of substrings

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17831: sentence unclear (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

one or subExpressions of it may should be or one of its subExpressions may

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17832: body text strings (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

may have a body that consists of a sequence of text Strings should be may have a sequence of body text Strings

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17833: OCL not indexed (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Index OCL

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17834: String expression notation missing (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

This is unclear. Several examples are needed

missing string expression notation

What is it? "aaa" + "bbb" ???

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17835: Expression examples unclear (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

These are unclear. How many Expression nodes in "plus(x,1)"? Is "xor" well-formed without arguments?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17836: Event (uml25-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Should there be a specific metaclass for event that DurationObservation and TimeObservation refer to.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17837: Time constant (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Time constant means something else to me.
	Suggest: constant time value

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17838: Duration (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

What does it mean to have both an expr and an observation?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17839: Always non-negative (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Duration is always non-negative value, so re-write text
“A Duration is a non-negative value, often an integer expression ….

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17840: missing headings (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Missing headings for DurationInterval, TimeInterval, DurationConstraint, TimeConstraint.
These must be distinct to fully populate the PDF Bookmarks.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17841: Wrong Reference (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

The notation in Figure 17.5 for timing annotation on sequence diagram does not match the almost identical diagram of Figure 8.5

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received isuse

Issue 17842: Duration Definition (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

"the temporal distance between two time instants "

is not necessarily true. The value may be derived by an arbitrary computation over the set of observations. Could be three standard deviations.

Suggest "a temporal distance as a DurationObservation or as a computation over a set of observations

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17843: Improve readability of constraint names (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

IMHO  NoExprRequiresObservation is more readable than no_expr_requires_observation which is important since the text may well appear in tool error messages.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17844: Invariant name (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

The invariant is unnamed in the OCL snippet, but named in the editorial text.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: rewceived issue

Issue 17845: What is a DurationConstaint (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

I've read the description of firstEvent four times and I still do not understand it. Rewrite so there is a simple if/else that avoids the need to do detailed comparison between two very similar sentences.

Suggest:

A DurationConstraint is a Constraint that refers to a DurationInterval. which may be the interval between execution entering and  exiting a single constrained element, or between selectable enter/exit events on a pair of constrained elements.

...
When there are two constrainedElements, firstEvent[i] is true to select the enter, or false to select the exit event for execution of the corresponding constrainedElement.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17846: What is a DurationInterval (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

What is the "range" between two durations. Is it a statistical property? is it max to max, min to min, ....?? Ah. I get it. This is a spectacularly confusing class name. Introducing an alternate editorial term compounds rather than mitigates the problem. Use "distance" in the descriptions, then users might grasp that it is not a time interval. In max/min refer to larger/smaller duration rather than range. 
---
Discussion
Source: Edward Willink
I'm stll very confused, if two duration are being compared in some way, such that the min and max of the range is being found, then the durations must either be duration constants, or offset from some observation. If the two durations do not use the same observation, then there should be no duration interval?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17847: What is a DurationInterval (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

Identifies is better than points out. 

Subsequent description is confusing about one/two NamedElements.

Suggest:

It identifies either a NamedElement whose enter and exit events are observed, or a pair of NamedElements for each of which either an enter or exit event is observed.
...
When there are two events, firstEvent[i] is true to select the enter, or false to select the exit, event for observation of the corresponding event. ---

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17848: one -- > first (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

the first NamedElement is better than one event Element

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17849: incompatible multiplicities (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

It defines a symbol is inconsistent with the [0..1] multi

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17850: More detail on Express (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

What is a symbol? Suggest: a symbol such as "+" may be used to define the functionality of a particular expression node.

Are there any semantics for the inherited name? Suggest: the inherited name may be used to give distinct identifications to expression nodes. 

Are there any semantics for the inherited type? Suggest: the inherited type may be used to identify the type resulting from evaluation of the expression node.

What type should be used for a set of values? Suggest: a domain-specific type system may be appropriate to represent a richer or more specific variety of values than can be modeled directly in UML.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17851: Range Confusion (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

'range' is a bit confusing again. Use 'intervening distance', so that (temporal) distance is a consistent terminology.

Use 'larger ValueSpecification' or 'ending ValueSpecification' rather than 'maximum value of the range'

Use 'smaller ValueSpecification' or 'starting ValueSpecification' rather than 'minimum value of the range'

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17852: Like to overridden definition (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: Significant
Summary:

In e.g. LiteralInteger and LiteralNull on p 91 (and the rest)there is no hyperlink from isComputable() to the overridden definition and indeed no qualified name to aid manual navigation.
Consider 
Move 6 versions of isComputable() to LiteralSpecification.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17853: Why is value optional (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Why is value optional

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17854: Bad Description, observation has no value (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Bad description; observation has no value.

Suggest:

Observation specifies the event or events observed to determine a TimeExpression or Duration.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17855: Bad Description (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Unnecessarily wordy suggest just:

An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or a textual expression in some language.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17856: Set--> List (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Location: 8.6 p 94 OpaqueExpression Description

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17857: French (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

I guess you mean something "OCL", but you could mean "French"

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17858: Intended to Produce (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

How does the isIntegral determine the intent of the expression. It can only determine if the expressions produces an integer. Redefine

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17860: result() error (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

Surely invoking result on a non-behavior is invalid?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17861: Two anonymous invariants (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Significant
Summary:

Two anonymous invariants violates distinguishability.
Simpler
inv BehaviorHasResult: behavior <> null impliesbehavior.ownedParameter->size() = 1 and behavior.ownedParameter->forAll(direction=ParameterDirectionKind::return)

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17862: Too many alls (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Too many 'all's; remove all in front of all the component values.

Suggest just: ... concatenating the ordered String values of each operand or subExpression. 

Simplerbody: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17863: Why can’t the operand be a stringExpression (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Enhancement
Severity: Minor
Summary:

Too many 'all's; remove all in front of all the component values.

Suggest just: ... concatenating the ordered String values of each operand or subExpression. 

Simpler body: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17864: What incompatible about sub-expressions and operands (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

The problem seems solvable

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17865: Simplify (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

firstEvent[i] is true to select the enter, or false to select the exit event to constrain execution of the constrainedElement.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17866: Simplify (Location: 8.6 p 97 TimeExpression) (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

The worded requirement should be in OCL, possibly deferring the issue to a clear definition of isConstant().

expr <> null and observation->isEmpty() implies expr->isConstant()

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17867: Min/Max (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

More consistent to use 'temporal distance' rather than range.

max ... refers to the later time.

min ... refers to the earlier time.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17868: Location: 8.6 p 98 TimeObservation ...simplify (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Simpler:
A TimeObservation identifies a time instant at which execution either enters or exits a particular NamedElement.
...

firstEvent[i] is true to select the enter, or false to select the exit event when observing execution of the NamedElement

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17869: Save Space (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Consider saving space by listing Diagrams, Generalizations, Specializations on the same line as their title.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17870: 8.6 p 100 isCompatibleWith() ..save space (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Change
The query isCompatibleWith() determines if this Parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. In addition, for a ValueSpecification, the type must be conformant with the type of the specified ParameterableElement (which must have a type, since it must be a kind of ValueSpecification). 

to

The query isCompatibleWith() determines if the self ParameterableElement is compatible with the specified ParameterableElement.  A ValueSpecification extends the default that the ParameterableElement P is compatible with ParameterableElement Q if the kind of P is the same or a subtype as the kind of Q. Additionally, the type of self must be conformant with the type of the specified ParameterableElement (which must have a type, as it must be a kind of ValueSpecification).

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17871: Turing Machine lurking paradox? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity:
Summary:

Turing Machine lurking paradox?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Discussion:

The isComputable() can not deteremine whether something is computable without trying to compute it?...It might never fail, …

Issue 17872: Reword isComputable (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity:
Summary:

This is woolly just redirecting to 'can be computed'.

Suggest: A ValueSpecification can be computed when all the algorithms, resources and values required to perform a computation are available. So a ValueSpecification would not be computable if an operation without a body was invoked, an off-line processor is required, or a source value is required. isComputable() is intended to be a static determination of capability, so a computation failure such as divide-by-zero or an I/O
failure would not prevent isComputable() returning true, rather they would cause a query
such as realValue() to return no value. 

?? if a computation needs a currently locked resource, is it computable? Probably yes, since if the computation waits patiently the result will appear ?? 

?? Should be three-valued...

True => a computation now will run
False => a computation now will abort
Null => a computation now might abort

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17873: IsNull not Boolean (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

IsNull not Boolean

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Discussion:

Surely the result is three-valued. null, !null, cannot compute. So Boolean[0..1].

Issue 17874: Association Descriptions not that useful (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Association Descriptions not that useful

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Discussion:

When there is an Owned End, the corresponding Member End is listed as an 'opposite' rather than a Member End.

When there is no Owned End, the listing of Member Ends is uninformative.

The listing of Associations is of mixed benefit.

Less might be better:
 - just a title and a hyperlink to the Diagram(s).

More would be better:
- full descriptions of all ends
-- {redefines ... on a new line
-- opposite as a Member End

Issue 17875: Objects? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

It should probably be instances not objects, based on 9.2.3

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17876: the parent of a Classifier is not its owner.” (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity: Significant
Summary:

current text: “Note: the parent of a Classifier is not its owner.”

[AC] This note is not completely clear, in my opinion, maybe because it relates two unrelated concepts (generalization and ownership) without sufficient explanation in the context of this description.

Furthermore, I could interpret the note in different ways:
*	the parent of a Classifier is not necessarily its owner 
*	the parent of a Classifier may not be its owne
Proposed Resolution:

Update metamodel.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17877: What is inherited or not (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity:
Summary:

current text: “When a Classifier is generalized, certain members of its generalizations are inherited, that is they behave as though they were defined in the inheriting Classifier itself.”.

[AC] This sentence suggests that some members are inherited, some are not. In the following sentence it is explained, as examples, that attributes and operations are inherited. But which are members that are NOT inherited? Are there examples, or, better, rules?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17878: Inherited members (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity:
Summary:

current text: “For example, an inherited member that is an attribute has a value or collection of values in any instance of the inheriting Classifier, and an inherited member that is an Operation may be invoked on an instance of the inheriting Classifier.”.

[AC] An attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17879: Incompatible with SysML (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

This is not compatible with SysML, which I believe calls them "constraints" --> Location: 9.2.4 p 110.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17880: Location p.112 (9.3 Classifier Templates) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity: Minor
Summary:

[AC]  Since this section is (in my opinion) an advanced topic, and a feature of the UML not always used by most practitioners, I would rather move it after the sections about features, properties, and operations

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17881: Location: p.116 (9.4.3 Semantics) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity: Significant
Summary:

current text: “For each instance of a Classifier there is a value or collection of values for each direct or inherited non-static attribute of the
Classifier” 

[AC] Again, an attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity. In the following sentences is discussed the upper multiplicity, but never the lower one.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17882: Multiplicity of 0..0 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Location:  p 117 Not handled / discussed

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17883: Alterative Scopes? (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Title: Alterative Scopes?
current text: “Inherited static StructuralFeatures shall have one of two alternative semantics, within a given execution scope:
1. The value of the StructuralFeature is always the same for any inheriting Classifier as its value for the owning Classifier.
2. The StructuralFeature has a separate and independent value for its owning Classifier and for each Classifier that inherits it.”

[AC] This is not clear to me. Which one of the semantics apply in a certain execution scope?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17884: Examples of alternative scopes? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Can you say more about these options. I don't know but, for example, is #1 Ada and #2 Objective C.
Some explanatory comment might help.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17886: Redefinable Static attributes (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Are static structuralfeatures redefinavble? Are they redefinable only ounder scope 2?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17887: Default value of readonly should be referenced (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “If a StructuralFeature is marked with isReadOnly true, then it may not be updated once it has been assigned an initial value. Conversely, when isReadOnly is false, the value may be modified at any time.”

[AC] I would say that when isReadOnly is not marked (i.e. is false, that is the default, see page 163) then the values can be modified.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17888: Return Parameter order (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “A single Parameter may be distinguished as a return Parameter.“

[AC] This sentence should be placed after the following one, and made clearer. I guess its meaning is “Only one Parameter may be marked as return

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17889: Return Parameter pronoun (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Its type is ParameterDirectionKind”.

[AC] The subject of this sentence should be the Direction property, but the pronoun comes after another sentence, whose subject is differ

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17890: Effect Intent (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Significant
Summary:

current text: “The effect property may be used to declare additional indications of the effect on values passed in or out of a Parameter. It is a declaration of the modeler's intent, and does not have execution semantics: the modeler must ensure that the Parameter has the stated effect.”
[AC] The implementation, not the modeler, must ensure the effect.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Discussion:

Or perhaps the Modeler must ensure that the implementation  has the stated effect? Unclear. It is preferred that the tools should be able to either force or verify this
Michael Jesse Chonoles

Issue 17891: inout parameters and effects (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Problem: 9.023
Severity: minor
Type: clarification
Location: 9.4.3 p 118
Title: inout parameters and effects 
Description:
Current Text:
Only in and inout Parameters may have a delete effect. Only out, inout, and return Parameters may have a create effect.

1)	What is passed out for a deleted inout Parameter
2)	What happens to the input if a create effect is applied to an inout Parameter

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17892: isException and direction and effect (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Current text: The isException property applies to output Parameters

1)	Does this mean that isException can apply to inout parameters?
2)	Should isException always have effect=create?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17893: Parameter Sets (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

AC] The last two paragraphs in the 9.4.3 section are about ParameterSets. They are really unclear to me. I guess ParameterSets are intended to be only defined and used when an alternative exist, but an example would be in my opinion very useful.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17894: ParameterSet Notation (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Notation for parameterset in a standard operation calls is very needed. If parametersets are used in an activity diagram, it may not be possible to match this up with an operation on the class, either in a list of operations or from a sequence diagram

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17895: Use isReadOnly default (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Enhancement
Severity: Minor
Summary:

current text: “A read only StructuralFeature is shown using {readOnly} as part of the notation for the StructuralFeature. This annotation may be suppressed, in which case it is not possible to determine its value from the diagram. Alternatively a confirming tool may only allow suppression of the {readOnly} annotation when isReadOnly=false. In this case it is possible to assume this value in all cases where {readOnly} is not shown.”

[AC]  In the metamodel, isReadOnly=false is the default. If nothing is shown, the default should be assumed, I suppose

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17896: Redefinition does not allow for overloading (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

Feature redefinitions may either be explicitly notated with the use of a {redefines <x>} property string on the Feature or implicitly by having a Feature with the same name as another Feature in one of the owning Classifier’s more general Classifiers. In both cases, the redefined Feature shall conform to the compatibility constraint on the redefinitions. 

By allowing reuse of the name to cause redefinition, you prevent overloading. A class should be allowed to more than one operation with the same name with different argument lists.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17897: What is aggregation (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Composite aggregation is a strong form of aggregation that requires a part (see 11.2.3) instance be included in at most one composite instance at a time.”

[AC] It could be also useful to explain in general terms what an aggregation (whether shared or composite) is.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17898: What is “Intentionally Not specified”? (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “The precise lifecycle semantics of composite aggregation is intentionally not specified.” (and two following sentences)

[AC]  Is it explained somewhere in the spec what is the meaning of the “intentionally not specified” expression? Not by bad intentions, I suppose, but the reader may wonder why.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17899: What is “Intentionally Not specified”? (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “A Property may be marked, via the property isID, as being (part of) the identifier (if any) for Classifiers of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple Properties are marked (possibly...”

[AC] I would specify “are marked as isID (possibly…”

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17900: Location: 9.5.3 p 121 Why not all empty (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

If only one instance has all values with the isID true to be empty, what’s the problem.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17901: Location: 9.5.3 p 122 In the common case (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

Suggest: In the specific case

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17902: Location: 9.5.3 p 122 Qualifiers must be enumerated type (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

I believe qualifiers must be constrained to be an enumerated type. For example, can an qualifier be a real number?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17903: Location: 9.5.3 p 121 Can’t qualifiers be queries? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Qualifiers should be able to be queries that return an enumerated type that otherwise meets the criteria for qualifiers. This would allow for different mapping to the set at the other end, that might be situationally determined.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17904: Location: 9.6.3 Operations p 127 Undefined ? (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

this sounds peculiar. 
Intentionally undefined by the modeler, or by the authors of the specification. 
In think this should say
The behavior of an invocation of an Operation when a precondition is not satisfied is not defined in UML

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17905: Location: 9.6.3 Operations p 127 (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Significant
Summary:

current text: “The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.”

[AC] The concept of bodyCondition is not explained, and I fear it is less known that the concepts of precondition and postconditions, that are explained. On page 158, it is said that only query operations may have a bodyCondition. An explanation would be useful.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17906: Location: 9.6.4 Notation p 127 Simplify description of syntax (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

AC] This section on the syntax of operations is complex in itself, but also too hard to read. Maybe a little more structure could improve its readability. E.g. separate the template operation syntax from the previous part.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17907: Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17908: Location: 9.6.4 Notation p 128 Is return a reserved parameter name? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example: 

toString(return : String) 

means the same thing as 

toString() : String

Why is this true. The 1st example, could be interpreted as an operation with a parameter named “return”.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17909: Location: 9.7.5 Examples p 134 Generalization Sets (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Significant
Summary:

[AC] Figures 9.23 and 9.24 are, in my opinion, misleading. It seems, based on these examples, that either the generalization set name is shown, or the relative constraints (e.g. {incomplete, disjoint} ), while both could be shown. Same problem in previous figures, from 9.17 to 9.20

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17910: Location: 9.7.5 Examples p 135 Political Correctness (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

When you say that the generalization by Gender into woman and man is complete and disjoint you are making a politically sensitive statement. You need a caveat, perhaps as a footnote, acknowledging that you are only using this for sample syntax purposes and not claiming facts about the world.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17911: Location: 9.8.3 Semantics p 139 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

and if one classifier is abstract and one is not (and they are not realized by generalization)

It would seem that if any of the classifiers are abstract, the instancespec only partially describes the instance?  This need explanation

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17912: Location: 9.8.4 Notation p 141 (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “If the InstanceSpecification is shown using an enclosing shape (such as a rectangle) that contains the name, the ValueSpecification is shown within the enclosing shape.”

[AC] How would otherwise be possible to show an InstanceSpecification?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17913: Location: 9.8.4 Notation p 141 representing the roles vs representing the instances (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

a bit confusing. It says:
may contain nested rectangles representing the instances playing its roles 

Do you mean
may contain nested rectangles representing the roles the instance is playing? Please clarify nearby

Give an example with the roles

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17914: Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity: Minor
Summary:

Correct Typo (done). Also I have doubts about the upper multiplicity.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17915: Location: p 145 (3X) Detail: simultaneously -- > concurrently (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

These words mean something different. Concurrently would include overlapping calls, simultaneously means at the same instant.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17916: Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Revision
Severity: Minor
Summary:

current text: “guardedMultiple invocations of a BehavioralFeature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the currently executing BehavioralFeature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks.” 
Typo: should be locks.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17917: Location p 145 Classifier Description - objects -> instances (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Objects are not defined in the spec, while instances are

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17918: Location p 145 Classifier Description: objects -> instances (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “A Classifier represents a classification of objects according to their Features. Classifiers are related by Generalizations.”

[AC] Classifiers are also related by other relationships

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17919: Location p 146 Classifier Description: isAbstract (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “isAbstract : Boolean [1..1] = false
If true, the Classifier does not provide a complete declaration and cannot be instantiated.”

[AC] I would remove “does not provide a complete declaration and”, because the completeness of declaration is not the point of abstraction.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Discussion:

The isAbstract indicates an intent, a Classifier with isAbstract = true, may possibly have all features complete. 
The implementation may enforce that it cannot be instantiated, but should not force that all features are complete
Michael Jesse Chonoles

Issue 17920: Location p 152 Generalization Attributes: IsSubstitutable (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Significant
Summary:

current text: “isSubstitutable : Boolean [0..1] = true Indicates whether the specific Classifier can be used wherever the general Classifier can be used. If true, the execution traces of the specific Classifier shall be a superset of the execution traces of the general Classifier. If false, there is no such constraint on execution traces. If unset, the modeler has not stated whether there is such a constraint or not.”

[AC] I have always assumed that substitutability is a fundamental characteristic of generalizations, not an option. I may be wrong, of course, but I would like to see in the spec a discussion of this topic. If it is in the spec, I have not found it.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17921: Location p 153 complete_and_disjoint: Complete vs covering? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Location p 153 complete_and_disjoint: Complete vs covering?

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17922: Location p 153 complete_and_disjoint: Abstract Implication (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

I'm not sure this is correct. i see the logic of saying this, but I can imagine circumstances where the generalization would be complete and disjoint, but the generalization class would be useful to instantiate as a temporary until I determine which one of the subclasses it is. 

Forcing it to be abstract is a coding style limitation, which should not be required

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17923: Location p 154 Association Ends: Instances of multiple classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

If there can be more than one classifier, there could be more than one structuralfeature with the same name. How are these handled, or notated. They may have different types. 
Could also have two operations with the same name.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17924: Location p 157 isConsistentWith: missing rules (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Even though an operation it has the same # of parameters and the type is the same, does not really make the types match.
For example, changing effect or unique--> nonUnique would change the “effective” type though not in a way that UML recognizes

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17925: Location p 162 two_parameter_sets: Why (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

It should be possible to have two parametersset that are the same, but taking different paths in the activity diagram

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17926: Location p 162 ParameterSet constraints input: Exceptions and parameterset (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

It appears that as Exceptions are not streaming, they must be part of a output ParameterSet. Practically, they may be part of all of the output ParameterSets.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17927: Location p 162 ParameterSet associationends: Exceptions and parametersets (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17929: p 118: isException and other outputs (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

An output posted to a Parameter with isException true during an invocation of a BehavioralFeature excludes outputs from being posted to any other outputs of the BehavioralFeature during the same invocation. 

This does not seem to match description of how exception handlers work later. I would rewrite it:

Proposed text:
An output may be posted to a Parameter with isException true during an invocation of a BehavioralFeature. When this occurs, unless an ExceptionHandler catches the exception, other outputs are not posted from the BehavioralFeature during the same invocation. When an ExceptionHandler catches the exception, outputs are posted from the BehavioralFeature at the level of the ExceptionHandler.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17930: Location: 9.6.4 Notation p 128: Confusing indentation (uml25-ftf)

Click here for this issue's archive.
Source: Everware-CBDI (Mr. James L. Logan III, jllogan+omg(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

The line 

"[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}’]]" 

has its terms defined under the bulleted list after the first un-indented "where", except for "<parameter-list>". 

That term is defined one level too deep, where "<oper-property>" terms are defined. 

The bullet found there (i.e., "<parameter-list> is a list of Parameters of the Operation in the following format:") should become the third bullet in the first level of bullets.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17931: Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

An Enumeration that specializes another may define new EnumerationLiterals; in such a case the set of applicable literals comprises inherited literals plus locally-defined ones.

“New” could mean completely new, or it could be redefined, that is, changing the value for an existing literal. Please be clear, specifying which types of changes are allowed

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17932: Location: 10.2.4 Notation p 184 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

What is the Name of literal compartment?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17933: 10.2.4 Notation p 184. - Enumeration attributes and operations (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Current text:
The attributes and operations compartments may be suppressed, and typically are suppressed and empty.

What could be in the attributes compartment?

Could you have operations on an enumeration, such as predecessor, successor ?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17934: Location 10.3.3 Signals p.186 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

I’m not sure “object” is the best word. 

1)	Object is methodology based. Prefer using instances
2)	Can the reception of a signal be a static scoped behavior?, therefore being a class not an object

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17935: Location 10.3.3 Receptions p.186 - exceptions for receptions? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Can’t receptions have out exceptions?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17936: Location 10.4.4 Notations p.188 - Reception compartment (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Where does the unmentioned reception compartment go?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17937: Location: constraints class_behavior p.190 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

current text: 
If a behavior is classifier behavior, it does not have a specification

Why is this so. How do you handle classifier behavior that has parameters (sometime called object behavior). It’s usually started by the constructor.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17938: Location: Constraints p 193 - Missing constraint? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

ownedReception + ownedOperation >0

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17939: Location: Constraints p 193 - All feturs must be public? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Why
An interface should be allowed to have not public proprieties/attributes. These are necessary to have them referred to in the protocol state machine, but they need not be public attributes, i.e., no direct or query-based access to their values from he outside. They need to be there to allow for a consistent description of the state-based behavior.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17940: Location: Figure 11-3 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Figure and title must be on same page

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17941: Location: Figure 11-5 (ii) p 204 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

How do we show that each engine has 2 connections to each Wheel, as opposed to two  in total?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17942: Location Figure 11-21 s p.216 - Instance/roll names (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed. 

In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17943: Location Figure 11-22 s p.216 - Title doesn’t match contents (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Current text:
Figure 11-22 InstanceSpecification describes the return value of an Operation 

The diagram doesn’t show this, it show a dependence on an instance, but not that this the return value of a particular operation. 

The relevant text, 11.4.4 Notation on page 213 says 
A usage dependency may relate an InstanceSpecification to a constructor for a Class,

The diagram doesn’t connect the instance to the constructor, just to the class.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17944: Location Figure 11-23 s p.217 - Instance/roll names (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed. 

In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

Also the constructor is not connected to the instance. See 11.010

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17945: Location Figure 11-23 s p.217 - Instance/roll names (02) (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed. 

In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17946: Operations p 245 (2X) typo (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Comppnent -- > Component

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issuie

Issue 17947: Location: 12.1 Packages Summary p 264 (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

Summary:

"Models...which organize extensions to UML." suggests that Models contain extensions, which I don't think is true.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17948: Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The reference "(see Using XMI to Exchange Profiles in section Profile)", isn't using a known section heading and doesn't give a relevant section number.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17949: Location: Page 265, 12.2.3 Semantics - Unchanged URIs (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

"The URIs should hence be unique and unchanged once assigned." The UML metamodel changes its URI with every release. I think the UPDM profile used the same URI for multiple packages/profiles. Both of which conflict with the specification statement

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17950: Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The paragraph starting "A PackageMerge can be viewed..." is a bit long-winded and contains lots of parentheses.

Proposed Resolution:

Simplify text, removing parentheses:

A PackageMerge can be viewed as a set of transformations whereby the contents of the merged Package and the receiving Package are combined. Matching elements are merged into a single resulting element according to the formal rules of PackageMerge specified below. This is akin to “copying down” the features of superclasses into a subclass: the fully expanded subclass is the equivalent to the resulting package

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17951: Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The "resulting element" is described as being the same when no match exists. However this isn't strictly true. References from the element may be updated to other resulting elements

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17952: Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

General Package Merge Rules, Transformations 4 is round the wrong way. A TypedElement references a Type not the other way round. I suspect this rule shouldn't say anything about types at all. It should just be "All references to elements...resulting Elements..."

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17953: Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

Property Rules, Constraints 2 means that Transformations 7 is either wrong or unnecessary

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17954: Location: Page 269, 12.2.3 Semantics - Property merge rule pointless (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

Property Rules, Transformations 5 doesn't really do anything. It should probably be specifying the value of isDerivedUnion

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17955: Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

Association Rules, Constraints 2 is a property rule so ought to appear there. The property rules ought to say something about shared aggregation too.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17956: Location: Page 270/271, 12.2.3 Semantics - Model description confusing (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

The description of Model uses viewpoint, vantage point and perspective. I realise these are synonyms but they don't really all need to be used here. Just use viewpoint as that is the attribute name. A Model is a view, but that isn't mentioned until the third paragraph. Really that should be in the first paragraph. Abstraction is also used giving the impression that it is something distinct from the viewpoint. However surely the viewpoint defines the level of abstraction. It might be a good idea to the define the terms viewpoint and view first of all and then show how Model relates to them.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17957: Location: Page 280, 12.3.3 Semantics - Note should be main text (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

"[Note: ...]"

I don't see why this is a note, it should just be a normal bit of text.

Proposed Resolution:

Remove "[Node:" and "]" keeping the note text.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17958: Location: Page 280, 12.3.3 Semantics - Poorly indented XMI (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The XMI for the HomeExample profile has variable indenting and unaligned XML open/close elements.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17959: Location: Page 281, 12.3.3 Semantics - Duplicated text (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

The "Defining Profiles for Non-UML Metamodels" section seems to duplicate the "Restricting Availability of UML Elements" section (which also has the wrong heading style). Surely this could just be done as a single block of text that describes the filtering rules in general and then gives a specific example using the UML metamodel, while stating that in theory other metamodels could be extended.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17960: Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

"Matching between the names of Stereotype definitions and applications is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete."

What does matching actually mean here? I think this should really just say that the correct way to display stereotype names is exactly as they are in the model.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17961: Location: Page 286, 12.3.3 Semantics - Incorrect if statement (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

"If the value is the name of a NamedElement..." doesn't make sense as the name is a string and doesn't have a qualified name.

Proposed Resolution:

Replace with:

"If the value is a NamedElement..."

Revised Text:
Source: dave.hawkins@oracle.com

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17962: Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

An alternative name is given for stereotypes:

"If the ExtensionEnd is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element."

Earlier, the specification of the extension end name is given as "extension_stereotypeName" so this is a rather bizarre option. When would this ever make sense?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17963: Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect (uml25-ftf)

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

Figure 12-15 (MOF Model Equivalent to Extending "Interface" by the Home" Stereotype) shows navigation only from the stereotype to the metaclass, but the paragraph just below it says the ExtensionEnd (the one opposite the metaclass) is a navigableOwnedEnd. Extensions were made navigableOwnedEnds in 2.3.  
Before that the spec explicitly said Extensions were non-navigable because the association owned them. This wasn't true, so Pete filed issue 9891 (ExtensionEnd description refers to old use of navigability) and it was corrected by making them navigableOwnedEnds.  
Presumably the figure should show navigation in both directions and use the dot notation to show which end is owned. 
A constraint could be added to Extension that its ownedEnd is a navigableOwnedEnd.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17964: Location: Figure 12-13 p.281 - Incorrect use of << for «. (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Figure 12-13 has interface titled <<Home>> it should be «Home»

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17965: Location 13.1 Summary p 305 - Use of the word “emergent” (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

in the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

The different format of the term should be made conforming.

1) emergent behavior as in 13.1 
vs
2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
vs
3) Emergent Behavior as in 17.1.4

It should certainly be in the index.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17966: Location Behavior Parameters p 307 - Optional with default value (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

what happens when an in parameter is optional and has a defaultvalue?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17967: Location Behavior Parameters p 307 - Streaming and Multiplicity (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

If there is a minimum multiplicity on a streaming parameter, is it
1) The min # must be there to start
2) The minimum # must arrive before it finishes.
3) If a streaming parameter has a default how does that work?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17968: Location: Opaque and Function Behaviors p 308 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Detail: Why limit OpagueBehavior to a textual specification. It seems to me that any language other than UML, including graphical languages would be opaque for this purpose.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17969: Location: Page 313, 13.2.4 Notation relative (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Title: Relative to what?
The concept of relative TimeEvent does not make sense unless a base Event is identified. This should be reflected in the metamodel diagrams and definitions. This is often a problem with timers in activity diagrams.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17970: Location: 13.3.5 Examples p 314 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Explain why there are no examples

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17971: Location: Page 315 Association ends - Explain about having no nestedClassifier (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

How can it be? What are the consequences. Is this something to be avoided.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17972: Location: Page 316 redifinedBehavior - Extends (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

What does “extends” mean in this context. Is it the extends of use cases? Or statemachines? Or profiles? I don’t believe it is defined clearly

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17973: Location: 14.1 Summary p 326 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Can we point to a useful Harel book?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17974: Location: 14.2.1 Summary - Behavior StateMachines for UseCases (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Can we make this possible, explicitly?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17975: Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Revision
Severity: Significant
Summary:

 “If the StateMachine has a kind of BehavioredClassifier context, then that Classifier defines which Signal and CallEvent triggers 
are applicable”. A UseCase is a BehavioredClassifier and thus would be the context of a Statemachine. Since a UseCase cannot have Signal receptions or operations no such triggers would be applicable to this StateMachine.  
 
Proposed Res 
The radical solution would be to make UseCase not a BehavioredClassifier. However this would be out of scope. Therefore the next sentence should be changed:
“If the StateMachine has no BehavioredClassifier context or this context is a UseCase…”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Source: Axel Scheithauer  
Discussion 
A usecase can have operations. For example see  §18.1.4 Notation, 5th¶ it says
“Attributes and operations may be shown in compartments within the UseCase oval, with the same content as though they were in a normal Classifier rectangle.”
Michael Jesse Chonoles
A UseCase is a BehavioredClassifier, which is a Classifier, which has features of Type Property (Subclasses are Operation and Reception). However "feature" is a derived union and neither BehavioredClassifier nor UseCase define subsets of it. Therefore the features of a UseCase are always an empty set. I heard of one UML-Tool that actually enforces this rule.
Axel Scheithauer

Issue 17976: Location: Page 328 Regions 14.2.3 - Text about regions without initial state (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Revision
Severity: Minor
Summary:

 “No one approach is defined for the case when there is no initial Pseudostate exists within the Region.”  
Proposed Res “What it means if none is defined, is left to the modeler.”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17977: Location: Page 329 States - Stable (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

s the configuration stable if there is a pending deferred event that should be processed?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17978: Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Revision
Severity: Significant
Summary:

Title: History State described multiple times  
Summary The History State is described here: 
State history (p. 330)
Entering a state (p. 331)
PseudostateKind (p. 333)
History State Notation (p. 347)
PseudoStateKind classifier description (p 357).

Though it is OK to have descriptions in the various predefined sections, it seems that in this case I need to read all places to fully understand the history state. 
On other occasions the wording is slightly different (e.g., containing state-owning state), so that the reader wonders, whether there is a different meaning. 
On page 333 the description of deepHistory is incomplete: It doesn’t describe the default history state. This is described at other places, but not describing it here misleads the reader to think, that only shallowHistory has this feature.  

Proposed Res Reduce the number of places. Focus the description on the purpose of the section, hyperlink to other parts of the description where necessary.  
 
Source: axel.scheithauer@oose.de

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17979: Location: Page 331 deep history entry - Default deep history entry (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Shouldn’t there be a default deep history transition. See p. 374.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17980: Location: Page 338, Transition selection algorithm - Maximal Set (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

The phrase “maximal set” increases the confusion here. It appears to possibly mean that the possible sets of transitions are evaluated and the maximal set is chosen. The algorithm that is describing indicates a local decision making approach that just chooses the next transition. 
The whole concept of the “set” seems misleading in the light of immediate decisions.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17981: Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Enhancement
Severity: Significant
Summary:

The spec says 
“Alternatively, in place of a textual behavior expression the various Behaviors associated with a State or internal Transition can be expressed using the appropriate graphical representation (e.g., an activity diagram)”. 
How would that be shown? As an embedded Activity Diagram in a compartment with the name of the triggers in the left upper corner?
 
Proposed Res Add an example or give more details.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17982: Location: Page 341, State - More examples needed (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

There are some common combination notation examples that should be demonstrated and explained. That is, internal activities Behaviors compartments and decomposition compartments. 
1)	A composite state that also has a compartment for the do/activity, and possibly entry/ and exit/actions
2)	A composition state with a hidden decomposition, with compartments as above.
3)	A composite state, with regions, that also has a compartment for the do/activity, and possibly entry/ and exit/actions, crossing the regions, and compartments that are region-specific.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17983: Location: Page 346, State List Notations (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Do State Lists exchange via diagram exchange?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17984: Location: Page 346, State List Notations - Why must state lists be effect free? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Why must they be effect-free? If all the transitions have the same effect, it would be easily understandable

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17985: Location: Page 347, 14.2.4 (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

Title: state list examples with alternative notation without state lists  
Summary The text on state lists is difficult to understand without a graphical representation of the examples.   
 
Proposed Res Add corresponding diagram without state list to Figure 14-13

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17986: Location: Transition , bottom of page 352 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

What's a Data node?  Not defined in the spec?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17987: Location: Signal Receipt symbol (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

What is the motivation for the limitation on not have time events, or call events here

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17988: Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Revision
Severity: Critical
Summary:

The spec says that a choice point symbol on a graphical representation of a transition is not part of any Activity. That’s exactly what I expected, since a choice point is not allowed in an Activity. Then it says, that the symbol maps to a choice Pseudostate and uses the same notation. In other words, the choice point symbol maps to a choice point and uses the choice point symbol. Hm.
What is the difference between a choice point symbol on a transition with textual representation and on a transition with a graphical representation? The same is unclear with state, initial state, merge, and final state symbols. The symbols are the same and mean the same as in normal transitions. The example in figure 14-30 supports this view.  
 
Proposed Res Explain in more detail. If possible add the corresponding Activity Diagram.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Maybe following mapping is meant
Activities::DecisionNode to choice Pseudostate symbol
Activities::MergeNode to junction Pseudostate symbol

In this case the Transition in 14-30 would not be a compound Transition.

It would then be helpful to mention how to proceed with other elements of the corresponding Activity Diagram (interruptible regions, fork nodes…). Is there a restriction on the Activities that can be the effect of a Transition?

Issue 17989: Location: p 373 outgoing_from_initial - Limitations on guards (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

The limitation on not having a guard seems not justified, if we can constrain that the set of guards are covering. 
Please explain or fix.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17990: Location: p 378 State Description - What is hidden? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

The concept of hidden in this paragraph is unclear. Certainly any state, including those of behavior StateMachines can be visible to the users. Please add "usually" before the word "hidden" in the 2nd  sentence of this paragraph and offer or refer to explanation

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17991: Location: p. 328 Regions - Resolve intentional ambiguity (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

This is an area of intentional ambiguity. Why not just make a choice regarding a region with no start state? I would suggest that UML should allow a region without a start state and go with the second choice "the region remains inactive while the containing state is active."

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17992: Location: p. 329 State Configurations (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

Title: What state are you in when the entry action is being executed? 
As I remember, this is new in this version (UML 2.5). This line implies that a state is not active until the entry action has been executed and completed (or the entry method has returned). This is also how Umple (try.umple.org) implements state machines. The issue with this choice is that if you query the state machine while the entry action is being executed, the return value will be outdated. This is a concern even if the entry action takes insignificant amount of time.
For example, what if the entry action code queries the state machine? In that case, the query will return the source state (and not the current state). Here is the example using Umple

stateMachine {
  State1 {
    event1 -> State2; 
  }
  State2 {
    entry /{defaultEntryActionMethod();} 
  }
}

 private void defaultEntryActionMathod() {
   if (currentState == State1)
    {.. .. ..}
    if (currentState == State2)
    {.. .. ..}
}

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17993: Location: p. 330 Deferred Events - Value of Deferred Events (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

I think this is also new specification in UML 2.5. If so, it should be added to the summary of new specifications at the beginning of the document.

This is a feature with some value. The question is the following. Does this feature brings more value than the complexity it adds to the specification and the tools that supports UML? My view is that such a feature adds more avoidable complexity to the tools. At the same time, the same behavior can be achieved using the already existing UML features. I would vote against this feature in favor of keeping the specifications less complex

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17994: Location: p. 331 Explicit Entry - Clarification of Explicit Entry (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:

I would like to note that when entering a composite state, the current configuration of the state machine will not be updated until all entry actions are called, executed, and completed.

It makes more semantics sense to update the parent state machine right after its entry action is called, and recursively thereafter for all nesting levels.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17995: Location: p. 331 Exiting a State - Clarification of Exiting a State (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:

This can be clarified. When does the state machine configuration get updated?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17996: Location: p. 333 FinalState (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:

Difference between FinalState and state w/o outgoing transition. 
I see no difference between FinalState and any other state without any outgoing transition. I suggest (similar to what we did with Umple) is to delete the object when the FinalState is reached. In the case of regions, all regions must reach a final state before the object is deleted.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17997: Location: p. 333 Transitions - How do multiple triggers work? (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

This seems new to me. Does this mean that a Transition can be triggered by more than one event? if so, then what is the priority between them. For example, what if two triggering events for the same transition are fired at the same time? Which event becomes consumed by that transition? What if one of the events is a deferredEvent?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17998: Location: p. 336 Compound transitions (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

More than one transitions guarded to be true?
A known under-specification. For tool developers, it is better to make a choice here. In Umple (since it is a textual notation) we give precedence to the transition that was defined earlier in the sequential text.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 17999: Location: p. 336 Compound transitions - Run-to-completion Paradigm (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

It should be stated that a do-activity is the exception here. Also, code within the do activity should be prevented from updating the state machine configurations or firing of events (directly or indirectly).

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

The proposed limitation appears overly strong. While changing the state machine configuration above the current state perhaps should be forbidden, it seems over-limiting to completely forbidding the raising of additional events. Some modeling approaches have the do/activity equivalent to a lower-level state machines. Anything that could be done there, except perhaps direct transition to outside the parents state should be allowed.
Michael Jesse Chonoles

Issue 18000: Location: p. 337 2nd ¶ (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Title: More Non-Determinism
Similar to my comment earlier on this type of non-determinism

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18001: Location: p. 337 Conflicting Transitions (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:

Explain how conflicts arise
I suggest to add text to explain that this happens in the case of higher transition exiting a composite state machine or a state that has regions

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18002: Location: p. 337 Conflicting Transitions (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Minor
Summary:

Clarification of conflicting transitions 
This requires clarification. So, does this mean that conflicting transitions are not allowed? Sometimes conflicting transitions can only be identified at run time, for example, in the case of guarded transitions.

The following paragraph clarifies some of the ambiguity, but not all of it. Still, the case when two transitions are at the same nesting level is still ambiguous.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18003: Location: p. 338 Transition execution sequence (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

Transition execution sequence 
In this sequence, missing is the transition action. When does the action associated with a transition execute?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18004: Location: p. 338 Transition execution sequence (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

Transition execution sequence 
In this sequence, missing is the transition action. When does the action associated with a transition execute?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18005: Location: p. 357 StateMachine Redefinition (uml25-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Omar Badreddin, oobahy(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

StateMachine Redefinition Notation
As far as I remember, this is a new specification in UML 2.5. The semantics of redefining state machine is clear. I find it rather confusing is the notation. When you redefine a generalized state machine, you typically do not want to redraw the whole state machine. The proposed notation means that the whole state machine must be re-drawn with the added modeling elements.

Also, this notation supports only the addition to the generalized state machine, but not the deletion or modification of the generalized state machine

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18006: Location: p 410 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Show how to pass activities around

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Issue 18007: Location: Figure 15-23 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Use {stream} not [stream]

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18008: Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Multiplicity Limitations on DecisionInputFlows

It does not seem logically necessary that a particular ObjectFlow can only connect to [0..1] DecisionNodes. Why can't more be connected? 
For example, the same ObjectFlow could be used in multiple swimlanes.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18009: Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Type Limitations on DecisionInputFlows

It also does not seem logical necessary to restrict the decisionInputFlow to be an Objectflow. Though a ControlFlow has not value it could be present or null, which could be tested to enable or disable the decision.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18010: Location p413 Final Node - Atomic behavior (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

It is often necessary to prevent an ActivityFinalNode from terminating behavior in the middle. 
We recommend the creation of a stereotype for an Activity or Action, such as «atomic» which indicates that reaching an ActivityFinalNode on the diagram will allow the behavior to finish, but that no output tokens are emitted when this occurs. 

This prevents some sorts of inconsistency that can occur when cancelling.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18011: Location p413 Final Node - Rollback behavior (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Consider adding a «rollback» region that is automatically executed if the parent is canceled.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18012: Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Diagramming style should reflect good diagramming and programming practice, which is NOT to share merge diamonds. This is like two IF statements sharing the same ENDIF

If there are two decisions there should be two merges (in the majority of cases)

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18013: Location: Figure 15.57 page 426 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Detail:
Explain how the exception works with the other out parameter. 
Should Accepted Computers also be streaming?
If not, under what circumstances are the AcceptedComputers released?
Without an exception, how would this stop?
Does the AcceptedComputers only release when rejectedcomputers is raised and handled; otherwise when would it be released?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18014: Location: 15.5.1 - typo (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Detail; the word used is not a word, "produceas", perhaps what is wanted is "as"

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18015: Location: Figure 15-63 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Detail:
Unclear why this Alternative ExceptionHandler notation requires pins on both ends, when the standard notation only has a pin on one side. Perhaps pins should always be there, or never be there.

The description just has the zig-zag adornment on a straight line and does not mention the pins

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18016: Location: Figure 15.67 page 436 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Significant
Summary:

Detail:
Show notation to indicate specific partitions for control nodes

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18017: Location: Figure 15-23 p.411 (uml25-ftf)

Click here for this issue's archive.
Source: Alion Science and Technology (Mr. Jim Logan, jllogan+omg(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Figure 15-23 shows streaming activity edges--are those control flows or object flows? I don't think control flows can stream, and these activity edges don't look like object flows to me.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18018: Location: 16.2.3 Semantics / Opaque Actions (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Detail:
Why restrict OpaqueActions to textual concrete syntax, when other approaches are possible.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18019: Location: p 484 - Exception store (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

1) Makes sense to have the notation for an exception store to be a triangle
2) The left most action on this diagram is an exceptionhandler.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18020: Location: p 504 - Marshall Actions (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Why aren’t there Marshall Actions

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18021: 17.1.5 Interaction Diagram Variants p 607 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Significant
Summary:

What is the rationale for making Timing Diagrams optional for tool compliance?

Description:
This clause states, “Conformant UML 2.5 tools are not required to implement Timing Diagrams.”  UML 2.5 takes the bold step—which I favor—of eliminating the formal compliance levels, and then carves out caveats in the fine print.  What is the rationale for making Timing Diagrams part of the UML spec., but then stating that they’re optional for tool compliance?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18022: Interactions p 607 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Current text:
The invalid set of traces is associated only with the use of a Negative CombinedInteraction. For simplicity we describe only valid traces for all other constructs 

This is not quite true
1) An assert declares all non-compliant traces as invalid
2) It may also be possible to use consider on normal trace where the message to be considered is not in the trace to indicate that if it occurs it is invalid. 
3) It is also possible to declare invalid traces with state invariants. For example, imagine a constraint such as {1=2}
Source: Michael Jesse Chonoles

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18023: Location: 17.2.3 Semantics Interaction Fragments p 607 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Significant
Summary:

Title: Reference to “InteractionOperator” should instead say “InteractionOperand”
Description:
current text
An InteractionFragment may either be contained directly in an enclosing Interaction, or may be contained within an InteractionOperator of a CombinedFragment, 

Discussion: 
In that sentence, “InteractionOperator” should be changed to “InteractionOperand.”  The InteractionOperand metaclass has an association end “fragment : InteractionFragment.”  An interaction operator, on the other hand, is simply an attribute of a combined fragment; it has no association with an interaction fragment.

Proposed Resolution: 
 Change “InteractionOperator” to “InteractionOperand” in that sentence.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18024: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Darren Kumasawa, darren.kumasawa(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

Location:
Page #607, 17.2.3 Semantics, Execution Specifications
Page #619, 17.5.3 Semantics, Execution Occurrence Specifications

Summary:
Page #607, 17.2.3 Semantics, Execution Specifications
"Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
"A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead?  The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification.  Is there a guideline of when to use one over the other?

Source: darren.kumasawa@oracle.com

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Issue 18025: Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Clarification
Severity: Significant
Summary:

Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.”  However, this is inconsistent with the idea that UML does not prescribe color for notations

Proposed Resolution:   In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation.  In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Without this, any tool that shaded these a nice pastel would be non-compliant.

Issue 18026: Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5) (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Enhancement
Severity: Minor
Summary:

This clause states, “Finally a fourth message is sent from the ACSystem to the environment through a gate with implicit name out_Unlock.”  I recommend inserting the word “formal” in front of “gate” to help readers reinforce the connection to what they’re seeing on the diagram in Figure 17.3.

Proposed Resolution:  Insert “formal” in front of “gate” in that sentence.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18027: Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Enhancement
Severity: Minor
Summary:

The placement of the labels “CardOut {0..13}” and “OK” is ambiguous.  A reader may confuse which message they are associated with.  Also, the non-UML arrow associated with the “TimeObservation” label (outside of the diagram frame) is unnecessarily cluttering the diagram.

Proposed Resolution:  Move the “CardOut {0..13}” and “OK” labels to eliminate the ambiguity.  Move the “TimeObservation” label to the right side of the figure to de-clutter the diagram.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18028: Location: p 611 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

The notation in Figure 17.5 does not match the almost identical diagram of Figure 8.5

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18029: Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Enhancement
Severity: Minor
Summary:

This clause states, “The :User sends a message Code and its duration is measured.”  I don’t believe it’s meaningful to refer to a message’s duration; neither the Duration metaclass nor the DurationObservation metaclass have an association with the Message metaclass.  Rather, the DurationObservation metaclass is associated with 1..2 NamedElements that are the event occurrences on either end of the observation.  In the case of a Message, those event occurrences are the “send” and the “receive.”  I recommend rewording the excerpted sentence as shown below.

Proposed Resolution:  
Recommend rewording the sentence as follows:  “The :User sends a message Code and the duration between its send and receive occurrences is measured.”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18030: Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Significant
Summary:

The multiplicity shown for “coveredBy : InteractionFragment” is “*”.  However, I believe the lower multiplicity should be 1, not 0.  A lifeline can only exist within an Interaction; it cannot exist independently.  This is affirmed by the multiplicity of “1” shown in this figure for the end “interaction : Interaction”.  And an Interaction is a type of InteractionFragment as we see in the metamodel in Figure 17.1.  Therefore, an instance of Lifeline must always know at least one instance of InteractionFragment:  the Interaction that owns it.  And thus, the multiplicity for “coveredBy : InteractionFragment” should be “1..*”, not “*”.

Proposed Resolution:
Change the multiplicity for the end “coveredBy : InteractionFragment” to “1..*”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18031: Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Significant
Summary:

The multiplicity shown for both ends named “covered” of type “Lifeline” is “*”.  The multiplicity for both of these ends should be “1” to match the metaclass entries for “OccurrenceSpecification” and “StateInvariant”.  Both entries show that these two metaclasses each have an association “covered : Lifeline [1]”.  And “1” is the intuitively correct multiplicity; an instance of OccurrenceSpecification (e.g. send, receive, start, end, destruction) can only be associated with a single lifeline.  And an instance of StateInvariant is placed on a single lifeline.  

Proposed Resolution:

Change the multiplicity for both of the ends “covered : Lifeline” to “1”.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18032: Pg. 613, Clause 17.3.4: Notation (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Title:  Incomplete grammar for “<lifelineident>” in Clause 17.3.4
Summary:  This clause specifies the following grammar for “<lifelineident>”:  

<lifelineident> ::= ([<connectable-element-name>[‘[‘<selector>‘]’]] [: <class_name>][decomposition]) | ‘self’

“<class_name>”, however, is too restrictive for the type.  A lifeline may represent an instance of an Actor, not just an instance of a Class.  In fact, the metamodel, as written, allows a lifeline to represent an instance of any type of BehavioredClassifier.  Here are the relationships:

A lifeline represents 0..1 instances of ConnectableElement.
ConnectableElement is a type of TypedElement.
TypedElement has an association with 0..1 instances of Type.
BehavioredClassifier is a type of Classifier, which is a type of Type.
BehavioredClassifier has 4 specializations:  Class, Actor, UseCase, and Collaboration.

Therefore, any of these 4 subtypes may serve as the type of the connectable element that a lifeline represents.  But only 2 of these make sense in the context of a lifeline:  Class and Actor.  So there are really 2 problems that need to be resolved.  Recommendations provided below

Proposed Resolution:  
1)  The grammar for “<lifelineident>” needs to be expanded to allow for an actor to serve as the type of the connectable element that a lifeline represents, and
2)  A constraint needs to be introduced to allow only two of the four subtypes of BehavioredClassifier to serve as the type of the connectable element that a lifeline represents.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18034: Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Significant
Summary:

his clause states, “A lost Message is a Message where the sending event occurrence is known, but there is no receiving event occurrence.  We interpret this to be because the Message never reached its destination.”  
The semantics described in the second sentence seem unnecessarily strict.  Additionally, this interpretation for a lost Message is inconsistent with the interpretation of a found Message described in the next paragraph:  “We interpret this to be because the origin of the [found] Message is outside the scope of the description.”  The semantics of a lost Message should be similar.  

Proposed Resolution:

Change the second sentence in the excerpt to read:  “We interpret this to be because the destination of the [lost] Message is outside the scope of the description.”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18035: Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Revision
Severity: Minor
Summary:

This clause states, “Gates are matched by name, with a formal Gate matched with a formal Gate having the same name, and with an inner CombinedFragment Gate matched with an outer CombinedFragment Gate having the same name.”  The second occurrence of the word “formal” should be replaced with “actual” to be consistent with the idea expressed about CombinedFragment gates in the second part of the sentence, “…inner…matched with an outer…”.

Proposed Resolution:  Replace the second occurrence of the word “formal” with “actual”.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18036: Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Title:  Incorrect specification of the notation for a reply message.
Summary:  
This clause states, “A reply Message (messageSort equals reply) has a dashed line with a filled arrow head.”  A reply message has an open arrow head as shown in the usage example in Figure 17.14.  

Proposed Resolution:  Replace “…filled arrow head” with “…open arrow head” in the excerpted sentence.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18037: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Darren Kumasawa, darren.kumasawa(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

Location:
Page #607, 17.2.3 Semantics, Execution Specifications
Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
Title: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

Summary:
Page #607, 17.2.3 Semantics, Execution Specifications
"Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
"A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead?  The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification.  Is there a guideline of when to use one over the other?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18038: Location: weak sequencing p. 622 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Need better explanation and examples

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18039: Location: LostMessage Row p 639 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

“the Receiver is either not known, out of scope, or does not happen”

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18040: Location:Page #640, 17.8.2 Example Sequence Diagram (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Darren Kumasawa, darren.kumasawa(at)oracle.com)
Nature: Revision
Severity: Critical
Summary:

Title: Need more complicated Example Sequence Diagram

Summary:
Section 17.8.2 should include an example of a more complicated Sequence Diagram that includes BehaviorExecutionSpecification, ExecutionOccurrenceSpecification and CombinedFragment metamodel elements.  It is unclear how these elements should be ordered in the "fragment" set of the Interaction.  See diagram 17.14 for an example that would be useful to see the metamodel elements depicted.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18041: Location: Table 17.6 entire table p 646 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Detail: Cell boundaries often stepped on by diagrams in 2nd column, partial elements in some cells. 

Example: Frame row page 646

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18042: General value lifeline Row p 647 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

picture is missing

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18043: Location: 18. Global - No discussion of use case instances (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Need some discussion on the use and limitations of use case instances

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18044: Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “A UseCase’s subject represents the system or systems under consideration to which the UseCase applies.”

[AC] This addition wasn't in the previous UML version, 11-08-06, where the description was “The subject is the system under consideration to which the use cases apply.”

I consider the plural “or systems” ambiguous, because it lets the reader think that the subject may refer to more than a single system. 
If we want to say that the subject may be a very complex one, such as a system of systems (and this may be indeed useful in my opinion) we should state this point explicitly.

So I suggest to go back to the previous formulation, or to state more explicitly that the subject may refer to an arbitrarily complex system

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

Perhaps the current text was trying to get at the fact that a UseCase may have more than one subject, each one representing a system to which the UseCase applies

Issue 18045: Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

current text: “A UseCase is the specification of a set of behaviors performed by a subject, which yields an observable result that is of value for one or more Actors”
Other than this and the next paragraph, there is no indication that an actor is mandatory, e.g., no OCL, no relationship on the diagram. Consider updating the Figure 18.1 UseCases to show a relationship between the actors and usecases to make a use case require an actor. 

In addition, this is contradicted by p 686, which says: “UseCases may have associated Actors,”, which seems to indicate that actors are not mandatory.

So  
•	Make the text consistent between 685 and 686
•	Consider updated Figure 18-1 to show at least one actor
•	Consider adding OCL to force at least one actor.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18046: Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Uncategorized Issue
Severity: Significant
Summary:

current text: “Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality, which is initiated by an Actor, must always be completed for the UseCase to complete.”

[AC] I think the clause “which is initiated by an Actor” is wrong, according to the use case theory formulated by Jacobson, where each use case must provide value to an actor, but not necessarily be initiated by an actor, because there are also time-triggered use cases.

What's more, this clause does not correspond to any constraint in the metamodel. So, even if it was also in the  11-08-06 version, I suggest to remove it

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

Note this is independent from 18.003, which says there must be at least 1 actor. This suggests removing the text requiring an actor to initiate.

Michael Jesse Chonoles

Issue 18047: Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors”.

[AC] I think the clause “possibly including variants” could and should be avoided, because: a) “variant” is not a term defined in the specification, and could be interpreted differently by different readers
b) it does not lead to a better explanation of what a behavior specification is.

However, the clause “possibly including variants” was also included in the 11-08-06 version

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18048: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

current text: “The subject of a UseCase could be a system or any other element that may have behavior, such as a Component, subsystem, or Class”

The restriction on behavior elements is not clear. 

This limits subjects to element that may have behavior. There is no OCL to enforce this. Is this only BehavioredClassifiers?  Can a UseCase be the subject of usecase?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18049: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, or by pre-conditions and post-conditions...”

[AC] The “or” in “ or by pre-conditions and post-conditions” is ambiguous, because it can be interpreted as an XOR, while it is not exclusive. In fact, but several lines below, it is correctly stated that “These descriptions can be combined”. I suggest to remove the “or”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

For a more complete correction, try the following:
“The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, or by pre-conditions, and post-conditions...”
This puts the “and” at the correct part of the sentence and include the comma.

Michael Jesse Chonoles

Issue 18050: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in initiating the UseCase.”

[AC] I would delete the term “initiating”, because it is wrong. Not only [may] a use case may be time-triggered, but the multiplicity may be >1 even if an instance of actor initiates the use case, then another instance is involved.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

In addition, some actors are not initiators at all.

Recommendation: Replace initiating with “interacting with”

Issue 18051: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Although the owning Classifier typically represents the subject to which the owned UseCases apply, this is not necessarily the case.”

[AC] I would add: “as is shown in Figures 18.10 and 18.11”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18052: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “The same UseCase can be applied to multiple subjects”.

[AC] I would add: “if, and only if, it is associated with the same actors”. Otherwise, it would be possible to have an inconsistent “reuse” of use cases, with a different set of actors in each context.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18053: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. “

[AC] In my opinion, this is ambiguous, and could be replaced with  “in the sense that, in a specific modeling context, an instance of the Actor is not a part of the instance of the subject of an associated UseCase”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18054: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “When an Actor has an association to a UseCase with a multiplicity that is greater than one at the UseCase end, it means that a given Actor can be involved in multiple UseCases of that type.”

[AC] This relationship between Actors and UseCases is asymmetric and in my opinion inconsistent. When a UseCase has a upper multiplicity >1 towards Actor, this means that multiple instances of Actor are involved. At the opposite end, the meaning is undetermined. This should be avoided in a metamodel definition. It would surely be less ambiguous to state that the upper multiplicity from Actor to UseCase is just 1.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

Leaving the interpretation as undefined in this specification supports several methodological interpretations, none which should be enforced. I would recommend leaving this as stated. 
Michael Jesse Chonoles

Issue 18055: Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in a UseCase.”

[AC] According to the metamodel, if I'm not wrong, this should be “in one or more UseCases”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

The intention is to capture the additional behavior. then an extension UseCase is created. I would not rewrite this unless additional clarifying description is added. 
Michael Jesse Chonoles

Issue 18056: 18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Extend is a kind of DirectedRelationship, such that the source is the extending UseCase and the target is the extended UseCase. It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

[AC] I can infer that the owning UseCase is the extending UseCase, but I think this should be stated again, to avoid misunderstandings. It could be also useful to give an example, with a specific figure, of a naming of the extend relationship.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18057: 18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Therefore, it is not easy to capture its structure accurately or generally by a formal model.”

[AC] I would say “it is not possible”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18058: 18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

As it is unclear whether an omitted condition is true, clarify the situation by explicitly handing it.  Replace the start of this paragraph with  "If the condition of the Extend is missing or evaluates to true at the time the first ExtensionPoint is reached during the execution…”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18059: 18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

It is a bit unclear whether “first” means the first of extensionPoints in the {ordered} extensionLocation list or the first that is reached in the particular execution path. 

Please clarify

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18060: 18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

current text: Once a given fragment is completed, execution continues with the behavior of the extended UseCase following the ExtensionPoint. 

This means that inserting an extension UC can't ever supply alternative behavior to the base use cases, but can only supply additional behavior. This is contrary to the vast majority of practice.
In addition, it prevents extension use cases from being used for exception handling where the behavior ends in the extension.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18061: 18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

[AC] I would add at the end “(the includingCase)”.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18062: 18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

current text: “All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

It appears that it’s not possible (or unclear how) to insert the same included Use Case in multiple locations in the base (including) use case. Surely this is possible.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18063: Location: 18.1.4 Notation P. 688 - Point to diagram (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “The subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name (and associated keywords and stereotypes) in the top-left corner, with the UseCase ellipses visually located inside this rectangle.”
[
AC] I would add at the end “as shown in figure 18-2”. 

General note: the numeric ordering of figures should be aligned with the sequence in which they are referenced in the text.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18064: Location: 18.1.4 Notation P. 688 - Point to diagram (02) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “A UseCase may also be shown using the standard rectangle notation for Classifiers with an ellipse icon in the upper-right-hand corner of the rectangle. In this case, “extension points” is an optional compartment. This rendering is more suitable when there are a large number of extension points or features.”

[AC] I would add at the end “See figure 18-5”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18065: Location: 18.1.4 Notation P. 688 - Point to diagram (03) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “An Actor is represented by “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon.”

[AC] I would add at the end “See figure 18-6”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18066: Location: 18.1.4 Notation P. 688 - Point to diagram (04) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “An Actor may also be shown as a Classifier rectangle with the keyword «actor», with the usual notation for all compartments.”

[AC] I would add at the end “See figure 18-7”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18067: Location: 18.1.4 Notation P. 688 - Point to diagram (05) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “Other icons that convey the kind of Actor may also be used to denote an Actor, such as using a separate icon for non-human Actors.”

[AC] I would add at the end “See figure 18-8”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18068: Location: 18.1.4 Notation P. 688 - Point to diagram (06) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “The nesting (owning) of a UseCase by a Classifier may optionally be represented by nesting the UseCase ellipse inside the Classifier rectangle in a separate compartment. This is a case of the optional compartment for ownedMembers described in 9.2.4.”

[AC] I would add at the end “See figure 18-9”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18069: Location: 18.1.4 Notation P. 688 - Point to diagram (07) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “An Extend relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the extending UseCase towards the extended UseCase. The arrow is labeled with the keyword «extend». The condition of the Extend as well as references to the ExtensionPoints are optionally shown in a note symbol (see 7.2.4) attached to the corresponding arrow.”

[AC] I would add at the end “See figure 18-3”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18070: Location: 18.1.4 Notation P. 688 - Point to diagram (08) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Clarification
Severity: Minor
Summary:

current text: “An Include relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the base UseCase to the included UseCase. The arrow is labeled with the keyword «include»..”
.”

[AC] I would add at the end “See figure 18-4”

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18071: Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem» (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

It might be useful to explain in the text somewhere that the «Subsytem»ATM System is (necessarily) a component. 

This clarification will address open UML 2.4 issue 16494

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18072: Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Please explain the multiplicity as used on this Figure 18-2. Without a good explanation, an example doesn’t really help
Something like this.
In this example, a Customer or Administrator may or may not participate in any of their associated Use Cases (hence the 0..1 multiplicity). From the Use Case perspective, it must have an Actor to initiate it (hence the 1 multiplicity). The Deposit and Register ATM use cases require participation by the Bank, while the bank can participate with many Deposit and Register ATM use cases at the same time.

This description will address open UML 2.4 issue 8854

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18073: Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

The example should be shown with navigation (arrows) on the associations, to indicate initiating (primary) and non-initiating (secondary) actors. This is legal and common notation
This would partially address Issue 8855

Resolution:
Revised Text:
Actions taken:

Discussion:

Good that Navigation (arrow) is a legal notation. I find the arrows useful when depicting a system’s capability from an external interface perspective, wherein the external systems are the system actors and the subject contains the external interface capabilities. And having the arrow depicts which system initiates the use case (for example transfer of data) and having the arrows towards the system actor depicts that the external system receives the data pushed to it. If nothing else, asking for an example for when a navigation or arrow is useful.
Milagros Nguyen

Issue 18074: Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Current text Figure 18-9 illustrates an ownedUseCase of a Class using an optional ownedMember compartment.
In the figure 18-9, the title of the compartment is owned use cases. The description should explain the discrepancy.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18075: Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Figure 18-10 duplicates Figure 18-2.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Discussion:

This may be acceptable as the diagram is used for different purposes as different times. It would be preferred to change the earlier diagram to give more examples to the reader.

Issue 18076: Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing constraint or discussion anywhere that the chain of extends relations must not contain loops

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18077: Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Significant
Summary:

current text: The ExtensionPoints referenced by the Extend relationship must belong to the UseCase that is being extended 

Does this "belong" also include 
1) ExtensionPoints that would be inherited? 
2) ExtensionPoints that would be defined in Included Use Cases. 

Both of these are required to support behavioral refactoring and reuse. If a "super" UseCase or an Included UseCase are made to pull out common behavioral parts, it may be that some an extending use case needs to be inserted at
a) extension points that cross use case boundaries (e.g., in the super and child use case, or in the included and base use case) or
b) an extension UseCase needs to be inserted in a base use case, but not in all use cases tsshat include the Included UseCase, and not in all children of the generalized UseCase.

Without including the extensionPoints from both these sources, such situations cannot be handled.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18078: Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing constraint or discussion anywhere that the chain of includes relations must not contain loops

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18079: Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

Missing OCL to enforce this constraint.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18080: Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

Missing OCL to enforce this constraint.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18081: Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Uncategorized Issue
Severity: Significant
Summary:

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

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

Resolution:
Revised Text:
Actions taken:
November 21, 2008: received issue
September 28, 2012: received issue

Discussion:

I believe Adriano is being overly limiting, For example, a particular instance of a use case might have a relationship to a particular message instance (with values). This instance to instance relationship requires an association at the classifier level. 

Michael Jesse Chonoles

Issue 18082: Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02) (uml25-ftf)

Click here for this issue's archive.
Source: Soluta.net (Dr. Adriano Comai, acomai(at)soluta.net)
Nature: Uncategorized Issue
Severity: Significant
Summary:

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

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

Resolution:
Revised Text:
Actions taken:
November 21, 2008: received issue
September 28, 2012: received issue

Discussion:

Need to understand more what was on the minds of the original authors here. 

Michael Jesse Chonoles

Issue 18083: Location: 18.1.1 Summary p 685 - emergent behavior (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:

In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

The different uses of the term should be made conforming.

1) emergent behavior as in 13.1 
vs
2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
vs
3) Emergent Behavior as in 17.1.4

It should certainly be in the index.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18084: Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

This notation, using the circle at the end of the line is not indicated elsewhere. As it is, it appears to be only used in extension conditions?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18085: Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations? (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Clarification
Severity: Significant
Summary:

A UseCase is a BehavioredClassifier, which is a Classifier, which has features of Type Property (Subclasses are Operation and Reception). However "feature" is a derived union and neither BehavioredClassifier nor UseCase define subsets of it. Therefore the features of a UseCase are always an empty set. I heard of one UML-Tool that actually enforces this rule.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18086: Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes (uml25-ftf)

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

Was wondering if clarification was needed on adding bases to specialized stereotypes.  Since Extensions are associations:

•	Bases of general stereotypes inherit to specialized stereotypes, and instances of specialized stereotypes can be applied to any of the bases, including inherited ones.

•	Bases of specialized stereotypes can be specialized from more general bases by redefinition or subsetting of ExtensionEnds.

This all follows from Extensions as associations/classifiers, so maybe doesn't really need to be explicitly said, not sure.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18087: Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1] (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

An artifact can be located in multiple locations, for example, on a disk and in ROM, and in RAM. Similarly, it could execute partially in ROM and also in RAM. In addition, an executable could reside in multiple places in memory on the same machines, with multiple copies running at once. Also they could assigned to different "cores"

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18088: Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

In fancy hw, a node could be owned by more than one owning node: Shared memory, shared processors, distributed processing...

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18089: Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

The way you've documented this, it's unclear whether a informationItem can represent both other informationItems and concrete Classifiers.
Current text: InformationItems can represent other InformationItems or concrete Classifiers.
Suggested Text: InformationItems can represent other InformationItems and concrete Classifiers.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18090: Location: 21.1 Summary P. 726 - Missing header (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The diagram of the model should be in a separate section called "21.2 Model", cf 22.2.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18091: Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Should we be point to IEEE 754 the well-known standard (754-1985 or 754-2008) or 
the newer ISO/IEC/IEEE 60559:2011 (with identical content to IEEE 754). 
I would imagine that getting our spec through the ISO process would be easier if we point to the ISO standards

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18092: Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Current Text: Typically an implementation will represent Real numbers using a 
Suggested Text: Typically an implementation will internally represent Real numbers using a 
We already have a standard for Real Literals

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18093: Location: 21.2 Semantics P. 726 - Subsection title (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

This is an unfortunate title for a subsection that defines no semantics. Perhaps unavoidable for auto-generated consistency.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18094: Location: Table 21-1 P. 726 - Title of table not great (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Again not semantics. Suggest "PrimitiveType Domains".
[If it defined semantics, it would define how many Boolean instances there may be.]

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18095: Location: Table 21-1 String P. 726 (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

'computational language expression' and 'OCL expression' are almost the same. 'name' is not mentioned.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18096: Location: Table 21-1 Unlimited Natural P. 726 - Infinity (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Enhancement
Severity: Significant
Summary:

The infinity value was called 'infinity' in UML 2.3 and 2.4. It is called 'unlimited' in OCL. It is called 'unlimited' in 8.2.4. Introducing the new term 'unbounded' seems undesirable, particularly in view of the familiarity and appropriateness of the mathematical concept of 'infinity'. [OCL should change to 'infinity'. UML Integer should grow to include +/- infinity to eliminate the inconsistency wrt Real/UnlimitedNatural.]
Suggest replace 'unbounded' by 'infinity'

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18097: Location: Table 21-1 P. 726 - Row ordering (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

What is the row ordering rationale? Suggest alphabetical order, else increasing domain size order.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18098: Location: Figure 21-3 (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

Class boxes in close proximity should generally have the same height, width, and font size

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18099: Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Subsystem should also be allowed for other types of classifier, e.g., class.  Limiting this to components enforces a particular methodological approach and is incompatible with Systems Engineers, who would use «Subsystem» for blocks, a specialization of Class.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18100: Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

A diagram of Model, Node, Datatype, etc. should be allowed. 
This is also UML 2.4 Open Issue 16484.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18101: Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

Use case diagrams don’t show change over time, they should intents, purposes, etc. They are neither structure nor behavior. Redraw diagram to make new category 
They are more similar to SysML requirement diagrams

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18102: Location: Figure B.3. 737 - A diagram is a PackageableElement (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

A diagram is a packageableElement. 

What does it look like in a package

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18103: Location: B.2.2 P. 738 - What ISO document (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Explain which document

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18104: Location: B.2.3 P. 738 - confusing model and diagram (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Is there a model in the diagram?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18105: Location: B.2.4 P. 739 - confusing model and diagram (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Is there a model in the diagram?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18106: Location: B.4.4 State Shapes P. 752 - State List Limitations (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Enhancement
Severity: Minor
Summary:

State lists are not limited to no triggers
See Figure 14-13 and Figure 14-14. 

They are limited to no effects, though I don't see why

Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate.  Either transition F is not legal for a state list, or this paragraph is overly restrictive.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18107: Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams? (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

if I'm  using a class diagram to show the namespace structure of a class (not the composite structure), wouldn't that classdiagram have a modelElement, that of the owning class

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18108: Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763 (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny.delligatti(at)lmco.com)
Nature: Clarification
Severity: Significant
Summary:

Title:  Specification of color
Description: This is inconsistent with the idea that UML does not prescribe color for notations. 
Proposed Resolution:   give a literal of Shaded or Hatched

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18109: Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval. (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

How are use case ovals (and their titles) handled? As too model elements?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18110: Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Wouldn’t this be the «profile» Package being modeled?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18111: Location B.6 UMLStateShape statelist p 770 - StateList Limitations (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

State lists are not limited to no triggers
See Figure 14-13 and Figure 14-14. 

They are limited to no effects, though I don't see why

Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate.  Either transition F is not legal for a state list, or this paragraph is overly restrictive.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18112: Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

The first paragraph gives a number of constraints on model element names, in particular stereotypes. I don't believe this is mentioned in either the NamedElement description or the Stereotype description. I don't think this is a constraint that should be left to an annex, if indeed it should exist: the EJB profile example in figure 12-19 has an Entity stereotype that extends Component as does StandardProfile.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18113: Location: Annex C Keywords p 777 - Capitalization of «trace» (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Throughout the spec, «trace», is indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Trace». It is also given as «Trace» in the table of Keywords here in Annex C.
What is the correct capitalization? 
The document needs to be consistent

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18114: Location: Annex C Keywords p 777 - Capitalization of «create» (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

Throughout the spec, «create», is someimes spelled with an initial cap and sometimes not, indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Create». It is also given as both  «Create» and «create» in the table of Keywords here in Annex C.
What is the correct capitalization? 
The document needs to be consistent

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18115: Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Significant
Summary:

There a number of keywords that are used when the same notation is used for multiple metaclasses. These aren't derived from the name of the metaclass in a consistent manner. For example, centralBuffer for CentralBufferNode, deployment spec for DeploymentSpecification, substitute for Substitution.

Stereotypes are now given as their exact name, without transliteration or abbreviation. Should the same approach be used for metaclasses?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18116: Location: Table B.1 UML Keywords p 778 - Keywords should be in index (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Every keyword should be in the index. Actually none of them are indexed to this location. Some keywords don’t appears in the index at all.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18117: Location: Annex C Keywords P. 780 - Bizarre definition of statemachine (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity: Minor
Summary:

The keyword statemachine has semantics "BehavioredClassifer::self.oclIsKindOf(StateMachine)". Surely the semantics should just be "StateMachine" with a separate keyword for ProtocolStateMachine.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18118: Location: Index (uml25-ftf)

Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. Neil Capey, ncapey(at)sparxsystems.com.au)
Nature: Revision
Severity: Critical
Summary:

Entries don't hyperlink back to the main document (this is a show stopper for me).

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18119: Type: Structural - Location Index p 790, 794, (uml25-ftf)

Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. Neil Capey, ncapey(at)sparxsystems.com.au)
Nature: Revision
Severity: Minor
Summary:

Short index entries: alt, in, and is are not formatted corrected.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18120: Location: Index p 793 - emergent behavior (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

The different uses of the term should be made conforming.

1) emergent behavior as in 13.1 
vs
2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
vs
3) Emergent Behavior as in 17.1.4

It should certainly be in the index.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18121: Location: Index p 795 - Index of "is" (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Why would "is" be in the index. "Is" is not a  UML specific term.

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18122: Location: Index p. 796 among others - Index items with only one page (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:

I think there are few items that should appear only once in the index.

For example, look at isTabbed. it appears in the index with a page # of 769 which is where the formal classifier description appears. However, isTabbed also appears on page 751 where the field is described. 

as another example, look at isSynchronous which is indexed from page 527 the formal areas, but  isSynchronous is defined on page 479.

It is also used on page 672

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18123: Location: Index Mis. - Missing terms in the Index (uml25-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

 'alphabet' missing
'Boolean' missing
'Character Set' missing
'false' missing
'floating point' missing
'Integer' missing
'infinity' missing
'OCL' missing
'OCL expression' missing
'primitive' missing
'PrimitiveType' reference to Section 21 missing
'PrimitiveTypes' missing
'Real' missing
'String' missing
'true' missing
'unbounded' missing
'Unicode' missing
'UnlimitedNatural' missing

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18124: Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

Expressions such as visibility <> #public are not clear (I suppose this is OCL) and should be explained. Also the of isRelative = true (w/o the #) appears inconsistent

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18126: UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is a pity that UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18127: Lifeline has no type. (uml25-ftf)

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

Lifeline has no type.  Type comes from ConnectableElement it represents. 

That means, we must have "fake" property created for every call to static operation (one per class). 

Should it be property of Interaction? Or should it be property of context Classifier? This is an issue.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18128: How should context be represented? (uml25-ftf)

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

We have similar issues to represent calls to self/context.  How context should be represented? As lifeline with keyword "self" or "this"?

Resolution:
Revised Text:
Actions taken:
September 28, 2012: received issue

Issue 18129: Interaction parameters. (uml25-ftf)

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

Other related issue - Interaction parameters. 

When Interaction itself is set as a method of Operation with parameters, how these are represented in Sequence Diagram?  Can Parameter be represented as a lifeline? (Parameter is ConnectableElement).

How value returning is represented?

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18131: 17 Semantics of interactions (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself)
Consider Figure 17.2 (in the UML2.5 Revised August draft):

Clearly we expect that:

 

"oper1()" is a Message whose Message::signature refers to A::oper1() 

"callback()" is a Message whose Message::signature refers to C::callback()

 

However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message.

 

In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3)

The spec does not currently specify any kind of bound on this resolution process — that is,  Behaviors could be found potentially anywhere in the model.

 

This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.

Resolution:
Revised Text:
Actions taken:
October 2, 2012: received issue

Discussion:

From: <Wendland>, Marc-Florian <marc-florian.wendland@fokus.fraunhofer.de>
Date: Tuesday, October 2, 2012 12:02 AM
To: JPL <nicolas.f.rouquette@jpl.nasa.gov>, "uml-spec-simplification@omg.org" <uml-spec-simplification@omg.org>
Subject: AW: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself)

Hi Nicolas,

I don’t think that this has been filed yet. I flicked briefly through the Interaction-related issues in preparation for my contribution to FTF. However, I might have overlooked something, of course.

Anyway, I agree that there is a need for more clarification on this, however, I don’t think that this is a trivial thing due to the very flexible concepts of Messages etc. There are several possibilities where those Operations can be located, respectively what Operations are actually invokable via that Message.

Possible locations for any invoked BehavioralFeatures

1.       Directly owned or inherited by the Type of the ConnectableElement the Lifeline represents (simplest possibility)

2.       Directly owned or inherited by the Type of a Port of the ConnectableElement the Lifeline represents

3.       Directly owned or inherited by a realized (via InterfaceRealization) Interface of the Type of a Port of the ConnectableElement the Lifeline represents – we are using this kind of BehavioralFeature offering a lot when modeling test architectures with UTP

Offered BehavioralFeatures for a Message sent via Connector

4.       If the Message is send via a specific Connector that is connected to a Port (e.g., owned by C), only those BehavioralFeatures are allowed to be invoked by the Message which are offered by the Type of the Port that is connected by the Connector over which the Message is sent – we are using this kind of Message sending when modeling test cases with UTP that can be executed via TTCN-3 or JUnit etc.

These are just four possible ways on how to determine the offered BehavioralFeature of a called Lifeline.  I guess there are even more. In any case, your statement

“This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.”

Is not absurd, but for what we doing a normal matter of fact. In that case B would be a (I call them InterfaceComponent, simply a Type of a Port that realizes Interfaces) Type of a Port that is connected with a Connector over which the Message is sent.

But I agree: There is a need to identify and clarify all possibilities for invoking a Behavior.

Regards,

Marc-Florian

Issue 18132: UML2.5: clarification about the semantics of redefinition (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

There are three closely related problems in this issue:


1) incorrect constraint in Structured Classifiers, clause 11, Connector:


roles The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles.
inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))


- The OCL constraint does not take into account the structured classifier's inherited roles.
- The English constraint description is ambiguous whether inherited roles are to be included or not.


2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors.


For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier:
The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element.
The semantics view where all occurrences of a redefined element are replaced by its redefining element.


Ed's message below explains the distinction between these two views.


3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to:
Class diagrams
State machine diagrams
Activity diagrams
Interaction diagrams
Etc

Resolution:
Revised Text:
Actions taken:
October 2, 2012: received issue

Issue 18140: ConnectableElement-end" has @isOrdered='true' (uml25-ftf)

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

I've just came across another issue: "ConnectableElement-end" has @isOrdered='true'. Since it is derived (and not derivedUnion) there is a corresponding operation for that attribute. However, the 'return' parameter for that operation doesn't declare @isOrdered='true'.
Shouldn't the return parameter of operations that describe derived attributes always 'match' the corresponding attribute ?

Resolution:
Revised Text:
Actions taken:
October 5, 2012: received issue

Issue 18141: Problems with XMI IDs in the UML 2.5 UML.xmi file (uml25-ftf)

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

In the case of a derived, non-union attribute for which there is a corresponding derivation operation with the same name, the XMI IDs of one or the other of the attribute or the operation are incorrect in the UML 2.5 Beta 1 UML.xmi file (that is, inconsistent with what the IDs were in UML 2.4.1). For example, the XMI ID for the attribute NamedElement::qualifiedName is AcceptCallAction-qualifiedName. The XMI ID for the operation Namespace::importedMember is ConditionalNode-importedMember. Worse, the XMI IDs of the attribute Connector::kind and the operation Connector::kind are both the same, Connector-kind.

Resolution:
Revised Text:
Actions taken:
October 5, 2012: received issue

Issue 18154: Stable state not needed (uml25-ftf)

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

Category: Minor


The 2.5 spec says:

“A state configuration is said to be stable when:

·         no further Transitions from that state configuration are enabled and

·         all the entry Behaviors of that configuration, if present, have completed (but not necessarily the doActivity Behaviors of that configuration, which, if defined, may continue executing”

 

I believe that the concept of a stable state configuration is not necessary, since all state configurations are, by definition, stable. I cannot think of a transient one

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18155: Default entry if default history transition missing (uml25-ftf)

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

Category: Minor

The behavior in case of a default entry when the default history transition is missing was not specified; The following option was added in 2.5, but needs to be checked by vendors:

“If no default history Transition is defined, then standard default entry of the State is performed”

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18156: Overriding deferred events (uml25-ftf)

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

Category: Minor

The 2.5 spec says:

“Event occurrences remain in the event pool until:

·         a state configuration is reached where these Event types are no longer deferred or, 

·         if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a kind of override option)

It is not clear if the override capability extends inside the deferring State or only on the outside. The latter option was chosen in the spec, since it would be difficult to spot the override if it occurred inside the deferring state. But….

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18157: State of the substates of the history state (uml25-ftf)

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

Category: Clarification




The 2.5 spec says:

“Shallow history entry: If the incoming Transition terminates on a shallowHistory Pseudostate of the composite State, the active substate becomes the substate that was most recently active prior to this entry,”

It is not clear what the ``state`of the substates of the history state are.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18158: Not clear if “else” keyword is defined for State Machines (uml25-ftf)

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

Category: Minor




The 2.5 spec says: 

“As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition”

The formal specification of the “else” keyword is not given (presumably maps to a Constraint that is the conjunctive negation of all the other Constraints)

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18159: Should “completion” event be an explicit event type? (uml25-ftf)

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

Category: Minor




Should a completion event described in the StateMachines chapter be defined as an explicit event type like ChangeEvent, etc.? If so, then it should be discussed in the Commo Behaviors clause as well.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18160: Can passive classes have ClassifierBehaviors? (uml25-ftf)

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

Category: Major




In the StateMachine section “Event processing for state machines”, there is an explicit statement: “for passive classes it can be implemented using a monitor”, which suggests that passive classes implement the run-to-completion paradigm. This implies that passive classes can have classifier behaviors. Perhaps this capability should be removed, but, it may not be backward compatible and might invalidate numerous existing designs (e.g., Rhapsody models).

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18161: Figure 14.39 – missing superclass (uml25-ftf)

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

Category: Minor




The diagram for ProtocolStateMachines does not show the superclass of ProtocolConformance; it should in line with the general convention for such abstract syntax diagrams

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18162: Meaning of State in ProtocolStateMachines (uml25-ftf)

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

Category: Minor




In the section on “State in ProtocolStateMachines” it is stated:

“The States of ProtocolStateMachines are exposed to the users of their context Classifiers. A protocol State represents an exposed stable situation of its context Classifier: When an instance of the Classifier classifier is not processing any BehavioralFeature invocation, users of this instance can always know its state configuration. ”

This does not seem to make sense, at least for declarative protocol state machines – they do not have a run-time manifestation, so it is not clear what it means for the state of such a machine to be “exposed to collaborators”.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18163: Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember. (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The way it is modeled now, a Node’s nested nodes will not appear in its nestedClassifier property, which must be wrong.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18164: Meaning of absent multiplicity notation (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML 2.5 beta does not appear to take a clear position on what it means when the multiplicity is omitted from the notation for an element, although there are many places in the spec itself where multiplicity is absent.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18170: It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

Resolution:
Revised Text:
Actions taken:
August 24, 2012: received issue

Issue 18171: Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Title: UML2.5, section 11: feature inheritance (of attribute properties,
ports and connectors) should be orthogonal to the topology of well-formed
connections in a structured classifier


Summary:


SysML uses extensively UML's StructuredClassifiers.
In UML 2.4.1, the well-formedness constraints for UML's
StructuredClassifiers were written in English only.
In UML 2.5, the well-formedness constraints have both English descriptions
and OCL specifications.


Unfortunately, the UML 2.5 OCL specifications for the well-formedness of
UML's StructuredClassifiers are too restrictive for SysML in 3 areas:


1) StructuredClassifier::/role is a derived union that is subsetted only
once by StructuredClassifier::ownedAttribute.


This means that inherited attributes of a StructuredClassifier are not
considered to be roles of that StructuredClassifier.


2) StructuredClassifier::/part is derived and the derivation is:
ownedAttribute->select(isComposite)


This means that inherited attributes of a StructuredClassifier are not
considered to be parts of that StructuredClassifier.


3) Connector has a constraint, roles, stated as follows:


The ConnectableElements attached as roles to each ConnectorEnd owned by a
Connector must be roles of the Classifier that owned the Connector, or
they must be Ports of such roles.


inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and
structuredClassifier.role->includes(e.partWithPort))



There is a significant conceptual asymmetry between the two disjuncts of
the forAll() clause.


The first disjunct is: structuredClassifier.role->includes(e.role)


This restricts the ConnectableElement to be a role of the
StructuredClassifier owning the Connector; that is, the ConnectableElement
must be an ownedAttribute of that StructuredClassifier.


The second disjunct is: e.role.oclIsKindOf(Port) and
structuredClassifier.role->includes(e.partWithPort)


This also restricts the ConnectableElement::partWithPort to be a role of
the StructuredClassifier owning the Connector; however, the
ConnectableElement Port may be inherited!
(see ConnectorEnd::role_and_part_with_port)


The conceptual asymmetry is that it is OK to connect inherited ports of
owned attributes but it is not OK to connect inherited attributes.


>From a conceptual point of view, UML 2.5 does not provide a rationale for
restricting the connectivity of UML StructuredClassifiers to owned
attributes only.
>From a conceptual point of view, feature inheritance (I.e., of attribute
properties and of connectors) should be orthogonal to the topology of
connections in a StructuredClassifier.

Resolution:
Revised Text:
Actions taken:
October 11, 2012: received issue

Discussion:

Issue 18176: UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint that structural features with isStatic = true may not have a slot in InstanceSpecifications

Resolution:
Revised Text:
Actions taken:
October 18, 2012: received issue

Issue 18177: The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.5: “The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance”, with this email discussion attached

Resolution:
Revised Text:
Actions taken:
October 18, 2012: received issue

Issue 18184: confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”. (uml25-ftf)

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

A "local" transition is a group transition that emanates from a composite state (i.e., it is a group transition representing transitions form any contained substate of the composite source state) and terminates on an internal subvertex (the target vertex). This is OK and quite useful. However, the wording is confusing as is the terminology.

Resolution:
Revised Text:
Actions taken:
October 19, 2012: received issue

Issue 18185: UML association semantics vis-a-vis Interfaces (and other types of classifiers) (uml25-ftf)

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

The semantics of associations are specified in terms of links, which the UML 2.4 spec defines as: "a tuple with one value for each end of the association, where each value is an instance of the type of the end" and the 2.5 spec as "a tuple with one value for each memberEnd of the Association, where each value is an instance of the type of the end". However, the specs include several examples of associations between interfaces. Since interfaces are abstract classifiers they cannot have instances ("Interfaces may not be instantiated"), the semantics of associations whose ends terminate on interfaces cannot be described by the above semantics. 

Some other semantics need to be provided for such cases.

Furthermore, the issue extends to other types of classifiers (e.g., collaborations) where the meaning of "instance" is not straightforward.

Resolution:
Revised Text:
Actions taken:
October 19, 2012: received issue

Issue 18186: UML: No restrictions on what seem to be meaningless associations (uml25-ftf)

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

It seems possible to draw associations between any two kinds of types, including seemingly absurd combinations of associations between, say, an Interface and a Collaboration.Should there be constraints that prevent such combinations? If not, then the semantics of such combinations should be clarified.

Resolution:
Revised Text:
Actions taken:
October 19, 2012: received issue

Issue 18192: Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical. (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

Resolution:
Revised Text:
Actions taken:
October 22, 2012: received issue

Issue 18194: Allow a notation to allow for a default assignment of a decision to the owner of the activity (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

Allow a notation to allow for a default assignment of a decision to the owner of the activity (this is probably the normal circumstances). This is both a UML / SysML issue

Resolution:
Revised Text:
Actions taken:
October 22, 2012: received issue

Issue 18195: Need packages overview diagram and explicit depiction of package dependencies (uml25-ftf)

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 current 2.5 metamodel, there is a diagram that simply shows all the various packages that comprise it. Note, however, that we do not have such a diagram in the spec itself. In fact, as far as I can tell, it seems that the spec does not even mention explicitly that the metamodel is divided up into these packages. 

Furthermore, it is useful to see the dependencies between the various packages captured explicitly in diagrams. In a sense, this shows the intended couplings between the various modules, which is usually important architectural information. Not showing them explicitly either in the spec or in a metamodel diagram is obscuring this and could lead to corruption of the architecture in subsequent maintenance (e.g., the introduction of undesired and even incorrect couplings between the packages).

Resolution:
Revised Text:
Actions taken:
October 23, 2012: received issue

Discussion:

Issue 18226: Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example (uml25-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The example in Figure 17.2 has different dash types for the two reply messages.  



This is confusing since it is by no means significant.

Resolution:
Revised Text:
Actions taken:
October 23, 2012: received issue

Issue 18228: UML2.5 issue : missing constraints on aggregation / composition (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

As far as I know, a Property may only be marked as an aggregation or composition if either (a) it is not an association end or (b) it is the end of a binary association and the other end is not marked as an aggregation or composition.  The spec does not actually say this clearly, and there is no OCL to enforce it.

Resolution:
Revised Text:
Actions taken:
October 25, 2012: received issue

Issue 18245: Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Clarification
Severity:
Summary:

The UML 2.5 beta document explains the mapping of Profiles, Stereotypes,
and Extensions in terms of the CMOF-equivelent semantics as follows:


- A Profile maps to a CMOF Package
Š
- A Stereotype maps to a CMOF class with the same name and properties
Š
- An instance of a Stereotype (created when the Stereotype is applied to
an Element) maps to an instance of the CMOF class representing the
Stereotype. 
It is associated with the Element to which it applies using a Link which
is an instance of the Association to which the Extension is mapped.


According to the above, this means that


1) when defining the stereotype Clock (Fig 12.22), the property
Clock::OSVersion maps to a property of the CMOF class named Clock
2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element
(StopWatch on Fig 12.22), the underlying semantics has an instance of the
CMOF class Clock with a slot corresponding to the property
Clock::OSVersion (Fig 12.27)


It should be possible to define a stereotype extending UML::Slot and apply
such stereotype to a slot corresponding to a property of an instance of a
stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27.


This is a subtle point about the current profile mechanism that should be
made clear in the spec.
I suggest adding an explanation about this in the "MOF Equivalent
Semantics" sub-section of section 12.3.3 Profile Semantics.

Resolution:
Revised Text:
Actions taken:
November 3, 2012: received issue

Discussion:

Issue 18247: Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes? (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

The UML 2.5 beta document is unclear about the combination of stereotype extensions & generalization relationships.
Suppose a stereotype S1 extends metaclasses MC1 and MC2.
Suppose another stereotype S2 specializes S1 and is only applicable to MC1 but not to MC2.


Should S2's extension of MC1 then redefine S1's extensions of MC1 and of MC2 or is this restriction capability beyond the scope of the UML profile mechanism?

Resolution:
Revised Text:
Actions taken:
November 5, 2012: received issue

Discussion:

Issue 18248: Notation for state machine specializations (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter 14, the notation for state machine specializations uses <<extended>> and {final}.


<<extended>> is defined as a constraint-based keyword for a Region or a StateMachine.
However, the notation in 14.3.4 clearly indicates that a state can be extended.
There should be a new entry in the keyword table specifying the constraint-based application 
of the extended keyword to a State that has a non-empty redefinedState.


The notation only covers the possibility of a modeler declaring states and transitions as {final}.
Conceptually, a modeler should also be able to declare a region as {final}.
There is no definition for what {final} is. Since it requires explicit declaration from the modeler, 
it should be defined as a stereotype-based keyword notation with a new stereotype <<final>> defined in the UML standard profile.


<<extended>> and {final} should be explicitly defined in the semantics section in 14.3.3.

Resolution:
Revised Text:
Actions taken:
November 5, 2012: received issue

Issue 18252: Please provide running footers or headers indicating the section/subsection of a page (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

The UML 2.5 document has great hyperlink/navigation support.
However, since sub-sub-sections are unnumbered, it is sometimes difficult to tell where we are in the document if the sub-section runs across multiple pages.


For example, look at sub-section 14.2.3 Semantics. The short title makes sense for the bookmarks but in the document itself, it would be easier if we had: 14.2.3 StateMachines Semantics
This particular sub-section runs over several pages and has several sub-sub-sections; e.g. "States"  on p. 319. It's hard to tell we're in the middle of 14.2.3.
Unfortunately, Acrobat doesn't have a way to highlight the bookmark corresponding to the page we're currently reading.


I suggest adding a footer or header with the numbered section or sub-section title to each page.
It would be even better if the footer/header were in fact a hyperlink to jump to the beginning of that numbered section/sub-section.

Resolution:
Revised Text:
Actions taken:
November 6, 2012: received issue

Discussion:

Issue 18270: Stereotype for extended bound element realization (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.3.3

 

UML 2.5 allows the “expanded bound element” for a template bound element to be related to the bound element using a realization. Should there be a standard stereotype to be applied to a realization used in this way?

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18271: Inconsistent template binding notation example (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclauses: 7.3.4, 9.3.5

 

In 7.3.4, it states that “A TemplateBinding is shown as a dashed arrow with the tail on the bound element and the arrowhead on the template and the keyword «bind». The binding information may be displayed as a comma-separated list of template parameter substitutions…” However, Figure 9.5 in 9.3.5 shows an example of a classifier binding using a realization arrow, not just a plain dashed arrow, and has the template parameter substitutions appearing within angle brackets. Both of these things are inconsistent with 7.3.4.

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18272: Semantics of Namespaces (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.4.3

 

The semantics of Namespaces in 7.4.3 needs to be better specified. In particular:

- The concepts of “enclosing Namespace”, “hidden members” and “accessibility/availability of names” need to be clearly defined.

- The handling of name clashes , visibility and distinguishability needs to be better specified.

- The use of partially qualified vs. fully qualified names needs to be addressed.

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18273: Error in diagram using StringExpressions (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.4.5

 

In Figure 7.6, replace $<resource>$ with $a<Resource>$, $<resource>Allocation$ with $a<Resource>Allocation$ and $<resourceKind>$ with $the<ResourceKind>$ (for Request) or $a<ResourceKind>$ (for System).

 

The notation for template binding shown in Figure 7.6 is also inconsistent with the description in 7.3.4.

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18274: Meaning of access to constrainedElements (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.6.3

 

The semantics of Constraints includes the statement “The only restriction is that the owning Element must have access to the constrainedElements.” What does it mean for one Element to “have access” to another?

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18275: Error in Dependency notation example (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.7.4

 

In Figure 7.18, the name within the guillemets should be a stereotype name, not the dependency name. The dependency name should be separate from the stereotype.

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18276: Notation for DurationObservation with two event elements (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 8.4.4

 

In 8.4.4 it says that “An Observation may be denoted by a straight line attached to the NamedElement it references.” However, a DurationObservation may reference two NamedElements. It is not clear what the notation is for that.

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18277: Semantics of TimeConstraints and DurationConstraints (uml25-ftf)

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

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 8.5.3

 

A TimeConstraint is specified by a TimeInterval that has min and max TimeExpressions. Similarly, a DurationConstraint is specified by a DurationInterval that has min and max Durations. Both TimeExpressions and Durations identify Observations of specific event NamedElements. Should these observed event NamedElements be related to the constrainedElements of the constraints, and, if so, how?

Resolution:
Revised Text:
Actions taken:
November 20, 2012: received issue

Issue 18287: Fixed-point issues with the definition of default values for literals (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of LiteralBoolean in the XMI for UML1.5 includes the following:

 

    <packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">

      …

      <ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">

        …

        <defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>

      </ownedAttribute>

…

 

So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as “the default value for LiteralBoolean::value” in the XMI. This is circular and ill-defined.

 

One issue is with the XMI specification.  The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves.                                             Another issue is with the UML xmi.  This needs to serialize the value for the default value of literals, regardless of other considerations. In the case above, value=”false”.

Resolution:
Revised Text:
Actions taken:
December 5, 2012: received issue

Issue 18366: UML2.5: Clarification about UML profiles (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Revision
Severity:
Summary:

12.3.1 Summary

The only mentions that the profile mechanism is applicable to arbitrary metamodel are:

> The Profiles clause describes capabilities that allow metaclasses to be extended to adapt them for different purposes. (1st paragraph)

The paragraph continues with "the UML metamodel". So the generality is very subtle.

> In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF.

The next sentence reverts to the special case of a UML profile extending the UML metamodel:

> Thus when defining a UML profile, the profile’s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel whose XMI serialization is referenced in Annex E.

The next paragraph is the same:

> Profiles are not a first-class extension capability (i.e., it does not allow for creating new metamodels).

> Rather, the intention of Profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method.

Again, the generality is lost in the next sentence:

> Each such adaptation is grouped in a Profile. It is not possible to remove any of the Constraints that apply to UML using a Profile, but it is possible to add new Constraints that are specific to the Profile.

The reasons for defining a profile are only explained in terms of extending the UML metamodel.

If anything, these reasons are equally applicable for extending UMLDI!

12.3.3 Semantics

The sub-clause "Restricting Availability of UML Elements" is specific to UML profiles extending the UML metamodel.

This is misleading. These restrictions are equally valid for UML profiles extending other metamodels (defined in UML of course)

ProfileApplication.

This is written again from the perspective of a UML profile extending the UML metamodel:

> One or more Profiles that extend UML may be applied at will to a model Package.

Again, the generality is lost.

Stereotypes

The "Restricting Availability of UML Elements" section in Profiles has the following constraint:

> Stereotypes can participate only in binary Associations. The opposite class can be another Stereotype, a non-Stereotype Class that is a packagedElement of a Profile (directly or indirectly), or a UML metaclass.

Because this constraint is in 12.3.1 only and not in 12.3.3, it is unclear whether this constraint is only applicable to UML profiles extending the UML metamodel or not.

These problems are a consequence of the organization of the Profile clause which has an uneven split where the UML-based explanation is in one place (12.3.1) and the generic explanation elsewhere (12.3.3)

For readers, it is difficult to tell whether there are differences between the two capabilities.

It is difficult to tell what is specific to UML profiles extending the UML metamodel (I.e., does not apply to UML profiles extending other metamodels)

It is difficult to tell whether users have to figure out how to "merge" 12.3.1 and 12.3.3 for UML profiles that extend both the UML metamodel and some other metamodel.

This difficulty comes from the duplication of the content, once for UML a second time for other cases.

It would be better if the material were not duplicated at all and if there care special cases for UML profiles extending the UML metamodel that do not apply to other cases, then have these clearly described in a sub-clause.

Resolution:
Revised Text:
Actions taken:
January 8, 2013: received issue

Issue 18376: UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope" (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The semantics of static are defined with respect to a concept called “execution scope”.  I think that concept needs a definition in section 6.3.  Maybe the terminology is wrong – it might be “model instance” or “model execution” or something, but there needs to be a term for a set of related executing instances that comprise an instantiation of the model.

Resolution:
Revised Text:
Actions taken:
January 15, 2013: received issue

Issue 18384: UML 2.5 issue; the word "individual" is incorrect in 9.8 (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Clause 9.8 uses the word “individual” in several places where it would be correct and consistent to use “instance”.

Resolution:
Revised Text:
Actions taken:
January 22, 2013: received issue

Issue 18408: Two entries (uml25-ftf)

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

UML 2.4.1 and UML 2.5 beta1 specs incorrectly show TWO entry behaviors on state, when only one is allowed in metamodel.
Figure 14.5 State with compartments

Resolution:
Revised Text:
Actions taken:
February 4, 2013: received issue

Issue 18411: Semantics of Message argument mapping in Interactions (uml25-ftf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity:
Summary:

The spec is inconsistent regarding the correspondence of Message arguments and its in/inout parameter.

 

In Section 17.4.3 it says: “The arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters.” 

This is also specified in the formal OCL constraint in Section 17.12, subsection Message, subsubsection Constraints

 

However, in Section 17.4.4 it says: “A request-message-label may only have input-arguments with in-parameter-names if the Message has a signature. In this case, the input-arguments are matched by name to the in and inout ownedParameters of an Operation or the attributes of a Signal.”

 

I assume that the OCL is correct and the Notation section would need clarification?!

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18412: Interactions and parameter assignments (uml25-ftf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity:
Summary:

is it intended to not let message arguments being assignable to attributes of the receiving lifeline?

 

As an example: Lifeline A sends a synchronous operation call to Lifeline B for the operation op(in x:Integer). Assume that the Type Lifeline B represents owns a Property p:Integer. The received actual parameter x shall be assigned to Property p of the receiving lifeline. 

 

With the current semantics of Messages and its description for notation it is only possible to assign out/inout/return values to a receiving lifeline. Consider the case that a certain Lifeline receives a Signal (no out/inout/return parameter at all) and wants to store the value of an attribute of that Signal in an attribute (either of the surrounding Interaction or its context Classifier); this is not possible by default. 

 

In my realm (which is validation and testing mainly using UTP), this is quite normal. A system under test (SUT) responds with a Signal and some values of that signal need to be stored for later calculation or re-sending.

 

Shall we allow this in Interactions?

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18413: Reply messages now mandatory? (uml25-ftf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity:
Summary:

until UML 2.3, the spec said about reply messages: “If the Message represents a CallAction, there will normally be a reply message from the called Lifeline back to the calling lifeline before the calling Lifeline will proceed.” 

 

Did the initial submission team agree on making reply messages mandatory? 

 

I’m just asking because the above mentioned sentence was removed (actually already by UML 2.4 RTF) and there is only one example listed in the current spec for synchronous calls showing reply messages, and also the semantics of Message indicates that reply messages are mandatory from now on. 

 

Tool vendors commonly not enforce the existence of reply messages for synchronous calls.

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18414: Classifier::hasVisibilityOf(...) (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

Classifier::hasVisibilityOf(...)
   The description doesn't match the OCL.

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

Issue 18415: InformationFlow::sources_and_target_kind (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL doesn't match the description - no check is made of the
   InstanceSpecification classifier. (This constraint could probably
   be split in two and the type test separated as an operation.)

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

Issue 18416: Metaclass operations incomplete (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

The operations listed for each metaclass should give the uniqueness
   and ordering of all their parameters, including return type. For
   example, NamedElement::getAllNamespaces() is actually ordered. In
   addition, operation redefinitions should be given, for example,
   Package::mustBeOwned().

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

Issue 18417: Table C.1 apply (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

 The semantics of apply refer to 'importedProfile'. There is no
   such property. I'm not entirely sure why there's any OCL at all
   as the keyword is just used with the ProfileApplication diagram
   edge itself.

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

Issue 18419: UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction (uml25-ftf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity:
Summary:

First sentence of fourth paragraph says: 

 

The invalid set of traces is associated only with the use of a Negative CombinedInteraction.

 

But it ought to say:

 

The invalid set of traces is associated only with the use of a Negative CombinedFragment.

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

Issue 18436: Serilaization of required stereotypes (uml25-ftf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Clarification
Severity:
Summary:

There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions:
The stereotype is defined so that it is an required extension (i.e. its isRequired property is “true”)
This stereotype does not have any property or all of its properties are derived (i.e. isDerived is “true”)

As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange).

Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it.

Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified.

Suggested resolution:
To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return “true” when an extension shall be serialized. I propose to use the following OCL expression to specify this query:

context Extension
def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty()

To clarify that extensions that return “false” to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class.

Resolution:
Revised Text:
Actions taken:
February 11, 2013: received issue

Issue 18442: Conflict in use of unlimited natural (uml25-ftf)

Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Clarification
Severity: Minor
Summary:

Section 7.3.32 states in its Notation subsection that an asterisk denotes "unlimited (and not infinity)". Section 7.3.33 states that an asterisk represents "the unlimited (or infinite) upper bound".  That one is infinite and the other not seems a contradiction

Resolution:
Revised Text:
Actions taken:
February 11, 2013: received issue

Issue 18443: UML2.5 issue: constraints needed in model of Standard Profile (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 15144 pointed out a lot of flaws in the modeling of standard profiles.  Some of those flaws involved the absence of constraints. To help manage the process, I’m raising a separate issue that just lists the constraints that are needed. They ought to be OCL in the profile.

 

The client and supplier of Usages stereotyped by Call must be Operations.

The client and supplier of Usages stereotyped by Create must be Classifiers.

Realization and ImplementationClass may not both be applied to the same element.

Specification and Type may not both be applied to the same element.

The clients of Usages stereotyped by Send must be Operations, and the suppliers must be Signals.

Resolution:
Revised Text:
Actions taken:
February 12, 2013: received issue

Issue 18444: UML2.5 issue: clause 10 Signal and Reception (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The sentence in 10.3.3 “The receiving object handles Signals as specified by its Receptions” should read “The receiving object handles Signals as specified by clause 13.3”.    The current sentence seems to imply that a Reception is needed to receive a Signal which is actually not the case,

Resolution:
Revised Text:
Actions taken:
February 12, 2013: received issue

Issue 18448: UML 2.5 - clause 14 does not put Examples at the correct heading level (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

All the other clauses have Examples at the same level as Notation, Semantics etc.  Clause 14 does not do this.  

 

14.3.4 defines the notation {final} in the Examples section: notation should be defined in the Notation section and exemplified in the Examples section.

Resolution:
Revised Text:
Actions taken:
February 13, 2013: received issue

Discussion:

Issue 18449: UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figures 14.37 and 14.38 show the word {extended} but the notation definition in 14.3.4 defines the keyword «extended» in guillemets. If it is a keyword, which is confirmed by Annex C, then the guillemets are correct and the curly braces wrong.

Resolution:
Revised Text:
Actions taken:
February 13, 2013: received issue

Issue 18450: UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In 7.7.5 «instantiate» is described and lower-cased as though it were a keyword.  It sort of implies that Instantiate is a subclass of Dependency.

 

In fact «Instantiate» is a standard stereotype. It should be referred to using upper case, and the text should explain that it is a standard stereotype applied to a Usage. The figure and caption will need changing.

 

(Note: this example is also the topic of issue 17804, which is a separate matter about the direction of the arrow.)

Resolution:
Revised Text:
Actions taken:
February 13, 2013: received issue

Issue 18452: UML 2.5: ActivityPartition::represents keywords (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

The keywords «attribute» and «class» are part of the notation for ActivityPartition (examples in 15.70 and 15.72) but are not specified in the notation and should be. They do appear in Annex C.

Resolution:
Revised Text:
Actions taken:
February 13, 2013: received issue

Issue 18454: Keywords are inconsistently defined and applied (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The word “keyword” is used inconsistently throughout the spec. It is defined in Annex C, which clearly says that keywords are always enclosed in guillemets, and lists the keywords that appear in the spec. Non-stereotype keyword are currently all defined starting with lower case, while standard stereotypes (also listed in Annex C and counting as keywords) use upper case.

However:

1. Several keywords defined in the spec are missing from Annex C: bind, collaboration, complete, disjoint, parallel, iterative, stream and flow.

2. Several references in the spec to standard stereotypes use lower case and should use upper: derive, refine, trace

3. In 7.7.5 instantiate is described and lower-cased as a keyword when it should be referred to as a standard stereotype in upper case

4. 9.2.4 states that the standard notation for classifiers “shows the metaclass in guillemets”. This is not true: almost all classifiers define a lower-case keyword for their notation, such as interface; sometimes the keyword is different from the metaclass name, e.g. primitive.

5. Notwithstanding the above, the notations for Collaboration, Class and StateMachine explicitly and inconsistently use the metaclass name with uppercase. In the case of Collaboration (11.7.4) and Class (11.4.4), Annex C is missing the keyword; in the case of StateMachine, Annex C shows it as statemachine.

6. Some words are described as keywords when they are not. Clause 13: all, at, after, when; clause 14: via, protocol; clause 17: sd, self, out, strict

7. Annex C itself uses the phrase ‘the keyword “trace”’ when it should surely say ‘the keyword «Trace»’.

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

Issue 18455: wrong multiplicity of redefining states (uml25-ftf)

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

UML spec, Figure 15.3 shows that multiplicity of redefining state is 0..1  which automatically means that it is impossible to have two or more subclasses which redefine the same state in their statemachines.

It should be fixed to state [0..*]  I believe

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

Discussion:

Issue 18457: Issue with Reply message in interactions (UML 2.5 Beta) (uml25-ftf)

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 clarifying statement for the labels on reply messages that was added in UML 2.5 Beta, which reads:

"The message-name appearing in a reply-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."


This is more constrained than was the case in UML 2.4 and can lead to some backward compatibility problems. Namely, there is a situation supported in RSA-RTE where the reply message to an Operation call can have a different label than the name of the Operation to which it is a response. 

Although there is no OCL constraint that mandates that the label of the reply message has to be the same as the Operation that caused it, the above text can be interpreted as if such a constraint existed. My suggestion is to modify the second sentence in the quoted text above to read:


" If the Message has a signature, this can be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."


This leaves the clarification in place, but does not prevent the possibility of different labels on the reply message.

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

Issue 18465: UML2.5 issue: incorrect use of oclKindOf()->notEmpty() (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

There is a systematic error in the OCL in Clause 17.  There are many erroneous expressions of the form x.oclIsKindOf(T)->notEmpty().  These are apparently intended to mean x.oclIsKindOf(T), i.e. a Boolean-valued test that x has the type T or a subtype.  

 

The fact that the ->notEmpty() happens to pass the syntax checking is an unfortunate and misleading “feature” of OCL.  Semantically, all of these expressions in their current form will evaluate to true, whatever their arguments.

 

I found these constraints all to have the problem:

 

all_lifelines

interaction_uses_share_lifeline

selector_int_or_string

sending_receiving_message_event

signature_is_signal

signature_is_operation_request

signature_is_operation_reply

Resolution:
Revised Text:
Actions taken:
February 20, 2013: received issue

Issue 18466: Association notation for properties does not allow representation of aggregation (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

UML 2.5 issue.

 

There is a sentence in 9.5.4: “In a Classifier, an attribute may also be shown using association notation, with no adornments at the tail of the arrow.”  This does not allow the use of diamond notation to represent properties that are aggregations or compositions.

Resolution:
Revised Text:
Actions taken:
February 20, 2013: received issue

Issue 18467: [UML 2.5] Redundancy in the definition of use case extensions (uml25-ftf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:

As pointed out by Pete in issue #7793, there is a redundancy between ExtensionPoint::useCase and Extend::extendedCase since the later can be derived from the use case owning the ExtensionPoint. It should be specified as such.

Resolution:
Revised Text:
Actions taken:
February 21, 2013: received issue

Issue 18495: Transition redefinition (uml25-ftf)

A question: For transitions, the spec says: 

“… while the source State and trigger are preserved”

 

Maybe related to not being a native speaker, but for me “preserved” means that at least the triggers defined for the extended transition must remain in the redefining transition, whereas new triggers can be added.

 

Or does “preserve” mean in this context really to seal the triggers, i.e., I cannot add a new one?!

Resolution:
Revised Text:
Actions taken:
February 21, 2013: received issue

Issue 18496: Rg. Realization and InterfaceRealization (uml25-ftf)

not sure, but the way how Interfaces are supposed to be realizd throughout the spec may need some more Clarification in the spec. I might have missed some discussions on this topic, though. If this has already been clarified (haven’t found an issue in the issue sheet for the component section), please ignore my question.

 

The required/provided Interfaces of Components are derived. The derivation algorithm (p 235) makes use of Classifier.allRealizedInterfaces() and C.allUsedInterface(). I do not have any problems with allUsedInterface, but allRealizedInterfaces() or more concrete directlyRealizedInterfaces() is not very well chosen I think. directlyRealizedInterface() is based on Realizations between the Classifier and an Interface. Given this, any Interface that is referenced by ComponentRealization or Substitution is part of the realized Interfaces of that Classifier.

 

As a BehavioredClassifier, a Component should make use of InterfaceRealization solely. However, the provided Interfaces of a Component rely on the above mentioned concept, i.e., a Realization between a Classifier and Interface. Of course, using an InterfaceRealization instead would also do the job and calculate the provided Interface of that Component correctly. In case of Class and Component, it is just confusing why the algorithm to calculate the provided Interfaces is based on Realization, whereas BehavioredClassifier uses InterfaceRealizations. It could be even more confusing, in case only Realization relationships are used to establish the provided Interfaces, asking for BehavioredClassifier.interfaceRealization might return an empty list, since all Interfaces are realized via Realization.

 

This may cause other issues: A DataType could establish a Realization dependency to an Interface. Classifier.allRealizedInterfaces() would return that Interface. This holds true for all non-Class Classifier, in fact. Is this a desired situation?

Resolution:
Revised Text:
Actions taken:
February 22, 2013: received issue

Issue 18505: UML 2.5 Beta 1 9.5.3 Qualifiers (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Revision
Severity:
Summary:

The description of qualifiers in section 9.5.3 is unclear.
I'm really struggling to understand it. The second paragraph
in particular seems to unnecessarily divide qualifiers by
the opposite end multiplicity. (In fact opposite ends, but
the opposite end is for binary associations only.) I have
no idea why this hints at implementation issues. Likewise
why does the note mention tables and indices? It shouldn't
be a note as it's a constraint on the multiplicity given
the qualifier values.


Here is an alternative explanation to replace all three
paragraphs:


A qualified Association end has qualifiers that partition
the instances associated with an instance at that end, the
qualified instance. Each partition is designated by a qualifier
value, which is a tuple comprising one value for each qualifier.
The multiplicities at the other ends of the association
determine the number of instances in each partition. So, for
example, 0..1 means there is at most one instance per qualifier
value. If the lower bounds are non-zero, the qualifier values
must be a finite set, for example, the qualifiers are typed by
enumerations.

Resolution:
Revised Text:
Actions taken:
February 26, 2013: received issue

Issue 18506: Notation for Variables and Variable Actions is very vague and incomplete (uml25-ftf)

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

I think the notation for variables is supposed to be covered by the notation for variable actions – see figure 16.38, which describes a presentation option, but there is actually no specification for the canonical notation that it is an option for – nor was there in 2.4.  We need a new issue: “Notation for Variables and Variable Actions is very vague and incomplete

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Discussion:

I think the notation for variables is supposed to be covered by the notation for variable actions – see figure 16.38, which describes a presentation option, but there is actually no specification for the canonical notation that it is an option for – nor was there in 2.4.  We need a new issue: “Notation for Variables and Variable Actions is very vague and incomplete”, with this email as its summary.

 

-- Steve

 

From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] 
Sent: 27 February 2013 12:47
To: uml25-ftf@omg.org
Subject: Notation for Variables within Activity diagrams

 

Hi,

 

Except if I missed it, I did not find any notional mean to denote a variable within an activity diagram. Is it correct? In that case, how to declare a variable?

 

Thanks,

Cheers… Séb..

Issue 18507: ActionInputPin notations missing (uml25-ftf)

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

UML 2.4.1, in the activity notation for ActionInputPin (as specialized) (Clause 12.3.3), says:


  "An action input pin with a ReadVariableAction as a fromAction is notated as an input pin with the variable name written beside it. An action input pin with a ReadSelfObject as a fromAction is notated as an input pin with the word “self” written beside it. An action input pin with a ValueSpecification as a fromAction is notated as an input pin with the value specification written beside it."


The above seems to be missing from 2.5's notation section for ActionInputPin (Clause 16.2.4), though it is covered in Annex B (Clause B.4.3, Activity Diagram Labels), search on "ActionInputPin".

Would also be good to include figures in the notation section for ActionInputPin (Clause 16.2.4), similar to Figure 16.38 (Presentation option for AddVariableValueAction).

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18528: Interactions needs to fix Gate name Distinguishability rules (uml25-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Revision
Severity:
Summary:

The isDistingishableFrom() operation of NamedElement needs to be
overridden for Gate class  to cover the case of when the gate is used as
a formalGate of an Interaction.  The association end formalGate subsets
ownedElement,  and since the Gate name attribute is optional, it is
allowed to have two formal gates without an explicit name, but having
derived names which are distinct.


Even though the gate matching rules do not use this operation,  we need
to override it to avoid problems.


In addition to this fix, there is a also need to add constraints to the
gate names used for Gates for the gate matching rules to work properly.
In particular, there are cases in use of gates which require distinction
for the gate matching rules to work.


Thus there is still a need to add new constraints on gate Names (explicit
or derived).


Because Gates which do not have an explicity name attribute  have derived
names, any constraint must include the possibility of these derived
names.


There is an explicit operation getGateName()  on Gate class which returns
the name of the gate which is to be used in the gate matching rules.  If
a gate does not have an explicit name attribute, a gate name is derived
from the name of the message the gate is attached to , and the direction
of the message with respect to the gate  (e.g,  foo_in,  foo_out). The
direction "in" or "out" is considered with respect to the outer perimeter
of the interaction fragment  that the gate is attached to.


UML 2.5 added Gate matching rules in OCL, using this getGateName()
operation, however there are currently no gate name distinguishably
constraints in the spec.   Two gates in the same container may have
duplicate derived names, just because they are attached to two different
messages, with the same direction, which happen to have the same name.
There are cases when the gate matching rules will not work unless at
least one of these gates needs includes an explicit name attribute value
contrived to avoid the collision of the getGateNames() operation.


The association end formalGates of Interaction subset ownedMember, and,
as already stated above, we have to override the isDistinguisableFrom()
operator for gate class.  However, If there were two formal Gates with
the same gate name in an interaction,  the gate matching rules would
become invalid.


The association ends actualGates of  InteractionUse, and cFragmentGates
of CombinedFragment, both subset ownedElement, not ownedMember.  So they
no not need to obey the isDistinguisableFrom test. However, even though
not required for the UML namespace Rules, actual Gates for an
InteractionUse should have distinguishable gate names, in order for the
gate matching rules to work.


For the same reason, If a cFragmentGate is outside the CombinedFragment,
then it must be distinguishable from other outer cFragmentGates of that
same CombinedFragment.


For the same reason, any two  inner cFragmentGates associated with the
same InteractionOperator of a  CombinedFragment  must have distinguished
gate names.


Thus we need to add a set of four constraints (one for each kind of gate)
to the Gate class.  Adding these four constraints will ensure that the
gate matching rules work correctly.


Proposed Change:


Override the isDistinguishableFrom() operation of Gate to always return
true.


Add the following four new constraints to the Gate class.  These rely on
the four existing boolean operators of the Gate class which are used to
determine in which of the four contexts of association that the gate is
an instance of.


formal_gate_distinguishable
isFormal() implies <test that no other formal
gate of the parent Interaction returns the same getGateName() as returned
for self>


actual_gate_distinguishable
isActual() implies <test that no other actual
gate of the parent InteractionUse returns the same getGateName() as
returned for self>


outside_cf_gate_distinguishable
isOutsideCF() implies <test that no other
outside cf gate of the parent CombinedFragment returns the same
getGateName() as returned for self>


inside_cf_gate_distinguishable
isInsideCF() implies <test that no other
inside cf gate attached to a message with its other end in the same
InteractionOperator as self returns the same getGateName() as returned
for self>


I leave the detailed OCL for the actual  OCL to include within the <  >
for  the actual resolution of this issue.

Resolution:
Revised Text:
Actions taken:
March 5, 2013: received issue

Issue 18544: Classifier operation inherit(NamedElement[]) : NamedElement[] (uml25-ftf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity:
Summary:

Classifier operation inherit(NamedElement[*]) : NamedElement[*] needs to be overridden for Signal, Interface, Enumeration, Component, Association

Resolution:
Revised Text:
Actions taken:
March 13, 2013: received issue

Issue 18545: Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature (uml25-ftf)

Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out.

Resolution:
Revised Text:
Actions taken:
March 13, 2013: received issue

Issue 18566: Incorrect text on state list notation interchange (uml25-ftf)

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

Under Figure 14.12 (Submachine Sate that uses an exit point), there is a NOTE saying the graphical notation for state lists cannot be exchanged normatively, but the interchange model for this given in the paragraph under Figure B.14 (State Shapes), starting at the third sentence.

Resolution:
Revised Text:
Actions taken:
March 17, 2013: received issue

Issue 18568: Issue for Figure 17.18 (uml25-ftf)

Figure 17.18 (Abstract Syntax: InteractionUse) does not show the association ‘A_returnValueRecipient_interactionUse’

Resolution:
Revised Text:
Actions taken:
March 19, 2013: received issue

Issue 18569: UML 2.5 FTF 14.2.3 Page 327 Typo (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

Two examples of AnyReceivEvent rather than AnyReceiveEvent

Resolution:
Revised Text:
Actions taken:
March 19, 2013: received issue

Issue 18570: UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput (uml25-ftf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

The semantics of DecisionNode consistently uses
decisionInputBehavior. However the property is
actually decisionInput. Similarly for the notation
and the constraint two_input_parameters.

Resolution:
Revised Text:
Actions taken:
March 19, 2013: received issue

Issue 18650: Inheriting Connectors (uml25-ftf)

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

If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should?


If inherited, how should they be represented?  If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model.


See diagram attached

Resolution:
Revised Text:
Actions taken:
April 10, 2013: received issue

Issue 18677: UML 2.5 FTF] Editorial / §15.5.1 p429 (uml25-ftf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:

I don’t know whether this has already been raised or corrected
 
In §15.5.1 “Summary”, p429. The second sentence starts with: “Generally, tThe ControlNodes […]” => the double “t” has to be removed.

Resolution:
Revised Text:
Actions taken:
April 16, 2013: received issue

Issue 18683: Contradiction between the abstract syntax and semantics of an Interval (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2.5 Beta1, section 8.5.3, the semantics of an Interval specifies that:


An Interval is evaluated by first evaluating each of its constituent ValueSpecifications, which must each evaluate to a single value. 
The value of the Interval is then the range from the min value to the max value—that is, the set of all values greater than or equal to the min value and less than or equal to the max value (which may be the empty set). 


The semantics suggests that an Interval would own its constituent min/max ValueSpecifications; however, the abstract syntax shown in Fig 8.4 shows otherwise: min/max do not have composite aggregation.
This means that:
An Interval does not own its constituent min/max ValueSpecifications
The same ValueSpecification can be used as the min or max of more than one Interval (I.e., multiple Interval can share the same min/max ValueSpecification)
Intervals are the only ValueSpecifications that do not compositionally own their constituent parts:
LiteralSpecifications compositionally own their values
Expressions compositionally own their operands and sub-expressions
Durations and TimeExpressions own their expressions.
Some ValueSpecifications have non-compositional properties but these do not have the semantics of "constituent parts" like min/max do for Interval:
TimeObservations and DurationObservations refer to events non-compositionally
TImeExpressions and Durations refer to optional observations
OpaqueExpressions optionally refer to behavior and behavior result parameters non-compositionally.
Suggest changing all min/max association end properties defined in Interval, TimeInterval and DurationInterval to have composite aggregation.

Resolution:
Revised Text:
Actions taken:
April 20, 2013: received issue

Issue 18684: Forked association notation ill-formed (uml25-ftf)

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

Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same.  If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also).  The notation wasn't in 2.4.1 that I can find.

Resolution:
Revised Text:
Actions taken:
April 24, 2013: received issue

Issue 18687: UML 2.5: Time Observation and Duration Observation problem (uml25-ftf)

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 current model of Time (UML 2.5), TimeObservation and DurationObservation are both a kind of Observation which is, in turn, a kind of PackageableElement. Significantly, however, neither is a kind of ValueSpecificaiton or even a kind of TypedElement. Hence, it is not particularly meaningful to use it in expressions such as constraints or shown in numerous diagrams such as Figure 8.5 or in numerous diagrams in the Interactions clause (clause 17). 


Note that these examples might be OK if they actually referenced not the observations themselves, but to the associated TimeExpressions. Unfortunately, there are two issues that prevent this as a solution to the above problem:


(1) It is not possible to navigate from an observation to its associated TimeExpression, which means that, given a TimeObservation or a DurationObservation element in a model, it is not possible to easily find the time value that is associated with it (what is the use of a time observation if we do not know the time value associated with it?)


(2) A TimeExpression can be associated with multiple TimeObservations (or DurationObservations), which means that referencing a given TimeExpression does not necessarily identify which observation is being referenced. Hence, if the time expression is referenced in a constraint, that would presumably automatically apply to all observations pointed to by that expression, even if that is not the intent.


One possible simple solution is to make Observation a kind of ValueSpecification instead of a kind of PackageableElement. (A more systematic solution would be to revisit and rationalize the entire SimpleTime and Intervals metamodel, which seem unnecessarily complicated.)

Resolution:
Revised Text:
Actions taken:
April 24, 2013: received issue

Issue 18690: Behavior is not allowed to be source or target of an InformationFlow (uml25-ftf)

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

The InformationFlow element has an additional constraint that only allows a few classifiers to be source and target of an information flow. I don’t know why an Activity  or more general a Behavior  is not allowed to be a source or target of an information flow.


I propose to allow Behavior source/target of an InformationFlow.

Resolution:
Revised Text:
Actions taken:
April 30, 2013: received issue

Issue 18695: parts should be allowed to show their interfaces (uml25-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de)
Nature: Enhancement
Severity: Minor
Summary:

The specification allows ports on parts to also show the interfaces of the type of the port:


page 202: "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Port, using the same notation as for the Port’s definition."


The same thing is not allowed for parts. While it might be not all that important for parts, it makes the notation incoherent. 


Proposed Resolution:
Add following sentence:


"Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Part, using the same notation as for the Part’s definition."

Resolution:
Revised Text:
Actions taken:
May 3, 2013: received issue

Issue 18696: Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2.5, the summary of the Actions chapter in 16.1 refers to the possibility of an Interaction owning an Action and makes several points:

(1) Actions are contained in Behaviors, specifically Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors determine when Actions execute (2) and what inputs they have (3). However, the abstract syntax and semantics of Actions are very dependent on Activities (4), because they specialize elements and semantics from Activities to accept inputs and provide outputs and to define Actions that coordinate other Actions (Structured Actions, see sub clause 16.11).

(1) is reflected in figure 17.1

(2) is under-specified.

17.12, ActionExecutionSpecification states:
An ActionExecutionSpecification is a kind of ExecutionSpecification representing the execution of an Action.
17.5.3 semantics of Action Execution Specification states:
ActionExecutionSpecification is used for interactions specifying messages that result from actions, which may be actions owned by other behaviors.

The semantics of ActionExecutionSpecification should be described in 1 place; suggest 17.12.

(3) is a problem because 17.12 + 17.5.3 are insufficient to explain the semantics of ActionExecutionSpecification.

Depending on who owns the Action and of the context classifier for the Action vs. the Interaction, several cases need to be distinguished.
An ActionExecutionSpecification refers to an Action owned by the owning Interaction
An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is different than the context classifier of the owning Interaction
An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is also the context classifier of the owning Interaction
The first case is severely under-specified.
The last two cases are more complicated because the semantics of ActionExecutionSpecification depends on the semantics of Action owned by an Activity.

In all 3 cases, it is unclear how the message notation in Interactions relates to the input/output pins of actions referred to via an ActionExecutionSpecification.

Resolution:
Revised Text:
Actions taken:
May 7, 2013: received issue

Discussion:

Issue 18697: UML2.5's Connector role constraint excludes inherited roles (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:


[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier
that owned the Connector, or they must be ports of such roles.


inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))


Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute


In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:


Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.


Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.


In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:


The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.


One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.


I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles'  where applicable.


I also suggest introducing a query:


StructuredClassifier::allRoles() : ConnectableElement[*]
body: allFeatures()->select(oclAsKind(ConnectableElement))->collect(oclAsType(ConnectableElement))->asSet()


Then the roles constraint on Connector in 11.8 should read:


[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
that owned the Connector, or they must be ports of such roles.


inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.allRoles()->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.allRoles()->includes(e.partWithPort))

Resolution:
Revised Text:
Actions taken:
May 7, 2013: received issue

Discussion:

Issue 18698: Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization? (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

ML 2.5 section 17.2.3 Interaction semantics says:


As Behavior an Interaction is generalizable and redefineable. Specializing an Interaction is simply to add more traces to those of the original. The traces defined by the specialization is combined with those of the inherited Interaction with a union.


If a parent Interaction defines Gates, then a specializing Interaction will inherit its parent's Gates as  Classifier::/inheritedMember.
However, Gates that are inherited from a parent Interaction are not formalGates of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!


Similarly, if a parent Interaction has fragments, then a specializing Interaction will inherit its parent's InteractionFragment as Classifier::/inheritedMember.
However, InteractionFragment that are inherited from a parent Interaction are not fragments of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!


To support the intent of the Interaction semantics, I suggest adding RedefinableElement as generalization parents of Gate and InteractionFragment.

Resolution:
Revised Text:
Actions taken:
May 7, 2013: received issue

Discussion:

Issue 18699: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In UML 2.5 section 11.7.3 Collaboration Semantics says:

Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
Unfortunately, this is not possible:

Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
That is, I suggest replacing:

Collaboration::collaborationRole : ConnectableElement[*] {subsets StructuredClassifier::role}

with:

Collaboration::collaborationRole : ConnectableElement[*] { subsets Classifier::inheritedMember}

Resolution:
Revised Text:
Actions taken:
May 7, 2013: received issue

Discussion:

Issue 18701: Incorrect notation in figure 14.37 (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 14.37 shows an “extended” state machine.  In it, the state ReadAmount is shown as extended, which means it is not inherited.  Hence ReadAmount should have a solid border, not a dashed one.

Resolution:
Revised Text:
Actions taken:
May 8, 2013: received issue

Issue 18702: UML2.5 clause 17 keyword inconsistency (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords.  These should be fixed in a similar manner to issue 18454.

Resolution:
Revised Text:
Actions taken:
May 8, 2013: received issue

Issue 18706: Clarification needed about the semantics of stereotype specialization and stereotype application (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Many profiles define stereotypes that specialize other stereotypes.
UML 2.5 does this in two places:


* UML 2.5, section 12.3.5 Examples, Figure 12.19 where the Entity and
Session stereotypes specialize the Bean stereotype
* UML2.5, section 22 StandardProfile, Figure 22.1 where the File
stereotype has several specializations (Document, Executable, Š)


The UML specification does not explicitly define a the semantics of
stereotype specialization, particularly with respect to stereotype
application.
This puts UML users and UML tool vendors in the difficult position to
interpret the UML specification to come up with such a semantics.
Given the popularity of UML profiles in practice, the UML specification
must explain this clearly.


I propose using the UML semantics of classifier generalization as a
guiding principle for specifying the semantics of stereotype
specialization and application; that is:


1) If a stereotype S2 specializes S1, then the semantics of S2 must be
consistent with the semantics of S1.
2) Given (1), the semantics of applying S2 to X must be consistent with
the semantics of applying S1 to X.
3) Given (1) and (2), it must be possible to define S2 in several ways:


3a) S2 specializes S1; S1 is abstract and does not define any extension;
S2 extends Classifier.


There is only one property: S2::base_Classifier.
It is not possible to apply S1 because it is abstract.
Only S2 can be applied.


3b) S2 specializes S1 but S2 does not define its own extension; instead,
it inherits S1's "base_" property or properties.


It is possible to apply S1 or S2 or both to the same element.
The semantics should be consistent regardless of whether S1 only, S2 only
or S1 and S2 are applied.


3c) S2 specializes S1 and defines its own extension(s) by specializing
S1's extension relationships and redefining the extension ends.


For example, suppose S1 extends Classifier, then S1 has a property:
S1::base_Classifier.
Then, if S2 extends Classifier, the extension between S2 and Classifier
specializes the extension between S1 and Classifier with redefinitions on
both sides.
That is, S2::base_Classifier { redefines S1::base_Classifier }


This ensures that the semantics of applying S1 only to a Classifier is
consistent with the semantics of applying S2 only to the same Classifier
and with the semantics of applying S1 and S2 to the same Classifier.


3d) S2 specializes S1 and defines its own extensions(s) but does not
specializes any of S1's extensions.


For example, suppose S1 extends Classifier, then S1 has a property:
S1::base_Classifier.
Then, if S2 extends Classifier without specializing S1's extension, then
there are two distinct properties: S1::base_Classifier and
S2::base_Classifier
This should be ill-formed; there should be an explicit specialization of
the extension and redefinitions of both sides as in (3c).

Resolution:
Revised Text:
Actions taken:
May 10, 2013: received issue

Issue 18715: Clarify that stereotypes can be applied to UML DI (uml25-ftf)

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

[From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 -- that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

Resolution:
Revised Text:
Actions taken:
May 14, 2013: received issue

Issue 18716: UML 2.5 issue. AssociationClasses should have isUnique property (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Dragan Milicev’s paper at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip points out that AssociationClasses can be multiply instantiated between the same set of end instances, even when all the ends are marked as unique.  He proposes adding an isUnique property to AssociationClass to distinguish between circumstances where this is allowed and those where it is not.

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

Issue 18717: Annex B summary table (uml25-ftf)

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

It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

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

Issue 18726: About UseCase description (uml25-ftf)

The description of a UseCase is: “A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.”.

However, UseCase may have no subjects. What happen in that case?

Resolution:
Revised Text:
Actions taken:
May 21, 2013: received issue

Issue 18727: The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:


// difference in the parameter direction
op1(String)
op1():String


// difference in the parameter effect
op2(update String)
op2(delete String)


// difference in the parameter exception
op3(Throwable)
op3() throws Throwable


// difference in the parameter collection characteristics
op4(Set(String))
op4(String[1])


This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)


This can be easily fixed.


In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:


...->isUnique(ownedParameter->collect(type))


With:


…->isUnique(ownedParameter->collect(p|Tuple{name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper}))


Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

Resolution:
Revised Text:
Actions taken:
May 22, 2013: received issue

Issue 18728: Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are.


For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable.
It is unclear whether this is an explicit intent of the spec or a bug in the spec.

Resolution:
Revised Text:
Actions taken:
May 22, 2013: received issue

Issue 18729: UseCases: Explanation of words “fragment” and “increment” (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The semantics of UseCases uses the words “fragment” and “increment” without explaining what these words mean in terms of the metamodel

Resolution:
Revised Text:
Actions taken:
May 23, 2013: received issue

Issue 18730: UseCases editorial change (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”,  “extending” should read “extended”.

Resolution:
Revised Text:
Actions taken:
May 23, 2013: received issue

Issue 18731: UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Although the textual semantics asserts that it can – “individual fragments” and other references - there is no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

Resolution:
Revised Text:
Actions taken:
May 23, 2013: received issue

Discussion:

Issue 18732: The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it. (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

Resolution:
Revised Text:
Actions taken:
May 23, 2013: received issue

Issue 18736: Timing Events Question / Issue (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

A wait for an absolute time event is reached in an activity diagram, but when the event time is evaluated, the time is in the past. 
 
Does the timer receive that event and continue, or does it wait there forever, or is the behaviour not specified. 
 
The spec does not seem to be specific.

Resolution:
Revised Text:
Actions taken:
May 27, 2013: received issue

Issue 18747: Observations in TimeExpressions (uml25-ftf)

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

In section 8.4.4 dealing with TimeExpression and Duration (both of which are kinds of ValueSpecification) it currently says:


"A TimeExpression or Duration is denoted by the textual representation of its expr, if it has one (see sub clause 8.3.5). The representation is of a formula for computing the time or duration value, which may include the names of related Observations and constants. If a TimeExpression or Duration does not have an expr, then it is simply represented by its single associated Observation."



It is not clear to me what is meant by "which may include the names of related Observations ". An Observation in the current time model is a kind of PackageableElement and not a value specification; i.e., it does not represent a value. The above text seems to suggest some kind of special case for Observation such that it should be treated as a value when its name appears in a TimeExpression or Duration. If so, what is the type of that value and where is it stored? (Note that Observation does not have an attribute for storing such a value.) What happens if the expression is one that computes the value of the Observation? Or, if the value of the Observation is needed to compute some other value?


I suggested earlier that this problem can be easily resolved if we make Observation a kind of ValueSpecification, but this does mean a metamodel change.

Resolution:
Revised Text:
Actions taken:
June 2, 2013: received issue

Issue 18748: UML 2.5 class_name (uml25-ftf)

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:

In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement.  This is the only place in the spec where <class_name> appears.   <class-name> appears in the text following the BNF.  <class_name> in the BNF should be changed to <class-name>.

 

Recommend that we add the following statement to the BNF

 

<class-name>::=<Variable> | <Parameter> | <Property>

Resolution:
Revised Text:
Actions taken:
June 3, 2013: received issue

Issue 18749: What is the abstract syntax for Figure 17.25? (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 17.25 is very helpful to understand how interaction diagrams look like in the abstract syntax.


It is really unfortunate there is no such diagram for all the figures in the interaction chapter.
In particular, Figure 17.27 defies my ability to understand the abstract syntax behind it.


Figure 17.27 shows several elements that an Activity can own but not an Interaction:
initial state
Control flow edges
Final state
Decision node
Figure 17.27 shows several elements that an Interaction can own but not an Activity:
(inline) interaction
Duration constraint
Interaction use
Have I missed something or is there a genuine mismatch between the capabilities implied by the interaction diagram overviews per 17.10 and the actual capabilities of interactions per 17?

Resolution:
Revised Text:
Actions taken:
May 27, 2013: received issue

Discussion:

Issue 18750: UML 2.5 Issue: specification for qualified association ends is in wrong clause (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

Resolution:
Revised Text:
Actions taken:
June 4, 2013: received issue

Discussion:

Issue 18752: Completion events disambiguation (uml25-ftf)

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

Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

Resolution:
Revised Text:
Actions taken:
June 4, 2013: received issue

Issue 18753: Behavior after exceptions are encountered (uml25-ftf)

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 discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities. 

So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception?  For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

Resolution:
Revised Text:
Actions taken:
June 4, 2013: received issue

Issue 18754: Event pools for passive objects (uml25-ftf)

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

There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

Resolution:
Revised Text:
Actions taken:
June 4, 2013: received issue

Issue 18756: UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends.  For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

Resolution:
Revised Text:
Actions taken:
June 5, 2013: received issue

Issue 18759: UML: Parameter Direction and Effect (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

The rules on Parameter Direction and Effect, seem overly weak.

It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

And Conrad says:
Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

But Ed Seidewitz says
The object passed out in on inout parameter doesn't have to be the same one that was passed in.

For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

So, we have at least different suggestions for changes to this material.

Resolution:
Revised Text:
Actions taken:
June 5, 2013: received issue

Issue 18760: actors of a use case express the requirements of its subject(s) regarding its/their environment. (uml25-ftf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Quoted from §18.1.3, p686:  “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging 
signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an 
associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.”
 
There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

Resolution:
Revised Text:
Actions taken:
June 6, 2013: received issue

Discussion:

Issue 18777: UML 2.5 FTF Receptions may not have a method (uml25-ftf)

Click here for this issue's archive.
Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.
 
context Reception
inv: self.method->isEmpty()
 
What do you think?

Resolution:
Revised Text:
Actions taken:
June 12, 2013: received issue

Discussion:

Issue 18788: Association::endType() is inconsistent (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The operation Association::endType() is inconsistent in multiplicity and ordering with the derived property endType which it is intended to calculate – the property is [1..*, ordered, unique} and the operation is {0..*, ordered, nonunique}.  We think that the property is correct and the operation should be changed to match.

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18789: Action operation redefinition is invalid (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The operation Action::allOwnedNodes() redefines Action::allActions().  That must surely be wrong.

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18790: The resolution to 18697 contains errors (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

The definition for the new operation allRoles() contains no textual documentation.  Also the OCL is wrong; it should read:

 

allFeatures()->select(oclIsKindOf(ConnectableElement))->collect(oclAsType(ConnectableElement))->asSet()

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18791: Improve documentation of how derived properties are calculated (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type.

Resolution:
Revised Text:
Actions taken:
June 25, 2013: received issue

Issue 18792: The resolution to issue 18415 contains invalid OCL (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

18415 was applied in Ballot 6.  The revised OCL for sources_and_targets_kind contains the expressions self.informationSource.classifier and self.informationTarget.classifier, which are not well-typed.  The first subexpression gives a NamedElement which in general does not have a classifier.  The correct OCL should check if it is an InstanceSpecification, cast to InstanceSpecification and then check its classifier.

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18793: The resolution to Issue 18528 contains incorrect OCL and operation names (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment.  Also the name getGateName() should be getName() throughout the revised text.

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18801: ActivityParameterNode notation (uml25-ftf)

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

Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.


UML spec says:
An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label. 


However, I can't find Parameter BNF.


Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

Resolution:
Revised Text:
Actions taken:
July 4, 2013: received issue

Issue 18802: Clarification of use of BNF for textual notations (uml25-ftf)

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

In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

Resolution:
Revised Text:
Actions taken:
July 9, 2013: received issue

Issue 18806: Definition of allOwningPackages() (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

NamedElement:: allOwningPackages() is documented as 

 

“The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.”

 

But the OCL is 

 

if namespace.oclIsKindOf(Package) 

then 

let owningPackage : Package = namespace.oclAsType(Package) in 

owningPackage->union(owningPackage.allOwningPackages()) 

else 

null 

endif

 

Which would stop looking at any element not owned by a Package - which contradicts the documentation.

I think it should instead read:

 

allNamespaces()->select(oclIsKindOf(Package))

 

But allOwningPackages is only used in Profile::references_same_metamodel, and I don’t like that either:

 

All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel. 

inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()-> 

union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

 

Surely this is completely wrong, both in its own right, and especially in the light of the following statement:

 

Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

 

I’m thinking the right logic would be something like this:

 

(metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

and 

metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

                                                                                             

Any comments?

Resolution:
Revised Text:
Actions taken:
July 10, 2013: received issue

Issue 18810: Avoid covariant parameters in metamodel operation redefinition (uml25-ftf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition.  MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it.  This can be done using a precondition that requires the parameter to be of the right type.

 

Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

Resolution:
Revised Text:
Actions taken:
July 11, 2013: received issue

Issue 18812: No explanation of how to deal with conflicting transitions of equal priority (uml25-ftf)

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

The spec does not say anything about how to deal with the case where two or more conflicting transitions with the same priority (e.g., triggered by the same event but with different guards that evaluate to true). Presumably, this is left as an implementation choice.


In any case, there should be an explicit statement on this point.

Resolution:
Revised Text:
Actions taken:
July 15, 2013: received issue

Issue 18816: Dashed interaction lifelines in UML DI (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Interaction lifelines can be dashed, but the model in Annex B cannot express this.

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18817: Classifier and state annotations in UML DI (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Annex B should explain how the {abstract} annotations in UMLClassifierShapes and the {extended} and {final} annotations in UMLStateShapes are modeled.

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18818: Dependencies with more than two ends in UML DI (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

Annex B should explain how dependency lines with more than two ends are modeled

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18819: Ownership of property qualifier rectangles (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Annex B should explain the ownership of property qualifier rectangles

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18820: Template parameter rectangles (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Annex B should explain how template parameter rectangles are modeled

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18821: Labels for generalization sets in UML DI (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

Annex B should explain how to model labels of generalization sets.

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18823: Wording corrections in Behavior Diagrams and Activity Diagram Labels (uml25-ftf)

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

Clause B.4.2 (Behavior Diagrams), second bullet, UseCase => Actor.


Clause B.4.3 (Activity Diagram Labels), second bullet, UMLObjectNodes with ActivityParameterNodes => UMLShapes with ActivityParameterNodes as modelElements

Resolution:
Revised Text:
Actions taken:
July 17, 2013: received issue

Issue 18830: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

UML says:

An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard).

Mapping this to xsd:double is just wrong:

xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality.

xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits.

3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double

[Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.

Note: The only significant differences between float and double are the three defining constants 53 (vs 24), -1074 (vs -149), and 971 (vs 104).

3.3.5.1 Value Space

The ·value space· of double contains the non-zero numbers m × 2e , where m is an integer whose absolute value is less than 253, and e is an integer between -1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '-INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '-0' to refer to positiveZero and negativeZero.

Equality and order for double are defined as follows:

Equality is identity, except that 0 = -0 (although they are not identical) and NaN ? NaN (although NaN is of course identical to itself).

0 and -0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values.

For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; -INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and -0 are greater than all the negative numbers and less than all the positive numbers.

Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN').

Note: The Schema 1.0 version of this datatype did not differentiate between 0 and -0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008].

3.3.5.2 Lexical Mapping

The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN'

Lexical Space

[5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep

The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression):

(\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN

The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible?and is thus useful for insuringg inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008].

3.3.5.3 Facets

The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

whiteSpace = collapse (fixed)

Datatypes derived by restriction from double may also specify values for the following ·constraining facets·:

pattern

enumeration

maxInclusive

maxExclusive

minInclusive

minExclusive

assertions

The double datatype has the following values for its ·fundamental facets·:

ordered = partial

bounded = true

cardinality = finite

numeric = true

Resolution:
Revised Text:
Actions taken:
July 25, 2013: received issue

Issue 18831: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value (uml25-ftf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'.
The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools.

Resolution:
Revised Text:
Actions taken:
July 25, 2013: received issue

Issue 18847: problems with BehavioralFeature::method (uml25-ftf)

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

We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs.

The UML metamodel problems:

1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible).
2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible)
3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable.

Clarifications and possible spec corrections are highly appreciated.

UML 2.5 beta spec says:

ï‚· method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior).

ï‚· specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier.

Proposed changes:
1. Don't constrain where behavior must be owned to implement operation.
2. Let the same behavior be a method of more than one Operation.
3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived.
4. Allow one method only and use redefining Operations instead.

Resolution:
Revised Text:
Actions taken:
August 1, 2013: received issue

Issue 18848: Assocation display options too narrow (uml25-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Raphael Barbau, raphael.barbau(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

The options on class and composite diagrams for how associations are displayed (with/without dots, etc) apply to other diagrams, such as package and object diagrams.

Resolution:
Revised Text:
Actions taken:
August 1, 2013: received issue