Issues for UML 1.4 Revision Task Force discussion list

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

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

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

Issue 790: UML Documentation-Typos (01) (uml-rtf)

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

Summary: Page 1
 1. Preface
 paragraph 4: UML Notation Guide - reads "...defines notion and provides
 supporting examples..." but presumably should read "...notation..."

Resolution: Fixed in UML 1.2.
Revised Text: UML Notation Guide - reads "...defines notion and provides
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

 Fixed in UML 1.2

Issue 791: UML Documentation--Typos (02) (uml-rtf)

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

Summary: UML Summary, v 1.1: Page 3
 3. Goals of the UML
 paragraph 10, last line: reads "...directly by he standard..." but
 should read "...the..."

Resolution: Fixed in UML 1.2.
Revised Text: reads "...directly by he standard..." but
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 792: UML Documentation--Typos (03) (uml-rtf)

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

Summary: UML Summary, v 1.1: Page 7
 4.1.1 UML-Defining Artifacts - UML Extensions
 paragraph 3: UML Variant - reads "...It can specializes the UML
 metamodel..." but should read "...specialize..."

Resolution: Fixed in UML 1.2.
Revised Text: UML Variant - reads "...It can specializes the UML
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 793: UML Documentation--Typos (04) (uml-rtf)

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

Summary: Page 8
 4.2 Outside the scope of the UML
 paragraph 2: Tools - reads "...not an tool interface..." but should read
 "...a..."

Resolution: Fixed in UML 1.2.
Revised Text: Tools - reads "...not an tool interface..." but should read
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 794: UML Documentation--Typos (05) (uml-rtf)

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

Summary: Page 9
 4.3 Comparing UML to other modeling languages
 paragraph 5: reads "...as they previous knew..." but should read
 "...previously..."

Resolution: Fixed in UML 1.2.
Revised Text: reads "...as they previous knew..." but should read
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 795: UML Documentation--Typos (06) (uml-rtf)

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

Summary: Page 14
 5.2 UML 1.0 - 1.1 and the UML partners
 paragraph *: Microsoft - the last sentence ends in two periods (..)
 instead of one

Resolution: Fixed in UML 1.2.
Revised Text: Microsoft - the last sentence ends in two periods (..)
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 796: UML Documentation--Typos (07) (uml-rtf)

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

Summary: General
 Inconsistent use of "OOAD" and "OOA&D"

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
December 3, 1997: received issue
July 6, 1999: closed issue

Discussion:

 received issue

Issue 815: Error on association owners (uml-rtf)

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

Summary: The following constraint on associations :
 
 self.allConnections->forAll (r | self.namespace.allContents->includes
 (r.type) )
 
 seems incorrect to me :
 This basically restrict associations between classifiers in the same
 namespace. ==> you can not create an association between classes of
 different packages ?

Resolution: Considered and declined.
Revised Text: OCL changed to say the associations must be visible from the defining package, but they may be defined in other packages.
Actions taken:
December 23, 1997: received issue
July 6, 1999: closed issue

Discussion:

Issue 818: page 60 - CallConcurrencyKind (uml-rtf)

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

Summary: 1- The enumeration "�CallConcurrencyKind�" is not described.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 819: page 60 - EventOriginKind (uml-rtf)

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

Summary: 2 - The enumeration "�EventOriginKind�" is not described.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 820: Page 60 - PseudostateKind (uml-rtf)

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

Summary: 3 - The enumeration "�PseudostateKind�" is described, but the description refers (by error) to VisibilityKind (page 62)

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 821: Page 60 - visibilityKind (uml-rtf)

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

Summary: 4 - The enumaration "�visibilityKind�" has not any "�default�" visibility, such as in Java. We could think about adding such property to UML.

Resolution: Considered but declined.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 822: Page 60 - GraphicMarker (uml-rtf)

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

Summary: 5 - The "�GraphicMarker�" has a so vague definition, that no exchange can be provided between case tools. The same applies for every graphical features. This needs at least more explainations. May be, is it considered that the interpretations relies on each tool, or that more detail will come in the file exchange format??

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 823: Page 60 - MultiplicityRange (uml-rtf)

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

Summary: 6 - "�MultiplicityRange�"�: what is the rule for representing the "�*�" value by an integer�?

Resolution: UML 1.3: Multiplicity definition updated.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

The type of the upper bound in Multiplicity should be {Natural + Unlimited}, where Unlimited is a set with one value
denoting no limit. How to encode that is an implementation problem; various approaches suggest themselves. We
have overspecified Multiplicity by giving this much of an implementation.
Suggest we remove the MultiplicityRanges and just state what Multiplicity must contain abstractly and
mathematically.
Better proposals are needed. Consider interchange aspects here: semantically just a natural, but for interchange want
the symbol �*�. Also, do we need a set of ranges? Just having it as a constraint is difficult, because OCL
interpretation is not mandatory.
After discussion of the issue it became apparent that a fully general definition of multiplicity (e.g., which would allow
"all the even integers") would be impractical: difficult to specify and implement and not generally useful.
Proposal
Multiplicity remains defined as a set of integer ranges, with the definition of the interval to be fixed to allow an open
upper bound.

Issue 824: Page 35/37 - AssociationRole (uml-rtf)

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

Summary: Page 35 and 37
 
 7 - In the diagram, the AssociationRole class appears. Its name is "�AssociationEnd�".

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 825: Page 81: message has no parent class (uml-rtf)

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

Summary: Page 81: message has no parent class

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 826: Page 98: ActionSequence has no parent class (uml-rtf)

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

Summary: ActionSequence has no parent class.

Resolution: no action needed, close issue
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 827: Page 121 - Partition has no parent class (uml-rtf)

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

Summary: 10 - Page 121�: Partition has no parent class.
 It must be more clearly stated that classes having no Parent class inherit by defaut from the "Element" Class.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 828: Page 16- The association from parameter to classifier has a 1-1 cardinalit (uml-rtf)

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

Summary: 12 - Page 16�: The association from parameter to Classifier has a 1-1 cardinality. 0..1 is more appropriate, because an incomplete defined parameter (during analysis, for example) may not have a defined type.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 829: Page 39 - ModelElement/Dependency associations (uml-rtf)

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

Summary: 13 - Page 39�: The ModelElement/Dependency associations are inconsistent with the others diagrams (cardinalities, role names)

Resolution: Fixed in UML 1.3: Dependency relationships updated.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 830: Page 54 - ConstrainedStereotype (uml-rtf)

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

Summary: This association is a means to define constraints to particular stereotypes, generally defined by the User. If we want to be able to let the user define constraints for every model elements, the constraint should have a "�baseClass�" attribute, or a specific kind of stereotype should be defined, which name is "�default�" or "�base�", and which is the root of the stereotype inheritance tree In that case, defining a constraint for that stereotype means that a constraint for the associated metaclass is defined.

Resolution: considered and declined
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Association between Contraint and Stereotype (p. 53) is redundant and should be removed.

Issue 831: Page 40, table 2: Core - Standard Elements (uml-rtf)

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

Summary:  Class model element shows <<inherits>> stereotype
     but <<inherits>> is not shown in A.1 for Class.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 832: Page 40 table 2:Constraints Model (uml-rtf)

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

Summary: Constraints model element shows <<metaclass>> stereotype
     but <<metaclass>> is not show in A.1 for Constraints.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 833: page 40 table2: Classifier model element (uml-rtf)

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

Summary:  Classifier model element does not show <<metaclass>>,
     <<powertype>>, and <<thread>> stereotypes but these
     are shown in A.1 for Classifier.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 834: Page 40 table2: Generalization model element (uml-rtf)

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

Summary:  Generalization model element does not show <<inherits>>
     or <<extends>> stereotypes but these are shown in A.1
     for Generalization.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 836: Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele (uml-rtf)

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

Summary: On pg. 50, table 3: Auxiliary Elements - Standard Elements
 
     Component model element shows <<friend>> stereotype
     but <<friend>> is not shown in A.1 for Component.

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 837: Page 50 table 3: Dependency model element (uml-rtf)

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

Summary:  Dependency model element shows <<deletion>> stereotype
     but <<deletion>> is not shown in A.1 for Dependency.

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 838: Page 50 table 3: Dependency Model elements (02) (uml-rtf)

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

Summary: Dependency model element does not show <<friend>>
     stereotype but this is shown in A.1 for Dependency.

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 839: Page 50 table 3: Component model element (uml-rtf)

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

Summary: Component model element does not show location for tagged
     values but this is shown in A.2 for Component

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 840: Page 137 table 6: Model management - Standard Elements (uml-rtf)

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

Summary: On pg. 137, table 6: Model Management - Standard Elements
 
     Package model element does not show <<toplevelPackage>>
     stereotype but this is shown in A.1 for Package.

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 841: Page 9 figure 2: foundation packages (uml-rtf)

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

Summary: A dependency from Data Types to Core is not shown although this
     is implied by the existence of a generalization from elements in
     Data Types to the Data type element in Core.

Resolution: clarified in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

It needs to be clarified that data types defined are for the metamodel (M2) not the for the user (M1).
Are there two kinds of dependencies? Action on this one is to clarify. Two kinds of data types mixed in DataType
package: mixes M2 and M1 concepts (e.g. multiplicity, scopekind only for metamodel). For the latter, add
dependency relationship.

Issue 842: Page 60 figure 10: Data types (uml-rtf)

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

Summary: On pg. 60, figure 10: Data Types
 
     A "Float" class is not shown although it is discussed in the description
     of Geometry on pg. 61. Is Float a data type?

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

According to the metamodel diagram the body of Geometry is uninterpreted, so Float is not required.

Issue 843: Page 61: CallConcurrencyKind and EventOriginKind not defined (uml-rtf)

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

Summary: On pg. 61, neither "CallConcurrencyKind" nor "EventOriginKind" is 
     defined, although both exist on the diagram on pg 60.

Resolution: Redundant (duplicates 818 & 819).
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 844: Page 61 "EnumerationLiteral"--editorial (uml-rtf)

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

Summary: On pg. 61, in EnumerationLiteral, the phrase "that but can be" should
     be "that can be".

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 845: Page 62 "PseudostateKind"--editorial (uml-rtf)

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

Summary: On pg. 62, in PseudostateKind, the word VisibilityKind should be replaced
     with PseudostateKind.

Resolution: Redundant (duplicates 820).
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 846: Page 62---editorial (uml-rtf)

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

Summary: On pg. 62, in String, the word "Sting" should be "String".

Resolution: fixed in UML 1.2
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 closed issue

Issue 847: Page 16 of UML Semantics, figure 5 (uml-rtf)

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

Summary: On pg. 16 of UML 1.1 Semantics, figure 5 shows a 
     <Classifier>type--feature<StructuralFeature> association 
     which conflicts with the <Classifier>owner--feature<Feature> 
     aggregation. Note the duplicate role names for feature. I 
     presume the first association is a
     duplicate.

Resolution: Fixed in UML 1.3. Removed rolename "feature" on Classifier--StructuralFeature and removed ordering.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Remove rolename "feature" on Classifier--StructuralFeature and remove ordering. This is just the use of a class as a
type, not something that the classifier needs to know about.
One is type of something, one is owner of Feature. Keep association, but remove role name and ordering, it is from
Feature to type, not the other way around.
Proposal
Fig 5: Remove rolename "feature" on Classifier--StructuralFeature and remove ordering.

Issue 848: Page 43 UML 1.1 Semantics, figure 7 --editorial (uml-rtf)

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

Summary: On pg. 43 of UML 1.1 Semantics, figure 7 shows a relationship 
     labeled subDependencies when pg. 45 shows it as subDependency.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 received issue

Issue 849: Page 43 of UML Semantics, figure 7 (uml-rtf)

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

Summary: On pg. 43 of UML 1.1 Semantics, figure 7 does not show that 
     Dependency is "(from Core)".

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 850: Page 44 UML 1.1 Semantics, figure 8 (uml-rtf)

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

Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not label the target 
     end of the aggregation from Node to Component as "component" even
     though pg. 46 does describe it as such.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 851: Page 46 of UML 1.1 Semantics, description of associations for ModelElement (uml-rtf)

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

Summary: On pg. 46 of UML 1.1 Semantics, the description of the associations 
     for ModelElement does not describe the "template" association.

Resolution: Fixed in UML 1.3: Added description of ModelElement::template association.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

SEM p46: Add description of ModelElement::template association.

Issue 852: Page 47 of UML 1.1 Semantics, description of Refinement (uml-rtf)

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

Summary: On pg. 47 of UML 1.1 Semantics, the description of Refinement shows 
     "mapping" as an association when it should be an attribute.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 853: Page 47 of UML 1.1 Semantics, description of ViewElement (uml-rtf)

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

Summary: On pg. 47 of of UML 1.1 Semantics, the description of ViewElement 
     does not describe the "model" association.

Resolution: Fixed in UML 1.3: Added PresentationElement:subject relationship.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

SEM p47: Add description of PresentationElement::model association.

Issue 854: Page 98 of UML 1.1 Semantics, figure 17 (01) (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 17 shows the role from 
     CompositeState to StateVertex as "substate" while pg. 99 
     shows it as "substates".

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 855: Page 98 of UML 1.1 Semantics, figure 17 (02) (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 17 CompositeState does 
     not show "isRegion: Boolean" attribute described on pg. 98.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 856: Page 98 of UML 1.1 Semantics, figure 17 (03) (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 17 ActionSequence and
      Action are not shown "(from CommonBehavior)".

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 received issue

Issue 857: Page 98 of UML 1.1 Semantics, figure 17 (04) (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 17 shows the role 
     internalTransition from State to Transition as being on the State end when
     pg. 101 shows it as being on the Transition end.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 858: Page 98 of UML 1.1 Semantics, figure 18 (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 18 does not label the 
     signal role from SignalEvent to Signal as described on pg. 101.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 received issue

Issue 859: Page 98 of UML 1.1 Semantics, figure 18 (02) (uml-rtf)

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

Summary: On pg. 98 of UML 1.1 Semantics, figure 18 does not label the 
     operation role from CallEvent to Operation as described on pg. 99.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

 received issue

Issue 860: Page 10 UML 1.1 Semantics, duplicate entries listed (uml-rtf)

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

Summary: On pg. 10 of UML 1.1 Semantics, the State class  lists duplicate
      entries for the deferredEvent association.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 861: Page 102 of UML 1.1, StateVertex class misses description (uml-rtf)

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

Summary: On pg. 102 of UML 1.1, the StateVertex class does not describe 
     the parent association from StateVertex to CompositeStates 
     shown in figure 17 on pg. 98.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 2, 1998: received issue
July 6, 1999: closed issue

Discussion:

Add description of StateVertex::parent.

Issue 862: UML 1.1 Semantics: Partition (pp.121 123) (uml-rtf)

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

Summary: Partitioning according to various criteria is not possible.

Resolution: considered and declined
Revised Text:
Actions taken:
January 5, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 864: UML 1.1 bug (uml-rtf)

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

Summary: I"ve just noticed a well-formedness rules for parameters which seems
 incorrect:
 "An interface cannot be used as the type of a parameter".
 It"s not clear how UML can be used to represent COM or Java if this 
 is the case.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 4, 1998: received issue
July 6, 1999: closed issue

Discussion:

Remove Parameter Rule 1.
Weaken AssociationEnd Rule 1 to permit interfaces in associations, but only with knowledge to them, not from them.

Issue 866: Package dependencies (01) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 
     A dependency from Foundation to Behavioral Elements is not shown 
     although this is implied by the diagram on pg.. 121.

Resolution: considered and declined
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 867: Package dependencies (02) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 A dependency from Model Management to Core is not shown although this
     is implied by the diagram on pg.. 129.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 868: Package dependencies (03) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 
     A dependency from Data Types to Core is not shown although this
     is implied by the diagram on pg.. 60.

Resolution: considered and declined
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 869: Package dependencies (05) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
  A dependency from Collaborations to Core is not shown although this
     is implied by the diagram on pg.. 81.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 871: Package dependencies (06) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 A dependency from Use Cases to Core is not shown although this
     is implied by the diagram on pg.. 90.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 872: Package dependencies (07) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 A dependency from State Machines to Core is not shown although this
     is implied by the diagram on pg.. 121.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 873: Package dependencies (08) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
 A dependency from Core to Data Types is not shown although this
     is implied by the diagram on pg.. 121.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 874: Package dependencies (09) (uml-rtf)

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

Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
  A dependency from Data Types to Core is not shown although this
     is implied by the diagram on pg.. 81.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 875: ElementOwnership subclass of ModelElement? (uml-rtf)

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

Summary: On pg. 16 of UML 1.1 Semantics, figure 5 does not indicate whether
     ElementOwnership is a subclass of any other class. By implication
     on pg. 25, it must be a subclass of ModelElement.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 876: ModelElement Associations (01) (uml-rtf)

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

Summary: On pg. 17 of UML 1.1 Semantics, figure 6 shows the "requirement" role from
     ModelElement to Dependency with multiplicity "*". The description on
     pg. 25 for ModelElement refers to "a" Dependency. This would imply
     a multiplicity of "1" rather than "*".

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 7, 1998: received issue
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Issue 879: ModelElement Associations (02) (uml-rtf)

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

Summary: On pg. 17 of UML 1.1 Semantics, figure 6 shows the "provision" role from
     ModelElement to Dependency with multiplicity "*". The description on
     pg. 25 for ModelElement refers to "a" Dependency. This would imply
     a multiplicity of "1" rather than "*".

Resolution: Fixed in UML 1.3: Renamed role and corrected description.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

 Fixed in UML 1.3: Renamed role and corrected description.

Issue 880: Missing role descriptions (uml-rtf)

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

Summary: On pg. 20 of UML 1.1 Semantics, BehavioralFeature describes a "parameters"
     association but figure 5 on pg. 16 shows the same association as "parameter".
 
 On pg. 21 of UML 1.1 Semantics, Classifier does not describe a "associationEnd"
     association but figure 6 on pg. 17 does show "associationEnd".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 6, 1999: closed issue

Discussion:

Change text to "parameter" on p20.
Remove "associationEnd" rolename from Classifier to AssociationEnd. It will not be navigated that way.

Issue 881: Page 44 UML 1.1 Semantics, figure 8: no component role name (uml-rtf)

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

Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not show the "component"
     role name from Node to Component although this is described on pg. 46.

Resolution: Redundant (duplicates 850).
Revised Text:
Actions taken:
January 7, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 882: Page 44 UML 1.1 Semantics, figure 8: no base class for ViewElement (uml-rtf)

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

Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not show the base class
     for ViewElement. Based upon the description on pg. 22, it is assumed
     to be Element.

Resolution: Fixed in UML 1.3: Presentation Element is a subclass of Element,
Revised Text:
Actions taken:
January 7, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 883: Page 53 UML semantics: base class of TaggedValue not shown (uml-rtf)

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

Summary: On pg. 53 of UML 1.1 Semantics, the base class of TaggedValue is not
     shown. It is assumed to be ModelElement, based upon the description
     on pg. 25 of ModelElement.

Resolution: Fixed in UML 1.3: TaggedValue a subclass of ModelElement.
Revised Text:
Actions taken:
January 7, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 922: Section 5.16.1--editorial (uml-rtf)

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

Summary: In the first line of Section 5.16.1 of of the Notation Guide (page 44), the
 stereotype "<<imports>>" should be "<<import>>" (no "s").

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 923: Second para, Section 5.16.1: conflict with statement on p 141 (uml-rtf)

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

Summary: The first sentence of the second paragraph of Section 5.16.1 of the
 Notation Guide (page 44) states "Note that an imports dependency does not
 modify the namespace of the client or in any other way automatically create
 references..." This seems to conflict with the statement on page 141 of the
 Semantics document that the "public contents of the target package [of an
 imports dependency] are added to the namespace of the source package".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Do we really need import? Is the name space flat or tree-based?
Choices:
a. It is a mechanism for adding names (essentially aliases) to a flat name space for use within expressions and
actions.
It means that the names in the target package enter the namespace of the source package without the need for
pathname qualification.
We need it to model the semantics of package importing in various target languages (e.g., Ada, C++, Java). This is
an important aspect of modeling the structure/architecture of large systems, and is essential for supporting large
excecutable models. Consequently we should keep and clarify the SEM specification.
b. It is a mechanism for managing and controlling visibility of packages within large models.
It means that the source package can see into the target package, provided the elements in the target package
have public visibility (both public visibility of the referenced element and import of the containing package are
needed).
An import does not actually establish any references and it does not alter the namespace; the references
must be made separately after the contents of the package have been made accessible.
No namespace changes are needed.
We can use direct references or pathnames.
Imports is a package-level control/permission mechanism that doesn't modify (in particular, add) to the namespace.
It is needed to manage large models.
c. Drop the whole concept as unnecessary.
Other issues related to import include: #62, #1664.
Proposal
There need to be two kinds of import dependencies:
1) an import that simply grants permission to access elements in another package; and
2) an import that brings all the names from the supplier namespace into the client namespace as flat (non pathname)
names.
Since bringing names requires permission to access, the second kind may be considered a specialization of the first.
Use the name "access" for the first, "import" for the second.

Issue 924: Figure 5 Semantics document (p. 16) (uml-rtf)

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

Summary: Figure 5 of the Semantics document (page 16) shows the type of the
 "specification" attribute of class "Operation" to be "uninterpretted". On
 pacge 26 it is said to be an "Expression". Change this to "uninterpretted"
 on page 26.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 925: Well-formedness rule [4] for Association (uml-rtf)

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

Summary: Well-formedness rule [4] for Association (Semantics, pp. 27-28) states that
 "The connected Classifiers of the AssociationEnds should be included in the
 Namespace of the Association." However, rule [2] for Class (p. 29) and rule
 [1] for Package (p. 131) indicates that these namespace elements may
 contain associations, but NOT association ends. The rules for Class and
 Pachakge should be changed to allow them to contain association ends.

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

AssociationEnds can only be owned by Associations, which in turn are owned by Namespaces. They are already
there by transitivity. However, the connected Classifiers must be in the outer Namespace as stated.
Should be covered by OCL (AllContents); needs checking.

Issue 926: Well-formedness rulw [2] for Class (Semantics, p. 27-28) (uml-rtf)

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

Summary: Well-formedness rule [2] for Class (Semantics, p. 29) and rule [1] for
 Package (p.131) do not allow Signals (which, according to Figure 12 on page
 66 are generalizable elements but NOT classifiers) to be contained in
 classes or packages. The rules for Class and Package should be updated to
 allow this.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Change Package Rule 1 to allow Signal also.

Issue 927: well-formedness rules for BehavioralFeature (uml-rtf)

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

Summary: Should the well-formedness rules for BehavioralFeature (Semantics, p. 28)
 include a rule restricting a beahvioral feature to contain only one
 parameter of kind "return"?

Resolution: Considered and declined.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 928: ActivityState in Figure 22 (uml-rtf)

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

Summary: Figure 22 of the Semantics document (p. 121) incorrectly shows
 ActivityState as a subclass of SimpleState. It should be a subclass of
 SubmachineState, as stated on page 122.

Resolution: UML 1.3: Renamed ActivityState to SubactivityState and updated relevant semantics.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Rename ActivityState to SubactivityState and update relevant semantics.

Issue 929: No notation defined in the Notation Guide (uml-rtf)

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

Summary: There is no notation defined in the Notation Guide mapping to the
 ActivityState metaclass defined on page 122 of the Semantics document.

Resolution: UML 1.3: Notation defined for SubactivityState.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Use the round-end box for SubactivityState. Action state can use it by just having an entry action.

Issue 930: diagram fragment at start of Model section on page 136 (uml-rtf)

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

Summary: The diagram fragement at the start of the Model section on page 136 of the
 Semantics document incorrectly shows the Model metaclass as having a
 composition association with the Package metaclass. Instead, the Model
 metaclass should be a subclass of Package, as shown in Figure 23 (p. 129).

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 931: Figure 8 (Semantics, p. 44) (uml-rtf)

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

Summary: The Semantics document states that "a Component is a subclass of Class" (p.
 45) and "a Node is a subclass of Class" (p. 46). However, Figure 8
 (Semantics, p.44) shows both Component and Node as subclasses of
 Classifier. Further, the Notation Guide states that "A component symbol
 maps into a <<component>> stereotype of a Class or Object" and similarly
 for a node symbol. My understanding is that the text of the Semantics
 document is correct, and the diagram and Notation Guide should be changed
 to conform to this.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
January 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 936: Predefined LinkEnd constraints shown as stereotypes in Notation Guide (uml-rtf)

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

Summary: Summary: Predefined LinkEnd constraints used in Collaboration diagrams and defined in Semantics A.3 (association, global, local, parameter, self) are shown as stereotypes in Notation Guide (e.g., 8.2.3 diagram) and sometimes as constraints (e.g., 8.7.3 diagram).

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
February 3, 1998: received issue
July 7, 1999: closed issue

Discussion:

Add to list of standard stereotypes: association, global, local, parameter, self. They apply to AssociationEnd within
collaborations. Remove them from list of standard contraints on SEM p145. Modify NOT to use stereotype notation
in the diagrams.

Issue 937: Predefined LinkEnd constraints issue (uml-rtf)

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

Summary: Summary: Predefined LinkEnd constraints (or properties --  it is unclear) used in Collaboration diagrams and indicated in Notation Guide 8.10 (new, transient, destroyed) are shown as stereotypes in Notation 8.4.2 page 92. In addition, they are not indicated at all in the Semantics document. These constraints/properties also apply to the Object names in Collaboration.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
February 3, 1998: received issue
July 7, 1999: closed issue

Discussion:

Add new, transient, destroyed as standard constraints on p145. Rephrase Notation to call them constraints and not
stereotypes.

Issue 938: Parameters/Attributes need Specification Classifiers (uml-rtf)

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

Summary: AssociationEnds have onr type, but may have many specifiers. These specifiers limit the setof operations that may be used on the actual classifiers at that end. In several senses, attributes are parallel to AssociationEnds. Often they are freely diagrammed interchangeably. It appears that if an associationEnd is diagrammed as an attribute, the specifiers would be lost. This breaks the symmetry between associationEnds and attributes

Resolution: considered and declined
Revised Text:
Actions taken:
February 4, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 950: Inconsistency of UML metamodel (uml-rtf)

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

Summary: Semantics Specification v1.1
 On page 37 two diagrams lack multiplicity on composite associations.
 On page 35 the diagram does not make clear which multiplicity is for
 Association - Class
 On page 35 all composite associations lack multiplicity

Resolution: considered and declined
Revised Text:
Actions taken:
February 8, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 951: UML potential inconsistency about stereotypes (uml-rtf)

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

Summary: [Stereotype]stereotype*---*extendedElement[ModelElement]
 
 so: many-to-many.
 
 The text, in �ModelElement(as extended)/Associations/stereotype (p54 in my
 copy) says "Designates _at most one_ stereotype..."
 
 so: one-to-many.
 
 Unless I misunderstood something, this is not consistent. Otherwise, a
 better explanation is needed.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
February 20, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 952: UML stereotypes (uml-rtf)

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

Summary: UML Semantics:
 I think that the attribute Stereotype::baseClass could (should, IMhO) be
 replaced by a second association between Stereotype and ModelElement, with
 {targetScope=Classifier} on the ModelElement end (presentation: role name
 underlined).
 This would represent better the two links side by side: the "meta" link and
 its instances.

Resolution: Considered and declined.
Revised Text:
Actions taken:
February 20, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 953: UML Notation Guide, association ends (uml-rtf)

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

Summary: UML Notation Guide
 
 I did not find in �5.21 any notation to represent
 AssociationEnd::targetScope. To be consistent with the notation of
 attributes and operations or methods, I suggest that the role name can be
 underlined to show that "targetScope=classifier".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 20, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 954: UML Notation Guide, boolean properties (uml-rtf)

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

Summary: �5.5.1 says that you can show properties betwen braces and that a boolean
 property can be displayed without its value (meaning true).
 
 1) examples are {leaf} and {abstract}, which are isLeaf and isAbstract in
 the metamodel. Since all boolean properties are called isXxxx, I suggest to
 add an explicit rule in �5.5.1 stating that a property isXxxx=true is
 displayed simply as {xxxx}
 
 2) I suggest to add a shortcut for false properties as well. May be
 {�xxxx}, or {\xxxx}... some character not too overloaded by UML and
 programming languages anyway (# ~ ! - ...)

Resolution: considered and declined
Revised Text:
Actions taken:
February 20, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 955: Association between Method and Operation (uml-rtf)

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

Summary: Figure 5 (Core Package-backbone) of the UML Semantics suggests that _1
 (one)_ Operation is the specification of * (none-to-many) Methods.
 
 P25, the text on Method says that "a Method is a declaration of a named
 piece of behavior in a Classifier and realizes one _or a set of_ Operations
 of the Classifier". This suggests (or is it just unclear?) that several
 Operations may be linked (implemented?) by the same method.
 
 I do not understand this, or what I understand is not consistent.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
February 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

The method realizes the most specific operation. Any inherited operations must have the same signature. The method
can be overridden by another method in a child, and both methods realize the same operation.

Issue 973: Inconsistency of UML metamodel (uml-rtf)

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

Summary: The mentioned "inconsistency" was found on page 35 and 37 of the
 Semantics Specification v1.1
 On page 37 two diagrams lack multiplicity on composite associations.
 On page 35 the diagram does not make clear which multiplicity is for
 Association - Class
 On page 35 all composite associations lack multiplicity

Resolution: Redundant (duplicates 950; mistaken submitter id).
Revised Text:
Actions taken:
February 8, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 974: Node class issue (01) (uml-rtf)

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

Summary: 1) The Node class (in the Auxiliary Elements package) has an
 > aggregation to the Component class.  The description of the Node in
 > the text talks about as the "component" association.  However, the
 > "component" name does not occur on the Component end of the
 > aggregation in the diagram.(Figure 8).

Resolution: Redundant (duplicates 850).
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

 Redundant (duplicates 850).

Issue 975: Node class shown as subclass of classifier (uml-rtf)

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

Summary: 2) The description of the Node class says: "In the metamodel a Node is
 > a subclass of Class..."  However, in Figure 8, it is shown as a
 > subclass of a Classifier.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 976: Description of component shown as subclass of class (uml-rtf)

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

Summary: 3) Like the Node, the description of the Component in the Auxiliary
 > Package indicates that it is a subclass of Class.  Figure 8 shows it
 > as a subclass of the Classifier.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Component is a subclass of Classfier.

Issue 977: Comment class shown as subclass of ModelElement class (uml-rtf)

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

Summary: 4) The Comment class (again in the Auxiliary Package) description
 > indicates that it is a subclass of the ViewElement.  The diagram
 > (Figure 8 again) shows it as a subclass of the ModelElement class.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Comment is a subclass of ModelElement.

Issue 978: Description of ViewElement indicates that it is subclass of Element (uml-rtf)

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

Summary: 5)   The description of ViewElement indicates that it is a subclass of
 > Element.  Figure 8 does not show it as a subclass of anything.  This
 > would be OK if the derivation of ViewElement were shown someplace
 > else, but I can find it in no other place.  Furthermore, it is shown
 > as an abstract class, but I can find no classes which are derived from
 > it.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Should be a subclass of Element.
Now moot as the sentiment was for removing view element from the metamodel.
Proposal
PresentationElement is a subclass of Element.

Issue 979: Action class is no abstract class as indicated (uml-rtf)

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

Summary: 6) The Action class is indicated as being an abstract class in the
 > description of the Behavioral common elements package, but it is not
 > indicated as abstract in the diagram (Figure 13).

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 980: Request class is not an abstract class as indicated (uml-rtf)

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

Summary: 6) The Request class is indicated as being an abstract class in the
 > description of the Behavioral common elements package, but it is not
 > indicated as abstract in the diagram (Figure 13).

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 981: Behavioral Features called context (uml-rtf)

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

Summary: 8) The Common Behavioral Element Package defines the Exception and
 > indicates that it has an association called "behavioralFeature" which
 > is "The set of BehavioralFeatures that raise the exception".  Figure
 > 12 calls this association the "context".

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 982: Figure 12 shows no attributes for exceptions (uml-rtf)

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

Summary: 9) The description of the Exception indicates that it has an attribute
 > called "body", which is "A description of the Exception in a format
 > not defined by UML".  However, Figure 12 shows no attributes for
 > Exceptions.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 983: Reception class has wrong attribute (uml-rtf)

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

Summary: 10) THe Reception Class (also in the Common Behavioral package)
 > description indicates that the type of the "specification" attribute
 > is an Expression.  Figure 12 indicates that this attribute is of the
 > Uninterpreted type.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 984: ActionSequence class issue (uml-rtf)

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

Summary: 11) The ActionSequence class (Common Behavioral ELements Package)
 > would seem to be an ordered relation, but the figure which illustrates
 > it (Fig 13) does not indicate this.  Neither does the description,
 > even though it explicitly says that the "action" association is "A
 > sequence of Actions performed sequentially as an atomic unit".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Add {ordered} to ActionSequence-Action association.

Issue 985: Description of ActionSequence indicates that it is composition of Actions (uml-rtf)

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

Summary: 12) The description of ActionSequence is "In the metamodel an
 > ActionSequence is an aggregation of Actions".  The diagram indicates
 > that it is a composition of Actions.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

text should be updated

Issue 986: Collaborations package--editorial (uml-rtf)

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

Summary: 3) In the Collaborations package, Figure 15, there is a "{or}"
 > particle floating near the Collaboration class.  It is unclear what it
 > means or to what it applies.

Resolution: Fixed in 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 987: Collaboration package: constrainingElement aggregation misdrawn (uml-rtf)

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

Summary:  14) Also in the Collaboration package, the "constrainingElement"
 > aggregation is misdrawn in Figure 15.  It shows up normally in the
 > Rose MDL file from Rational.

Resolution: Fixed in 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 988: Figure 15, AssociationRole class issue (uml-rtf)

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

Summary: 15) In FIgure 15, the AssociationRole class has the "multiplicity"
 > attribute; the type is not given there nor in the text description of
 > this class.  Presumably, it is the Multiplicity type, since that is
 > the type of the corresponding attribute in the ClassifierRole class.

Resolution: Fixed in 1.2.
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 989: Signal label in figure 18 is not present (uml-rtf)

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

Summary: 16 ) The SIgnalEvent descriptive text in the State Machines package
 > indicates the presence of the "signal" association with the Signal
 > class.  An association between these two classes is shown in Fig 18,
 > but the "signal" label is not present.
 >

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
February 27, 1998: recived issue
July 7, 1999: closed issue

Discussion:

Fig 18: Add rolename "signal" to association SignalEvent::Signal

Issue 990: CallEvent: operation label in figure 18 is not present (uml-rtf)

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

Summary: 17 ) The CallEvent descriptive text in the State Machines package
 > indicates the presence of the "operation" association with the
 > Operation class.  An association between these two classes is shown in
 > Fig 18, but the "operation" label is not present.
 >

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
February 27, 1998: received issue
July 7, 1999: closed issue

Discussion:

Fig 18: Add rolename "operation" to association CallEvent-Operation

Issue 1000: UML 1.0: Collaborations not well defined (uml-rtf)

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

Summary: Collaborations, especially Collaboration Digarams, are not defined very well,
 given the following quotes:
 
 The SG states on p. 86:
 "A collaboration may be presented at two different levels: specification
 level or instance level. A diagram presenting the collaboration at the
 specification level will show classifier roles and association roles, while
 a diagram at the instance level will present instances and links conforming
 to the roles in the collaboration."
 
 So, according to the SG, there are TWO kinds of collaboration diagrams: one
 containing ClassifierRoles and one containing Instances.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Re notation for collaborations: Add notation to distinguish between specification-level and instance-level
collaborations. As with classes/objects, use non-underlining/underlining to distinguish.
Underline actual objects, do not underline roles. Show 3 part context diagram.
When role is used as a classifier, put it in angle brackets.
So:
rolename: classname,<subrolenome>
instancename: classname,<rolename> ALL UNDERLINED

Issue 1001: UML 1.o: Qualified things in Collaborations (uml-rtf)

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

Summary: The diagram on p. 90 of the NG contains some items that cannot be represented
 in the model:
    The lines from "wire" to "left" and "right" look like an instance of
    a qualified association. There is no such thing in the SG.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Add structure to collaboration that parallels association qualifiers. Probably QualifierRole with an expression for the
value.

Issue 1002: UML 1.0: Collaborations and Association (role) (uml-rtf)

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

Summary: On p. 97 the NG defines how to map nested "things" in a collaboration diagram:
 "A nested object symbol (active or not) maps into a Classifierrole that has
  a composition association to the roles corresponding to its contents, as
  described under Composition."
 
 But, according to the SG on p. 81, fig. 15, a collaboration should contain
 AssociationRoles, not plain Associations.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Rephrase to make it clear that it maps to an AssociationRole whose base is a composition association.

Issue 1003: UML 1.0: No notation for ClassifierRole.availableFeature (uml-rtf)

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

Summary: There is no notation for the meta-association 
 ClassifierRole.availableFeature (on p. 94 of the SG).

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1004: UML 1.0: Attachment of messages in Collaboration Diagrams (uml-rtf)

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

Summary: p. 98 of the NG:
 
 "A message flow is shown as a labeled arrow placed near a link. The
 meaning is that the link is used to transport or otherwise implement the
 delivery of the message to the target object."
 
 However, attachment of a message to an AssociationRole is not possible in
 the model.

Resolution: Redundant with 1019.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1005: UML 1.0: No notation for ModelElement.implementation etc. (uml-rtf)

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

Summary: There is no notation for the associations ModelElement.implementation
 and Component.deployment, both defined in Figure 8 on p. 44 of the SG.

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1006: UML 1.0: Node/Component Instances not defined (uml-rtf)

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

Summary: In the NG, the Deployment Diagram is defined to contain Node and Component
 INSTANCES. But these model elements do not exist according to the SG.

Resolution: Merged with #1006.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1007: UML 1.0: Inconsistent mapping of interface circles (uml-rtf)

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

Summary: The NG is inconsistent in the way "interface circles" are mapped.
 On p. 138 it says "Interface circles attached to the component symbol by
 solid lines map into supports Dependencies to Interfaces."

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Change it to map into Realize relationship.

Issue 1008: UML 1.0: Tagged value "location" (uml-rtf)

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

Summary: On p. 144 of the SG, the predefined tagged value "location" is specified:
 Applied to Classifier: "Location denotes that the classifier is a part of
 the given component." This seems to be the same as the association
 ModelElement.implementation, although the definition of that association
 is missing (it is in fig. 8, but not in the list of associations of
 ModelElement on p. 46).
 
 Applied to Component: "Location denotes that the component resides on given
 node." This is almost the same as the definition of the association
 Component.deployment on p. 45: "The set of Nodes the Component is residing on."
 
 Information should either be represented as an association in the metamodel
 or as a predefined tagged value, but not both.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Make "location" a reserved word and not a stereotype.

Issue 1009: UML 1.0: Inconsistent arrow heads for dependencies (uml-rtf)

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

Summary: p. 21 NG fig. 6 The <<calls>> dependency should use stick arrow i.s.o. a
 filled solid arrow head. The remainder of the NG uses stick arrow heads
 for Dependencies.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1010: UML 1.0: instances (uml-rtf)

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

Summary: The NG and the SG are inconsistent on where Instances my be defined:
 
 On p. 22 the NG states:
 
 "Note that a "class" diagram may also contain interfaces, packages,
  relationships, and even instances, such as objects and links."
 
 and: 
 
 "If a diagram is part of a package, then its contents map into elements
  in the same package."

Resolution:
Revised Text: Packages can now contain instances. A general clean up has been done for all classifiers that are instantiable to make the metamodel more homogeneous.
Actions taken:
March 13, 1998: re eived issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

Clarification of issue from Fred Mol:
The inconsistency became clear when I asked myself one question: where can Instances be defined in, or to rephrase
that: what is the owner of an Instance.
My first idea was a Package, but that's not possible because of well formedness rule [1] of Package, on page 131 of
the semantics guide
that states: "A Package may only own or reference Packages, Subsystems, Classifiers, Associations, Generalizations,
Dependencies, Constraints, Collaborations, Messages, and Stereotypes."
Instances are not in this list, so Instances may not be defined in a Package.
Looking in the notation guide, however, there are two sentences that lead to the conclusion that Instances are defined
in a Package, thereby
contradicting the well formedness rule [1] of Package: 1) On p. 22 the NG states: "Note that a "class" diagram may
also contain interfaces, packages, relationships, and even instances, such as objects and links."; and 2) "If a diagram
is part of a package, then its contents map into elements in the same package."
So, the inconsistency is that according to the semantics guide Instances may not be defined in a Packages, while,
according to the notation guide, they are. Add Instance to the list of elements that may be owned by a Package.
Also state machines go in packages, probably other things.
WG
Need to walk through the entire metamodel and decide which elements can be contained
in which other elements.

Issue 1011: Inconsistent name space rules (uml-rtf)

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

Summary: The NG and SG have slightly different name space rules for Packages:
 
 On p. 23 the NG states:
 
 "The name of a class has scope within the package in which it is declared and
  the name must be unique (among class names) within its package."
 
 The "among class names" implies that the name need NOT be unique among other
 names in the Package. This contradicts rule[2] of Package on p. 131 of the
 SG:
 
 "No referenced element (excluding Association) may have the same name or
 alias as any element owned by the Package or one of its supertypes."

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: close dissue

Discussion:

Need to clarify how many namespaces there are. All classifiers are in one, associations in another. Are there any
others?
Also need Signal as namespace (Signal is not a classifier). What about UseCase, ActivityState? Multiple namespaces
required.
Sentiment to keep everything of one kind in its own namespace, not to mix classifiers together.
Proposal
Separate namespace for Classes, Components, Use Cases, Nodes, Signals, basically every kind of Classifier, as well
as Association.

Issue 1012: Inconsistent name for stereotype implementationClass (uml-rtf)

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

Summary: p. 35 NG Stereotype <<implementation class>> contradicts p. 142 SG where
 the same stereotype is written as <<implementationClass>>.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Rename as <<implementationClass>>

Issue 1013: UML 1.0: Stereotype "uses" applied to more than one class (uml-rtf)

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

Summary: On p. 38, 71 NG <<uses>> is a stereotype of Dependency. On p. 144 SG <<uses>>
 is a stereotype of Generalization. A stereotype can be applied to only one
 ModelElement, according to its definition on p. 55, SG.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Make it a stereotype of Dependency throughout.

Issue 1014: UML 1.0: multiplicity "unspecified" not possible (uml-rtf)

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

Summary: p. 53 NG "In an incomplete model the multiplicity may be unspecified in the
 model itself". This contradicts the definition of Multiplicity in the SG p. 60,
 where Multiplicity is defines as ONE or more ranges. "Unspecified" cannot be
 represented.

Resolution: Considered but declined.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1015: UML 1.0: Inconsistent name of stereotype "import" (uml-rtf)

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

Summary: p. 44 NG Defines the <<imports>> Dependency. On p. 45 NG and p. 142 SG it
 is named <<import>> (without the trailing "s").

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

NOT p44: rename as <<import>>

Issue 1016: UML 1.0: Template example cannot be representaed in model (uml-rtf)

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

Summary: p. 40 NG The example in fig. 14 can not be represented in the model. The
 template parameter "k:Integer" refers to the multiplicity "k" of the
 composition association to "T". To be more precise: it refers to the
 attribute "multiplicity" of AssociationEnd. But this contradicts fig. 7 on
 p. 43 of the SG. A template parameter is there defined to be a reference to
 a ModelElement. Referring to an attribute of a ModelElement is not possible.

Resolution:
Revised Text: To address the issue of proper binding of Template parameters, a new metaclass TemplateArgument has been added, with relationships to ModelElement and Binding.
Actions taken:
March 13, 1998: received issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

True. The appearance of "k" in the multiplicity is purely linguistic. It is not a model element. Templates in languages
are fundamentally textual with substitution. In this usage we punted on expanding Multiplicity into its primitive
elements. The same thing would happen anywhere an expression appears.
The attempt to base Template on ModelElements seems doomed. Also there is no means in the Semantics for a
template to enclose a context. We may need some more generic type mechanism.
The body of the template needs to be separated from the rest of the model since it is in effect a parameterized form
that must be bound before it becomes a model element. (Compare the parameters and body of a lambda expression.)
Although
the issue has been known for several years it has never been properly handled.
Proposal
The requirement that a template parameter be a ModelElement is too strict, but a proper resolution may require
first-class extensibility features proposed for UML 2.0, in which a more uniform approach may be taken that reduces
the distance between model elements and their attributes. In the meantime, implementations will have to fudge the
implementation of templates, as they would probably do anyway.
Resolution
Deferred to UML 1.4/2.0.

Issue 1017: UML 1.0: "role" should be "end" (uml-rtf)

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

Summary: p. 50 NG "The end of an association where it connects to a class is called
 an association role". The word "role" must be "end".
 
 UML

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1018: UML 1.0: Unknown model element "Qualifier" (uml-rtf)

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

Summary: p. 59 NG "The presence of a qualifier box on an end of an association path
 maps into a Qualifier on the corresponding Association Role." There is no
 model element named "Qualifier" in the SG.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

NOT correction:
"The presence of a qualifier box on an end of an association path maps into a Qualifier on the corresponding
Association Role."
-->
"The presence of a qualifier box on an end of an association path maps into a Qualifier on the corresponding
Association End."
Clarification re "There is no model element named "Qualifier" in the SG.":
"qualifier" is defined as an association of AssociationEnd in SEM p. 19.

Issue 1019: Attachment of message in Sequence Diagram (uml-rtf)

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

Summary: p. 83 NG "unless the correct AssociationRole can be determined from a
 complementary collaboration diagram or other means, the Message must be
 attached to a dummy AssociationRole implied between the two ClassifierRoles
 for lack of complete information."
 
 This conflicts with fig. 15 on p. 81 of the SG: a Message is NOT connected to
 an AssocationRole.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

The semantics of Interaction apparently fail to attach messages to association roles, but that is where they are
supposed to go, otherwise the information about which link is used to send the message is lost. This looks like a
large mistake in the model for Interaction.
Needs discussion: is collaboration a view on underlying model or does it define new associations? Is this related to
the completeness issue? Can AssociationRole exist without pointing to an Association? Is this a tool issue?
Also need to improve the mapping in NOT p90 to mention mapping from message flows on links.
Re association roles:
The presence of an association role without an underlying association is the implicit declaration of an underlying
association that is used only in the collaboration.
Proposal
Associate Message directly with AssociationRole. Multiplicity is AssociationRole 0..1 - * Message. Keep the
associations to ClassifierRole but add constraints that they must match the ClassifierRoles at the end of the
AssociationRole. The mapping in the notation from Message can be updated to map into the AssociationRole; if it is
missing then it is just ignored and the ClassifierRole mapping used.

Issue 1020: Inconsistent mapping of labels in Sequence Diagram (uml-rtf)

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

Summary: p. 83 NG "A timing label placed on the level of an arrow endpoint maps into
 the name of the corresponding Message."
 
 This contradicts the statement on p. 85 of the NG:
 
 "The arrow is labeled with the name of the message (operation or signal) and
 its argument values."

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Confusion between the name of the Message as a model element and the name of the Operation or Signal that it
invokes through its action. The timing label maps into tho name of the Message element, the signature to the action.
Proposal
NOT p83: Add language to say that the operation or signal signature maps into an Action attached to the Message.

Issue 1021: More arrow types than message kinds (uml-rtf)

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

Summary: p. 98 NG On this page, THREE kinds of arrows are defined for messages.
 However, the SG on p. 69 defines only TWO values of the attribute "mode"
 of CallAction: synchronous and asynchronous.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

The distinction is not between kinds of calls but between calls and signals. The stick arrowhead is for asynchronous
messages within a basically procedural sequence. 2 map to synchronous and 1 maps to asynchronous.
Proposal
Make the description clearer.

Issue 1022: Inconsistent format of signal/event (uml-rtf)

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

Summary: p. 109 NG "A signal or call event can be defined using the following format:
 event-name "(" comma-separated-parameter-list ")"
 A parameter has the format: parameter-name ":" type-expression"
 
 This is inconsistent with fig 41, p. 104 and fig 43, p. 107 and
 section 9.5.3 which only show the name of the parameter, not
 its type.

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1023: Inconsistent definition of state machine attachment (uml-rtf)

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

Summary: p. 103 NG "A state machine is attached to a class or a method"
 
 This is more restrictive than the SG, p. 104:
 
 "A StateMachine is aggregated within either a classifier or a behavioral
 feature".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: close dissue

Discussion:

Loosen language in NOT to make consistent.

Issue 1024: Inconsistent attachment of Activity Diagram (uml-rtf)

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

Summary: p. 121 NG "The entire activity diagram is attached (through the model) to a
 class or to the implementation of an operation or a use case."
 
     - How can an activity diagram be attached to THE IMPLEMENTATION of
       an operation or use case?
     - This attachement is different from the one in the SG, p.124:
       "[1] An ActivityModel specifies the dynamics of (i) a
       Package, or (ii) a Classifier (including UseCase), or (iii) a
       BehavioralFeature."

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1025: Extension points of operations not defined (uml-rtf)

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

Summary: p. 36 SG "An operation may have a set of extension points".
 
 This is not defined in the model.

Resolution: UML 1.3 clarification: Extension points only apply to use cases.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1026: Feature.owner must be optional (uml-rtf)

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

Summary: p. 16 SG Feature.owner is a mandatory association to Classifier. Attribute,
 derived from Feature, can also be used as qualifier of an AssociationEnd.
 Such an attribute is not owned by a Classifier, but is owned by the
 association end. 
 
 Conclusion: Feature.owner should be optional.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Fig 5: Make Feature - owner Classifier have multiplicity 0..1.

Issue 1027: Method visibility (uml-rtf)

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

Summary: p. 36 SG "The concept of visibility is not relevant for methods".
 
 Then why is visibility an attribute of Method and is there even a rule on
 p. 32 of the SG that states:
 
 "[3] The visibility of the Method should be the same as for the realized
 Operations."

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Should say that the method can't change the visibility specified on its operation.

Issue 1028: Wrong aggregation kind for templates (uml-rtf)

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

Summary: p. 43 SG In fig. 7, Binding.argument is composite, while
 ModelElement.templateParameter is not. This seems to be an error, as is
 indicated by the text on p. 49:
 
 "A further consequence is that a template must own a fragment of the model".
 
 ModelElement.templateParameter should be composite, Binding.argument should
 not be composite.

Resolution: Considered and declined
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

A template parameter is a reference to an element within itself. The template must own the parameter, but not
through the templateParameter association but through the normal Namespace composition. The argument, however,
is an expression that is just part of the Binding construct.
Proposal
No action needed.

Issue 1029: Inconsistent definition of stereotype "thread" (uml-rtf)

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

Summary: p. 40 SG <<thread>> is defined to be a stereotype for Generalization.
 On p. 144 it is defined as a stereotype of Classifier.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Should be a stereotype of Classifier.

Issue 1030: Inconsistent definition of stereotype "friend" (uml-rtf)

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

Summary: p. 50 SG <<friend>> is defined to be a stereotype for Component. On p. 142
 it is defined as a stereotype of Dependency.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

"friend" is a stereotype of Permission dependency.

Issue 1031: ordered missing for Constraint.constrainedStereotype (uml-rtf)

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

Summary: On p. 54 SG the association Constraint.constraindStereotype is defined as:
 
 "An ordered list of stereotypes subject to the constraint".
 
 The "ordered" property is not in fig. 9.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1032: Enumeration OperationDirectionKind obsolete (uml-rtf)

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

Summary: p. 62 SG The enumeration OperationDirectionKind is defined, but this
 enumeration is not used anywhere. So either it can be left out or it should
 be used.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1033: Misleading name Link.linkRole (uml-rtf)

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

Summary: p. 67 SG Fig. 14. Link.linkRole is an inconsistent name for an association
 with class LinkEnd. It should be named "Link.linkEnd".

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Actually for an association it is called "connection" which is not so great.
Proposal
Change rolename from "linkRole" to "connection".

Issue 1034: English contradicts OCL in rule for CompositeState (uml-rtf)

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

Summary: p. 104 SG Well-Formedness rule CompositeState[4] states:
 
 "There have to be at least two composite substates in a concurrent composite
 state"
 
  (self.isConcurrent) implies 
 	 (self.subState->select (v | v.oclIsKindOf(CompositeState))->size <= 2) 
 
 Clearly "<=" should be ">=".

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1035: Stereotypes applied to more than one ModelElement (uml-rtf)

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

Summary: p. 140 SG Several stereotypes apply to more than 1 ModelElement: create,
 destroy, metaclass and powertype.
 
 This is inconsistent with p. 54, fig. 9: Stereotype has a "baseClass"
 attribute which contains the name of exactly 1 ModelElement.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

This can be interpreted as being two distinct stereotypes with the same keyword but applying to different elements.
The combination of base element + keyword is unique.
This is a consistency problem. Can we inherit by attaching to ModelElement? Flat name space for stereotypes?
Proposal
Allow more than one stereotype with the same name, provided they don't have an inheritance relationship or clash
with other names.

Issue 1036: Inconsistent definition of enumeration (uml-rtf)

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

Summary: p. 140 SG "enumeration" is listed as stereotype, but it"s defined as a
 distinct ModelElement on p. 60.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Change it to be a reserved word, not an actual stereotype.

Issue 1037: Inconsistent definition of stereotype " process" (uml-rtf)

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

Summary: p. 143 SG Stereotype <<process>> is listed to apply to Classifier, but the
 description says "is also an active class". So it should apply to Class.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Change text: can also be module, component that has process, thread. However, isActive is an attribute of Class, not
Classifier.
Proposal
Leave as Classifier, but remove statement that it is an active class.
Problem: do we need to move isActive attribute from Class to Classifier to make this work? If so, we should defer to
UML 1.4.

Issue 1038: Inconsistent definition of stereotype "thread" (uml-rtf)

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

Summary: p. 143 SG Stereotype <<thread>> is listed to apply to Classifier, but the
 description says "is also an active class". So it should apply to Class.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Leave as Classifier, but remove statement that it is an active class.

Issue 1039: Well-formedness rules missing (uml-rtf)

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

Summary: On p. 11 of the SG it is stated that "*  Well-Formedness Rules: The static
 semantics of EACH construct in UML, except for multiplicity and ordering
 constraints, are defined as a set of invariants of an instance of the
 metaclass."
 
 And
 
 "The statement "No extra well-formedness rules" means that all current static
 semantics are expressed in the superclasses together with the multiplicity
 and type information expressed in the diagrams."
 
 Yet, the following model elements don"t have well-formdness rules, but this is
 not explicitly specified. (see corresponding archive file).

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1040: Well-formedness rules only expressed in English (uml-rtf)

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

Summary: The following well-formdness rules in the SG are only expressed in English.
 Whether the OCL was intentionally left out or not, is unclear:
 
 	- p. 27, Association[3]
 	- p. 75, Instance[6]
 	- p. 104 Guard[1]
 	- p. 124 ActivityModel[2]
 	- p. 125 PseudoState[2]

Resolution:
Revised Text: OCL added to rules, or an explanation given why not in most cases.
Actions taken:
March 13, 1998: received issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

May require backup from OCL WG.
Proposal
All fixed except Pseudostate [2], which is impractical to state in OCL.
Resolution
Deferred to UML 1.4: all but one fixed in UML 1.3.

Issue 1041: Missing mapping for directed constraint (uml-rtf)

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

Summary: p. 17 NG "For two graphical symbols (such as two classes or two associations):
 The constraint is shown as a dashed arrow from one element to the other
 element labeled by the constraint string (in braces). The direction of the
 arrow is relevant information within the constraint."
 
 and on p. 18:
 
 "A constraint string attached to a dashed arrow maps into a constraint
  attached to the two elements corresponding to the symbols connected by the
  arrow."
 
 Since the direction of the arrow is relevant: how is this direction mapped?

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Map tail end (client) as first position and arrow end (supplier) as second position. The constrainedElements are
ordered.
Proposal
Make mapping order clear.

Issue 1042: Confusing text (uml-rtf)

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

Summary: p. 36 NG "A class symbol (...) maps into a Class with no stereotype. This
 symbol is normally used between a class and an interface (...)"
 
 There seems to be something missing, because the sentence starting with
 "this symbol" doesn"t make any sense in this context.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1043: Missing notation for templates (uml-rtf)

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

Summary: p. 39 NG (notation for template) "A small dashed rectangle is superimposed
 on the upper right-hand corner of the rectangle for the class (or to the
 symbol for another modeling element)."
 
 What about templates that have no symbol of their own, such as operations?

Resolution: considered and declined
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1044: Inconsistent constraint for discriminator (uml-rtf)

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

Summary: p. 68 NG "The discriminator must be unique among the attributes and
 	  association roles of the given super-class."
 
 This is not specified in the SG.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

SEM p48. Classifier [4]: Add discriminators to the list of pseudoattributes that are in the same namespace with
attributes and association rolenames.

Issue 1045: Interface specifier not mapped (uml-rtf)

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

Summary: p. 54 NG the "interface specifier" is defined but not mapped.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1046: Property "derived" not defined (uml-rtf)

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

Summary: p. 73 NG "The presence of a derived adornment (a leading "/" on the symbol
 name) on a symbol maps into the setting of the "derived" property of the
 corresponding Element."
 
 The "derived" property is not defined in the SG.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

SEM p16 Fig 5: Add "isDerived: Boolean" attribute to ModelElement and add constraint for implementation.
This was not done.
Instead it is modeled using the {derived} tag on ModelElement which has been added to the list of standard tags.

Issue 1047: No mapping for swimlanes in Sequence Diagram (uml-rtf)

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

Summary: p. 80 NG (Notation for Sequence Diagram) "Objects can be grouped into
 "swimlanes" on a diagram."
 
 These swimlanes are not mapped and there is nothing in the SG to map them to.

Resolution:
Revised Text: The text is removed as swimlanes appear in activity graphs and not in collaboration notation. Can be reconsidered for 2.0.
Actions taken:
March 13, 1998: received issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

Issue 1048: No mapping for send/receive time in Sequence Diagram (uml-rtf)

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

Summary: p. 87 NG "A message may have a sending time and a receiving time."
 
 This is not specified in the SG.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

The idea was to encode this in the name of the Message. However, maybe a more direct approach is desirable.
Proposal
SEM p67 Fig 14 and SEM p81 Fig 15: Add sendTime and receiveTime attributes to Message and MessageInstance.

Issue 1049: No mapping for "transition string" (uml-rtf)

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

Summary: p. 113 NG (Complex Transitions)
 
 The "transition string" is not mapped.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Clarify that the NOT mapping applies.

Issue 1050: No mapping for TimingMark in Sequence Diagram (uml-rtf)

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

Summary: p. 112 NG "A transition time label on a transition maps into a TimingMark
 	   attached to the Transition".
 
 TimingMark is not defined in the SG.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Drop the TimingMark from the metamodel. In NOT use the message name together with the timing expression.

Issue 1051: No notation for ActivityState (uml-rtf)

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

Summary: p. 121 NG (Notation Activity Diagrams)
 
 There is no notation for the model element "ActivityState".

Resolution: Redundant: already fixed in UML 1.3.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1052: Inconsistent definition of extends relationship (uml-rtf)

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

Summary: p. 95 SG 4th par. "extends relationship includes both a condition for the
 extension and a reference to an extension point". 
 
 This is not defined in the model.

Resolution: UML 1.3: Extend relationship updated.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1053: Deep History Vertex (uml-rtf)

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

Summary: p. 111 SG (deepHistory) "A composite state can have at most one history
 vertex."
 
 This should be "A composite state can have at most one DEEP history vertex."

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
March 13, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1057: deferredEvent mentioned twice in Abstract Syntax (uml-rtf)

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

Summary: Semantics p. 101: The State Assciation deferredEvent is listed
 twice with different explanations.

Resolution: Redundant (duplicates 860).
Revised Text:
Actions taken:
March 17, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1058: internalTransition (uml-rtf)

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

Summary: Notation Guide, p. 106, 9.2.4 Mapping says "Any other internal
 action maps into an internal Association" should be "... into an
 internalTransition ...". 
 The internalTransition is described in Semantics, p. 101.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 17, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1059: ActionState implicit deferring of events (uml-rtf)

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

Summary: y interpretation of ActionState is that no events received
 during its execution are deferred, hence they will be lost unless they
 are explicitly deferred. 
 
 This means that if I want to defer all signals (which IMHO is the
 default behavior for ActionState) I have to explicitly use the /defer
 notation, which may result in enormous overhead and large symbols!

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

ActionState is an atomic state with conceptual duration 0, therefore events can't arrive while it is active.
Proposal
Clarify that events are not processed during an action state. They are processed during an activity state.

Issue 1060: Editorial error in Semantics (uml-rtf)

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

Summary: Semantics p.25: The Method attribute body:
 "...proceduralExpression..." should be "procedureExpression"

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
March 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1061: Missing sentence (uml-rtf)

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

Summary: Notation Guide p. 35. Chapter 5.9.4 Mapping (fourth row): There
 needs to be a sentence about the Realizes relationship (the dashed
 generalization arrow) before "This symbol..." to have a correct
 reference of "This symbol".

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
March 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1062: Procedure undefined (uml-rtf)

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

Summary: In Semantics p. 62, ProcedureExpression mentions "Procedure"
 (both italics and bold). Is Procedure defined at all?
 Resolutio

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

Rephrase statement as "will result in a change to the values of its environment when evaluated".

Issue 1063: Missing word - editorial (uml-rtf)

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

Summary: n Semanticsp. 120 +8. Unfinished sentence. "...invoke actions
 and then wait for their."

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
March 18, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1097: Contents of section "Control Icons" is vague (uml-rtf)

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

Summary:   The section "Control Icons" in the chapter "Activity Diagrams"
 does not follow the layout of the rest of the chapter, and the contents
 of the section is (intentionally?) vague. The most important issues,
 however, are: figure 58 is incorrect, and the text describing the
 control icon stereotypes is inconsistent with the activity model
 semantics. The mapping section also contains some peculiarities: signal
 sending should not be a RaiseAction but a SendAction, and the dummy
 state introduced for the join Pseudostate makes no sense. This entire
 section should be corrected and strengthened, and control icons put into
 a context.

Resolution: Redundant with activity diagram rework.
Revised Text:
Actions taken:
March 25, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1098: UML 1.1 Semantics, section 8.2, page 66 (uml-rtf)

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

Summary: The Semantics (ch. 8.2, p66, Figure 12) says that Signal is a GeneralizableElement and has Parameter(s). Multiple inheritance or repeated inheritance are not forbidden.
 
 2/ The Notation Guide (ch. 9.5.2, p111) says that an event has the following form: event-name "(" parameter "," ... ")" This means that the order of parameters is meaningful and implies that parameters must match the formal parameters declared in signals.

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 25, 1998: received issue
July 7, 1999: closed issue

Discussion:

While it's not clear what specific issue is being raised, in general the inconsistencies between the Semantics and
Notation for state machines have been fixed in UML 1.3.

Issue 1099: Editorial issue: OCL spec 1.1, section 6.3, example 2, last row (uml-rtf)

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

Summary: OCL Specification 1.1, section 6.3, example 2, last row:
 
            reads:
               self.employee->forAll(Person p|p.forename = "Jack")
 
            should read:
               self.employee->forAll(p : Person|p.forename = "Jack")

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Correct as recommended in the Summary.

Issue 1100: Difference between methods, attributes and operations not clear (uml-rtf)

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

Summary:   Normally methods, attributes and operations can be easily told from each
    other:
 
    Person.attribute
    Person.method(arg1..argn) alt Person.method()
    Person->Operation(arg1..argn) alt Person->Operation
 
    There is however a situation where it is not possible to tell the
    difference:
 
    Imagine a shoe-shop with a class Shoe, and the attribute size.
 
    you would imagine that the following
 
       Shoe.allInstances->select(size > 10)
 
    would give you a set of all the shoes with size bigger than 10, but it
    could just as well be interpreted as the set of all shoes since an object is a set of size 1.

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

The example is not ambiguous. Collection operations always need their context explicitly. Therefore an implicit
context as above is by definition the object.

Issue 1101: Definition of select and reject operations for Set"s is erranious (uml-rtf)

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

Summary: It reads:
 
               set->select(expr : OclExpression ) : Set( expr.type )
               set->reject(expr : OclExpression ) : Set( expr.type )
 
            It should read:
 
               set->select(expr : OclExpression ) : Set( T )
               set->reject(expr : OclExpression ) : Set( T )

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Proposal
Correct as recommended in the Summary.

Issue 1102: OCL specification 1.1, section 7.2.2 (uml-rtf)

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

Summary: The definition of the select and reject operations
            for Set"s is erroneous.

Resolution: Redundant with issue 1102.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1103: OCL specification 1.1, p. 10, 5.4.3, example 3 (uml-rtf)

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

Summary: Since both expressions start in the same object and one
  person can"t have both a wife and a husband, the expression will
  never give the result true, only false or undefined
 
  Here one could instead use the syntax of example 1:
  self.wife->nonempty implies self.wife.sex = #female and
  self.husband->nonempty implies self.husband.sex = #male

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Correct as recommended in the Summary.

Issue 1104: OCL specification 1.1, p. 32 (uml-rtf)

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

Summary:       The EBNF-construction "+" is not explained.
  add to explanation: "+" means one or more time
 
  A number of brackets have been lost in the definitions for
  typeName, name and number:
  number := ["0"-"9"] ( ["0"-"9"] )*
 
  there is no way to specify a float literal (3.14)

Resolution:
Revised Text: The explanation of '+ in the EBNF has been added
Actions taken:
March 26, 1998: received issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

Everything except float literal is done in UML 1.3. The float literal is deferred to UML 1.4/2.0.

Issue 1105: OCL specification 1.1, p. 30, 7.2.4 (uml-rtf)

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

Summary:       Sequence->prepend
  Correct explanation:
  The sequence consisting of /object/ followed by all
  elements in /sequence/

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Correct as recommended in the Summary.

Issue 1107: OCL specification 1.1, p. 24, 7.1.7 (uml-rtf)

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

Summary: New or simpler/shorter post conditions:
  b or b2 -- post: not ((not b) and (not b2))
  b xor b2 -- post: not (b=b2) (replaces previous post)
  b implies b2 -- post: (not b) or b2 (replaces prevoius post)

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

 Considered and declined.

Issue 1108: OCL specification 1.1, p. 15, 5.14, second last paragraph (uml-rtf)

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

Summary: Spelling: takes -> taken
  Could be rewritten as:
  "When the pre-value of a property evaluates to an object..."

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Correct as recommended in the Summary.

Issue 1109: OCL specification 1.1, p. 14, 5.13, example (uml-rtf)

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

Summary:  Why mention "Car" as a subtype of Transport when it is not used
  in the example?
 
 Proposed Resolution   : remove the reference to Car in the sentence.
 Revised Text : change text as suggested above
 Actions taken:

Resolution: Considered and declined.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1110: OCL Specification 1.1, section 8 (uml-rtf)

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

Summary:  The syntax specification does not include the
       extended syntax for the Iterate operation.
 
         xxx->iterate(x;acc=0|acc=acc+x.assets)
                       ^^^^^^
 
 Proposed Resolution   : include this in the grammar for the syntax
 Revised Text :

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
March 26, 1998: received issue
July 7, 1999: closed issue

Discussion:

 include this in the grammar for the syntax

Issue 1165: UML Semantics 1.1, p26, Operation::isPolymorphic (uml-rtf)

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

Summary: UML Semantics 1.1, p26, Operation::isPolymorphic
 Nothing says that isPolymorphic=TRUE is the default. In the NG, p19, �4.2.2 says "to specify a value of false you omit the name completely".
 
 This implies that *all operations are _not_ polymorphic by default*, and that you must write {polymorphic} explicitly on all polymorphic operations.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 22, 1998: received issue
July 7, 1999: closed issue

Discussion:

Drop default rule in SEM and specify explicitly as in NOT. - done
Change name of the property to Operation::isLeaf. - done
Keyword is {leaf}. - done

Issue 1171: Signature conflicts not well defined (uml-rtf)

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

Summary:  Parameter::kind is taken into account for differentiating between the
 signatures of two BehavioralFeatures
 (BehavioralFeature::hasSameSignature,
 Semantics pg.29). This may cause signature conflict problems. 
  For example we have two operations:
    oper( in i:integer )
    oper( out i:integer ) 
  in a class, their signatures will not be signaled as conflicting,
 although 
 they should.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Change WFR so that Parameter::kind is not used for differentiating between the equivalence of two
BehavioralFeatures.

Issue 1172: Features and ownedElements (1) (uml-rtf)

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

The fact that the owned Features of a Classifier are not accessed by Classifier::ownedElement but rather by the
Classifier::feature should be stated explicitly by the Semantics document.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1174: "feature" defined twice (uml-rtf)

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

Summary:  The "feature" association of Classifier is defined twice, the first
 time
 towards Feature, and then towards StructuralFeature (fig. 5, Core
 Package-Backbone).

Resolution: Redundant with issue 847
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1176: Features and ownedElements (2) (uml-rtf)

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

Summary: The visibility of an "ownedElement" in Namespace is modeled as an
 attribute
 of the association class ElementOwnership, while the visibility of a
 Feature
 in a Classifier is modeled as an attribute in the target class Feature.
 Inconsistent use of the modeling concepts.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1177: Signature conflicts not well defined (02) (uml-rtf)

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

Summary:  Semantics, Feature::name page 23 asserts that the name of a feature
 must be
 unique within a Class(ifier). Contradiction with the Well-Formedness
 Rules
 on page 29.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Make both statements more precise, especially for operations.
Operation includes name, parameter types, not directionality, not return types

Issue 1178: Package importing not well supported (uml-rtf)

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

Summary:  On page 134 is stated that "When an element is referenced by a package
 it
 extends the namespace of that package". This assertion is not supported
 by
 the metamodel and the Well-Formedness Rules (see the fact that the
 association between ModelElement and Namespace has "1" multiplicity),
 and it
 conflicts with WFR StructuralFeature [1] pg 34 which does not allow any
 kind
 of importing.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Remove this statement. It is bogus. Referencing does not modify the namespace.
A reference is just a reference.
An import extends the namespace.
Modify consistently with new definitions of import and access.

Issue 1180: Return types for BehavioralFeatures (uml-rtf)

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

Summary:  No mapping for the return type used for operations in Notation pg. 32.
 The
 correct mapping is probably into a anonymous parameter of the operation
 in
 question, with the kind "return".
  There is also no notation for operations with multiple "return"
 parameters.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

There are parameters of 'return' type so this is no problem. The notation can include multiple return types but this
should
be more explicit:
foo (a: A): T, U
Proposal
Clarify in text., multiple return values are allowed, maps into Parameter with kind=return.

Issue 1181: Use of language-dependant type expressions (uml-rtf)

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

Summary:  An attribute or parameter has a type in Semantics, which is a
 Classifier
 (Semantics, Fig. 5 pg. 16). But Notation uses a "language-dependent"
 expression to specify a type (Notation pg. 30, see the explanations for
 "type-expression"). If the Semantics is right, we have no need for type
 expressions, since a Classifier always has a name.

Resolution: resolved in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Resolved by new proposal for data types. A data type is a kind of Classifier.

Issue 1182: Correspondence between operation and method (uml-rtf)

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

Summary:  Semantics Method [1-3] pg. 32 implies that a method can have more than
 one
 specification (self.specification is a collection type, since it is
 applied
 the operation "forAll").
  Everywhere else (including the abstract syntax on p. 16) it is shown
 that a
 method implements exactly one operation.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Text of Method[1-3] changed to avoid implying more than one operation.

Issue 1183: Correspondence between operation and method (02) (uml-rtf)

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

Summary:  Notation states that a Class(ifier) can have at most one implementation
 for a given Operation. Although this can be inferred from the Semantics
 document, it should be stated explicitly in the Semantics document.

Resolution:
Revised Text: Explicity statement has been inserted.
Actions taken:
April 23, 1998: received issue
May 24, 2001: closed issue

Discussion:

Fix this in the next UML release to state explicitly that an operation can have at most one method in a giver classifier.

Issue 1184: Set of inheritable features not defined (uml-rtf)

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

Summary:  In Semantics/Inheritance pg. 34 it is stated that "Each kind of
 generalizable element has a set of inheritable features", without saying
 which are those features for each kind of generalizable element. Note
 that
 they are different: for a Package, the ownedElements are inherited,
 while
 for a Classifier they are not. The set of inheritable features should be
 defined for each descendent from GeneralizableElement.

Resolution:
Revised Text: The set of inheritable features have now been defined explicitly for all generalizable elements.
Actions taken:
April 23, 1998: received issue
July 7, 1999: deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

Issue 1185: Exotic uses of generalization (uml-rtf)

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

Summary:  Semantics allows exotic usages of generalization, such as between two
 Associations, without saying what it means, and without giving a
 notation
 for it.

Resolution: Redundant with issue 1184.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1186: Signature conflicts across an inheritance hierarchy (uml-rtf)

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

Summary:  If in a multiple inheritance graph we have an operation defined in two
 different ancestors of a class, the model is ill formed, although such a
 situation is very likely to happen in real life.
  Proposal: adopt a more relaxed semantics such as that of C++ or Eiffel
 for
 such a situation.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1187: Qualifier badly modeled (uml-rtf)

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

Summary:  A qualifier should be modeled as a (in)  Parameter and not as an
 Attribute
 (see fig. 6 pg 17). An Attribute has an ownerScope, a visibility, a
 changeability and a targetScope that are not characteristics for a
 qualifier. A Parameter instead has exactly what is needed for modeling a
 qualifier.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1188: Node and Component parent (uml-rtf)

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

Summary:  Node and Component are subclasses of Class or Classifier? Inconsistency
 between the diagram and the text: Semantics pg. 44 - 46.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Clarified that they are both subclasses of Classifier.

Issue 1190: "implementation" association not defined (uml-rtf)

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

Summary:  The "implementation" association between Component and ModelElement
 (Semantics, pg. 44) is not explained.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Describe association.

Issue 1191: Request"s parents (uml-rtf)

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

Summary:  Request is a subclass of BehavioralFeature or ModelElement?
 Inconsistency
 between the diagram and the text: Semantics pg. 66/72. Also, it should
 be
 abstract (shown in italics).

Resolution: considered and declined
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Issue 1192: Signal::isAsynchronous and Signal::direction not defined (uml-rtf)

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

Summary: Well-Formedness Rule Signal [1] pg. 76 refers to "isAsynchronous" and
 "direction" that are not defined anywhere.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

Delete these attributes.

Issue 1193: Action::isAsynchronous and Action::script not defined (uml-rtf)

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

Summary:  Semantics Fig. 13 pg. 67 shows the attributes Action::isAsynchronous
 and
 Action::script, that are not defined(explained) in the text.

Resolution: Defined in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 7, 1999: closed issue

Discussion:

isAsynchronous appears unnecessary now.
Script should be of type actionExpression.
Proposal
Defined in UML 1.3.

Issue 1194: CallAction::isAsynchronous and CallAction::mode (uml-rtf)

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

Summary:  CallAction has both "isAsynchronous" and "mode:{sync, async}".
 Redundancy.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Delete both isAsynchronous and mode.

Issue 1195: CallAction::request (uml-rtf)

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

Summary:  Semantics/CallAction [1] pg. 74 should read "request" instead of
 "message"
 in the OCL rule.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1196: Well-formedness Rules for Action::actualArguments (uml-rtf)

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

Summary:  Since request and actualArguments are defined in Action, why the
 Well-Formedness Rules concerning these associations are defined only for
 CallAction and SendAction. At least LocalInvocation should have the same
 WFR.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

No longer an issue since LocalInvocation has been removed, and a WFR is included for the other kinds of relevant
actions.

Issue 1197: WFR for instance links (uml-rtf)

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

Summary:  Rule Instance[2] pg. 74 does not take into account the direction of
 association, and therefore is incorrect. The rule should have referred
 to
 LinkEnds and AssociationEnds, and not to Links and Associations.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1198: MessageInstance not used (uml-rtf)

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

Summary: MessageInstance is an Instance of a Message? In which notation is it
 used?

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Examine further the issue of instances in the metamodel.
Perhaps we should remove run-time instance elements from the model.
At least separate Fig. 14 from the rest of the metamodel.

Issue 1199: Argument::type not defined (uml-rtf)

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

Summary:  Argument::type used in Semantics/CallAction [1] pg. 74 is not defined.

Resolution: Defined in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1200: AssociationEnd-AssociationEndRole inconsistencies (uml-rtf)

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

Summary:  Can there be inconsistencies between an AssociationEndRole and its base
 AssociationEnd, such as: an AssociationEndRole having a different name,
 multiplicity, changeability status or ordering status compared to its
 base?
  If not, this should be a Well-Formedness Rule (even if an informal
 one).

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1201: Message::base undefined (uml-rtf)

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

Summary:  What is "base" used in Semantics/Message pg. 83.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Currently there is no connection between Message and a Signal in the metamodel.
Proposal
SEM Fig. 15, p. 81: Replace "Action" with "Request" to indirectly effect a semantic relationship between Message
and Signal. Then the WFR on p. 85 for Interaction will be correct.

Issue 1202: CompositeStates with non-composite subregions allowed (uml-rtf)

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

Summary:  A CompositeState with isConcurent=TRUE should have only CompositeStates
 as
 substates (at least this is the only example explained in the
 documents).
 This is a Well-Formedness Rule missing from Semantics.
  If this is not the case, then a semantics for the other cases (cases of
 CompositeStates with substates that are not sub-regions) should be
 explained.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1203: Entry/Exit actions execution order (uml-rtf)

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

Summary:  The order in which the entry/exit actions are executed when entering /
 exiting a substate of a composite state is not given. The semantics is
 probably that the entry actions are executed sequentially from outer to
 inner states, and the exit actions are executed viceversa, but it should
 be
 stated explicitly.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Comments
This may have been stated, but we need to make it clear.
Also the transition action occurs at the outermost point.

Issue 1204: Transition WFR badly written (uml-rtf)

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

Summary:  Rules Transition [6] and [7] pg. 105-106 should be rewritten. One of
 the
 problems with them is:
 
  In rule Transition [6] pg. 105-106, the fact that the originating
 regions
 of a group of transitions entering a fork pseudostate should be
 orthogonal
 is not caught. A configuration like:
   state A with subregions B and C, b1 substate of B and transitions t1
   and t2 both exiting b1 and entering the same join state
 satisfies the constraint, although it is clearly wrong.
 
  The same problem appears for rule [7] pg. 106, for fork pseudostates.

Resolution:
Revised Text: OCL has been fixed
Actions taken:
April 23, 1998: received issue
July 21, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed issue

Discussion:

Issue 1205: Bad example for LCA, main source, main target (uml-rtf)

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

Summary:  In example 2 pg. 114, according to the definition of LCA, main source,
 main
 target, LCA(t)=s, main source(t)=region 1 of s, main target(t)=region 2
 of
 s. Text says all of them are s.

Resolution:
Revised Text: The example was OK, but exposed a problem in the definition of LCA to address the case where the LCA is a concurrent state
Actions taken:
April 23, 1998: received issue
July 21, 1999: Deferred to UML 1.4/2.0
May 24, 2001: closed issue

Discussion:

Issue 1206: "invoked" not defined (uml-rtf)

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

Summary:  Semantics/ObjectFlowState[1,2] pg. 124 uses "invoked" which is not
 defined.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Define "invoked" for ObjectFlowState.
Resolution

Issue 1207: Package importing transitive (uml-rtf)

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

Summary:  Package importing is transitive (Semantics/Package pg. 135). But the
 definition of UML uses importing not in a transitive way. For example,
 there
 are defined the following import relationships: AuxiliaryElements --->
 Core,
 Core ---> DataTypes and AuxiliaryElements ---> DataTypes.
  The renamig (aliasing) rule also confilcts with the transitive import:
 a
 module can be imported through multiple paths, therefore the model
 elements
 from a module can be imported repeatedly, possibly under different
 names.

Resolution: considered and declined
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Importing should probably not be transitive.
Check for redundancy.
Ada, Java are not transitive.

Issue 1208: Dependency wrongly mapped (uml-rtf)

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

Summary:  Notation 5.10.4 pg. 38 says that <--- maps to a <<uses>> Dependency. In
 fact
 it should map to a Usage (subclass of Dependency) and not to a <<uses>>
 Dependency, which is a stereotype for relationships between use-cases.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1210: The meta-type of template parameters (uml-rtf)

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

Summary:   It is not specified what is the meta-type of the template parameters
 that
 are exemplified in Notation, Fig. 14 pg. 40. T is a Class? k:integer
 maps to
 a Parameter object? And what can be the (meta)types of the actual
 parameters
 that can replace the template parameters. Some Well-Formedness Rules
 would
 be welcome.

Resolution: Redundant with issue# 1016.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1211: WFR for bound elements missing (uml-rtf)

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

Summary:  Notation 5.12.3 pg. 41. "Note that a bound element is fully specified
 by
 its template, therefore its content may not be extended [...]". This is
 a
 semantic rule that is important enough to be stated in the Semantics
 document (and not in Notation) and it should be a WFR.
  In fact, the contents of a bound element (definable in terms of its
 template with some replacements) is not defined formally at all.

Resolution: Redundant with #1016.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1212: Namespace in case of containment (uml-rtf)

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

Summary:  Does the containment of a class symbol within another class symbol mean
 also that the namespace of the contained is the container? 
  If not, a notation for the namespace-containment relationship must be
 given.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Nested notation means composition of structure, akin to the containment of attributes within the class symbol,
Nested classifier can be defined in the model but no inline notation is provided.
Show a package icon to indicate nested definitions.
Double click to enter the namespace.

Issue 1213: <<local>>, <<parameter>>, <<global>>, <<self>>, not well supported (uml-rtf)

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

Summary:  Notation 5.27.2 pg. 65 says that <<local>>, <<parameter>>, <<global>>,
 <<self>> are LinkEnd stereotypes, when they are in fact constraints.
  Moreover, <<local>>, <<parameter>>, <<global>> and <<self>> are not
 well
 supported by the metamodel, because a Link has a unary association to an
 Association, and a <<local>>, <<parameter>>, <<global>> and <<self>>
 Link do
 not refer to any association.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

They should be LinkEnd stereotypes. Don't see any other problems.
Proposal
Move them to stereotypes.

Issue 1214: "derived" not defined (uml-rtf)

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

Summary:  Notation 5.30.5 pg. 74. Where is "derived" defined?

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Use the tag {derived=true} to indicate a derived element.

Issue 1215: Notation for iteration in sequence diagram (uml-rtf)

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

Summary:  Notation 7.5.3 pg. 86. The notation for iteration is not clearly
 defined.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1216: "do" action not supported (uml-rtf)

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

Summary:  Notation 9.2.4 pg. 106,104: "An internal action string with the name
 "do"
 maps into the invocation of a nested state-machine." 
  My understanding is that this means that the state containing the "do"
 action is a SubmachineState with a separated State Diagram, drawn
 elsewhere.
 If this is the case, it should be stated more explicitly in the Notation
 document.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Fixed by addition of activity in a state.

Issue 1217: Mapping of concurrent subregions (uml-rtf)

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

Summary:  Notation 9.3.4 pg. 108. Each concurrent subregion map into a
 CompositeState?

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1218: RaiseAction and TimingMark are not defined (uml-rtf)

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

Summary:  Notation 9.5.4 pg. 112. RaiseAction and TimingMark do not exist in UML.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

References to RaiseAction and TimingMark have been removed.

Issue 1219: Control Flow types not modeled (uml-rtf)

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

Summary:  Notation 8.9.2 pg. 98 defines at least three kinds of Control Flow Type
 that have no mapping defined. In fact the metamodel does not support
 them,
 and besides that, they are ambiguous. The meaning of "flat flow of
 control"?
 should be explained in the document.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

The first is a call and has a CallAction.
The third is a send and has a SendAction.
The second shows the progression of steps within an execution and is a simple sequencing of actions.

Issue 1220: Threads of control in Collaboration Diagrams (uml-rtf)

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

Summary:  Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions,
 using
 names to differentiate between threads of control. These names do not
 map
 into anything in the metamodel.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1221: Syntax for Sequence Expressions inconsistently used (uml-rtf)

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

Summary:  Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions which
 is
 different from the one used in Fig. 40 pg. 97

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1222: GeneralizableElement should not inherit from Namespace (uml-rtf)

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

Summary:  GeneralizableElement inherits from Namespace (Semantics, Fig. 5 pg.
 16).
 This is not right because the property of an element of being
 generalizable
 and the property of being a namespace for other elements owned by it are
 orthogonal

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Separate Namespace and GeneralizableElement and use multiple inheritance.

Issue 1223: Modeling of realization/specification (uml-rtf)

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

Summary: Most of the relationships drawn on UML diagrams are modeled in the
 metamodel as classes (ex: Association, Dependency and Generalization
 with
 their possible subclasses).
  The relationship between a classifier and the classifier(s) that it
 implements is modeled by an (auto)association of Classifier
 (realization/specification, from Semantics, Fig.5 pg. 16), although it
 has
 a representation on UML class diagrams.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

This interpretation is correct.

Issue 1224: Class WFR (01) (uml-rtf)

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

Summary:  Correct WFR Class [1] pg. 29: m.specification ham multiplicity 1 so no
 "includes" is needed.

Resolution: Redundant with issue 864.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1226: Inconsistent use of stereotypes, tagged values, and metamodel (uml-rtf)

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

Summary: The use of stereotypes, tagged values and metamodel subclassing is not
 consistent in the metamodel. For instance, subclassing is used when
 defining
 the states specific to Activity Models, though the subclasses
 (ActivityState, ActionState) have no specific attributes and could have
 been
 stereotypes. The same with the subclasses of Action. Both approaches are
 correct, but since the two mechanisms are not orthogonal, there should
 be
 stated explicitly when to use one and when to use the other.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1227: Stereotypes for superclasses do not apply to superclasses (uml-rtf)

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

Summary:  There are a lot of stereotypes defined for Dependency, but which can
 apply
 only to some subclasses of Dependency. Example: <<call>> or <<becomes>>
 which certainly cannot apply to a Binding.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Problem of an instantiable superclass. Maybe should break out a subclass of Dependency to apply stereotypes to.
Proposal
Revise dependency relationships and clean-up stereotypes as discussed during Seattle RTF meeting..

Issue 1228: Stereotype modeled in two ways (uml-rtf)

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

Summary:  The concept of stereotype is modeled in two ways in the metamodel: as a
 class (Stereotype in the Extension Mechanisms package) and as a
 stereotype
 of Classifier, called <<stereotype>>.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Remove <<stereotype>> stereotype and make it a keyword on Rectangle symbol.
Describe how to define new stereotypes in the document.

Issue 1229: Inconsistency between stereotype tables (uml-rtf)

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

Summary:  There are inconsistencies between the tables containing stereotypes (at
 the
 end of each chapter) and Appendix A: <<inherits>> is a stereotype of a
 Class
 or of a Generalization; <<metaclass>> is a stereotype of a Constraint or
 of
 a Classifier; <<thread>> is a stereotype of Generalization or of
 Classifier.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Previously noted in issue# ???

Issue 1230: Collaboration showing instances (uml-rtf)

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

Summary:  If "an Interaction specifies messages sent between instances" (pg. 83)
 where
 are the instances on the diagram on page 81?
  I think a clear distinction between the meta-levels should be made. If
 Collaborations show ClassifierRoles and AssociationRoles (see fig. 15
 pg.
 81), the text should not imply that they show Instances and Links. The
 concepts are distinct, since they are modeled through two different
 classes
 in the metamodel.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

There is only one "metalevel" here, the metamodel level of abstraction. Interactions and collaborations are both
specifications.
However, since the later may appear "dualistic" (or 2-D) because it can be presented in terms of either 1) classifiers
and associations; or 2) "prototypical" instances and links. This is intentional, since methods vary in their modeling
techniques for collaborations.

Issue 1231: Collaboration::constrainingElement semantics (uml-rtf)

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

Summary:  Collaboration::constrainingElement doesn"t have a clear semantics.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1232: Modeling of guards (uml-rtf)

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

Summary:  Guard is a class, but it could have been modeled as an attribute in
 Transition, with the type BooleanExpression. 
  If it is left as a stand-alone class, it doesn"t have to inherit from
 ModelElement, especially since ModelElement has many associations, and
 Guard
 doesn"t use them at all. In fact this is more or less the case with many
 other descendants from ModelElement (for example, an Association doesn"t
 use
 the following associations inherited from ModelElement: behavior
 (towards
 StateMachine), collaboration (towards Collaboration) ).

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

style issue

Issue 1233: Multiple transitions from initial states should be allowed (uml-rtf)

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

Summary:   Maybe it would be useful to allow multiple transitions leaving an
 initial
 pseudostate (or multiple initial pseudostates), corresponding to
 multiple
 constructors of a class.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1234: Semantics of terminate transitions (uml-rtf)

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

Summary:  The semantics of terminate transitions leaving a CompositeState with
 sub-regions is defined in Notation pg. 105. It should be in Semantics,
 though.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Clarify semantics of final states.

Issue 1235: UseCaseInstance badly defined (uml-rtf)

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

Summary:  UseCaseInstance inherits from Instance, which inherits from
 ModelElement.
 Since a UseCaseInstance has no attributes and relationships defined, it
 has
 only those inherited, which are: name, the set of attribute slots and
 the
 link to a Classifier. Therefore, the statement "An explicitly described
 UseCaseInstance is called a scenario" (Semantics pg. 91) has no
 meaning,since
 there is no way to describe a UseCaseInstance by means of anything else
 than
 its UseCase.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

A scenario can be described with a sequence diagram, which cannot describe a use case.

Issue 1236: Notation for state machine inheritance (uml-rtf)

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

Summary:  Notation for state machine inheritance is defined in Semantics (pg.
 116)
 instead of Notation.

Resolution: UML 1.3: Clarified that notational example in Semantics is non-normative.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

Clarify that notational example in SEM is non-normative.

Issue 1237: Extension/recommendation needed for inner/outer transitions (uml-rtf)

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

Summary: An extension (or at least a recomendation) must be done in order to be
 able
 to express that a transition between two substates of the **same**
 CompositeSate crosses or not the boundary of the CompositeSate. If the
 transition crosses the boundary of the CompositeState, the
 CompositeState is
 re-entered: the exit+entry actions are re-executed, while if the
 transition
 does not cross the boundary.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 23, 1998: received issue
July 21, 1999: closed issue

Discussion:

The transition does not cross the boundary unless explicity. Perhaps a continuation state could be introduced in case
the transition needs to exit and reenter the region. It would be placed at the requisite outer level. Notationally the arcs
can cross the appropriate number of contours.

Issue 1248: UML Semantics, p 81, 145 (uml-rtf)

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

Summary: The Semantics introduces AssociationRole and AssociationEndRole wich inherits from the original Association and AssociationEnd (p81). Unfortunately, the xxxRole have a *mandatory* xxx as a "base" (multiplicity 1). I believe this is a bug, since it forces you to create an explicit association between the Classifiers, even for a {global} link, etc. Suggested correction: make the base optional (multiplicity 0,1) for AssociationEndRole with constraint base, local, global, self or parameter; make it optional too for related AssociationRole; leave it as is (mandatory) for ClassifierRole. Make it mandatory through OCL constraints for other AssociationEndRoles and AssociationRoles.

Resolution: Redundant with issue# 1019.
Revised Text:
Actions taken:
April 28, 1998: received issue
July 21, 1999: closed issue

Discussion:

 closed issue

Issue 1290: Interfaces and support classes (uml-rtf)

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

Summary: in UML I"m missing a specified way (e.g. a class stereotype) to 
 support the paradigm of "interfaces and support classes". I think it 
 would be a convienient way to specify the interfaces which are offered 
 by a class like methods and properties:
 
 +------------------------------+
 | SomeContainer                |
 | <<implementation Class>>     |
 +------------------------------+
 | interface IIndexAccess       |
 | interface IEnumerationAccess |
 | interface ISomewhatOther     |
 +------------------------------+
 | property PropA               |
 | property PropB               |
 +------------------------------+
 
 The other thing annoying for me is the definition of aggregation. My 
 understanding of aggregation ist that the aggregating object offers 
 the interfaces of the aggregated objects as they where it"s own (for 
 the outer view). The definition of UML seems to be only a "containing" 
 relationship.

Resolution: Considered and declined.
Revised Text:
Actions taken:
April 29, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1309: Collaboration as a Classifier (uml-rtf)

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

Summary: It appears very useful to make Collaboration a subtype of Classifier or 
 GeneralizableElement (instead of just Namespace). This would allow 
 refinement of Collaborations using the standard UML refinement 
 mechanisms.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 5, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1323: Why is Classifier an Aggregate of Features? (uml-rtf)

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

Summary: Page 16 Why is Classifier an Aggregate of Features (black diamond). It also 
 needs a name; and is it really invariant? (Or, more broadly, does it have
 the properties of a composite aggregation - but see General Concern 1
 above)

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

It has a name and it owns its features.
This is a design choice, not an issue.

Issue 1324: Interface must also have features (uml-rtf)

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

Summary: Page 16 If Classifiers have features  (e.g. attributes and methods) then an
 Interface must also have features since it is a kind of Classifier. Yet, 
 on page 24, it is stated that an Interface has operations only; on page 37
 Notation document it clearly states Interface "lacks attributes". If this is 
 done by an OCL constraint, then we have a negation of properties of the
 subtype which Brachman points out to be dangerous.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

May need to clarify how WFR constraints are used to "subtract" features.

Issue 1325: Page 16 lost fact that Class realizes an interface (uml-rtf)

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

Summary: Page 16 Lost the fact that Class realizes an Interface although I think this
 may just have been moved to Classifier realizes an Interface.  But this is
 no longer explicit.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1326: Is name space really a composite aggregation of model elements? (uml-rtf)

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

Summary: Page 16 Is a namespace really a *composite aggregation* of model elements?

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

 closed issue

Issue 1327: Page 16 ---editorial (Element Ownership) (uml-rtf)

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

Summary: Page 16 Isn"t Element Ownership an Association Class - in which case the 
 joining line should be dotted.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

fix as suggested

Issue 1328: Why does GeneralizableElement inherit from Namespace? (uml-rtf)

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

Summary: Page 17 Figure 6 Why does GeneralizableElement inherit from Namespace? This is 
 a question to which I *really* would appreciate an answer. I asked Grady but 
 got an unconvincing answer (see General point 2 above). The white triangled 
 arrowhead indicates generalization i.e. knowledge representation and/or 
 subtyping. I don"t see how a GeneralizableElement *is a kind of* Namespace. 
 I see that a Namespace would include (containment or maybe even aggregation) a
 Generalizable Element but ...

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

It is an accidental coincidence that was adopted for convenience.
It is not logically valid but it is a collapse of two separate hierarchies with the net effect.
Proposal
Change it to use multiple inheritance.

Issue 1329: How to stop an interface realizing a Data Type ? (uml-rtf)

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

Summary: Page 20 line -2 "may realize zero or more interfaces". Where is this shown in
 the metamodel? Answer is recursively on page 16. But how to you stop an
 Interface realizing a DataType, for instance?

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1330: Class to be defined as an intension (uml-rtf)

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

Summary: Page 20 Class.  A class is a description of a set ...
 This is a definition of class as an extension. We also need class to be 
 defined as an intension (Odell and de Champeaux also stress this).

Resolution: Clarified in UML 1.3
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1331: Page 35 -Diagram (uml-rtf)

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

Summary: Page 35 line beneath diagram A class declares a collection of methods,
 operations and attributes. Since methods implement operations, then this is
 confusing concepts at two different levels which elsewhere are cleanly
 separated into the internal/external dichotomy which objects need to support
 (and which in general in UML is much improved)

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

 considered and declined

Issue 1332: Page 35 Diagram (02) (uml-rtf)

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

Summary: Page 35 Diagram. Is a Class really a composite aggregation of model eleemnts. 
 I guess the answer is yes since it inherits from Namespace. However, as
 I am challenging the Generalizable Element/Namespace inheritance, this might 
 have repercussions here.

Resolution: Clarified.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1333: Page 38 para 2 line 3, one of its containers is deleted (uml-rtf)

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

Summary: Page 38 para 2 line -3 one of its containers is deleted. 
 Bad choice of word (container). Containment is a relationship which is NOT
 related to aggregation. This para discusses aggregation and should not therefore
 discuss containment (see Winston et al., 1987, Odell, 1994, 
 Henderson-Sellers, 1997).

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Reword the offending sentence to avoid the word "container".

Issue 1334: Page 40 table 2 Model Element class (uml-rtf)

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

Summary: Page 40 Table 2 Model Element Class. Surely the stereotype of inherits is
 incorrect here. It is not correct according to the Appendix.
 Also <<thread>> for Generalization is not defined -- page 143. Is it correct?

Resolution: Fixed is UML 1.3
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

The stereotype has been removed.

Issue 1335: Aggregation of class? (uml-rtf)

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

Summary: Page 45 Component. Is it really a class -- or perhaps an aggregation of classes?

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

It is both source and runtime. As source, it is a namespace. It may also have its own features and interfaces.
As run time, it contains the code for the elements in its namespace. It is a unit for loading code onto nodes. If it
wants to contain instances, they must be related to it as an instance.

Issue 1336: Page 45 dependency lines 2/3 between model elements not instances? (uml-rtf)

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

Summary: Page 45 Dependency lines 2/3 between model elements not instances. Really?
 But A <<uses>>B is a client-server at instance level also, where
 <<uses>> is a stereotyped Dependency. Why is this discrimination between
 class/type versus instance applied here so explicitly. (BTW I have been
 trying to elucidate the connection between Dependency and Association as
 raised in OTUG by Bob Martin and others. My answer is in my JOOP
 column of Feb 98. I have constructed an interesting and progressive metamodel 
 for relationships including aggregation-type ones which seems to make overall
 sense).

Resolution: Clarified
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Comments
When modeled in this way, Dependency has no extent. It may have a deep connection to instances but the
point of modeling it as a Dependency (rather than a collaboration, for example) is to connect simply the classifiers.
Proposal
This is not a problem. See comments.

Issue 1337: Page 47: Dependency is a unidirectional, client-server (uml-rtf)

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

Summary: Page 47 Dependency is clearly a unidirectional, client-server relationship.
 Usage, as a stereotype of Dependency, similar. But I don"t get the same
 feel for Trace and, to a lesser degree, Refinement. Indeed, trace seems
 to negate some of the properties of Dependency - a bad practice as
 Brachman pointed out many years ago. For example, Trace has no
 directionality yet it inherits unidirectionality from Dependency which it must
 therefore cancel/negate.

Resolution: Redundant with issue# 1227.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

There is no harm in ascribing directionality to Trace, even though sometimes it might be ignored ( but not always).
Proposal
Combine with #1227 Dependency cleanup

Issue 1338: Page 50: "instance" should be changed to "instatiate" (uml-rtf)

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

Summary: Page 50 We have <<instance>> and on page 71 notation doc <<instantiates>>.
 I understand from Cris Kobryn that this will be fixed and both will be
 changed to <<instantiate>> [comment included here for completeness only]

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1339: Page 50: should stereotypes be defined at the subclass level? (uml-rtf)

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

Summary: Page 50 Dependency has 4 subtypes (refinement, trace, binding, usage) and
 (page 50 semantics) 10 or so stereotypes. Each of these stereotypes
 can be applied to each of the 4 subtypes. Are all combinations valid?
 If not, some of the stereotypes should be defined at the subclass level, not
 as stereotypes of the superclass, Dependency.

Resolution: Redundant with #1227
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1340: Page 50: table 3 component (uml-rtf)

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

Summary: Page 50 Table 3 Component. Stereotype <<friend>>. Elsewhere the document says
 this is a stereotype of <<using>>

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1341: Page 50 Table 3 "refinement" (uml-rtf)

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

Summary: Page 50 Table 3 <<refinement>> should be added as a stereotype of Dependency.

Resolution: Fixed in UML 1.2.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed,issue

Discussion:

Issue 1342: Typos on pages 55 and 62 (uml-rtf)

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

Summary: Page 55 Typo line -4 base Class Specifies (not Species)
 
 Page 62 Typo line -3 String not Sting

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Previously fixed in editorial revision 1.2.

Issue 1343: Discussion on Collaborations and Interactions is confusing (uml-rtf)

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

Summary: Page 86 et seq. I find the discussion on Collaborations and Interactions etc.
 confusing. It seems to be inconsistent. On page 86 we have Collaboration is
 at a higher level than Interaction and Collaboration is an aggregate of
 Interactions. Whilst in the  Notation Guide (see also Fowler and Scott,
 p103-110) Interaction diagrams are at a higher abstraction level than
 Collaboration diagrams (page 80 of Notation guide)

Resolution: considered and declined
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

There are some unfortunate naming inconsistencies here.

Issue 1344: Page 93: Is Namespace really aggregeation of use cases? (uml-rtf)

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

Summary: Page 93 Is a Namespace really an aggregation of use cases? I thought a
 namespace could be at the class level whereas use cases often involve
 very many classes.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

What's the problem here? Some namespace will have a collection of use cases.

Issue 1345: Page 93: use case (uml-rtf)

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

Summary: Page 93 Is Use Case really a composite aggregation of attributes and 
 operations -- surely not?

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Ivar claims that it is (among other things that it contains).

Issue 1346: Uses and extends not types of generalization (uml-rtf)

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

Summary: Page 93 Lots will argue, as do I and Rumbaugh in JOOP some years ago, that
 uses and extends are NOT types of generalization. They do not have 
 substitutability in the sense of a generalization hierarchy for Classes, 
 for instance.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

This has been addressed in another issue and resolved.
Proposal
The revision of use case relationships in UML 1.3 corrects this and related problems.

Issue 1347: Page 98: Transition is an aggregation of guards (uml-rtf)

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

Summary: Page 98 Transition is an aggregation of guards. Surely, the guard 
 governs whether a transition takes place, it is not an integral part of
 it. Similarly, I don"t believe that a State is made up of (i.e.
 composite aggregation) Transitions!

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1348: Page 136: Model package relationship (uml-rtf)

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

Summary: Page 136 Model - Package relationship (in diagram) should not be
 aggregation but generalization (according to page 129, Figure 23)

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1349: Page 143: uses is a stereotyped dependency (uml-rtf)

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

Summary: Page 143 Uses is a stereotyped Dependency (Notation page 71) and so should
 be added to list in Semantics document here on page 143 and also on page 50

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

The Semantics document is correct in this case, not the Notation document.

Issue 1350: Page 143: "uses" as a stereotype on Generalization (uml-rtf)

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

Summary: Page 143 <<uses>> as a stereotype on Generalization. It is also an important
 stereotype on Dependency.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

This has been removed by the use case changes.

Issue 1351: Typos on page 90, 151 plus errors in page numbering (uml-rtf)

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

Summary: Page 90 line 1 typo Ref to Figure 15 should be to Figure 16 presumably
 Page 151 Typo dependency line 2 will affect should be may affect
 
 Page 161 Lots of errors on pages numbers e.g. Dependency should be
 22, 31, 43, 44, 141; Mapping 60 etc.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 14, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1354: Editorials on pages iv, v, 3, and 4 (uml-rtf)

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

Summary: Page iv and v Section 7 and 7.2 and 10 and 10.2 have same names. This is not
 normal practice
 
 Page 3 line -9 no dangling lines -- agreed re final diagram but may be 
 needed as interim state
 
 Page 4 para 2 Two options equivalent. Yes, except for discriminants when
 joining together all paths would be wrong

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Reject dangling lines change--not allowed and we considered it.
Fix or clarify typos.

Issue 1355: Page 11: Operation-Call (uml-rtf)

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

Summary: Page 11 line -9 Operation-Call. I don"t find this (a) intuitive and
 (b) in the metamodel. A Method implements an Operation and a call is the
 dynamic activation of an operation -- is it really an instance of an
 Operation? Surely Operation-Call should read Operation-Method.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1356: Page 13: Packages are GeneralizableElements (uml-rtf)

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

Summary: Page 13 Packages are GeneralizableElements. I understand they can be
 inherited, yet I am not sure what that may mean, especially with
 respect to protected status
 This seems to be using C++ syntax at too high a level of abstraction

Resolution: Clarifed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Maybe, but it is consistent. Child package can see protected stuff from the parent.
Issue: are the inherited elements clones or by reference? It includes inheritance of the namespace. The child package can add elements to the namespace.
A child can see protected elements.

Issue 1357: Page 20: Section 4.3.1 could be misleading (uml-rtf)

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

Summary: Page 20 I think Section 4.3.1 could be misleading since we are talking
 of the subclasses at the *meta*level. Saying it "represents a subclass
 of an existing modelling element" could be (erroneously) interpreted
 at the model, rather than the metamodel, level. This is particularly
 likely since the description is part of the Notation doc. Had it been
 part of the Semantics doc, its context there would have not led to any 
 problems.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Rephrased to indicate that it applies to metamodel elements.

Issue 1358: Page 24: add link to Interface (uml-rtf)

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

Summary: Page 23 notation and page 16 semantics say Interface is subtype of
 Classifier. Yet on page 24 Semantics it is stated that a Classifier
 *realizes* the Interface. Since both are true, perhaps a link should be
 made somewhere to give the complete picture.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1360: Page 24 Section 5.4.3 para 1: missing compartments (uml-rtf)

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

Summary: Page 24 Section 5.4.3 para 1 re missing compartments. This will be
 confusing to users when boxes are absent with no obvious clue as to 
 which it is that *is* present. This is much more important for novices;
 experts will cope.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1361: Page 26: rename reponsibilities, rules, modification histories etc. (uml-rtf)

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

Summary: Page 26 line -6 responsibilities, rules, modification histories etc.
 These are collectively called traits in OML. A useful way of describing
 them which we recommend to you.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1362: Page 29: Protected member (uml-rtf)

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

Summary: Page 29 Protected visibility only has meaning in context of inheritance.
 Fromoutside a protected member is essentially a private (i.e. encapsulated)
 one.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1363: Page 30: Class scope attribute underlined (uml-rtf)

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

Summary: Page 30 Class-scope attributes underlined.  I think users will find this totally
 obtuse. For consistency one really should underline object attributes. 
 I understand that they are more common but ...
 Users will also find the explanation here arcane and contrived.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1364: Page 35/6 : Stereotypes (uml-rtf)

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

Summary: Page 35/6 I have a number of problems here.
 1. Stereotypes are merely a subclassing or specialization mechanism
 (Notation doc, p20, l2). Agreed. The question is whether Type and
 ImplementationClass are *really* subtypes of Class. This I doubt.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 21, 1999: closed issue

Discussion:

Issue 1365: Page 35/6: Use of word type is confusing (uml-rtf)

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

Summary: 2. The use of the word Type here is confusing. In previous versions it
 was used as approximately the same as Interface as in: "the Class
 realizes/implements the Type". Here it seems to be a synonym for
 Role as in OOram (or OPEN). Why not just call it Role, for that is
 what it seems to be -- a type of dynamic classification.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1366: Page 35/6: Why are attributes and association not inherited? (uml-rtf)

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

Summary: 3. Why are attributes and associations not inherited? (The diagram is
 confusing since elements:Collection is not inherited yet appears to be).
 This odd sort of inheritance is stressed again in connection with
 Interfaces on page 36 and again on page 37 (last line).
 If Types can have attributes (presumably logical attributes) then surely
 the ImplementationClass needs to know about these to map into physical
 attributes or methods in its implementation.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1367: Typos on pages 24, 40, and 50 (uml-rtf)

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

Summary: Page 24 line -3 Typo Being should be Begin
 Page 40 Arrowhead wrong <<bind>> is a stereotyped dependency. Open 
 arrowhead needed
 
 Page 50 Section 5.20.2 para 2 l1. Typo Un should be In and para 3 l1
 hasn"t association role now been changed to association end?
 (see p52 in Semantics doc)

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1368: Page 52 figure 20 (uml-rtf)

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

Summary: Page 52 Figure 20. In the recursive association on Job,
 how does the Job play the role of boss or worker?

Resolution: Clarified.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

It shows the job playing the given rule.

Issue 1369: Page 57: mathematical issue (uml-rtf)

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

Summary: Page 57 Mathematically *..* cannot be identical to 0..*. Since * is a "wild
 card" value, then it could be say 1. So the first would be 1..1 and the
 second 0..1 i.e. different

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1370: Page 58: Add index entry (uml-rtf)

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

Summary: Page 58 I had difficulty in  finding Qualifier in the metamodel of 
 the Semantics document (it isn"t in the index -- suggest adding index entry)

Resolution: Rebuild index on each release.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

The index is weak on things that are not primary concepts.
Proposal
The index will be expanded.

Issue 1371: Page 67: Why is discriminator not discussed in terms of power types? (uml-rtf)

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

Summary: Page 67 Why is discriminator no longer discussed in terms of power types?
 If correct, that was neat (in the previous version)

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Power types confused people, so we avoided them in the definition.

Issue 1372: Page 68 overlapping (uml-rtf)

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

Summary: Page 68 overlapping/disjoint. This relates to whether the subsets overlap
 or not; in other words, whether an individual instance can belong to more 
 than one of the subclasses. At present it implies there are classes,
 subclasses and subsubclasses. Suggest reworing (for both overlapping
 and disjoint) as
    ...may be an instance of ...
 rather than 
    ... may be descended from ...
 Typo: descendant (-ant not -ent by the way)

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Reword as necessary.

Issue 1373: Page 71: Distinction between Dependency and Association (uml-rtf)

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

Summary: Page 71 I don"t find a *clear* distinction between Dependency (especially
 its <<uses>> stereotype) and Association. Since all OO is to do with 
 Client-server relationships, these must all be Dependencies thus eliminating
 the need for Association!!?? My answer is that they are equivalent but with a
 different focus, an association describing the static architecture and a uses
 the dynamic (message-passing) topology -- see Henderson-Sellers, Feb 1998, JOOP

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Comments
Association and Generalization can be considered dependencies with precise semantics. Dependency is all the rest.

Issue 1374: Page 72: Example needs rejigging (uml-rtf)

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

Summary: Page 72 If Class C - Class B relationship is instantiates, then surely 
 Class C should be Object C. A consequence of this is that the <<calls>>
 is now wrong because it needs to be between 2 classes. Example needs
 rejigging.

Resolution: Consdered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1375: Page 79: Poor choice of arrowhead (uml-rtf)

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

Summary: Page 79 The <<uses>> relationship is a poor choice of arrowhead, since the
 white arrowhead is a generalization-style. What is needed is something 
 more reminiscent of either association, or, probably better, dependency.  So 
 an open arrowhead, possibly even with dotted line as in Dependency
 stereotyped with <<uses>> in static diagrams might be better.

Resolution: Consdered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1376: Page 80: Confusion with headings (uml-rtf)

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

Summary: Page 80. I still get confused with the headings here. Interaction diagrams is
 a collective name which includes both sequence diagrams and collaboration
 diagrams. So the heading for section 7 of Sequence diagrams seems wrong
 because it is low level followed by a high level heading of Kinds of
 Interaction Diagrams.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Some structural and naming cleanup is needed here.
Proposal
Add a cross reference in Chap. 8 to chapter 7.

Issue 1377: Page 82: Add explanation (uml-rtf)

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

Summary: Page 82 Why do some arrows have solid heads and yet on the previous page they
 were open both to left and to right? An explanation of these
 notational elements must be added to page 81/2

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Add a reference to messages in Chap. 7.

Issue 1378: Page 94 --editorial (uml-rtf)

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

Summary: Page 94 I am unconvinced about class roles and association roles (bottom half) 
 and this text seems to have been pasted in from elsewhere

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

This will be rewritten as a result of clarification of colllaboration semantics.

Issue 1379: Page 98: arrowhead issue (uml-rtf)

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

Summary: Page 98 Filled arrowheads, stick arrowheads are dangerously close. For
 instance, Powerpoint only offers the filled and in other situations this
 would double for the stick arrowhead. In other words, too much semantic stress on
 arrowhead shape when many common tools like Powerpoint can"t differentiate.
 [Powerpoint is a simple example. I have watched tool vendors and publishers take
 a diagram like this and replace with their own versions of a black/white;
 open/closed arrowhead and accidentally transform the meaning. Even from
 UML generalization to stick arrowhead for dependency is not that hard -
 I"ve seen it done!]

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1389: Aggregation is poorly defined (uml-rtf)

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

Summary: 1. Aggregation is poorly defined. It is not clear whether it is meant to be
 configurational and/or invariant (reading different parts of the documents
 give different signals). Instead it concentrates on lifetime dependency
 and unique connections. I believe it is intended to be invariant but not
 necessarily configurational.  Firstly, that definition needs tightening and,
 to me and Jim Odell, being configurational seems to be a prime requirement
 for aggregation. Without it we really have a membership (yet still whole-part)
 relationship.  
 Secondly, whatever the definition decided upon, its use in the metamodel must 
 be clear and clean. At present, I believe many of the "black diamonds" in the 
 metamodel really are not strong aggregations (whichever definition I try
 to use).

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 19, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1390: "Inheritance" connection used is a generalization relationship (uml-rtf)

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

Summary: 2. In the same vein, it is clear that the "inheritance" connection used
 in all parts of the metamodel is in 
 fact a generalization relationship. I believe this to be the best choice.
 However, I would ask whether ALL of the generalization relationships in the
 metamodel really do fulfil the criterion of generalization  i.e. we can
 say yes to the question "is the subclass A KIND OF the superclass?". 
 My biggest query here, which I have asked many times, is "Is a Generalizable
 Element a kind of Namespace?" as shown in Figure 6 of semantics document.
 Grady"s answer to me was "the simple reason is that superclasses form
 a namespace". Forming a namespace sounds to me like aggregation or 
 membership and not generalization.

Resolution: Considered and declined.
Revised Text:
Actions taken:
May 19, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1391: Responsibilities hardly figure in these documents (uml-rtf)

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

Summary: 3. Another major concern is the way that Responsibilities hardly figure in these
 documents. They are shown as a tagged value of Classifier and that is all.
 On page 156 a responsibility is defined as a contract. This is incorrect.
 The two are linked but in no-one"s responsibility and contract model 
 (e.g. Wirfs-Brock, Meyer) are the two the same. 
 Responsibilities are not even in the Index. 
 I believe that a standard metamodel should be equally usable for a
 responsibility-driven modelling approach as for a use case or data driven 
 approach. The lack of good support for responsibilities (which is not that
 hard - we have done it in OML as an extension of UML - see paper in <<UML>>"98
 Conference proceedings) is a significant drawback to the adoption of UML
 by organizations using any type of responsibility-driven method.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 19, 1998: received issue
July 22, 1999: closed issue

Discussion:

Make it a stereotype of Comment.

Issue 1392: General recommended use of UML (uml-rtf)

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

Summary: 4. Whilst there is no statement explicitly, it is clear that the general
 recommended use of UML associations is as bidirectionality for the default.
 It has been shown by many that such an assumption is not in line with
 good OO modelling and indeed violates encapsulation: a key tenet of OT.
 The notation similarly supports such an interpretation and, furthermore,
  mandates the decision on directionality immediately since there is no
 way to sketch in a relationship whose direction is to be decided (TBD) later.

Resolution: Considered and declined
Revised Text:
Actions taken:
May 19, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1393: Permit multiple stereotyping on relationship (uml-rtf)

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

Summary: 5. Finally, a suggestion. In OML (see e.g. JOOP, May 1998) we found it useful
 to permit multiple stereotyping on relationships. In UML, as I understand it,
 there is a restriction that only a single stereotype can be used at any
 one time. Whilst care must be taken in multiple stereotyping, I would suggest
 that for predefined stereotypes there should be no problem and recommend
 UML consider permitting multiple stereotypes.

Resolution: Considered and declined
Revised Text:
Actions taken:
May 19, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1400: State diagrams: action expressions (uml-rtf)

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

Summary: Is there any reason why UML1.1 specifies different syntax for showing an
 action in response to an event, depending on whether the event is internal
 (NG 9.2.2) or external (NG 9.5.2)? 
 
 And in the latter case, what is the point of the caret? For example, 9.5.2
 seems to suggest that we should probably write (yes, I"m hedging, because
 it isn"t completely clear there what can be in an action expression, or
 indeed what the overall syntax of a transition string is intended to be)

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
May 25, 1998: received issue
July 22, 1999: closed issue

Discussion:

These are all just actions.
Proposal
Remove '^' as a special delimiter and just treat sent as yet another action, possibly with reserved words.

Issue 1402: Specification for method in a derived class (uml-rtf)

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

Summary: It is unclear whether a specification for a method in a derived class should be an operation in the base class, or if the operation is redeclared and it is the derived class"s instance of the operation that is the specification.
 The text on p36 ("Each method implements an operation declared in the class or inherited from an ancestor...the same operation may not be
 declared more than once in a full class descriptor") suggests that it is illegal to redeclare the operation in the derived class and we must have the former interpretation.  However this is not enforced by the Classifier constraint [1] on page 29.  If this is really what is desired, then the constraint should be self.allFeatures... instead of self.feature...
 
 This interpretation causes operations and methods to behave like C++ rather than Java.  An operation has on

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
June 1, 1998: received issue
July 22, 1999: closed issue

Discussion:

This is already identified for cleaned up in 1.3

Issue 1406: Extension Point (uml-rtf)

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

Summary: Here is the new proposal for the definition of extension points.
 
 Extension point -- a named location in the behavior specified by a
 Classifier. An extension point might either be before or after an
 Activity or an Action in an ActionSequence, or be a State. It is used
 for specifying where additional behavior may be added, e.g. by being
 referenced by an Extends relationship.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
June 1, 1998: received issue
July 22, 1999: closed issue

Discussion:

Recommended as proposed in UML Reference Manual.

Issue 1506: UML 1.1 issue on Associations (uml-rtf)

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

Summary: The semantics of Navigation with Nary associations is not clear. For example, If we have three Classes C1, C2, C3 linked with a ternary association. 
 If this ternary association is navigable to C3 : what does it means?? Does C1 and C2 instances may access to C3 linked instances through this association?
 Then if the ternary association is navigable to C2 and to C3. Is this legal? What does it means? Does C1 instances may access to C2 and C3 instances? Does C2 instances may access to C3 instances and C3 instances may access to C2 instances?
 Some clarification is needed there.
 I imagin that Navigability makes sense in binary association, but do not make much sense with Nary associations.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
June 5, 1998: received issue
July 22, 1999: closed issue

Discussion:

Navigability has little meaning on anything but a binary association.
It may be declared on n-ary associations (because it is not worth the trouble of prohibiting it)
but we do not assign a meaning in that case.
Creative souls will undoubtedly come up with suggestions for a meaning anyway.

Issue 1507: Merge "Class" and "Interface" into one class (uml-rtf)

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

Summary: Specifying "Interface" and "Class" as seperate metamodel classes has practical ramifications for UML tools. During analysis/design, a developer may start out by specifying a class, but then decide that it should be an interface. The reverse is also possible. This switching, from Class to Interface, or vice versa, would be very easy if "Interface" is merged into "Class" and the two concepts are distiguished by a stereotype called "interface". This recommendation is also supported by the fact that indeed the notation distinguishes the two concepts by a stereotype called "interface".

Resolution: Withdrawn by submitter.
Revised Text:
Actions taken:
June 6, 1998: received issue
July 22, 1999: closed issue

Discussion:

 closed issue

Issue 1508: Clarify how types of attributes and parameters should be instantiated (uml-rtf)

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

Summary: It is not very clear how types of attributes and parameters should be instantiated. For example, consider the following C++ methods:
 
     void Draw(Window win);
     void Draw(Window* win);
     void Draw(Window& win);
 
 In all three cases the name of the parameter is "win". The types are "Window", "Window*" and "Window&" respectively. How can these types be modeled? In the first case I can imagine creating a link between the parameter "win" and the Classifier "Window". But what about the remaining two cases?
 
 UML 1.0 represented attribute and parameter types by simple uninterpretted strings. This allowed user to specify any complex language expression for types. I would prefer that this mechanism be reintroduced. The current mechanism may be left in place in case users or tools like to specify tighter bindings to Classifier instances.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
June 6, 1998: received issue
July 22, 1999: closed issue

Discussion:

Discussion: 1) UML Semantics/page 60/figure 10 Derive a class from Expression called TypeExpression.
Note that type expressions can be language-specific (because of the "language" attribute of Expression). 2)
Add the following definition for TypeExpression in section 7.2: "In the metamodel TypeExpression defines a
statement which will evaluate to a reference to a Classifier when it is evaluated." Since we are now defining
TypeExpression precisely, remove the glossary item "type expression" from Appendix B. 3) UML
Semantics/page 16/figure 5 Add the following attribute to metaclasses Parameter and StructuralFeature: type:
TypeExpression Change the name of the two association ends called "type" to "typeref". The implication now
is that the language-specific type expressions added above evaluate to references to Classifiers. 4) Change
language in section 4.2 to reflect the above changes: page 20: Attribute->Attributes
============================== type A TypeExpression that evaluates to the type of the attribute.
page 20: Attribute->Associations ================================ typeref Designates the
classifier refered by the type of the attribute. page 27: Parameter->Attributes
============================== type A TypeExpression that evaluates to the type of the parameter.
page 27: Parameter->Associations ================================ typeref Designates the
classifier refered by the type of the parameter. Proposal
Add LanguageType as a DataType with a body that is a TypeExpression. Add TypeExpression.

Issue 1509: Class "Model" is too prescriptive (uml-rtf)

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

Summary: "Different Models can be defined for the same modeled system, specifying it from different viewpoints, like a logical model, a design model, a use-case model, etc."
 
 This statement is too prescriptive in suggesting that the modeled system should be partitioned into a logical model, a use case model, etc. The user may wish to partition the system using some other criteria, for example on functional lines, and may wish to "package" all the views for a particular function or facility within a single package. The partitioning suggested above can be easily obtained by using UML Packages named "Logical Model", "Use-Case Model" etc. Also note that class "Model" adds no attributes or associations to its superclass - it simply suggests a groping concept.
 
 Hence I recommend complete elimination of class "Model". The modeled system is simply a hierarchy of "Packages".

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
June 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1510: The class "Subsystem" inherits from "GeneralizedElement" twice (uml-rtf)

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

Summary: The class "Subsystem" inherits from "GeneralizedElement" twice:
 
     SubSystem->Package->GeneralizableElement
     SubSystem->Classifier->GeneralizableElement
 
 The only functionality it adds to Package is the ability to add operations at the Subsystem level as indicated by the statement below:
 
 "In the metamodel Subsystem is a subclass of both Package and Classifier, whose Features are all Operations."
 
 I would recommend simplification of the class hierarchy by merging "Subsystem" into "Package" and deriving "Package" from "Classifier":
 
     Package->Classifier->GeneralizableElement
 
 The attibute "isInstantiable" of Subsystem can be moved up to Package.

Resolution: Considered and declined.
Revised Text:
Actions taken:
June 6, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1515: Reflexive association in section 5.20.2 (uml-rtf)

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

Summary: In section 5.20.1, a "reflexive association" is defined as an association
 from a class to itself. This is consistent with the terminology as 
 generally used in the field.
 
 However, in section 5.20.2, a reflexive association appears to be defined
 as one that has links from an object to to itself.
 
 This second defintion is not industry standard (including some of the 
 amigos work), appears to conflict with 5.20.1 and somewhat misapplied. The contingent existence of an 
 object-to-self link should not be changing the characterization of the 
 association. A reflexive assocation need not require a reflexive link.

Resolution: Fixed in UML 1.3
Revised Text:
Actions taken:
June 10, 1998: received issue
July 22, 1999: closed issue

Discussion:

Comments
Refilexive means in relation R: A * A then for every a in A, (a,a) is in R.
We have been using it wrong.
Proposal
Reword to avoid the term "reflexive".

Issue 1579: Stereotypes on Dependency, page 43 of V 1.1 (figure 7) (uml-rtf)

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

Summary: There are four stereotypes shown on Dependency on page 43 of V1.1 (Figure 7).
 Trace, Refinement, Binding and Usage
 These are shown as peers but are in fact representative of two very different
 types of partition.
 My proposal is to remove Usage as a subtype of Dependency. We could than add
 a new abstract type Relationship to model runtime relationships, with Associaton
 and Usage as subtypes. There should be no connection between Relationship
 and Dependency.

Resolution: Redundant with 1227.
Revised Text:
Actions taken:
June 24, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1634: No discription of the association between Classifier and Parameter is give (uml-rtf)

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

Summary: No discription of the association between Classifier and Parameter is given.
 The (*) indicates that the association (with the implicit name of parameter)
 is a set.  It should also be noted that it is ordered.

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 2, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1635: Operation asSequence Issue (uml-rtf)

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

Summary: The operation asSequence is defined to return 
 "A Sequence that contains all the elements from set, in random order."
 
 This probably should read "arbitrary order" since we are not promising to
 apply a "random number generator."

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
July 2, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1636: Collection type within OCL missing (uml-rtf)

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

Summary: There is no collection type within OCL that corresponds to the UML notion 
 of an ordered list without duplicates [UML Notation Guide, ad/97-08-05, p.
 53, definition of "ordered"], i.e. an "ordered set".

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 2, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1637: Semantics for dynamic invocation of concurrent activity models are missing (uml-rtf)

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

Summary: Semantics for dynamic invocation of concurrent activity models are
 missing in the current UML version.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 6, 1998: received issue
July 22, 1999: closed issue

Discussion:

Recommended fix outlined in activity model issue document.

Issue 1651: Changes to figure 15 and description of ClassifierRole on page 82 (uml-rtf)

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

Summary: Figure 15 on page 81 shows that a ClassifierRole has a single base Classifier.
 However, an Instance may have multiple Classifiers (see Figure 14 on p. 67).
 Indeed, the Notation Guide gives a notation for showing an Object having
 multiple Classes (on p. 46) and maps this notation to an Object within an
 object or class diagram, but to a ClassifierRole on a collaboration diagram.
 To support this notation, and to be consistant with the ability of Instances
 to have multiple Classifiers, a ClassifierRole should be able to have
 multiple base Classifiers.
 
 This requires a change to the multiplicity of the appropriate association
 in Figure 15 as well as updates to the ClassifierRole description on p. 82
 and the well-formedness rules for ClassifierRile on p. 84. (Actually, I think
 only the words in the WF rules need to change -- the current OCL rules will
 accomodate the change in multiplicity of "base".)

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 9, 1998: received issue
July 22, 1999: closed issue

Discussion:

Allow ClassifierRole to have multiple Classifiers.

Issue 1663: Protocol state diagrams issue (uml-rtf)

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

Summary: UML still does not develop the meaning and the semantics of protocol state diagrams. Protocol state diagrams are close to be supported by the UML metamodel, which still requires some smooth evolutions.
 In a protocol state diagram, a transition related to an operation expresses that the operation can be invoked under the origin state and the "guard" condition, and that under these preliminary context, the operation invocation will lead to the destination state, under a certain post-condition. 
 A protocol state diagram can be entirely transformed into pre and post conditions for the involved methods.
 There is a need to add post-condition to transitions for protocol state diagram.
 Suggestion : add a new aggregation from transition to "Guard", called post.

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 10, 1998: received issue
July 22, 1999: closed issue

Discussion:

Put the responsibility of the pre- and post-conditions on the actions.
Proposal
The postcondition belongs on the action, not on the state machine.

Issue 1664: Implicit transitive import between packages (uml-rtf)

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

Summary: Implicit transitive import between packages is destructive for encapsulation management. "package Users import package TapeRecorder that import package integratedCircuit implies that package Users sees every public components of integratedCircuit". I suggest that imports becomes not transitive, so that import dependencies must be explicitely declared, or deduced from package aggregation.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
July 10, 1998: received issue
July 22, 1999: closed issue

Discussion:

Already the rule for import, but need to reinforce this by discussion.
Phillippe's experience suggests that nontransitive saves users much headache.
Proposal
Make import and access nontransitive.

Issue 1678: States of an object not referenceable from OCL expression (uml-rtf)

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

Summary:  The states of an object, as specified in its state machine, are not
 directly referenceablle from within
     an OCL expression. In many cases it is very useful to be able to use them
 in invariants, and especially
     in pre- and postconditions.
 Currently, we can define a so-called state attribue, which enumerates the
 states, or alternatively we can
    define a boolean attribute for each state. This allows one to reference
 states, but this is specific for
     the chosen implementation of states.  This is undesireable.  Being able to
 directly refer to the abstract
     states from the state machine is much easier, since it allows specifying
 constraints independent of
     the implementation of states.
 Proposal
    Define an extra standard OCL operation on OclAny called "oclIsInState", or
 "oclInState" which takes a state name as
    a parameter, and results in true if the object is within the specified
 state.  This solution adds the
    desired functionality without altering the syntax of OCL.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 14, 1998: received issue
July 22, 1999: closed issue

Discussion:

Add oclIsInState as operation to OclAny.

Issue 1687: Collection operation size not defined for infinite collections (uml-rtf)

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

Summary:    It is not specified what the result is of the expression
 Integer.allInstances->size,
     neither of Real.allInstances->size.  This needs to be added to the OCL
 Specification.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Probably should support infinity, probably more than one kind.
Proposal
Fix as suggested in the Summary.

Issue 1689: Change events issue (uml-rtf)

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

Summary: Change events should be generalizable. For example, a traffic light
   changing to any color is a more general event than a change of that
   traffic light to Red only.  If the second event happens, then the
   first must have happened also.  A state machine with a trigger event
   on the first event will transition if the second event occurs.
 
   The semantics document says that an event can trigger transitions which
   have a more general event [p 113, UML 1.1 Semantics].
 
 
 Comments:
 
   This is close to issue # 29, "Events should be generalizable
   elements", which Rumbaugh filed and withdrew.  His reasoning is that
   signals are generalizable and event are just pointers to them, so it
   is not necessary for events to be generalizable.  In fact, events are
   more than pointers to signals, as shown in the event meta-model
   [figure 18, page 98, of UML 1.1 Semantics].  Events also cover call
   events, time events, and change events.

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 17, 1998: received issue
July 22, 1999: closed issue

Discussion:

Boolean conditions do not need generalization semantics. They work directly.

Issue 1691: It"s mistake to automatically flatten collections of collections (uml-rtf)

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

Summary: It"s a mistake to automatically flatten collections of
 collections.  This is noncompositional in that Set{1,2} means something
 different when it"s in one context (another set, say) than it means
 everywhere else.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 17, 1998: received issue
July 22, 1999: closed issue

Discussion:

Redefined OclAny so that collection types are not subtypes of OclAny. Only the basic (integer, etc.) types and the
types from the UML model are subtypes of OclAny.

Issue 1693: pre value of object (uml-rtf)

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

Summary: Why can"t one ask for the @pre value of a object that has
 been destroyed during execution?  Logically there"s no reason to prohibit
 this.

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 17, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1694: Need way to approximate comparisons (uml-rtf)

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

Summary: You"ll need some ways to do approximate comparisions
 if you want reals to be useful in practical specifications.

Resolution: Considered and declined.
Revised Text:
Actions taken:
July 17, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1695: Need to have relative precedence and, or, xor (uml-rtf)

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

Summary: You really need to have some relative precedence among
 and, or, xor and implies to have any hope of usefulness from these
 operators.
 You should also separate out the precedence of = and <> from the other
 comparisons

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
July 17, 1998: received issue
July 22, 1999: closed issue

Discussion:

Define the precedence.

Issue 1709: Text in Figure 2.13.7.1 ActivityState seems to be incorrect (uml-rtf)

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

Summary: In Figure 2.1 ActivityState is a specialization of SimpleState yet the text on page 2-135 in section 2.13.7.1 says "ActivityState is a SubmachineState".  The text seems correct,  ActivityState should be a specialization of SubmachineState.

Resolution: Redundant with #928.
Revised Text:
Actions taken:
July 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1710: Text on page 2-49 section 2.2 (uml-rtf)

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

Summary: In figure 2-13 Comment is a specialization of ModelElement.  Yet the text on page 2-49 section 2.6.2 says that "Comment is a subclass of ViewElement."  Also it mentions it has an association with a set of model elements.  Presumably it would have a text attribute to hold the comment as well.

Resolution:
Revised Text: Changed Comment to be a ModelElement and added a body:String attribute to it.
Actions taken:
July 22, 1998: received issue
July 22, 1999: Deferred to UML 1.3/2.0: Partially fixed in UML 1.3.
May 24, 2001: closed issue

Discussion:

Update text to say that Comment is a ModelElement. The attachment is through a Dependency. Note is a
PresentationElement.
Somehow the text attribute got omitted.
It should really be there as attribute body: String but it's too late now.
An implementor can either add it anyway or use the documentation tag to contain the text.
Resolution
Deferred to UML 1.3/2.0: Partially fixed in UML 1.3.
Attribute should be added in the future.

Issue 1781: OCL should allow the use of "let" expressions (uml-rtf)

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

Summary: OCL should allow the use of "let" expressions (for the sake of
 readability).
 
 Note: The lack of a "let" feature is also mentioned in the abstract for
 a paper on OCL at
 http://www.it.brighton.ac.uk/staff/Stuart.Kent/publications/UML98.html
 along with a number of other issues:
 
 "Specifically, the paper suggests that: the concept of flattening
 collections of collections is unnecessary, state models should be
 connectable to class models, defining object creation should be made more
 convenient, OCL should be based on a 2-valued logic, set subtraction
 should be covered more fully, and a "let" feature should be introduced."

Resolution: Redundant with issue# 1689.
Revised Text:
Actions taken:
August 6, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1789: Notion of "conceptual" or "specification-only" not supported (uml-rtf)

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

Summary: Currently UML fails to support the notion of "conceptual" or 
 "specification-only" features, i.e. features introduced only for the
 purposes of defining pre/postconditions and other constraints.
 
 This is extremely important to anyone doing formal class specifications
 from which we hope to generate code (e.g. us) and should be an easy matter
 to resolve.

Resolution: Considered and declined.
Revised Text:
Actions taken:
August 10, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1815: UML Semantics, section Common behavior (uml-rtf)

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

Summary: Attribute "body" of Metaclass "UninterpretedAction" is redundant to
 attribute "script" of Metaclass "Action"

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
August 13, 1998: received issue
July 22, 1999: closed issue

Discussion:

1. Script is redundant. Keep it in Action or just in UninterpretedAction. Some feeling that the other actions are
specific.
2. We apparently don't need LocalAction anymore.
Proposal
Delete LocalAction and UninterpretedAction::body.

Issue 1886: Rules 3 and 4 for Transitions in state machines should be limited (uml-rtf)

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

Summary: Rules 3 and 4 for Transitions in state machines should be limited
      to state machines, because these rules are overridden in the first
      rule for PseudoState in activity models. See Rule 3 and 4
      Transitions in State Machines: [p 118, UML 1.2 Semantics], and 
      Rule 1 of PseudoState in Activity Models: [p 138 UML 1.2,
      Semantics].

Resolution:
Revised Text: The following wf rules in the state machine chapter are modified to not apply to activity graphs: PseudoState 4, 6, and Transition 1, 3, 4.
Actions taken:
August 26, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed issue

Discussion:

Issue 1887: ClassifierInState does not satisfy one of its stated usages (uml-rtf)

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

Summary: ClassifierInState does not satisfy one of its stated usages, namely
     to be used as input to an action.  This would require that it have
     all the attributes and associations of its corresponding classifier.

Resolution: Witdrawn by submitter.
Revised Text:
Actions taken:
August 26, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1888: Activities operate by and on objects (uml-rtf)

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

Summary: The notation document says regarding object flow:
 
        Activities operate by and on objects. Two kinds of relationships
        can be shown: 1) The kinds of objects that have primary
        responsibility for performing an action and 2) the other objects
        whose values are used or determined by the action. These are
        modeled as messages sent between the object owning the activity
        model and the objects that are input or output by the actions in
        the model.  [section 3.80.1, p 130 Notation 1.2]
 
    Presumably the activity model doesn"t tell the objects being passed

Resolution: Clarified in UML 1.3
Revised Text:
Actions taken:
August 26, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1890: States leading to joins in activity models (uml-rtf)

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

Summary:   The semantics has the following statement regarding states leading
     to joins:
 
       If the ObjectFlowState leads into a join pseudostate, then the
       ObjectFlowState remains activated until the other predecessors
       of the join have completed [end of first paragraph of semantics of
       ObjectFlowState, p 139, UML Semantics 1.2].
 
     This behavior applies to all states leading to a join in
     an activity model, because of regions already exist implicitly when
     using joins in activity models.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
August 26, 1998: received issue
July 22, 1999: closed issue

Discussion:

Clarify that this is true for all states.

Issue 1921: Notation section describing activity states needed (uml-rtf)

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

Summary: There is no description of what an activity state should look like.  The specification needs a notation section describing activity states.

Resolution: Redundant with 1051.
Revised Text:
Actions taken:
September 1, 1998: received issue
July 22, 1999: closed issue

Discussion:

 received issue

Issue 1939: Existance of classes in classes (uml-rtf)

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

Summary: The UML Semantics Guide 1.1 (top of p.37) says "...a class acts as a namespace for contained classes...".  But the UML Notation Guide 1.1 (p. 23) only says "The name of a class has scope within the package in which it is declared...", i.e. it only speaks to classes that are directly contained in packages and is silent on the existence of classes within classes (Java"s "inner classes", or "nested classes" in C++) or how to represent them.

Resolution: Considered and declined.
Revised Text:
Actions taken:
September 8, 1998: received issue
July 22, 1999: closed issue

Discussion:

 received issue

Issue 1940: Section 5.17 of Notation Guide: No mapping is given (uml-rtf)

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

Summary: In Section 5.17 of the Notation Guide, the notation for an object is
 described as allowing the inclusion of particular states that the object
 is in, but no mapping is given. The obvious mapping is to use a
 ClassifierInState construct from activity modeling as a classifier of
 such an Object, but the well-formedness rule for Object on page 76 of
 the Semantics requires that all classifiers of Objects be Classes.
 A ClassifierInState is a kind of Classifier, but NOT a kind of Class, so
 its use is prevented in the metamodel.

Resolution:
Revised Text: Clarified mapping to ClassifierInState.
Actions taken:
September 9, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed isse

Discussion:

Issue 1943: Associations as parts of a composite. (uml-rtf)

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

Summary:    The notation says that associations may be parts of composites:
 
           The parts of a composition may include classes and
           associations. The meaning of an association in a composition
           is that any tuple of objects connected by a single link must
           all belong to the same container object. [p62, section 5.26.1
           Notation, UML 1.1, or p65, section 3.42.1 in UML 1.2]
 
       The above meaning of association as part is not recorded in the
       semantics.
 
       In any case, the definition prevents associations from having
       parts themselves.  When an association has parts, some parts must
       be associations that connect to objects outside the containing
       association.  See Bock & Odell in JOOP, Vol 11, No 5, September
       1998, also at:

Resolution:
Revised Text: Stated that a composite object can contain both objects and links as parts.
Actions taken:
September 10, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed issue

Discussion:

Issue 1945: Are subsystems instantiable? (uml-rtf)

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

Summary: The semantics document is contradictory on whether subsystems
          are instantiable. Comments: If a classsifier is instantiable, it should be allowed to have
           methods to implement calls to its operations at runtime.  In
           the case of subsystems, this may just translate to operation
           calls on it contained objects.  If subsystems are not supposed
           to have behavior of their own, then they should not be
           instantiable.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 11, 1998: received issue
July 22, 1999: closed issue

Discussion:

The UML 1.3 Semantics provides an isInstantiable attribute to state whether a Subsystem is instantiable or not.

Issue 1951: Abstract class inconsistencies (uml-rtf)

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

Summary: Issue: abstract class inconsistencies
 1) Figure 13 on page 67 shows the Action class as concrete.  The text on page 70 says Action is abstract.
 2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70 says Instance is abstract.
 3) Figure 8 on page 44 shows Comment as a subclass of ModelElement.  The text on page 44 states Comment is a subclass of ViewElement.

Resolution: Inconsistencies corrected in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1952: Diagram missing attributes (uml-rtf)

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

Summary: Issue: Diagram missing attributes
 1) The attributes of Action on page 68 do not include all of the attributes in the diagram on page 67. 
 2) The attributes of BehavioralFeature includes Name in the text on page 20, but is not in the diagram on page 16.  
 3) The attributes of Feature includes Name in the text on page 23, but is not in the diagram on page 16.  
 4) The attributes of Parameter includes Name in the text on page 27, but is not in the diagram on page 16.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1953: Issue: inheritance inconsistencies (uml-rtf)

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

Summary: Issue: inheritance inconsistencies
 1) The semantics document shows Component inheriting from Classifier on page 4, however the definition on page 45 indicates that it inherits from Class.  
 2) The semantics document shows Node inheriting from Classifier on page 44, however the definition on page 45 indicates that it inherits from Class.
 3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but the description on page 122 indicates that it inherits from SubmachineState.

Resolution: Inconsistencies corrected in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1954: missing association names (uml-rtf)

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

Summary: missing association names
 1) Very few of the associations have names, a required property of MOF metamodels.  Naming metamodel relationships also enhances model interchange.
 2) Many of the role names of associationEnds are missing. 
 3) The role name of Operation->Method is missing.
 4) Missing role name: Classifier<-Parameter, p16
 5) Missing role name: Binding->ModelElement, p43
 6) Missing role name: Node->Component, p44
 7) Missing role name: ModelElement<-Component, p44
 8) Missing role name: Enumeration<-EnumerationLiteral, p60
 9) Missing role name: MultiplicityRange->Multiplicity, p60
 10) Missing role name: Parameter->Signal, p66
 11) Missing role name: Action->ActionSequence, p67
 12) Missing role name: Request->Action, p67
 13) Missing role name: Argument->Action, p67
 14) Missing role name: Most of the associations, Fig 14, p67
 15) Missing role name: Most of the associations, Fig 15, p81
 16) Missing role name: Classifier->Instance, p90
 17) Missing role name: Most of the associations, Figs 17 and 18, p98
 18) Missing role name: Most of the associations, Fig 22, p121
 19) Missing role name: ModelElement->Package, p129

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Association names and role names were added to the physical model as recommended.

Issue 1955: Association attributes (uml-rtf)

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

Summary: Issue: association attributes
 The MOF does not support association attributes in metamodels.
 The following relationships have association attributes:
 1) Namespace contains ModelElement (ElementOwnership)
 2) ModelElement presents ViewElement (Presentation)  [removed in uml 1.2]
 3) Package contains ModelElement (ElementReference)

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Define a separate physical metamodel for the UML and XMI facilities.

Issue 1956: UML Semantics (page 109) (uml-rtf)

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

Summary: One improperly phrased rule in the UML Semantics manual (page
 109):
 	> 
 	> 	"The set of transitions that will fire is the maximal
 set that
 	> satisfies the following conditions..." (italics added)
 	> 
 	> Clearly, this should say a, not the.  There may be more than
 one such maximal set.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 15, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1966: Figure 2-18 : redundant attributes (uml-rtf)

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

Summary: n figure 2-18 an Action has the attribute isAsynchronous and the specialization of Action, CallAction has the attribute mode:SynchronousKind.  SynchronousKind is either: sk_synchronous or sk_asynchronous.  This seems redundant.
 
 Also the isAsynchronous flag is explained nowhere but it is used on page 2-84 as an attribute of Signal although it does not appear to be a member of Signal.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 16, 1998: received issue
July 22, 1999: closed issue

Discussion:

CallAction::mode has been removed in UML 1.3.

Issue 1986: Issue: abstract class inconsistencies (uml-rtf)

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

Summary: Here"s issue xmi1, which was generated by questions arising during work on the
 XMI SMIF submission.  Numbers refer to the UML 1.1 semantics document.
 
 Severity: Clarification
 Issue: abstract class inconsistencies
 1) Figure 13 on page 67 shows the Action class as concrete.  The text on page
 70 says Action is abstract.
 2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70
 says Instance is abstract.

Resolution: Clarified in UML 1.3 physical model.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1987: Issue: Name attribute inheritance (uml-rtf)

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

Summary: Here"s issue xmi2, which was generated by questions arising during work on the
 XMI SMIF submission.  Numbers refer to the UML 1.1 semantics document.
 
 Severity: Clarification
 Issue: Name attribute inheritance
 Please clarify that the Name attribute is inherited from ModelElement and not
 redefined in these cases.
 1) Parameter on page 27
 2) Feature on page 23
 3) BehavioralFeature on page 20
 4) Association on page 17
 
 If Name is redefined, the diagrams should include them.

Resolution: Clarified in UML 1.3 physical model.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1988: Issue: Action does not define attributes (uml-rtf)

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

Summary: Here"s issue xmi3, which was generated by questions arising during work on the
 XMI SMIF submission.  Numbers refer to the UML 1.1 semantics document.
 
 Severity: Clarification
 Issue: Action does not define attributes
 The textual description of Action on page 68 does not defne all of the
 attributes in the diagram on page 67.

Resolution: Clarifed in UML 1.3.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1989: Issue: Inheritance inconsistencies (uml-rtf)

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

Summary: Here"s issue xmi4, which was generated by questions arising during work on the
 XMI SMIF submission.  Numbers refer to the UML 1.1 semantics document.
 
 Severity: Clarification
 Issue: inheritance inconsistencies
 1) The semantics document shows Component inheriting from Classifier on page 4,
 however the definition on page 45 indicates that it inherits from Class.
 2) The semantics document shows Node inheriting from Classifier on page 44,
 however the definition on page 45 indicates that it inherits from Class.
 3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but
 the description on page 122 indicates that it inherits from SubmachineState.
 4) Figure 8 on page 44 shows Comment as a subclass of ModelElement.  The text
 on page 44 states Comment is a subclass of ViewElement.

Resolution: Inconsistencies corrected in UML 1.3. (Mostly redundant with issue 1953.)
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1990: Issue: Missing role names (uml-rtf)

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

Summary: Severity: Minor
 Issue: missing role names
 
 Very few of the association roles have names, which are needed for model
 interchange.
 Here is the convention being considered in XMI for providing those names.
 1) Start with the role name.
 2) If the role name is missing, use the association name
 3) If the association name is missing or a generated name (see xmi6), use the
 class name
 4) If the name is a duplicate, use the Class name appended with a number,
 counting up from 2.

Resolution: Clarified in UML 1.3 physical model.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1991: issue: Missing association names (uml-rtf)

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

Summary: Severity: Minor
 Issue: missing association names
 
 Most of the associations are missing names, which are useful for model
 interchange.
 Here is the convention being considered in XMI for providing those names.
 1) Identify the names of the classes on each end.
 2) The "first" class is the one with the name that is lexigraphically first.
 3) Concatenate the two class names together, separated by an underscore (_)
 character. First_Second.
 4) Duplicates have a number appended, starting with 2.
 
 An example association name is Method_Operation (and not Operation_Method).

Resolution: Clarified in UML 1.3 physical model.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1992: MOF does not support association attributes in metamodels. (uml-rtf)

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

Summary: Severity: Minor
 MOF does not support association attributes in metamodels.
 The following relationships have association attributes:
 1) Namespace contains ModelElement (ElementOwnership), p16
 2) ModelElement presents ViewElement (Presentation), p44
 3) Package contains ModelElement (ElementReference), p129
 
 Please describe the proposed MOF mapping if the association attributes are to
 be retained in UML.

Resolution: Redundant with issue 1955.
Revised Text:
Actions taken:
September 22, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1995: Core package-backbone diagram (uml-rtf)

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

Summary: The "Core Package-Backbone" diagram shows, on the Association
 between Classifer and StructuralFeature, that the "feature" 
 AssociationEnd is ordered.  Ordering is neither wanted nor
 feasible for this end.  What ordering would be applied to the
 set of Attributes that given Class or DataType types?  The order
 in which they are defined is the only conceivable ordering, which
 doesn"t seem very valuable.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 24, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 1999: UML RTF Issue: Normative MOF-Compatible version of UML (uml-rtf)

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

Summary: UML RTF Issue: Normative MOF-Compatible version of UML
 Severity: Critical
 
 1) The UML RTF must produce a normative version of UML which is MOF-compatible.
 2) This normative representation should be in Rose (or equivalent) and SMIF
 form in the event that a SMIF submission is adopted.
 3) In the event that XMI is adopted as the SMIF technology, the normative XMI
 form of UML is a generated XMI document and DTD.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 29, 1998: receivedissue
July 22, 1999: closed issue

Discussion:

The UML physical model used to generate the IDL and XMI facilities satisfies this requirement.

Issue 2001: Not instantiable (uml-rtf)

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

Summary: There does not appear to be a definition of "instantiable."
 
 If "not instantiable" means can not have instances in a model, then some
 model elements should be instantiable, which are currently specified to
 be not instantiable.
 
 If "not instantiable" means can not have instances in a running system,
 but may have instances in a model, then this should be made clear.

Resolution:
Revised Text: Added text to clarify each use of the word "instantiable".
Actions taken:
September 26, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed issue

Discussion:

Issue 2004: Asynchronous action (uml-rtf)

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

Summary: An asynchronous action is defined as a request where the sending object does not pause to wait for results. Synonym: asynchronous request [OMA]. 
 
 1) What results?
 In the OMA v3 (June 13 1995), it is said on p. 78 that 
 an asynchronous request has no response (hence no results). 
 So, soes "results" means "response", or something else ?
 
 2) The OMA speaks also of a deferred synchronous request -- 
 proceed after sending request; claim reply later). 
 The synonym used is confusing since the OMA has a concept of 
 deferred synchronous request in which the sending object does 
 not pause to wait for results (proceed after sending request; 
 claim reply later). 
 
 3) In fact, my understanding is that the sending object does not 
 even pause to wait for the receiving object to be notified of
 the request.  The definition is silent about this.

Resolution: Previously considered for 1.4 and closed w.o. change
Revised Text:
Actions taken:
September 28, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
October 23, 2002: closed issue

Discussion:

Previously considered for 1.4 and closed w.o. change.

Issue 2006: Synchronous request (uml-rtf)

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

Summary:  synchronous request is defined as a request where the client object 
 pauses to wait for completion of the request.
 
 1) My understanding of CORBA is that a request is only synchronous 
 with respect to a given thread. Is this true?
 - So, does the sending *client* truly pause to wait for results? 
 - Or is it just a *thread* of that client that pauses for results?
 
 Deferred synchronous request (mentioned on p.78) has not been 
 defined.

Issue 2011: ModelElement to Partition multiplicity should be many (uml-rtf)

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

Summary: Partitions in various activity models may reuse the same model
          element.  So the multiplicity of the association from
          ModelElement to Partition should be *.
 
 Comments:
 
 Proposal: Change multiplicity of association from ModelElement to Partition
           from 0..1 to * [p 121, Figure 22, Activity Model, Semantics,
           or p134 in UML 1.2].

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

 Change multiplicity of association from ModelElement to Partition

Issue 2012: Notation says swimlanes are packages (uml-rtf)

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

Summary:    The notation guide has a couple descriptions of swimlanes as
     packages, even though swimlanes are not mapped to packages.
     References:
 
         If an object lifeline is not shown, then some object within the
         swimlane package is responsible for the action, but the object
         is not shown. [p 127, section 10.5.2, Notation, or p 130 in UML
         1.2]
 
         Actions may be organized into swimlanes. Swimlanes are a kind of
         package used to organize responsibility for activities within a
         class. [p 125, section 10.4.2, Notation, or p 128 in UML
         1.2]

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

A swimlane maps into a Partition of the States in a Activity Graph.

Issue 2013: Need well defined way to extend OCL (uml-rtf)

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

Summary: Because no predefined set of operations will cover all cases needed in
     practical situations it s important that there is a well-defined way
     to extend OCL.
 
     It is possible to define all predefined OCL types within one predefined UML
 package
     end define package extension mechanisms to add extensions to OCL.
     The current OCL specification doesn"t disallow that, but it should
     be explained explicitly how this can be done.

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

An implicit default package named UML_OCL has beed defined, containing all predefined OCL types. A special
stereotype import from any package may replace the default OCL package with the imported one. Any replacement
should be a proper extension of the UML_OCL package.

Issue 2014: Add OCL operation to refer to all new instances created during operation (uml-rtf)

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

Summary:    There is no simple way currently in OCL to refer in a postcondition to the
 new instances created
     during the operation. The current solution is:
        Person.allIstances  - Person.allInstances@pre
     Since this is commonly used, a simper way to denote this will be
 bened=ficial.
     We propose to add an operation "new" or "created" to OclType, which can ony
 be used
    in postconditions and has the meaning describd above.  We can then write:
     Person.new  or Person.created

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

AllInstances has semantic problems, which will be identical to allNewInstances as proposed here. Instead the
operation oclIsNew has been defined to check to see if a specific instance has been created.
Proposal
Added ockIsNew to OclAny, which allows one to check a specific object to see if it has been created during an
operation.

Issue 2015: Common operations should be added to collection types in OCL (uml-rtf)

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

Summary: A number of common operations should be added to the collection
     types in OCL. These are:
 
     Collection(T) :
         any( <boolean-expression> ) : T
             returns any element which satisfies <boolean-expression>
         one( <boolean-expression> ) : Boolean
             returns true if thee is exactly one element that satisfies
             <boolean-expression>
         theOne( <boolean-expression> ) : T
             returns the single element which satisfies <boolean-expression>
 
     and maybe others as well.

Resolution:
Revised Text: Collection operation 'any()' has been added as standard operation.
Actions taken:
September 30, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
May 24, 2001: closed issue

Discussion:

 Boolean

Issue 2016: Add "Let"-like construct to OCL (uml-rtf)

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

Summary:  Currently if a sub-expression within an OCL expression is
     used twice or more, you need to spell it out each time.  This
     is cumbersone, eror-prone and it also disguises to the reader
     of the constraint that these sub-expressions are in fact identical.
 
     The proposal is to add a construct to OCL, that allows one
     to define a variable which holds the value of such a sub-expression.

Resolution: Redundant with issue 1788.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 2017: Set of allInstances should be referrable by the class name (uml-rtf)

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

Summary: ances of a class, as
    in "Person.allInstances".   It is quite common in many area"s to use the
 class name for this collection.
    To get the size of the collection of persons we now need to write:
        Person.alllnstances->size"
    With the proposes change we can write:
        Person->size
    which is a shorthand for the use of allInstances.

Resolution: rejected
Revised Text: This introduces an ambniguity where the classname can be use as a collection of all instances or as the sorce for the class operations and attributes.
Actions taken:
September 30, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
October 23, 2002: closed issue

Discussion:

This introduces an ambiguity where the classname can be use as a collection of all instances or as the sorce for the class operations and attributes. Previously considered for 1.4 and closed w.o. change.

Issue 2018: Infix operator use should be clarified (uml-rtf)

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

Summary: Infix operators like "+" and "<" etc. are defined for built-in OCL types.
 It is not explained whether you can
     use these for user defined types.  The proposal is to allow infix notation
 for all of the
     operators defined in OCL for used-defined types as well.  If someone
 defines  the operation
          "+(p : Person)"
     on type Person, this can be used in OCL by
          somePerson + anotherPerson.
     instead of just by
         somePerson.+(anotherPerson)
     The OCL specification is not clear whether this is allowed or not.

Resolution: Clarified in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

Clarify how to define and use infix operation in UML, to be useable in OCL.

Issue 2021: Definition of OclAny leads to problems when formalizing OCL (uml-rtf)

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

Summary:  OclAny is essentially a type of all types.  In particular,
    section 5.13 of the OCL specification implies that Set(OclAny)
    is a subtype of OclAny, from which a version of the Russell
    Paradox promptly follows.
 
    This needs to be clarified/resolved in the specification

Resolution: Fixed in UML 1.3.
Revised Text:
Actions taken:
September 30, 1998: receive dissue
July 22, 1999: closed issue

Discussion:

Redefine OclAny, such that it is not a supertype of the collection types. This solves Russell Paradox.

Issue 2022: There are issues that make OCL hard to formalize--document ad/98-10-01 (uml-rtf)

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

Summary: There are a number of issues that make OCL hard to formalize.  The attached
     document is a draft of a research into formalizing UML/OCL.  It contains
     a number of issues on OCL.  Instead of making all of these into separate
     issues, the document is attached and all problems described in there are
     hereby submitted as one (rather big) issue. This document will be posted as ad/98-10-01 on the OMG document server

Resolution: Redundant with issue 2013.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 2024: Generalized change events (uml-rtf)

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

Summary: The expressive power of change-events is limited.  We are writing a
 specification that is much simpler if we can trigger transitions under a
 circumstance like the following:
 
 	"P has just become true and it is not the case that Q has just
 become true"
 
 There"s no way to say that with a change-event. Instead we have to write a
 somewhat obscure sequence of transitions that defines a program to calculate
 this.

Resolution: Considered and declined.
Revised Text:
Actions taken:
September 30, 1998: received issue
July 22, 1999: closed issue

Discussion:

Issue 2071: BooleanExpression written in OCL or some other language? (uml-rtf)

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

Summary: In the current metamodel, it is not unambiguously defined whether
     a BooleanExpression is written in OCL or in some other language.
     With tool vendors developing OCL tools, it is important to be able
     to state exactly whether an Expression is written in OCL or not.

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
October 13, 1998: received issue
May 24, 2001: closed issue

Discussion:

Issue 2073: Widen the naming characteristics (uml-rtf)

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

Summary: The OCL prescribes certain characteristics of names of classes,
     attributes, etc. Clas anmes must start with uppercase, attributes
     start with lowercase, etc.
     It would be more flexible if these restrictions could be widened.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
October 13, 1998: received issue
May 24, 2001: closed issue

Discussion:

Issue 2074: Some attributes can be expressed in OCL (uml-rtf)

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

Summary: At several places in the UML metamodel there are attributes of type
     "...Expression".  Some of these might be specified in OCL.  This should be
     stated in the metamodel. The OCL specification should expicitly describe the
     meaning and context of such an OCL expresion.
     Examples are:
       Action:      attribute   target           : ObjectSetExpression
       Argument:    attribute   value            : Expression
       ChangeEvent: attribute   changeExpression : BooleanExpression
 
     Especially the last one should be expressable in OCL, since it is
     a Boolean Expression.

Resolution:
Revised Text:
Actions taken:
October 13, 1998: received issue
October 23, 2002: closed issue

Discussion:

Issue 2279: Metamodel and semantics for aggregations (uml-rtf)

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

Summary: The metamodel and semantics for aggregations is still causing me
 much concern. Primarily, it is stated that black diamond (composition)
 must have linked lifetimes and dependencies between part and whole.
 This means that the parts are NOT separable from the whole. It also states
 that whilst there is only one owner that owner may be changed. This means
 that the parts MUST BE separable from the whole. This is a contradiction.

Resolution:
Revised Text: Reworded to make clear that owner has responsibility for parts but parts can be explicitly detached from owner. Removed references to "coincident lifetime" semantics from notation and glossary.
Actions taken:
December 22, 1998: received issue
May 24, 2001: closed issue

Discussion:

Issue 2280: On aggregation. The white diamond name should be "shareable" (uml-rtf)

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

Summary: On aggregation. The white diamond name should be "shareable"
 not "shared" because it really indicates the ability to be shared not
 the notion that it IS necessarily shared.
 submit: Submit Issue Report

Resolution:
Revised Text: The words have been changed to a more complete phrasing.
Actions taken:
December 22, 1998: received issue
May 24, 2001: closed issue

Discussion:

Issue 2281: Use of black diamond in the metamodel (uml-rtf)

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

Summary: Use of black diamond (even when semantics are pinned down) in the metamodel e.g. Classifier
 as a composition of Feature is not convincing. The ideas of lifetime
 interlinking seems not necessarily to be the case for many of the metamodel
 uses of black diamond. Similarly for Transition as a composition of
 Guards in the STD.

Resolution:
Revised Text: The semantics of composition have been restated, The rest of the submitted issue is a matter of opinion and is therefore declined.
Actions taken:
December 22, 1998: receive dissue
May 24, 2001: closed issue

Discussion:

Issue 2282: Only single stereotyping is supported (uml-rtf)

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

Summary: Only single stereotyping is supported. Multiple partitioning and
 therefore multiple partitioning would be usefully and easily added

Resolution:
Revised Text: Multiple stereotypes can now be assigned to a ModelElement
Actions taken:
December 22, 1998: received issue
May 24, 2001: closed issue

Discussion:

Issue 2283: Interface issue (uml-rtf)

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

Summary: Interface is a kind ofclassifier and therefore has features - but it
 supposedly only has operations

Resolution: rejected
Revised Text: Bad reasoning. It chooses not to use the attributes potentially available to Classifier. Don't go misapplying the LSP.
Actions taken:
December 22, 1998: received issue
May 24, 2001: closed issue

Discussion:

Bad reasoning. It chooses not to use the attributes potentially available to Classifier. Don't go misapplying the LSP. Previously considered for 1.4 and closed w.o. change.

Issue 2284: Add Responsibilities as a new metatype (uml-rtf)

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

Summary:  I would again propose that Responsibilities are added as a new metatype.
 After all Relationship  is about to be added in Version 1.3 so I would
 suggest respectfully that the easy addition of one metaclass (Responsibility)
 and two metalevel association relationships (from Classifier to
 Responsibility and from Responsibility to Feature) would be highly
 beneficial and very easily changed in the metamodel. Notational support
 is no problem since (as I have discussed with Grady) is just the addition
 of a new box under the class icon.

Resolution:
Revised Text: Responsibilities have no semantics and can easily be modeled as tagged values or comments.
Actions taken:
December 22, 1998: received issue
May 24, 2001: closed issue

Discussion:

Responsibilities have no semantics and can easily be modeled as tagged values or comments. Previously considered for 1.4 and closed w.o. change.

Issue 2292: UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99 (uml-rtf)

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

Summary: In the current version of UML, use cases must not have associations to other use cases specifying the same entity. Use cases can exchange messages only with actors and not with each-other. UML use cases are always initiated by a signal from the actor.  
 
 However, there are use cases that are initiated by a system if a specific condition is met. Example: in the well-known ATM machine example the use case "dispense cash" is initiated by the system, if the customer request was evaluated as valid. The use case "dispense cash" is not initiated by the (user) actor.  In other words, the use case "dispense cash" receives a message or signal from the other use case specifying the same system. Therefore, the association between use cases must exist. 
 
 Solution: Allow associations between use cases specifying the same entity.

Resolution: rejected
Revised Text: in the well-known ATM machine example the use case "dispense cash" is initiated by the system, if the customer request was evaluated as valid. The use case "dispense cash" is not initiated by the (user) actor. In other words, the use case "dispense cash" receives a message or signal from the other use case specifying the same system. Therefore, the association between use cases must exist.
Actions taken:
January 6, 1999: received issue
October 23, 2002: closed issue

Discussion:

Previously considered for 1.4 and closed w.o. change.  In the given example, either the 'bank system' is a second actor initiating the dispense use case, or the dispense use case is part of the withdrawal use case initiated by the customer. There are two modeling solutions to this problem without revising UML. From the actor's point-of view (the outside level), the system action "dispense cash" would only be a step in the "withdraw cash" use case, possibly modeled as an included use case of the "withdraw cash" use case. At a lower level, the action "dispense cash" could be modeled as a use case, but then it is probably initiated by the subsystem that determines it is appropriate to dispense the cash. In each approach, the use case should be initiated by an actor at its own level.

Issue 2293: action state symbol/state symbol difficult to distinguish when drawn by ha (uml-rtf)

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

Summary: Summary: The action state symbol and the state symbol differ only in the convexity of their vertical sides. Therefore, it is difficult to distinguish between them, if the diagram is drawn by hand. The symbols have different semantics and both of them can appear in a single diagram (activity diagram). Therefore, it is necessary to clearly distinguish between the symbol for the state and the symbol for the action state.

Resolution: Previously considered for 1.4 and closed w.o. change
Revised Text:
Actions taken:
January 6, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2294: Dependencies (and other relationships) with role ends (uml-rtf)

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

Summary: Dependency relationship in UML does not have role ends, similar to the association ends that associations have. Therefore, it is not possible to specify, for example, that: 
 
 1. an entity depends on an ordered set of other entities.   
 2. an entity depends on a specified number of instances of other entities 
 3. the roles of the entities that participate in the dependency. Dependency imply the entity roles "client" and "supplier". However, I often came across situations where I needed to specify more concrete roles than "client" and "supplier". In cases I came across, replacing dependencies by associations was not a convenient solution.

Resolution:
Revised Text: Dependencies are between elements and don't apply to instances. Associations are for relationships whose semantics apply to instances.
Actions taken:
January 6, 1999: received issue
May 24, 2001: closed issue

Discussion:

Dependencies are between elements and don't apply to instances. Associations are for relationships whose semantics apply to instances. Previously considered for 1.4 and closed w.o. change.

Issue 2295: UML has symbol for multiobject, not for multi-instances of other classifie (uml-rtf)

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

Summary: UML has a symbol for multiobject. However, UML does not have any specific symbol for multiple instances of a component, node, subsystem, interface, actor, use case and collaboration. Adding these symbols to UML will maintain symmetry and therefore, simplicity of the notation.

Resolution: declined
Revised Text: There are already a lot of symbols and multi-instances of other elements do not seem important enough to justify adding more symbols, symmetry notwithstanding.
Actions taken:
January 6, 1999: received issue
May 24, 2001: closed issue

Discussion:

There are already a lot of symbols and multi-instances of other elements do not seem important enough to justify adding more symbols, symmetry notwithstanding. Previously considered for 1.4 and closed w.o. change.

Issue 2298: Package symbol as a polygon (uml-rtf)

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

Summary: A package is a grouping of model elements. However, the rectangular shape of the package symbol makes it difficult to group model elements that have fixed geometrical position to each-other. In other words, the rectangular package shape often requires to change geometrical position of the model elements that belong to the group. It is almost impossible to use the rectangular package to show overlapping groups of model elements.  
 
 For example, it is difficult to use the rectangular package symbol to show the objects in a class diagram that belong to a certain thread, or to show the use cases in a use case diagram that belong to a certain group.

Resolution: declined
Revised Text:
Actions taken:
January 7, 1999: received issue
May 24, 2001: resolved issue

Discussion:

Previously considered for 1.4 and closed w.o. change.

Issue 2305: OCL should allow one constraint to reference another (uml-rtf)

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

Summary: OCL should allow one constraint to reference another (e.g. by name) to avoid
 redundancy in a specifiation and errors related to maintenance of separate constraints
 that should be the same.

Resolution: declined
Revised Text: The Let construct solves this in a more structural way
Actions taken:
January 15, 1999: received issue
May 24, 2001: closed issue

Discussion:

"The Let construct solves this in a more structural way. 
Previously considered for 1.4 and closed w.o. change. "

Issue 2339: Wording od OCL definition (uml-rtf)

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

Summary: Some minor flaws in the wording of the OCL description within OMG-UML
 version 1.3, Jan. 1999:
 
 
 ** Section 6.4.4, Type Conformance, page 6-222
 
 	"Each type conforms to its supertype." 
 
 The word "its" implies that there is only one. It would be better if this
 said: "Each type conforms to each of its supertypes."
 
 
 ** Section 6.4.5, Re-typing or Casting, page 6-223
 
 	"If the actual type of the object is not equal to the type to which
 it is re-typed, the expression is undefined."

Resolution:
Revised Text:
Actions taken:
January 19, 1999: received issue

Discussion:

Issue 2510: There is an association between between Constraint and ModelElement (uml-rtf)

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

Summary: The end of the association which is opossite to ModelElement is named as "stereotypeConstraint". I sugesst to rename it to "constraint" or "elementConstraint".
 The name "stereotypeConstraint" is somewhat misleading. issue from Constantine Plotnikov (cap@novosoft.nsc.ru)

Resolution:
Revised Text: The relationship is actually named �constraint� in UML1.3 and UML1.4. The end of the association which is opposed to Stereotype is named StereotypeConstraint, in UML1.3 and UML1.4.
Actions taken:
March 4, 1999: received issue
May 24, 2001: closed issue

Discussion:

The relationship is actually named  �constraint� in UML1.3 and UML1.4. The end of the association which is opposed to Stereotype is named StereotypeConstraint, in UML1.3 and UML1.4. Previously considered for 1.4 and closed w.o. change.  Previously considered for 1.4 and closed w.o. change.

Issue 2544: OCL Standard package (uml-rtf)

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

Summary: resolving the issue of extensibility of OCL (like adding an operation to a
 predefined
 OCL type) I have written a new section in the OCL chapter.  It describes
 the
 existence of a default package in each UML model, containing the predefined
 OCL
 types.  I have chosen to name this package "UML_OCL" (or StandardOCL, ...).
 
 Typically, the modeler will define its own OCL package (named e.g. MyOCL),
 import
 the standard OCL package (import UML_OCL) and extend the predefined OCL
 types
 to his/her liking. A like approach is taken in Catalysis.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 16, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2546: (Minor) Activity diagram change recommendation (uml-rtf)

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

Summary: I know it"s late in the game, but in my use of activity diagrams for
 modeling algorithms, a minor change has become apparent. Specifically, it
 is possible to have objects "flow" from one activity state to another, but
 it is not possible to show a persistent object which is modified by some
 activity states and used by others. I therefore recommend the following change:
 
 Activity states be able to depend on objects with stereotypes for <<use>>
 and <<modify>>. In this case, control flow among the activity states must
 be shown since the "data object" does not flow between activity states but
 exists in an enclosing structural context.

Resolution:
Revised Text: A new tag called "usage" is added to transitions that have an ObjectFlowState as source or target. The tag value indicates whether the action of the state at the other end of the transition modifies or only reads the flowing object.
Actions taken:
March 16, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2566: The second postcondition on Integer::div is incorrect (uml-rtf)

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

Summary: The second postcondition on Integer::div is incorrect.  It currently reads:
 
 
     i.div( i2 : Integer) : Integer
 
     The number of times that i2 fits completely within i.
 
     post: result * i2 <= i
     post: result * (i2 + 1) > i

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2567: The postcondition on set::collect seems to be incorrect (uml-rtf)

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

Summary: The postcondition on set::collect seems to be incorrect.  It currently reads:
 
 
     set->collect(expression : OclExpression) : Bag(expression.oclType)
 
     The Bag of elements that results from applying expr to every member of set.
 
     post: result = set->iterate(elem; acc : Bag(T) = Bag{} | acc->including(expr) )
 
 
 
 The type of acc is wrong, and it should read:
 
 
     post: result = set->iterate(elem; acc : Bag(expression.oclType) = Bag{} | acc->including(expr) )
 
 
 Note that the same goes for Bag::collect on page 6-41.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2568: The postcondition seems to be incorrect for sequence::subSequence (uml-rtf)

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

Summary: The postcondition seems to be incorrect for sequence::subSequence.  It currently reads:
 
 
     sequence->subSequence(lower : Integer, upper : Integer) : Sequence(T)
 
     The sub-sequence of sequence starting at element number lower, up to and including element number upper.
 
     post: if sequence->size < upper then
         result = Undefined
     else
         result->size = upper - lower + 1 and
         Sequence{lower..upper}->forAll( index |
         result->at(index - lower + 1) =
         sequence->at(lower + index - 1))
     endif
 
 
 The indexing is incorrect.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2569: page 6-10 of OCL documentation for 1.3alphaR5 (uml-rtf)

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

Summary:  page 6-10 of OCL documentation for 1.3alphaR5
 
 I notice that not equals <>, the pathname operator :: and the @pre operator are not listed in the precedence table, and so I guess, technically, their precedence is undefined.
 
 You could also put parentheses at the top of the table as well, of course, to make that table more complete and stand-alone.  Parentheses would then not need to be described in a sentence following the list.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2570: pages 6-28 to 6-29 of OCL documentation (uml-rtf)

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

Summary: pages 6-28 to 6-29 of OCL documentation
 
 Trivial point - For consistency, the Real operators +, -, * and / should take a parameter called r2, not r1.  This seems to be the convention used elsewhere throughout the document, and makes the point that they are the second real number in the expression.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2571: Divide operator is incorrect (uml-rtf)

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

Summary: Under the "Real" type on page 6-29, the divide operator is incorrectly
 written as an asterisk instead of a forward slash.
 
 I am not sure if this is just a typo, computer glitch, or error in translating the document to Acrobat format or something weird like that.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2572: The not-equals operator, "<>", (uml-rtf)

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

Summary: The not-equals operator, "<>",  seems to be listed for Enumerations, but not for Reals (page 6-27), Integers (p 6-29), Booleans (p 6-31) or Strings (p 6-30), even though it seems to be used in many places elsewhere in the specification.
 
 All the other operators seem to be there (equality, less than, etc.), so I think this one should be as well (although you can simulate it using "not").
 
 Note that inequality is defined for OclAny, but then so is equality.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2573: Error in the third postcondition for String::concat on page 6-31 (uml-rtf)

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

Summary: There seems to be an error in the third postcondition for String::concat on page 6-31.  It says:
 
 
 post:  result.substring(string.size + 1, string2.size) = string2
 
 
 It should read:
 
 
 post:  result.substring(string.size + 1, string.size + string2.size) = string2

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
March 29, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2626: Strange GENERAl USE RESTRICTION (uml-rtf)

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

Summary: "The owners of the copyright in the UML specification version 1.2 [sic, in
 1.3alpha5] hereby grant you a [...] license [...] to create and distribute
 software which is based upon the UML specifications [...]
 
 Software developed under the terms of this license must include a complete
 implementation of the current version of this specification [...]"
 
 This appears to say that any UML-based CASE tool must implement the whole
 of the standard. Since as far as I"m aware no existing tool, including
 Rational Rose, comes even close to doing this, should not the restriction
 be changed? (I do not suggest that it should be enforced!)

Resolution: fixed in UML 1.3
Revised Text:
Actions taken:
May 3, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2786: OCL issue (uml-rtf)

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

Summary: Descriptor:
 symbols such as +, - or * in the name of a feature in Ocl expressions 
 are not allowed.

Resolution:
Revised Text: Was already fixed in UML 1.3, no changes in 1.4
Actions taken:
June 30, 1999: received issue
May 24, 2001: closed issue

Discussion:

Issue 2837: role concept in UML remains rather vague (uml-rtf)

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

Summary: Roles play a dual role in UML. On one hand, a role is the name of an association end [UML, � 2.5.2] and thus nothing more than the name of place of a relation. On the other hand, UML has a notion of roles specified in the context of collaborations [UML, 2.10]. This notion conflicts with the first one since a single role of the collaboration may have different role names assigned by the different associations it participates in. In other words, the associations of a collaboration may assign different role names to their ends (and thus, to the classifiers at the ends) than assigned by the collaboration directly, potentially leading to a clash of role names.
 
 Overall, the specification of the role concept in UML remains rather vague. It seems that classifier roles only indirectly specify the base classifiers whose instances can play the roles: "In fact, since an instance may originate from several classifiers (multiple classification), a classifier role may have several base classifiers." (but where are these specified?) and "However, since the only requirement on conforming instances is that they must have attribute values corresponding to the attributes specified by the classifier role, and must participate in links corresponding to the association roles connected to the classifier role, they may be instances of any classifier meeting this requirement." [UML, 2.10.4]. And finally "Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent"s roles; it is enough that they contain all the required features." This is certainly a very unusual feature in a typed language such as UML.
 
 So what are roles? It seems that in UML they are not types (or classifiers), but a positive definition (other than the equally vague glossary entry) would seem imperative!

Resolution: resolved
Revised Text: "In fact, since an instance may originate from several classifiers (multiple classification), a classifier role may have several base classifiers." (but where are these specified?) and "However, since the only requirement on conforming instances is that they must have attribute values corresponding to the attributes specified by the classifier role, and must participate in links corresponding to the association roles connected to the classifier role, they may be instances of any classifier meeting this requirement." [UML, 2.10.4]. And finally "Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent"s roles; it is enough that they contain all the required features." This is certainly a very unusual feature in a typed language such as UML.
Actions taken:
August 11, 1999: received issue
May 24, 2001: closed issue

Discussion:

The term role is used in e.g. collaborations and associations with different but will-defined semantics

Issue 2850: Generalization should be meta-metamodel element (uml-rtf)

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

Summary: UML 1.3 Metamodel Semantics
 
 Generalization should be meta-metamodel element
 
 It is a generally accepted fact that generalization is a second order
 relation, ie, a relation whose elements (instances) are pairs of
 *types* (classifiers, or whatever). Associations, by contrast, are
 first order: their elements are tuples of *objects* (individuals,
 etc.). 
 
 UML is based on a four-layer metamodel structure, including metamodel 
 and meta-metamodel layers. Why, then, do Generalization and 
 Association appear on the same layer, namely the metamodel? Much more 
 troublesome: How can they be specializations of the same 
 generalization, namely Relationship? Together with the defined 
 implication of generalization: "The more specific element is fully 
 consistent with the more general element (it has all of its 
 properties, members, and *relationships*) ..." [UML 1.3, sect. 2.5.2] 
 this leads to a paradox, because generalization itself would be 
 inherited. The paradox would be avoided, however, if generalization 
 were a relation of the meta-metalayer.

Resolution: declined
Revised Text: We do not agree at all with this reasoning.
Actions taken:
August 13, 1999: received issue
May 24, 2001: closed issue

Discussion:

Previously considered for 1.4 and closed w.o. change.

Issue 2921: Use of interfaces in associations (uml-rtf)

Click here for this issue's archive.
Source: University of Frankfurt (Mr. Thomas Behrens, behrens(at)dbis.informatik.uni-frankfurt.de)
Nature: Uncategorized Issue
Severity:
Summary:

The issue / problem relates to the use of interfaces in associations, i.e.
the "type" association in the meta model between AssociationEnd and
Classifier.

Besides the use of a syntactical interface specification, I use the
interfaces as well as the location to provide semantics, using OCL.

OCL provides a well-defined way to navigate along association ends. Where
actually interfaces would provide the semantic context for association ends,
I have to refrain from specifiying those on the interface, but have to defer
this association to the realizing class.

As an alternative it is possible to provide getter and setter operations
providing access to the association ends in the deferred implementation. But
this presents two other problems:
a) this public (as no other ones are allowed) operation on the interface
will need to be realized any realizing class (and I do not always want to
compromise this information)
b) the return value of the operation (in case of a multiplicity > 1) will
not per se have the same OCL "accessibility" as an association end;
furthermore tools - at this point in time - provide significant better
control in terms of verification for associations than for operation
parameters / return values.

Resolution: rejected
Revised Text: Associations relate things that can actually exist, that is, classes. The arguments about OCL access are peripheral and should be directed to OCL.
Actions taken:
September 27, 1999: received issue
May 24, 2001: closed issue

Discussion:

Associations relate things that can actually exist, that is, classes. The arguments about OCL access are peripheral and should be directed to OCL.. Previously considered for 1.4 and closed w.o. change.

Issue 3098: OCL Error (uml-rtf)

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

sUnique for Collections is defined as follows:
>>
>>collection->isUnique(expr : OclExpression) : Boolean
>>   post: result = collection->collect(expr)->forAll(e1,e2 | e1<>e2)
>>
>>Unfortunately, if the collection is not empty, this expression
>>always evaluates to false. This is due to the fact that in a
>>forAll over two iterators, both iterate over the full collection.
>>Therefor, for each element in the collectionen , there is a
>>step where both itereters point to this element, but at this
>>point, e1 <> e2 evaluates to false.
>>
>>My suggestion for the definition of isUnique would be as follows:
>>
>>collection->isUnique(expr : OclExpression) : Boolean
>>   post:
>>     let res = collection->collect(expr) in
>>       result = res->forAll(e $|$ res->count(e) = 1)
>>
>>This expression states, that each element in the collection 'res'
>>appears exactly once, i.e. is unique.

Resolution:
Revised Text: The definition of 'isUnique()' has been fixed.
Actions taken:
December 7, 1999: received issue
May 24, 2001: closed issue

Issue 3121: Language Name (uml-rtf) (uml-rtf)

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

In order to maximize tool interoperability, the language names provided in
UML Expressions should follow a consistent naming pattern.  No such pattern
is given by the UML Specification.

Recommendation:  Add the following simple statement after the predefined
language names (a list of one) given in the description of Expression.  Note
that the following naming practice has a president.  It is recommended in
the ANSI/ISO C++ standard for language names used for external linkage:

Resolution:
Revised Text: Followed submitter's recommendation to use official language names.
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed issue

Issue 3122: Precise "Physical" Metamodels Missing from Specification (uml-rtf (uml-rtf)

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

There is no XMI-based XML rendering of the UML metamodels in the UML 1.3
Specification.  The "physical" metamodels must be precisely described using
the MOF Model document type in order to maximize tool interoperability
across vendors and to enable extension of the metamodels by others.  This
has been done in MOF 1.3, in the initial CWM submission and in other OMG
submissions, thereby providing definitive metamodels with complete
machine-readable clarity.

Recommendation:  Put an XML rendering of UML metamodels in the UML 1.4
specification based on the MOF Model DTD.

Resolution:
Revised Text: The "Physical" Metamodel will be provided with UML 1.4 as an XML document.
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed issue

Issue 3124: "Physical" Metamodel References (uml-rtf) (uml-rtf)

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

UML's "physical" metamodels need to be more careful about which association
ends have corresponding references.  In places where an association end can
relate one element to another element imported from another model, it is
generally best to not have a reference on the inverse end.  Note that
"reference" is a MOF concept.  The lack of a reference does not affect
whether an association end is navigable.  It does affect whether a link can
be in a different MOF package extent (this is a MOF constraint).  If both
sides of an association have references, then related objects are forced to
reside in the same package extent, which prevents the federation of UML
facilities.

An important aspect of interoperability comes from federation: UML
facilities having links to other UML facilities.  The overuse of references
prevents use of such links in places where they should be allowed.

Resolution:
Revised Text: Undesired implicit references are removed from the "Physical" Metamodel in UML 1.4.
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed issue

Issue 3125: "Physical" Metamodel References in Diagrams (uml-rtf) (uml-rtf)

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

The UML Specification contains UML diagrams of the "physical" metamodel, but
the diagrams do not show which association ends have corresponding
references.  Using a UML facility requires knowing exactly where references
occur, so showing references in diagrams is important.

Recommendation:  Make references explicit in the UML diagrams of the
"Physical Metamodel".  We can do this by showing each reference as an
attribute with a stereotype of <<reference>>.

Resolution:
Revised Text: All references of the "Physical" Metamodel are made explicit in UML 1.4.
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed issue

Issue 3137: OCL: Consistency in grammar description (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 Some non-terminals are enclosed in angle brackets <>,
  and others are not. This would not have been a big problem, if not for the
  fact that enclosing non-terminals in angle brackets is a technique from
  the original BNF specification format. So, we should either use it
  consistently for all non-terminals � or not use it at all.

Proposed resolution:

  make the grammar description consistent.

Resolution:
Revised Text: The grammar description has been made consistent.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3138: OCL: Are keywords reserved or not (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  Although the OCL specifies a respectable set of keywords (like 
  "and", "if", etc.) the OCL reference says nothing about whether 
  they are reserved or not. Clearly, a software designer is completely 
  free to specify the class with an attribute called "if". Or, more 
  probably, "context". Or any other OCL keyword. How, then, to 
  parse an OCL constraint like:

    context if : X inv:
      if.then->size()>=else->size()

  (where if is used instead of self to designate the object an 
  invariant is applied to, and then and else are its associations).

  Clearly, reserving keywords is a bad idea. The rule, which seems 
  to work well (and has been tried in many real programming 
  languages over decades) is:

      An identifier is recognized as a keyword if and only if it is 
      encountered in a context where this keyword can legally 
      appear.

Resolution:
Revised Text: Yes, keywords are reserved in OCL, an escape character can be used if needed.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3139: OCL: Class context specification grammar incomplete (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 The text of the OCL specification says, that both following forms 
  are allowed:

    context Company
    inv : self.numberOfEmployees > 50

  and

    context c : Company
    inv : c.numberOfEmployees > 50

  However, the OCL grammar does not allow the 2nd form.
  To allow the 2nd form, the rule

    classifierContext	:= <typeName>

  Should be changed to

    classifierContext	:= ( name ":" )? 
    <typeName>

Resolution:
Revised Text: Grammar for class context declaration is fixed to support the examples.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3140: textual syntax cannot deal with identical class names in different package (uml-rtf)

Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  We can imagine packages 
  Package1 and Package2, both containing the class X, but we 
  are free to use scope resolution to refer to these two different 
  classes as Package1::X and Package2::X.

  However, we then should also be able to specify constraints on 
  these classes. To do so, the context definition should allow the 
  fully scoped class name to be used, like in

    context Package1::X inv: �

Resolution:
Revised Text: The 'package' and 'endpackage' keywords are introduced to specify in which package a constraint belongs. This allows files with OCL constraints to be fully self-descriptive.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Discussion:

Discussion:

  The problem is how to express the context for a class in a specific
  package. Something that is important to realise 
  is the position of constraints in UML. Each constraint in UML is 
  always attached to a specific model-element, which is its context. 
  The UML notation is a notebox containing the constraint 
  expression, with a dotted line to the model-element. In this notation 
  tThere is no ambiguity of the context. When many constraints are 
  written on classes and operations in a class model, this easily 
  leads to unreadable visual models. 
  The textual "context" notation in the OCL specification is a 
  convenience to circumvent this problem. Formally, the "context" 
  declaration is a textual representation of the dotted line between 
  the constraint and the attached model-element, but when there are
  multiple classes with the same name this declaration is incomplete.
  There are two solutions to the problem mentioned:

  1 Add a "package" statement to the OCL grammar, 
    allowing the modeller to state in which package the 
    constraint should be interpreted. the above example 
    would then look like:

    package Package1

      context X inv:

      context Y inv:

    endpackage

  2 Allow a fully qualified classname as the context. The above
    example then becomes:

        context Package::X inv: 

  Option 1 has the advantage that the separate OCL invariant file
  follows the packages structure defined in the corresponding UML model.
  In this way, each OCL constraint is defined within a specific 
  package. This makes it easier to define visibility rules based on the 
  package in which the constraint belongs. This also promotes structured
  OCL files. All constraint for a given package can now be grouped together.
  
  In option 1, the OCL textual form can follow all visibility and scoping
  rules as defiuned in the UMNL metamodel. This keps OCL consustent with UML.

  Option 2 has the disadvantage that you should use fully qualified
  names in each invariant and pre/postcondition, because new packages with
  identical class names in them might be added later on. This leads to less
  readable constraint files, especially with nested packages.

Issue 3141: OCL: Feature calls on default target (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  The rule for non-terminal primaryExpression should be 
  changed from

    primaryExpression :=   literalCollection
                         | literal
                         | pathName 
                           timeExpression? qualifier?
                           featureCallParameters?
                         | "(" expression ")"
                         | ifExpression

  to

    primaryExpression :=  literalCollection
                         | literal
                         | featureCall
                         | "(" expression ")"
                         | ifExpression

  for two reasons:
  - It will become shorter
  - It describes what is going on more carefully � since 
    what happens is exactly the feature call on the default 
    object (self).

Proposed sulution:

  Needs to be checked in detail to see what the consequences of this 
  change are.

Resolution:
Revised Text: The grammar for 'primaryExpression' is simplified for default feature calls.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3142: OCL: Enumeration types (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  When an enumeration constant is used, it has to be preceded by the 
  hash '#' sign. While this is not strictly necessary, it certainly 
  makes parsing easier and, therefore, can stand as it is.

  However, the need for the same hash characters in the definition of 
  the enumeration types, like in

    enum { #male, #female }

  is what the OCL grammar currently requires � and in this context 
  the hash characters should probably be abolished, because:

  - Their presence does not give anything significant to user
    because name conflicts can't happen inside the  enumeration type
    definition. Everything inside the curly brackets {} is enumeration
constants.
  - Normally, one can try to copy-paste some text between UML and OCL
    parts of the class model. This is made a bit tricky, because UML and
OCL use 
    different syntax for the enumeration types. It would 
    be nice of OCL could adopt the UML syntax.

Resolution:
Revised Text: Syntax for enumeration types has changed from #enumvalue to EnumType::enumvalue. This is in line with the new definition of enumeration in the semantics section.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3143: OCL: Enumeration types inconsistent with UML metamodel (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  Enumerations are Datatypes in UML and have a name.  They can be shown
  with the notation of a class. In the attribute box, the possible values
  of the enumeration are written. In fact these names are class
  constants (class-scopes frozen attribute) for the enumeration type.
  If we use this UML definition in OCL, the logical way to 
  refer to them will be as class attributes, for which there is already a
  defined notation in OCL (Classname.attributeName):

  When we have Datatype named Sex with values 'female' or 'male'
  they can be used as follows:

    context Person inv:
       sex = Sex.male

  Also the enumeration type has a name, therefore the "var : 
  enum { �}" type declaration in OCL is superfluous. We can use 
  the typename instead: "var : EnumTypeName".
  A logical consequence of this is that the special notation for 
  enumerations will disappear completely and only the above syntax is allowed.

Issue 3144: OCL: Literal collections (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Currently, the syntax for the literal collection allows either a single 
  range of values, or a list of individual values:

    literalCollection	:= collectionKind "{"
	   
    expressionListOrRange? "}"

    expressionListOrRange :=   expression
                               ( ( "," expression  )+
	                     |   ( ".." expression ) )?

  This is too complicated a rule for what could have been 
  made much simpler:

    literalCollection := collectionKind "{"
                         (collectionItem ("," collectionItem )+)? "}"

    collectionItem    := expression ( ".." expression )?

  Which would also allow more general types of literal collections,  
  like in:

     Set { 0..2, 3, 4, 5..15 }

  And is just as easy to parse.


Proposed resolution:

  This is more generic and should be includes in the OCL grammar.
  grammar is ok.

Resolution:
Revised Text: Grammar for literal collection ('literalCollectio' and 'collectionItem') has been fixed to make it more general.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3145: OCL: Numeric constants missing (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 The OCL chapter of the UML reference insists that not only there 
  is a data type Real, but one can also write constants of this type. 
  However, the OCL grammar does not allow for floating-point 
  constants.

  To correct that, the rule for numbers:
 
    number := ["0"-"9"] (["0"-"9"])*

  could be rewritten as:

    number := ["0"-"9"] (["0"-"9"])*
	      ( "." ["0"-"9"] (["0"-"9"])* )?
              ( ("e" | "E") ( "+" | "-" )? ["0"-"9"] (["0"-"9"])* )?

  to allow all traditional forms of Real constants, both with decimal 
  point and with exponent (and both).

  The one mandatory digit after the decimal point is there on purpose,
  to make sure that in an OCL string like

     1..10

  (which is perfectly legal inside the OCL collection literal) the 
  leftmost sub-string '1.' will not be incorrectly recognized as a real 
  constant. This little trick allows writing lexical parser for the OCL 
  that does not need more than one-character look-ahead.

Proposed resolution:

  Agreed. 
______________

Resolution:
Revised Text: Grammar rules for numeric constants ('number') have been altered
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3146: OCL: String literals (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

  If, as I was told before, they are supposed to be similar to Java 
  strings, the correct rule for string constants will be:

  string := "'" ( 
            (~["'","\\","\n","\r"] )
            | ("\\"
	    ( 
               ["n","t","b","r","f","\\","'","\""]
             | ["0"-"7"] 
               ( ["0"-"7"] ["0"-"7"]?)?
	        )
	       )
	       )*
	       "'"

  Allowing octal escapes only in the ASCII range is not really a part 
  of syntax � it is a part of OCL semantics, and this is where it 
  belongs.
 
  As a matter of fact, even that is not 100% right � because it doesn't 
  allow for hexadecimal escape sequences � and allows to specify 
  only ASCII characters (decimal codes 0..255), while in Java strings 
  the hexadecimal escapes can be used to specify any UNICODE 
  character. 

  I am also wondering, why OCL insists that all strings should be 
  ASCII strings? Is there a compelling reason for disallowing 
  UNICODE strings (and thus having no support for international 
  applications)?

Resolution:
Revised Text: Typo in grammar rule for 'string' has been fixed. Unicode strings have not been added.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3147: OCL: class operation has no 'self' (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 There is no 'self' object in preconditions and postconditions
  of class operations. For example the following:

    context X::increaseInstanceCounter() 
    post: instanceCounter = instanceCounter@pre+1

  will not work, because "instanceCounter" is only a 
  syntactic shortcut for the full form 
  "self.instanceCounter", and, as already said, there is no 
  valid self in this context.

  We can even allow a little syntactic trick along the lines of OCL 
  case-sensitivity: when a class name is on the other end of an 
  association, making its 1st letter lowercase actually denotes 
  associated instance(s) of this class. Going the other way round, we 
  may state that when self is written in a capitalized form Self, it 
  actually denotes the context class, not object:

    context X::increaseInstanceCounter() 
    post:
         Self.instanceCounter = 
         Self.instanceCounter@pre+1

  This point clearly merits a discussion. The good thing is: even if 
  the provisions for static class members are included in the OCL 
  exactly as suggested above, all existing OCL code will remain 
  valid.

Resolution: rejected
Revised Text: The proposed solution ('self' and 'Self' with starting capital seems too confusing.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Discussion:

"The proposed solution ('self' and 'Self' with starting capital seems too confusing. 
Previously considered for 1.4 and closed w.o. change. "

Issue 3148: OCL: Let-expressions (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

his nice feature provides a useful shortcut for writing complex OCL 
  expressions. However, it is under-defined both syntactically and 
  semantically.

  Syntactically, why stop at one level, as specified by the grammar 
  rule:

    expression  := letExpression? 
                   logicalExpression

  To make the language more orthogonal, that rule should be 
  replaced with:

    expression  := ( letExpression expression )
	           | logicalExpression

  which, by the way, ensures the correct precedence and evaluation 
  order.  The generic form of the let expression is:

    let <variable> = <expression-1> in <expression-2>

  what is not so self-evident, is the following: this fancy syntax 
  somehow hides the fact that semantically this is equivalent to the 
  lambda-expressions known from functional analysis:

Resolution:
Revised Text: Let expressions are much better defined. They can now have parameters and be attached to Classifiers to make them reusable.
Actions taken:
December 17, 1999: received issue
May 24, 2001: closed issue

Issue 3149: OCL: Samples of invalid typing (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 There are some examples of OCL expressions with type errors.
  For example, in section 7.4.4. there is an OCL expression:

    1 + 'motorcycle'

  of which it is said that it is invalid because type Integer does 
  not conform to type String. The conclusion is correct, but the reason
  for the expression above being invalid is entirely different. 
  The reason for it is that type String does not confirm to type Real!

Proposed solution:

  Rephrase the text in the OCL specification. And check other examples.
____________________________________________________________________________

Resolution:
Revised Text: Some examples in section 7.4.4 have been fixed.
Actions taken:
December 17, 1999: receive dissue
May 24, 2001: closed issue

Issue 3153: Invalid OCL expression in initial transition (uml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Revision
Severity: Minor
Summary:

 OCL expression is duplicated with errors:

"self.source.kind = #initial" should be
"self.source.oclAsType(Pseudostate).kind = #initial"
"self.StateMachine.top"       should be "self.stateMachine.top"
"self.trigger.operation"      should be
"self.trigger.oclAsType(CallEvent).operation"
"self.StateMachine.context"   should be "self.stateMachine.context"

Resolution:
Revised Text: OCL has been fixed
Actions taken:
December 21, 1999: received issue
May 24, 2001: closed issue

Issue 3201: Why is "FinalState" a separate metaclass ? (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

State Machines:

   Why is "FinalState" a separate metaclass ?

   It seems that a final state can be modeled as a kind of PseudoState
   (with PseudoStateKind = final).

   FinalState has no attributes of its own, and all associations inherited
   from State must be empty for a final state:
     - A final state cannot have an entry action
     - A final state cannot have an exit action
     - A final state cannot have an doActivity     
     - A final state cannot have a  deferrableEvent
     - A final state cannot have an internalTransition

   Could anybody explain the reason of existence for a FinalState metaclass ?

Resolution: declined
Revised Text:
Actions taken:
January 10, 2000: received issue
May 24, 2001: closed issue

Discussion:

The semantics of final states are different from psuedostates, which are transient. Also, final states can indeed have entry actions. Previously considered for 1.4 and closed w.o. change.

Issue 3210: Inheritance of Stereotypes (uml-rtf)

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

Issue: The semantics of inheritance (UML 1.3,  ad/99-06-8, p. 60-61) does
not include Stereotypes as being among the things that a subclass inherits
from its superclasses. 

Recommendation: Explicitly specify that Stereotypes are inherited.

Discussion: UML specifies that Constraints are inherited.  A Stereotype is
logically a constraint, and can even formally define Constraints that apply
to stereotyped ModeledElements.  Consider a Class A that is stereotyped S, where C is the Constraint that the Stereotype definition specifies for all ModelElements stereotyped S.  Now consider Class B that
inherits A.  It stands to reason that the Constraint C applies to Class B.

Resolution:
Revised Text: Stereotypes are GeneralizableElements and a discussion of what it means to subtype a Stereotype and what the applicable rules are has been added.
Actions taken:
January 11, 2000: received issue
May 24, 2001: closed issue

Issue 3241: Shouldn't the UML Package be allowed to own/reference UML 'Instances'? (uml-rtf)

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

We are currently implementing the UML spec into java and have stumbled upon the following problem: 
According to the Model Management package, a UML Package can only own/reference Packages, Classifiers, ..., and Stereotypes. 
My question is, where to put UML 'Instances' (Common Behavior package, p. 2-89) in the model?

Shouldn't the UML Package (p. 2-173 & 2-175) be allowed to own/reference UML 'Instances'?

Resolution:
Revised Text: See issue 1010
Actions taken:
January 20, 2000: received issue
May 24, 2001: closed issue

Discussion:

Issue 3243: ISSUE FOR UML, SECTION ActivityGraphs (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Description:
------------
The metaclass ClassifierInState is unneccesary and can be replaced by
existing metaclasses.

Discussion
-----------
In a number of cases a specific ClassifierInState is not needed.  When e.g.
a ClassifierRole always has certain restrictions, these restrictions can be
modeled with a Constraint (stereotypes as <<invariant>>) on the
ClassifierRole.

The use of ClassifierInState in activity graphs is to show the output or input
parameter to actions. The same concept can be modeled in a unified way by
using existing preconditions and postconditions.

To denote that an object must be in a state after the action can be modeled
by a
<<postcondition>> Constraint attached to the action state.
To denote that an object must be in a state before the action can be
modeled by a
<<precondition>> Constraint attached to the action state.
An action is a piece of behavior and can have pre- and postconditions attached
to it. using that, the ClassifierInState might turn out to be superfluous.

Solution
--------
Remove ClassifierInState metaclass and replace it by a description how
existing 
metaclasses can be used to solve the same modeling problem.

Resolution: declined
Revised Text:
Actions taken:
February 24, 2000: received issue
May 24, 2001: closed issue

Discussion:

Previously considered for 1.4 and closed w.o. change.

Issue 3244: Issue Activity Package (uml-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

ISSUE FOR UML, SECTION ActivityGraphs
-------------------------------------

Description:
------------
The metaclass ClassifierInState is too limited and can be generalized
to become more useful.  It might show to be completely unneccesary.

The Definition of ClassifierInSate in UML 1.3 is as follows:

    A classifier-in-state characterizes instances of a given classifier
    that are in a particular state or states.  ......
    ClassifierInState is a child of Classifier and may be used in static
    structural models and collaborations (e.g., it can be used to show
    associations that are only relevant when objects of a class are in a
    given state).

Issue 1: 
This might be a useful concept, but defined in a too limited way. 

Specifying that only instances which fulfil certain condiations
can be used is meaningful at many places. However, these restrcitions
are not based only on the state in which the instance is.  They can also
be based on attribute values and link values.  
Therefore the ClassifierInState is too restricted, because the
condition can only be a (or more) state(s).

Solution:
---------
Instead I would like to define a metaclass RestrictedClassifier (or
ConstrainedClassifier) instead of ClassifierInState. The definition should
be:

    A RestrictedClassifier characterizes instances of a given classifier
    that conform to certain constraints.

For modeling the restrictions UML already has a perfect metaclass called
Constraint. A RestrictedClassifier has an association to Constraint with
multiplicity 1..* (at least one constraint)
The constraint can either be stated in OCL, which allows one to specify
generically any restrictions you want (or in any other language).
OCL allows to check whether an instance is in a certain state by the
expression "instance.oclInState(statename)", and is therefore able to
specify at least everything you can specify with ClassifierInState.

Potentially we could define a stereotype (e.g. <<restriction>>) for this
kind of Constraint.

Resolution: declined
Revised Text:
Actions taken:
January 24, 2000: received issue
May 24, 2001: closed issue

Discussion:

Previously considered for 1.4 and closed w.o. change.

Issue 3259: State machine name space (uml-rtf)

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

What is the reason that Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the  context model element?

Resolution: duplicate 3341
Revised Text:
Actions taken:
January 27, 2000: received issue
May 24, 2001: closed issue'

Issue 3273: UML RTF 1.4 Issue: Notation for call state (uml-rtf)

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

It is very common for readers of activity diagrams to look at a
call state and want to see what type of object is having an
operation invoked by the action of that state. There is
currently no adopted notation for this. Notes are too bulky and
non-standard for this application. Without this notation
activity diagrams appear non-object-oriented.

Resolution:
Revised Text: Notation for CallState is added. The name of the class of object receiving the call is placed in parentheses below the action name.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3274: UML RTF 1.4 Issue: State constraint on host object (uml-rtf)

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

States currently do not model the conditions required for an
object to be in a particular state.  A constraint note can be
linked to a state, but there is no specification of when the
constraint should be tested.  It could be tested when the object
enters the state, leaves the state, or at any other time.  Even if
this were unambiguous, the consequence of violating the constraint
is not defined, namely, to transition the machine to a state that
has a constraint satisfied by the object.  This might be modeled
as a change-event trigger on an exiting transition, but it would
be redundant with the constraint recorded on the state and with
triggers on other transitions leaving the state, thereby impairing
maintainability.

Resolution:
Revised Text: A standard stereotype <<stateInvariant>> has been added for this purpose (solution consistent with existing <<precondition>> and <<invariant>> standard stereotypes)
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3275: UML RTF 1.4 Issue: Join in collaboration (uml-rtf)

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

It is possible to model forks in sequence charts using multiple
asynchronous messages.  However, it is not possible to model
joins, because return messages are considered activitators, and
multiple activators are not allowed.

Resolution: Previously considered for 1.4 and closed w.o. change
Revised Text:
Actions taken:
February 5, 2000: received issue
October 23, 2002: closed issue

Discussion:

Issue 3277: UML RTF 1.4 Issue: Deferred event ambiguity (uml-rtf)

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

What happens when a event is defered in one region, but not another?  Is
it left on the queue accessible to both regions, even if it has already
been consumed by one of the regions? Semantics says deferred events are
kept if not used in one of the regions.  So if one region uses it, it is
lost, even if it is deferred in the other region.  User cannot use event
in both regions.

 Reference manual says:

 At the time that an object processes an event, it may be in one or more
concurrent states. Each state receives a separate copy of the event and
acts on it independently. Transitions in concurrent states fire
independently. One substate can change without affecting the others,
except on a fork or join caused by a complex transition (described
later).[p 443, Reference Manual]

 and refers to an internal queue of events:

 Deferred events. A list of events whose occurrence in the state
 is postponed until a state in which they are not deferred becomes
 active, at which time they occur and may trigger transitions in
 that state as if they had just occurred. The implementation of
 such deferred events would involve an internal queue of
 events. [p 438]

Resolution: declined
Revised Text: There was presumably a potential conflict between nested state regarding deferal of events. Apprently there is no conflict. Need to fix the text.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Discussion:

There was presumably a potential conflict between nested state regarding deferal of events. Apprently there is no conflict. No need for further change.

Issue 3278: UML RTF 1.4 Issue: Guard evaluation for choice points. (uml-rtf)

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

Make guard evaluation procedure for choice points more explicit. 
It is not clear from the specification whether all guards are
required to be evaluated, even after one is found to be true.
This affects performance/real time issues even if the guards have
no side-effects.

Resolution:
Revised Text:
Actions taken:
February 5, 2000: received issue
October 23, 2002: closed issue

Discussion:

This was fixed in 1.4 with clarifying text included in the "Guards" subsection of the state machine semantics

Issue 3279: UML RTF 1.4 Issue: ownerScope and targetScope (uml-rtf)

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

ownerScope in Feature has the same semantics as targetScope in
StructureFeature.  Aren't they clashing?

Resolution:
Revised Text: Not true. Owner scope tells whether there is one global instance of the feature or one per classifier. Target scope tells whether the contained value is a reference to an instance or a classifier.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Discussion:

Not true. Owner scope tells whether there is one global instance of the feature or one per classifier. Target scope tells whether the contained value is a reference to an instance or a classifier. Previously considered for 1.4 and closed w.o. change.

Issue 3280: UML RTF 1.4: Description of context role, between state machine and model (uml-rtf)

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

  Each state machine is owned by exactly one model element. 

The meta-model shows 0..1.

Resolution: declined
Revised Text:
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Discussion:

This was fixed in 1.4 with the text for the association end "context" for StateMachine changed to indicate that a state machine does not necessarily have to be owned.

Issue 3281: UML RTF 1.4 Issue: Arrowhead semantics in collaboration unclear (uml-rtf)

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

The semantics of the stick arrowhead is described as:

  [p 124, notation] Flat flow of control. Each arrow shows the
  progression to the next step in sequence. Normally all of the
  messages are asynchronous.

  [p 128, notation] stick arrowhead: flat flow of control
  (normally asynchronous).

What is a "flat flow of control"?  How is it different than an
asynchronous operation or signal?  It is ambiguous to say that it
is "normally" asychronous.  How does the user tell whether it is
or isn't in any particular case?

It is more confusing when compared to the descriptions for
half-stick:

  [p 124, notation] Asynchronous flow of control. Used instead of
  the stick arrowhead to explicitly show an asynchronous
  communication between two Objects in a procedural sequence.

  [p 128] half stick arrowhead: an asynchronous operation invocation

How is a "flat flow of control" different from a "procedural
sequence"?

This topics has been very confusing for the agent modelers, who
are using sequence diagrams to model agent protocols.

Resolution:
Revised Text: The semantics and notation of the arrowheads have been simplified and made consistent. Only two different kinds are standard.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3282: UML RTF 1.4 Issue: Confusing example of sequence diagram (uml-rtf)

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

  [p 102, notation] An arrow with the arrowhead pointing to an
     object symbol within the frame of the diagram maps into a
     Stimulus dispatched by a CreateAction

   Figure 3-48 [p 100] shows the above for ob1:C1, and ob2:C2, but
   with lifelines below each one sending messages (eg, to ob2:C2
   and ob4:C4 respectively).  Does this mean the constructor of
   the object, that is the object creation method, is sending
   messages?  These objects aren't notated as active, so they
   can't send messages on their own.  It would be good to explain
   this in the above text.

Resolution:
Revised Text: The text describing creation in a sequence diagram is clarified
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3283: UML RTF 1.4 Issue: <<primitive>> keyword/stereotype (uml-rtf)

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

The <<primitive>> keyword/stereotype used in the meta-models of
the datatype section are not defined.  Isn't clear what level the
datatype meta-model elements are at.

Resolution:
Revised Text: Kept enumeration keyword, which is not defined, and removed primive keyword.
Actions taken:
February 8, 2000: received issue
May 24, 2001: closed issue

Issue 3284: UML RTF 1.4 Issue: Flow relationship has the incorrect semantics (uml-rtf)

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

Flow relationship has the incorrect semantics specified for it:

  [p 2-33] It usually connects an activity to or from an object
  flow state, or two object flow states.  It can also connect from
  a fork or to a branch.

Compare:

  <<become>>

   Specifies a Flow relationship, source and target of which
   represent the same instance at different points in time, but
   each with potentially different values, state instance, and
   roles. A Become Dependency from A to B means that instance A
   becomes B with possibly new values, state instance, and roles at
   a different moment in time/space.

   <<copy>

   Specifies a Flow relationship, the source and target of which
   are different instances, but each with the same values, state
   instance, and roles (but a distinct identity). A Copy Dependency
   from A to B means that B is an exact copy of A. Future changes
   in A are not necessarily reflected in B.

Resolution:
Revised Text: Removed references to activity graphs flow states. The stereotypes become and copy are consistent with the definition of Flow. Distinguish from ObjectFlowState, which may be the same at a deeper level, but not at the surface.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3287: UML RTF 1.4 Issue: Action composition meta-modelled improperly: (uml-rtf)

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

Action composition meta-modelled improperly: action sequence
inherits from action.  Should be Gamma's composition model with
action as a sibling of action sequence.

Resolution: declined
Revised Text:
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3288: UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous? (uml-rtf)

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

UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

Resolution:
Revised Text: Added well-formedness rule that return action is always asynchronous.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3289: UML RTF 1.4 Issue: Create action in collaborations (uml-rtf)

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

Using a role as the target of a create action does not support
instantiation of children of the role classifier. [p 2-112
collaboration semantics].

Resolution:
Revised Text: The text is clarified as roles themselves cannot be instantiated
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3290: UML RTF 1.4 Issue: Duplicate association end names from Constraint. (uml-rtf)

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

The Constraint meta-type, in the Extension Mechanisms meta-model, has
two associations with the same association end name on the "opposite"
ends ("constrainedElement").  Assuming that UML meta-classifiers should
adhere to the OCL for regular classifiers, then this is ill-formed
according to OCL 3 of Classifier, p 47:

   [3]  No opposite AssociationEnds may have the same name within a Classifier.

	self.oppositeEnds->forAll ( p, q | p.name = q.name implies p = q )


The same may be true for the Collaboration meta-type (the
"ownedElement" association end is duplicated), but these two are
specializations of an association inherited from ModelElement, so
perhaps that is acceptable.

Resolution:
Revised Text: Renamed one of the end names "constrainedStereotype"
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3292: Incorrect example of constraining elements in collaborations. (uml-rtf)

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

 Figure 3-56, p 117 of the collaboration notation, it intended to
 give an example of constraining elements, but it shows
 generalization relationships between roles instead.  I thought
 the constraining elements would refer to the base classifiers and
 associations, not the roles.  Using generalization links between
 roles has a different semantics than between the base classifiers
 (see Semantics of Collaboration 2, above).

Resolution:
Revised Text: No, but an additional example is provided.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3293: UML RTF 1.4 Issue: Multi-objects in collaborations (uml-rtf)

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

 [p 122] A multi-object symbol maps to a set of Objects that
  together conforms to a ClassifierRole with multiplicity
  "many".

There is no construct for "set" in UML.

Resolution:
Revised Text: The text is clarified
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3294: UML RTF 1.4 Issue: Guard condition in collaborations poorly named. (uml-rtf)

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

 [p 125, notation] predecessor guard-condition
      sequence-expression return-value := message-name
	  argument-list

The descriptions after this imply that "predecessor" and "guard
condition" are the same:

  [p 125, notation] The meaning is that the Message is not
  enabled until all of the communications whose sequence
  numbers appear in the list have occurred (once the
  communication has occurred the guard remains
  satisfied). Therefore, the guard condition represents a
  synchronization of threads.

It's confusing the have two names for the same thing.  I
thought on first glance that some bracketed notation as in
state machine were supported at this position in the label, but
that is in the recurrence part of sequence expressions.

Resolution:
Revised Text: Guards as such removed from Collaborations - they are now named Conditions, to avoid confusion with the formal concept of Guards in State Machines.
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3295: UML RTF 1.4 Issue: Messages do not have signatures (uml-rtf)

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

[p 126, notation] A signature is a string that indicates the
  name, the arguments, and the return value of an Operation, a
  Message, or a Signal. 

Messages don't have signatures.  "Message" can be dropped from
the above sentence.

Resolution:
Revised Text: The text is clarified
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3296: Misleading description of feature inheritance on roles. (uml-rtf)

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

 [p 109, semantics] the former roles may possibly be
  specialized with new features (as classifier roles are also
  generalizable elements).

The parenthetical remark is misleading.  Classifier roles are
not allowed to have features of their own (see OCL on
ClassifierRole).  They only have links to features, ie,
instances of the meta-association between ClassifierRole and
Feature.  These links don't automatically inherit to children
of a ClassifierRole, because inheritance only applies to actual
features of the role, which it isn't allowed to have.  So the
fact that classifier roles are generalizable elements doesn't
achieve the inheritance of the links to features.  That is a
behavior introduced by role specialization.

Resolution:
Revised Text: The text is clarified
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3297: UML RTF 1.4 Issue: Typo in state exit (uml-rtf)

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

This should refer to "exit" not entry:

  [p 134] An optional action that is executed whenever this state
  is exited regardless of which transition was taken out of the
  state. If defined, entry actions are always executed to
  completion only after all internal activities and transition
  actions have completed execution.

Resolution:
Revised Text: Typo fixed
Actions taken:
February 5, 2000: received issue
May 24, 2001: closed issue

Issue 3316: Notation for Namespace ownership (uml-rtf)

Click here for this issue's archive.
Source: University of Oslo (Prof. Birger M�ller-Pedersen, birger(at)ifi.uio.no)
Nature: Enhancement
Severity:
Summary:

The contents of a package (i.e. the ownedElements of the Namespace of
the the package) can be shown in two different ways: either enclosed by
the package symbol or attached with the encircled plus sign (figure 3-6
in the Notation Guide).

Even though classes are also namespaces, then the same options do not
apply for them. In fact there is no notation for this at all. It is
possible to have class boxes enclosed by a class box, but it has another
mapping than notation elements being enclosed graphically by a package
symbol: according to 3.47.5 of the Notation Guide "A class box with
contained class boxes maps into a set of composition associations;".

One may argue that packages are different from classes, but subsystems
come close to objects. A Subsystem (in its capacity of being a Package)
have the two options of showing the contents, i.e. it is possible to
have class boxes within the Subsystem symbol. The meaning of this should
be (according to the text on Package) that the classes are defined
within the Subsystem. However, the Semantics of Subsystem says that "the
semantics of an instantiable susbsystem is similar to the semantics of a
composite class", which means that the enclosed class boxes should be
interpreted in the same way as for class boxes enclosed by a class
boxes.

The enhancement of this should be that notation for namespace
"containment" (ownedElement) and object containment (composition) should
be clarified and made similar for similar concepts.

Resolution:
Revised Text: Removed nested package notation for nested classes. Declined to broaden "anchor" notation to Namespace in general.
Actions taken:
February 11, 2000: received issue
May 24, 2001: closed issue

Issue 3325: "Unused" data types (uml-rtf)

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

During a discussion of "physical" metamodel (i.e., the MOF-compliant
metamodel) issues, the following data types defined in the logical
metamodel Data Types package were identified as unused anywhere else:

o MessageDirectionKind
o Time
o Mapping
o TypeExpression

This note responds to an action to search the UML Specification document
to make sure this is actually true before we consider removing them from
the logical model. I performed this search by doing using the Acrobat
"Find" command on the PDF file for the UML Specification, which also
searches the diagrams.

o MessageDirectionKind: This data type is actually described in the
semantics as "no longer used in UML." And, indeed, it appears no where
in the document outside of the Data Types section, except for the index
and the parts of the IDL and the physical metamodel generated from the
Data Types package.

o Time: This data type is only referenced in the logical metamodel in
the text of the definition of a TimeExpression: "In the metamodel
TimeExpression defines a statement which will evaluate to an instance of
Time when it is evaluated." Thus, this type is not really necessary for
defining the metamodel, since TimeExpression is not further specified
(this will probably have to be dealt with as part of the action
semantics work.) In the IDL, the Time data type is implemented as
"UmlTime", which is a typedef of float. It appears as Time in the
physical metamodel.

o Mapping: This data type is only reference in the logical metamodel in
the text of the definition of a MappingExpression: "An expression that
evaluates to a mapping." As with Time, this type is not really necessary
for defining the metamodel, since the form of its "body" is not further
specified. It is implemented as a string in the IDL, but has no body
attribute in the physical metamodel.

o TypeExpression: This data type appears nowhere else in the Semantics
chapter than the Data Types section (except for the index). However, in
Notation Guide states:

"The type of an attribute is a TypeExpression. It may resolve to a class
name or it may be complex, such as array[String] of Point. In any case,
the details of the attribute type expressions are not specified by UML.
They depend on the expression syntax supported by the particular
specification or programming language being used."

Unfortunately, the abstract syntax requires that the type of an
attribute (or any structural feature) by a classifier (see Section
2.5.2). There is thus no way to map the notation for an attribute,
unless the type expression happens to be the name of a classifier. The
use of a general type expression is desirable, so this should be
corrected.

(One possible approach, which would preserve the definition of an
attribute type as a classifier, would be to make TypeExpression a child
of Classifier as well as Expression. This could also be useful on
instance diagrams, since it would allow one to show instances of
implementation-specific type expressions.)

Resolution:
Revised Text: Removed MessageDirectionKind and Time from the metamodel. They are unused. TypeExpression is now referenced only within ProgrammingLanguageDataType.
Actions taken:
February 16, 2000: received issue
May 24, 2001: closed issue

Issue 3366: Design patterns and collaboration templates. (uml-rtf)

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

The current UML definition of design pattern is oversimplifying the situation. The relationship between a design pattern and collaboration template is 1 to n. For any given design pattern, you can find any number of templates as formal abstract specifications of specific collaboration specifications.

The structure diagram in the GOF book illustrates one common abstract form of the design pattern, but certainly not the only one. Other variants, typically more complex ones, are hidden in the implementation section. The reason for this: in the opinion of its fathers, design patterns can not be formalized.

The best way to escape the debate of whether to formalize or not is to distinguish between a non-formalizable pattern and formalizable templates. This is also how people do it in practice, if you take a look at the many different abstract descriptions (= templates) of, say, the Observer pattern.

Resolution:
Revised Text: duplicate of 3375, 1016
Actions taken:
February 26, 2000: received issue
March 16, 2001: closed issue

Issue 3367: Terminology: Collaboration and Collaboration Template (uml-rtf)

Nature: Clarification
Severity: Significant
Summary:

 suggest to stick with one consistent terminology and avoid imprecise variations and synonyms.

2.1 Collaboration should be a shortcut for Collaboration Specification. Frequently, however, it also means Collaboration Instance. Here, I suggest to drop the rather awkward "collaboration (diagram) on a specification level" and make it collaboration specification, etc.

2.2 IMO, it should be collaboration template rather than template collaboration or parameterized collaboration. First of all, a template collaboration is a collaboration, not a template, so this is confusing. Also, should UML 2.0 solve the template problem in ModelElement, it will be the natural thing anyway.

Resolution:
Revised Text: Changed to consistent usage of the terms
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3369: Focus is on 2.10 Collaborations (uml-rtf)

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

1. I suggest to consistently use "collaboration specification" and "collaboration instance" rather than the awkward "collaboration diagram on an instance or specification level". The use of "collaboration" should probably be discouraged. If it cannot be avoided, it should default to "collaboration specification".

Resolution:
Revised Text: Fixed by introducing collaboration instance to UML 1.4.
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3370: 2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam". (uml-rtf)

Nature: Clarification
Severity: Minor
Summary:

2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

Resolution: fixed
Revised Text:
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3371: why is AssociationRole is a subtype of Association? (uml-rtf)

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

3. It is unclear to me, why AssociationRole is a subtype of Association, and, similarly, why AssociationEndRole is a subtype of AssociationEnd. The resulting recursive relationship suggests that AssociationRoles can serve as the base for further AssociationRoles, the meaning of which is unclear to me. (Some people suggest to have roles of roles, but I think this confuses concepts.)

Resolution:
Revised Text: The text is clarified
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3372: use of the phrase "In the metamodel..." is unclear (uml-rtf)

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

 4. In 2.10.2, the use of the phrase "In the metamodel..." is unclear to me. (It typically starts the second paragraph of a concept definition. Using ClassifierRole as the example, it should be "In a model, an (instance of) ClassifierRole specifies".

Resolution:
Revised Text: The phrase "in the metamodel" is totally unnecessary but not wrong and too hard to remove.
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Discussion:

The phrase "in the metamodel" is totally unnecessary but not wrong and too hard to remove. Previously considered for 1.4 and closed w.o. change.

Issue 3373: Confusing wording (uml-rtf)

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

5. In 2.10.2 and 2.10.4, the words "classifier roles", "ClassifierRoles" and "instances of ClassifierRole" are used interchangeably. I suggest to stick to one way of doing it and avoid the others.

Resolution: fixed
Revised Text:
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3374: Page 2-114, 2nd paragraph. It should be collaboration template (uml-rtf)

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

Page 2-114, 2nd paragraph. It should be collaboration template rather than template collaboration. This distinction is important: a template is not a special form of the templatized model element. (Much like a process description is not a described process or a painted car is not car paint).

Resolution: fixed
Revised Text:
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3375: In 2.10.5, you give pattern a non-standard definition (uml-rtf)

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

In 2.10.5, you give pattern a non-standard definition. A pattern is not a formal template. For any given design pattern, there may be any number of collaboration templates that represent a category of design structures that will be considered pattern instances by experts. So the relationship between design pattern and collaboration template is 1 to n, similar to the relationship between collaboration specification template and collaboration specification.

Resolution:
Revised Text: In UML a pattern is less powerful than in e.g. the Gamma book. Can be extended for Uml 2.0.
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3377: Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Cla (uml-rtf)

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

 Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Class".

Resolution:
Revised Text: Changed to Classifier.
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3378: In 2.10.4, semantics of Collaboration, the 1st sentence is confusing (uml-rtf)

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

 In 2.10.4, semantics of Collaboration, the 1st sentence is confusing. It should be "The term instance of a collaboration (also collaboration instance) denotes the set of instances of Classifiers that play roles defined by ClassifierRoles in one specific collaboration specification."

Resolution:
Revised Text: Fixed by introducing collaboration instance to UML 1.4.
Actions taken:
February 26, 2000: received issue
May 24, 2001: closed issue

Issue 3383: OCL: Declarators for iterate (uml-rtf)

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

The declarators for the collection operation "iterate" have a different
format than those for "forAll" and other operations. The specification�s 
grammar allows only the form used with "forAll". The production rule
"declarator" should be updated as follows:

declarator :=
  ( name ("," name)* (":" simpleTypeSpecifier)? "|" ) | 
  ( name ":" simpleTypeSpecifier ";" name simpleTypeSpecifier "=" 
expression "|" )

Resolution:
Revised Text: Grammar rule for 'declarator' changed.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3384: UML 1.4 RTF issue: OCL: Iterator declarators (uml-rtf)

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

The collection operations "iterate", "forAll", "exists", 
"select", "reject", and "collect" can have declarators. 
Declarators should also be allowed for "sortedBy" and "isUnique", 
or, more generally, for all collection operations
with an OclExpression as parameter. This is not stated clearly stated by 
the specification, though it's propably intended.

Resolution:
Revised Text: Declarators added to several operations: isUnque() and sortedBty()
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3385: UML 1.4 RTF issue: OCL: Precedence of relational operators (uml-rtf)

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

The OCL specification defines a precedence of "<", ">", "<=" and
">=" over "=" and "<>". This is misleading, because the OCL 
grammar does not allow relational expression with more than one
relational operator, so that expressions like "a>b = c<d" are illegal
anyway. 

Proposed Solution: Change the precedence rules to define that "<", ">",
"<=", ">=", "=" and "<>" have the same precedence.

Resolution:
Revised Text: The precedence of operators is left as in 1.3.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Discussion:

"The precedence of operators is left as in 1.3.  
Previously considered for 1.4 and closed w.o. change. "

Issue 3386: UML 1.4 RTF issue: OCL: Unary operator "-" missing (uml-rtf)

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

The unary prefix operator "-" is missing in the definition of the OCL
type "Real". It only defines binary "-".

Resolution:
Revised Text: Binary '-' operation added to Real.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3387: UML 1.4 RTF issue: OCL: navigation context in iterate (uml-rtf)

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

he term "navigation context" is used to denote the 
start of an OCL navigation expression. The standard navigation context
is "self", or the iterator name in a subexpression 
that is the argument to collection operations like "forAll".

The standard navigation context in the argument expression of the
operation "iterate" is not clearly defined in the OCL specification. It
might either be the iterator or the accumulator.

Proposed solution:
Since none of these alternatives is clearly more intuitive than the
other, we would favour to demand the explicit qualification of the
navigation context in iterate's argument expression through either the
iterator or accumulator name or "self".

It might be noted that similarly, the default navigation context is not
clear if the operation "forAll" is used with two or more iterators.

Resolution:
Revised Text: Added clarification that 'self' is always the original contextual object. No matter how deeply nested the expression is.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3389: UML 1.4 RTF issue: OCL: grammar is ambigous (uml-rtf)

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

In OCL versions prior to UML 1.3, type names had to begin with a
upper-case character. This was changed, and the rules for typeName and
name are now identical.
Unfortunately, this introduces an ambiguity into the OCL grammar rule
pathName.
pathName := (<typeName> | <name>) ("::" (<typeName> | <name>))*

This problem could be solved by dropping the distinction between names
and type name completely. The path name rule could be changed to:
pathName := <name> ("::" <name>)*

Now, the problem arises that it is not possible to distinguish between 
property accesses and type literals if they have the same name. For
example, consider the following UML model:
- Classes TypeA, typeB, TypeC
- Association between TypeA and TypeC, association end at TypeC is 
  named typeB.
The expression "typeB" in the context of "TypeA" might either be
interpreted as a navigation to the association end 
"typeB", and hence result in an object of "TypeC", or as the type 
"typeB".

Resolution:
Revised Text: The 'typeName' grammar rule is dropped, and the 'pathName' used instread.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3390: Change syntax of certain pre-defined operations (uml-rtf)

Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

In the OCL specification, properties of Collections like
'isEmpty', 'size' etc. are defined as operations with
pre and postconditions.  Their syntax however is as attributes without
parenthesis.
For consistency it would be more clear to change the sytax of these
predefined operations to use parenthesis as in 'isEmpty()', just
like other operations.
The same holds for operations on other predefined types like
Real::floor.

Resolution:
Revised Text: Predefined operations must be used with brackets. I.e. ->isEmpty becomes ->isEmpty(). This is more consistent with their definition as operations and the notation for operations of user defined model classes.
Actions taken:
May 24, 2001: closed issue

Issue 3393: UML 1.4 RTF Issue: changeability in associations (uml-rtf)

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

Changeability in associations

Changeability as currently described does not make sense when applied to
associations.  It is summarized as:

  [p 2-21] When placed on a target end, specifies whether an instance of
  the Association may be modified from the source end. Possibilities
  are:

What does "modified from the source end" mean?

  [p 2-21] frozen - No links may be added after the creation of the
           source object.

  [p 2-57] the link cannot be modified once it has been initialized
           (frozen).

No links may be added to what?  The source/target objects, the link
itself? See below for the conflicting answers:

  [p 2-21] addOnly - Links may be added at any time from the source
           object, but once created a link may not be removed from the
           source end.

  [p 2-57] new links of the association may be added but not removed or
           altered (addOnly)   
  
Again, what does it mean to modify an association from "an end"?  It
doesn't mean the objects at the ends, according to this:

  These constraints do not affect the modifiability of the objects
  themselves that are attached to the links. Moreover, t ) the
  classifier, or (a child of) the classifier itself.

(The second sentence has too many typos to understand).

Finally, compare the above to:

  An association-end also specifies whether or not an instance playing
  that role in a connection may be replaced by another instance. It may
  state that no constraints exist (changeable), that the link cannot be
  modified once it has been initialized (frozen), or that new links of
  the association may be added but not removed or altered (addOnly).

The first sentence implies the link is what is frozen, but that isn't
consistent with the last sentence.

Resolution:
Revised Text: Clarified changeability to refer to operations of the source class.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3394: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings (uml-rtf)

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

Multiple languages for uninterpreted strings

The various places that uninterpreted strings are used in UML should
support multiple languages.  For example, the Expression metaclass has
an metaattribute for language and another for the uninterpreted string.
This should be a set of such pairs.  Then code generators can target
multiple languages from the same model.

Resolution: duplicate of 3391
Revised Text:
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3395: UML 1.4 RTF Issue: Ordering of attribute values (uml-rtf)

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

Ordering of attribute values

Link ends can be ordered, by setting the ordering metaattibute of
AssociationEnd to "ordered".  But attribute values currently cannot be
ordered.  The metaclass StructuralFeature should have an ordering
metaattribute.

Resolution:
Revised Text: Added ordering attribute to class Attribute.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3396: UML 1.4 RTF Issue: Association generalization has notation but no semantics (uml-rtf)

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

Association generalization has notation but no semantics.

The notation document says:

  [p 3-80] Generalization may be applied to associations as well as
  classes, although the notation may be messy because of the multiple
  lines. An association can be shown as an association class for the
  purpose of attaching generalization arrows.

But no semantics is defined for association generalization.  That's why
it's on the UML 2.0 roadmap.  The above should be removed for 1.4.

Resolution:
Revised Text: Added some semantics but noted that UML 2.0 would likely expand the semantics.
Actions taken:
March 1, 2000: received issue
May 24, 2001: closed issue

Issue 3397: UML RTF 1.4 editorial comments (Part 2 Diagram Elements) (uml-rtf)

Source: Technical Resource Connection (Mr. Brian J. Cook, )
Nature: Uncategorized Issue
Severity:
Summary:

Part 2 - Diagram Elements
1.	3.6.4: Title should be 'Examples' for clarity. Or add a subheading
to communicate that a list of examples follows.
2.	3.10.3: same as above
3.	3.10.7: same as above
4.	3.12: "Examples of such pairs in UML include: Class-Object,
Association-Link, Parameter-Value, Operation-Call, and so on." Should
Operation-Call be Operation-Method? 3.59.5 defines a call as procedural.

Resolution:
Revised Text: Made changes as suggested (note that instance of Operation is Invocation, not Method)
Actions taken:
March 2, 2000: received issue
May 24, 2001: closed issue

Issue 3398: UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements) (uml-rtf)

Click here for this issue's archive.
Source: Technical Resource Connection (Mr. Brian J. Cook, )
Nature: Uncategorized Issue
Severity:
Summary:

Part 3 - Behavioral Elements
1.	In 2.8: typo "that is used to model proocesses."  Should be
"processes"
2.	In 2.9.2, Figure 2-15: "Clas" should be "Class"
3.	In 2.9.2, Figure 2-15 and Argument: There is an internal
inconsistency. The relationship from Argument to Action is diagrammed as a
composition. The text says: [An argument] "is aggregated within an action."
Is it aggregation or composition? 
4.	Continuing #3: Also the glossary definition of composition ties
non-fixed multiplicity and coincident lifetimes. Does 0..1 count as
non-fixed? If so, where is it defined? What does this distinction mean in
the first place?
5.	In 2.9.2, Instance: "The instance construct defines an entity to
which a set of operations can be applied ..." Operation should be method.
Operations exist at the Classifier level; methods are instances of
operations and exist at the instance (application) level.
6.	In 2.9.2, Instance\Tagged Values\persistent: "Persistence denotes
the permanence of the state of the instance, marking it as transitory (its
state is destroyed when the instance is destroyed) or persistent (its state
is not destroyed when the instance is destroyed)." Seems it should say that
transitory is the default. Else add transitory as a tagged value.
7.	In 2.9.2, Figure 2-16: Would two refinements be clearer than the two
associations from Link to Association and LinkEnd to AssociationEnd since
they are a different levels of  abstraction? Also from Instance to
Classifier? [Should the relationship from Method to Operation in 2.5.2,
Figure 2-5 also be a refinement?]
8.	In 2.9.2, Figure 2-16: Should the composition relationship from
Attribute to Classifier also be modeled?
9.	In 2.9.2, Figure 2-16: The element Instance is abstract according to
the text and should be stereotyped <<abstract>>.
10.	In 2.9.2, Link: "In the metamodel Link is an instance of an
Association. It has a set of LinkEnds that matches the set of
AssociationEnds of the Association." In Figure 2-16 LinkEnd to Link is
{ordered}. Should this be consistent with AssociationEnd to Association?

Resolution:
Revised Text: Corrected a number of more or less significant typos.
Actions taken:
March 2, 2000: received issue
May 24, 2001: closed issue

Issue 3399: UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams) (uml-rtf)

Click here for this issue's archive.
Source: Technical Resource Connection (Mr. Brian J. Cook, )
Nature: Uncategorized Issue
Severity:
Summary:

Suggestions for the UML Notation Guide, Part 6 - Use Case Diagrams
1.	3.56.1: Use different class names in the relationships: extend use A
& B, generalization use C & D, include use E & F for clarity.

Resolution: declined
Revised Text:
Actions taken:
March 2, 2000: received issue
May 24, 2001: closed issue

Discussion:

3.56.1: Use different class names in the relationships: extend use A & B, generalization use C & D, include use E & F for clarity. Resolution: declined, reuse of class names intentionally emphasizes alternatives and facilitates comparisons.

Issue 3400: UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams) (uml-rtf)

Click here for this issue's archive.
Source: Technical Resource Connection (Mr. Brian J. Cook, )
Nature: Uncategorized Issue
Severity:
Summary:

Suggestions for the UML Notation Guide, Part 9 - Statechart Diagrams
1.	In Part 9 - Statechart Diagrams:[Proposed changes in red for the
first 3 suggestions.] "A statechart diagram can be used to describe the
behavior of instances of a model element such as an object or an
interaction. Specifically, it describes possible sequences of states and
actions through which the element instance can proceed during its lifetime
as a result of reacting to discrete events (e.g., signals, operation
invocations). " [The idea is that model elements are not dynamic or have
lifetimes; rather they apply to instances of model elements.]
2.	In 3.74.1: "Typically, it is used for describing the behavior of
classes instances, but statecharts may also describe the behavior of other
model entities such as use-cases, actors, subsystems, operations, or
methods." [A method is an instance of an operation. Therefore, you must have
implementation level knowledge, in this case, the programming language used,
to know about a method. This is antithetical to good modeling principles
which state that a model should be implementation independent.]
3.	In 3.74.3: "That StateMachine may be owned by an instance of a model
element capable of dynamic behavior, ..."
4.	Event-name or action-label??? 3.75.2 says "Internal transitions
compartment This compartment holds a list of internal actions or activities
that are performed while the element is in the state. The notation for such
each of these list items has the following general format: action-label '/'
action-expression" and later  "The general format for the list item of an
internal transition is: event-name '(' comma-separated-parameter-list ')'
'[' guard-condition']' '/'action-expression". Which is to be used? Or is
action-label the name of  the expression: event-name '('
comma-separated-parameter-list ')' '[' guard-condition']'? Compare this with
3.78.2 which has " event-signature '[' guard-condition ']' '/'
action-expression. The event-signature describes an event with its
arguments: event-name '(' comma-separated-parameter-list ')'"
5.	In 3.75.2: "If the event has parameters, they can be used in the
action expression through the current event variable." Should it be
action-expression for consistency?
6.	3.75.4: "The action expression maps into the ActionSequence and
Guard for the Transition." Should it be action-expression?
7.	3.75.4: "The Transition has a trigger Association to the Event." The
term trigger does not appear to be unambiguously defined. It was previously
mentioned in the section. " In all other cases, the action label identifies
the event that triggers the corresponding action expression." Is this
sufficient? It is not in the glossary.
8.	The use of the term pseudostate is not consistent throughout. In the
glossary it is "pseudo-state", with a hyphen. In 2.12.2 it is pseudostate.
9.	3.76.3, Figure 3-63: Passed and Failed are activities and not
states. Change to the right graphic.
10.	3.78.1: " A simple transition is a relationship between two states
indicating that an object in the first state ..." Object should probably be
instance. (This should be looked at throughout the document.) I suspect this
opens a can of worms but the definitions, and probably the concepts
themselves, of instance and object need clarification. 
11.	3.80.4 Figure 3-66: Each of the two diagrams should have a top level
state around it to keep the rule about not transitioning from a stubbed
state to an external state. See below. Granted they are implied but we are
trying to be clear. 
12.	3.80.5: Eliminate the word "elision". It is not a common word plus
it appears to be misused. "Elision is the omission of sounds, syllables, or
words in spoken or written discourse
</lingualinks/library/literacy/glossary/cjJ405/tks2801.htm>." and "The
omission of a letter or syllable as a means of contraction, generally to
achieve a uniform metrical pattern, but sometimes to smooth the
pronunciation; such omissions are marked with an apostrophe <gl-a.html>.
Specific types of elision include aphaeresis <gl-a.html>, apocope
<gl-a.html>, syncope <gl-s.html>, synaeresis <gl-s.html> and synaloepha
<gl-s.html>." Suggest replace with shortcut. 
13.	3.81.2: " represented by a a small white circle"  Eliminate one "a".
14.	3.83.2: " The bound is either a positive integer or a star ('*') for
unlimited." "Unlimited" should be "any number" and "star" should be
"asterisk".

Resolution:
Revised Text: Comments incorporated (not all accepted)
Actions taken:
March 2, 2000: received issue
May 24, 2001: closed issue

Issue 3408: UML 1.4 RTF Issue: Namespace notation too specific (uml-rtf)

Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock(at)objectswitch.com)
Nature: Uncategorized Issue
Severity:
Summary:

Namespace notation too specific

The model management namespace containment notation (the circled plus
sign (+)) should be available on all namespace elements.

Resolution: declined
Revised Text: The plus-sign notation is restricted to packages and classifiers. Any broadening is deferred until UML 2.0, if at all.
Actions taken:
March 8, 2000: received issue
May 24, 2001: closed issue

Discussion:

The plus-sign notation is restricted to packages and classifiers. Any broadening is defer until UML 2.0, if at all.

Issue 3530: Page 2-47, well-formedness rule #2 for Classifier (uml-rtf)

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

In the UML 1.3 specification (ad/99-06-08) there are the following problems:

1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
operation 'oppositeEnds' which is not defined.  This probably should be
'oppositeAssociationEnds'.

Resolution:
Revised Text:
Actions taken:
March 27, 2000: received issue
October 23, 2002: closed issue

Discussion:

This issue has been fixed in UML 1.4. The correct operation is "allOppositeAssociationEnds".

Issue 3531: 2) Page 2-49, additional operation #7 for Classifier (uml-rtf)

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

2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
follows:

1     oppositeAssociationEnds : Set (AssociationEnd);
2     oppositeAssociationEnds =
3     self.association->select ( a | a.associationEnd->select ( ae |
4         ae.type = self ).size = 1 )->collect ( a |
5             a.associationEnd->select ( ae | ae.type <self ) )->union
6     (
7     self.association->select ( a | a.associationEnd->select ( ae |
8         ae.type = self ).size 1 )->collect ( a |
9             a.associationEnd) )


In line 5, the expression 'ae.type <self' is clearly wrong.  I believe the
intention may have been to test for inequality, i.e. 'ae.type <> self'.

In line 8 'size 1' doesn't parse.  I'm not sure what the intent was.

A greater concern is that, even if corrected to address these flaws, this
logic doesn't seem right in the case where we are dealing with an
association where both ends are of the same type. It appears to be relying
on detecting whether an end is opposite by testing the end's type.  A fair
number of other well-formedness rules leverage this operation in one way or
another, so they are affected by this apparent flaw.  Correcting this would
require comparing the end instances, i.e. something like 'ae <> self' which
does not have the same problem as 'ae.type <> self'.

Resolution: This issue has been fixed in UML 1.4. The correct operator is "<>"
Revised Text:
Actions taken:
March 27, 2000: received issue
October 23, 2002: closed issue

Discussion:

Issue 3558: Who owns an Event? (uml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Revision
Severity: Minor
Summary:

An Event is aggregated by a transition but there seems to be no
reference to who owns an event. 
If it should reside in a Package the OCL-WellFormedness rule for Package
should be updated.

Resolution:
Revised Text: A Signal is a Classifier and hence owned by the Package in which it is defined. Events are owned by StateMachines
Actions taken:
April 13, 2000: receive dissue
May 24, 2001: closed issue

Issue 3631: Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics (uml-rtf)

Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Revision
Severity: Minor
Summary:

The Action ModelElement looks like it is abstract in the Rose MDL
because the name is in italics. 
However, checking the details tab in Rose shows that it has not been marked
as abstract.

Resolution:
Revised Text: Action and Instance have both been set to be Abstract.
Actions taken:
May 19, 2000: received issue
May 24, 2001: closed issue

Issue 3637: The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4 (uml-rtf)

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

 The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4.4 as follows:

2.9.4.25 Object and DataValue . 2-103
2.9.4.26 Link . . . . . . . . . . 2-104
2.9.4.27 Signal, Exception and Stimulus . 2-104
2.9.4.28 Action . . . . . . . . 2-105

It would appear that the fourth level carries on from 2.9.3.24

Resolution:
Revised Text: The numbers have been updated.
Actions taken:
May 23, 2000: received issue
May 24, 2001: closed issue

Issue 3803: elimination of the Association Class TemplateParameter (uml-rtf)

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

At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9. 

My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version: 

1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association 

B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1 

2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement 

B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of * 

3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances 

B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind 

Can you help me to solve this trouble?

Resolution: rejected
Revised Text:
Actions taken:
September 5, 2000: received issue
October 23, 2002: closed issue

Discussion:

The model interchange chapter has changed sufficiently from 1.3 (against which this issue was raised) to 1.4 that this issue may not be relevant any more. The author is encouraged to resubmit an issue against 1.4, if the problem still persists.

Issue 3860: Who owns a Comment? (uml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Eugenio Alvarez, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2,  p. 2-17, Figure
2-9 Core Package - Auxiliary Elements
Nature: Revision
Severity: Minor
Summary: A Comment is shown as having a relationship to ModelElement
(annotatedElement). However, the ownership of a Comment is not specified
anywhere. If it should reside in a Package the OCL-WellFormedness rule for
Package should be updated. Also, shouldn't a Comment have a text field to
hold the annotation?

Resolution: Add Comment to wfr listing what may be owned by a Package
Revised Text:
Actions taken:
September 18, 2000: received issue
October 23, 2002: closed issue

Issue 3931: Remove uses of multiple inheritance from UML meta model (uml-rtf)

Click here for this issue's archive.
Source: Capable Objects (Mr. Anders Ivner, anders.ivner(at)capableobjects.com)
Nature: Revision
Severity: Significant
Summary:

Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model. 

Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It�s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

Resolution: rejected
Revised Text:
Actions taken:
October 3, 2000: received issue
October 23, 2002: closed issue

Discussion:

Considered but declined. Vendors have not had problems with implementing multiple inheritance. Note: Java does support m.I. Of Interfaces.

Issue 4060: No servant with object . minorcode=0 completed=NO (uml-rtf)

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

I am running a simple program but i am getting the error 

"There is no servant with object . minorcode=0 completed=NO" 

but i am not finding any documentation that explains abt the minorcode=0. it starts from 1. can u please help me out

Resolution:
Revised Text:
Actions taken:
November 20, 2000: received issue
November 20, 2000: withdrawn

Issue 4120: In 3.23.1 "Notation" (Internationalization issues) (uml-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

> In 3.23.1 "Notation", it is described that
> italics are used to represent abstract classes.
> We don't usally use slanting letters in Japanese.
> It seems strange. So, I think this should be moved into
> "Presentaion Options" or "Style Guidelines".
>
> In 3.22.4 "Style Guidelines",
> it is described that uppercase letters are
> used to represent class names and
> lowercase letters are used to represent attributes
> and operation names.
> Japanese language doesn't have uppercase nor lowercase
> letters. However, this is "Style Guidelines", so I think
> this is not a problem, because the specification already
> says that "Style Guideline" and "Presentation Option" are
> not mandatory.

Resolution:
Revised Text: Notation issues from Japanese ISO review - italics and certain characters made optional
Actions taken:
December 9, 2000: received issue
May 24, 2001: closed issue

Issue 4187: class TaggedValuewill two association-ends with the same name "stereotype" (uml-rtf)

Click here for this issue's archive.
Source: Capable Objects (Mr. Anders Ivner, anders.ivner(at)capableobjects.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the physical metamodel for extensions (Figure 6-8) the class
TaggedValuewill have two association-ends with the same name "stereotype".
One
from the association with the superclass ModelElement
(extendedElement-stereotype) and one on its own (requiredTag-stereotype).

Resolution: in Uml 1.4 final, there is only one association end with this name
Revised Text:
Actions taken:
January 31, 2001: received issue
October 23, 2002: closed issue

Discussion:

Issue 4300: issues and bugs on the UML 1.4 Draft (uml-rtf)

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

This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

----Begin of issues----------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

(p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

(p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

(p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

(p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

Please clarify or correct the statement.

(p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

(p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

(p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

(p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

(p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

(p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

(p. 3-3) Typographical/Editorial: There is no Part 8.

(p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

(p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

(p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

(p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

(p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

(p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

(p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

(p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

(p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

Please clarify

Resolution: see below
Revised Text: Various small edits, mostly in Section 2, plus a few in Sections 3 and 5: (p. 2-47, ModelElement) Accepted 1.4.1. : added editorial clarification "(even though not displayed explicitly for ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument)" (p. 2-98, Uninterpreted)Accept 1.4.1. Text is removed (This is not reflected in the Abstract Sytax nor XMI). (p. 2-106) Accept 1.4.1.: changed order (p. 2-111, Stimulus) Accept 1.4.1. 2.9.2.21 - Replace with Stimulus in the text (p. 2-182,2-183) Accept 1.4.1 editorial (p. 3-15, Type-Instance Correspondence) Accept 1.4.1. : Replaced examples with "UseCase and UseCaseInstance, Message - Stimulus" (p. 3-22, Subsystem - Presentation Options) Accept for 1.4.1. : sentence added to 3.13.3 (figure was already present) (p. 3-59, Stereotype Declaration - Semantics) Accept 1.4.1: the word "below" is replaced with "above" to be consistent with the diagram (p. 5-32, Figure 5-9) Accept 1.4.1 : caption updated
Actions taken:
May 13, 2001: received issue
October 23, 2002: closed issue

Discussion:

The following sub-points are referenced in the issue text:
(p. xi) Already fixed in 1.4 final specification
(p. xxi) Already fixed in 1.4 final specification
(p. 2-34, Component) Rejected. This is modeled through "!visibilityKind" on ElementImport
(p. 2-46, Interface) Rejected. This is modeled through Realization Dependency
(p. 2-47, ModelElement) Accepted 1.4.1. Clarify editorial ... (even though not displayed explicitly for ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument)
(p. 2-95, 2-98, Integer, String, UnlimitedInteger) Defer 2.0 (major). UML 2.0 will re-architect the meta model area.
(p. 2-98, Uninterpreted)Accept 1.4.1. Text will be removed (This is not reflected in the Abstract Sytax nor XMI).
(p. 2-106) Accept 1.4.1.
(p. 2-111, Stimulus) Accept 1.4.1. 2.9.2.21 - Replace with Stimulus in the text
(p. 2-139, Overview and 2-142, UseCase) Defer 2.0 (major). Adding ActorInstance will impact the DTD. Instance modleing in general to be reviewed in UML 2.0 
(p. 2-182,2-183) Accept 1.4.1 editorial
(p. 3-3) Fixed in UML 1.4 final.
(p. 3-15, Type-Instance Correspondence) Accept 1.4.1. Replace examples with "UseCase and UseCaseInstance, Message - Stimulus" or remove examples altogether
(p. 3-22, Subsystem - Presentation Options) Accept for 1.4.1. Add sentence to 3.13.3
(p. 3-59, Stereotype Declaration - Semantics) Accept 1.4.1
(p. 3-60, Stereotype Declaration - Notation) Defer (2.0 major). This is not a Dependency in the metamodel - rather it is overloading the notation. Profiles expected to be addressed in UML 2.0
(p. 5-21?, Chapter 5) Already fixed in 1.4 final
(p. 5-24, Figure 5-1) Defer 2.0 (major). This has a ripple effect on the DTD. UML 2.0 expected to address meta model architecture issues.
(p. 5-31, Figure 5-8) Defer 2.0 (minor). This is an error in chapter 5. Deferred because it would touch the DTD.
(p. 5-32, Figure 5-9) Accept 1.4.1
(p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) Rejected for 1.4.1. These are derived associations and hence do not show in the physical model and DTD

Issue 4349: 2.9.2 Abstract Syntax (uml-rtf)

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

In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'. 

This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

Resolution: editorial fix : Rose truncating the diagram, Previously fixed.
Revised Text:
Actions taken:
June 18, 2001: received issue
October 23, 2002: closed issue

Issue 4450: Wf 2 for AssociationEnd (uml-rtf)

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

The second wf rule for AssociationEnd uses the OCL operation
     applied to the wrong type (max applied to multiplicities).

Resolution: obvious error, OCL only fix.
Revised Text: Updated section 2.5.3.3 by defining OCL operation "upperbound", similar to defined in Action Semantics specification (ad/02-01-09)
Actions taken:
August 3, 2001: received issue
October 23, 2002: closed issue

Issue 4453: it's => its on page 3-150. (uml-rtf)

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

it's => its on page 3-150.

Resolution: editorial fix
Revised Text:
Actions taken:
August 3, 2001: received issue
October 23, 2002: closed issue

Issue 4454: The glossary entry "call" should be "call state". (uml-rtf)

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

The glossary entry "call" should be "call state".

Resolution: Change the name of the glossary entry
Revised Text: Glossary entry, B-4
Actions taken:
August 3, 2001: received issue
October 23, 2002: closed issue

Issue 4463: Notation example typo in Fig. 3-99 (uml-rtf)

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

In the example the dependencies between the focus class and the two
auxiliary classes should connect to the target interfaces of the auxiliary
classes, rather than their class rectangles. (Note: this typo may be
corrected in the formal version of the UML 1.4 specification, which is not
yet available.)

Resolution: Diagram to be fixed
Revised Text: Fig. 3-98
Actions taken:
August 3, 2001: received issue
October 23, 2002: closed issue

Issue 4466: Compliance ambiguity (uml-rtf)

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

Although the current specification defines the basic units of
compliance for UML, it does not clearly specify the extent to which they may
be omitted (via the "no/incomplete" Valid Options in the summary table on p.
xxv) before the implementation is not considered OMG UML.  (As a degenerate
case, it could be argued that they all could be omitted and that an
implementation might still claim compliance.) Further note that the optional
compliance of OCL is discussed as a special case on p. xxiii, although no
special treatment of its compliance is reflected in the summary table.
Optional compliance needs to be more clearly specified before we consider
future optional compliance points, as some are proposing for the Action
Semantics.

Resolution: duplicate
Revised Text:
Actions taken:
August 3, 2001: received issue

Discussion:

This issue of basic units of compliance, extent of compliance and the question of
�omitted� compliance are all incorporated in issue 6248. The issue of OCL compliance is
subject of the UML 2.0 OCL specification and not this specification.

Issue 4508: page 2-163, the statemachine semantics escription (uml-rtf)

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

I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty 

I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state. 

On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add? 

On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

Resolution: see above
Revised Text: 1st pt.: Section 2.12.3.5 WFR 3. 3rd. pt.: Section 2.12.5.2
Actions taken:
August 17, 2001: received issue
October 23, 2002: closed issue

Discussion:

First point re: pg. 2-163 is valid. Change the text for the third WF rule of
StateMachine to read:  "A top state cannot be directly contained in any other state"
The second point re pg. 2-168 is rejected: there is an explicit statement that actually describes the order of execution. ("...executed in sequence, starting with the innermost active state in the current state configuraiton")
The third point re: pg. 2-176 is valid. The single quotation mark (') at the end of the specified line should be replaced by a semicolon (;).

Issue 4531: Figure 2-15 of the uml 1.4 spec (uml-rtf)

Nature: Clarification
Severity: Minor
Summary:

Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

Resolution: editorial fix in diagram: metaclass name is truncated (ModelElement => Model�). Duplicate of 4349
Revised Text:
Actions taken:
August 23, 2001: received issue
October 23, 2002: closed issue

Issue 4534: well-formedness rule for Package is missing inUML 1.4 (uml-rtf)

Click here for this issue's archive.
Source: Enea Business Software (Ms. Karin Palmkvist, nobody)
Nature: Clarification
Severity: Minor
Summary:

A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

Resolution: The rule seems to have unintentionally disappeared from 1.3 to 1.4.
Revised Text: Section 2.14.3.3
Actions taken:
August 24, 2001: received issue
October 23, 2002: closed issue

Issue 5433: How to properly designate exception returned from message sent to Java obje (uml-rtf)

Click here for this issue's archive.
Source: ObjectShare (Ms. Rebecca Wirfs-Brock, rebecca(at)parcplace.com)
Nature: Clarification
Severity: Critical
Summary:

I am trying to properly designate an exception returned from a message sent to a Java object. 

In UML a return is drawn as a dashed line with an open arrow. But is that the same for an exception returned? I can stereotype a return with the <<exception>> which is fine , but how do I properly draw the returned exception. I don't think the exception should be drawn the same as an asynchronous signal because control pops out from the exception raiser and returns to the callee at the exception handling point (it is the result of the original call, but the exception return is to a different point in the flow).... so it isn't exactly a signal.... but it does alter the control flow.. 

So in my mind, if I wanted to show a returned exception, I should draw it like a return (dashed line with open stick arrowhead) labelled <<exception>> 

But I defer to someone with more expertise to untangle this for me. I spent time and could not find an answer to this in the UML 1.4 docs

Resolution: This is a subset of the issue addressed by issue 7397.
Revised Text:
Actions taken:
June 17, 2002: received issue
December 2, 2004: closed issue

Issue 5733: There is a bug in additional operation 1 of the Namespace element (uml-rtf)

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

There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: �contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)�.

Resolution: Issue 4848 also raises a similar problem with Namespace.contents
Revised Text:
Actions taken:
October 31, 2002: received issue
December 2, 2004: closed issue

Issue 5923: isPolymorphic is never in a diagram (uml-rtf)

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

2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic); 

2.5.4.3 Class has methods which can be polymorphic (isPolymorphic) 

2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic) 

But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

Resolution: This is a duplicate of issue 4617,
Revised Text:
Actions taken:
April 30, 2000: received issue
December 2, 2004: closed issue