Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 402
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML14-1046 Type vs. Implementastion class UML 1.1 UML 1.2 Resolved closed
OCL231-38 Lack of features commonly used in OCL UML 1.1 OCL 2.3.1 Resolved closed
UML14-1044 Wording od OCL definition UML 1.1 UML 1.2 Resolved closed
UML14-1042 Package symbol as a polygon UML 1.1 UML 1.3 Resolved closed
UML14-957 OCL issue UML 1.1 UML 1.3 Resolved closed
UML14-956 Strange GENERAl USE RESTRICTION UML 1.1 UML 1.3 Resolved closed
UML14-955 Error in the third postcondition for String::concat on page 6-31 UML 1.1 UML 1.3 Resolved closed
UML14-954 The not-equals operator, "<>", UML 1.1 UML 1.3 Resolved closed
UML14-953 Divide operator is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-952 pages 6-28 to 6-29 of OCL documentation UML 1.1 UML 1.3 Resolved closed
UML14-951 page 6-10 of OCL documentation for 1.3alphaR5 UML 1.1 UML 1.3 Resolved closed
UML14-950 The postcondition seems to be incorrect for sequence::subSequence UML 1.1 UML 1.3 Resolved closed
UML14-949 The postcondition on set::collect seems to be incorrect UML 1.1 UML 1.3 Resolved closed
UML14-948 The second postcondition on Integer::div is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-947 (Minor) Activity diagram change recommendation UML 1.1 UML 1.3 Resolved closed
UML14-946 OCL Standard package UML 1.1 UML 1.3 Resolved closed
UML14-945 There is an association between between Constraint and ModelElement UML 1.1 UML 1.3 Resolved closed
UML14-944 OCL should allow one constraint to reference another UML 1.1 UML 1.3 Resolved closed
UML14-943 UML has symbol for multiobject, not for multi-instances of other classifie UML 1.1 UML 1.3 Resolved closed
UML14-942 Dependencies (and other relationships) with role ends UML 1.1 UML 1.3 Resolved closed
UML14-941 action state symbol/state symbol difficult to distinguish when drawn by ha UML 1.1 UML 1.3 Resolved closed
UML14-940 UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99 UML 1.1 UML 1.4 Resolved closed
UML14-939 Add Responsibilities as a new metatype UML 1.1 UML 1.3 Resolved closed
UML14-938 Interface issue UML 1.1 UML 1.3 Resolved closed
UML14-937 Only single stereotyping is supported UML 1.1 UML 1.3 Resolved closed
UML14-936 Use of black diamond in the metamodel UML 1.1 UML 1.3 Resolved closed
UML14-935 On aggregation. The white diamond name should be "shareable" UML 1.1 UML 1.3 Resolved closed
UML14-934 Metamodel and semantics for aggregations UML 1.1 UML 1.3 Resolved closed
UML14-933 Some attributes can be expressed in OCL UML 1.1 UML 1.4 Resolved closed
UML14-932 Widen the naming characteristics UML 1.1 UML 1.3 Resolved closed
UML14-931 BooleanExpression written in OCL or some other language? UML 1.1 UML 1.3 Resolved closed
UML14-930 Generalized change events UML 1.1 UML 1.2 Resolved closed
UML14-929 There are issues that make OCL hard to formalize--document ad/98-10-01 UML 1.1 UML 1.2 Resolved closed
UML14-928 Definition of OclAny leads to problems when formalizing OCL UML 1.1 UML 1.2 Resolved closed
UML14-927 Infix operator use should be clarified UML 1.1 UML 1.2 Resolved closed
UML14-926 Set of allInstances should be referrable by the class name UML 1.1 UML 1.4 Resolved closed
UML14-925 Add "Let"-like construct to OCL UML 1.1 UML 1.2 Resolved closed
UML14-924 Common operations should be added to collection types in OCL UML 1.1 UML 1.3 Resolved closed
UML14-923 Add OCL operation to refer to all new instances created during operation UML 1.1 UML 1.2 Resolved closed
UML14-922 Need well defined way to extend OCL UML 1.1 UML 1.2 Resolved closed
UML14-921 Notation says swimlanes are packages UML 1.1 UML 1.2 Resolved closed
UML14-920 ModelElement to Partition multiplicity should be many UML 1.1 UML 1.2 Resolved closed
UML14-919 Synchronous request UML 1.1 UML 1.4 Resolved closed
UML14-918 Asynchronous action UML 1.1 UML 1.4 Resolved closed
UML14-917 Not instantiable UML 1.1 UML 1.3 Resolved closed
UML14-916 UML RTF Issue: Normative MOF-Compatible version of UML UML 1.1 UML 1.2 Resolved closed
UML14-915 Core package-backbone diagram UML 1.1 UML 1.2 Resolved closed
UML14-914 MOF does not support association attributes in metamodels. UML 1.1 UML 1.2 Resolved closed
UML14-913 issue: Missing association names UML 1.1 UML 1.2 Resolved closed
UML14-912 Issue: Missing role names UML 1.1 UML 1.2 Resolved closed
UML14-911 Issue: Inheritance inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-910 Issue: Action does not define attributes UML 1.1 UML 1.2 Resolved closed
UML14-909 Issue: Name attribute inheritance UML 1.1 UML 1.2 Resolved closed
UML14-908 Issue: abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-907 Figure 2-18 : redundant attributes UML 1.1 UML 1.2 Resolved closed
UML14-906 UML Semantics (page 109) UML 1.1 UML 1.2 Resolved closed
UML14-905 Association attributes UML 1.1 UML 1.2 Resolved closed
UML14-904 missing association names UML 1.1 UML 1.2 Resolved closed
UML14-903 Issue: inheritance inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-902 Diagram missing attributes UML 1.1 UML 1.2 Resolved closed
UML14-901 Abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-900 Are subsystems instantiable? UML 1.1 UML 1.2 Resolved closed
UML14-899 Associations as parts of a composite. UML 1.1 UML 1.3 Resolved closed
UML14-898 Section 5.17 of Notation Guide: No mapping is given UML 1.1 UML 1.3 Resolved closed
UML14-897 Existance of classes in classes UML 1.1 UML 1.2 Resolved closed
UML14-896 Notation section describing activity states needed UML 1.1 UML 1.2 Resolved closed
UML14-895 States leading to joins in activity models UML 1.1 UML 1.2 Resolved closed
UML14-894 Activities operate by and on objects UML 1.1 UML 1.2 Resolved closed
UML14-893 ClassifierInState does not satisfy one of its stated usages UML 1.1 UML 1.2 Resolved closed
UML14-892 Rules 3 and 4 for Transitions in state machines should be limited UML 1.1 UML 1.3 Resolved closed
UML14-891 UML Semantics, section Common behavior UML 1.1 UML 1.2 Resolved closed
UML14-890 Notion of "conceptual" or "specification-only" not supported UML 1.1 UML 1.2 Resolved closed
UML14-889 OCL should allow the use of "let" expressions UML 1.1 UML 1.2 Resolved closed
UML14-888 Text on page 2-49 section 2.2 UML 1.1 UML 1.3 Resolved closed
UML14-887 Text in Figure 2.13.7.1 ActivityState seems to be incorrect UML 1.1 UML 1.2 Resolved closed
UML14-886 Need to have relative precedence and, or, xor UML 1.1 UML 1.2 Resolved closed
UML14-885 Need way to approximate comparisons UML 1.1 UML 1.2 Resolved closed
UML14-884 pre value of object UML 1.1 UML 1.2 Resolved closed
UML14-883 It"s mistake to automatically flatten collections of collections UML 1.1 UML 1.2 Resolved closed
UML14-882 Change events issue UML 1.1 UML 1.2 Resolved closed
UML14-881 Collection operation size not defined for infinite collections UML 1.1 UML 1.2 Resolved closed
UML14-880 States of an object not referenceable from OCL expression UML 1.1 UML 1.2 Resolved closed
UML14-879 Implicit transitive import between packages UML 1.1 UML 1.2 Resolved closed
UML14-878 Protocol state diagrams issue UML 1.1 UML 1.2 Resolved closed
UML14-877 Changes to figure 15 and description of ClassifierRole on page 82 UML 1.1 UML 1.2 Resolved closed
UML14-876 Semantics for dynamic invocation of concurrent activity models are missing UML 1.1 UML 1.2 Resolved closed
UML14-875 Collection type within OCL missing UML 1.1 UML 1.2 Resolved closed
UML14-874 Operation asSequence Issue UML 1.1 UML 1.2 Resolved closed
UML14-873 No discription of the association between Classifier and Parameter is give UML 1.1 UML 1.2 Resolved closed
UML14-872 Stereotypes on Dependency, page 43 of V 1.1 (figure 7) UML 1.1 UML 1.2 Resolved closed
UML14-871 Reflexive association in section 5.20.2 UML 1.1 UML 1.2 Resolved closed
UML14-870 The class "Subsystem" inherits from "GeneralizedElement" twice UML 1.1 UML 1.2 Resolved closed
UML14-869 Class "Model" is too prescriptive UML 1.1 UML 1.2 Resolved closed
UML14-868 Clarify how types of attributes and parameters should be instantiated UML 1.1 UML 1.2 Resolved closed
UML14-867 Merge "Class" and "Interface" into one class UML 1.1 UML 1.2 Resolved closed
UML14-866 UML 1.1 issue on Associations UML 1.1 UML 1.2 Resolved closed
UML14-865 Extension Point UML 1.1 UML 1.2 Resolved closed
UML14-864 Specification for method in a derived class UML 1.1 UML 1.2 Resolved closed
UML14-863 State diagrams: action expressions UML 1.1 UML 1.2 Resolved closed
UML14-862 Permit multiple stereotyping on relationship UML 1.1 UML 1.2 Resolved closed
UML14-861 General recommended use of UML UML 1.1 UML 1.2 Resolved closed
UML14-860 Responsibilities hardly figure in these documents UML 1.1 UML 1.2 Resolved closed
UML14-859 "Inheritance" connection used is a generalization relationship UML 1.1 UML 1.2 Resolved closed
UML14-858 Aggregation is poorly defined UML 1.1 UML 1.2 Resolved closed
UML14-857 Page 98: arrowhead issue UML 1.1 UML 1.2 Resolved closed
UML14-856 Page 94 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-855 Page 82: Add explanation UML 1.1 UML 1.2 Resolved closed
UML14-854 Page 80: Confusion with headings UML 1.1 UML 1.2 Resolved closed
UML14-853 Page 79: Poor choice of arrowhead UML 1.1 UML 1.2 Resolved closed
UML14-852 Page 72: Example needs rejigging UML 1.1 UML 1.2 Resolved closed
UML14-851 Page 71: Distinction between Dependency and Association UML 1.1 UML 1.2 Resolved closed
UML14-850 Page 68 overlapping UML 1.1 UML 1.2 Resolved closed
UML14-849 Page 67: Why is discriminator not discussed in terms of power types? UML 1.1 UML 1.2 Resolved closed
UML14-848 Page 58: Add index entry UML 1.1 UML 1.2 Resolved closed
UML14-847 Page 57: mathematical issue UML 1.1 UML 1.2 Resolved closed
UML14-846 Page 52 figure 20 UML 1.1 UML 1.2 Resolved closed
UML14-845 Typos on pages 24, 40, and 50 UML 1.1 UML 1.2 Resolved closed
UML14-844 Page 35/6: Why are attributes and association not inherited? UML 1.1 UML 1.2 Resolved closed
UML14-843 Page 35/6: Use of word type is confusing UML 1.1 UML 1.2 Resolved closed
UML14-842 Page 35/6 : Stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-841 Page 30: Class scope attribute underlined UML 1.1 UML 1.2 Resolved closed
UML14-840 Page 29: Protected member UML 1.1 UML 1.2 Resolved closed
UML14-839 Page 26: rename reponsibilities, rules, modification histories etc. UML 1.1 UML 1.2 Resolved closed
UML14-838 Page 24 Section 5.4.3 para 1: missing compartments UML 1.1 UML 1.2 Resolved closed
UML14-837 Page 24: add link to Interface UML 1.1 UML 1.2 Resolved closed
UML14-836 Page 20: Section 4.3.1 could be misleading UML 1.1 UML 1.2 Resolved closed
UML14-835 Page 13: Packages are GeneralizableElements UML 1.1 UML 1.2 Resolved closed
UML14-834 Page 11: Operation-Call UML 1.1 UML 1.2 Resolved closed
UML14-833 Editorials on pages iv, v, 3, and 4 UML 1.1 UML 1.2 Resolved closed
UML14-832 Typos on page 90, 151 plus errors in page numbering UML 1.1 UML 1.2 Resolved closed
UML14-831 Page 143: "uses" as a stereotype on Generalization UML 1.1 UML 1.2 Resolved closed
UML14-830 Page 143: uses is a stereotyped dependency UML 1.1 UML 1.2 Resolved closed
UML14-829 Page 136: Model package relationship UML 1.1 UML 1.2 Resolved closed
UML14-828 Page 98: Transition is an aggregation of guards UML 1.1 UML 1.2 Resolved closed
UML14-827 Uses and extends not types of generalization UML 1.1 UML 1.2 Resolved closed
UML14-826 Page 93: use case UML 1.1 UML 1.2 Resolved closed
UML14-825 Page 93: Is Namespace really aggregeation of use cases? UML 1.1 UML 1.2 Resolved closed
UML14-824 Discussion on Collaborations and Interactions is confusing UML 1.1 UML 1.2 Resolved closed
UML14-823 Typos on pages 55 and 62 UML 1.1 UML 1.2 Resolved closed
UML14-822 Page 50 Table 3 "refinement" UML 1.1 UML 1.2 Resolved closed
UML14-821 Page 50: table 3 component UML 1.1 UML 1.2 Resolved closed
UML14-820 Page 50: should stereotypes be defined at the subclass level? UML 1.1 UML 1.2 Resolved closed
UML14-819 Page 50: "instance" should be changed to "instatiate" UML 1.1 UML 1.2 Resolved closed
UML14-818 Page 47: Dependency is a unidirectional, client-server UML 1.1 UML 1.2 Resolved closed
UML14-817 Page 45 dependency lines 2/3 between model elements not instances? UML 1.1 UML 1.2 Resolved closed
UML14-816 Aggregation of class? UML 1.1 UML 1.2 Resolved closed
UML14-815 Page 40 table 2 Model Element class UML 1.1 UML 1.2 Resolved closed
UML14-814 Page 38 para 2 line 3, one of its containers is deleted UML 1.1 UML 1.2 Resolved closed
UML14-813 Page 35 Diagram (02) UML 1.1 UML 1.2 Resolved closed
UML14-812 Page 35 -Diagram UML 1.1 UML 1.2 Resolved closed
UML14-811 Class to be defined as an intension UML 1.1 UML 1.2 Resolved closed
UML14-810 How to stop an interface realizing a Data Type ? UML 1.1 UML 1.2 Resolved closed
UML14-809 Why does GeneralizableElement inherit from Namespace? UML 1.1 UML 1.2 Resolved closed
UML14-808 Page 16 ---editorial (Element Ownership) UML 1.1 UML 1.2 Resolved closed
UML14-807 Is name space really a *composite aggregation* of model elements? UML 1.1 UML 1.2 Resolved closed
UML14-806 Page 16 lost fact that Class realizes an interface UML 1.1 UML 1.2 Resolved closed
UML14-805 Interface must also have features UML 1.1 UML 1.2 Resolved closed
UML14-804 Why is Classifier an Aggregate of Features? UML 1.1 UML 1.2 Resolved closed
UML14-803 Collaboration as a Classifier UML 1.1 UML 1.2 Resolved closed
UML14-802 Interfaces and support classes UML 1.1 UML 1.2 Resolved closed
UML14-801 UML Semantics, p 81, 145 UML 1.1 UML 1.2 Resolved closed
UML14-800 Extension/recommendation needed for inner/outer transitions UML 1.1 UML 1.2 Resolved closed
UML14-799 Notation for state machine inheritance UML 1.1 UML 1.2 Resolved closed
UML14-798 UseCaseInstance badly defined UML 1.1 UML 1.2 Resolved closed
UML14-797 Semantics of terminate transitions UML 1.1 UML 1.2 Resolved closed
UML14-796 Multiple transitions from initial states should be allowed UML 1.1 UML 1.2 Resolved closed
UML14-795 Modeling of guards UML 1.1 UML 1.2 Resolved closed
UML14-794 Collaboration::constrainingElement semantics UML 1.1 UML 1.2 Resolved closed
UML14-793 Collaboration showing instances UML 1.1 UML 1.2 Resolved closed
UML14-792 Inconsistency between stereotype tables UML 1.1 UML 1.2 Resolved closed
UML14-791 Stereotype modeled in two ways UML 1.1 UML 1.2 Resolved closed
UML14-790 Stereotypes for superclasses do not apply to superclasses UML 1.1 UML 1.2 Resolved closed
UML14-789 Inconsistent use of stereotypes, tagged values, and metamodel UML 1.1 UML 1.2 Resolved closed
UML14-788 Class WFR (01) UML 1.1 UML 1.2 Resolved closed
UML14-787 Modeling of realization/specification UML 1.1 UML 1.2 Resolved closed
UML14-786 GeneralizableElement should not inherit from Namespace UML 1.1 UML 1.2 Resolved closed
UML14-785 Syntax for Sequence Expressions inconsistently used UML 1.1 UML 1.2 Resolved closed
UML14-784 Threads of control in Collaboration Diagrams UML 1.1 UML 1.2 Resolved closed
UML14-783 Control Flow types not modeled UML 1.1 UML 1.2 Resolved closed
UML14-782 RaiseAction and TimingMark are not defined UML 1.1 UML 1.2 Resolved closed
UML14-781 Mapping of concurrent subregions UML 1.1 UML 1.2 Resolved closed
UML14-780 "do" action not supported UML 1.1 UML 1.2 Resolved closed
UML14-779 Notation for iteration in sequence diagram UML 1.1 UML 1.2 Resolved closed
UML14-778 "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-777 <>, <>, <>, <>, not well supported UML 1.1 UML 1.2 Resolved closed
UML14-776 Namespace in case of containment UML 1.1 UML 1.2 Resolved closed
UML14-775 WFR for bound elements missing UML 1.1 UML 1.2 Resolved closed
UML14-774 The meta-type of template parameters UML 1.1 UML 1.2 Resolved closed
UML14-773 Dependency wrongly mapped UML 1.1 UML 1.2 Resolved closed
UML14-772 Package importing transitive UML 1.1 UML 1.2 Resolved closed
UML14-771 "invoked" not defined UML 1.1 UML 1.2 Resolved closed
UML14-770 Bad example for LCA, main source, main target UML 1.1 UML 1.3 Resolved closed
UML14-769 Transition WFR badly written UML 1.1 UML 1.3 Resolved closed
UML14-768 Entry/Exit actions execution order UML 1.1 UML 1.2 Resolved closed
UML14-767 CompositeStates with non-composite subregions allowed UML 1.1 UML 1.2 Resolved closed
UML14-766 Message::base undefined UML 1.1 UML 1.2 Resolved closed
UML14-765 AssociationEnd-AssociationEndRole inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-764 Argument::type not defined UML 1.1 UML 1.2 Resolved closed
UML14-763 MessageInstance not used UML 1.1 UML 1.2 Resolved closed
UML14-762 WFR for instance links UML 1.1 UML 1.2 Resolved closed
UML14-761 Well-formedness Rules for Action::actualArguments UML 1.1 UML 1.2 Resolved closed
UML14-760 CallAction::request UML 1.1 UML 1.2 Resolved closed
UML14-759 CallAction::isAsynchronous and CallAction::mode UML 1.1 UML 1.2 Resolved closed
UML14-758 Action::isAsynchronous and Action::script not defined UML 1.1 UML 1.2 Resolved closed
UML14-757 Signal::isAsynchronous and Signal::direction not defined UML 1.1 UML 1.2 Resolved closed
UML14-756 Request"s parents UML 1.1 UML 1.2 Resolved closed
UML14-755 "implementation" association not defined UML 1.1 UML 1.2 Resolved closed
UML14-754 Node and Component parent UML 1.1 UML 1.2 Resolved closed
UML14-753 Qualifier badly modeled UML 1.1 UML 1.2 Resolved closed
UML14-752 Signature conflicts across an inheritance hierarchy UML 1.1 UML 1.2 Resolved closed
UML14-751 Exotic uses of generalization UML 1.1 UML 1.2 Resolved closed
UML14-750 Set of inheritable features not defined UML 1.1 UML 1.3 Resolved closed
UML14-749 Correspondence between operation and method (02) UML 1.1 UML 1.3 Resolved closed
UML14-748 Correspondence between operation and method UML 1.1 UML 1.2 Resolved closed
UML14-747 Use of language-dependant type expressions UML 1.1 UML 1.2 Resolved closed
UML14-746 Return types for BehavioralFeatures UML 1.1 UML 1.2 Resolved closed
UML14-745 Package importing not well supported UML 1.1 UML 1.2 Resolved closed
UML14-744 Signature conflicts not well defined (02) UML 1.1 UML 1.2 Resolved closed
UML14-743 Features and ownedElements (2) UML 1.1 UML 1.2 Resolved closed
UML14-742 "feature" defined twice UML 1.1 UML 1.2 Resolved closed
UML14-741 Features and ownedElements (1) UML 1.1 UML 1.2 Resolved closed
UML14-740 Signature conflicts not well defined UML 1.1 UML 1.2 Resolved closed
UML14-739 UML Semantics 1.1, p26, Operation::isPolymorphic UML 1.1 UML 1.2 Resolved closed
UML14-738 OCL Specification 1.1, section 8 UML 1.1 UML 1.2 Resolved closed
UML14-737 OCL specification 1.1, p. 14, 5.13, example UML 1.1 UML 1.2 Resolved closed
UML14-736 OCL specification 1.1, p. 15, 5.14, second last paragraph UML 1.1 UML 1.2 Resolved closed
UML14-735 OCL specification 1.1, p. 24, 7.1.7 UML 1.1 UML 1.2 Resolved closed
UML14-734 OCL specification 1.1, p. 30, 7.2.4 UML 1.1 UML 1.2 Resolved closed
UML14-733 OCL specification 1.1, p. 32 UML 1.1 UML 1.3 Resolved closed
UML14-732 OCL specification 1.1, p. 10, 5.4.3, example 3 UML 1.1 UML 1.2 Resolved closed
UML14-731 OCL specification 1.1, section 7.2.2 UML 1.1 UML 1.2 Resolved closed
UML14-730 Definition of select and reject operations for Set"s is erranious UML 1.1 UML 1.2 Resolved closed
UML14-729 Difference between methods, attributes and operations not clear UML 1.1 UML 1.2 Resolved closed
UML14-728 Editorial issue: OCL spec 1.1, section 6.3, example 2, last row UML 1.1 UML 1.2 Resolved closed
UML14-727 UML 1.1 Semantics, section 8.2, page 66 UML 1.1 UML 1.2 Resolved closed
UML14-726 Contents of section "Control Icons" is vague UML 1.1 UML 1.2 Resolved closed
UML14-725 Missing word - editorial UML 1.1 UML 1.2 Resolved closed
UML14-724 Procedure undefined UML 1.1 UML 1.2 Resolved closed
UML14-723 Missing sentence UML 1.1 UML 1.2 Resolved closed
UML14-722 Editorial error in Semantics UML 1.1 UML 1.2 Resolved closed
UML14-721 ActionState implicit deferring of events UML 1.1 UML 1.2 Resolved closed
UML14-720 internalTransition UML 1.1 UML 1.2 Resolved closed
UML14-719 deferredEvent mentioned twice in Abstract Syntax UML 1.1 UML 1.2 Resolved closed
UML14-718 Deep History Vertex UML 1.1 UML 1.2 Resolved closed
UML14-717 Inconsistent definition of extends relationship UML 1.1 UML 1.2 Resolved closed
UML14-716 No notation for ActivityState UML 1.1 UML 1.2 Resolved closed
UML14-715 No mapping for TimingMark in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-714 No mapping for "transition string" UML 1.1 UML 1.2 Resolved closed
UML14-713 No mapping for send/receive time in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-712 No mapping for swimlanes in Sequence Diagram UML 1.1 UML 1.3 Resolved closed
UML14-711 Property "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-710 Interface specifier not mapped UML 1.1 UML 1.2 Resolved closed
UML14-709 Inconsistent constraint for discriminator UML 1.1 UML 1.2 Resolved closed
UML14-708 Missing notation for templates UML 1.1 UML 1.2 Resolved closed
UML14-707 Confusing text UML 1.1 UML 1.2 Resolved closed
UML14-706 Missing mapping for directed constraint UML 1.1 UML 1.2 Resolved closed
UML14-705 Well-formedness rules only expressed in English UML 1.1 UML 1.3 Resolved closed
UML14-704 Well-formedness rules missing UML 1.1 UML 1.2 Resolved closed
UML14-703 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-702 Inconsistent definition of stereotype " process" UML 1.1 UML 1.2 Resolved closed
UML14-701 Inconsistent definition of enumeration UML 1.1 UML 1.2 Resolved closed
UML14-700 Stereotypes applied to more than one ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-699 English contradicts OCL in rule for CompositeState UML 1.1 UML 1.2 Resolved closed
UML14-698 Misleading name Link.linkRole UML 1.1 UML 1.2 Resolved closed
UML14-697 Enumeration OperationDirectionKind obsolete UML 1.1 UML 1.2 Resolved closed
UML14-696 ordered missing for Constraint.constrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-695 Inconsistent definition of stereotype "friend" UML 1.1 UML 1.2 Resolved closed
UML14-694 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-693 Wrong aggregation kind for templates UML 1.1 UML 1.2 Resolved closed
UML14-692 Method visibility UML 1.1 UML 1.2 Resolved closed
UML14-691 Feature.owner must be optional UML 1.1 UML 1.2 Resolved closed
UML14-690 Extension points of operations not defined UML 1.1 UML 1.2 Resolved closed
UML14-689 Inconsistent attachment of Activity Diagram UML 1.1 UML 1.2 Resolved closed
UML14-688 Inconsistent definition of state machine attachment UML 1.1 UML 1.2 Resolved closed
UML14-687 Inconsistent format of signal/event UML 1.1 UML 1.2 Resolved closed
UML14-686 More arrow types than message kinds UML 1.1 UML 1.2 Resolved closed
UML14-685 Inconsistent mapping of labels in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-684 Attachment of message in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-683 UML 1.0: Unknown model element "Qualifier" UML 1.1 UML 1.2 Resolved closed
UML14-682 UML 1.0: "role" should be "end" UML 1.1 UML 1.2 Resolved closed
UML14-681 UML 1.0: Template example cannot be representaed in model UML 1.1 UML 1.3 Resolved closed
UML14-680 UML 1.0: Inconsistent name of stereotype "import" UML 1.1 UML 1.2 Resolved closed
UML14-679 UML 1.0: multiplicity "unspecified" not possible UML 1.1 UML 1.2 Resolved closed
UML14-678 UML 1.0: Stereotype "uses" applied to more than one class UML 1.1 UML 1.2 Resolved closed
UML14-677 Inconsistent name for stereotype implementationClass UML 1.1 UML 1.2 Resolved closed
UML14-676 Inconsistent name space rules UML 1.1 UML 1.2 Resolved closed
UML14-675 UML 1.0: instances UML 1.1 UML 1.3 Resolved closed
UML14-674 UML 1.0: Inconsistent arrow heads for dependencies UML 1.1 UML 1.2 Resolved closed
UML14-673 UML 1.0: Tagged value "location" UML 1.1 UML 1.2 Resolved closed
UML14-672 UML 1.0: Inconsistent mapping of interface circles UML 1.1 UML 1.2 Resolved closed
UML14-671 UML 1.0: Node/Component Instances not defined UML 1.1 UML 1.2 Resolved closed
UML14-670 UML 1.0: No notation for ModelElement.implementation etc. UML 1.1 UML 1.2 Resolved closed
UML14-669 UML 1.0: Attachment of messages in Collaboration Diagrams UML 1.1 UML 1.2 Resolved closed
UML14-668 UML 1.0: No notation for ClassifierRole.availableFeature UML 1.1 UML 1.2 Resolved closed
UML14-667 UML 1.0: Collaborations and Association (role) UML 1.1 UML 1.2 Resolved closed
UML14-666 UML 1.o: Qualified things in Collaborations UML 1.1 UML 1.2 Resolved closed
UML14-665 UML 1.0: Collaborations not well defined UML 1.1 UML 1.2 Resolved closed
UML14-664 CallEvent: operation label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-663 Signal label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-662 Figure 15, AssociationRole class issue UML 1.1 UML 1.2 Resolved closed
UML14-661 Collaboration package: constrainingElement aggregation misdrawn UML 1.1 UML 1.2 Resolved closed
UML14-660 Collaborations package--editorial UML 1.1 UML 1.2 Resolved closed
UML14-659 Description of ActionSequence indicates that it is composition of Actions UML 1.1 UML 1.2 Resolved closed
UML14-658 ActionSequence class issue UML 1.1 UML 1.2 Resolved closed
UML14-657 Reception class has wrong attribute UML 1.1 UML 1.2 Resolved closed
UML14-656 Figure 12 shows no attributes for exceptions UML 1.1 UML 1.2 Resolved closed
UML14-655 Behavioral Features called context UML 1.1 UML 1.2 Resolved closed
UML14-654 Request class is not an abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-653 Action class is no abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-652 Description of ViewElement indicates that it is subclass of Element UML 1.1 UML 1.2 Resolved closed
UML14-651 Comment class shown as subclass of ModelElement class UML 1.1 UML 1.2 Resolved closed
UML14-650 Description of component shown as subclass of class UML 1.1 UML 1.2 Resolved closed
UML14-649 Node class shown as subclass of classifier UML 1.1 UML 1.2 Resolved closed
UML14-648 Node class issue (01) UML 1.1 UML 1.2 Resolved closed
UML14-647 Inconsistency of UML metamodel UML 1.1 UML 1.2 Resolved closed
UML14-646 Association between Method and Operation UML 1.1 UML 1.2 Resolved closed
UML14-645 UML Notation Guide, boolean properties UML 1.1 UML 1.2 Resolved closed
UML14-644 UML Notation Guide, association ends UML 1.1 UML 1.2 Resolved closed
UML14-643 UML stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-642 UML potential inconsistency about stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-641 Inconsistency of UML metamodel UML 1.1 UML 1.2 Resolved closed
UML14-640 Parameters/Attributes need Specification Classifiers UML 1.1 UML 1.2 Resolved closed
UML14-639 Predefined LinkEnd constraints issue UML 1.1 UML 1.2 Resolved closed
UML14-638 Predefined LinkEnd constraints shown as stereotypes in Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-637 Figure 8 (Semantics, p. 44) UML 1.1 UML 1.2 Resolved closed
UML14-636 diagram fragment at start of Model section on page 136 UML 1.1 UML 1.2 Resolved closed
UML14-635 No notation defined in the Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-634 ActivityState in Figure 22 UML 1.1 UML 1.2 Resolved closed
UML14-633 well-formedness rules for BehavioralFeature UML 1.1 UML 1.2 Resolved closed
UML14-632 Well-formedness rulw [2] for Class (Semantics, p. 27-28) UML 1.1 UML 1.2 Resolved closed
UML14-631 Well-formedness rule [4] for Association UML 1.1 UML 1.2 Resolved closed
UML14-630 Figure 5 Semantics document (p. 16) UML 1.1 UML 1.2 Resolved closed
UML14-629 Second para, Section 5.16.1: conflict with statement on p 141 UML 1.1 UML 1.2 Resolved closed
UML14-628 Section 5.16.1--editorial UML 1.1 UML 1.2 Resolved closed
UML14-627 Page 53 UML semantics: base class of TaggedValue not shown UML 1.1 UML 1.2 Resolved closed
UML14-626 Page 44 UML 1.1 Semantics, figure 8: no base class for ViewElement UML 1.1 UML 1.2 Resolved closed
UML14-625 Page 44 UML 1.1 Semantics, figure 8: no component role name UML 1.1 UML 1.2 Resolved closed
UML14-624 Missing role descriptions UML 1.1 UML 1.2 Resolved closed
UML14-623 ModelElement Associations (02) UML 1.1 UML 1.2 Resolved closed
UML14-622 ModelElement Associations (01) UML 1.1 UML 1.2 Resolved closed
UML14-621 ElementOwnership subclass of ModelElement? UML 1.1 UML 1.2 Resolved closed
UML14-620 Package dependencies (09) UML 1.1 UML 1.2 Resolved closed
UML14-619 Package dependencies (08) UML 1.1 UML 1.2 Resolved closed
UML14-618 Package dependencies (07) UML 1.1 UML 1.2 Resolved closed
UML14-617 Package dependencies (06) UML 1.1 UML 1.2 Resolved closed
UML14-616 Package dependencies (05) UML 1.1 UML 1.2 Resolved closed
UML14-615 Package dependencies (03) UML 1.1 UML 1.2 Resolved closed
UML14-614 Package dependencies (02) UML 1.1 UML 1.2 Resolved closed
UML14-613 Package dependencies (01) UML 1.1 UML 1.2 Resolved closed
UML14-612 UML 1.1 bug UML 1.1 UML 1.2 Resolved closed
UML14-611 UML 1.1 Semantics: Partition (pp.121 123) UML 1.1 UML 1.2 Resolved closed
UML14-610 Page 102 of UML 1.1, StateVertex class misses description UML 1.1 UML 1.2 Resolved closed
UML14-609 Page 10 UML 1.1 Semantics, duplicate entries listed UML 1.1 UML 1.2 Resolved closed
UML14-608 Page 98 of UML 1.1 Semantics, figure 18 (02) UML 1.1 UML 1.2 Resolved closed
UML14-607 Page 98 of UML 1.1 Semantics, figure 18 UML 1.1 UML 1.2 Resolved closed
UML14-606 Page 98 of UML 1.1 Semantics, figure 17 (04) UML 1.1 UML 1.2 Resolved closed
UML14-605 Page 98 of UML 1.1 Semantics, figure 17 (03) UML 1.1 UML 1.2 Resolved closed
UML14-604 Page 98 of UML 1.1 Semantics, figure 17 (02) UML 1.1 UML 1.2 Resolved closed
UML14-603 Page 98 of UML 1.1 Semantics, figure 17 (01) UML 1.1 UML 1.2 Resolved closed
UML14-602 Page 47 of UML 1.1 Semantics, description of ViewElement UML 1.1 UML 1.2 Resolved closed
UML14-601 Page 47 of UML 1.1 Semantics, description of Refinement UML 1.1 UML 1.2 Resolved closed
UML14-600 Page 46 of UML 1.1 Semantics, description of associations for ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-599 Page 44 UML 1.1 Semantics, figure 8 UML 1.1 UML 1.2 Resolved closed
UML14-598 Page 43 of UML Semantics, figure 7 UML 1.1 UML 1.2 Resolved closed
UML14-597 Page 43 UML 1.1 Semantics, figure 7 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-596 Page 16 of UML Semantics, figure 5 UML 1.1 UML 1.2 Resolved closed
UML14-595 Page 62---editorial UML 1.1 UML 1.2 Resolved closed
UML14-594 Page 62 "PseudostateKind"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-593 Page 61 "EnumerationLiteral"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-592 Page 61: CallConcurrencyKind and EventOriginKind not defined UML 1.1 UML 1.2 Resolved closed
UML14-591 Page 60 figure 10: Data types UML 1.1 UML 1.2 Resolved closed
UML14-590 Page 9 figure 2: foundation packages UML 1.1 UML 1.2 Resolved closed
UML14-589 Page 137 table 6: Model management - Standard Elements UML 1.1 UML 1.2 Resolved closed
UML14-588 Page 50 table 3: Component model element UML 1.1 UML 1.2 Resolved closed
UML14-587 Page 50 table 3: Dependency Model elements (02) UML 1.1 UML 1.2 Resolved closed
UML14-586 Page 50 table 3: Dependency model element UML 1.1 UML 1.2 Resolved closed
UML14-585 Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele UML 1.1 UML 1.2 Resolved closed
UML14-584 Page 40 table2: Generalization model element UML 1.1 UML 1.2 Resolved closed
UML14-583 page 40 table2: Classifier model element UML 1.1 UML 1.2 Resolved closed
UML14-582 Page 40 table 2:Constraints Model UML 1.1 UML 1.2 Resolved closed
UML14-581 Page 40, table 2: Core - Standard Elements UML 1.1 UML 1.2 Resolved closed
UML14-580 Page 54 - ConstrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-579 Page 39 - ModelElement/Dependency associations UML 1.1 UML 1.2 Resolved closed
UML14-578 Page 16- The association from parameter to classifier has a 1-1 cardinalit UML 1.1 UML 1.2 Resolved closed
UML14-577 Page 121 - Partition has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-576 Page 98: ActionSequence has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-575 Page 81: message has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-574 Page 35/37 - AssociationRole UML 1.1 UML 1.2 Resolved closed
UML14-573 Page 60 - MultiplicityRange UML 1.1 UML 1.2 Resolved closed
UML14-572 Page 60 - GraphicMarker UML 1.1 UML 1.2 Resolved closed
UML14-571 Page 60 - visibilityKind UML 1.1 UML 1.2 Resolved closed
UML14-570 Page 60 - PseudostateKind UML 1.1 UML 1.2 Resolved closed
UML14-569 page 60 - EventOriginKind UML 1.1 UML 1.2 Resolved closed
UML14-568 page 60 - CallConcurrencyKind UML 1.1 UML 1.2 Resolved closed
UML14-567 Error on association owners UML 1.1 UML 1.2 Resolved closed
UML14-566 UML Documentation--Typos (07) UML 1.1 UML 1.2 Resolved closed
UML14-565 UML Documentation--Typos (06) UML 1.1 UML 1.2 Resolved closed
UML14-564 UML Documentation--Typos (05) UML 1.1 UML 1.2 Resolved closed
UML14-563 UML Documentation--Typos (04) UML 1.1 UML 1.2 Resolved closed
UML14-562 UML Documentation--Typos (03) UML 1.1 UML 1.2 Resolved closed
UML14-561 UML Documentation--Typos (02) UML 1.1 UML 1.2 Resolved closed
UML14-560 UML Documentation-Typos (01) UML 1.1 UML 1.2 Resolved closed

Issues Descriptions

Type vs. Implementastion class

  • Key: UML14-1046
  • Legacy Issue Number: 1582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the
    Notation Guide, version 1.1. Complete suggested text is availabl ein the issues"s archive

  • Reported: UML 1.1 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 04:16 GMT

Lack of features commonly used in OCL

  • Key: OCL231-38
  • Legacy Issue Number: 1790
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current specification for OCL lacks many of the features we commonly
    use when doing formal specification of class interfaces, e.g. the ability
    to specify the frame condition, the ability to specify postconditions
    case-wise, the ability to specify when exceptions are thrown, etc.

    To bring OCL closer to the state of the art, I would like to see these
    considered as future extensions.

  • Reported: UML 1.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    This issue was forked off from UML 1.x 15 years ago. It doesn't seem to have anything to do with OCL at all. But rather than throw the issue back to UML, let's address it anyway.
    One could imagine a UML extension that introduced a Frame class and an Operation.ownedFrameCondition to host it. OCL expressions could then impose the semantics.
    However a Frame would be specific to a particular implementation approach, and so it would seem more appropriate to use stereotypes to model the implementation characteristics. Perhaps one of the standard UML profiles already provides this capability.
    Disposition: Closed, no change

  • Updated: Sun, 8 Mar 2015 18:23 GMT

Wording od OCL definition

  • Key: UML14-1044
  • Legacy Issue Number: 2339
  • Status: closed  
  • Source: Anonymous
  • 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."

  • Reported: UML 1.1 — Tue, 19 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 18:22 GMT

Package symbol as a polygon

  • Key: UML14-1042
  • Legacy Issue Number: 2298
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Sat, 7 Mar 2015 03:21 GMT

OCL issue

  • Key: UML14-957
  • Legacy Issue Number: 2786
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Descriptor:
    symbols such as +, - or * in the name of a feature in Ocl expressions
    are not allowed.

  • Reported: UML 1.1 — Wed, 30 Jun 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Strange GENERAl USE RESTRICTION

  • Key: UML14-956
  • Legacy Issue Number: 2626
  • Status: closed  
  • Source: Anonymous
  • 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!)

  • Reported: UML 1.1 — Mon, 3 May 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Error in the third postcondition for String::concat on page 6-31

  • Key: UML14-955
  • Legacy Issue Number: 2573
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

The not-equals operator, "<>",

  • Key: UML14-954
  • Legacy Issue Number: 2572
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Divide operator is incorrect

  • Key: UML14-953
  • Legacy Issue Number: 2571
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

pages 6-28 to 6-29 of OCL documentation

  • Key: UML14-952
  • Legacy Issue Number: 2570
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

page 6-10 of OCL documentation for 1.3alphaR5

  • Key: UML14-951
  • Legacy Issue Number: 2569
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The postcondition seems to be incorrect for sequence::subSequence

  • Key: UML14-950
  • Legacy Issue Number: 2568
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The postcondition on set::collect seems to be incorrect

  • Key: UML14-949
  • Legacy Issue Number: 2567
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The second postcondition on Integer::div is incorrect

  • Key: UML14-948
  • Legacy Issue Number: 2566
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

(Minor) Activity diagram change recommendation

  • Key: UML14-947
  • Legacy Issue Number: 2546
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL Standard package

  • Key: UML14-946
  • Legacy Issue Number: 2544
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

There is an association between between Constraint and ModelElement

  • Key: UML14-945
  • Legacy Issue Number: 2510
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Thu, 4 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL should allow one constraint to reference another

  • Key: UML14-944
  • Legacy Issue Number: 2305
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML has symbol for multiobject, not for multi-instances of other classifie

  • Key: UML14-943
  • Legacy Issue Number: 2295
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Dependencies (and other relationships) with role ends

  • Key: UML14-942
  • Legacy Issue Number: 2294
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

action state symbol/state symbol difficult to distinguish when drawn by ha

  • Key: UML14-941
  • Legacy Issue Number: 2293
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99

  • Key: UML14-940
  • Legacy Issue Number: 2292
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add Responsibilities as a new metatype

  • Key: UML14-939
  • Legacy Issue Number: 2284
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Interface issue

  • Key: UML14-938
  • Legacy Issue Number: 2283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Interface is a kind ofclassifier and therefore has features - but it
    supposedly only has operations

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Only single stereotyping is supported

  • Key: UML14-937
  • Legacy Issue Number: 2282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only single stereotyping is supported. Multiple partitioning and
    therefore multiple partitioning would be usefully and easily added

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Use of black diamond in the metamodel

  • Key: UML14-936
  • Legacy Issue Number: 2281
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

On aggregation. The white diamond name should be "shareable"

  • Key: UML14-935
  • Legacy Issue Number: 2280
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Metamodel and semantics for aggregations

  • Key: UML14-934
  • Legacy Issue Number: 2279
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Some attributes can be expressed in OCL

  • Key: UML14-933
  • Legacy Issue Number: 2074
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Widen the naming characteristics

  • Key: UML14-932
  • Legacy Issue Number: 2073
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

BooleanExpression written in OCL or some other language?

  • Key: UML14-931
  • Legacy Issue Number: 2071
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Generalized change events

  • Key: UML14-930
  • Legacy Issue Number: 2024
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

There are issues that make OCL hard to formalize--document ad/98-10-01

  • Key: UML14-929
  • Legacy Issue Number: 2022
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 2013.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Definition of OclAny leads to problems when formalizing OCL

  • Key: UML14-928
  • Legacy Issue Number: 2021
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Infix operator use should be clarified

  • Key: UML14-927
  • Legacy Issue Number: 2018
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Set of allInstances should be referrable by the class name

  • Key: UML14-926
  • Legacy Issue Number: 2017
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add "Let"-like construct to OCL

  • Key: UML14-925
  • Legacy Issue Number: 2016
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1788.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Common operations should be added to collection types in OCL

  • Key: UML14-924
  • Legacy Issue Number: 2015
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add OCL operation to refer to all new instances created during operation

  • Key: UML14-923
  • Legacy Issue Number: 2014
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need well defined way to extend OCL

  • Key: UML14-922
  • Legacy Issue Number: 2013
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notation says swimlanes are packages

  • Key: UML14-921
  • Legacy Issue Number: 2012
  • Status: closed  
  • Source: Anonymous
  • 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]

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

ModelElement to Partition multiplicity should be many

  • Key: UML14-920
  • Legacy Issue Number: 2011
  • Status: closed  
  • Source: Anonymous
  • 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].

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Synchronous request

  • Key: UML14-919
  • Legacy Issue Number: 2006
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Asynchronous action

  • Key: UML14-918
  • Legacy Issue Number: 2004
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Not instantiable

  • Key: UML14-917
  • Legacy Issue Number: 2001
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Sat, 26 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML RTF Issue: Normative MOF-Compatible version of UML

  • Key: UML14-916
  • Legacy Issue Number: 1999
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Core package-backbone diagram

  • Key: UML14-915
  • Legacy Issue Number: 1995
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MOF does not support association attributes in metamodels.

  • Key: UML14-914
  • Legacy Issue Number: 1992
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1955.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

issue: Missing association names

  • Key: UML14-913
  • Legacy Issue Number: 1991
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Missing role names

  • Key: UML14-912
  • Legacy Issue Number: 1990
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Inheritance inconsistencies

  • Key: UML14-911
  • Legacy Issue Number: 1989
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3. (Mostly redundant with issue 1953.)

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Action does not define attributes

  • Key: UML14-910
  • Legacy Issue Number: 1988
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarifed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Name attribute inheritance

  • Key: UML14-909
  • Legacy Issue Number: 1987
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: abstract class inconsistencies

  • Key: UML14-908
  • Legacy Issue Number: 1986
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Figure 2-18 : redundant attributes

  • Key: UML14-907
  • Legacy Issue Number: 1966
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics (page 109)

  • Key: UML14-906
  • Legacy Issue Number: 1956
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Association attributes

  • Key: UML14-905
  • Legacy Issue Number: 1955
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

missing association names

  • Key: UML14-904
  • Legacy Issue Number: 1954
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: inheritance inconsistencies

  • Key: UML14-903
  • Legacy Issue Number: 1953
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Diagram missing attributes

  • Key: UML14-902
  • Legacy Issue Number: 1952
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Abstract class inconsistencies

  • Key: UML14-901
  • Legacy Issue Number: 1951
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Are subsystems instantiable?

  • Key: UML14-900
  • Legacy Issue Number: 1945
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 11 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Associations as parts of a composite.

  • Key: UML14-899
  • Legacy Issue Number: 1943
  • Status: closed  
  • Source: Anonymous
  • 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:

  • Reported: UML 1.1 — Thu, 10 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Section 5.17 of Notation Guide: No mapping is given

  • Key: UML14-898
  • Legacy Issue Number: 1940
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 9 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Existance of classes in classes

  • Key: UML14-897
  • Legacy Issue Number: 1939
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 8 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notation section describing activity states needed

  • Key: UML14-896
  • Legacy Issue Number: 1921
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no description of what an activity state should look like. The specification needs a notation section describing activity states.

  • Reported: UML 1.1 — Tue, 1 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with 1051.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

States leading to joins in activity models

  • Key: UML14-895
  • Legacy Issue Number: 1890
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Activities operate by and on objects

  • Key: UML14-894
  • Legacy Issue Number: 1888
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

ClassifierInState does not satisfy one of its stated usages

  • Key: UML14-893
  • Legacy Issue Number: 1887
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Witdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Rules 3 and 4 for Transitions in state machines should be limited

  • Key: UML14-892
  • Legacy Issue Number: 1886
  • Status: closed  
  • Source: Anonymous
  • 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].

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics, section Common behavior

  • Key: UML14-891
  • Legacy Issue Number: 1815
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Attribute "body" of Metaclass "UninterpretedAction" is redundant to
    attribute "script" of Metaclass "Action"

  • Reported: UML 1.1 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notion of "conceptual" or "specification-only" not supported

  • Key: UML14-890
  • Legacy Issue Number: 1789
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL should allow the use of "let" expressions

  • Key: UML14-889
  • Legacy Issue Number: 1781
  • Status: closed  
  • Source: Anonymous
  • 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."

  • Reported: UML 1.1 — Thu, 6 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1689.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Text on page 2-49 section 2.2

  • Key: UML14-888
  • Legacy Issue Number: 1710
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Text in Figure 2.13.7.1 ActivityState seems to be incorrect

  • Key: UML14-887
  • Legacy Issue Number: 1709
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #928.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need to have relative precedence and, or, xor

  • Key: UML14-886
  • Legacy Issue Number: 1695
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need way to approximate comparisons

  • Key: UML14-885
  • Legacy Issue Number: 1694
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: You"ll need some ways to do approximate comparisions
    if you want reals to be useful in practical specifications.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

pre value of object

  • Key: UML14-884
  • Legacy Issue Number: 1693
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

It"s mistake to automatically flatten collections of collections

  • Key: UML14-883
  • Legacy Issue Number: 1691
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Change events issue

  • Key: UML14-882
  • Legacy Issue Number: 1689
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Collection operation size not defined for infinite collections

  • Key: UML14-881
  • Legacy Issue Number: 1687
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

States of an object not referenceable from OCL expression

  • Key: UML14-880
  • Legacy Issue Number: 1678
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Implicit transitive import between packages

  • Key: UML14-879
  • Legacy Issue Number: 1664
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Protocol state diagrams issue

  • Key: UML14-878
  • Legacy Issue Number: 1663
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Changes to figure 15 and description of ClassifierRole on page 82

  • Key: UML14-877
  • Legacy Issue Number: 1651
  • Status: closed  
  • Source: Anonymous
  • 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".)

  • Reported: UML 1.1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Semantics for dynamic invocation of concurrent activity models are missing

  • Key: UML14-876
  • Legacy Issue Number: 1637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics for dynamic invocation of concurrent activity models are
    missing in the current UML version.

  • Reported: UML 1.1 — Mon, 6 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Collection type within OCL missing

  • Key: UML14-875
  • Legacy Issue Number: 1636
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Operation asSequence Issue

  • Key: UML14-874
  • Legacy Issue Number: 1635
  • Status: closed  
  • Source: Anonymous
  • 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."

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

No discription of the association between Classifier and Parameter is give

  • Key: UML14-873
  • Legacy Issue Number: 1634
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Stereotypes on Dependency, page 43 of V 1.1 (figure 7)

  • Key: UML14-872
  • Legacy Issue Number: 1579
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with 1227.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Reflexive association in section 5.20.2

  • Key: UML14-871
  • Legacy Issue Number: 1515
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

The class "Subsystem" inherits from "GeneralizedElement" twice

  • Key: UML14-870
  • Legacy Issue Number: 1510
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class "Model" is too prescriptive

  • Key: UML14-869
  • Legacy Issue Number: 1509
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: UML 1.1 — Mon, 15 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Clarify how types of attributes and parameters should be instantiated

  • Key: UML14-868
  • Legacy Issue Number: 1508
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Merge "Class" and "Interface" into one class

  • Key: UML14-867
  • Legacy Issue Number: 1507
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML 1.1 issue on Associations

  • Key: UML14-866
  • Legacy Issue Number: 1506
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 5 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Extension Point

  • Key: UML14-865
  • Legacy Issue Number: 1406
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Mon, 1 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Specification for method in a derived class

  • Key: UML14-864
  • Legacy Issue Number: 1402
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Mon, 1 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

State diagrams: action expressions

  • Key: UML14-863
  • Legacy Issue Number: 1400
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Mon, 25 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Permit multiple stereotyping on relationship

  • Key: UML14-862
  • Legacy Issue Number: 1393
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

General recommended use of UML

  • Key: UML14-861
  • Legacy Issue Number: 1392
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Responsibilities hardly figure in these documents

  • Key: UML14-860
  • Legacy Issue Number: 1391
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"Inheritance" connection used is a generalization relationship

  • Key: UML14-859
  • Legacy Issue Number: 1390
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Aggregation is poorly defined

  • Key: UML14-858
  • Legacy Issue Number: 1389
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 98: arrowhead issue

  • Key: UML14-857
  • Legacy Issue Number: 1379
  • Status: closed  
  • Source: Anonymous
  • 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!]

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 94 --editorial

  • Key: UML14-856
  • Legacy Issue Number: 1378
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 82: Add explanation

  • Key: UML14-855
  • Legacy Issue Number: 1377
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 80: Confusion with headings

  • Key: UML14-854
  • Legacy Issue Number: 1376
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 79: Poor choice of arrowhead

  • Key: UML14-853
  • Legacy Issue Number: 1375
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Consdered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 72: Example needs rejigging

  • Key: UML14-852
  • Legacy Issue Number: 1374
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Consdered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 71: Distinction between Dependency and Association

  • Key: UML14-851
  • Legacy Issue Number: 1373
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 68 overlapping

  • Key: UML14-850
  • Legacy Issue Number: 1372
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 67: Why is discriminator not discussed in terms of power types?

  • Key: UML14-849
  • Legacy Issue Number: 1371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 67 Why is discriminator no longer discussed in terms of power types?
    If correct, that was neat (in the previous version)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 58: Add index entry

  • Key: UML14-848
  • Legacy Issue Number: 1370
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Rebuild index on each release.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 57: mathematical issue

  • Key: UML14-847
  • Legacy Issue Number: 1369
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 52 figure 20

  • Key: UML14-846
  • Legacy Issue Number: 1368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 52 Figure 20. In the recursive association on Job,
    how does the Job play the role of boss or worker?

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on pages 24, 40, and 50

  • Key: UML14-845
  • Legacy Issue Number: 1367
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6: Why are attributes and association not inherited?

  • Key: UML14-844
  • Legacy Issue Number: 1366
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6: Use of word type is confusing

  • Key: UML14-843
  • Legacy Issue Number: 1365
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6 : Stereotypes

  • Key: UML14-842
  • Legacy Issue Number: 1364
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 30: Class scope attribute underlined

  • Key: UML14-841
  • Legacy Issue Number: 1363
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 29: Protected member

  • Key: UML14-840
  • Legacy Issue Number: 1362
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 26: rename reponsibilities, rules, modification histories etc.

  • Key: UML14-839
  • Legacy Issue Number: 1361
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 24 Section 5.4.3 para 1: missing compartments

  • Key: UML14-838
  • Legacy Issue Number: 1360
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 24: add link to Interface

  • Key: UML14-837
  • Legacy Issue Number: 1358
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 20: Section 4.3.1 could be misleading

  • Key: UML14-836
  • Legacy Issue Number: 1357
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 13: Packages are GeneralizableElements

  • Key: UML14-835
  • Legacy Issue Number: 1356
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarifed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 11: Operation-Call

  • Key: UML14-834
  • Legacy Issue Number: 1355
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorials on pages iv, v, 3, and 4

  • Key: UML14-833
  • Legacy Issue Number: 1354
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on page 90, 151 plus errors in page numbering

  • Key: UML14-832
  • Legacy Issue Number: 1351
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 143: "uses" as a stereotype on Generalization

  • Key: UML14-831
  • Legacy Issue Number: 1350
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 143 <<uses>> as a stereotype on Generalization. It is also an important
    stereotype on Dependency.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 143: uses is a stereotyped dependency

  • Key: UML14-830
  • Legacy Issue Number: 1349
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 136: Model package relationship

  • Key: UML14-829
  • Legacy Issue Number: 1348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 136 Model - Package relationship (in diagram) should not be
    aggregation but generalization (according to page 129, Figure 23)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 98: Transition is an aggregation of guards

  • Key: UML14-828
  • Legacy Issue Number: 1347
  • Status: closed  
  • Source: Anonymous
  • 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!

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Uses and extends not types of generalization

  • Key: UML14-827
  • Legacy Issue Number: 1346
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 93: use case

  • Key: UML14-826
  • Legacy Issue Number: 1345
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 93 Is Use Case really a composite aggregation of attributes and
    operations – surely not?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 93: Is Namespace really aggregeation of use cases?

  • Key: UML14-825
  • Legacy Issue Number: 1344
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Discussion on Collaborations and Interactions is confusing

  • Key: UML14-824
  • Legacy Issue Number: 1343
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on pages 55 and 62

  • Key: UML14-823
  • Legacy Issue Number: 1342
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 55 Typo line -4 base Class Specifies (not Species)

    Page 62 Typo line -3 String not Sting

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50 Table 3 "refinement"

  • Key: UML14-822
  • Legacy Issue Number: 1341
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Table 3 <<refinement>> should be added as a stereotype of Dependency.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: table 3 component

  • Key: UML14-821
  • Legacy Issue Number: 1340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Table 3 Component. Stereotype <<friend>>. Elsewhere the document says
    this is a stereotype of <<using>>

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: should stereotypes be defined at the subclass level?

  • Key: UML14-820
  • Legacy Issue Number: 1339
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #1227

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: "instance" should be changed to "instatiate"

  • Key: UML14-819
  • Legacy Issue Number: 1338
  • Status: closed  
  • Source: Anonymous
  • 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]

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 47: Dependency is a unidirectional, client-server

  • Key: UML14-818
  • Legacy Issue Number: 1337
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1227.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 45 dependency lines 2/3 between model elements not instances?

  • Key: UML14-817
  • Legacy Issue Number: 1336
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Aggregation of class?

  • Key: UML14-816
  • Legacy Issue Number: 1335
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 45 Component. Is it really a class – or perhaps an aggregation of classes?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 40 table 2 Model Element class

  • Key: UML14-815
  • Legacy Issue Number: 1334
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed is UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 38 para 2 line 3, one of its containers is deleted

  • Key: UML14-814
  • Legacy Issue Number: 1333
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35 Diagram (02)

  • Key: UML14-813
  • Legacy Issue Number: 1332
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35 -Diagram

  • Key: UML14-812
  • Legacy Issue Number: 1331
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class to be defined as an intension

  • Key: UML14-811
  • Legacy Issue Number: 1330
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

How to stop an interface realizing a Data Type ?

  • Key: UML14-810
  • Legacy Issue Number: 1329
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Why does GeneralizableElement inherit from Namespace?

  • Key: UML14-809
  • Legacy Issue Number: 1328
  • Status: closed  
  • Source: Anonymous
  • 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 ...

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 16 ---editorial (Element Ownership)

  • Key: UML14-808
  • Legacy Issue Number: 1327
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Isn"t Element Ownership an Association Class - in which case the
    joining line should be dotted.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Is name space really a *composite aggregation* of model elements?

  • Key: UML14-807
  • Legacy Issue Number: 1326
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Is a namespace really a composite aggregation of model elements?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 16 lost fact that Class realizes an interface

  • Key: UML14-806
  • Legacy Issue Number: 1325
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Interface must also have features

  • Key: UML14-805
  • Legacy Issue Number: 1324
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Why is Classifier an Aggregate of Features?

  • Key: UML14-804
  • Legacy Issue Number: 1323
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration as a Classifier

  • Key: UML14-803
  • Legacy Issue Number: 1309
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 5 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Interfaces and support classes

  • Key: UML14-802
  • Legacy Issue Number: 1290
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Wed, 29 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML Semantics, p 81, 145

  • Key: UML14-801
  • Legacy Issue Number: 1248
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1019.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Extension/recommendation needed for inner/outer transitions

  • Key: UML14-800
  • Legacy Issue Number: 1237
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Notation for state machine inheritance

  • Key: UML14-799
  • Legacy Issue Number: 1236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation for state machine inheritance is defined in Semantics (pg.
    116)
    instead of Notation.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Clarified that notational example in Semantics is non-normative.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UseCaseInstance badly defined

  • Key: UML14-798
  • Legacy Issue Number: 1235
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Semantics of terminate transitions

  • Key: UML14-797
  • Legacy Issue Number: 1234
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Multiple transitions from initial states should be allowed

  • Key: UML14-796
  • Legacy Issue Number: 1233
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Modeling of guards

  • Key: UML14-795
  • Legacy Issue Number: 1232
  • Status: closed  
  • Source: Anonymous
  • 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) ).

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration::constrainingElement semantics

  • Key: UML14-794
  • Legacy Issue Number: 1231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Collaboration::constrainingElement doesn"t have a clear semantics.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration showing instances

  • Key: UML14-793
  • Legacy Issue Number: 1230
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistency between stereotype tables

  • Key: UML14-792
  • Legacy Issue Number: 1229
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Stereotype modeled in two ways

  • Key: UML14-791
  • Legacy Issue Number: 1228
  • Status: closed  
  • Source: Anonymous
  • 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>>.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Stereotypes for superclasses do not apply to superclasses

  • Key: UML14-790
  • Legacy Issue Number: 1227
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent use of stereotypes, tagged values, and metamodel

  • Key: UML14-789
  • Legacy Issue Number: 1226
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class WFR (01)

  • Key: UML14-788
  • Legacy Issue Number: 1224
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Correct WFR Class [1] pg. 29: m.specification ham multiplicity 1 so no
    "includes" is needed.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 864.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Modeling of realization/specification

  • Key: UML14-787
  • Legacy Issue Number: 1223
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

GeneralizableElement should not inherit from Namespace

  • Key: UML14-786
  • Legacy Issue Number: 1222
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Syntax for Sequence Expressions inconsistently used

  • Key: UML14-785
  • Legacy Issue Number: 1221
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Threads of control in Collaboration Diagrams

  • Key: UML14-784
  • Legacy Issue Number: 1220
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Control Flow types not modeled

  • Key: UML14-783
  • Legacy Issue Number: 1219
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

RaiseAction and TimingMark are not defined

  • Key: UML14-782
  • Legacy Issue Number: 1218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.5.4 pg. 112. RaiseAction and TimingMark do not exist in UML.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Mapping of concurrent subregions

  • Key: UML14-781
  • Legacy Issue Number: 1217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.3.4 pg. 108. Each concurrent subregion map into a
    CompositeState?

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"do" action not supported

  • Key: UML14-780
  • Legacy Issue Number: 1216
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Notation for iteration in sequence diagram

  • Key: UML14-779
  • Legacy Issue Number: 1215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 7.5.3 pg. 86. The notation for iteration is not clearly
    defined.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"derived" not defined

  • Key: UML14-778
  • Legacy Issue Number: 1214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.30.5 pg. 74. Where is "derived" defined?

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

<>, <>, <>, <>, not well supported

  • Key: UML14-777
  • Legacy Issue Number: 1213
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Namespace in case of containment

  • Key: UML14-776
  • Legacy Issue Number: 1212
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

WFR for bound elements missing

  • Key: UML14-775
  • Legacy Issue Number: 1211
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #1016.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

The meta-type of template parameters

  • Key: UML14-774
  • Legacy Issue Number: 1210
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1016.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Dependency wrongly mapped

  • Key: UML14-773
  • Legacy Issue Number: 1208
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Package importing transitive

  • Key: UML14-772
  • Legacy Issue Number: 1207
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"invoked" not defined

  • Key: UML14-771
  • Legacy Issue Number: 1206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics/ObjectFlowState[1,2] pg. 124 uses "invoked" which is not
    defined.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Bad example for LCA, main source, main target

  • Key: UML14-770
  • Legacy Issue Number: 1205
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Transition WFR badly written