Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

  • Acronym: UML
  • Issues Count: 355
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UML14-1046 Type vs. Implementastion class UML 1.1 UML 1.2 Resolved closed
UML14-1044 Wording od OCL definition 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-930 Generalized change events 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-928 Definition of OclAny leads to problems when formalizing OCL UML 1.1 UML 1.2 Resolved closed
UML14-925 Add "Let"-like construct to OCL UML 1.1 UML 1.2 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-920 ModelElement to Partition multiplicity should be many UML 1.1 UML 1.2 Resolved closed
UML14-921 Notation says swimlanes are packages UML 1.1 UML 1.2 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-913 issue: Missing association names 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-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-908 Issue: abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-909 Issue: Name attribute inheritance 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-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-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-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-883 It"s mistake to automatically flatten collections of collections UML 1.1 UML 1.2 Resolved closed
UML14-884 pre value of object 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-878 Protocol state diagrams issue UML 1.1 UML 1.2 Resolved closed
UML14-879 Implicit transitive import between packages 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-874 Operation asSequence Issue 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-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-867 Merge "Class" and "Interface" into one class 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-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-863 State diagrams: action expressions 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-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-858 Aggregation is poorly defined 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-857 Page 98: arrowhead issue UML 1.1 UML 1.2 Resolved closed
UML14-855 Page 82: Add explanation UML 1.1 UML 1.2 Resolved closed
UML14-856 Page 94 --editorial 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-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-852 Page 72: Example needs rejigging UML 1.1 UML 1.2 Resolved closed
UML14-848 Page 58: Add index entry UML 1.1 UML 1.2 Resolved closed
UML14-846 Page 52 figure 20 UML 1.1 UML 1.2 Resolved closed
UML14-847 Page 57: mathematical issue 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-839 Page 26: rename reponsibilities, rules, modification histories etc. UML 1.1 UML 1.2 Resolved closed
UML14-840 Page 29: Protected member 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-836 Page 20: Section 4.3.1 could be misleading 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-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-829 Page 136: Model package relationship 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-832 Typos on page 90, 151 plus errors in page numbering 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-819 Page 50: "instance" should be changed to "instatiate" UML 1.1 UML 1.2 Resolved closed
UML14-821 Page 50: table 3 component 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-818 Page 47: Dependency is a unidirectional, client-server 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-816 Aggregation of 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-815 Page 40 table 2 Model Element class UML 1.1 UML 1.2 Resolved closed
UML14-813 Page 35 Diagram (02) 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-812 Page 35 -Diagram 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-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-808 Page 16 ---editorial (Element Ownership) 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-804 Why is Classifier an Aggregate of Features? UML 1.1 UML 1.2 Resolved closed
UML14-805 Interface must also have features UML 1.1 UML 1.2 Resolved closed
UML14-803 Collaboration as a Classifier UML 1.1 UML 1.2 Resolved closed
UML14-801 UML Semantics, p 81, 145 UML 1.1 UML 1.2 Resolved closed
UML14-802 Interfaces and support classes 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-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-796 Multiple transitions from initial states should be allowed 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-787 Modeling of realization/specification UML 1.1 UML 1.2 Resolved closed
UML14-788 Class WFR (01) 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-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-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-779 Notation for iteration in sequence diagram UML 1.1 UML 1.2 Resolved closed
UML14-780 "do" action not supported 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-774 The meta-type of template parameters UML 1.1 UML 1.2 Resolved closed
UML14-775 WFR for bound elements missing 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-768 Entry/Exit actions execution order 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-767 CompositeStates with non-composite subregions allowed 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-762 WFR for instance links UML 1.1 UML 1.2 Resolved closed
UML14-763 MessageInstance not used 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-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-755 "implementation" association not defined UML 1.1 UML 1.2 Resolved closed
UML14-751 Exotic uses of generalization 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-748 Correspondence between operation and method UML 1.1 UML 1.2 Resolved closed
UML14-746 Return types for BehavioralFeatures 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-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-739 UML Semantics 1.1, p26, Operation::isPolymorphic UML 1.1 UML 1.2 Resolved closed
UML14-740 Signature conflicts not well defined 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-736 OCL specification 1.1, p. 15, 5.14, second last paragraph 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-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-731 OCL specification 1.1, section 7.2.2 UML 1.1 UML 1.2 Resolved closed
UML14-732 OCL specification 1.1, p. 10, 5.4.3, example 3 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-728 Editorial issue: OCL spec 1.1, section 6.3, example 2, last row 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-726 Contents of section "Control Icons" is vague UML 1.1 UML 1.2 Resolved closed
UML14-724 Procedure undefined UML 1.1 UML 1.2 Resolved closed
UML14-725 Missing word - editorial 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-719 deferredEvent mentioned twice in Abstract Syntax 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-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-714 No mapping for "transition string" 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-713 No mapping for send/receive time in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-716 No notation for ActivityState UML 1.1 UML 1.2 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-703 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-704 Well-formedness rules missing UML 1.1 UML 1.2 Resolved closed
UML14-697 Enumeration OperationDirectionKind obsolete UML 1.1 UML 1.2 Resolved closed
UML14-698 Misleading name Link.linkRole UML 1.1 UML 1.2 Resolved closed
UML14-702 Inconsistent definition of stereotype " process" 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-701 Inconsistent definition of enumeration 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-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-696 ordered missing for Constraint.constrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-689 Inconsistent attachment of Activity Diagram 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-692 Method visibility 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-684 Attachment of message in Sequence Diagram 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-682 UML 1.0: "role" should be "end" UML 1.1 UML 1.2 Resolved closed
UML14-680 UML 1.0: Inconsistent name of stereotype "import" 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-679 UML 1.0: multiplicity "unspecified" not possible 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-678 UML 1.0: Stereotype "uses" applied to more than one class UML 1.1 UML 1.2 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-666 UML 1.o: Qualified things in Collaborations 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-665 UML 1.0: Collaborations not well defined 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-663 Signal label in figure 18 is not present 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-662 Figure 15, AssociationRole class issue 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-657 Reception class has wrong attribute 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-658 ActionSequence class issue 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-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-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-647 Inconsistency of UML metamodel 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-646 Association between Method and Operation UML 1.1 UML 1.2 Resolved closed
UML14-644 UML Notation Guide, association ends UML 1.1 UML 1.2 Resolved closed
UML14-645 UML Notation Guide, boolean properties 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-636 diagram fragment at start of Model section on page 136 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-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-631 Well-formedness rule [4] for Association 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-630 Figure 5 Semantics document (p. 16) 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-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-623 ModelElement Associations (02) UML 1.1 UML 1.2 Resolved closed
UML14-624 Missing role descriptions 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-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-619 Package dependencies (08) UML 1.1 UML 1.2 Resolved closed
UML14-620 Package dependencies (09) 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-618 Package dependencies (07) 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-608 Page 98 of UML 1.1 Semantics, figure 18 (02) 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-606 Page 98 of UML 1.1 Semantics, figure 17 (04) 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-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-601 Page 47 of UML 1.1 Semantics, description of Refinement 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-599 Page 44 UML 1.1 Semantics, figure 8 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-600 Page 46 of UML 1.1 Semantics, description of associations for ModelElement 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-596 Page 16 of UML Semantics, figure 5 UML 1.1 UML 1.2 Resolved closed
UML14-594 Page 62 "PseudostateKind"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-595 Page 62---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-593 Page 61 "EnumerationLiteral"--editorial 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-581 Page 40, table 2: Core - Standard Elements 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-583 page 40 table2: Classifier model element UML 1.1 UML 1.2 Resolved closed
UML14-579 Page 39 - ModelElement/Dependency associations UML 1.1 UML 1.2 Resolved closed
UML14-580 Page 54 - ConstrainedStereotype 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-578 Page 16- The association from parameter to classifier has a 1-1 cardinalit 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-574 Page 35/37 - AssociationRole UML 1.1 UML 1.2 Resolved closed
UML14-572 Page 60 - GraphicMarker UML 1.1 UML 1.2 Resolved closed
UML14-573 Page 60 - MultiplicityRange 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-570 Page 60 - PseudostateKind UML 1.1 UML 1.2 Resolved closed
UML14-568 page 60 - CallConcurrencyKind UML 1.1 UML 1.2 Resolved closed
UML14-571 Page 60 - visibilityKind UML 1.1 UML 1.2 Resolved closed
UML14-569 page 60 - EventOriginKind UML 1.1 UML 1.2 Resolved closed
UML14-567 Error on association owners UML 1.1 UML 1.2 Resolved closed
UML14-565 UML Documentation--Typos (06) UML 1.1 UML 1.2 Resolved closed
UML14-566 UML Documentation--Typos (07) UML 1.1 UML 1.2 Resolved closed
UML14-564 UML Documentation--Typos (05) UML 1.1 UML 1.2 Resolved closed
UML14-561 UML Documentation--Typos (02) UML 1.1 UML 1.2 Resolved closed
UML14-562 UML Documentation--Typos (03) UML 1.1 UML 1.2 Resolved closed
UML14-563 UML Documentation--Typos (04) 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

"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

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

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

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

Entry/Exit actions execution order

  • Key: UML14-768
  • Legacy Issue Number: 1203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The order in which the entry/exit actions are executed when entering /
    exiting a substate of a composite state is not given. The semantics is
    probably that the entry actions are executed sequentially from outer to
    inner states, and the exit actions are executed viceversa, but it should
    be
    stated explicitly.

  • 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

Message::base undefined

  • Key: UML14-766
  • Legacy Issue Number: 1201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is "base" used in Semantics/Message pg. 83.

  • 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

AssociationEnd-AssociationEndRole inconsistencies

  • Key: UML14-765
  • Legacy Issue Number: 1200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can there be inconsistencies between an AssociationEndRole and its base
    AssociationEnd, such as: an AssociationEndRole having a different name,
    multiplicity, changeability status or ordering status compared to its
    base?
    If not, this should be a Well-Formedness Rule (even if an informal
    one).

  • 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

Argument::type not defined

  • Key: UML14-764
  • Legacy Issue Number: 1199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Argument::type used in Semantics/CallAction [1] pg. 74 is not defined.

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

    Defined in UML 1.3.

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

CompositeStates with non-composite subregions allowed

  • Key: UML14-767
  • Legacy Issue Number: 1202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A CompositeState with isConcurent=TRUE should have only CompositeStates
    as
    substates (at least this is the only example explained in the
    documents).
    This is a Well-Formedness Rule missing from Semantics.
    If this is not the case, then a semantics for the other cases (cases of
    CompositeStates with substates that are not sub-regions) should be
    explained.

  • 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

Well-formedness Rules for Action::actualArguments

  • Key: UML14-761
  • Legacy Issue Number: 1196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since request and actualArguments are defined in Action, why the
    Well-Formedness Rules concerning these associations are defined only for
    CallAction and SendAction. At least LocalInvocation should have the same
    WFR.

  • 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 instance links

  • Key: UML14-762
  • Legacy Issue Number: 1197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rule Instance[2] pg. 74 does not take into account the direction of
    association, and therefore is incorrect. The rule should have referred
    to
    LinkEnds and AssociationEnds, and not to Links and Associations.

  • 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

MessageInstance not used

  • Key: UML14-763
  • Legacy Issue Number: 1198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: MessageInstance is an Instance of a Message? In which notation is it
    used?

  • 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

CallAction::request

  • Key: UML14-760
  • Legacy Issue Number: 1195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics/CallAction [1] pg. 74 should read "request" instead of
    "message"
    in the OCL rule.

  • 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

CallAction::isAsynchronous and CallAction::mode

  • Key: UML14-759
  • Legacy Issue Number: 1194
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CallAction has both "isAsynchronous" and "mode:

    {sync, async}

    ".
    Redundancy.

  • 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

Action::isAsynchronous and Action::script not defined

  • Key: UML14-758
  • Legacy Issue Number: 1193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics Fig. 13 pg. 67 shows the attributes Action::isAsynchronous
    and
    Action::script, that are not defined(explained) in the text.

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

    Defined in UML 1.3.

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

Signal::isAsynchronous and Signal::direction not defined

  • Key: UML14-757
  • Legacy Issue Number: 1192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Well-Formedness Rule Signal [1] pg. 76 refers to "isAsynchronous" and
    "direction" that are not defined anywhere.

  • 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

Request"s parents

  • Key: UML14-756
  • Legacy Issue Number: 1191
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Request is a subclass of BehavioralFeature or ModelElement?
    Inconsistency
    between the diagram and the text: Semantics pg. 66/72. Also, it should
    be
    abstract (shown in italics).

  • 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

Node and Component parent

  • Key: UML14-754
  • Legacy Issue Number: 1188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Node and Component are subclasses of Class or Classifier? Inconsistency
    between the diagram and the text: Semantics pg. 44 - 46.

  • 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

Qualifier badly modeled

  • Key: UML14-753
  • Legacy Issue Number: 1187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A qualifier should be modeled as a (in) Parameter and not as an
    Attribute
    (see fig. 6 pg 17). An Attribute has an ownerScope, a visibility, a
    changeability and a targetScope that are not characteristics for a
    qualifier. A Parameter instead has exactly what is needed for modeling a
    qualifier.

  • 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

"implementation" association not defined

  • Key: UML14-755
  • Legacy Issue Number: 1190
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "implementation" association between Component and ModelElement
    (Semantics, pg. 44) is not explained.

  • 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

Exotic uses of generalization

  • Key: UML14-751
  • Legacy Issue Number: 1185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics allows exotic usages of generalization, such as between two
    Associations, without saying what it means, and without giving a
    notation
    for it.

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

    Redundant with issue 1184.

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

Signature conflicts across an inheritance hierarchy

  • Key: UML14-752
  • Legacy Issue Number: 1186
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If in a multiple inheritance graph we have an operation defined in two
    different ancestors of a class, the model is ill formed, although such a
    situation is very likely to happen in real life.
    Proposal: adopt a more relaxed semantics such as that of C++ or Eiffel
    for
    such a situation.

  • 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

Correspondence between operation and method

  • Key: UML14-748
  • Legacy Issue Number: 1182
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Return types for BehavioralFeatures

  • Key: UML14-746
  • Legacy Issue Number: 1180
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Use of language-dependant type expressions

  • Key: UML14-747
  • Legacy Issue Number: 1181
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    resolved in UML 1.3

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

Package importing not well supported

  • Key: UML14-745
  • Legacy Issue Number: 1178
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Signature conflicts not well defined (02)

  • Key: UML14-744
  • Legacy Issue Number: 1177
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Features and ownedElements (2)

  • Key: UML14-743
  • Legacy Issue Number: 1176
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

"feature" defined twice

  • Key: UML14-742
  • Legacy Issue Number: 1174
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Redundant with issue 847

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

Features and ownedElements (1)

  • Key: UML14-741
  • Legacy Issue Number: 1172
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

UML Semantics 1.1, p26, Operation::isPolymorphic

  • Key: UML14-739
  • Legacy Issue Number: 1165
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Semantics 1.1, p26, Operation::isPolymorphic
    Nothing says that isPolymorphic=TRUE is the default. In the NG, p19, ยง4.2.2 says "to specify a value of false you omit the name completely".

    This implies that all operations are not polymorphic by default, and that you must write

    {polymorphic}

    explicitly on all polymorphic operations.

  • Reported: UML 1.1 — Wed, 22 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

Signature conflicts not well defined

  • Key: UML14-740
  • Legacy Issue Number: 1171
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

OCL Specification 1.1, section 8

  • Key: UML14-738
  • Legacy Issue Number: 1110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax specification does not include the
    extended syntax for the Iterate operation.

    xxx->iterate(x;acc=0|acc=acc+x.assets)
    ^^^^^^

    Proposed Resolution : include this in the grammar for the syntax
    Revised Text :

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

OCL specification 1.1, p. 15, 5.14, second last paragraph

  • Key: UML14-736
  • Legacy Issue Number: 1108
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

OCL specification 1.1, p. 14, 5.13, example

  • Key: UML14-737
  • Legacy Issue Number: 1109
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why mention "Car" as a subtype of Transport when it is not used
    in the example?

    Proposed Resolution : remove the reference to Car in the sentence.
    Revised Text : change text as suggested above
    Actions taken:

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

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

OCL specification 1.1, p. 24, 7.1.7

  • Key: UML14-735
  • Legacy Issue Number: 1107
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

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

OCL specification 1.1, p. 30, 7.2.4

  • Key: UML14-734
  • Legacy Issue Number: 1105
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

OCL specification 1.1, section 7.2.2

  • Key: UML14-731
  • Legacy Issue Number: 1102
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1102.

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

OCL specification 1.1, p. 10, 5.4.3, example 3

  • Key: UML14-732
  • Legacy Issue Number: 1103
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since both expressions start in the same object and one
    person can"t have both a wife and a husband, the expression will
    never give the result true, only false or undefined

    Here one could instead use the syntax of example 1:
    self.wife->nonempty implies self.wife.sex = #female and
    self.husband->nonempty implies self.husband.sex = #male

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

UML 1.1 Semantics, section 8.2, page 66

  • Key: UML14-727
  • Legacy Issue Number: 1098
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Semantics (ch. 8.2, p66, Figure 12) says that Signal is a GeneralizableElement and has Parameter(s). Multiple inheritance or repeated inheritance are not forbidden.

    2/ The Notation Guide (ch. 9.5.2, p111) says that an event has the following form: event-name "(" parameter "," ... ")" This means that the order of parameters is meaningful and implies that parameters must match the formal parameters declared in signals.

  • Reported: UML 1.1 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

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

Editorial issue: OCL spec 1.1, section 6.3, example 2, last row

  • Key: UML14-728
  • Legacy Issue Number: 1099
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL Specification 1.1, section 6.3, example 2, last row:

    reads:
    self.employee->forAll(Person p|p.forename = "Jack")

    should read:
    self.employee->forAll(p : Person|p.forename = "Jack")

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

Definition of select and reject operations for Set"s is erranious

  • Key: UML14-730
  • Legacy Issue Number: 1101
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It reads:

    set->select(expr : OclExpression ) : Set( expr.type )
    set->reject(expr : OclExpression ) : Set( expr.type )

    It should read:

    set->select(expr : OclExpression ) : Set( T )
    set->reject(expr : OclExpression ) : Set( T )

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

Difference between methods, attributes and operations not clear

  • Key: UML14-729
  • Legacy Issue Number: 1100
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Normally methods, attributes and operations can be easily told from each
    other:

    Person.attribute
    Person.method(arg1..argn) alt Person.method()
    Person->Operation(arg1..argn) alt Person->Operation

    There is however a situation where it is not possible to tell the
    difference:

    Imagine a shoe-shop with a class Shoe, and the attribute size.

    you would imagine that the following

    Shoe.allInstances->select(size > 10)

    would give you a set of all the shoes with size bigger than 10, but it
    could just as well be interpreted as the set of all shoes since an object is a set of size 1.

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

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

Contents of section "Control Icons" is vague

  • Key: UML14-726
  • Legacy Issue Number: 1097
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with activity diagram rework.

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

Procedure undefined

  • Key: UML14-724
  • Legacy Issue Number: 1062
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

Missing word - editorial

  • Key: UML14-725
  • Legacy Issue Number: 1063
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

Missing sentence

  • Key: UML14-723
  • Legacy Issue Number: 1061
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

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

Editorial error in Semantics

  • Key: UML14-722
  • Legacy Issue Number: 1060
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

deferredEvent mentioned twice in Abstract Syntax

  • Key: UML14-719
  • Legacy Issue Number: 1057
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 860).

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

ActionState implicit deferring of events

  • Key: UML14-721
  • Legacy Issue Number: 1059
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: y interpretation of ActionState is that no events received
    during its execution are deferred, hence they will be lost unless they
    are explicitly deferred.

    This means that if I want to defer all signals (which IMHO is the
    default behavior for ActionState) I have to explicitly use the /defer
    notation, which may result in enormous overhead and large symbols!

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

internalTransition

  • Key: UML14-720
  • Legacy Issue Number: 1058
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

Deep History Vertex

  • Key: UML14-718
  • Legacy Issue Number: 1053
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    This should be "A composite state can have at most one DEEP history vertex."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

Inconsistent definition of extends relationship

  • Key: UML14-717
  • Legacy Issue Number: 1052
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    This is not defined in the model.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Extend relationship updated.

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

No mapping for "transition string"

  • Key: UML14-714
  • Legacy Issue Number: 1049
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 113 NG (Complex Transitions)

    The "transition string" is not mapped.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

No mapping for TimingMark in Sequence Diagram

  • Key: UML14-715
  • Legacy Issue Number: 1050
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    TimingMark is not defined in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

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

No mapping for send/receive time in Sequence Diagram

  • Key: UML14-713
  • Legacy Issue Number: 1048
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 87 NG "A message may have a sending time and a receiving time."

    This is not specified in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

No notation for ActivityState

  • Key: UML14-716
  • Legacy Issue Number: 1051
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 121 NG (Notation Activity Diagrams)

    There is no notation for the model element "ActivityState".

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant: already fixed in UML 1.3.

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

Property "derived" not defined

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

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

    The "derived" property is not defined in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

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

Interface specifier not mapped

  • Key: UML14-710
  • Legacy Issue Number: 1045
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

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

Inconsistent constraint for discriminator

  • Key: UML14-709
  • Legacy Issue Number: 1044
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 68 NG "The discriminator must be unique among the attributes and
    association roles of the given super-class."

    This is not specified in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

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

Missing notation for templates

  • Key: UML14-708
  • Legacy Issue Number: 1043
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 39 NG (notation for template) "A small dashed rectangle is superimposed
    on the upper right-hand corner of the rectangle for the class (or to the
    symbol for another modeling element)."

    What about templates that have no symbol of their own, such as operations?

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

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

Confusing text

  • Key: UML14-707
  • Legacy Issue Number: 1042
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 NG "A class symbol (...) maps into a Class with no stereotype. This
    symbol is normally used between a class and an interface (...)"

    There seems to be something missing, because the sentence starting with
    "this symbol" doesn"t make any sense in this context.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

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

Missing mapping for directed constraint

  • Key: UML14-706
  • Legacy Issue Number: 1041
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 17 NG "For two graphical symbols (such as two classes or two associations):
    The constraint is shown as a dashed arrow from one element to the other
    element labeled by the constraint string (in braces). The direction of the
    arrow is relevant information within the constraint."

    and on p. 18:

    "A constraint string attached to a dashed arrow maps into a constraint
    attached to the two elements corresponding to the symbols connected by the
    arrow."

    Since the direction of the arrow is relevant: how is this direction mapped?

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

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

Inconsistent definition of stereotype "thread"

  • Key: UML14-703
  • Legacy Issue Number: 1038
  • Status: closed  
  • Source: Anonymous
  • Summary:

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