${taskforce.name} Avatar
  1. OMG Task Force

UML 1.4 RTF — Closed Issues

  • Key: UML14
  • Issues Count: 1,046
Open 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-1045 Compliance ambiguity UML 1.3 UML 1.4 Duplicate or Merged closed
UML14-1044 Wording od OCL definition UML 1.1 UML 1.2 Resolved closed
UML14-1043 Change syntax of certain pre-defined operations UML 1.2 UML 1.3 Resolved closed
UML14-1042 Package symbol as a polygon UML 1.1 UML 1.3 Resolved closed
UML14-1041 There is a bug in additional operation 1 of the Namespace element UML 1.4 UML 1.4.2 Resolved closed
UML14-1040 How to properly designate exception returned from message sent to Java obje UML 1.4 UML 1.4.2 Resolved closed
UML14-1039 In 3.23.1 "Notation" (Internationalization issues) UML 1.3 UML 1.4 Resolved closed
UML14-1038 No servant with object . minorcode=0 completed=NO UML 1.3 UML 1.4 Closed; No Change closed
UML14-1037 The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4 UML 1.3 UML 1.4 Resolved closed
UML14-1036 Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics UML 1.3 UML 1.4 Resolved closed
UML14-1035 Who owns an Event? UML 1.3 UML 1.4 Resolved closed
UML14-1033 UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1034 UML 1.4 RTF Issue: Namespace notation too specific UML 1.3 UML 1.4 Resolved closed
UML14-1032 UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1031 UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1030 UML RTF 1.4 editorial comments (Part 2 Diagram Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1029 UML 1.4 RTF Issue: Association generalization has notation but no semantics UML 1.2 UML 1.3 Resolved closed
UML14-1028 UML 1.4 RTF Issue: Ordering of attribute values UML 1.2 UML 1.3 Resolved closed
UML14-1023 UML 1.4 RTF issue: OCL: Unary operator "-" missing UML 1.2 UML 1.3 Resolved closed
UML14-1027 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings UML 1.2 UML 1.3 Resolved closed
UML14-1026 UML 1.4 RTF Issue: changeability in associations UML 1.2 UML 1.3 Resolved closed
UML14-1025 UML 1.4 RTF issue: OCL: grammar is ambigous UML 1.2 UML 1.3 Resolved closed
UML14-1024 UML 1.4 RTF issue: OCL: navigation context in iterate UML 1.2 UML 1.3 Resolved closed
UML14-1021 UML 1.4 RTF issue: OCL: Iterator declarators UML 1.2 UML 1.3 Resolved closed
UML14-1020 OCL: Declarators for iterate UML 1.2 UML 1.3 Resolved closed
UML14-1022 UML 1.4 RTF issue: OCL: Precedence of relational operators UML 1.2 UML 1.3 Resolved closed
UML14-1019 In 2.10.4, semantics of Collaboration, the 1st sentence is confusing UML 1.2 UML 1.3 Resolved closed
UML14-1016 Page 2-114, 2nd paragraph. It should be collaboration template UML 1.2 UML 1.3 Resolved closed
UML14-1015 Confusing wording UML 1.2 UML 1.3 Resolved closed
UML14-1017 In 2.10.5, you give pattern a non-standard definition UML 1.2 UML 1.3 Resolved closed
UML14-1018 Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Cla UML 1.2 UML 1.3 Resolved closed
UML14-1010 Terminology: Collaboration and Collaboration Template UML 1.2 UML 1.3 Resolved closed
UML14-1014 use of the phrase "In the metamodel..." is unclear UML 1.2 UML 1.3 Resolved closed
UML14-1013 why is AssociationRole is a subtype of Association? UML 1.2 UML 1.3 Resolved closed
UML14-1012 2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam". UML 1.2 UML 1.3 Resolved closed
UML14-1011 Focus is on 2.10 Collaborations UML 1.2 UML 1.3 Resolved closed
UML14-1009 Design patterns and collaboration templates. UML 1.2 UML 1.3 Resolved closed
UML14-1008 "Unused" data types UML 1.2 UML 1.3 Resolved closed
UML14-1007 Notation for Namespace ownership UML 1.2 UML 1.3 Resolved closed
UML14-1006 UML RTF 1.4 Issue: Typo in state exit UML 1.2 UML 1.3 Resolved closed
UML14-1005 Misleading description of feature inheritance on roles. UML 1.2 UML 1.3 Resolved closed
UML14-1001 Incorrect example of constraining elements in collaborations. UML 1.2 UML 1.3 Resolved closed
UML14-1004 UML RTF 1.4 Issue: Messages do not have signatures UML 1.2 UML 1.3 Resolved closed
UML14-1003 UML RTF 1.4 Issue: Guard condition in collaborations poorly named. UML 1.2 UML 1.3 Resolved closed
UML14-1002 UML RTF 1.4 Issue: Multi-objects in collaborations UML 1.2 UML 1.3 Resolved closed
UML14-1000 UML RTF 1.4 Issue: Duplicate association end names from Constraint. UML 1.2 UML 1.3 Resolved closed
UML14-999 UML RTF 1.4 Issue: Create action in collaborations UML 1.2 UML 1.3 Resolved closed
UML14-998 UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous? UML 1.2 UML 1.3 Resolved closed
UML14-997 UML RTF 1.4 Issue: Action composition meta-modelled improperly: UML 1.2 UML 1.3 Resolved closed
UML14-994 UML RTF 1.4 Issue: Confusing example of sequence diagram UML 1.2 UML 1.3 Resolved closed
UML14-993 UML RTF 1.4 Issue: Arrowhead semantics in collaboration unclear UML 1.2 UML 1.3 Resolved closed
UML14-992 UML RTF 1.4: Description of context role, between state machine and model UML 1.2 UML 1.3 Resolved closed
UML14-996 UML RTF 1.4 Issue: Flow relationship has the incorrect semantics UML 1.2 UML 1.3 Resolved closed
UML14-995 UML RTF 1.4 Issue: <> keyword/stereotype UML 1.2 UML 1.3 Resolved closed
UML14-989 UML RTF 1.4 Issue: Deferred event ambiguity UML 1.2 UML 1.3 Resolved closed
UML14-988 UML RTF 1.4 Issue: Join in collaboration UML 1.2 UML 1.4 Resolved closed
UML14-987 UML RTF 1.4 Issue: State constraint on host object UML 1.2 UML 1.3 Resolved closed
UML14-991 UML RTF 1.4 Issue: ownerScope and targetScope UML 1.2 UML 1.3 Resolved closed
UML14-990 UML RTF 1.4 Issue: Guard evaluation for choice points. UML 1.2 UML 1.4 Resolved closed
UML14-986 UML RTF 1.4 Issue: Notation for call state UML 1.2 UML 1.3 Resolved closed
UML14-985 State machine name space UML 1.2 UML 1.3 Resolved closed
UML14-984 Issue Activity Package UML 1.2 UML 1.3 Resolved closed
UML14-983 ISSUE FOR UML, SECTION ActivityGraphs UML 1.2 UML 1.3 Resolved closed
UML14-982 Shouldn't the UML Package be allowed to own/reference UML 'Instances'? UML 1.2 UML 1.3 Resolved closed
UML14-981 Inheritance of Stereotypes UML 1.2 UML 1.3 Resolved closed
UML14-980 Why is "FinalState" a separate metaclass ? UML 1.2 UML 1.3 Resolved closed
UML14-977 OCL: Let-expressions UML 1.2 UML 1.3 Resolved closed
UML14-979 Invalid OCL expression in initial transition UML 1.2 UML 1.3 Resolved closed
UML14-978 OCL: Samples of invalid typing UML 1.2 UML 1.3 Resolved closed
UML14-976 OCL: class operation has no 'self' UML 1.2 UML 1.3 Resolved closed
UML14-975 OCL: String literals UML 1.2 UML 1.3 Resolved closed
UML14-974 OCL: Numeric constants missing UML 1.2 UML 1.3 Resolved closed
UML14-973 OCL: Literal collections UML 1.2 UML 1.3 Resolved closed
UML14-972 OCL: Enumeration types inconsistent with UML metamodel UML 1.2 UML 1.3 Resolved closed
UML14-971 OCL: Enumeration types UML 1.2 UML 1.3 Resolved closed
UML14-970 OCL: Feature calls on default target UML 1.2 UML 1.3 Resolved closed
UML14-967 OCL: Are keywords reserved or not UML 1.2 UML 1.3 Resolved closed
UML14-966 OCL: Consistency in grammar description UML 1.2 UML 1.3 Resolved closed
UML14-965 "Physical" Metamodel References in Diagrams (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-969 textual syntax cannot deal with identical class names in different package UML 1.2 UML 1.3 Resolved closed
UML14-968 OCL: Class context specification grammar incomplete UML 1.2 UML 1.3 Resolved closed
UML14-964 "Physical" Metamodel References (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-963 Precise "Physical" Metamodels Missing from Specification (uml-rtf UML 1.2 UML 1.3 Resolved closed
UML14-962 Language Name (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-961 OCL Error UML 1.2 UML 1.3 Resolved closed
UML14-960 Use of interfaces in associations UML 1.2 UML 1.3 Resolved closed
UML14-959 Generalization should be meta-metamodel element UML 1.2 UML 1.3 Resolved closed
UML14-958 role concept in UML remains rather vague UML 1.2 UML 1.3 Resolved closed
UML14-957 OCL issue UML 1.1 UML 1.3 Resolved closed
UML14-956 Strange GENERAl USE RESTRICTION UML 1.1 UML 1.3 Resolved closed
UML14-955 Error in the third postcondition for String::concat on page 6-31 UML 1.1 UML 1.3 Resolved closed
UML14-954 The not-equals operator, "<>", UML 1.1 UML 1.3 Resolved closed
UML14-953 Divide operator is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-952 pages 6-28 to 6-29 of OCL documentation UML 1.1 UML 1.3 Resolved closed
UML14-951 page 6-10 of OCL documentation for 1.3alphaR5 UML 1.1 UML 1.3 Resolved closed
UML14-948 The second postcondition on Integer::div is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-950 The postcondition seems to be incorrect for sequence::subSequence UML 1.1 UML 1.3 Resolved closed
UML14-949 The postcondition on set::collect seems to be incorrect UML 1.1 UML 1.3 Resolved closed
UML14-947 (Minor) Activity diagram change recommendation UML 1.1 UML 1.3 Resolved closed
UML14-946 OCL Standard package UML 1.1 UML 1.3 Resolved closed
UML14-945 There is an association between between Constraint and ModelElement UML 1.1 UML 1.3 Resolved closed
UML14-944 OCL should allow one constraint to reference another UML 1.1 UML 1.3 Resolved closed
UML14-941 action state symbol/state symbol difficult to distinguish when drawn by ha UML 1.1 UML 1.3 Resolved closed
UML14-940 UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99 UML 1.1 UML 1.4 Resolved closed
UML14-943 UML has symbol for multiobject, not for multi-instances of other classifie UML 1.1 UML 1.3 Resolved closed
UML14-942 Dependencies (and other relationships) with role ends UML 1.1 UML 1.3 Resolved closed
UML14-939 Add Responsibilities as a new metatype UML 1.1 UML 1.3 Resolved closed
UML14-935 On aggregation. The white diamond name should be "shareable" UML 1.1 UML 1.3 Resolved closed
UML14-934 Metamodel and semantics for aggregations UML 1.1 UML 1.3 Resolved closed
UML14-938 Interface issue UML 1.1 UML 1.3 Resolved closed
UML14-937 Only single stereotyping is supported UML 1.1 UML 1.3 Resolved closed
UML14-936 Use of black diamond in the metamodel UML 1.1 UML 1.3 Resolved closed
UML14-933 Some attributes can be expressed in OCL UML 1.1 UML 1.4 Resolved closed
UML14-932 Widen the naming characteristics UML 1.1 UML 1.3 Resolved closed
UML14-931 BooleanExpression written in OCL or some other language? UML 1.1 UML 1.3 Resolved closed
UML14-927 Infix operator use should be clarified UML 1.1 UML 1.2 Resolved closed
UML14-930 Generalized change events UML 1.1 UML 1.2 Resolved closed
UML14-929 There are issues that make OCL hard to formalize--document ad/98-10-01 UML 1.1 UML 1.2 Resolved closed
UML14-928 Definition of OclAny leads to problems when formalizing OCL UML 1.1 UML 1.2 Resolved closed
UML14-924 Common operations should be added to collection types in OCL UML 1.1 UML 1.3 Resolved closed
UML14-923 Add OCL operation to refer to all new instances created during operation UML 1.1 UML 1.2 Resolved closed
UML14-922 Need well defined way to extend OCL UML 1.1 UML 1.2 Resolved closed
UML14-926 Set of allInstances should be referrable by the class name UML 1.1 UML 1.4 Resolved closed
UML14-925 Add "Let"-like construct to OCL UML 1.1 UML 1.2 Resolved closed
UML14-919 Synchronous request UML 1.1 UML 1.4 Resolved closed
UML14-921 Notation says swimlanes are packages UML 1.1 UML 1.2 Resolved closed
UML14-920 ModelElement to Partition multiplicity should be many UML 1.1 UML 1.2 Resolved closed
UML14-918 Asynchronous action UML 1.1 UML 1.4 Resolved closed
UML14-917 Not instantiable UML 1.1 UML 1.3 Resolved closed
UML14-916 UML RTF Issue: Normative MOF-Compatible version of UML UML 1.1 UML 1.2 Resolved closed
UML14-915 Core package-backbone diagram UML 1.1 UML 1.2 Resolved closed
UML14-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-914 MOF does not support association attributes in metamodels. UML 1.1 UML 1.2 Resolved closed
UML14-913 issue: Missing association names UML 1.1 UML 1.2 Resolved closed
UML14-910 Issue: Action does not define attributes UML 1.1 UML 1.2 Resolved closed
UML14-909 Issue: Name attribute inheritance UML 1.1 UML 1.2 Resolved closed
UML14-908 Issue: abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-907 Figure 2-18 : redundant attributes UML 1.1 UML 1.2 Resolved closed
UML14-906 UML Semantics (page 109) UML 1.1 UML 1.2 Resolved closed
UML14-905 Association attributes UML 1.1 UML 1.2 Resolved closed
UML14-904 missing association names UML 1.1 UML 1.2 Resolved closed
UML14-903 Issue: inheritance inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-902 Diagram missing attributes UML 1.1 UML 1.2 Resolved closed
UML14-900 Are subsystems instantiable? UML 1.1 UML 1.2 Resolved closed
UML14-901 Abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-899 Associations as parts of a composite. UML 1.1 UML 1.3 Resolved closed
UML14-898 Section 5.17 of Notation Guide: No mapping is given UML 1.1 UML 1.3 Resolved closed
UML14-896 Notation section describing activity states needed UML 1.1 UML 1.2 Resolved closed
UML14-897 Existance of classes in classes UML 1.1 UML 1.2 Resolved closed
UML14-895 States leading to joins in activity models UML 1.1 UML 1.2 Resolved closed
UML14-894 Activities operate by and on objects UML 1.1 UML 1.2 Resolved closed
UML14-893 ClassifierInState does not satisfy one of its stated usages UML 1.1 UML 1.2 Resolved closed
UML14-892 Rules 3 and 4 for Transitions in state machines should be limited UML 1.1 UML 1.3 Resolved closed
UML14-891 UML Semantics, section Common behavior UML 1.1 UML 1.2 Resolved closed
UML14-890 Notion of "conceptual" or "specification-only" not supported UML 1.1 UML 1.2 Resolved closed
UML14-889 OCL should allow the use of "let" expressions UML 1.1 UML 1.2 Resolved closed
UML14-888 Text on page 2-49 section 2.2 UML 1.1 UML 1.3 Resolved closed
UML14-887 Text in Figure 2.13.7.1 ActivityState seems to be incorrect UML 1.1 UML 1.2 Resolved closed
UML14-886 Need to have relative precedence and, or, xor UML 1.1 UML 1.2 Resolved closed
UML14-885 Need way to approximate comparisons UML 1.1 UML 1.2 Resolved closed
UML14-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-884 pre value of object UML 1.1 UML 1.2 Resolved closed
UML14-883 It"s mistake to automatically flatten collections of collections UML 1.1 UML 1.2 Resolved closed
UML14-880 States of an object not referenceable from OCL expression UML 1.1 UML 1.2 Resolved closed
UML14-879 Implicit transitive import between packages UML 1.1 UML 1.2 Resolved closed
UML14-878 Protocol state diagrams issue UML 1.1 UML 1.2 Resolved closed
UML14-877 Changes to figure 15 and description of ClassifierRole on page 82 UML 1.1 UML 1.2 Resolved closed
UML14-876 Semantics for dynamic invocation of concurrent activity models are missing UML 1.1 UML 1.2 Resolved closed
UML14-875 Collection type within OCL missing UML 1.1 UML 1.2 Resolved closed
UML14-874 Operation asSequence Issue UML 1.1 UML 1.2 Resolved closed
UML14-873 No discription of the association between Classifier and Parameter is give UML 1.1 UML 1.2 Resolved closed
UML14-872 Stereotypes on Dependency, page 43 of V 1.1 (figure 7) UML 1.1 UML 1.2 Resolved closed
UML14-871 Reflexive association in section 5.20.2 UML 1.1 UML 1.2 Resolved closed
UML14-870 The class "Subsystem" inherits from "GeneralizedElement" twice UML 1.1 UML 1.2 Resolved closed
UML14-869 Class "Model" is too prescriptive UML 1.1 UML 1.2 Resolved closed
UML14-868 Clarify how types of attributes and parameters should be instantiated UML 1.1 UML 1.2 Resolved closed
UML14-867 Merge "Class" and "Interface" into one class UML 1.1 UML 1.2 Resolved closed
UML14-866 UML 1.1 issue on Associations UML 1.1 UML 1.2 Resolved closed
UML14-865 Extension Point UML 1.1 UML 1.2 Resolved closed
UML14-864 Specification for method in a derived class UML 1.1 UML 1.2 Resolved closed
UML14-863 State diagrams: action expressions UML 1.1 UML 1.2 Resolved closed
UML14-860 Responsibilities hardly figure in these documents 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-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-856 Page 94 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-855 Page 82: Add explanation UML 1.1 UML 1.2 Resolved closed
UML14-854 Page 80: Confusion with headings UML 1.1 UML 1.2 Resolved closed
UML14-852 Page 72: Example needs rejigging UML 1.1 UML 1.2 Resolved closed
UML14-851 Page 71: Distinction between Dependency and Association UML 1.1 UML 1.2 Resolved closed
UML14-849 Page 67: Why is discriminator not discussed in terms of power types? UML 1.1 UML 1.2 Resolved closed
UML14-850 Page 68 overlapping 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-846 Page 52 figure 20 UML 1.1 UML 1.2 Resolved closed
UML14-845 Typos on pages 24, 40, and 50 UML 1.1 UML 1.2 Resolved closed
UML14-848 Page 58: Add index entry UML 1.1 UML 1.2 Resolved closed
UML14-847 Page 57: mathematical issue UML 1.1 UML 1.2 Resolved closed
UML14-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-841 Page 30: Class scope attribute underlined UML 1.1 UML 1.2 Resolved closed
UML14-840 Page 29: Protected member UML 1.1 UML 1.2 Resolved closed
UML14-842 Page 35/6 : Stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-839 Page 26: rename reponsibilities, rules, modification histories etc. UML 1.1 UML 1.2 Resolved closed
UML14-838 Page 24 Section 5.4.3 para 1: missing compartments UML 1.1 UML 1.2 Resolved closed
UML14-837 Page 24: add link to Interface UML 1.1 UML 1.2 Resolved closed
UML14-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-836 Page 20: Section 4.3.1 could be misleading UML 1.1 UML 1.2 Resolved closed
UML14-833 Editorials on pages iv, v, 3, and 4 UML 1.1 UML 1.2 Resolved closed
UML14-832 Typos on page 90, 151 plus errors in page numbering UML 1.1 UML 1.2 Resolved closed
UML14-831 Page 143: "uses" as a stereotype on Generalization UML 1.1 UML 1.2 Resolved closed
UML14-830 Page 143: uses is a stereotyped dependency UML 1.1 UML 1.2 Resolved closed
UML14-829 Page 136: Model package relationship UML 1.1 UML 1.2 Resolved closed
UML14-828 Page 98: Transition is an aggregation of guards UML 1.1 UML 1.2 Resolved closed
UML14-827 Uses and extends not types of generalization UML 1.1 UML 1.2 Resolved closed
UML14-826 Page 93: use case UML 1.1 UML 1.2 Resolved closed
UML14-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-825 Page 93: Is Namespace really aggregeation of use cases? UML 1.1 UML 1.2 Resolved closed
UML14-822 Page 50 Table 3 "refinement" UML 1.1 UML 1.2 Resolved closed
UML14-818 Page 47: Dependency is a unidirectional, client-server UML 1.1 UML 1.2 Resolved closed
UML14-817 Page 45 dependency lines 2/3 between model elements not instances? UML 1.1 UML 1.2 Resolved closed
UML14-820 Page 50: should stereotypes be defined at the subclass level? UML 1.1 UML 1.2 Resolved closed
UML14-819 Page 50: "instance" should be changed to "instatiate" UML 1.1 UML 1.2 Resolved closed
UML14-821 Page 50: table 3 component UML 1.1 UML 1.2 Resolved closed
UML14-814 Page 38 para 2 line 3, one of its containers is deleted UML 1.1 UML 1.2 Resolved closed
UML14-813 Page 35 Diagram (02) UML 1.1 UML 1.2 Resolved closed
UML14-812 Page 35 -Diagram UML 1.1 UML 1.2 Resolved closed
UML14-811 Class to be defined as an intension UML 1.1 UML 1.2 Resolved closed
UML14-816 Aggregation of class? UML 1.1 UML 1.2 Resolved closed
UML14-815 Page 40 table 2 Model Element class UML 1.1 UML 1.2 Resolved closed
UML14-810 How to stop an interface realizing a Data Type ? UML 1.1 UML 1.2 Resolved closed
UML14-809 Why does GeneralizableElement inherit from Namespace? UML 1.1 UML 1.2 Resolved closed
UML14-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-807 Is name space really a *composite aggregation* of model elements? UML 1.1 UML 1.2 Resolved closed
UML14-805 Interface must also have features UML 1.1 UML 1.2 Resolved closed
UML14-804 Why is Classifier an Aggregate of Features? UML 1.1 UML 1.2 Resolved closed
UML14-803 Collaboration as a Classifier UML 1.1 UML 1.2 Resolved closed
UML14-802 Interfaces and support classes UML 1.1 UML 1.2 Resolved closed
UML14-801 UML Semantics, p 81, 145 UML 1.1 UML 1.2 Resolved closed
UML14-798 UseCaseInstance badly defined 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-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-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-797 Semantics of terminate transitions UML 1.1 UML 1.2 Resolved closed
UML14-790 Stereotypes for superclasses do not apply to superclasses UML 1.1 UML 1.2 Resolved closed
UML14-789 Inconsistent use of stereotypes, tagged values, and metamodel UML 1.1 UML 1.2 Resolved closed
UML14-788 Class WFR (01) UML 1.1 UML 1.2 Resolved closed
UML14-787 Modeling of realization/specification UML 1.1 UML 1.2 Resolved closed
UML14-791 Stereotype modeled in two ways UML 1.1 UML 1.2 Resolved closed
UML14-786 GeneralizableElement should not inherit from Namespace UML 1.1 UML 1.2 Resolved closed
UML14-785 Syntax for Sequence Expressions inconsistently used UML 1.1 UML 1.2 Resolved closed
UML14-784 Threads of control in Collaboration Diagrams UML 1.1 UML 1.2 Resolved closed
UML14-783 Control Flow types not modeled UML 1.1 UML 1.2 Resolved closed
UML14-782 RaiseAction and TimingMark are not defined UML 1.1 UML 1.2 Resolved closed
UML14-781 Mapping of concurrent subregions UML 1.1 UML 1.2 Resolved closed
UML14-780 "do" action not supported UML 1.1 UML 1.2 Resolved closed
UML14-779 Notation for iteration in sequence diagram UML 1.1 UML 1.2 Resolved closed
UML14-778 "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-775 WFR for bound elements missing UML 1.1 UML 1.2 Resolved closed
UML14-774 The meta-type of template parameters UML 1.1 UML 1.2 Resolved closed
UML14-773 Dependency wrongly mapped UML 1.1 UML 1.2 Resolved closed
UML14-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-772 Package importing transitive UML 1.1 UML 1.2 Resolved closed
UML14-771 "invoked" not defined UML 1.1 UML 1.2 Resolved closed
UML14-770 Bad example for LCA, main source, main target UML 1.1 UML 1.3 Resolved closed
UML14-769 Transition WFR badly written UML 1.1 UML 1.3 Resolved closed
UML14-768 Entry/Exit actions execution order UML 1.1 UML 1.2 Resolved closed
UML14-767 CompositeStates with non-composite subregions allowed UML 1.1 UML 1.2 Resolved closed
UML14-766 Message::base undefined UML 1.1 UML 1.2 Resolved closed
UML14-765 AssociationEnd-AssociationEndRole inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-764 Argument::type not defined UML 1.1 UML 1.2 Resolved closed
UML14-762 WFR for instance links UML 1.1 UML 1.2 Resolved closed
UML14-761 Well-formedness Rules for Action::actualArguments UML 1.1 UML 1.2 Resolved closed
UML14-760 CallAction::request UML 1.1 UML 1.2 Resolved closed
UML14-759 CallAction::isAsynchronous and CallAction::mode UML 1.1 UML 1.2 Resolved closed
UML14-763 MessageInstance not used 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-758 Action::isAsynchronous and Action::script not defined UML 1.1 UML 1.2 Resolved closed
UML14-757 Signal::isAsynchronous and Signal::direction not defined UML 1.1 UML 1.2 Resolved closed
UML14-756 Request"s parents UML 1.1 UML 1.2 Resolved closed
UML14-755 "implementation" association not defined UML 1.1 UML 1.2 Resolved closed
UML14-752 Signature conflicts across an inheritance hierarchy UML 1.1 UML 1.2 Resolved closed
UML14-751 Exotic uses of generalization UML 1.1 UML 1.2 Resolved closed
UML14-750 Set of inheritable features not defined UML 1.1 UML 1.3 Resolved closed
UML14-749 Correspondence between operation and method (02) UML 1.1 UML 1.3 Resolved closed
UML14-748 Correspondence between operation and method UML 1.1 UML 1.2 Resolved closed
UML14-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-747 Use of language-dependant type expressions UML 1.1 UML 1.2 Resolved closed
UML14-746 Return types for BehavioralFeatures UML 1.1 UML 1.2 Resolved closed
UML14-745 Package importing not well supported UML 1.1 UML 1.2 Resolved closed
UML14-739 UML Semantics 1.1, p26, Operation::isPolymorphic UML 1.1 UML 1.2 Resolved closed
UML14-741 Features and ownedElements (1) UML 1.1 UML 1.2 Resolved closed
UML14-740 Signature conflicts not well defined UML 1.1 UML 1.2 Resolved closed
UML14-738 OCL Specification 1.1, section 8 UML 1.1 UML 1.2 Resolved closed
UML14-737 OCL specification 1.1, p. 14, 5.13, example UML 1.1 UML 1.2 Resolved closed
UML14-736 OCL specification 1.1, p. 15, 5.14, second last paragraph UML 1.1 UML 1.2 Resolved closed
UML14-733 OCL specification 1.1, p. 32 UML 1.1 UML 1.3 Resolved closed
UML14-732 OCL specification 1.1, p. 10, 5.4.3, example 3 UML 1.1 UML 1.2 Resolved closed
UML14-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-730 Definition of select and reject operations for Set"s is erranious UML 1.1 UML 1.2 Resolved closed
UML14-729 Difference between methods, attributes and operations not clear UML 1.1 UML 1.2 Resolved closed
UML14-728 Editorial issue: OCL spec 1.1, section 6.3, example 2, last row UML 1.1 UML 1.2 Resolved closed
UML14-727 UML 1.1 Semantics, section 8.2, page 66 UML 1.1 UML 1.2 Resolved closed
UML14-726 Contents of section "Control Icons" is vague UML 1.1 UML 1.2 Resolved closed
UML14-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-725 Missing word - editorial UML 1.1 UML 1.2 Resolved closed
UML14-724 Procedure undefined UML 1.1 UML 1.2 Resolved closed
UML14-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-719 deferredEvent mentioned twice in Abstract Syntax 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-717 Inconsistent definition of extends relationship UML 1.1 UML 1.2 Resolved closed
UML14-715 No mapping for TimingMark in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-714 No mapping for "transition string" UML 1.1 UML 1.2 Resolved closed
UML14-716 No notation for ActivityState 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-712 No mapping for swimlanes in Sequence Diagram UML 1.1 UML 1.3 Resolved closed
UML14-711 Property "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-710 Interface specifier not mapped UML 1.1 UML 1.2 Resolved closed
UML14-705 Well-formedness rules only expressed in English UML 1.1 UML 1.3 Resolved closed
UML14-704 Well-formedness rules missing UML 1.1 UML 1.2 Resolved closed
UML14-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-700 Stereotypes applied to more than one ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-699 English contradicts OCL in rule for CompositeState UML 1.1 UML 1.2 Resolved closed
UML14-698 Misleading name Link.linkRole UML 1.1 UML 1.2 Resolved closed
UML14-697 Enumeration OperationDirectionKind obsolete UML 1.1 UML 1.2 Resolved closed
UML14-702 Inconsistent definition of stereotype " process" UML 1.1 UML 1.2 Resolved closed
UML14-701 Inconsistent definition of enumeration UML 1.1 UML 1.2 Resolved closed
UML14-696 ordered missing for Constraint.constrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-695 Inconsistent definition of stereotype "friend" UML 1.1 UML 1.2 Resolved closed
UML14-694 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-693 Wrong aggregation kind for templates UML 1.1 UML 1.2 Resolved closed
UML14-689 Inconsistent attachment of Activity Diagram UML 1.1 UML 1.2 Resolved closed
UML14-692 Method visibility UML 1.1 UML 1.2 Resolved closed
UML14-691 Feature.owner must be optional UML 1.1 UML 1.2 Resolved closed
UML14-690 Extension points of operations not defined UML 1.1 UML 1.2 Resolved closed
UML14-688 Inconsistent definition of state machine attachment UML 1.1 UML 1.2 Resolved closed
UML14-687 Inconsistent format of signal/event UML 1.1 UML 1.2 Resolved closed
UML14-686 More arrow types than message kinds UML 1.1 UML 1.2 Resolved closed
UML14-684 Attachment of message in Sequence Diagram 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-681 UML 1.0: Template example cannot be representaed in model UML 1.1 UML 1.3 Resolved closed
UML14-683 UML 1.0: Unknown model element "Qualifier" 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-679 UML 1.0: multiplicity "unspecified" not possible UML 1.1 UML 1.2 Resolved closed
UML14-676 Inconsistent name space rules UML 1.1 UML 1.2 Resolved closed
UML14-675 UML 1.0: instances UML 1.1 UML 1.3 Resolved closed
UML14-678 UML 1.0: Stereotype "uses" applied to more than one class UML 1.1 UML 1.2 Resolved closed
UML14-677 Inconsistent name for stereotype implementationClass UML 1.1 UML 1.2 Resolved closed
UML14-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-669 UML 1.0: Attachment of messages in Collaboration Diagrams 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-674 UML 1.0: Inconsistent arrow heads for dependencies UML 1.1 UML 1.2 Resolved closed
UML14-666 UML 1.o: Qualified things in Collaborations UML 1.1 UML 1.2 Resolved closed
UML14-665 UML 1.0: Collaborations not well defined UML 1.1 UML 1.2 Resolved closed
UML14-668 UML 1.0: No notation for ClassifierRole.availableFeature UML 1.1 UML 1.2 Resolved closed
UML14-667 UML 1.0: Collaborations and Association (role) UML 1.1 UML 1.2 Resolved closed
UML14-664 CallEvent: operation label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-663 Signal label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-662 Figure 15, AssociationRole class issue UML 1.1 UML 1.2 Resolved closed
UML14-659 Description of ActionSequence indicates that it is composition of Actions UML 1.1 UML 1.2 Resolved closed
UML14-658 ActionSequence class issue UML 1.1 UML 1.2 Resolved closed
UML14-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-657 Reception class has wrong attribute UML 1.1 UML 1.2 Resolved closed
UML14-656 Figure 12 shows no attributes for exceptions UML 1.1 UML 1.2 Resolved closed
UML14-655 Behavioral Features called context UML 1.1 UML 1.2 Resolved closed
UML14-654 Request class is not an abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-653 Action class is no abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-652 Description of ViewElement indicates that it is subclass of Element UML 1.1 UML 1.2 Resolved closed
UML14-647 Inconsistency of UML metamodel 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-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-645 UML Notation Guide, boolean properties UML 1.1 UML 1.2 Resolved closed
UML14-644 UML Notation Guide, association ends UML 1.1 UML 1.2 Resolved closed
UML14-646 Association between Method and Operation UML 1.1 UML 1.2 Resolved closed
UML14-643 UML stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-642 UML potential inconsistency about stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-641 Inconsistency of UML metamodel UML 1.1 UML 1.2 Resolved closed
UML14-640 Parameters/Attributes need Specification Classifiers UML 1.1 UML 1.2 Resolved closed
UML14-639 Predefined LinkEnd constraints issue UML 1.1 UML 1.2 Resolved closed
UML14-638 Predefined LinkEnd constraints shown as stereotypes in Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-636 diagram fragment at start of Model section on page 136 UML 1.1 UML 1.2 Resolved closed
UML14-635 No notation defined in the Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-634 ActivityState in Figure 22 UML 1.1 UML 1.2 Resolved closed
UML14-633 well-formedness rules for BehavioralFeature UML 1.1 UML 1.2 Resolved closed
UML14-637 Figure 8 (Semantics, p. 44) UML 1.1 UML 1.2 Resolved closed
UML14-630 Figure 5 Semantics document (p. 16) UML 1.1 UML 1.2 Resolved closed
UML14-629 Second para, Section 5.16.1: conflict with statement on p 141 UML 1.1 UML 1.2 Resolved closed
UML14-632 Well-formedness rulw [2] for Class (Semantics, p. 27-28) UML 1.1 UML 1.2 Resolved closed
UML14-631 Well-formedness rule [4] for Association UML 1.1 UML 1.2 Resolved closed
UML14-628 Section 5.16.1--editorial UML 1.1 UML 1.2 Resolved closed
UML14-627 Page 53 UML semantics: base class of TaggedValue not shown UML 1.1 UML 1.2 Resolved closed
UML14-624 Missing role descriptions UML 1.1 UML 1.2 Resolved closed
UML14-623 ModelElement Associations (02) UML 1.1 UML 1.2 Resolved closed
UML14-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-618 Package dependencies (07) 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-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-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-609 Page 10 UML 1.1 Semantics, duplicate entries listed UML 1.1 UML 1.2 Resolved closed
UML14-608 Page 98 of UML 1.1 Semantics, figure 18 (02) UML 1.1 UML 1.2 Resolved closed
UML14-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-607 Page 98 of UML 1.1 Semantics, figure 18 UML 1.1 UML 1.2 Resolved closed
UML14-606 Page 98 of UML 1.1 Semantics, figure 17 (04) UML 1.1 UML 1.2 Resolved closed
UML14-605 Page 98 of UML 1.1 Semantics, figure 17 (03) UML 1.1 UML 1.2 Resolved closed
UML14-604 Page 98 of UML 1.1 Semantics, figure 17 (02) UML 1.1 UML 1.2 Resolved closed
UML14-603 Page 98 of UML 1.1 Semantics, figure 17 (01) UML 1.1 UML 1.2 Resolved closed
UML14-598 Page 43 of UML Semantics, figure 7 UML 1.1 UML 1.2 Resolved closed
UML14-597 Page 43 UML 1.1 Semantics, figure 7 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-600 Page 46 of UML 1.1 Semantics, description of associations for ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-599 Page 44 UML 1.1 Semantics, figure 8 UML 1.1 UML 1.2 Resolved closed
UML14-602 Page 47 of UML 1.1 Semantics, description of ViewElement UML 1.1 UML 1.2 Resolved closed
UML14-601 Page 47 of UML 1.1 Semantics, description of Refinement UML 1.1 UML 1.2 Resolved closed
UML14-596 Page 16 of UML Semantics, figure 5 UML 1.1 UML 1.2 Resolved closed
UML14-595 Page 62---editorial UML 1.1 UML 1.2 Resolved closed
UML14-594 Page 62 "PseudostateKind"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-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-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-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-585 Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele UML 1.1 UML 1.2 Resolved closed
UML14-584 Page 40 table2: Generalization model element UML 1.1 UML 1.2 Resolved closed
UML14-583 page 40 table2: Classifier model element UML 1.1 UML 1.2 Resolved closed
UML14-582 Page 40 table 2:Constraints Model UML 1.1 UML 1.2 Resolved closed
UML14-581 Page 40, table 2: Core - Standard Elements UML 1.1 UML 1.2 Resolved closed
UML14-580 Page 54 - ConstrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-579 Page 39 - ModelElement/Dependency associations UML 1.1 UML 1.2 Resolved closed
UML14-578 Page 16- The association from parameter to classifier has a 1-1 cardinalit UML 1.1 UML 1.2 Resolved closed
UML14-577 Page 121 - Partition has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-576 Page 98: ActionSequence has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-572 Page 60 - GraphicMarker UML 1.1 UML 1.2 Resolved closed
UML14-574 Page 35/37 - AssociationRole UML 1.1 UML 1.2 Resolved closed
UML14-573 Page 60 - MultiplicityRange UML 1.1 UML 1.2 Resolved closed
UML14-575 Page 81: message has no parent class 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-568 page 60 - CallConcurrencyKind UML 1.1 UML 1.2 Resolved closed
UML14-570 Page 60 - PseudostateKind UML 1.1 UML 1.2 Resolved closed
UML14-564 UML Documentation--Typos (05) 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-567 Error on association owners UML 1.1 UML 1.2 Resolved closed
UML14-562 UML Documentation--Typos (03) UML 1.1 UML 1.2 Resolved closed
UML14-561 UML Documentation--Typos (02) UML 1.1 UML 1.2 Resolved closed
UML14-560 UML Documentation-Typos (01) UML 1.1 UML 1.2 Resolved closed
UML14-563 UML Documentation--Typos (04) UML 1.1 UML 1.2 Resolved closed
UML14-559 UML 2 issue, Common Behaviors RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-558 Components / provided and required interfaces -- derived or subsets XMI 2.0 UML 1.4.2 Resolved closed
UML14-557 Feature;ModelElement UML 1.5 UML 1.4.2 Resolved closed
UML14-554 "Physical" Metamodel Package Structure (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-556 TaggedValue in TaggedValue XMI 1.3 UML 1.4.2 Resolved closed
UML14-555 Ambiguous semantics of classifier ownerscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-471 UML2 super/notation/Keywords XMI 2.0 UML 1.4.2 Resolved closed
UML14-470 Appendix B/Standard Stereotypes too heavyweight and incompletely defined XMI 2.0 UML 1.4.2 Resolved closed
UML14-480 UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition XMI 2.0 UML 1.4.2 Resolved closed
UML14-479 The contents of the Interfaces package is shown in Figure 51 XMI 2.0 UML 1.4.2 Resolved closed
UML14-482 UML 2 Super / Interactions / navigability of enclosingOperation XMI 2.0 UML 1.4.2 Resolved closed
UML14-481 UML 2 Super / Dependencies / Abstraction should have an optional mapping XMI 2.0 UML 1.4.2 Resolved closed
UML14-478 UML 2 Super / Templates / subsetting templateParameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-477 UML 2 Super / General / Idenitfy sections specifying run-time semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-476 UML 2 Super / Classes / XMI 2.0 UML 1.4.2 Resolved closed
UML14-473 importedMember property XMI 2.0 UML 1.4.2 Resolved closed
UML14-475 UML 2 Super / Interactions / Two typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-474 missing closing bracket XMI 2.0 UML 1.4.2 Resolved closed
UML14-472 "• value : InstanceSpecification XMI 2.0 UML 1.4.2 Resolved closed
UML14-377 Corrections and improvements to glossary definitions UML 1.5 UML 1.4.2 Resolved closed
UML14-376 The name "required interface" is misleading UML 1.5 UML 1.4.2 Resolved closed
UML14-373 UML 2.0 significant typo - collaboration diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-372 targetScope on StructuralFeature and AssociationEnd UML 1.5 UML 1.4.2 Resolved closed
UML14-375 Specification of parametric models UML 1.5 UML 1.4.2 Resolved closed
UML14-374 Excessive syntactic and semantic overlap between structured Classifiers UML 1.5 UML 1.4.2 Resolved closed
UML14-371 UML Superstructure: 03-08-02 / <> UML 1.5 UML 1.4.2 Resolved closed
UML14-370 ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort UML 1.5 UML 1.4.2 Resolved closed
UML14-369 ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint UML 1.5 UML 1.4.2 Resolved closed
UML14-368 Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-553 Issue 6090 correction RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-543 UML2 Super / Classes / Operation constraints XMI 2.0 UML 1.4.2 Resolved closed
UML14-542 UML2 Super / ordering of association ends XMI 2.0 UML 1.4.2 Resolved closed
UML14-541 Q re Parameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-537 UML2 super/interactions XMI 2.0 UML 1.4.2 Resolved closed
UML14-536 UML 2 Super / Templates / invalid multiplicity XMI 2.0 UML 1.4.2 Resolved closed
UML14-535 UML 2 Super / Profiles / problem with name collisions XMI 2.0 UML 1.4.2 Resolved closed
UML14-548 XMI schema (02) RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-547 Question about Enumeration and EnumerationLiteral XMI 2.0 UML 1.4.2 Resolved closed
UML14-540 UML 2 Super / missing owners of concepts XMI 2.0 UML 1.4.2 Resolved closed
UML14-539 UML 2 Super / state machines / state should be a namespace XMI 2.0 UML 1.4.2 Resolved closed
UML14-538 UML 2 Super/Connector XMI 2.0 UML 1.4.2 Resolved closed
UML14-546 UML2 Super / Common Behavior / Trigger should be a named element XMI 2.0 UML 1.4.2 Resolved closed
UML14-545 UML2 Super / Use cases / navigation from subject to use case XMI 2.0 UML 1.4.2 Resolved closed
UML14-544 UML 2 Super / General / superclass pointers XMI 2.0 UML 1.4.2 Resolved closed
UML14-552 Issue 6094 correction. RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-551 UML 2 Super/Interactions/Need unattached lifelines RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-534 transition is simply never enabled XMI 2.0 UML 1.4.2 Resolved closed
UML14-533 UML Sequence diagram XMI 2.0 UML 1.4.2 Resolved closed
UML14-550 property strings on association ends RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-549 change trigger RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-405 Clarify termination of asynchronous invocations UML 1.5 UML 1.4.2 Resolved closed
UML14-404 Appendix A Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-403 Section 17 UML 1.5 UML 1.4.2 Resolved closed
UML14-396 Section 8.3.3 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-395 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-401 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-400 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-394 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-399 Section 14.3.14 Message UML 1.5 UML 1.4.2 Resolved closed
UML14-398 Section 10 Deployments UML 1.5 UML 1.4.2 Resolved closed
UML14-393 Section 8.1 Overview UML 1.5 UML 1.4.2 Resolved closed
UML14-402 Section 14.4 Diagrams (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-397 Section 9.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-450 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-449 UML2 Super/Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-457 UML 2 Super / Activities / association end naming UML 1.5 UML 1.4.2 Resolved closed
UML14-456 UML 2 Super / Activities / inconsistency in representing subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-454 UML 2 Super/Activities/assocition end specialization consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-452 subsettedProperty->forAll(sp | isDerivedUnion) ? UML 1.5 UML 1.4.2 Resolved closed
UML14-451 UML2 Super/Connector End UML 1.5 UML 1.4.2 Resolved closed
UML14-455 UML 2 Super/Activities/invalid multiplicity 0 UML 1.5 UML 1.4.2 Resolved closed
UML14-447 UML2 Super/Structured Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-453 UML 2 Super/Activities/end naming consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-448 Page 164 - there are two constraints sections for Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-444 UML 2.0 Superstructure Derived Union vs. derivationExpression? UML 1.5 UML 1.4.2 Resolved closed
UML14-443 UML 2.0 Superstructure reccomendation (derived unions) UML 1.3 UML 1.4.2 Resolved closed
UML14-442 UML 2 Super / use cases / incorrect comments in notation section UML 1.5 UML 1.4.2 Resolved closed
UML14-441 Error in definition of PackageMergeKind UML 1.5 UML 1.4.2 Resolved closed
UML14-446 UML2 Super/parts UML 1.5 UML 1.4.2 Resolved closed
UML14-445 UML2 Super/Composite Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-437 section 9 (State Machines) of 3rd revision UML 1.5 UML 1.4.2 Resolved closed
UML14-436 UML 2 Super/Actions/PrimitiveFunction missing properties UML 1.5 UML 1.4.2 Resolved closed
UML14-434 Time trigger notation in state machines UML 1.5 UML 1.4.2 Resolved closed
UML14-433 No way to represent "uninterpreted" actions UML 1.5 UML 1.4.2 Resolved closed
UML14-438 UML 2 Super/Actions/non-existent feature "multiplicity" UML 1.5 UML 1.4.2 Resolved closed
UML14-435 Notation when guards are used in conjunction with triggers in transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-440 UML 2.0 Superstructure 3rd revision - Owner of triggers? UML 1.5 UML 1.4.2 Resolved closed
UML14-439 UML 2 Super/Action/featuringClassifier misinterpreted UML 1.5 UML 1.4.2 Resolved closed
UML14-493 UseCase - Constraint for non-circular include relation XMI 2.0 UML 1.4.2 Resolved closed
UML14-492 What level of MOF 2.0 is the metamodel for UML 2.0? XMI 2.0 UML 1.4.2 Resolved closed
UML14-484 UML 2 Super / Realize keyword-stereotype XMI 2.0 UML 1.4.2 Resolved closed
UML14-483 UML 2 Super / Classes / Properties owned by properties XMI 2.0 UML 1.4.2 Resolved closed
UML14-489 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367 XMI 2.0 UML 1.4.2 Resolved closed
UML14-488 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366 XMI 2.0 UML 1.4.2 Resolved closed
UML14-487 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365 XMI 2.0 UML 1.4.2 Resolved closed
UML14-486 UML 2 Super / Deployments / Invalid cross-references XMI 2.0 UML 1.4.2 Resolved closed
UML14-495 UML 2 Super / use cases / incorrect table title XMI 2.0 UML 1.4.2 Resolved closed
UML14-494 UseCase - Include - Constraint for irreflexivity XMI 2.0 UML 1.4.2 Resolved closed
UML14-485 UML 2 Super / Classes / Dependency should not be abstract XMI 2.0 UML 1.4.2 Resolved closed
UML14-496 UML2 superstructur: actor XMI 2.0 UML 1.4.2 Resolved closed
UML14-491 UML 2 Super / General / specialization labeling convention XMI 2.0 UML 1.4.2 Resolved closed
UML14-490 Typo in Collaboration Diagram figure XMI 2.0 UML 1.4.2 Resolved closed
UML14-386 UML 2 Issue: Connector types UML 1.5 UML 1.4.2 Resolved closed
UML14-385 glossary UML 1.5 UML 1.4.2 Resolved closed
UML14-383 Abandon the OMGS4LMMA UML 1.5 UML 1.4.2 Resolved closed
UML14-382 14.3: StateInvariant and ExecutionOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-381 UML 2.0 Superstructure FTF issue - Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-380 Removal of gratuitous restrictions to software applications UML 1.5 UML 1.4.2 Resolved closed
UML14-388 Section 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-387 UML 2 Issue: Include(s) and Extend(s) UML 1.5 UML 1.4.2 Resolved closed
UML14-379 Diagram Taxonomy corrections UML 1.5 UML 1.4.2 Resolved closed
UML14-378 Inconsistent use of terms "implement" and "realize" UML 1.5 UML 1.4.2 Resolved closed
UML14-392 Section 7.18 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-391 Section 7.15.3 Interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-384 Change 'Part' to 'Role. UML 1.5 UML 1.4.2 Resolved closed
UML14-390 Section 7.13.2 Package Merge UML 1.5 UML 1.4.2 Resolved closed
UML14-389 Section 7.3.5 PackageImport UML 1.5 UML 1.4.2 Resolved closed
UML14-412 concurrent vs. parallel ExpansionRegions UML 1.5 UML 1.4.2 Resolved closed
UML14-411 Use Case Metamodel - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-420 Operation without - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-419 Components and artifacts: Dependency problem - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-416 AcitivityEdge: weight=all vs weight=null - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-415 Large diamond for binary associations legal? - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-418 Guard conditions at fork nodes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-417 Token flow semantics: Implicit fork and join - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-409 Multiobject in UML2 UML 1.5 UML 1.4.2 Resolved closed
UML14-408 Outputting constants UML 1.5 UML 1.4.2 Resolved closed
UML14-414 Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-413 Binary associations decorated with large diamonds legal? UML 1.5 UML 1.4.2 Resolved closed
UML14-407 Protocol machines do not subset state invariant UML 1.5 UML 1.4.2 Resolved closed
UML14-406 Conditions for parameter sets (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-410 ActivityFinalNode and running actions - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-518 adopt a single notation to specify text strings used in the notation XMI 2.0 UML 1.4.2 Resolved closed
UML14-517 Appendix A of the superstructure spec XMI 2.0 UML 1.4.2 Resolved closed
UML14-516 UML 2 Super / Activities / Fig.192 constraint duplicated XMI 2.0 UML 1.4.2 Resolved closed
UML14-515 Ambiguous semantics of isStatic - resubmission of issue 4446 XMI 2.0 UML 1.4.2 Resolved closed
UML14-514 UML 2 Super / Interactions / Invalid subsetting for enclosingOperand XMI 2.0 UML 1.4.2 Resolved closed
UML14-513 UML 2 Super / Classes / makesVisible () operation incorrect XMI 2.0 UML 1.4.2 Resolved closed
UML14-512 Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition XMI 2.0 UML 1.4.2 Resolved closed
UML14-526 Operations and derived attributes XMI 2.0 UML 1.4.2 Resolved closed
UML14-525 use of stereotypes XMI 2.0 UML 1.4.2 Resolved closed
UML14-524 UML 2 Super / Appendix A / Typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-523 UML 2 Super/Interactions/Alternative with all false guards XMI 2.0 UML 1.4.2 Resolved closed
UML14-522 UML 2 Super / General / Classes chapter organization XMI 2.0 UML 1.4.2 Resolved closed
UML14-521 UML 2 Super / State machines / incorrect navigation specifications XMI 2.0 UML 1.4.2 Resolved closed
UML14-520 UML 2 Super / General / consistent formatting conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-519 UML 2 Super / General / Dcoument conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-528 Activity Diagrams: Relax Traverse-to-Completion semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-530 UML2 super/Deployments/CommunicationPath XMI 2.0 UML 1.4.2 Resolved closed
UML14-529 State machines / name of transitions association end XMI 2.0 UML 1.4.2 Resolved closed
UML14-532 UML2 Super/Composite Structure XMI 2.0 UML 1.4.2 Resolved closed
UML14-531 UML 1 activities XMI 2.0 UML 1.4.2 Resolved closed
UML14-527 Composite Structures, 03-08-02.pdf XMI 2.0 UML 1.4.2 Resolved closed
UML14-431 Incorrect usage/definition of "emergence" in Common Behavior Chapter UML 1.5 UML 1.4.2 Resolved closed
UML14-427 The node "Order cancel request" that appears in figure 6-86 UML 1.5 UML 1.4.2 Resolved closed
UML14-426 GeneralizationSet Description clarification - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-429 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-428 Order cancel request UML 1.5 UML 1.4.2 Resolved closed
UML14-423 Package Extensibility <> - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-422 Dependency notation for interfaces - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-421 Inconsistency concerning VisibilityKind - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-424 does "is not instantiable" imply "isAbstract"? - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-425 Activity nodes and Stereotypes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-432 Missing actual arguments in submachines states UML 1.5 UML 1.4.2 Resolved closed
UML14-430 /pages 485,487,495/mixed names for state machine diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-511 Ambiguous example of a local action on a Lifeline in Figures 334, 335 XMI 2.0 UML 1.4.2 Resolved closed
UML14-510 ambiguous definition of the scope of a break CombinedFragment XMI 2.0 UML 1.4.2 Resolved closed
UML14-509 UML 2 Super/Interactions/inconsistent spelling for InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-502 Ambiguous sentence and typo in description of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-501 graphic nodes for state invariant and continuation are not always distingui XMI 2.0 UML 1.4.2 Resolved closed
UML14-498 Ambiguous semantics of isStatic XMI 2.0 UML 1.4.2 Resolved closed
UML14-497 self-activation notation in Sequence diagrams missing XMI 2.0 UML 1.4.2 Resolved closed
UML14-505 UML 2 Super/Interactions/rationale subsections not informative XMI 2.0 UML 1.4.2 Resolved closed
UML14-504 UML 2 Super/Interactions/incorrect grammar for XMI 2.0 UML 1.4.2 Resolved closed
UML14-507 word "execute" in definition of alternative CombinedFragment is ambiguous XMI 2.0 UML 1.4.2 Resolved closed
UML14-506 UML 2 Super/Interactions/Ambiguous description of state invariants XMI 2.0 UML 1.4.2 Resolved closed
UML14-500 UML 2 Super/Interactions/incorrect text and table title for Table 19 XMI 2.0 UML 1.4.2 Resolved closed
UML14-499 UML 2 Super/Interactions/incorrect text before Table 14 XMI 2.0 UML 1.4.2 Resolved closed
UML14-503 UML 2 Super/Interactions/incorrect spelling of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-508 text differs from metamodel for critical region InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-466 UML 2 Super / state machines / incorrect property redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-465 UML 2 Super / state machines / non-existent property reference UML 1.5 UML 1.4.2 Resolved closed
UML14-462 Ambuiguity in value pin evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-461 page 136, "BasicComponents", UML 1.5 UML 1.4.2 Resolved closed
UML14-468 UML 2 Super / state machines / non-existent return type UML 1.5 UML 1.4.2 Resolved closed
UML14-467 UML 2 Super / state machines / misplaced operation definition UML 1.5 UML 1.4.2 Resolved closed
UML14-458 UML 2 Super / Activities / subsetting two properties UML 1.5 UML 1.4.2 Resolved closed
UML14-460 Consistent Naming UML 1.5 UML 1.4.2 Resolved closed
UML14-464 UML 2 Super / state machines / oclIsKindOf arguments error UML 1.5 UML 1.4.2 Resolved closed
UML14-459 UML2 Super/Signal UML 1.5 UML 1.4.2 Resolved closed
UML14-463 UML 2 Super/State machines/pseudostate name consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-469 UML 2 Super / use cases / invalid subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-366 ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2 UML 1.5 UML 1.4.2 Resolved closed
UML14-365 ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation UML 1.5 UML 1.4.2 Resolved closed
UML14-367 ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-364 UML 2 Infras./Interactions/ execution occurrence should not be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-219 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-225 7.4.1 Multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-224 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-218 Clarify that profiles can contain model libraries UML 1.5 UML 1.4.2 Resolved closed
UML14-217 Notation for anonymous instance UML 1.5 UML 1.4.2 Resolved closed
UML14-221 UML Superstructure 03-08-02: Loop node notation missing UML 1.5 UML 1.4.2 Resolved closed
UML14-220 UML Superstructure: 03-08-02 -- typos UML 1.5 UML 1.4.2 Resolved closed
UML14-215 Notation for attributes UML 1.5 UML 1.4.2 Resolved closed
UML14-214 Property string undefined UML 1.5 UML 1.4.2 Resolved closed
UML14-226 InstanceSpecification UML 1.5 UML 1.4.2 Resolved closed
UML14-216 Instantiates stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-223 No notation defined for suppressing attributes or operations UML 1.5 UML 1.4.2 Resolved closed
UML14-222 Notation mismatch for the realization dependency UML 1.5 UML 1.4.2 Resolved closed
UML14-177 Parameter set corrections 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-181 Streaming UML 1.5 UML 1.4.2 Resolved closed
UML14-180 Parameter set corrections 6 UML 1.5 UML 1.4.2 Resolved closed
UML14-179 Parameter set corrections 5 UML 1.5 UML 1.4.2 Resolved closed
UML14-178 Parameter set corrections 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-332 Outgoing edges of initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-331 Port is a Property in XMI UML 1.5 UML 1.4.2 Resolved closed
UML14-326 InformationFlow realization UML 1.5 UML 1.4.2 Resolved closed
UML14-325 Dependency multiplicity to CollaborationOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-330 Ports as properties UML 1.5 UML 1.4.2 Resolved closed
UML14-329 partWithPort without ports UML 1.5 UML 1.4.2 Resolved closed
UML14-323 Control pins UML 1.5 UML 1.4.2 Resolved closed
UML14-322 Profiles in fixed repositories UML 1.5 UML 1.4.2 Resolved closed
UML14-328 Association end names and part types UML 1.5 UML 1.4.2 Resolved closed
UML14-327 Deployment location UML 1.5 UML 1.4.2 Resolved closed
UML14-333 Guards on initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-324 Control at joins UML 1.5 UML 1.4.2 Resolved closed
UML14-228 7.11.2 Association UML 1.5 UML 1.4.2 Resolved closed
UML14-227 7.10.1 Operation UML 1.5 UML 1.4.2 Resolved closed
UML14-234 UML 2 Super/Metamodel::IntermediateActivities/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-233 BehaviorStateMachines/missing owningState end name UML 1.5 UML 1.4.2 Resolved closed
UML14-238 UML 2 Super/Metamodel::Kernel::DataTypes/missing renames UML 1.5 UML 1.4.2 Resolved closed
UML14-237 AuxiliaryConstructs::Templates::Operation/extra space UML 1.5 UML 1.4.2 Resolved closed
UML14-232 UML 2 Super/Metamodel::BasicBehaviors/package merge issue UML 1.5 UML 1.4.2 Resolved closed
UML14-231 7.15.3 Interface UML 1.5 UML 1.4.2 Resolved closed
UML14-235 UML 2 Super/Metamodel::Communications/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-229 7.14.1 Abstraction UML 1.5 UML 1.4.2 Resolved closed
UML14-236 UML 2 Super/Metamodel::Nodes/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-230 7.14.6 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-195 Pins on structured nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-194 Pins on structured nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-203 Action packaging UML 1.5 UML 1.4.2 Resolved closed
UML14-202 BroadcastSignalAction UML 1.5 UML 1.4.2 Resolved closed
UML14-196 Time spec text UML 1.5 UML 1.4.2 Resolved closed
UML14-200 Update actions for isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-193 ExpansionRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-197 Partition semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-198 Activity frame and parameter nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-201 actions on properties that are association ends UML 1.5 UML 1.4.2 Resolved closed
UML14-199 Activity frame and parameter nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-347 Flows across SAN boundaries UML 1.5 UML 1.4.2 Resolved closed
UML14-346 Initial nodes in structured actions UML 1.5 UML 1.4.2 Resolved closed
UML14-345 Parameters in Features and Common Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-342 Clarify join specs referencing control flow edges UML 1.5 UML 1.4.2 Resolved closed
UML14-341 Combining joined tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-349 AcceptCallAction in SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-348 Terminating a SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-344 Join example UML 1.5 UML 1.4.2 Resolved closed
UML14-343 Clarify join rules UML 1.5 UML 1.4.2 Resolved closed
UML14-336 Side effects of value specifications UML 1.5 UML 1.4.2 Resolved closed
UML14-335 Activity final clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-339 ReadSelfAction with no host UML 1.5 UML 1.4.2 Resolved closed
UML14-338 Decision behaviors on control tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-340 Clarify ReadSelfAction in activity behaviors UML 1.5 UML 1.4.2 Resolved closed
UML14-337 Guard evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-334 Caption typo UML 1.5 UML 1.4.2 Resolved closed
UML14-291 Confusion regarding XMI for use of stereotypes UML 1.5 UML 1.4.2 Resolved closed
UML14-290 Actors that are outside and inside the system UML 1.5 UML 1.4.2 Resolved closed
UML14-289 UML2 super/pgs.17 + 598/"topLevel" UML 1.5 UML 1.4.2 Resolved closed
UML14-288 Actor UML 1.5 UML 1.4.2 Resolved closed
UML14-287 Multiplicity of Regions owning Transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-286 State list UML 1.5 UML 1.4.2 Resolved closed
UML14-285 UML 2.0 serious layout problems with activity diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-284 Stereotypes for Actions UML 1.5 UML 1.4.2 Resolved closed
UML14-283 UML Superstructure: 03-08-02 / Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-282 UML 2 Super/Compliance points/confusing and redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-281 UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-280 UML 2 Super/pg.379/anyTrigger clarifications UML 1.5 UML 1.4.2 Resolved closed
UML14-279 UML 2 Super/pg. 556/notation for template binding inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-278 UML 2 Super/pg. 471/choice pseudostate notation UML 1.5 UML 1.4.2 Resolved closed
UML14-277 UML 2 Super/pg.471/unclear terminate state semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-276 UML 2 Super/pg.519/multiplicity semantics of use case associations UML 1.5 UML 1.4.2 Resolved closed
UML14-295 Question about InterruptibleActivityRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-294 fig 141 p205 and 7.13.2 p101 / just what sort of relationship is < UML 1.5 UML 1.4.2 Resolved closed
UML14-293 Metamodel for applying a stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-292 Association not affecting ends UML 1.5 UML 1.4.2 Resolved closed
UML14-275 UML 2 Super/pg.427/missing notation description for lifelines UML 1.5 UML 1.4.2 Resolved closed
UML14-274 UML 2 Super/pg.429/incorrect constraint for Message UML 1.5 UML 1.4.2 Resolved closed
UML14-273 UML 2 Super/pg.416/incorrect multiplicities for event occurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-272 UML 2 Super/pg.395/multiple meaning of exception UML 1.5 UML 1.4.2 Resolved closed
UML14-271 UML 2 Super/pg.235/missing semantics of destroy action UML 1.5 UML 1.4.2 Resolved closed
UML14-270 UML 2 Super/pg.130/incorrect stereotype name UML 1.5 UML 1.4.2 Resolved closed
UML14-267 UML 2 Super/pg.109/Permission redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-265 UML 2 Super/pg.64/Classifier redefinition notation UML 1.5 UML 1.4.2 Resolved closed
UML14-266 UML 2 Super/pg.95/attributes in data types clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-268 UML 2 Super/pg.99/misnamed "packageMerge" attribute UML 1.5 UML 1.4.2 Resolved closed
UML14-269 UML 2 Super/pg.130/missing notation explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-264 UML 2 Super/pg.79/underlined operation syntax missing UML 1.5 UML 1.4.2 Resolved closed
UML14-312 PackageMerge (from Kernel) UML 1.5 UML 1.4.2 Resolved closed
UML14-311 Sequence diagram conditions on Message arrows UML 1.5 UML 1.4.2 Resolved closed
UML14-319 UML2 Super/Instances UML 1.5 UML 1.4.2 Resolved closed
UML14-318 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-310 Recommendation for InteractionOccurrences UML 1.5 UML 1.4.2 Resolved closed
UML14-309 UML 2 Super / Interactions / No way to model reply messages UML 1.5 UML 1.4.2 Resolved closed
UML14-321 description of Component on page 137 UML 1.5 UML 1.4.2 Resolved closed
UML14-320 Figure 61 UML 1.5 UML 1.4.2 Resolved closed
UML14-313 UML2.super (or infra)/Profiles-Stereotype (18.3.7) UML 1.5 UML 1.4.2 Resolved closed
UML14-317 UML 2 Super/Components & Deployment chapters missing OCL constraints UML 1.5 UML 1.4.2 Resolved closed
UML14-316 UML2 Super/Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-314 UML2 Super/Composite Structures UML 1.5 UML 1.4.2 Resolved closed
UML14-308 UML Superstructur 03-08-02: Notation for ConditionalNode is missing UML 1.5 UML 1.4.2 Resolved closed
UML14-315 UML2 Super/Kernel::Classifier UML 1.5 UML 1.4.2 Resolved closed
UML14-263 UML 2 Super/pg.78/missing return types syntax UML 1.5 UML 1.4.2 Resolved closed
UML14-262 UML 2 Super/pg.78/operation redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-258 UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements UML 1.5 UML 1.4.2 Resolved closed
UML14-257 UML 2 Super/Metamodel/missing namespaces for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-254 UML 2 Super/Metamodel/Mis-named Manifestation class UML 1.5 UML 1.4.2 Resolved closed
UML14-253 UML 2 Super/Metamodel::Templates/missing return type UML 1.5 UML 1.4.2 Resolved closed
UML14-261 UML 2 Super/Spec/completing mandatory sections UML 1.5 UML 1.4.2 Resolved closed
UML14-252 UML 2 Super/Metamodel::CommonBehaviors/redundant class? UML 1.5 UML 1.4.2 Resolved closed
UML14-256 UML 2 Super/Metamodel/missing owners for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-255 UML 2 Super/Metamodel/mis-spelled implementingClassifier" UML 1.5 UML 1.4.2 Resolved closed
UML14-260 UML 2 Super/Metamodel/missing source and target for InformationFlow UML 1.5 UML 1.4.2 Resolved closed
UML14-259 ProtocolStateMachines/ProtocolStateMachine not a type of Feature UML 1.5 UML 1.4.2 Resolved closed
UML14-209 Protocol state machines are not pre/postconditions UML 1.5 UML 1.4.2 Resolved closed
UML14-212 Replace "initial value" with "default value". UML 1.5 UML 1.4.2 Resolved closed
UML14-211 TimeObservationAction can't return values UML 1.5 UML 1.4.2 Resolved closed
UML14-208 Diamond notation for merge junctions UML 1.5 UML 1.4.2 Resolved closed
UML14-207 Activity attributes on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-213 Kernel::Classifier missing "attribute" UML 1.5 UML 1.4.2 Resolved closed
UML14-210 Interactions view of state machines/activities UML 1.5 UML 1.4.2 Resolved closed
UML14-206 Concrete Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-204 Composite structure dependent on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-205 Complex port UML 1.5 UML 1.4.2 Resolved closed
UML14-307 UML 2 Super / Interactions / no create message UML 1.5 UML 1.4.2 Resolved closed
UML14-306 UML2 Super / Primitive Types / implementation issue UML 1.5 UML 1.4.2 Resolved closed
UML14-296 UML super/Section 2/Compliance points UML 1.5 UML 1.4.2 Resolved closed
UML14-300 Defenition of redefines????? UML 1.5 UML 1.4.2 Resolved closed
UML14-299 UML 2 super/Composite Classes/Connecting parts of parts UML 1.5 UML 1.4.2 Resolved closed
UML14-303 UML2 Super / association end naming convention UML 1.5 UML 1.4.2 Resolved closed
UML14-302 UML2 Super / Classes/ Incorrect reference to "access" UML 1.5 UML 1.4.2 Resolved closed
UML14-305 UML 2 Super / State machines-CommonBehavior / undefined owner of triggers UML 1.5 UML 1.4.2 Resolved closed
UML14-304 UML2 Super / SimpleTime package / missing multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-298 fig236 Datastore example/Datastore should not directly linked with actions UML 1.5 UML 1.4.2 Resolved closed
UML14-297 UML 2 Super/p125 and p126/typos UML 1.5 UML 1.4.2 Resolved closed
UML14-301 What does redefines mean in package extensibility? UML 1.5 UML 1.4.2 Resolved closed
UML14-356 UML 2 Super / Interfaces / Cannot nest classes in interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-355 UML 2 Super / state machines / restriction on redefining transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-352 Typo on Notation for CombinedFragment? UML 1.5 UML 1.4.2 Resolved closed
UML14-351 Visibility of a Package UML 1.5 UML 1.4.2 Resolved closed
UML14-359 UML 2 Super / Simple Time / incorrect multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-358 UML 2 Super / Interface / missing owner of operation UML 1.5 UML 1.4.2 Resolved closed
UML14-361 UML 2 Super / Package Templates / StringExpression inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-360 UML 2 Super / Activities / inconsistent naming UML 1.5 UML 1.4.2 Resolved closed
UML14-353 Figure 395 requires a lot more explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-363 UML 2 super / Templates / parameters cannot have names UML 1.5 UML 1.4.2 Resolved closed
UML14-362 UML 2 Super / Deployments / node composition UML 1.5 UML 1.4.2 Resolved closed
UML14-350 Questions about CentralBufferNode semantic UML 1.5 UML 1.4.2 Resolved closed
UML14-354 UML 2 super / state machines / entry and exit actions cannot be redefined UML 1.5 UML 1.4.2 Resolved closed
UML14-357 UML 2 super / Activities / structured activity node contradiction UML 1.5 UML 1.4.2 Resolved closed
UML14-244 UML 2 Infra/Section 5.9/missing merge rules UML 1.5 UML 1.4.2 Resolved closed
UML14-243 UML 2 Super/Metamodel/package merge and visibility UML 1.5 UML 1.4.2 Resolved closed
UML14-247 UML 2 Super/Metamodel::BasicActivities/inGroup problem UML 1.5 UML 1.4.2 Resolved closed
UML14-246 UML 2 Super/Metamodel::StructuredClasses/erroneous association UML 1.5 UML 1.4.2 Resolved closed
UML14-245 UML 2 Super/Package Merge/redefinition rules and standard OO languages UML 1.5 UML 1.4.2 Resolved closed
UML14-241 UML 2 Super/Metamodel::Constructs/inconsistency with Kernel UML 1.5 UML 1.4.2 Resolved closed
UML14-240 UML 2 Super/Metamodel::BasicBehaviors/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-250 UML 2 Super/Package Merge/missing rule for operations UML 1.5 UML 1.4.2 Resolved closed
UML14-249 UML 2 Super/Metamodel::Compliance::L3/Missing merges UML 1.5 UML 1.4.2 Resolved closed
UML14-242 UML 2 Super/Metamodel/merging of non-redefinable model elements UML 1.5 UML 1.4.2 Resolved closed
UML14-239 UML 2 Super/Metamodel::Kernel::Packages/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-248 UML 2 Super/Metamodel::StructuredActivities/double redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-251 Profile/inability to attach a stereotype to an element UML 1.5 UML 1.4.2 Resolved closed
UML14-191 SendObjectAction UML 1.5 UML 1.4.2 Resolved closed
UML14-190 Clarification of insert UML 1.5 UML 1.4.2 Resolved closed
UML14-185 Colon notation for pins UML 1.5 UML 1.4.2 Resolved closed
UML14-184 Local pre/postcondition example UML 1.5 UML 1.4.2 Resolved closed
UML14-182 Parameter semantics clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-192 ExceptionHandler 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-189 No-token activity termination clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-187 Notation for for global pre/postconditions actions UML 1.5 UML 1.4.2 Resolved closed
UML14-183 Behavior execution instances UML 1.5 UML 1.4.2 Resolved closed
UML14-188 Notation for isSynchronous UML 1.5 UML 1.4.2 Resolved closed
UML14-186 Value Pin notation UML 1.5 UML 1.4.2 Resolved closed
UML14-171 ObjectFlowEffect UML 1.5 UML 1.4.2 Resolved closed
UML14-170 Optional parameters UML 1.5 UML 1.4.2 Resolved closed
UML14-176 Parameter set corrections 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-174 ObjectNode.isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-173 Reentrancy 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-169 Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-175 Parameter set corrections 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-172 ExecutableNode, ControlNode should be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-133 UML's use of the word "unique" for multiplicity is ambiguous UML 1.5 UML 1.4.2 Resolved closed
UML14-132 UML 2.0 Superstructure: Operation vs. Attribute notation UML 1.5 UML 1.4.2 Resolved closed
UML14-135 The description of DataType is plainly wrong in the specification UML 1.5 UML 1.4.2 Resolved closed
UML14-134 notation for shared aggregation UML 1.5 UML 1.4.2 Resolved closed
UML14-139 Question on Connectors - fig 2-17 UML 1.5 UML 1.4.2 Resolved closed
UML14-138 There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState UML 1.5 UML 1.4.2 Resolved closed
UML14-137 Well-Formedness Rules for Procedure on Common Behavior Package UML 1.5 UML 1.4.2 Resolved closed
UML14-141 An error in Figure 464 UML 1.5 UML 1.4.2 Resolved closed
UML14-140 PackageableElement UML 1.5 UML 1.4.2 Resolved closed
UML14-145 Figure 63 missing notation UML 1.5 UML 1.4.2 Resolved closed
UML14-144 Interface Figure 62 uses wrong notation UML 1.5 UML 1.4.2 Resolved closed
UML14-136 Description of GeneralizationSet UML 1.5 UML 1.4.2 Resolved closed
UML14-142 Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01 UML 1.5 UML 1.4.2 Resolved closed
UML14-143 Obsolete notation used in state machine - transition examples UML 1.5 UML 1.4.2 Resolved closed
UML14-55 Profile Notation UML 1.3 UML 1.4.2 Resolved closed
UML14-54 Appendix A, UML Standard Elements UML 1.3 UML 1.4.2 Resolved closed
UML14-58 Issue: Conflicting WFRs on Transition UML 1.3 UML 1.4.2 Resolved closed
UML14-57 Add Multiplicity to Parameter. UML 1.3 UML 1.4.2 Resolved closed
UML14-56 Events, signals, stimuli, etc. UML 1.3 UML 1.4.2 Resolved closed
UML14-61 Predefined datatypes XMI 1.2 UML 1.4.2 Resolved closed
UML14-60 The definition of Multiplicity in Datatypes does not list the range associa XMI 1.2 UML 1.4.2 Resolved closed
UML14-65 Component notation: logical compartments XMI 1.2 UML 1.4.2 Resolved closed
UML14-64 Exceptions do not correspond to common usage XMI 1.2 UML 1.4.2 Resolved closed
UML14-53 Clarify the origin of an Action in a Collaboration. UML 1.3 UML 1.4.2 Resolved closed
UML14-59 Ambiguous semantics of classifier targetscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-63 Event => Event Specification XMI 1.2 UML 1.4.2 Resolved closed
UML14-62 The text and OCL of rule #5 for Method do not say the same thing. XMI 1.2 UML 1.4.2 Resolved closed
UML14-37 Another State machine issue XMI 1.1 UML 1.4.2 Resolved closed
UML14-36 Data Types Misplaced in the "Physical" Metamodel (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-30 Inheritance violation in "Auxiliary Elements" XMI 1.0 UML 1.4.2 Resolved closed
UML14-33 class EnumerationLiteral issue XMI 1.0 UML 1.4.2 Resolved closed
UML14-35 Operations and Constraints Missing from "Physical" Metamodels XMI 1.1 UML 1.4.2 Resolved closed
UML14-31 Incomplete Inheritance Specification XMI 1.0 UML 1.4.2 Resolved closed
UML14-32 Datatypes: Expression XMI 1.0 UML 1.4.2 Resolved closed
UML14-34 Interfaces on Nodes XMI 1.0 UML 1.4.2 Resolved closed
UML14-38 UML RTF 1.4 Issue: Dynamic concurrency arguments XMI 1.1 UML 1.4.2 Resolved closed
UML14-39 UML RTF 1.4 Issue: Parallel action iteration XMI 1.1 UML 1.4.2 Resolved closed
UML14-168 Pin/parameter matching 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-167 Pin/parameter matching 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-158 Weight=all UML 1.5 UML 1.4.2 Resolved closed
UML14-157 Provide notations for Loop and Conditional UML 1.5 UML 1.4.2 Resolved closed
UML14-163 Multiple outputs of object flow transformations UML 1.5 UML 1.4.2 Resolved closed
UML14-162 Keywords or properties UML 1.5 UML 1.4.2 Resolved closed
UML14-159 Tokens at fork UML 1.5 UML 1.4.2 Resolved closed
UML14-161 ExpansionRegions keywords UML 1.5 UML 1.4.2 Resolved closed
UML14-165 Pin/parameter matching 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-160 ActivityFinalNode UML 1.5 UML 1.4.2 Resolved closed
UML14-166 Pin/parameter matching 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-164 Pins owned twice UML 1.5 UML 1.4.2 Resolved closed
UML14-131 representation of arrays of values in an action language UML 1.5 UML 1.4.2 Resolved closed
UML14-130 2.5.2.29 Node UML 1.4 UML 1.4.2 Resolved closed
UML14-128 2.5.2.15 Dependency UML 1.4 UML 1.4.2 Resolved closed
UML14-123 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-122 Section: 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-129 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-121 Designates a Generalization (02) UML 1.4 UML 1.4.2 Resolved closed
UML14-125 2.5.2.27 ModelElement UML 1.4 UML 1.4.2 Resolved closed
UML14-126 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-124 2.5.2.16 Element UML 1.4 UML 1.4.2 Resolved closed
UML14-127 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-82 UML 1.4: ClassifierRole contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-81 UML 1.4: Node, Artifact, Package and Model contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-89 Suggest that alternate syntax used in section 6.5.5 be adopted thoughout XMI 1.3 UML 1.4.2 Resolved closed
UML14-88 Invalid XMI.link.atts in UML 1.4 DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-95 UML 1.4.1 should use MOF 1.4 XMI 1.3 UML 1.4.2 Resolved closed
UML14-94 Add action for invoking an activity XMI 1.3 UML 1.4.2 Resolved closed
UML14-84 UML 1.4: Wrong target for StateMachine.top association XMI 1.3 UML 1.4.2 Resolved closed
UML14-83 UML 1.4: AttributeLink containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-87 Definitions in glossary don't conform to any standard for definitions XMI 1.3 UML 1.4.2 Resolved closed
UML14-86 Composite relationship between Event and StateMachine XMI 1.3 UML 1.4.2 Resolved closed
UML14-92 Simplify inputs/outputs of procedures XMI 1.3 UML 1.4.2 Resolved closed
UML14-91 match/correspond clarfication XMI 1.3 UML 1.4.2 Resolved closed
UML14-93 StartStateMachine clarification XMI 1.3 UML 1.4.2 Resolved closed
UML14-90 Namespace.contents XMI 1.3 UML 1.4.2 Resolved closed
UML14-85 Adding events to the class definition XMI 1.3 UML 1.4.2 Resolved closed
UML14-17 Parametrizable model elements not shown XMI 1.0 UML 1.4.2 Resolved closed
UML14-119 Inconsistency regarding guards on forks XMI 1.3 UML 1.4.2 Resolved closed
UML14-118 spelling of the word Use Case XMI 1.3 UML 1.4.2 Resolved closed
UML14-110 There is an unnecessary condition in rule 1 of the Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-109 Rule 6 of the Method element isn't formulated well XMI 1.3 UML 1.4.2 Resolved closed
UML14-115 There is a misprint in rule 2 of the Object element: “Stimuli” instead of “ XMI 1.3 UML 1.4.2 Resolved closed
UML14-114 There are misprints with numeration of rules of the Instance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-112 there is something wrong with rule 3 of the Trace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-120 The first sentence is not consistent with figure 2-9 on page 2-17 XMI 1.3 UML 1.4.2 Resolved closed
UML14-113 Wrong alphabetical order: DataValue section should be before DestroyAction XMI 1.3 UML 1.4.2 Resolved closed
UML14-111 Add rule to Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-116 There is a misprint in rule 1 of the SubsystemInstance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-117 font sizes XMI 1.3 UML 1.4.2 Resolved closed
UML14-69 Using or implementing an interface of a Subsystem UML 1.4 UML 1.4.2 Resolved closed
UML14-68 XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD UML 1.4 UML 1.4.2 Resolved closed
UML14-67 Optimize Instance data values XMI 1.2 UML 1.4.2 Resolved closed
UML14-66 Component notation: showing delegation of messages XMI 1.2 UML 1.4.2 Resolved closed
UML14-75 UML 1.4: State containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-74 UML 1.4: Action problem in Collaborations XMI 1.3 UML 1.4.2 Resolved closed
UML14-80 UML 1.4: Event containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-79 UML 1.4: Stimulus containment XMI 1.3 UML 1.4.2 Resolved closed
UML14-77 UML 1.4: Transition containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-76 UML 1.4: ExtensionPoint containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-78 UML 1.4: Feature containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-72 Compliance to the UML" pp xxxi -- Editorial? UML 1.4 UML 1.4.2 Resolved closed
UML14-71 Nameclash in UML 1.4 UML 1.4 UML 1.4.2 Resolved closed
UML14-70 Using OCL at the meta-model level UML 1.4 UML 1.4.2 Resolved closed
UML14-73 UML 1.4: Action containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-19 Guard in current metamodel can be replaced by Constraint with stereotype XMI 1.0 UML 1.4.2 Resolved closed
UML14-18 Need for notation for dealing with evolution of UML models XMI 1.0 UML 1.4.2 Resolved closed
UML14-25 Missing OCL XMI 1.0 UML 1.4.2 Resolved closed
UML14-24 OCL needs to be added XMI 1.0 UML 1.4.2 Resolved closed
UML14-26 ElementOwnership XMI 1.0 UML 1.4.2 Resolved closed
UML14-28 extension to the notation for a transition XMI 1.0 UML 1.4.2 Resolved closed
UML14-23 Page 19 semantic doc. name XMI 1.0 UML 1.4.2 Resolved closed
UML14-22 UML 1.1.section 4.2:editorial XMI 1.0 UML 1.4.2 Resolved closed
UML14-27 User-defined symbols for tagged values and properties XMI 1.0 UML 1.4.2 Resolved closed
UML14-29 Associate a predicate with a state XMI 1.0 UML 1.4.2 Resolved closed
UML14-21 Figure 7 p. 43 of the UML semantics guide XMI 1.0 UML 1.4.2 Resolved closed
UML14-20 AssociationEnd needs ownerScope XMI 1.0 UML 1.4.2 Resolved closed
UML14-151 running a “Check Model” in Rose you get the following errors UML 1.5 UML 1.4.2 Resolved closed
UML14-154 Clarify wording on executable activity nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-153 Outgoing edges from input pins UML 1.5 UML 1.4.2 Resolved closed
UML14-150 UML2 super/pg. 580/Stereotype typo UML 1.5 UML 1.4.2 Resolved closed
UML14-149 UML2 super/pg.470/entry and exit points for composite states UML 1.5 UML 1.4.2 Resolved closed
UML14-148 Multiplicities diagram in section 7.4 UML 1.5 UML 1.4.2 Resolved closed
UML14-156 Action should be concrete UML 1.5 UML 1.4.2 Resolved closed
UML14-155 Edge constraint for control nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-146 Strange notation in Figure UML 1.5 UML 1.4.2 Resolved closed
UML14-152 Variable and Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-147 No Glossary in 03-08-02 UML 1.5 UML 1.4.2 Resolved closed
UML14-100 Initial state for composite states - OCL example and missing constraint XMI 1.3 UML 1.4.2 Resolved closed
UML14-99 UML 1.4 - Partition relates to nothing XMI 1.3 UML 1.4.2 Resolved closed
UML14-104 In v1.4, section 3.84.1 the paragraph on semantics XMI 1.3 UML 1.4.2 Resolved closed
UML14-103 Section 2.13.4.3 XMI 1.3 UML 1.4.2 Resolved closed
UML14-101 UML Issue - Inconsistency between UML 1.3 XMI and DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-107 Section number duplicated XMI 1.3 UML 1.4.2 Resolved closed
UML14-106 Section 3.90.2.2 XMI 1.3 UML 1.4.2 Resolved closed
UML14-97 Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState XMI 1.3 UML 1.4.2 Resolved closed
UML14-96 A_context_raisedSignal XMI 1.3 UML 1.4.2 Resolved closed
UML14-102 How does one indicate the target object for a CallState XMI 1.3 UML 1.4.2 Resolved closed
UML14-105 parameters of object flow states XMI 1.3 UML 1.4.2 Resolved closed
UML14-98 Well-formedness rules for 2.12.3.8 XMI 1.3 UML 1.4.2 Resolved closed
UML14-108 Swap rule 2 and rule 3 of the Binding element XMI 1.3 UML 1.4.2 Resolved closed
UML14-49 MOF rules should disallow certain composition relationships UML 1.3 UML 1.4.2 Resolved closed
UML14-48 Notation for inherited associations UML 1.3 UML 1.4.2 Resolved closed
UML14-52 Conflicting constraint between ActivityGraph and StateMachine. UML 1.3 UML 1.4.2 Resolved closed
UML14-51 Attributes obsolete in UML 1.3 UML 1.3 UML 1.4.2 Resolved closed
UML14-50 Interface of an object UML 1.3 UML 1.4.2 Resolved closed
UML14-46 Why is a StateMachine's top a State instead of a CompositeState? UML 1.3 UML 1.4.2 Resolved closed
UML14-45 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings XMI 1.1 UML 1.4.2 Resolved closed
UML14-42 Efficient diagrammatic notation for Collaboration Specifications XMI 1.1 UML 1.4.2 Resolved closed
UML14-41 Statemachine/state as Namespace XMI 1.1 UML 1.4.2 Resolved closed
UML14-40 UML RTF 1.4 Issue: Missing notation mapping for association in composite XMI 1.1 UML 1.4.2 Resolved closed
UML14-47 Document 99-06-08 - UML Spec UML 1.3 UML 1.4.2 Resolved closed
UML14-43 ClassifierRoles should be independent of specific underlying base Classifi XMI 1.1 UML 1.4.2 Resolved closed
UML14-44 UML 1.4 issue: Top state in activity graphs XMI 1.1 UML 1.4.2 Resolved closed
UML14-7 issues and bugs on the UML 1.4 Draft UML 1.3 UML 1.4 Resolved closed
UML14-6 class TaggedValuewill two association-ends with the same name "stereotype" UML 1.3 UML 1.4 Resolved closed
UML14-14 Figure 2-15 of the uml 1.4 spec UML 1.3 UML 1.4 Resolved closed
UML14-13 page 2-163, the statemachine semantics escription UML 1.3 UML 1.4 Resolved closed
UML14-16 isPolymorphic is never in a diagram UML 1.3 UML 1.4 Resolved closed
UML14-15 well-formedness rule for Package is missing inUML 1.4 UML 1.3 UML 1.4 Resolved closed
UML14-10 it's => its on page 3-150. UML 1.3 UML 1.4 Resolved closed
UML14-9 Wf 2 for AssociationEnd UML 1.3 UML 1.4 Resolved closed
UML14-8 2.9.2 Abstract Syntax UML 1.3 UML 1.4 Resolved closed
UML14-12 Notation example typo in Fig. 3-99 UML 1.3 UML 1.4 Resolved closed
UML14-11 The glossary entry "call" should be "call state". UML 1.3 UML 1.4 Resolved closed
UML14-3 elimination of the Association Class TemplateParameter UML 1.3 UML 1.4 Resolved closed
UML14-2 2) Page 2-49, additional operation #7 for Classifier UML 1.3 UML 1.4 Resolved closed
UML14-5 Remove uses of multiple inheritance from UML meta model UML 1.3 UML 1.4 Resolved closed
UML14-4 Who owns a Comment? UML 1.3 UML 1.4 Resolved closed
UML14-1 Page 2-47, well-formedness rule #2 for Classifier UML 1.3 UML 1.4 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

Compliance ambiguity

  • Key: UML14-1045
  • Legacy Issue Number: 4466
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Although the current specification defines the basic units of
    compliance for UML, it does not clearly specify the extent to which they may
    be omitted (via the "no/incomplete" Valid Options in the summary table on p.
    xxv) before the implementation is not considered OMG UML. (As a degenerate
    case, it could be argued that they all could be omitted and that an
    implementation might still claim compliance.) Further note that the optional
    compliance of OCL is discussed as a special case on p. xxiii, although no
    special treatment of its compliance is reflected in the summary table.
    Optional compliance needs to be more clearly specified before we consider
    future optional compliance points, as some are proposing for the Action
    Semantics.

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Duplicate or Merged — UML 1.4
  • Disposition Summary:

    duplicate

  • Updated: Sun, 8 Mar 2015 18:39 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

Change syntax of certain pre-defined operations

  • Key: UML14-1043
  • Legacy Issue Number: 3390
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    In the OCL specification, properties of Collections like
    'isEmpty', 'size' etc. are defined as operations with
    pre and postconditions. Their syntax however is as attributes without
    parenthesis.
    For consistency it would be more clear to change the sytax of these
    predefined operations to use parenthesis as in 'isEmpty()', just
    like other operations.
    The same holds for operations on other predefined types like
    Real::floor.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Package symbol as a polygon

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

    Summary: A package is a grouping of model elements. However, the rectangular shape of the package symbol makes it difficult to group model elements that have fixed geometrical position to each-other. In other words, the rectangular package shape often requires to change geometrical position of the model elements that belong to the group. It is almost impossible to use the rectangular package to show overlapping groups of model elements.

    For example, it is difficult to use the rectangular package symbol to show the objects in a class diagram that belong to a certain thread, or to show the use cases in a use case diagram that belong to a certain group.

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

    declined

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

There is a bug in additional operation 1 of the Namespace element

  • Key: UML14-1041
  • Legacy Issue Number: 5733
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: “contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)”.

  • Reported: UML 1.4 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Issue 4848 also raises a similar problem with Namespace.contents

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

How to properly designate exception returned from message sent to Java obje

  • Key: UML14-1040
  • Legacy Issue Number: 5433
  • Status: closed  
  • Source: ObjectShare ( Rebecca Wirfs-Broc)
  • Summary:

    I am trying to properly designate an exception returned from a message sent to a Java object.

    In UML a return is drawn as a dashed line with an open arrow. But is that the same for an exception returned? I can stereotype a return with the <<exception>> which is fine , but how do I properly draw the returned exception. I don't think the exception should be drawn the same as an asynchronous signal because control pops out from the exception raiser and returns to the callee at the exception handling point (it is the result of the original call, but the exception return is to a different point in the flow).... so it isn't exactly a signal.... but it does alter the control flow..

    So in my mind, if I wanted to show a returned exception, I should draw it like a return (dashed line with open stick arrowhead) labelled <<exception>>

    But I defer to someone with more expertise to untangle this for me. I spent time and could not find an answer to this in the UML 1.4 docs

  • Reported: UML 1.4 — Mon, 17 Jun 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of the issue addressed by issue 7397.

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

In 3.23.1 "Notation" (Internationalization issues)

  • Key: UML14-1039
  • Legacy Issue Number: 4120
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    > In 3.23.1 "Notation", it is described that
    > italics are used to represent abstract classes.
    > We don't usally use slanting letters in Japanese.
    > It seems strange. So, I think this should be moved into
    > "Presentaion Options" or "Style Guidelines".
    >
    > In 3.22.4 "Style Guidelines",
    > it is described that uppercase letters are
    > used to represent class names and
    > lowercase letters are used to represent attributes
    > and operation names.
    > Japanese language doesn't have uppercase nor lowercase
    > letters. However, this is "Style Guidelines", so I think
    > this is not a problem, because the specification already
    > says that "Style Guideline" and "Presentation Option" are
    > not mandatory.

  • Reported: UML 1.3 — Sat, 9 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

No servant with object . minorcode=0 completed=NO

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

    I am running a simple program but i am getting the error

    "There is no servant with object . minorcode=0 completed=NO"

    but i am not finding any documentation that explains abt the minorcode=0. it starts from 1. can u please help me out

  • Reported: UML 1.3 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Closed; No Change — UML 1.4
  • Disposition Summary:

    No Data Available

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

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4

  • Key: UML14-1037
  • Legacy Issue Number: 3637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4.4 as follows:

    2.9.4.25 Object and DataValue . 2-103
    2.9.4.26 Link . . . . . . . . . . 2-104
    2.9.4.27 Signal, Exception and Stimulus . 2-104
    2.9.4.28 Action . . . . . . . . 2-105

    It would appear that the fourth level carries on from 2.9.3.24

  • Reported: UML 1.3 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics

  • Key: UML14-1036
  • Legacy Issue Number: 3631
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    The Action ModelElement looks like it is abstract in the Rose MDL
    because the name is in italics.
    However, checking the details tab in Rose shows that it has not been marked
    as abstract.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

Who owns an Event?

  • Key: UML14-1035
  • Legacy Issue Number: 3558
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    An Event is aggregated by a transition but there seems to be no
    reference to who owns an event.
    If it should reside in a Package the OCL-WellFormedness rule for Package
    should be updated.

  • Reported: UML 1.3 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams)

  • Key: UML14-1033
  • Legacy Issue Number: 3400
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 9 - Statechart Diagrams
    1. In Part 9 - Statechart Diagrams:[Proposed changes in red for the
    first 3 suggestions.] "A statechart diagram can be used to describe the
    behavior of instances of a model element such as an object or an
    interaction. Specifically, it describes possible sequences of states and
    actions through which the element instance can proceed during its lifetime
    as a result of reacting to discrete events (e.g., signals, operation
    invocations). " [The idea is that model elements are not dynamic or have
    lifetimes; rather they apply to instances of model elements.]
    2. In 3.74.1: "Typically, it is used for describing the behavior of
    classes instances, but statecharts may also describe the behavior of other
    model entities such as use-cases, actors, subsystems, operations, or
    methods." [A method is an instance of an operation. Therefore, you must have
    implementation level knowledge, in this case, the programming language used,
    to know about a method. This is antithetical to good modeling principles
    which state that a model should be implementation independent.]
    3. In 3.74.3: "That StateMachine may be owned by an instance of a model
    element capable of dynamic behavior, ..."
    4. Event-name or action-label??? 3.75.2 says "Internal transitions
    compartment This compartment holds a list of internal actions or activities
    that are performed while the element is in the state. The notation for such
    each of these list items has the following general format: action-label '/'
    action-expression" and later "The general format for the list item of an
    internal transition is: event-name '(' comma-separated-parameter-list ')'
    '[' guard-condition']' '/'action-expression". Which is to be used? Or is
    action-label the name of the expression: event-name '('
    comma-separated-parameter-list ')' '[' guard-condition']'? Compare this with
    3.78.2 which has " event-signature '[' guard-condition ']' '/'
    action-expression. The event-signature describes an event with its
    arguments: event-name '(' comma-separated-parameter-list ')'"
    5. In 3.75.2: "If the event has parameters, they can be used in the
    action expression through the current event variable." Should it be
    action-expression for consistency?
    6. 3.75.4: "The action expression maps into the ActionSequence and
    Guard for the Transition." Should it be action-expression?
    7. 3.75.4: "The Transition has a trigger Association to the Event." The
    term trigger does not appear to be unambiguously defined. It was previously
    mentioned in the section. " In all other cases, the action label identifies
    the event that triggers the corresponding action expression." Is this
    sufficient? It is not in the glossary.
    8. The use of the term pseudostate is not consistent throughout. In the
    glossary it is "pseudo-state", with a hyphen. In 2.12.2 it is pseudostate.
    9. 3.76.3, Figure 3-63: Passed and Failed are activities and not
    states. Change to the right graphic.
    10. 3.78.1: " A simple transition is a relationship between two states
    indicating that an object in the first state ..." Object should probably be
    instance. (This should be looked at throughout the document.) I suspect this
    opens a can of worms but the definitions, and probably the concepts
    themselves, of instance and object need clarification.
    11. 3.80.4 Figure 3-66: Each of the two diagrams should have a top level
    state around it to keep the rule about not transitioning from a stubbed
    state to an external state. See below. Granted they are implied but we are
    trying to be clear.
    12. 3.80.5: Eliminate the word "elision". It is not a common word plus
    it appears to be misused. "Elision is the omission of sounds, syllables, or
    words in spoken or written discourse
    </lingualinks/library/literacy/glossary/cjJ405/tks2801.htm>." and "The
    omission of a letter or syllable as a means of contraction, generally to
    achieve a uniform metrical pattern, but sometimes to smooth the
    pronunciation; such omissions are marked with an apostrophe <gl-a.html>.
    Specific types of elision include aphaeresis <gl-a.html>, apocope
    <gl-a.html>, syncope <gl-s.html>, synaeresis <gl-s.html> and synaloepha
    <gl-s.html>." Suggest replace with shortcut.
    13. 3.81.2: " represented by a a small white circle" Eliminate one "a".
    14. 3.83.2: " The bound is either a positive integer or a star ('*') for
    unlimited." "Unlimited" should be "any number" and "star" should be
    "asterisk".

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Namespace notation too specific

  • Key: UML14-1034
  • Legacy Issue Number: 3408
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Namespace notation too specific

    The model management namespace containment notation (the circled plus
    sign ) should be available on all namespace elements.

  • Reported: UML 1.3 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

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

UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams)

  • Key: UML14-1032
  • Legacy Issue Number: 3399
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 6 - Use Case Diagrams
    1. 3.56.1: Use different class names in the relationships: extend use A
    & B, generalization use C & D, include use E & F for clarity.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

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

UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements)

  • Key: UML14-1031
  • Legacy Issue Number: 3398
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 3 - Behavioral Elements
    1. In 2.8: typo "that is used to model proocesses." Should be
    "processes"
    2. In 2.9.2, Figure 2-15: "Clas" should be "Class"
    3. In 2.9.2, Figure 2-15 and Argument: There is an internal
    inconsistency. The relationship from Argument to Action is diagrammed as a
    composition. The text says: [An argument] "is aggregated within an action."
    Is it aggregation or composition?
    4. Continuing #3: Also the glossary definition of composition ties
    non-fixed multiplicity and coincident lifetimes. Does 0..1 count as
    non-fixed? If so, where is it defined? What does this distinction mean in
    the first place?
    5. In 2.9.2, Instance: "The instance construct defines an entity to
    which a set of operations can be applied ..." Operation should be method.
    Operations exist at the Classifier level; methods are instances of
    operations and exist at the instance (application) level.
    6. In 2.9.2, Instance\Tagged Values\persistent: "Persistence denotes
    the permanence of the state of the instance, marking it as transitory (its
    state is destroyed when the instance is destroyed) or persistent (its state
    is not destroyed when the instance is destroyed)." Seems it should say that
    transitory is the default. Else add transitory as a tagged value.
    7. In 2.9.2, Figure 2-16: Would two refinements be clearer than the two
    associations from Link to Association and LinkEnd to AssociationEnd since
    they are a different levels of abstraction? Also from Instance to
    Classifier? [Should the relationship from Method to Operation in 2.5.2,
    Figure 2-5 also be a refinement?]
    8. In 2.9.2, Figure 2-16: Should the composition relationship from
    Attribute to Classifier also be modeled?
    9. In 2.9.2, Figure 2-16: The element Instance is abstract according to
    the text and should be stereotyped <<abstract>>.
    10. In 2.9.2, Link: "In the metamodel Link is an instance of an
    Association. It has a set of LinkEnds that matches the set of
    AssociationEnds of the Association." In Figure 2-16 LinkEnd to Link is

    {ordered}

    . Should this be consistent with AssociationEnd to Association?

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 editorial comments (Part 2 Diagram Elements)

  • Key: UML14-1030
  • Legacy Issue Number: 3397
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 2 - Diagram Elements
    1. 3.6.4: Title should be 'Examples' for clarity. Or add a subheading
    to communicate that a list of examples follows.
    2. 3.10.3: same as above
    3. 3.10.7: same as above
    4. 3.12: "Examples of such pairs in UML include: Class-Object,
    Association-Link, Parameter-Value, Operation-Call, and so on." Should
    Operation-Call be Operation-Method? 3.59.5 defines a call as procedural.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Association generalization has notation but no semantics

  • Key: UML14-1029
  • Legacy Issue Number: 3396
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Association generalization has notation but no semantics.

    The notation document says:

    [p 3-80] Generalization may be applied to associations as well as
    classes, although the notation may be messy because of the multiple
    lines. An association can be shown as an association class for the
    purpose of attaching generalization arrows.

    But no semantics is defined for association generalization. That's why
    it's on the UML 2.0 roadmap. The above should be removed for 1.4.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Ordering of attribute values

  • Key: UML14-1028
  • Legacy Issue Number: 3395
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Ordering of attribute values

    Link ends can be ordered, by setting the ordering metaattibute of
    AssociationEnd to "ordered". But attribute values currently cannot be
    ordered. The metaclass StructuralFeature should have an ordering
    metaattribute.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF issue: OCL: Unary operator "-" missing

  • Key: UML14-1023
  • Legacy Issue Number: 3386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The unary prefix operator "-" is missing in the definition of the OCL
    type "Real". It only defines binary "-".

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-1027
  • Legacy Issue Number: 3394
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

    The various places that uninterpreted strings are used in UML should
    support multiple languages. For example, the Expression metaclass has
    an metaattribute for language and another for the uninterpreted string.
    This should be a set of such pairs. Then code generators can target
    multiple languages from the same model.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    duplicate of 3391

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

UML 1.4 RTF Issue: changeability in associations

  • Key: UML14-1026
  • Legacy Issue Number: 3393
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Changeability in associations

    Changeability as currently described does not make sense when applied to
    associations. It is summarized as:

    [p 2-21] When placed on a target end, specifies whether an instance of
    the Association may be modified from the source end. Possibilities
    are:

    What does "modified from the source end" mean?

    [p 2-21] frozen - No links may be added after the creation of the
    source object.

    [p 2-57] the link cannot be modified once it has been initialized
    (frozen).

    No links may be added to what? The source/target objects, the link
    itself? See below for the conflicting answers:

    [p 2-21] addOnly - Links may be added at any time from the source
    object, but once created a link may not be removed from the
    source end.

    [p 2-57] new links of the association may be added but not removed or
    altered (addOnly)

    Again, what does it mean to modify an association from "an end"? It
    doesn't mean the objects at the ends, according to this:

    These constraints do not affect the modifiability of the objects
    themselves that are attached to the links. Moreover, t ) the
    classifier, or (a child of) the classifier itself.

    (The second sentence has too many typos to understand).

    Finally, compare the above to:

    An association-end also specifies whether or not an instance playing
    that role in a connection may be replaced by another instance. It may
    state that no constraints exist (changeable), that the link cannot be
    modified once it has been initialized (frozen), or that new links of
    the association may be added but not removed or altered (addOnly).

    The first sentence implies the link is what is frozen, but that isn't
    consistent with the last sentence.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF issue: OCL: grammar is ambigous

  • Key: UML14-1025
  • Legacy Issue Number: 3389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In OCL versions prior to UML 1.3, type names had to begin with a
    upper-case character. This was changed, and the rules for typeName and
    name are now identical.
    Unfortunately, this introduces an ambiguity into the OCL grammar rule
    pathName.
    pathName := (<typeName> | <name>) ("::" (<typeName> | <name>))*

    This problem could be solved by dropping the distinction between names
    and type name completely. The path name rule could be changed to:
    pathName := <name> ("::" <name>)*

    Now, the problem arises that it is not possible to distinguish between
    property accesses and type literals if they have the same name. For
    example, consider the following UML model:

    • Classes TypeA, typeB, TypeC
    • Association between TypeA and TypeC, association end at TypeC is
      named typeB.
      The expression "typeB" in the context of "TypeA" might either be
      interpreted as a navigation to the association end
      "typeB", and hence result in an object of "TypeC", or as the type
      "typeB".
  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF issue: OCL: navigation context in iterate

  • Key: UML14-1024
  • Legacy Issue Number: 3387
  • Status: closed  
  • Source: Anonymous
  • Summary:

    he term "navigation context" is used to denote the
    start of an OCL navigation expression. The standard navigation context
    is "self", or the iterator name in a subexpression
    that is the argument to collection operations like "forAll".

    The standard navigation context in the argument expression of the
    operation "iterate" is not clearly defined in the OCL specification. It
    might either be the iterator or the accumulator.

    Proposed solution:
    Since none of these alternatives is clearly more intuitive than the
    other, we would favour to demand the explicit qualification of the
    navigation context in iterate's argument expression through either the
    iterator or accumulator name or "self".

    It might be noted that similarly, the default navigation context is not
    clear if the operation "forAll" is used with two or more iterators.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF issue: OCL: Iterator declarators

  • Key: UML14-1021
  • Legacy Issue Number: 3384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The collection operations "iterate", "forAll", "exists",
    "select", "reject", and "collect" can have declarators.
    Declarators should also be allowed for "sortedBy" and "isUnique",
    or, more generally, for all collection operations
    with an OclExpression as parameter. This is not stated clearly stated by
    the specification, though it's propably intended.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Declarators for iterate

  • Key: UML14-1020
  • Legacy Issue Number: 3383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The declarators for the collection operation "iterate" have a different
    format than those for "forAll" and other operations. The specification´s
    grammar allows only the form used with "forAll". The production rule
    "declarator" should be updated as follows:

    declarator :=
    ( name ("," name)* (":" simpleTypeSpecifier)? "|" ) |
    ( name ":" simpleTypeSpecifier ";" name simpleTypeSpecifier "="
    expression "|" )

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF issue: OCL: Precedence of relational operators

  • Key: UML14-1022
  • Legacy Issue Number: 3385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OCL specification defines a precedence of "<", ">", "<=" and
    ">=" over "=" and "<>". This is misleading, because the OCL
    grammar does not allow relational expression with more than one
    relational operator, so that expressions like "a>b = c<d" are illegal
    anyway.

    Proposed Solution: Change the precedence rules to define that "<", ">",
    "<=", ">=", "=" and "<>" have the same precedence.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

In 2.10.4, semantics of Collaboration, the 1st sentence is confusing

  • Key: UML14-1019
  • Legacy Issue Number: 3378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 2.10.4, semantics of Collaboration, the 1st sentence is confusing. It should be "The term instance of a collaboration (also collaboration instance) denotes the set of instances of Classifiers that play roles defined by ClassifierRoles in one specific collaboration specification."

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Page 2-114, 2nd paragraph. It should be collaboration template

  • Key: UML14-1016
  • Legacy Issue Number: 3374
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Page 2-114, 2nd paragraph. It should be collaboration template rather than template collaboration. This distinction is important: a template is not a special form of the templatized model element. (Much like a process description is not a described process or a painted car is not car paint).

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

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

Confusing wording

  • Key: UML14-1015
  • Legacy Issue Number: 3373
  • Status: closed  
  • Source: Anonymous
  • Summary:

    5. In 2.10.2 and 2.10.4, the words "classifier roles", "ClassifierRoles" and "instances of ClassifierRole" are used interchangeably. I suggest to stick to one way of doing it and avoid the others.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

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

In 2.10.5, you give pattern a non-standard definition

  • Key: UML14-1017
  • Legacy Issue Number: 3375
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 2.10.5, you give pattern a non-standard definition. A pattern is not a formal template. For any given design pattern, there may be any number of collaboration templates that represent a category of design structures that will be considered pattern instances by experts. So the relationship between design pattern and collaboration template is 1 to n, similar to the relationship between collaboration specification template and collaboration specification.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Cla

  • Key: UML14-1018
  • Legacy Issue Number: 3377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Class".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Terminology: Collaboration and Collaboration Template

  • Key: UML14-1010
  • Legacy Issue Number: 3367
  • Status: closed  
  • Source: Anonymous
  • Summary:

    suggest to stick with one consistent terminology and avoid imprecise variations and synonyms.

    2.1 Collaboration should be a shortcut for Collaboration Specification. Frequently, however, it also means Collaboration Instance. Here, I suggest to drop the rather awkward "collaboration (diagram) on a specification level" and make it collaboration specification, etc.

    2.2 IMO, it should be collaboration template rather than template collaboration or parameterized collaboration. First of all, a template collaboration is a collaboration, not a template, so this is confusing. Also, should UML 2.0 solve the template problem in ModelElement, it will be the natural thing anyway.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

use of the phrase "In the metamodel..." is unclear

  • Key: UML14-1014
  • Legacy Issue Number: 3372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4. In 2.10.2, the use of the phrase "In the metamodel..." is unclear to me. (It typically starts the second paragraph of a concept definition. Using ClassifierRole as the example, it should be "In a model, an (instance of) ClassifierRole specifies".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

why is AssociationRole is a subtype of Association?

  • Key: UML14-1013
  • Legacy Issue Number: 3371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3. It is unclear to me, why AssociationRole is a subtype of Association, and, similarly, why AssociationEndRole is a subtype of AssociationEnd. The resulting recursive relationship suggests that AssociationRoles can serve as the base for further AssociationRoles, the meaning of which is unclear to me. (Some people suggest to have roles of roles, but I think this confuses concepts.)

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

  • Key: UML14-1012
  • Legacy Issue Number: 3370
  • Status: closed  
  • Source: Anonymous
  • Summary:

    2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

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

Focus is on 2.10 Collaborations

  • Key: UML14-1011
  • Legacy Issue Number: 3369
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. I suggest to consistently use "collaboration specification" and "collaboration instance" rather than the awkward "collaboration diagram on an instance or specification level". The use of "collaboration" should probably be discouraged. If it cannot be avoided, it should default to "collaboration specification".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Design patterns and collaboration templates.

  • Key: UML14-1009
  • Legacy Issue Number: 3366
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current UML definition of design pattern is oversimplifying the situation. The relationship between a design pattern and collaboration template is 1 to n. For any given design pattern, you can find any number of templates as formal abstract specifications of specific collaboration specifications.

    The structure diagram in the GOF book illustrates one common abstract form of the design pattern, but certainly not the only one. Other variants, typically more complex ones, are hidden in the implementation section. The reason for this: in the opinion of its fathers, design patterns can not be formalized.

    The best way to escape the debate of whether to formalize or not is to distinguish between a non-formalizable pattern and formalizable templates. This is also how people do it in practice, if you take a look at the many different abstract descriptions (= templates) of, say, the Observer pattern.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

"Unused" data types

  • Key: UML14-1008
  • Legacy Issue Number: 3325
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    During a discussion of "physical" metamodel (i.e., the MOF-compliant
    metamodel) issues, the following data types defined in the logical
    metamodel Data Types package were identified as unused anywhere else:

    o MessageDirectionKind
    o Time
    o Mapping
    o TypeExpression

    This note responds to an action to search the UML Specification document
    to make sure this is actually true before we consider removing them from
    the logical model. I performed this search by doing using the Acrobat
    "Find" command on the PDF file for the UML Specification, which also
    searches the diagrams.

    o MessageDirectionKind: This data type is actually described in the
    semantics as "no longer used in UML." And, indeed, it appears no where
    in the document outside of the Data Types section, except for the index
    and the parts of the IDL and the physical metamodel generated from the
    Data Types package.

    o Time: This data type is only referenced in the logical metamodel in
    the text of the definition of a TimeExpression: "In the metamodel
    TimeExpression defines a statement which will evaluate to an instance of
    Time when it is evaluated." Thus, this type is not really necessary for
    defining the metamodel, since TimeExpression is not further specified
    (this will probably have to be dealt with as part of the action
    semantics work.) In the IDL, the Time data type is implemented as
    "UmlTime", which is a typedef of float. It appears as Time in the
    physical metamodel.

    o Mapping: This data type is only reference in the logical metamodel in
    the text of the definition of a MappingExpression: "An expression that
    evaluates to a mapping." As with Time, this type is not really necessary
    for defining the metamodel, since the form of its "body" is not further
    specified. It is implemented as a string in the IDL, but has no body
    attribute in the physical metamodel.

    o TypeExpression: This data type appears nowhere else in the Semantics
    chapter than the Data Types section (except for the index). However, in
    Notation Guide states:

    "The type of an attribute is a TypeExpression. It may resolve to a class
    name or it may be complex, such as array[String] of Point. In any case,
    the details of the attribute type expressions are not specified by UML.
    They depend on the expression syntax supported by the particular
    specification or programming language being used."

    Unfortunately, the abstract syntax requires that the type of an
    attribute (or any structural feature) by a classifier (see Section
    2.5.2). There is thus no way to map the notation for an attribute,
    unless the type expression happens to be the name of a classifier. The
    use of a general type expression is desirable, so this should be
    corrected.

    (One possible approach, which would preserve the definition of an
    attribute type as a classifier, would be to make TypeExpression a child
    of Classifier as well as Expression. This could also be useful on
    instance diagrams, since it would allow one to show instances of
    implementation-specific type expressions.)

  • Reported: UML 1.2 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Notation for Namespace ownership

  • Key: UML14-1007
  • Legacy Issue Number: 3316
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    The contents of a package (i.e. the ownedElements of the Namespace of
    the the package) can be shown in two different ways: either enclosed by
    the package symbol or attached with the encircled plus sign (figure 3-6
    in the Notation Guide).

    Even though classes are also namespaces, then the same options do not
    apply for them. In fact there is no notation for this at all. It is
    possible to have class boxes enclosed by a class box, but it has another
    mapping than notation elements being enclosed graphically by a package
    symbol: according to 3.47.5 of the Notation Guide "A class box with
    contained class boxes maps into a set of composition associations;".

    One may argue that packages are different from classes, but subsystems
    come close to objects. A Subsystem (in its capacity of being a Package)
    have the two options of showing the contents, i.e. it is possible to
    have class boxes within the Subsystem symbol. The meaning of this should
    be (according to the text on Package) that the classes are defined
    within the Subsystem. However, the Semantics of Subsystem says that "the
    semantics of an instantiable susbsystem is similar to the semantics of a
    composite class", which means that the enclosed class boxes should be
    interpreted in the same way as for class boxes enclosed by a class
    boxes.

    The enhancement of this should be that notation for namespace
    "containment" (ownedElement) and object containment (composition) should
    be clarified and made similar for similar concepts.

  • Reported: UML 1.2 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Typo in state exit

  • Key: UML14-1006
  • Legacy Issue Number: 3297
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    This should refer to "exit" not entry:

    [p 134] An optional action that is executed whenever this state
    is exited regardless of which transition was taken out of the
    state. If defined, entry actions are always executed to
    completion only after all internal activities and transition
    actions have completed execution.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Misleading description of feature inheritance on roles.

  • Key: UML14-1005
  • Legacy Issue Number: 3296
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 109, semantics] the former roles may possibly be
    specialized with new features (as classifier roles are also
    generalizable elements).

    The parenthetical remark is misleading. Classifier roles are
    not allowed to have features of their own (see OCL on
    ClassifierRole). They only have links to features, ie,
    instances of the meta-association between ClassifierRole and
    Feature. These links don't automatically inherit to children
    of a ClassifierRole, because inheritance only applies to actual
    features of the role, which it isn't allowed to have. So the
    fact that classifier roles are generalizable elements doesn't
    achieve the inheritance of the links to features. That is a
    behavior introduced by role specialization.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Incorrect example of constraining elements in collaborations.

  • Key: UML14-1001
  • Legacy Issue Number: 3292
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 3-56, p 117 of the collaboration notation, it intended to
    give an example of constraining elements, but it shows
    generalization relationships between roles instead. I thought
    the constraining elements would refer to the base classifiers and
    associations, not the roles. Using generalization links between
    roles has a different semantics than between the base classifiers
    (see Semantics of Collaboration 2, above).

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Messages do not have signatures

  • Key: UML14-1004
  • Legacy Issue Number: 3295
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 126, notation] A signature is a string that indicates the
    name, the arguments, and the return value of an Operation, a
    Message, or a Signal.

    Messages don't have signatures. "Message" can be dropped from
    the above sentence.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Guard condition in collaborations poorly named.

  • Key: UML14-1003
  • Legacy Issue Number: 3294
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 125, notation] predecessor guard-condition
    sequence-expression return-value := message-name
    argument-list

    The descriptions after this imply that "predecessor" and "guard
    condition" are the same:

    [p 125, notation] The meaning is that the Message is not
    enabled until all of the communications whose sequence
    numbers appear in the list have occurred (once the
    communication has occurred the guard remains
    satisfied). Therefore, the guard condition represents a
    synchronization of threads.

    It's confusing the have two names for the same thing. I
    thought on first glance that some bracketed notation as in
    state machine were supported at this position in the label, but
    that is in the recurrence part of sequence expressions.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Multi-objects in collaborations

  • Key: UML14-1002
  • Legacy Issue Number: 3293
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 122] A multi-object symbol maps to a set of Objects that
    together conforms to a ClassifierRole with multiplicity
    "many".

    There is no construct for "set" in UML.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Duplicate association end names from Constraint.

  • Key: UML14-1000
  • Legacy Issue Number: 3290
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Constraint meta-type, in the Extension Mechanisms meta-model, has
    two associations with the same association end name on the "opposite"
    ends ("constrainedElement"). Assuming that UML meta-classifiers should
    adhere to the OCL for regular classifiers, then this is ill-formed
    according to OCL 3 of Classifier, p 47:

    [3] No opposite AssociationEnds may have the same name within a Classifier.

    self.oppositeEnds->forAll ( p, q | p.name = q.name implies p = q )

    The same may be true for the Collaboration meta-type (the
    "ownedElement" association end is duplicated), but these two are
    specializations of an association inherited from ModelElement, so
    perhaps that is acceptable.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Create action in collaborations

  • Key: UML14-999
  • Legacy Issue Number: 3289
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Using a role as the target of a create action does not support
    instantiation of children of the role classifier. [p 2-112
    collaboration semantics].

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

  • Key: UML14-998
  • Legacy Issue Number: 3288
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Action composition meta-modelled improperly:

  • Key: UML14-997
  • Legacy Issue Number: 3287
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Action composition meta-modelled improperly: action sequence
    inherits from action. Should be Gamma's composition model with
    action as a sibling of action sequence.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

UML RTF 1.4 Issue: Confusing example of sequence diagram

  • Key: UML14-994
  • Legacy Issue Number: 3282
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 102, notation] An arrow with the arrowhead pointing to an
    object symbol within the frame of the diagram maps into a
    Stimulus dispatched by a CreateAction

    Figure 3-48 [p 100] shows the above for ob1:C1, and ob2:C2, but
    with lifelines below each one sending messages (eg, to ob2:C2
    and ob4:C4 respectively). Does this mean the constructor of
    the object, that is the object creation method, is sending
    messages? These objects aren't notated as active, so they
    can't send messages on their own. It would be good to explain
    this in the above text.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Arrowhead semantics in collaboration unclear

  • Key: UML14-993
  • Legacy Issue Number: 3281
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of the stick arrowhead is described as:

    [p 124, notation] Flat flow of control. Each arrow shows the
    progression to the next step in sequence. Normally all of the
    messages are asynchronous.

    [p 128, notation] stick arrowhead: flat flow of control
    (normally asynchronous).

    What is a "flat flow of control"? How is it different than an
    asynchronous operation or signal? It is ambiguous to say that it
    is "normally" asychronous. How does the user tell whether it is
    or isn't in any particular case?

    It is more confusing when compared to the descriptions for
    half-stick:

    [p 124, notation] Asynchronous flow of control. Used instead of
    the stick arrowhead to explicitly show an asynchronous
    communication between two Objects in a procedural sequence.

    [p 128] half stick arrowhead: an asynchronous operation invocation

    How is a "flat flow of control" different from a "procedural
    sequence"?

    This topics has been very confusing for the agent modelers, who
    are using sequence diagrams to model agent protocols.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4: Description of context role, between state machine and model

  • Key: UML14-992
  • Legacy Issue Number: 3280
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Each state machine is owned by exactly one model element.

    The meta-model shows 0..1.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

UML RTF 1.4 Issue: Flow relationship has the incorrect semantics

  • Key: UML14-996
  • Legacy Issue Number: 3284
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Flow relationship has the incorrect semantics specified for it:

    [p 2-33] It usually connects an activity to or from an object
    flow state, or two object flow states. It can also connect from
    a fork or to a branch.

    Compare:

    <<become>>

    Specifies a Flow relationship, source and target of which
    represent the same instance at different points in time, but
    each with potentially different values, state instance, and
    roles. A Become Dependency from A to B means that instance A
    becomes B with possibly new values, state instance, and roles at
    a different moment in time/space.

    <<copy>

    Specifies a Flow relationship, the source and target of which
    are different instances, but each with the same values, state
    instance, and roles (but a distinct identity). A Copy Dependency
    from A to B means that B is an exact copy of A. Future changes
    in A are not necessarily reflected in B.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: <> keyword/stereotype

  • Key: UML14-995
  • Legacy Issue Number: 3283
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The <<primitive>> keyword/stereotype used in the meta-models of
    the datatype section are not defined. Isn't clear what level the
    datatype meta-model elements are at.

  • Reported: UML 1.2 — Tue, 8 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Deferred event ambiguity

  • Key: UML14-989
  • Legacy Issue Number: 3277
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What happens when a event is defered in one region, but not another? Is
    it left on the queue accessible to both regions, even if it has already
    been consumed by one of the regions? Semantics says deferred events are
    kept if not used in one of the regions. So if one region uses it, it is
    lost, even if it is deferred in the other region. User cannot use event
    in both regions.

    Reference manual says:

    At the time that an object processes an event, it may be in one or more
    concurrent states. Each state receives a separate copy of the event and
    acts on it independently. Transitions in concurrent states fire
    independently. One substate can change without affecting the others,
    except on a fork or join caused by a complex transition (described
    later).[p 443, Reference Manual]

    and refers to an internal queue of events:

    Deferred events. A list of events whose occurrence in the state
    is postponed until a state in which they are not deferred becomes
    active, at which time they occur and may trigger transitions in
    that state as if they had just occurred. The implementation of
    such deferred events would involve an internal queue of
    events. [p 438]

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

UML RTF 1.4 Issue: Join in collaboration

  • Key: UML14-988
  • Legacy Issue Number: 3275
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is possible to model forks in sequence charts using multiple
    asynchronous messages. However, it is not possible to model
    joins, because return messages are considered activitators, and
    multiple activators are not allowed.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

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

UML RTF 1.4 Issue: State constraint on host object

  • Key: UML14-987
  • Legacy Issue Number: 3274
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    States currently do not model the conditions required for an
    object to be in a particular state. A constraint note can be
    linked to a state, but there is no specification of when the
    constraint should be tested. It could be tested when the object
    enters the state, leaves the state, or at any other time. Even if
    this were unambiguous, the consequence of violating the constraint
    is not defined, namely, to transition the machine to a state that
    has a constraint satisfied by the object. This might be modeled
    as a change-event trigger on an exiting transition, but it would
    be redundant with the constraint recorded on the state and with
    triggers on other transitions leaving the state, thereby impairing
    maintainability.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: ownerScope and targetScope

  • Key: UML14-991
  • Legacy Issue Number: 3279
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ownerScope in Feature has the same semantics as targetScope in
    StructureFeature. Aren't they clashing?

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Guard evaluation for choice points.

  • Key: UML14-990
  • Legacy Issue Number: 3278
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Make guard evaluation procedure for choice points more explicit.
    It is not clear from the specification whether all guards are
    required to be evaluated, even after one is found to be true.
    This affects performance/real time issues even if the guards have
    no side-effects.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Notation for call state

  • Key: UML14-986
  • Legacy Issue Number: 3273
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is very common for readers of activity diagrams to look at a
    call state and want to see what type of object is having an
    operation invoked by the action of that state. There is
    currently no adopted notation for this. Notes are too bulky and
    non-standard for this application. Without this notation
    activity diagrams appear non-object-oriented.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

State machine name space

  • Key: UML14-985
  • Legacy Issue Number: 3259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    What is the reason that Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: UML 1.2 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    duplicate 3341

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

Issue Activity Package

  • Key: UML14-984
  • Legacy Issue Number: 3244
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    ISSUE FOR UML, SECTION ActivityGraphs
    -------------------------------------

    Description:
    ------------
    The metaclass ClassifierInState is too limited and can be generalized
    to become more useful. It might show to be completely unneccesary.

    The Definition of ClassifierInSate in UML 1.3 is as follows:

    A classifier-in-state characterizes instances of a given classifier
    that are in a particular state or states. ......
    ClassifierInState is a child of Classifier and may be used in static
    structural models and collaborations (e.g., it can be used to show
    associations that are only relevant when objects of a class are in a
    given state).

    Issue 1:
    This might be a useful concept, but defined in a too limited way.

    Specifying that only instances which fulfil certain condiations
    can be used is meaningful at many places. However, these restrcitions
    are not based only on the state in which the instance is. They can also
    be based on attribute values and link values.
    Therefore the ClassifierInState is too restricted, because the
    condition can only be a (or more) state(s).

    Solution:
    ---------
    Instead I would like to define a metaclass RestrictedClassifier (or
    ConstrainedClassifier) instead of ClassifierInState. The definition should
    be:

    A RestrictedClassifier characterizes instances of a given classifier
    that conform to certain constraints.

    For modeling the restrictions UML already has a perfect metaclass called
    Constraint. A RestrictedClassifier has an association to Constraint with
    multiplicity 1..* (at least one constraint)
    The constraint can either be stated in OCL, which allows one to specify
    generically any restrictions you want (or in any other language).
    OCL allows to check whether an instance is in a certain state by the
    expression "instance.oclInState(statename)", and is therefore able to
    specify at least everything you can specify with ClassifierInState.

    Potentially we could define a stereotype (e.g. <<restriction>>) for this
    kind of Constraint.

  • Reported: UML 1.2 — Mon, 24 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

ISSUE FOR UML, SECTION ActivityGraphs

  • Key: UML14-983
  • Legacy Issue Number: 3243
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Description:
    ------------
    The metaclass ClassifierInState is unneccesary and can be replaced by
    existing metaclasses.

    Discussion
    -----------
    In a number of cases a specific ClassifierInState is not needed. When e.g.
    a ClassifierRole always has certain restrictions, these restrictions can be
    modeled with a Constraint (stereotypes as <<invariant>>) on the
    ClassifierRole.

    The use of ClassifierInState in activity graphs is to show the output or input
    parameter to actions. The same concept can be modeled in a unified way by
    using existing preconditions and postconditions.

    To denote that an object must be in a state after the action can be modeled
    by a
    <<postcondition>> Constraint attached to the action state.
    To denote that an object must be in a state before the action can be
    modeled by a
    <<precondition>> Constraint attached to the action state.
    An action is a piece of behavior and can have pre- and postconditions attached
    to it. using that, the ClassifierInState might turn out to be superfluous.

    Solution
    --------
    Remove ClassifierInState metaclass and replace it by a description how
    existing
    metaclasses can be used to solve the same modeling problem.

  • Reported: UML 1.2 — Thu, 24 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

Shouldn't the UML Package be allowed to own/reference UML 'Instances'?

  • Key: UML14-982
  • Legacy Issue Number: 3241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    We are currently implementing the UML spec into java and have stumbled upon the following problem:
    According to the Model Management package, a UML Package can only own/reference Packages, Classifiers, ..., and Stereotypes.
    My question is, where to put UML 'Instances' (Common Behavior package, p. 2-89) in the model?

    Shouldn't the UML Package (p. 2-173 & 2-175) be allowed to own/reference UML 'Instances'?

  • Reported: UML 1.2 — Thu, 20 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Inheritance of Stereotypes

  • Key: UML14-981
  • Legacy Issue Number: 3210
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The semantics of inheritance (UML 1.3, ad/99-06-8, p. 60-61) does
    not include Stereotypes as being among the things that a subclass inherits
    from its superclasses.

    Recommendation: Explicitly specify that Stereotypes are inherited.

    Discussion: UML specifies that Constraints are inherited. A Stereotype is
    logically a constraint, and can even formally define Constraints that apply
    to stereotyped ModeledElements. Consider a Class A that is stereotyped S, where C is the Constraint that the Stereotype definition specifies for all ModelElements stereotyped S. Now consider Class B that
    inherits A. It stands to reason that the Constraint C applies to Class B.

  • Reported: UML 1.2 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Why is "FinalState" a separate metaclass ?

  • Key: UML14-980
  • Legacy Issue Number: 3201
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines:

    Why is "FinalState" a separate metaclass ?

    It seems that a final state can be modeled as a kind of PseudoState
    (with PseudoStateKind = final).

    FinalState has no attributes of its own, and all associations inherited
    from State must be empty for a final state:

    • A final state cannot have an entry action
    • A final state cannot have an exit action
    • A final state cannot have an doActivity
    • A final state cannot have a deferrableEvent
    • A final state cannot have an internalTransition

    Could anybody explain the reason of existence for a FinalState metaclass ?

  • Reported: UML 1.2 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

OCL: Let-expressions

  • Key: UML14-977
  • Legacy Issue Number: 3148
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    his nice feature provides a useful shortcut for writing complex OCL
    expressions. However, it is under-defined both syntactically and
    semantically.

    Syntactically, why stop at one level, as specified by the grammar
    rule:

    expression := letExpression?
    logicalExpression

    To make the language more orthogonal, that rule should be
    replaced with:

    expression := ( letExpression expression )

    logicalExpression

    which, by the way, ensures the correct precedence and evaluation
    order. The generic form of the let expression is:

    let <variable> = <expression-1> in <expression-2>

    what is not so self-evident, is the following: this fancy syntax
    somehow hides the fact that semantically this is equivalent to the
    lambda-expressions known from functional analysis:

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Invalid OCL expression in initial transition

  • Key: UML14-979
  • Legacy Issue Number: 3153
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    OCL expression is duplicated with errors:

    "self.source.kind = #initial" should be
    "self.source.oclAsType(Pseudostate).kind = #initial"
    "self.StateMachine.top" should be "self.stateMachine.top"
    "self.trigger.operation" should be
    "self.trigger.oclAsType(CallEvent).operation"
    "self.StateMachine.context" should be "self.stateMachine.context"

  • Reported: UML 1.2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Samples of invalid typing

  • Key: UML14-978
  • Legacy Issue Number: 3149
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There are some examples of OCL expressions with type errors.
    For example, in section 7.4.4. there is an OCL expression:

    1 + 'motorcycle'

    of which it is said that it is invalid because type Integer does
    not conform to type String. The conclusion is correct, but the reason
    for the expression above being invalid is entirely different.
    The reason for it is that type String does not confirm to type Real!

    Proposed solution:

    Rephrase the text in the OCL specification. And check other examples.
    ____________________________________________________________________________

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: class operation has no 'self'

  • Key: UML14-976
  • Legacy Issue Number: 3147
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There is no 'self' object in preconditions and postconditions
    of class operations. For example the following:

    context X::increaseInstanceCounter()
    post: instanceCounter = instanceCounter@pre+1

    will not work, because "instanceCounter" is only a
    syntactic shortcut for the full form
    "self.instanceCounter", and, as already said, there is no
    valid self in this context.

    We can even allow a little syntactic trick along the lines of OCL
    case-sensitivity: when a class name is on the other end of an
    association, making its 1st letter lowercase actually denotes
    associated instance(s) of this class. Going the other way round, we
    may state that when self is written in a capitalized form Self, it
    actually denotes the context class, not object:

    context X::increaseInstanceCounter()
    post:
    Self.instanceCounter =
    Self.instanceCounter@pre+1

    This point clearly merits a discussion. The good thing is: even if
    the provisions for static class members are included in the OCL
    exactly as suggested above, all existing OCL code will remain
    valid.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

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

OCL: String literals

  • Key: UML14-975
  • Legacy Issue Number: 3146
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    If, as I was told before, they are supposed to be similar to Java
    strings, the correct rule for string constants will be:

    string := "'" (
    (~["'","\\","\n","\r"] )

    ("
    "
    (
    ["n","t","b","r","f","\\","'","\""]
    ["0"-"7"]
    ( ["0"-"7"] ["0"-"7"]?)?
    )
    )
    )*
    "'"

    Allowing octal escapes only in the ASCII range is not really a part
    of syntax ­ it is a part of OCL semantics, and this is where it
    belongs.

    As a matter of fact, even that is not 100% right ­ because it doesn't
    allow for hexadecimal escape sequences ­ and allows to specify
    only ASCII characters (decimal codes 0..255), while in Java strings
    the hexadecimal escapes can be used to specify any UNICODE
    character.

    I am also wondering, why OCL insists that all strings should be
    ASCII strings? Is there a compelling reason for disallowing
    UNICODE strings (and thus having no support for international
    applications)?

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Numeric constants missing

  • Key: UML14-974
  • Legacy Issue Number: 3145
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The OCL chapter of the UML reference insists that not only there
    is a data type Real, but one can also write constants of this type.
    However, the OCL grammar does not allow for floating-point
    constants.

    To correct that, the rule for numbers:

    number := ["0"-"9"] (["0"-"9"])*

    could be rewritten as:

    number := ["0"-"9"] (["0"-"9"])*
    ( "." ["0"-"9"] (["0"-"9"])* )?
    ( ("e" | "E") ( "+" | "-" )? ["0"-"9"] (["0"-"9"])* )?

    to allow all traditional forms of Real constants, both with decimal
    point and with exponent (and both).

    The one mandatory digit after the decimal point is there on purpose,
    to make sure that in an OCL string like

    1..10

    (which is perfectly legal inside the OCL collection literal) the
    leftmost sub-string '1.' will not be incorrectly recognized as a real
    constant. This little trick allows writing lexical parser for the OCL
    that does not need more than one-character look-ahead.

    Proposed resolution:

    Agreed.
    ______________

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Literal collections

  • Key: UML14-973
  • Legacy Issue Number: 3144
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Currently, the syntax for the literal collection allows either a single
    range of values, or a list of individual values:

    literalCollection := collectionKind "

    {" expressionListOrRange? "}

    "

    expressionListOrRange := expression
    ( ( "," expression )+

    ( ".." expression ) )?

    This is too complicated a rule for what could have been
    made much simpler:

    literalCollection := collectionKind "

    {" (collectionItem ("," collectionItem )+)? "}

    "

    collectionItem := expression ( ".." expression )?

    Which would also allow more general types of literal collections,
    like in:

    Set

    { 0..2, 3, 4, 5..15 }

    And is just as easy to parse.

    Proposed resolution:

    This is more generic and should be includes in the OCL grammar.
    grammar is ok.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Enumeration types inconsistent with UML metamodel

  • Key: UML14-972
  • Legacy Issue Number: 3143
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Enumerations are Datatypes in UML and have a name. They can be shown
    with the notation of a class. In the attribute box, the possible values
    of the enumeration are written. In fact these names are class
    constants (class-scopes frozen attribute) for the enumeration type.
    If we use this UML definition in OCL, the logical way to
    refer to them will be as class attributes, for which there is already a
    defined notation in OCL (Classname.attributeName):

    When we have Datatype named Sex with values 'female' or 'male'
    they can be used as follows:

    context Person inv:
    sex = Sex.male

    Also the enumeration type has a name, therefore the "var :
    enum

    { Â…}

    " type declaration in OCL is superfluous. We can use
    the typename instead: "var : EnumTypeName".
    A logical consequence of this is that the special notation for
    enumerations will disappear completely and only the above syntax is allowed.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Enumeration types

  • Key: UML14-971
  • Legacy Issue Number: 3142
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    When an enumeration constant is used, it has to be preceded by the
    hash '#' sign. While this is not strictly necessary, it certainly
    makes parsing easier and, therefore, can stand as it is.

    However, the need for the same hash characters in the definition of
    the enumeration types, like in

    enum

    { #male, #female }

    is what the OCL grammar currently requires ­ and in this context
    the hash characters should probably be abolished, because:

    • Their presence does not give anything significant to user
      because name conflicts can't happen inside the enumeration type
      definition. Everything inside the curly brackets {} is enumeration
      constants.
    • Normally, one can try to copy-paste some text between UML and OCL
      parts of the class model. This is made a bit tricky, because UML and
      OCL use
      different syntax for the enumeration types. It would
      be nice of OCL could adopt the UML syntax.
  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Feature calls on default target

  • Key: UML14-970
  • Legacy Issue Number: 3141
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The rule for non-terminal primaryExpression should be
    changed from

    primaryExpression := literalCollection

    literal
    pathName
    timeExpression? qualifier?
    featureCallParameters?
    "(" expression ")"
    ifExpression

    to

    primaryExpression := literalCollection

    literal
    featureCall
    "(" expression ")"
    ifExpression

    for two reasons:

    • It will become shorter
    • It describes what is going on more carefully ­ since
      what happens is exactly the feature call on the default
      object (self).

    Proposed sulution:

    Needs to be checked in detail to see what the consequences of this
    change are.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Are keywords reserved or not

  • Key: UML14-967
  • Legacy Issue Number: 3138
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Although the OCL specifies a respectable set of keywords (like
    "and", "if", etc.) the OCL reference says nothing about whether
    they are reserved or not. Clearly, a software designer is completely
    free to specify the class with an attribute called "if". Or, more
    probably, "context". Or any other OCL keyword. How, then, to
    parse an OCL constraint like:

    context if : X inv:
    if.then->size()>=else->size()

    (where if is used instead of self to designate the object an
    invariant is applied to, and then and else are its associations).

    Clearly, reserving keywords is a bad idea. The rule, which seems
    to work well (and has been tried in many real programming
    languages over decades) is:

    An identifier is recognized as a keyword if and only if it is
    encountered in a context where this keyword can legally
    appear.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Consistency in grammar description

  • Key: UML14-966
  • Legacy Issue Number: 3137
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Some non-terminals are enclosed in angle brackets <>,
    and others are not. This would not have been a big problem, if not for the
    fact that enclosing non-terminals in angle brackets is a technique from
    the original BNF specification format. So, we should either use it
    consistently for all non-terminals ­ or not use it at all.

    Proposed resolution:

    make the grammar description consistent.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

"Physical" Metamodel References in Diagrams (uml-rtf)

  • Key: UML14-965
  • Legacy Issue Number: 3125
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The UML Specification contains UML diagrams of the "physical" metamodel, but
    the diagrams do not show which association ends have corresponding
    references. Using a UML facility requires knowing exactly where references
    occur, so showing references in diagrams is important.

    Recommendation: Make references explicit in the UML diagrams of the
    "Physical Metamodel". We can do this by showing each reference as an
    attribute with a stereotype of <<reference>>.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

textual syntax cannot deal with identical class names in different package

  • Key: UML14-969
  • Legacy Issue Number: 3140
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    We can imagine packages
    Package1 and Package2, both containing the class X, but we
    are free to use scope resolution to refer to these two different
    classes as Package1::X and Package2::X.

    However, we then should also be able to specify constraints on
    these classes. To do so, the context definition should allow the
    fully scoped class name to be used, like in

    context Package1::X inv: Â…

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL: Class context specification grammar incomplete

  • Key: UML14-968
  • Legacy Issue Number: 3139
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The text of the OCL specification says, that both following forms
    are allowed:

    context Company
    inv : self.numberOfEmployees > 50

    and

    context c : Company
    inv : c.numberOfEmployees > 50

    However, the OCL grammar does not allow the 2nd form.
    To allow the 2nd form, the rule

    classifierContext := <typeName>

    Should be changed to

    classifierContext := ( name ":" )?
    <typeName>

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

"Physical" Metamodel References (uml-rtf)

  • Key: UML14-964
  • Legacy Issue Number: 3124
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    UML's "physical" metamodels need to be more careful about which association
    ends have corresponding references. In places where an association end can
    relate one element to another element imported from another model, it is
    generally best to not have a reference on the inverse end. Note that
    "reference" is a MOF concept. The lack of a reference does not affect
    whether an association end is navigable. It does affect whether a link can
    be in a different MOF package extent (this is a MOF constraint). If both
    sides of an association have references, then related objects are forced to
    reside in the same package extent, which prevents the federation of UML
    facilities.

    An important aspect of interoperability comes from federation: UML
    facilities having links to other UML facilities. The overuse of references
    prevents use of such links in places where they should be allowed.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Precise "Physical" Metamodels Missing from Specification (uml-rtf

  • Key: UML14-963
  • Legacy Issue Number: 3122
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    There is no XMI-based XML rendering of the UML metamodels in the UML 1.3
    Specification. The "physical" metamodels must be precisely described using
    the MOF Model document type in order to maximize tool interoperability
    across vendors and to enable extension of the metamodels by others. This
    has been done in MOF 1.3, in the initial CWM submission and in other OMG
    submissions, thereby providing definitive metamodels with complete
    machine-readable clarity.

    Recommendation: Put an XML rendering of UML metamodels in the UML 1.4
    specification based on the MOF Model DTD.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Language Name (uml-rtf)

  • Key: UML14-962
  • Legacy Issue Number: 3121
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In order to maximize tool interoperability, the language names provided in
    UML Expressions should follow a consistent naming pattern. No such pattern
    is given by the UML Specification.

    Recommendation: Add the following simple statement after the predefined
    language names (a list of one) given in the description of Expression. Note
    that the following naming practice has a president. It is recommended in
    the ANSI/ISO C++ standard for language names used for external linkage:

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

OCL Error

  • Key: UML14-961
  • Legacy Issue Number: 3098
  • Status: closed  
  • Source: Anonymous
  • Summary:

    sUnique for Collections is defined as follows:
    >>
    >>collection->isUnique(expr : OclExpression) : Boolean
    >> post: result = collection->collect(expr)->forAll(e1,e2 | e1<>e2)
    >>
    >>Unfortunately, if the collection is not empty, this expression
    >>always evaluates to false. This is due to the fact that in a
    >>forAll over two iterators, both iterate over the full collection.
    >>Therefor, for each element in the collectionen , there is a
    >>step where both itereters point to this element, but at this
    >>point, e1 <> e2 evaluates to false.
    >>
    >>My suggestion for the definition of isUnique would be as follows:
    >>
    >>collection->isUnique(expr : OclExpression) : Boolean
    >> post:
    >> let res = collection->collect(expr) in
    >> result = res->forAll(e $|$ res->count(e) = 1)
    >>
    >>This expression states, that each element in the collection 'res'
    >>appears exactly once, i.e. is unique.

  • Reported: UML 1.2 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Use of interfaces in associations

  • Key: UML14-960
  • Legacy Issue Number: 2921
  • Status: closed  
  • Source: University of Frankfurt ( Thomas Behrens)
  • Summary:

    The issue / problem relates to the use of interfaces in associations, i.e.
    the "type" association in the meta model between AssociationEnd and
    Classifier.

    Besides the use of a syntactical interface specification, I use the
    interfaces as well as the location to provide semantics, using OCL.

    OCL provides a well-defined way to navigate along association ends. Where
    actually interfaces would provide the semantic context for association ends,
    I have to refrain from specifiying those on the interface, but have to defer
    this association to the realizing class.

    As an alternative it is possible to provide getter and setter operations
    providing access to the association ends in the deferred implementation. But
    this presents two other problems:
    a) this public (as no other ones are allowed) operation on the interface
    will need to be realized any realizing class (and I do not always want to
    compromise this information)
    b) the return value of the operation (in case of a multiplicity > 1) will
    not per se have the same OCL "accessibility" as an association end;
    furthermore tools - at this point in time - provide significant better
    control in terms of verification for associations than for operation
    parameters / return values.

  • Reported: UML 1.2 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

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

Generalization should be meta-metamodel element

  • Key: UML14-959
  • Legacy Issue Number: 2850
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML 1.3 Metamodel Semantics

    Generalization should be meta-metamodel element

    It is a generally accepted fact that generalization is a second order
    relation, ie, a relation whose elements (instances) are pairs of
    types (classifiers, or whatever). Associations, by contrast, are
    first order: their elements are tuples of objects (individuals,
    etc.).

    UML is based on a four-layer metamodel structure, including metamodel
    and meta-metamodel layers. Why, then, do Generalization and
    Association appear on the same layer, namely the metamodel? Much more
    troublesome: How can they be specializations of the same
    generalization, namely Relationship? Together with the defined
    implication of generalization: "The more specific element is fully
    consistent with the more general element (it has all of its
    properties, members, and relationships) ..." [UML 1.3, sect. 2.5.2]
    this leads to a paradox, because generalization itself would be
    inherited. The paradox would be avoided, however, if generalization
    were a relation of the meta-metalayer.

  • Reported: UML 1.2 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

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

role concept in UML remains rather vague

  • Key: UML14-958
  • Legacy Issue Number: 2837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Roles play a dual role in UML. On one hand, a role is the name of an association end [UML, § 2.5.2] and thus nothing more than the name of place of a relation. On the other hand, UML has a notion of roles specified in the context of collaborations [UML, 2.10]. This notion conflicts with the first one since a single role of the collaboration may have different role names assigned by the different associations it participates in. In other words, the associations of a collaboration may assign different role names to their ends (and thus, to the classifiers at the ends) than assigned by the collaboration directly, potentially leading to a clash of role names.

    Overall, the specification of the role concept in UML remains rather vague. It seems that classifier roles only indirectly specify the base classifiers whose instances can play the roles: "In fact, since an instance may originate from several classifiers (multiple classification), a classifier role may have several base classifiers." (but where are these specified?) and "However, since the only requirement on conforming instances is that they must have attribute values corresponding to the attributes specified by the classifier role, and must participate in links corresponding to the association roles connected to the classifier role, they may be instances of any classifier meeting this requirement." [UML, 2.10.4]. And finally "Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent"s roles; it is enough that they contain all the required features." This is certainly a very unusual feature in a typed language such as UML.

    So what are roles? It seems that in UML they are not types (or classifiers), but a positive definition (other than the equally vague glossary entry) would seem imperative!

  • Reported: UML 1.2 — Wed, 11 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    resolved

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

OCL issue

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

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

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

    No Data Available

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

Strange GENERAl USE RESTRICTION

  • Key: UML14-956
  • Legacy Issue Number: 2626
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "The owners of the copyright in the UML specification version 1.2 [sic, in
    1.3alpha5] hereby grant you a [...] license [...] to create and distribute
    software which is based upon the UML specifications [...]

    Software developed under the terms of this license must include a complete
    implementation of the current version of this specification [...]"

    This appears to say that any UML-based CASE tool must implement the whole
    of the standard. Since as far as I"m aware no existing tool, including
    Rational Rose, comes even close to doing this, should not the restriction
    be changed? (I do not suggest that it should be enforced!)

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

    fixed in UML 1.3

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

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

  • Key: UML14-955
  • Legacy Issue Number: 2573
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be an error in the third postcondition for String::concat on page 6-31. It says:

    post: result.substring(string.size + 1, string2.size) = string2

    It should read:

    post: result.substring(string.size + 1, string.size + string2.size) = string2

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

    No Data Available

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

The not-equals operator, "<>",

  • Key: UML14-954
  • Legacy Issue Number: 2572
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The not-equals operator, "<>", seems to be listed for Enumerations, but not for Reals (page 6-27), Integers (p 6-29), Booleans (p 6-31) or Strings (p 6-30), even though it seems to be used in many places elsewhere in the specification.

    All the other operators seem to be there (equality, less than, etc.), so I think this one should be as well (although you can simulate it using "not").

    Note that inequality is defined for OclAny, but then so is equality.

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

    No Data Available

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

Divide operator is incorrect

  • Key: UML14-953
  • Legacy Issue Number: 2571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Under the "Real" type on page 6-29, the divide operator is incorrectly
    written as an asterisk instead of a forward slash.

    I am not sure if this is just a typo, computer glitch, or error in translating the document to Acrobat format or something weird like that.

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

    No Data Available

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

pages 6-28 to 6-29 of OCL documentation

  • Key: UML14-952
  • Legacy Issue Number: 2570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: pages 6-28 to 6-29 of OCL documentation

    Trivial point - For consistency, the Real operators +, -, * and / should take a parameter called r2, not r1. This seems to be the convention used elsewhere throughout the document, and makes the point that they are the second real number in the expression.

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

    No Data Available

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

page 6-10 of OCL documentation for 1.3alphaR5

  • Key: UML14-951
  • Legacy Issue Number: 2569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 6-10 of OCL documentation for 1.3alphaR5

    I notice that not equals <>, the pathname operator :: and the @pre operator are not listed in the precedence table, and so I guess, technically, their precedence is undefined.

    You could also put parentheses at the top of the table as well, of course, to make that table more complete and stand-alone. Parentheses would then not need to be described in a sentence following the list.

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

    No Data Available

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

The second postcondition on Integer::div is incorrect

  • Key: UML14-948
  • Legacy Issue Number: 2566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The second postcondition on Integer::div is incorrect. It currently reads:

    i.div( i2 : Integer) : Integer

    The number of times that i2 fits completely within i.

    post: result * i2 <= i
    post: result * (i2 + 1) > i

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

    No Data Available

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

The postcondition seems to be incorrect for sequence::subSequence

  • Key: UML14-950
  • Legacy Issue Number: 2568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The postcondition seems to be incorrect for sequence::subSequence. It currently reads:

    sequence->subSequence(lower : Integer, upper : Integer) : Sequence(T)

    The sub-sequence of sequence starting at element number lower, up to and including element number upper.

    post: if sequence->size < upper then
    result = Undefined
    else
    result->size = upper - lower + 1 and
    Sequence

    {lower..upper}

    ->forAll( index |
    result->at(index - lower + 1) =
    sequence->at(lower + index - 1))
    endif

    The indexing is incorrect.

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

    No Data Available

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

The postcondition on set::collect seems to be incorrect

  • Key: UML14-949
  • Legacy Issue Number: 2567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The postcondition on set::collect seems to be incorrect. It currently reads:

    set->collect(expression : OclExpression) : Bag(expression.oclType)

    The Bag of elements that results from applying expr to every member of set.

    post: result = set->iterate(elem; acc : Bag(T) = Bag{} | acc->including(expr) )

    The type of acc is wrong, and it should read:

    post: result = set->iterate(elem; acc : Bag(expression.oclType) = Bag{} | acc->including(expr) )

    Note that the same goes for Bag::collect on page 6-41.

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

    No Data Available

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

(Minor) Activity diagram change recommendation

  • Key: UML14-947
  • Legacy Issue Number: 2546
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I know it"s late in the game, but in my use of activity diagrams for
    modeling algorithms, a minor change has become apparent. Specifically, it
    is possible to have objects "flow" from one activity state to another, but
    it is not possible to show a persistent object which is modified by some
    activity states and used by others. I therefore recommend the following change:

    Activity states be able to depend on objects with stereotypes for <<use>>
    and <<modify>>. In this case, control flow among the activity states must
    be shown since the "data object" does not flow between activity states but
    exists in an enclosing structural context.

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

    No Data Available

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

OCL Standard package

  • Key: UML14-946
  • Legacy Issue Number: 2544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: resolving the issue of extensibility of OCL (like adding an operation to a
    predefined
    OCL type) I have written a new section in the OCL chapter. It describes
    the
    existence of a default package in each UML model, containing the predefined
    OCL
    types. I have chosen to name this package "UML_OCL" (or StandardOCL, ...).

    Typically, the modeler will define its own OCL package (named e.g. MyOCL),
    import
    the standard OCL package (import UML_OCL) and extend the predefined OCL
    types
    to his/her liking. A like approach is taken in Catalysis.

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

    No Data Available

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

There is an association between between Constraint and ModelElement

  • Key: UML14-945
  • Legacy Issue Number: 2510
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The end of the association which is opossite to ModelElement is named as "stereotypeConstraint". I sugesst to rename it to "constraint" or "elementConstraint".
    The name "stereotypeConstraint" is somewhat misleading. issue from Constantine Plotnikov (cap@novosoft.nsc.ru)

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

    No Data Available

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

OCL should allow one constraint to reference another

  • Key: UML14-944
  • Legacy Issue Number: 2305
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL should allow one constraint to reference another (e.g. by name) to avoid
    redundancy in a specifiation and errors related to maintenance of separate constraints
    that should be the same.

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

    declined

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

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

  • Key: UML14-941
  • Legacy Issue Number: 2293
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Summary: The action state symbol and the state symbol differ only in the convexity of their vertical sides. Therefore, it is difficult to distinguish between them, if the diagram is drawn by hand. The symbols have different semantics and both of them can appear in a single diagram (activity diagram). Therefore, it is necessary to clearly distinguish between the symbol for the state and the symbol for the action state.

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

    Previously considered for 1.4 and closed w.o. change

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

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

  • Key: UML14-940
  • Legacy Issue Number: 2292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the current version of UML, use cases must not have associations to other use cases specifying the same entity. Use cases can exchange messages only with actors and not with each-other. UML use cases are always initiated by a signal from the actor.

    However, there are use cases that are initiated by a system if a specific condition is met. Example: in the well-known ATM machine example the use case "dispense cash" is initiated by the system, if the customer request was evaluated as valid. The use case "dispense cash" is not initiated by the (user) actor. In other words, the use case "dispense cash" receives a message or signal from the other use case specifying the same system. Therefore, the association between use cases must exist.

    Solution: Allow associations between use cases specifying the same entity.

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

    rejected

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

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

  • Key: UML14-943
  • Legacy Issue Number: 2295
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML has a symbol for multiobject. However, UML does not have any specific symbol for multiple instances of a component, node, subsystem, interface, actor, use case and collaboration. Adding these symbols to UML will maintain symmetry and therefore, simplicity of the notation.

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

    declined

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

Dependencies (and other relationships) with role ends

  • Key: UML14-942
  • Legacy Issue Number: 2294
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dependency relationship in UML does not have role ends, similar to the association ends that associations have. Therefore, it is not possible to specify, for example, that:

    1. an entity depends on an ordered set of other entities.
    2. an entity depends on a specified number of instances of other entities
    3. the roles of the entities that participate in the dependency. Dependency imply the entity roles "client" and "supplier". However, I often came across situations where I needed to specify more concrete roles than "client" and "supplier". In cases I came across, replacing dependencies by associations was not a convenient solution.

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

    No Data Available

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

Add Responsibilities as a new metatype

  • Key: UML14-939
  • Legacy Issue Number: 2284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would again propose that Responsibilities are added as a new metatype.
    After all Relationship is about to be added in Version 1.3 so I would
    suggest respectfully that the easy addition of one metaclass (Responsibility)
    and two metalevel association relationships (from Classifier to
    Responsibility and from Responsibility to Feature) would be highly
    beneficial and very easily changed in the metamodel. Notational support
    is no problem since (as I have discussed with Grady) is just the addition
    of a new box under the class icon.

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

    No Data Available

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

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

  • Key: UML14-935
  • Legacy Issue Number: 2280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On aggregation. The white diamond name should be "shareable"
    not "shared" because it really indicates the ability to be shared not
    the notion that it IS necessarily shared.
    submit: Submit Issue Report

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

    No Data Available

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

Metamodel and semantics for aggregations

  • Key: UML14-934
  • Legacy Issue Number: 2279
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The metamodel and semantics for aggregations is still causing me
    much concern. Primarily, it is stated that black diamond (composition)
    must have linked lifetimes and dependencies between part and whole.
    This means that the parts are NOT separable from the whole. It also states
    that whilst there is only one owner that owner may be changed. This means
    that the parts MUST BE separable from the whole. This is a contradiction.

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

    No Data Available

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

Interface issue

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

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

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

    rejected

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

Only single stereotyping is supported

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

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

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

    No Data Available

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

Use of black diamond in the metamodel

  • Key: UML14-936
  • Legacy Issue Number: 2281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Use of black diamond (even when semantics are pinned down) in the metamodel e.g. Classifier
    as a composition of Feature is not convincing. The ideas of lifetime
    interlinking seems not necessarily to be the case for many of the metamodel
    uses of black diamond. Similarly for Transition as a composition of
    Guards in the STD.

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

    No Data Available

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

Some attributes can be expressed in OCL

  • Key: UML14-933
  • Legacy Issue Number: 2074
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At several places in the UML metamodel there are attributes of type
    "...Expression". Some of these might be specified in OCL. This should be
    stated in the metamodel. The OCL specification should expicitly describe the
    meaning and context of such an OCL expresion.
    Examples are:
    Action: attribute target : ObjectSetExpression
    Argument: attribute value : Expression
    ChangeEvent: attribute changeExpression : BooleanExpression

    Especially the last one should be expressable in OCL, since it is
    a Boolean Expression.

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

    No Data Available

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

Widen the naming characteristics

  • Key: UML14-932
  • Legacy Issue Number: 2073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The OCL prescribes certain characteristics of names of classes,
    attributes, etc. Clas anmes must start with uppercase, attributes
    start with lowercase, etc.
    It would be more flexible if these restrictions could be widened.

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

    No Data Available

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

BooleanExpression written in OCL or some other language?

  • Key: UML14-931
  • Legacy Issue Number: 2071
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the current metamodel, it is not unambiguously defined whether
    a BooleanExpression is written in OCL or in some other language.
    With tool vendors developing OCL tools, it is important to be able
    to state exactly whether an Expression is written in OCL or not.

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

    fixed in UML 1.3

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

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

Generalized change events

  • Key: UML14-930
  • Legacy Issue Number: 2024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The expressive power of change-events is limited. We are writing a
    specification that is much simpler if we can trigger transitions under a
    circumstance like the following:

    "P has just become true and it is not the case that Q has just
    become true"

    There"s no way to say that with a change-event. Instead we have to write a
    somewhat obscure sequence of transitions that defines a program to calculate
    this.

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

    Considered and declined.

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

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

  • Key: UML14-929
  • Legacy Issue Number: 2022
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a number of issues that make OCL hard to formalize. The attached
    document is a draft of a research into formalizing UML/OCL. It contains
    a number of issues on OCL. Instead of making all of these into separate
    issues, the document is attached and all problems described in there are
    hereby submitted as one (rather big) issue. This document will be posted as ad/98-10-01 on the OMG document server

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

    Redundant with issue 2013.

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

Definition of OclAny leads to problems when formalizing OCL

  • Key: UML14-928
  • Legacy Issue Number: 2021
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OclAny is essentially a type of all types. In particular,
    section 5.13 of the OCL specification implies that Set(OclAny)
    is a subtype of OclAny, from which a version of the Russell
    Paradox promptly follows.

    This needs to be clarified/resolved in the specification

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

    Fixed in UML 1.3.

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

Common operations should be added to collection types in OCL

  • Key: UML14-924
  • Legacy Issue Number: 2015
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A number of common operations should be added to the collection
    types in OCL. These are:

    Collection(T) :
    any( <boolean-expression> ) : T
    returns any element which satisfies <boolean-expression>
    one( <boolean-expression> ) : Boolean
    returns true if thee is exactly one element that satisfies
    <boolean-expression>
    theOne( <boolean-expression> ) : T
    returns the single element which satisfies <boolean-expression>

    and maybe others as well.

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

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

  • Key: UML14-923
  • Legacy Issue Number: 2014
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no simple way currently in OCL to refer in a postcondition to the
    new instances created
    during the operation. The current solution is:
    Person.allIstances - Person.allInstances@pre
    Since this is commonly used, a simper way to denote this will be
    bened=ficial.
    We propose to add an operation "new" or "created" to OclType, which can ony
    be used
    in postconditions and has the meaning describd above. We can then write:
    Person.new or Person.created

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

    Fixed in UML 1.3.

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

Need well defined way to extend OCL

  • Key: UML14-922
  • Legacy Issue Number: 2013
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Because no predefined set of operations will cover all cases needed in
    practical situations it s important that there is a well-defined way
    to extend OCL.

    It is possible to define all predefined OCL types within one predefined UML
    package
    end define package extension mechanisms to add extensions to OCL.
    The current OCL specification doesn"t disallow that, but it should
    be explained explicitly how this can be done.

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

    Fixed in UML 1.3.

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

Set of allInstances should be referrable by the class name

  • Key: UML14-926
  • Legacy Issue Number: 2017
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ances of a class, as
    in "Person.allInstances". It is quite common in many area"s to use the
    class name for this collection.
    To get the size of the collection of persons we now need to write:
    Person.alllnstances->size"
    With the proposes change we can write:
    Person->size
    which is a shorthand for the use of allInstances.

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

    rejected

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

Add "Let"-like construct to OCL

  • Key: UML14-925
  • Legacy Issue Number: 2016
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently if a sub-expression within an OCL expression is
    used twice or more, you need to spell it out each time. This
    is cumbersone, eror-prone and it also disguises to the reader
    of the constraint that these sub-expressions are in fact identical.

    The proposal is to add a construct to OCL, that allows one
    to define a variable which holds the value of such a sub-expression.

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

    Redundant with issue 1788.

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

Synchronous request

  • Key: UML14-919
  • Legacy Issue Number: 2006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: synchronous request is defined as a request where the client object
    pauses to wait for completion of the request.

    1) My understanding of CORBA is that a request is only synchronous
    with respect to a given thread. Is this true?

    • So, does the sending client truly pause to wait for results?
    • Or is it just a thread of that client that pauses for results?

    Deferred synchronous request (mentioned on p.78) has not been
    defined.

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

    Previously considered for 1.4 and closed w.o. change

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

Notation says swimlanes are packages

  • Key: UML14-921
  • Legacy Issue Number: 2012
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation guide has a couple descriptions of swimlanes as
    packages, even though swimlanes are not mapped to packages.
    References:

    If an object lifeline is not shown, then some object within the
    swimlane package is responsible for the action, but the object
    is not shown. [p 127, section 10.5.2, Notation, or p 130 in UML
    1.2]

    Actions may be organized into swimlanes. Swimlanes are a kind of
    package used to organize responsibility for activities within a
    class. [p 125, section 10.4.2, Notation, or p 128 in UML
    1.2]

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

    Fixed in UML 1.3.

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

ModelElement to Partition multiplicity should be many

  • Key: UML14-920
  • Legacy Issue Number: 2011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Partitions in various activity models may reuse the same model
    element. So the multiplicity of the association from
    ModelElement to Partition should be *.

    Comments:

    Proposal: Change multiplicity of association from ModelElement to Partition
    from 0..1 to * [p 121, Figure 22, Activity Model, Semantics,
    or p134 in UML 1.2].

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

    Fixed in UML 1.3.

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

Asynchronous action

  • Key: UML14-918
  • Legacy Issue Number: 2004
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An asynchronous action is defined as a request where the sending object does not pause to wait for results. Synonym: asynchronous request [OMA].

    1) What results?
    In the OMA v3 (June 13 1995), it is said on p. 78 that
    an asynchronous request has no response (hence no results).
    So, soes "results" means "response", or something else ?

    2) The OMA speaks also of a deferred synchronous request –
    proceed after sending request; claim reply later).
    The synonym used is confusing since the OMA has a concept of
    deferred synchronous request in which the sending object does
    not pause to wait for results (proceed after sending request;
    claim reply later).

    3) In fact, my understanding is that the sending object does not
    even pause to wait for the receiving object to be notified of
    the request. The definition is silent about this.

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

    Previously considered for 1.4 and closed w.o. change

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

Not instantiable

  • Key: UML14-917
  • Legacy Issue Number: 2001
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There does not appear to be a definition of "instantiable."

    If "not instantiable" means can not have instances in a model, then some
    model elements should be instantiable, which are currently specified to
    be not instantiable.

    If "not instantiable" means can not have instances in a running system,
    but may have instances in a model, then this should be made clear.

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

    No Data Available

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

UML RTF Issue: Normative MOF-Compatible version of UML

  • Key: UML14-916
  • Legacy Issue Number: 1999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML RTF Issue: Normative MOF-Compatible version of UML
    Severity: Critical

    1) The UML RTF must produce a normative version of UML which is MOF-compatible.
    2) This normative representation should be in Rose (or equivalent) and SMIF
    form in the event that a SMIF submission is adopted.
    3) In the event that XMI is adopted as the SMIF technology, the normative XMI
    form of UML is a generated XMI document and DTD.

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

    Fixed in UML 1.3.

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

Core package-backbone diagram

  • Key: UML14-915
  • Legacy Issue Number: 1995
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "Core Package-Backbone" diagram shows, on the Association
    between Classifer and StructuralFeature, that the "feature"
    AssociationEnd is ordered. Ordering is neither wanted nor
    feasible for this end. What ordering would be applied to the
    set of Attributes that given Class or DataType types? The order
    in which they are defined is the only conceivable ordering, which
    doesn"t seem very valuable.

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

    Clarified in UML 1.3.

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

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

MOF does not support association attributes in metamodels.

  • Key: UML14-914
  • Legacy Issue Number: 1992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Severity: Minor
    MOF does not support association attributes in metamodels.
    The following relationships have association attributes:
    1) Namespace contains ModelElement (ElementOwnership), p16
    2) ModelElement presents ViewElement (Presentation), p44
    3) Package contains ModelElement (ElementReference), p129

    Please describe the proposed MOF mapping if the association attributes are to
    be retained in UML.

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

    Redundant with issue 1955.

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

issue: Missing association names

  • Key: UML14-913
  • Legacy Issue Number: 1991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Severity: Minor
    Issue: missing association names

    Most of the associations are missing names, which are useful for model
    interchange.
    Here is the convention being considered in XMI for providing those names.
    1) Identify the names of the classes on each end.
    2) The "first" class is the one with the name that is lexigraphically first.
    3) Concatenate the two class names together, separated by an underscore (_)
    character. First_Second.
    4) Duplicates have a number appended, starting with 2.

    An example association name is Method_Operation (and not Operation_Method).

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

    Clarified in UML 1.3 physical model.

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

Issue: Action does not define attributes

  • Key: UML14-910
  • Legacy Issue Number: 1988
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi3, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: Action does not define attributes
    The textual description of Action on page 68 does not defne all of the
    attributes in the diagram on page 67.

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

    Clarifed in UML 1.3.

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

Issue: Name attribute inheritance

  • Key: UML14-909
  • Legacy Issue Number: 1987
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi2, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: Name attribute inheritance
    Please clarify that the Name attribute is inherited from ModelElement and not
    redefined in these cases.
    1) Parameter on page 27
    2) Feature on page 23
    3) BehavioralFeature on page 20
    4) Association on page 17

    If Name is redefined, the diagrams should include them.

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

    Clarified in UML 1.3 physical model.

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

Issue: abstract class inconsistencies

  • Key: UML14-908
  • Legacy Issue Number: 1986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi1, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: abstract class inconsistencies
    1) Figure 13 on page 67 shows the Action class as concrete. The text on page
    70 says Action is abstract.
    2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70
    says Instance is abstract.

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

    Clarified in UML 1.3 physical model.

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

Figure 2-18 : redundant attributes

  • Key: UML14-907
  • Legacy Issue Number: 1966
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: n figure 2-18 an Action has the attribute isAsynchronous and the specialization of Action, CallAction has the attribute mode:SynchronousKind. SynchronousKind is either: sk_synchronous or sk_asynchronous. This seems redundant.

    Also the isAsynchronous flag is explained nowhere but it is used on page 2-84 as an attribute of Signal although it does not appear to be a member of Signal.

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

    Fixed in UML 1.3.

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

UML Semantics (page 109)

  • Key: UML14-906
  • Legacy Issue Number: 1956
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: One improperly phrased rule in the UML Semantics manual (page
    109):
    >
    > "The set of transitions that will fire is the maximal
    set that
    > satisfies the following conditions..." (italics added)
    >
    > Clearly, this should say a, not the. There may be more than
    one such maximal set.

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

    Clarified in UML 1.3.

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

Association attributes

  • Key: UML14-905
  • Legacy Issue Number: 1955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: association attributes
    The MOF does not support association attributes in metamodels.
    The following relationships have association attributes:
    1) Namespace contains ModelElement (ElementOwnership)
    2) ModelElement presents ViewElement (Presentation) [removed in uml 1.2]
    3) Package contains ModelElement (ElementReference)

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

    Clarified in UML 1.3.

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

missing association names

  • Key: UML14-904
  • Legacy Issue Number: 1954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: missing association names
    1) Very few of the associations have names, a required property of MOF metamodels. Naming metamodel relationships also enhances model interchange.
    2) Many of the role names of associationEnds are missing.
    3) The role name of Operation->Method is missing.
    4) Missing role name: Classifier<-Parameter, p16
    5) Missing role name: Binding->ModelElement, p43
    6) Missing role name: Node->Component, p44
    7) Missing role name: ModelElement<-Component, p44
    8) Missing role name: Enumeration<-EnumerationLiteral, p60
    9) Missing role name: MultiplicityRange->Multiplicity, p60
    10) Missing role name: Parameter->Signal, p66
    11) Missing role name: Action->ActionSequence, p67
    12) Missing role name: Request->Action, p67
    13) Missing role name: Argument->Action, p67
    14) Missing role name: Most of the associations, Fig 14, p67
    15) Missing role name: Most of the associations, Fig 15, p81
    16) Missing role name: Classifier->Instance, p90
    17) Missing role name: Most of the associations, Figs 17 and 18, p98
    18) Missing role name: Most of the associations, Fig 22, p121
    19) Missing role name: ModelElement->Package, p129

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

    Clarified in UML 1.3.

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

Issue: inheritance inconsistencies

  • Key: UML14-903
  • Legacy Issue Number: 1953
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: inheritance inconsistencies
    1) The semantics document shows Component inheriting from Classifier on page 4, however the definition on page 45 indicates that it inherits from Class.
    2) The semantics document shows Node inheriting from Classifier on page 44, however the definition on page 45 indicates that it inherits from Class.
    3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but the description on page 122 indicates that it inherits from SubmachineState.

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

    Inconsistencies corrected in UML 1.3.

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

Diagram missing attributes

  • Key: UML14-902
  • Legacy Issue Number: 1952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: Diagram missing attributes
    1) The attributes of Action on page 68 do not include all of the attributes in the diagram on page 67.
    2) The attributes of BehavioralFeature includes Name in the text on page 20, but is not in the diagram on page 16.
    3) The attributes of Feature includes Name in the text on page 23, but is not in the diagram on page 16.
    4) The attributes of Parameter includes Name in the text on page 27, but is not in the diagram on page 16.

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

    Clarified in UML 1.3.

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

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

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

Associations as parts of a composite.

  • Key: UML14-899
  • Legacy Issue Number: 1943
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation says that associations may be parts of composites:

    The parts of a composition may include classes and
    associations. The meaning of an association in a composition
    is that any tuple of objects connected by a single link must
    all belong to the same container object. [p62, section 5.26.1
    Notation, UML 1.1, or p65, section 3.42.1 in UML 1.2]

    The above meaning of association as part is not recorded in the
    semantics.

    In any case, the definition prevents associations from having
    parts themselves. When an association has parts, some parts must
    be associations that connect to objects outside the containing
    association. See Bock & Odell in JOOP, Vol 11, No 5, September
    1998, also at:

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

    No Data Available

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

Section 5.17 of Notation Guide: No mapping is given

  • Key: UML14-898
  • Legacy Issue Number: 1940
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 5.17 of the Notation Guide, the notation for an object is
    described as allowing the inclusion of particular states that the object
    is in, but no mapping is given. The obvious mapping is to use a
    ClassifierInState construct from activity modeling as a classifier of
    such an Object, but the well-formedness rule for Object on page 76 of
    the Semantics requires that all classifiers of Objects be Classes.
    A ClassifierInState is a kind of Classifier, but NOT a kind of Class, so
    its use is prevented in the metamodel.

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

    No Data Available

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

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

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

States leading to joins in activity models

  • Key: UML14-895
  • Legacy Issue Number: 1890
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics has the following statement regarding states leading
    to joins:

    If the ObjectFlowState leads into a join pseudostate, then the
    ObjectFlowState remains activated until the other predecessors
    of the join have completed [end of first paragraph of semantics of
    ObjectFlowState, p 139, UML Semantics 1.2].

    This behavior applies to all states leading to a join in
    an activity model, because of regions already exist implicitly when
    using joins in activity models.

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

    Clarified in UML 1.3.

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

Activities operate by and on objects

  • Key: UML14-894
  • Legacy Issue Number: 1888
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation document says regarding object flow:

    Activities operate by and on objects. Two kinds of relationships
    can be shown: 1) The kinds of objects that have primary
    responsibility for performing an action and 2) the other objects
    whose values are used or determined by the action. These are
    modeled as messages sent between the object owning the activity
    model and the objects that are input or output by the actions in
    the model. [section 3.80.1, p 130 Notation 1.2]

    Presumably the activity model doesn"t tell the objects being passed

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

    Clarified in UML 1.3

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

ClassifierInState does not satisfy one of its stated usages

  • Key: UML14-893
  • Legacy Issue Number: 1887
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ClassifierInState does not satisfy one of its stated usages, namely
    to be used as input to an action. This would require that it have
    all the attributes and associations of its corresponding classifier.

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

    Witdrawn by submitter.

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

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

  • Key: UML14-892
  • Legacy Issue Number: 1886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rules 3 and 4 for Transitions in state machines should be limited
    to state machines, because these rules are overridden in the first
    rule for PseudoState in activity models. See Rule 3 and 4
    Transitions in State Machines: [p 118, UML 1.2 Semantics], and
    Rule 1 of PseudoState in Activity Models: [p 138 UML 1.2,
    Semantics].

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

    No Data Available

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

UML Semantics, section Common behavior

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

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

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

    Fixed in UML 1.3.

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

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

  • Key: UML14-890
  • Legacy Issue Number: 1789
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently UML fails to support the notion of "conceptual" or
    "specification-only" features, i.e. features introduced only for the
    purposes of defining pre/postconditions and other constraints.

    This is extremely important to anyone doing formal class specifications
    from which we hope to generate code (e.g. us) and should be an easy matter
    to resolve.

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

    Considered and declined.

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

OCL should allow the use of "let" expressions

  • Key: UML14-889
  • Legacy Issue Number: 1781
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL should allow the use of "let" expressions (for the sake of
    readability).

    Note: The lack of a "let" feature is also mentioned in the abstract for
    a paper on OCL at
    http://www.it.brighton.ac.uk/staff/Stuart.Kent/publications/UML98.html
    along with a number of other issues:

    "Specifically, the paper suggests that: the concept of flattening
    collections of collections is unnecessary, state models should be
    connectable to class models, defining object creation should be made more
    convenient, OCL should be based on a 2-valued logic, set subtraction
    should be covered more fully, and a "let" feature should be introduced."

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

    Redundant with issue# 1689.

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

Text on page 2-49 section 2.2

  • Key: UML14-888
  • Legacy Issue Number: 1710
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In figure 2-13 Comment is a specialization of ModelElement. Yet the text on page 2-49 section 2.6.2 says that "Comment is a subclass of ViewElement." Also it mentions it has an association with a set of model elements. Presumably it would have a text attribute to hold the comment as well.

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

    No Data Available

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

Text in Figure 2.13.7.1 ActivityState seems to be incorrect

  • Key: UML14-887
  • Legacy Issue Number: 1709
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Figure 2.1 ActivityState is a specialization of SimpleState yet the text on page 2-135 in section 2.13.7.1 says "ActivityState is a SubmachineState". The text seems correct, ActivityState should be a specialization of SubmachineState.

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

    Redundant with #928.

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

Need to have relative precedence and, or, xor

  • Key: UML14-886
  • Legacy Issue Number: 1695
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: You really need to have some relative precedence among
    and, or, xor and implies to have any hope of usefulness from these
    operators.
    You should also separate out the precedence of = and <> from the other
    comparisons

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

    Fixed in UML 1.3.

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

Need way to approximate comparisons

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

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

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

    Considered and declined.

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

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

pre value of object

  • Key: UML14-884
  • Legacy Issue Number: 1693
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why can"t one ask for the @pre value of a object that has
    been destroyed during execution? Logically there"s no reason to prohibit
    this.

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

    Considered and declined.

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

It"s mistake to automatically flatten collections of collections

  • Key: UML14-883
  • Legacy Issue Number: 1691
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s a mistake to automatically flatten collections of
    collections. This is noncompositional in that Set

    {1,2}

    means something
    different when it"s in one context (another set, say) than it means
    everywhere else.

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

    Fixed in UML 1.3.

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

States of an object not referenceable from OCL expression

  • Key: UML14-880
  • Legacy Issue Number: 1678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The states of an object, as specified in its state machine, are not
    directly referenceablle from within
    an OCL expression. In many cases it is very useful to be able to use them
    in invariants, and especially
    in pre- and postconditions.
    Currently, we can define a so-called state attribue, which enumerates the
    states, or alternatively we can
    define a boolean attribute for each state. This allows one to reference
    states, but this is specific for
    the chosen implementation of states. This is undesireable. Being able to
    directly refer to the abstract
    states from the state machine is much easier, since it allows specifying
    constraints independent of
    the implementation of states.
    Proposal
    Define an extra standard OCL operation on OclAny called "oclIsInState", or
    "oclInState" which takes a state name as
    a parameter, and results in true if the object is within the specified
    state. This solution adds the
    desired functionality without altering the syntax of OCL.

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

    Fixed in UML 1.3.

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

Implicit transitive import between packages

  • Key: UML14-879
  • Legacy Issue Number: 1664
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implicit transitive import between packages is destructive for encapsulation management. "package Users import package TapeRecorder that import package integratedCircuit implies that package Users sees every public components of integratedCircuit". I suggest that imports becomes not transitive, so that import dependencies must be explicitely declared, or deduced from package aggregation.

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

    fixed in UML 1.3

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

Protocol state diagrams issue

  • Key: UML14-878
  • Legacy Issue Number: 1663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML still does not develop the meaning and the semantics of protocol state diagrams. Protocol state diagrams are close to be supported by the UML metamodel, which still requires some smooth evolutions.
    In a protocol state diagram, a transition related to an operation expresses that the operation can be invoked under the origin state and the "guard" condition, and that under these preliminary context, the operation invocation will lead to the destination state, under a certain post-condition.
    A protocol state diagram can be entirely transformed into pre and post conditions for the involved methods.
    There is a need to add post-condition to transitions for protocol state diagram.
    Suggestion : add a new aggregation from transition to "Guard", called post.

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

    Considered and declined.

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

Changes to figure 15 and description of ClassifierRole on page 82

  • Key: UML14-877
  • Legacy Issue Number: 1651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 15 on page 81 shows that a ClassifierRole has a single base Classifier.
    However, an Instance may have multiple Classifiers (see Figure 14 on p. 67).
    Indeed, the Notation Guide gives a notation for showing an Object having
    multiple Classes (on p. 46) and maps this notation to an Object within an
    object or class diagram, but to a ClassifierRole on a collaboration diagram.
    To support this notation, and to be consistant with the ability of Instances
    to have multiple Classifiers, a ClassifierRole should be able to have
    multiple base Classifiers.

    This requires a change to the multiplicity of the appropriate association
    in Figure 15 as well as updates to the ClassifierRole description on p. 82
    and the well-formedness rules for ClassifierRile on p. 84. (Actually, I think
    only the words in the WF rules need to change – the current OCL rules will
    accomodate the change in multiplicity of "base".)

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

    Fixed in UML 1.3.

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

Semantics for dynamic invocation of concurrent activity models are missing

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

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

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

    Fixed in UML 1.3.

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

Collection type within OCL missing

  • Key: UML14-875
  • Legacy Issue Number: 1636
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no collection type within OCL that corresponds to the UML notion
    of an ordered list without duplicates [UML Notation Guide, ad/97-08-05, p.
    53, definition of "ordered"], i.e. an "ordered set".

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

    Considered and declined.

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

Operation asSequence Issue

  • Key: UML14-874
  • Legacy Issue Number: 1635
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The operation asSequence is defined to return
    "A Sequence that contains all the elements from set, in random order."

    This probably should read "arbitrary order" since we are not promising to
    apply a "random number generator."

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

    fixed in UML 1.3

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

No discription of the association between Classifier and Parameter is give

  • Key: UML14-873
  • Legacy Issue Number: 1634
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: No discription of the association between Classifier and Parameter is given.
    The indicates that the association (with the implicit name of parameter)
    is a set. It should also be noted that it is ordered.

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

    Considered and declined.

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

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

  • Key: UML14-872
  • Legacy Issue Number: 1579
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are four stereotypes shown on Dependency on page 43 of V1.1 (Figure 7).
    Trace, Refinement, Binding and Usage
    These are shown as peers but are in fact representative of two very different
    types of partition.
    My proposal is to remove Usage as a subtype of Dependency. We could than add
    a new abstract type Relationship to model runtime relationships, with Associaton
    and Usage as subtypes. There should be no connection between Relationship
    and Dependency.

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

    Redundant with 1227.

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

Reflexive association in section 5.20.2

  • Key: UML14-871
  • Legacy Issue Number: 1515
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.20.1, a "reflexive association" is defined as an association
    from a class to itself. This is consistent with the terminology as
    generally used in the field.

    However, in section 5.20.2, a reflexive association appears to be defined
    as one that has links from an object to to itself.

    This second defintion is not industry standard (including some of the
    amigos work), appears to conflict with 5.20.1 and somewhat misapplied. The contingent existence of an
    object-to-self link should not be changing the characterization of the
    association. A reflexive assocation need not require a reflexive link.

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

    Fixed in UML 1.3

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

The class "Subsystem" inherits from "GeneralizedElement" twice

  • Key: UML14-870
  • Legacy Issue Number: 1510
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The class "Subsystem" inherits from "GeneralizedElement" twice:

    SubSystem->Package->GeneralizableElement
    SubSystem->Classifier->GeneralizableElement

    The only functionality it adds to Package is the ability to add operations at the Subsystem level as indicated by the statement below:

    "In the metamodel Subsystem is a subclass of both Package and Classifier, whose Features are all Operations."

    I would recommend simplification of the class hierarchy by merging "Subsystem" into "Package" and deriving "Package" from "Classifier":

    Package->Classifier->GeneralizableElement

    The attibute "isInstantiable" of Subsystem can be moved up to Package.

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

    Considered and declined.

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

Class "Model" is too prescriptive

  • Key: UML14-869
  • Legacy Issue Number: 1509
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Different Models can be defined for the same modeled system, specifying it from different viewpoints, like a logical model, a design model, a use-case model, etc."

    This statement is too prescriptive in suggesting that the modeled system should be partitioned into a logical model, a use case model, etc. The user may wish to partition the system using some other criteria, for example on functional lines, and may wish to "package" all the views for a particular function or facility within a single package. The partitioning suggested above can be easily obtained by using UML Packages named "Logical Model", "Use-Case Model" etc. Also note that class "Model" adds no attributes or associations to its superclass - it simply suggests a groping concept.

    Hence I recommend complete elimination of class "Model". The modeled system is simply a hierarchy of "Packages".

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

    Clarified in UML 1.3.

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

Clarify how types of attributes and parameters should be instantiated

  • Key: UML14-868
  • Legacy Issue Number: 1508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not very clear how types of attributes and parameters should be instantiated. For example, consider the following C++ methods:

    void Draw(Window win);
    void Draw(Window* win);
    void Draw(Window& win);

    In all three cases the name of the parameter is "win". The types are "Window", "Window*" and "Window&" respectively. How can these types be modeled? In the first case I can imagine creating a link between the parameter "win" and the Classifier "Window". But what about the remaining two cases?

    UML 1.0 represented attribute and parameter types by simple uninterpretted strings. This allowed user to specify any complex language expression for types. I would prefer that this mechanism be reintroduced. The current mechanism may be left in place in case users or tools like to specify tighter bindings to Classifier instances.

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

    Fixed in UML 1.3.

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

Merge "Class" and "Interface" into one class

  • Key: UML14-867
  • Legacy Issue Number: 1507
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Specifying "Interface" and "Class" as seperate metamodel classes has practical ramifications for UML tools. During analysis/design, a developer may start out by specifying a class, but then decide that it should be an interface. The reverse is also possible. This switching, from Class to Interface, or vice versa, would be very easy if "Interface" is merged into "Class" and the two concepts are distiguished by a stereotype called "interface". This recommendation is also supported by the fact that indeed the notation distinguishes the two concepts by a stereotype called "interface".

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

    Withdrawn by submitter.

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

UML 1.1 issue on Associations

  • Key: UML14-866
  • Legacy Issue Number: 1506
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of Navigation with Nary associations is not clear. For example, If we have three Classes C1, C2, C3 linked with a ternary association.
    If this ternary association is navigable to C3 : what does it means?? Does C1 and C2 instances may access to C3 linked instances through this association?
    Then if the ternary association is navigable to C2 and to C3. Is this legal? What does it means? Does C1 instances may access to C2 and C3 instances? Does C2 instances may access to C3 instances and C3 instances may access to C2 instances?
    Some clarification is needed there.
    I imagin that Navigability makes sense in binary association, but do not make much sense with Nary associations.

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

    Clarified in UML 1.3.

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

Extension Point

  • Key: UML14-865
  • Legacy Issue Number: 1406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is the new proposal for the definition of extension points.

    Extension point – a named location in the behavior specified by a
    Classifier. An extension point might either be before or after an
    Activity or an Action in an ActionSequence, or be a State. It is used
    for specifying where additional behavior may be added, e.g. by being
    referenced by an Extends relationship.

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

    Fixed in UML 1.3.

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

Specification for method in a derived class

  • Key: UML14-864
  • Legacy Issue Number: 1402
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is unclear whether a specification for a method in a derived class should be an operation in the base class, or if the operation is redeclared and it is the derived class"s instance of the operation that is the specification.
    The text on p36 ("Each method implements an operation declared in the class or inherited from an ancestor...the same operation may not be
    declared more than once in a full class descriptor") suggests that it is illegal to redeclare the operation in the derived class and we must have the former interpretation. However this is not enforced by the Classifier constraint [1] on page 29. If this is really what is desired, then the constraint should be self.allFeatures... instead of self.feature...

    This interpretation causes operations and methods to behave like C++ rather than Java. An operation has on

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

    Fixed in UML 1.3.

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

State diagrams: action expressions

  • Key: UML14-863
  • Legacy Issue Number: 1400
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there any reason why UML1.1 specifies different syntax for showing an
    action in response to an event, depending on whether the event is internal
    (NG 9.2.2) or external (NG 9.5.2)?

    And in the latter case, what is the point of the caret? For example, 9.5.2
    seems to suggest that we should probably write (yes, I"m hedging, because
    it isn"t completely clear there what can be in an action expression, or
    indeed what the overall syntax of a transition string is intended to be)

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

    Fixed in UML 1.3.

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

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

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

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

  • Key: UML14-856
  • Legacy Issue Number: 1378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 94 I am unconvinced about class roles and association roles (bottom half)
    and this text seems to have been pasted in from elsewhere

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

    Fixed in UML 1.3.

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

Page 82: Add explanation

  • Key: UML14-855
  • Legacy Issue Number: 1377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 82 Why do some arrows have solid heads and yet on the previous page they
    were open both to left and to right? An explanation of these
    notational elements must be added to page 81/2

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

    Fixed in UML 1.3.

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

Page 80: Confusion with headings

  • Key: UML14-854
  • Legacy Issue Number: 1376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 80. I still get confused with the headings here. Interaction diagrams is
    a collective name which includes both sequence diagrams and collaboration
    diagrams. So the heading for section 7 of Sequence diagrams seems wrong
    because it is low level followed by a high level heading of Kinds of
    Interaction Diagrams.

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

    Fixed in UML 1.3.

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

Page 72: Example needs rejigging

  • Key: UML14-852
  • Legacy Issue Number: 1374
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 72 If Class C - Class B relationship is instantiates, then surely
    Class C should be Object C. A consequence of this is that the <<calls>>
    is now wrong because it needs to be between 2 classes. Example needs
    rejigging.

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

    Consdered and declined.

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

Page 71: Distinction between Dependency and Association

  • Key: UML14-851
  • Legacy Issue Number: 1373
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 71 I don"t find a clear distinction between Dependency (especially
    its <<uses>> stereotype) and Association. Since all OO is to do with
    Client-server relationships, these must all be Dependencies thus eliminating
    the need for Association!!?? My answer is that they are equivalent but with a
    different focus, an association describing the static architecture and a uses
    the dynamic (message-passing) topology – see Henderson-Sellers, Feb 1998, JOOP

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

    Considered and declined.

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

Page 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 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 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 52 figure 20

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

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

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

    Clarified.

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

Typos on pages 24, 40, and 50

  • Key: UML14-845
  • Legacy Issue Number: 1367
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 24 line -3 Typo Being should be Begin
    Page 40 Arrowhead wrong <<bind>> is a stereotyped dependency. Open
    arrowhead needed

    Page 50 Section 5.20.2 para 2 l1. Typo Un should be In and para 3 l1
    hasn"t association role now been changed to association end?
    (see p52 in Semantics doc)

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

    Fixed in UML 1.3.

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

Page 58: Add index entry

  • Key: UML14-848
  • Legacy Issue Number: 1370
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 58 I had difficulty in finding Qualifier in the metamodel of
    the Semantics document (it isn"t in the index – suggest adding index entry)

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

    Rebuild index on each release.

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

Page 57: mathematical issue

  • Key: UML14-847
  • Legacy Issue Number: 1369
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 57 Mathematically .. cannot be identical to 0..*. Since * is a "wild
    card" value, then it could be say 1. So the first would be 1..1 and the
    second 0..1 i.e. different

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

    Considered and declined.

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

Page 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 30: Class scope attribute underlined

  • Key: UML14-841
  • Legacy Issue Number: 1363
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 30 Class-scope attributes underlined. I think users will find this totally
    obtuse. For consistency one really should underline object attributes.
    I understand that they are more common but ...
    Users will also find the explanation here arcane and contrived.

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

    Considered and declined.

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

Page 29: Protected member

  • Key: UML14-840
  • Legacy Issue Number: 1362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 29 Protected visibility only has meaning in context of inheritance.
    Fromoutside a protected member is essentially a private (i.e. encapsulated)
    one.

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

    Considered and declined.

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

Page 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 26: rename reponsibilities, rules, modification histories etc.

  • Key: UML14-839
  • Legacy Issue Number: 1361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 26 line -6 responsibilities, rules, modification histories etc.
    These are collectively called traits in OML. A useful way of describing
    them which we recommend to you.

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

    Considered and declined.

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

Page 24 Section 5.4.3 para 1: missing compartments

  • Key: UML14-838
  • Legacy Issue Number: 1360
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 24 Section 5.4.3 para 1 re missing compartments. This will be
    confusing to users when boxes are absent with no obvious clue as to
    which it is that is present. This is much more important for novices;
    experts will cope.

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

    Considered and declined.

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

Page 24: add link to Interface

  • Key: UML14-837
  • Legacy Issue Number: 1358
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 23 notation and page 16 semantics say Interface is subtype of
    Classifier. Yet on page 24 Semantics it is stated that a Classifier
    realizes the Interface. Since both are true, perhaps a link should be
    made somewhere to give the complete picture.

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

    Considered and declined.

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

Page 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

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

Editorials on pages iv, v, 3, and 4

  • Key: UML14-833
  • Legacy Issue Number: 1354
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page iv and v Section 7 and 7.2 and 10 and 10.2 have same names. This is not
    normal practice

    Page 3 line -9 no dangling lines – agreed re final diagram but may be
    needed as interim state

    Page 4 para 2 Two options equivalent. Yes, except for discriminants when
    joining together all paths would be wrong

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

    Fixed in UML 1.3.

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

Typos on page 90, 151 plus errors in page numbering

  • Key: UML14-832
  • Legacy Issue Number: 1351
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 90 line 1 typo Ref to Figure 15 should be to Figure 16 presumably
    Page 151 Typo dependency line 2 will affect should be may affect

    Page 161 Lots of errors on pages numbers e.g. Dependency should be
    22, 31, 43, 44, 141; Mapping 60 etc.

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

    Fixed in UML 1.3.

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

Page 143: "uses" as a stereotype on Generalization

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

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

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

    Fixed in UML 1.3.

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

Page 143: uses is a stereotyped dependency

  • Key: UML14-830
  • Legacy Issue Number: 1349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 143 Uses is a stereotyped Dependency (Notation page 71) and so should
    be added to list in Semantics document here on page 143 and also on page 50

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

    Fixed in UML 1.3.

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

Page 136: Model package relationship

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

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

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

    Considered and declined.

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

Page 98: Transition is an aggregation of guards

  • Key: UML14-828
  • Legacy Issue Number: 1347
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 98 Transition is an aggregation of guards. Surely, the guard
    governs whether a transition takes place, it is not an integral part of
    it. Similarly, I don"t believe that a State is made up of (i.e.
    composite aggregation) Transitions!

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

    Considered and declined.

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

Uses and extends not types of generalization

  • Key: UML14-827
  • Legacy Issue Number: 1346
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 93 Lots will argue, as do I and Rumbaugh in JOOP some years ago, that
    uses and extends are NOT types of generalization. They do not have
    substitutability in the sense of a generalization hierarchy for Classes,
    for instance.

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

    Fixed in UML 1.3

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

Page 93: use case

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

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

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

    Considered and declined.

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

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

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 47: Dependency is a unidirectional, client-server

  • Key: UML14-818
  • Legacy Issue Number: 1337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 47 Dependency is clearly a unidirectional, client-server relationship.
    Usage, as a stereotype of Dependency, similar. But I don"t get the same
    feel for Trace and, to a lesser degree, Refinement. Indeed, trace seems
    to negate some of the properties of Dependency - a bad practice as
    Brachman pointed out many years ago. For example, Trace has no
    directionality yet it inherits unidirectionality from Dependency which it must
    therefore cancel/negate.

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

    Redundant with issue# 1227.

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

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

  • Key: UML14-817
  • Legacy Issue Number: 1336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 45 Dependency lines 2/3 between model elements not instances. Really?
    But A <<uses>>B is a client-server at instance level also, where
    <<uses>> is a stereotyped Dependency. Why is this discrimination between
    class/type versus instance applied here so explicitly. (BTW I have been
    trying to elucidate the connection between Dependency and Association as
    raised in OTUG by Bob Martin and others. My answer is in my JOOP
    column of Feb 98. I have constructed an interesting and progressive metamodel
    for relationships including aggregation-type ones which seems to make overall
    sense).

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

    Clarified

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

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

  • Key: UML14-820
  • Legacy Issue Number: 1339
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Dependency has 4 subtypes (refinement, trace, binding, usage) and
    (page 50 semantics) 10 or so stereotypes. Each of these stereotypes
    can be applied to each of the 4 subtypes. Are all combinations valid?
    If not, some of the stereotypes should be defined at the subclass level, not
    as stereotypes of the superclass, Dependency.

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

    Redundant with #1227

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

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

  • Key: UML14-819
  • Legacy Issue Number: 1338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 We have <<instance>> and on page 71 notation doc <<instantiates>>.
    I understand from Cris Kobryn that this will be fixed and both will be
    changed to <<instantiate>> [comment included here for completeness only]

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

    Fixed in UML 1.3

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

Page 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 38 para 2 line 3, one of its containers is deleted

  • Key: UML14-814
  • Legacy Issue Number: 1333
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 38 para 2 line -3 one of its containers is deleted.
    Bad choice of word (container). Containment is a relationship which is NOT
    related to aggregation. This para discusses aggregation and should not therefore
    discuss containment (see Winston et al., 1987, Odell, 1994,
    Henderson-Sellers, 1997).

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

    Fixed in UML 1.3

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

Page 35 Diagram (02)

  • Key: UML14-813
  • Legacy Issue Number: 1332
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 Diagram. Is a Class really a composite aggregation of model eleemnts.
    I guess the answer is yes since it inherits from Namespace. However, as
    I am challenging the Generalizable Element/Namespace inheritance, this might
    have repercussions here.

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

    Clarified.

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

Page 35 -Diagram

  • Key: UML14-812
  • Legacy Issue Number: 1331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 line beneath diagram A class declares a collection of methods,
    operations and attributes. Since methods implement operations, then this is
    confusing concepts at two different levels which elsewhere are cleanly
    separated into the internal/external dichotomy which objects need to support
    (and which in general in UML is much improved)

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

    Considered and declined.

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

Class to be defined as an intension

  • Key: UML14-811
  • Legacy Issue Number: 1330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20 Class. A class is a description of a set ...
    This is a definition of class as an extension. We also need class to be
    defined as an intension (Odell and de Champeaux also stress this).

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

    Clarified in UML 1.3

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

Aggregation of class?

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

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

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

    Fixed in UML 1.3.

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

Page 40 table 2 Model Element class

  • Key: UML14-815
  • Legacy Issue Number: 1334
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 40 Table 2 Model Element Class. Surely the stereotype of inherits is
    incorrect here. It is not correct according to the Appendix.
    Also <<thread>> for Generalization is not defined – page 143. Is it correct?

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

    Fixed is UML 1.3

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

How to stop an interface realizing a Data Type ?

  • Key: UML14-810
  • Legacy Issue Number: 1329
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20 line -2 "may realize zero or more interfaces". Where is this shown in
    the metamodel? Answer is recursively on page 16. But how to you stop an
    Interface realizing a DataType, for instance?

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

    Considered and declined.

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

Why does GeneralizableElement inherit from Namespace?

  • Key: UML14-809
  • Legacy Issue Number: 1328
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 17 Figure 6 Why does GeneralizableElement inherit from Namespace? This is
    a question to which I really would appreciate an answer. I asked Grady but
    got an unconvincing answer (see General point 2 above). The white triangled
    arrowhead indicates generalization i.e. knowledge representation and/or
    subtyping. I don"t see how a GeneralizableElement is a kind of Namespace.
    I see that a Namespace would include (containment or maybe even aggregation) a
    Generalizable Element but ...

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

    Fixed in UML 1.3.

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

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

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

Interface must also have features

  • Key: UML14-805
  • Legacy Issue Number: 1324
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 If Classifiers have features (e.g. attributes and methods) then an
    Interface must also have features since it is a kind of Classifier. Yet,
    on page 24, it is stated that an Interface has operations only; on page 37
    Notation document it clearly states Interface "lacks attributes". If this is
    done by an OCL constraint, then we have a negation of properties of the
    subtype which Brachman points out to be dangerous.

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

    Considered and declined.

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

Why is Classifier an Aggregate of Features?

  • Key: UML14-804
  • Legacy Issue Number: 1323
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Why is Classifier an Aggregate of Features (black diamond). It also
    needs a name; and is it really invariant? (Or, more broadly, does it have
    the properties of a composite aggregation - but see General Concern 1
    above)

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

    Considered and declined.

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

Collaboration as a Classifier

  • Key: UML14-803
  • Legacy Issue Number: 1309
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears very useful to make Collaboration a subtype of Classifier or
    GeneralizableElement (instead of just Namespace). This would allow
    refinement of Collaborations using the standard UML refinement
    mechanisms.

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

    Fixed in UML 1.3.

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

Interfaces and support classes

  • Key: UML14-802
  • Legacy Issue Number: 1290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: in UML I"m missing a specified way (e.g. a class stereotype) to
    support the paradigm of "interfaces and support classes". I think it
    would be a convienient way to specify the interfaces which are offered
    by a class like methods and properties:

    ------------------------------

    SomeContainer
    <<implementation Class>>

    ------------------------------

    interface IIndexAccess
    interface IEnumerationAccess
    interface ISomewhatOther

    ------------------------------

    property PropA
    property PropB

    ------------------------------

    The other thing annoying for me is the definition of aggregation. My
    understanding of aggregation ist that the aggregating object offers
    the interfaces of the aggregated objects as they where it"s own (for
    the outer view). The definition of UML seems to be only a "containing"
    relationship.

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

    Considered and declined.

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

UML Semantics, p 81, 145

  • Key: UML14-801
  • Legacy Issue Number: 1248
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Semantics introduces AssociationRole and AssociationEndRole wich inherits from the original Association and AssociationEnd (p81). Unfortunately, the xxxRole have a mandatory xxx as a "base" (multiplicity 1). I believe this is a bug, since it forces you to create an explicit association between the Classifiers, even for a

    {global}

    link, etc. Suggested correction: make the base optional (multiplicity 0,1) for AssociationEndRole with constraint base, local, global, self or parameter; make it optional too for related AssociationRole; leave it as is (mandatory) for ClassifierRole. Make it mandatory through OCL constraints for other AssociationEndRoles and AssociationRoles.

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

    Redundant with issue# 1019.

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

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

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

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

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

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

Stereotypes for superclasses do not apply to superclasses

  • Key: UML14-790
  • Legacy Issue Number: 1227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a lot of stereotypes defined for Dependency, but which can
    apply
    only to some subclasses of Dependency. Example: <<call>> or <<becomes>>
    which certainly cannot apply to a Binding.

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

    Fixed in UML 1.3.

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

Inconsistent use of stereotypes, tagged values, and metamodel

  • Key: UML14-789
  • Legacy Issue Number: 1226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The use of stereotypes, tagged values and metamodel subclassing is not
    consistent in the metamodel. For instance, subclassing is used when
    defining
    the states specific to Activity Models, though the subclasses
    (ActivityState, ActionState) have no specific attributes and could have
    been
    stereotypes. The same with the subclasses of Action. Both approaches are
    correct, but since the two mechanisms are not orthogonal, there should
    be
    stated explicitly when to use one and when to use the other.

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

    Considered and declined.

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

Class WFR (01)

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

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

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

    Redundant with issue 864.

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

Modeling of realization/specification

  • Key: UML14-787
  • Legacy Issue Number: 1223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Most of the relationships drawn on UML diagrams are modeled in the
    metamodel as classes (ex: Association, Dependency and Generalization
    with
    their possible subclasses).
    The relationship between a classifier and the classifier(s) that it
    implements is modeled by an (auto)association of Classifier
    (realization/specification, from Semantics, Fig.5 pg. 16), although it
    has
    a representation on UML class diagrams.

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

    Clarified in UML 1.3.

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

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

GeneralizableElement should not inherit from Namespace

  • Key: UML14-786
  • Legacy Issue Number: 1222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: GeneralizableElement inherits from Namespace (Semantics, Fig. 5 pg.
    16).
    This is not right because the property of an element of being
    generalizable
    and the property of being a namespace for other elements owned by it are
    orthogonal

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

    Fixed in UML 1.3.

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

Syntax for Sequence Expressions inconsistently used

  • Key: UML14-785
  • Legacy Issue Number: 1221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions which
    is
    different from the one used in Fig. 40 pg. 97

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

    Fixed in UML 1.3.

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

Threads of control in Collaboration Diagrams

  • Key: UML14-784
  • Legacy Issue Number: 1220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions,
    using
    names to differentiate between threads of control. These names do not
    map
    into anything in the metamodel.

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

    Considered and declined.

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

Control Flow types not modeled

  • Key: UML14-783
  • Legacy Issue Number: 1219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 98 defines at least three kinds of Control Flow Type
    that have no mapping defined. In fact the metamodel does not support
    them,
    and besides that, they are ambiguous. The meaning of "flat flow of
    control"?
    should be explained in the document.

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

    Clarified in UML 1.3.

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

RaiseAction and TimingMark are not defined

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

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

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

    Fixed in UML 1.3.

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

Mapping of concurrent subregions

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

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

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

    Clarified in UML 1.3.

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

"do" action not supported

  • Key: UML14-780
  • Legacy Issue Number: 1216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.2.4 pg. 106,104: "An internal action string with the name
    "do"
    maps into the invocation of a nested state-machine."
    My understanding is that this means that the state containing the "do"
    action is a SubmachineState with a separated State Diagram, drawn
    elsewhere.
    If this is the case, it should be stated more explicitly in the Notation
    document.

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

    Fixed in UML 1.3.

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

Notation for iteration in sequence diagram

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

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

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

    Considered and declined.

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

"derived" not defined

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

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

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

    Fixed in UML 1.3

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

WFR for bound elements missing

  • Key: UML14-775
  • Legacy Issue Number: 1211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.12.3 pg. 41. "Note that a bound element is fully specified
    by
    its template, therefore its content may not be extended [...]". This is
    a
    semantic rule that is important enough to be stated in the Semantics
    document (and not in Notation) and it should be a WFR.
    In fact, the contents of a bound element (definable in terms of its
    template with some replacements) is not defined formally at all.

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

    Redundant with #1016.

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

The meta-type of template parameters

  • Key: UML14-774
  • Legacy Issue Number: 1210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not specified what is the meta-type of the template parameters
    that
    are exemplified in Notation, Fig. 14 pg. 40. T is a Class? k:integer
    maps to
    a Parameter object? And what can be the (meta)types of the actual
    parameters
    that can replace the template parameters. Some Well-Formedness Rules
    would
    be welcome.

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

    Redundant with issue# 1016.

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

Dependency wrongly mapped

  • Key: UML14-773
  • Legacy Issue Number: 1208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.10.4 pg. 38 says that <--- maps to a <<uses>> Dependency. In
    fact
    it should map to a Usage (subclass of Dependency) and not to a <<uses>>
    Dependency, which is a stereotype for relationships between use-cases.

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

    Fixed in UML 1.3

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

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

Package importing transitive

  • Key: UML14-772
  • Legacy Issue Number: 1207
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Package importing is transitive (Semantics/Package pg. 135). But the
    definition of UML uses importing not in a transitive way. For example,
    there
    are defined the following import relationships: AuxiliaryElements --->
    Core,
    Core ---> DataTypes and AuxiliaryElements ---> DataTypes.
    The renamig (aliasing) rule also confilcts with the transitive import:
    a
    module can be imported through multiple paths, therefore the model
    elements
    from a module can be imported repeatedly, possibly under different
    names.

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

    considered and declined

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

"invoked" not defined

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

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

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

    Fixed in UML 1.3.

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

Bad example for LCA, main source, main target

  • Key: UML14-770
  • Legacy Issue Number: 1205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In example 2 pg. 114, according to the definition of LCA, main source,
    main
    target, LCA(t)=s, main source(t)=region 1 of s, main target(t)=region 2
    of
    s. Text says all of them are s.

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

    No Data Available

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

Transition WFR badly written

  • Key: UML14-769
  • Legacy Issue Number: 1204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rules Transition [6] and [7] pg. 105-106 should be rewritten. One of
    the
    problems with them is:

    In rule Transition [6] pg. 105-106, the fact that the originating
    regions
    of a group of transitions entering a fork pseudostate should be
    orthogonal
    is not caught. A configuration like:
    state A with subregions B and C, b1 substate of B and transitions t1
    and t2 both exiting b1 and entering the same join state
    satisfies the constraint, although it is clearly wrong.

    The same problem appears for rule [7] pg. 106, for fork pseudostates.

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

    No Data Available

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

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

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

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

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

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

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

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

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

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

"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

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

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

Set of inheritable features not defined

  • Key: UML14-750
  • Legacy Issue Number: 1184
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Semantics/Inheritance pg. 34 it is stated that "Each kind of
    generalizable element has a set of inheritable features", without saying
    which are those features for each kind of generalizable element. Note
    that
    they are different: for a Package, the ownedElements are inherited,
    while
    for a Classifier they are not. The set of inheritable features should be
    defined for each descendent from GeneralizableElement.

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

    No Data Available

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

Correspondence between operation and method (02)

  • Key: UML14-749
  • Legacy Issue Number: 1183
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation states that a Class(ifier) can have at most one implementation
    for a given Operation. Although this can be inferred from the Semantics
    document, it should be stated explicitly in the Semantics document.

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

    No Data Available

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

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

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

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

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

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

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

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

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

  • Key: UML14-733
  • Legacy Issue Number: 1104
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The EBNF-construction "+" is not explained.
    add to explanation: "+" means one or more time

    A number of brackets have been lost in the definitions for
    typeName, name and number:
    number := ["0"-"9"] ( ["0"-"9"] )*

    there is no way to specify a float literal (3.14)

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

    No Data Available

  • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

No mapping for swimlanes in Sequence Diagram

  • Key: UML14-712
  • Legacy Issue Number: 1047
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 80 NG (Notation for Sequence Diagram) "Objects can be grouped into
    "swimlanes" on a diagram."

    These swimlanes are not mapped and there is nothing in the SG to map them to.

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

    No Data Available

  • 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

Well-formedness rules only expressed in English

  • Key: UML14-705
  • Legacy Issue Number: 1040
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following well-formdness rules in the SG are only expressed in English.
    Whether the OCL was intentionally left out or not, is unclear:

    • p. 27, Association[3]
    • p. 75, Instance[6]
    • p. 104 Guard[1]
    • p. 124 ActivityModel[2]
    • p. 125 PseudoState[2]
  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

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

Well-formedness rules missing

  • Key: UML14-704
  • Legacy Issue Number: 1039
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 11 of the SG it is stated that "* Well-Formedness Rules: The static
    semantics of EACH construct in UML, except for multiplicity and ordering
    constraints, are defined as a set of invariants of an instance of the
    metaclass."

    And

    "The statement "No extra well-formedness rules" means that all current static
    semantics are expressed in the superclasses together with the multiplicity
    and type information expressed in the diagrams."

    Yet, the following model elements don"t have well-formdness rules, but this is
    not explicitly specified. (see corresponding archive file).

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

    Clarified in UML 1.3.

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

  • 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

Stereotypes applied to more than one ModelElement

  • Key: UML14-700
  • Legacy Issue Number: 1035
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 140 SG Several stereotypes apply to more than 1 ModelElement: create,
    destroy, metaclass and powertype.

    This is inconsistent with p. 54, fig. 9: Stereotype has a "baseClass"
    attribute which contains the name of exactly 1 ModelElement.

  • 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

English contradicts OCL in rule for CompositeState

  • Key: UML14-699
  • Legacy Issue Number: 1034
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 104 SG Well-Formedness rule CompositeState[4] states:

    "There have to be at least two composite substates in a concurrent composite
    state"

    (self.isConcurrent) implies
    (self.subState->select (v | v.oclIsKindOf(CompositeState))->size <= 2)

    Clearly "<=" should be ">=".

  • 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

Misleading name Link.linkRole

  • Key: UML14-698
  • Legacy Issue Number: 1033
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Enumeration OperationDirectionKind obsolete

  • Key: UML14-697
  • Legacy Issue Number: 1032
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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 " process"

  • Key: UML14-702
  • Legacy Issue Number: 1037
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Key: UML14-701
  • Legacy Issue Number: 1036
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

ordered missing for Constraint.constrainedStereotype

  • Key: UML14-696
  • Legacy Issue Number: 1031
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 54 SG the association Constraint.constraindStereotype is defined as:

    "An ordered list of stereotypes subject to the constraint".

    The "ordered" property is not in fig. 9.

  • 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 "friend"

  • Key: UML14-695
  • Legacy Issue Number: 1030
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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-694
  • Legacy Issue Number: 1029
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Wrong aggregation kind for templates

  • Key: UML14-693
  • Legacy Issue Number: 1028
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 43 SG In fig. 7, Binding.argument is composite, while
    ModelElement.templateParameter is not. This seems to be an error, as is
    indicated by the text on p. 49:

    "A further consequence is that a template must own a fragment of the model".

    ModelElement.templateParameter should be composite, Binding.argument should
    not be composite.

  • 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

Inconsistent attachment of Activity Diagram

  • Key: UML14-689
  • Legacy Issue Number: 1024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 121 NG "The entire activity diagram is attached (through the model) to a
    class or to the implementation of an operation or a use case."

    • How can an activity diagram be attached to THE IMPLEMENTATION of
      an operation or use case?
    • This attachement is different from the one in the SG, p.124:
      "[1] An ActivityModel specifies the dynamics of a
      Package, or (ii) a Classifier (including UseCase), or (iii) a
      BehavioralFeature."
  • 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

Method visibility

  • Key: UML14-692
  • Legacy Issue Number: 1027
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 SG "The concept of visibility is not relevant for methods".

    Then why is visibility an attribute of Method and is there even a rule on
    p. 32 of the SG that states:

    "[3] The visibility of the Method should be the same as for the realized
    Operations."

  • 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

Feature.owner must be optional

  • Key: UML14-691
  • Legacy Issue Number: 1026
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    Conclusion: Feature.owner should be optional.

  • 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

Extension points of operations not defined

  • Key: UML14-690
  • Legacy Issue Number: 1025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 SG "An operation may have a set of extension points".

    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 clarification: Extension points only apply to use cases.

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

Inconsistent definition of state machine attachment

  • Key: UML14-688
  • Legacy Issue Number: 1023
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 103 NG "A state machine is attached to a class or a method"

    This is more restrictive than the SG, p. 104:

    "A StateMachine is aggregated within either a classifier or a behavioral
    feature".

  • 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 format of signal/event

  • Key: UML14-687
  • Legacy Issue Number: 1022
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 109 NG "A signal or call event can be defined using the following format:
    event-name "(" comma-separated-parameter-list ")"
    A parameter has the format: parameter-name ":" type-expression"

    This is inconsistent with fig 41, p. 104 and fig 43, p. 107 and
    section 9.5.3 which only show the name of the parameter, not
    its type.

  • 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

More arrow types than message kinds

  • Key: UML14-686
  • Legacy Issue Number: 1021
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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

Attachment of message in Sequence Diagram

  • Key: UML14-684
  • Legacy Issue Number: 1019
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 83 NG "unless the correct AssociationRole can be determined from a
    complementary collaboration diagram or other means, the Message must be
    attached to a dummy AssociationRole implied between the two ClassifierRoles
    for lack of complete information."

    This conflicts with fig. 15 on p. 81 of the SG: a Message is NOT connected to
    an AssocationRole.

  • 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 mapping of labels in Sequence Diagram

  • Key: UML14-685
  • Legacy Issue Number: 1020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 83 NG "A timing label placed on the level of an arrow endpoint maps into
    the name of the corresponding Message."

    This contradicts the statement on p. 85 of the NG:

    "The arrow is labeled with the name of the message (operation or signal) and
    its argument values."

  • 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

UML 1.0: "role" should be "end"

  • Key: UML14-682
  • Legacy Issue Number: 1017
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    UML

  • 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:34 GMT

UML 1.0: Template example cannot be representaed in model

  • Key: UML14-681
  • Legacy Issue Number: 1016
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    No Data Available

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

UML 1.0: Unknown model element "Qualifier"

  • Key: UML14-683
  • Legacy Issue Number: 1018
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Inconsistent name of stereotype "import"

  • Key: UML14-680
  • Legacy Issue Number: 1015
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: multiplicity "unspecified" not possible

  • Key: UML14-679
  • Legacy Issue Number: 1014
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered but declined.

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

Inconsistent name space rules

  • Key: UML14-676
  • Legacy Issue Number: 1011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The NG and SG have slightly different name space rules for Packages:

    On p. 23 the NG states:

    "The name of a class has scope within the package in which it is declared and
    the name must be unique (among class names) within its package."

    The "among class names" implies that the name need NOT be unique among other
    names in the Package. This contradicts rule[2] of Package on p. 131 of the
    SG:

    "No referenced element (excluding Association) may have the same name or
    alias as any element owned by the Package or one of its supertypes."

  • 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:34 GMT

UML 1.0: instances

  • Key: UML14-675
  • Legacy Issue Number: 1010
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The NG and the SG are inconsistent on where Instances my be defined:

    On p. 22 the NG states:

    "Note that a "class" diagram may also contain interfaces, packages,
    relationships, and even instances, such as objects and links."

    and:

    "If a diagram is part of a package, then its contents map into elements
    in the same package."

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

    No Data Available

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

UML 1.0: Stereotype "uses" applied to more than one class

  • Key: UML14-678
  • Legacy Issue Number: 1013
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

Inconsistent name for stereotype implementationClass

  • Key: UML14-677
  • Legacy Issue Number: 1012
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Tagged value "location"

  • Key: UML14-673
  • Legacy Issue Number: 1008
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 144 of the SG, the predefined tagged value "location" is specified:
    Applied to Classifier: "Location denotes that the classifier is a part of
    the given component." This seems to be the same as the association
    ModelElement.implementation, although the definition of that association
    is missing (it is in fig. 8, but not in the list of associations of
    ModelElement on p. 46).

    Applied to Component: "Location denotes that the component resides on given
    node." This is almost the same as the definition of the association
    Component.deployment on p. 45: "The set of Nodes the Component is residing on."

    Information should either be represented as an association in the metamodel
    or as a predefined tagged value, but not both.

  • 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:34 GMT

UML 1.0: Inconsistent mapping of interface circles

  • Key: UML14-672
  • Legacy Issue Number: 1007
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Attachment of messages in Collaboration Diagrams

  • Key: UML14-669
  • Legacy Issue Number: 1004
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 98 of the NG:

    "A message flow is shown as a labeled arrow placed near a link. The
    meaning is that the link is used to transport or otherwise implement the
    delivery of the message to the target object."

    However, attachment of a message to an AssociationRole is not possible in
    the model.

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

    Redundant with 1019.

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

UML 1.0: Node/Component Instances not defined

  • Key: UML14-671
  • Legacy Issue Number: 1006
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Merged with #1006.

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

UML 1.0: No notation for ModelElement.implementation etc.

  • Key: UML14-670
  • Legacy Issue Number: 1005
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Inconsistent arrow heads for dependencies

  • Key: UML14-674
  • Legacy Issue Number: 1009
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.o: Qualified things in Collaborations

  • Key: UML14-666
  • Legacy Issue Number: 1001
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Collaborations not well defined

  • Key: UML14-665
  • Legacy Issue Number: 1000
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Collaborations, especially Collaboration Digarams, are not defined very well,
    given the following quotes:

    The SG states on p. 86:
    "A collaboration may be presented at two different levels: specification
    level or instance level. A diagram presenting the collaboration at the
    specification level will show classifier roles and association roles, while
    a diagram at the instance level will present instances and links conforming
    to the roles in the collaboration."

    So, according to the SG, there are TWO kinds of collaboration diagrams: one
    containing ClassifierRoles and one containing Instances.

  • 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:34 GMT

UML 1.0: No notation for ClassifierRole.availableFeature

  • Key: UML14-668
  • Legacy Issue Number: 1003
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • 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:34 GMT

UML 1.0: Collaborations and Association (role)

  • Key: UML14-667
  • Legacy Issue Number: 1002
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 97 the NG defines how to map nested "things" in a collaboration diagram:
    "A nested object symbol (active or not) maps into a Classifierrole that has
    a composition association to the roles corresponding to its contents, as
    described under Composition."

    But, according to the SG on p. 81, fig. 15, a collaboration should contain
    AssociationRoles, not plain Associations.

  • 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:34 GMT

CallEvent: operation label in figure 18 is not present

  • Key: UML14-664
  • Legacy Issue Number: 990
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Signal label in figure 18 is not present

  • Key: UML14-663
  • Legacy Issue Number: 989
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.3

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

Figure 15, AssociationRole class issue

  • Key: UML14-662
  • Legacy Issue Number: 988
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in 1.2.

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

Description of ActionSequence indicates that it is composition of Actions

  • Key: UML14-659
  • Legacy Issue Number: 985
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

ActionSequence class issue

  • Key: UML14-658
  • Legacy Issue Number: 984
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Collaboration package: constrainingElement aggregation misdrawn

  • Key: UML14-661
  • Legacy Issue Number: 987
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in 1.2.

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

Collaborations package--editorial

  • Key: UML14-660
  • Legacy Issue Number: 986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) In the Collaborations package, Figure 15, there is a "

    {or}

    "
    > particle floating near the Collaboration class. It is unclear what it
    > means or to what it applies.

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

    Fixed in 1.2.

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

Reception class has wrong attribute

  • Key: UML14-657
  • Legacy Issue Number: 983
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Figure 12 shows no attributes for exceptions

  • Key: UML14-656
  • Legacy Issue Number: 982
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Behavioral Features called context

  • Key: UML14-655
  • Legacy Issue Number: 981
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Request class is not an abstract class as indicated

  • Key: UML14-654
  • Legacy Issue Number: 980
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Action class is no abstract class as indicated

  • Key: UML14-653
  • Legacy Issue Number: 979
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Description of ViewElement indicates that it is subclass of Element

  • Key: UML14-652
  • Legacy Issue Number: 978
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Inconsistency of UML metamodel

  • Key: UML14-647
  • Legacy Issue Number: 973
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Sun, 8 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 950; mistaken submitter id).

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

Node class shown as subclass of classifier

  • Key: UML14-649
  • Legacy Issue Number: 975
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Node class issue (01)

  • Key: UML14-648
  • Legacy Issue Number: 974
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Redundant (duplicates 850).

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

Comment class shown as subclass of ModelElement class

  • Key: UML14-651
  • Legacy Issue Number: 977
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Description of component shown as subclass of class

  • Key: UML14-650
  • Legacy Issue Number: 976
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

UML Notation Guide, boolean properties

  • Key: UML14-645
  • Legacy Issue Number: 954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: §5.5.1 says that you can show properties betwen braces and that a boolean
    property can be displayed without its value (meaning true).

    1) examples are

    {leaf}

    and

    {abstract}

    , which are isLeaf and isAbstract in
    the metamodel. Since all boolean properties are called isXxxx, I suggest to
    add an explicit rule in §5.5.1 stating that a property isXxxx=true is
    displayed simply as

    {xxxx}

    2) I suggest to add a shortcut for false properties as well. May be
    {§xxxx}, or {xxxx}

    ... some character not too overloaded by UML and
    programming languages anyway (# ~ ! - ...)

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

    considered and declined

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

UML Notation Guide, association ends

  • Key: UML14-644
  • Legacy Issue Number: 953
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Notation Guide

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

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

    Fixed in UML 1.3.

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

Association between Method and Operation

  • Key: UML14-646
  • Legacy Issue Number: 955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 5 (Core Package-backbone) of the UML Semantics suggests that _1
    (one)_ Operation is the specification of * (none-to-many) Methods.

    P25, the text on Method says that "a Method is a declaration of a named
    piece of behavior in a Classifier and realizes one or a set of Operations
    of the Classifier". This suggests (or is it just unclear?) that several
    Operations may be linked (implemented?) by the same method.

    I do not understand this, or what I understand is not consistent.

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

    Clarified in UML 1.3.

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

UML stereotypes

  • Key: UML14-643
  • Legacy Issue Number: 952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Semantics:
    I think that the attribute Stereotype::baseClass could (should, IMhO) be
    replaced by a second association between Stereotype and ModelElement, with

    {targetScope=Classifier}

    on the ModelElement end (presentation: role name
    underlined).
    This would represent better the two links side by side: the "meta" link and
    its instances.

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

    Considered and declined.

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

UML potential inconsistency about stereotypes

  • Key: UML14-642
  • Legacy Issue Number: 951
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Stereotype]stereotype*---*extendedElement[ModelElement]

    so: many-to-many.

    The text, in §ModelElement(as extended)/Associations/stereotype (p54 in my
    copy) says "Designates at most one stereotype..."

    so: one-to-many.

    Unless I misunderstood something, this is not consistent. Otherwise, a
    better explanation is needed.

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

    Fixed in UML 1.2.

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

Inconsistency of UML metamodel

  • Key: UML14-641
  • Legacy Issue Number: 950
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Sun, 8 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

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

Parameters/Attributes need Specification Classifiers

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

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

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

    considered and declined

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

Predefined LinkEnd constraints issue

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

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

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

    fixed in UML 1.3

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

Predefined LinkEnd constraints shown as stereotypes in Notation Guide

  • Key: UML14-638
  • Legacy Issue Number: 936
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.3

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

diagram fragment at start of Model section on page 136

  • Key: UML14-636
  • Legacy Issue Number: 930
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

No notation defined in the Notation Guide

  • Key: UML14-635
  • Legacy Issue Number: 929
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    UML 1.3: Notation defined for SubactivityState.

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

ActivityState in Figure 22

  • Key: UML14-634
  • Legacy Issue Number: 928
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    UML 1.3: Renamed ActivityState to SubactivityState and updated relevant semantics.

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

well-formedness rules for BehavioralFeature

  • Key: UML14-633
  • Legacy Issue Number: 927
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Figure 8 (Semantics, p. 44)

  • Key: UML14-637
  • Legacy Issue Number: 931
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Figure 5 Semantics document (p. 16)

  • Key: UML14-630
  • Legacy Issue Number: 924
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Second para, Section 5.16.1: conflict with statement on p 141

  • Key: UML14-629
  • Legacy Issue Number: 923
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Well-formedness rulw [2] for Class (Semantics, p. 27-28)

  • Key: UML14-632
  • Legacy Issue Number: 926
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Well-formedness rule [4] for Association

  • Key: UML14-631
  • Legacy Issue Number: 925
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Section 5.16.1--editorial

  • Key: UML14-628
  • Legacy Issue Number: 922
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 53 UML semantics: base class of TaggedValue not shown

  • Key: UML14-627
  • Legacy Issue Number: 883
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3: TaggedValue a subclass of ModelElement.

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

Missing role descriptions

  • Key: UML14-624
  • Legacy Issue Number: 880
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 20 of UML 1.1 Semantics, BehavioralFeature describes a "parameters"
    association but figure 5 on pg. 16 shows the same association as "parameter".

    On pg. 21 of UML 1.1 Semantics, Classifier does not describe a "associationEnd"
    association but figure 6 on pg. 17 does show "associationEnd".

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

    Fixed in UML 1.3.

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

ModelElement Associations (02)

  • Key: UML14-623
  • Legacy Issue Number: 879
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3: Renamed role and corrected description.

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

Page 44 UML 1.1 Semantics, figure 8: no base class for ViewElement

  • Key: UML14-626
  • Legacy Issue Number: 882
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3: Presentation Element is a subclass of Element,

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

Page 44 UML 1.1 Semantics, figure 8: no component role name

  • Key: UML14-625
  • Legacy Issue Number: 881
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Redundant (duplicates 850).

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

ModelElement Associations (01)

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

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

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

    Considered and declined.

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

ElementOwnership subclass of ModelElement?

  • Key: UML14-621
  • Legacy Issue Number: 875
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Package dependencies (08)

  • Key: UML14-619
  • Legacy Issue Number: 873
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Package dependencies (07)

  • Key: UML14-618
  • Legacy Issue Number: 872
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Package dependencies (09)

  • Key: UML14-620
  • Legacy Issue Number: 874
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Package dependencies (06)

  • Key: UML14-617
  • Legacy Issue Number: 871
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Package dependencies (05)

  • Key: UML14-616
  • Legacy Issue Number: 869
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Package dependencies (01)

  • Key: UML14-613
  • Legacy Issue Number: 866
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages

    A dependency from Foundation to Behavioral Elements is not shown
    although this is implied by the diagram on pg.. 121.

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

    considered and declined

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

UML 1.1 bug

  • Key: UML14-612
  • Legacy Issue Number: 864
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Sun, 4 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

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

Package dependencies (03)

  • Key: UML14-615
  • Legacy Issue Number: 868
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages

    A dependency from Data Types to Core is not shown although this
    is implied by the diagram on pg.. 60.

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

    considered and declined

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

Package dependencies (02)

  • Key: UML14-614
  • Legacy Issue Number: 867
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Page 10 UML 1.1 Semantics, duplicate entries listed

  • Key: UML14-609
  • Legacy Issue Number: 860
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Page 98 of UML 1.1 Semantics, figure 18 (02)

  • Key: UML14-608
  • Legacy Issue Number: 859
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

UML 1.1 Semantics: Partition (pp.121 123)

  • Key: UML14-611
  • Legacy Issue Number: 862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Partitioning according to various criteria is not possible.

  • Reported: UML 1.1 — Mon, 5 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

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

Page 102 of UML 1.1, StateVertex class misses description

  • Key: UML14-610
  • Legacy Issue Number: 861
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3.

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

Page 98 of UML 1.1 Semantics, figure 18

  • Key: UML14-607
  • Legacy Issue Number: 858
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 98 of UML 1.1 Semantics, figure 17 (04)

  • Key: UML14-606
  • Legacy Issue Number: 857
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 98 of UML 1.1 Semantics, figure 17 (03)

  • Key: UML14-605
  • Legacy Issue Number: 856
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 98 of UML 1.1 Semantics, figure 17 (02)

  • Key: UML14-604
  • Legacy Issue Number: 855
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 98 of UML 1.1 Semantics, figure 17 (01)

  • Key: UML14-603
  • Legacy Issue Number: 854
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 43 of UML Semantics, figure 7

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

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

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

    Fixed in UML 1.2.

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

Page 43 UML 1.1 Semantics, figure 7 --editorial

  • Key: UML14-597
  • Legacy Issue Number: 848
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 46 of UML 1.1 Semantics, description of associations for ModelElement

  • Key: UML14-600
  • Legacy Issue Number: 851
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3: Added description of ModelElement::template association.

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

Page 44 UML 1.1 Semantics, figure 8

  • Key: UML14-599
  • Legacy Issue Number: 850
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 47 of UML 1.1 Semantics, description of ViewElement

  • Key: UML14-602
  • Legacy Issue Number: 853
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3: Added PresentationElement:subject relationship.

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

Page 47 of UML 1.1 Semantics, description of Refinement

  • Key: UML14-601
  • Legacy Issue Number: 852
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 16 of UML Semantics, figure 5

  • Key: UML14-596
  • Legacy Issue Number: 847
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3. Removed rolename "feature" on Classifier--StructuralFeature and removed ordering.

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

Page 62---editorial

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

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

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

    fixed in UML 1.2

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

Page 62 "PseudostateKind"--editorial

  • Key: UML14-594
  • Legacy Issue Number: 845
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Redundant (duplicates 820).

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

Page 61: CallConcurrencyKind and EventOriginKind not defined

  • Key: UML14-592
  • Legacy Issue Number: 843
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Redundant (duplicates 818 & 819).

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

Page 61 "EnumerationLiteral"--editorial

  • Key: UML14-593
  • Legacy Issue Number: 844
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 50 table 3: Dependency Model elements (02)

  • Key: UML14-587
  • Legacy Issue Number: 838
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.2

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

Page 50 table 3: Dependency model element

  • Key: UML14-586
  • Legacy Issue Number: 837
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.2

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

Page 60 figure 10: Data types

  • Key: UML14-591
  • Legacy Issue Number: 842
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 60, figure 10: Data Types

    A "Float" class is not shown although it is discussed in the description
    of Geometry on pg. 61. Is Float a data type?

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

    fixed in UML 1.2

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

Page 9 figure 2: foundation packages

  • Key: UML14-590
  • Legacy Issue Number: 841
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    clarified in UML 1.3

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

Page 137 table 6: Model management - Standard Elements

  • Key: UML14-589
  • Legacy Issue Number: 840
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 137, table 6: Model Management - Standard Elements

    Package model element does not show <<toplevelPackage>>
    stereotype but this is shown in A.1 for Package.

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

    fixed in UML 1.2

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

Page 50 table 3: Component model element

  • Key: UML14-588
  • Legacy Issue Number: 839
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.2

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

Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele

  • Key: UML14-585
  • Legacy Issue Number: 836
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 50, table 3: Auxiliary Elements - Standard Elements

    Component model element shows <<friend>> stereotype
    but <<friend>> is not shown in A.1 for Component.

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

    fixed in UML 1.2

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

Page 40 table2: Generalization model element

  • Key: UML14-584
  • Legacy Issue Number: 834
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

page 40 table2: Classifier model element

  • Key: UML14-583
  • Legacy Issue Number: 833
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 40 table 2:Constraints Model

  • Key: UML14-582
  • Legacy Issue Number: 832
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.2.

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

Page 40, table 2: Core - Standard Elements

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

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

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

    Fixed in UML 1.2.

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

Page 54 - ConstrainedStereotype

  • Key: UML14-580
  • Legacy Issue Number: 830
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    considered and declined

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

Page 39 - ModelElement/Dependency associations

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

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

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

    Fixed in UML 1.3: Dependency relationships updated.

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

Page 16- The association from parameter to classifier has a 1-1 cardinalit

  • Key: UML14-578
  • Legacy Issue Number: 828
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Considered and declined.

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

Page 121 - Partition has no parent class

  • Key: UML14-577
  • Legacy Issue Number: 827
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Fixed in UML 1.3

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

Page 98: ActionSequence has no parent class

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

    Summary: ActionSequence has no parent class.

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

    no action needed, close issue

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

Page 60 - GraphicMarker

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

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

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

    fixed in UML 1.3

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

Page 35/37 - AssociationRole

  • Key: UML14-574
  • Legacy Issue Number: 824
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 and 37

    7 - In the diagram, the AssociationRole class appears. Its name is " AssociationEnd ".

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

    fixed in UML 1.2

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

Page 60 - MultiplicityRange

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

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

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

    UML 1.3: Multiplicity definition updated.

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

Page 81: message has no parent class

  • Key: UML14-575
  • Legacy Issue Number: 825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 81: message has no parent class

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

    fixed in UML 1.3

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

Page 60 - visibilityKind

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

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

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

    Considered but declined.

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

page 60 - EventOriginKind

  • Key: UML14-569
  • Legacy Issue Number: 819
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.3

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

page 60 - CallConcurrencyKind

  • Key: UML14-568
  • Legacy Issue Number: 818
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.3

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

Page 60 - PseudostateKind

  • Key: UML14-570
  • Legacy Issue Number: 820
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    fixed in UML 1.2

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

UML Documentation--Typos (05)

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

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML Documentation--Typos (06)

  • Key: UML14-565
  • Legacy Issue Number: 795
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML Documentation--Typos (07)

  • Key: UML14-566
  • Legacy Issue Number: 796
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

Error on association owners

  • Key: UML14-567
  • Legacy Issue Number: 815
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following constraint on associations :

    self.allConnections->forAll (r | self.namespace.allContents->includes
    (r.type) )

    seems incorrect to me :
    This basically restrict associations between classifiers in the same
    namespace. ==> you can not create an association between classes of
    different packages ?

  • Reported: UML 1.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

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

UML Documentation--Typos (03)

  • Key: UML14-562
  • Legacy Issue Number: 792
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML Documentation--Typos (02)

  • Key: UML14-561
  • Legacy Issue Number: 791
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML Documentation-Typos (01)

  • Key: UML14-560
  • Legacy Issue Number: 790
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML Documentation--Typos (04)

  • Key: UML14-563
  • Legacy Issue Number: 793
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

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

UML 2 issue, Common Behaviors

  • Key: UML14-559
  • Legacy Issue Number: 7380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Behaviors: objects that don't exist?

    At 13.1 we read:

    "Behaviors, as such, do not exist on their own, and they do not communicate. ... (Note that an executing behavior may itself be an object, however.)"

    It is not clear what this is intended to mean. To the untutored reader it seems to be a contradiction.

    What a behavior is and what a behavior execution is is fundamental to this half of UML. Whatever is intended should be spelled out clearly for the reader, very clearly.

  • Reported: RAS 2.0b1 — Wed, 26 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components / provided and required interfaces -- derived or subsets

  • Key: UML14-558
  • Legacy Issue Number: 6875
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

  • Reported: XMI 2.0 — Fri, 2 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Feature;ModelElement

  • Key: UML14-557
  • Legacy Issue Number: 5922
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    Why there are two different Backbone Diagrams in the UML 1.5 Specification. The one on Page 71 shows that a Feature has a visibility and a ModelElement has just a name, nothing more. On Page 596 an Feature has the visibility not anymore, but ModelElement has one, how this should be interpreted, which one is the right visibility

  • Reported: UML 1.5 — Tue, 29 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Physical" Metamodel Package Structure (uml-rtf)

  • Key: UML14-554
  • Legacy Issue Number: 3123
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The package structure of UML 1.3 makes it difficult to deploy small parts of
    the "physical" metamodel separately. For example, a MOF-based facility that
    supports classes from Behavioral_Elements.Common_Behavior must support all
    of Behavioral_Elements. A facility that supports Exceptions must also
    support Use Cases and State Machines. This has been a problem in the
    formation of the CWM metamodel which extends UML. Its interfaces and DTDs
    are made to be much too large.

    The result of UML currently having three metamodels (two of which are large)
    rather than many smaller metamodels is that the IDL modules are very large
    and so are the DTDs. Breaking the metamodels into several smaller ones will
    allow smaller interface sets and DTDs that can be mixed and matched to
    provide necessary functionality without a huge overhead.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TaggedValue in TaggedValue

  • Key: UML14-556
  • Legacy Issue Number: 4726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a ModelElement can contain any number of
    taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

    However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
    it can itself contain taggedValues.

    The question is: is this really intended? And if so: please explain the
    semantics of such a construction.

    If not, at simple well-formedness rule

    self.taggedValue = { }

    attached to TaggedValue would do the trick.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of classifier ownerscope

  • Key: UML14-555
  • Legacy Issue Number: 4446
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier ownerscope is ambiguous for structural
    features declared on classifiers that have children. It is not
    defined whether this gives value for the classifier and all its
    descendents, or values for the classifier and each descendant
    separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/notation/Keywords

  • Key: UML14-471
  • Legacy Issue Number: 6877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is a general issue that is quite pervasive. I think it is important
    enough to be considered by the FTF.

    The specification is littered with keywords which are used on diagrams
    to indicate various things.

    What the specification sorely needs is an Appendix that gathers them all
    together. And cross-references each with where it is defined and the
    compliance level it is associated with.
    Also what it needs is a general description of the semantics of
    keywords, how they differ from 'Standard Stereotypes' and associated
    constraints - e.g. it should not be allowed to declare a Stereotype with
    a name which, when decapitalized, is the same as a keyword (since they'd
    be indistinguishable).

    Arguably keywords would be depicted with a distinct notation from
    stereotypes (based on language design principles and to help users
    interpret diagrams where they see words in guillemets and don't know
    whether to look it up in the list of keywords or stereotypes) but that
    is probably too major a change to make at this stage. However the
    notation should be clarified to cover the following cases:
    A) if the same element requires a keyword and has a stereotype applied
    are they shown in 2 separate <<xxx>> expressions or in one, separated by
    a comma?
    B) if a stereotype is applied to a class normally indicated by a
    keyword, does that keyword still need to be provided?

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix B/Standard Stereotypes too heavyweight and incompletely defined

  • Key: UML14-470
  • Legacy Issue Number: 6876
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is in my opinion important enough to be considered by the FTF since
    it affects implementability.

    Appendix B contains a list of Standard Stereotypes.
    Ironically, due to the nature of the UML2 Profile mechanism this
    mechanism is more heavyweight than a subclass since it requires a
    separate instance - so for the <<call>> stereotype of Usage one ends up
    with not only a instance of Usage but an attached instance of Call -
    this is far more heavyweight than having a distinct subclass of Usage
    which would result in only one object. And it's also harder to process
    via XMI or APIs.

    The Appendix is not adequate as a definition and does not use the
    official Stereotype notation? In particular it does not make clear the
    name of the instance of Stereotype (which I can only guess would be the
    capitalized form of the stereotype keyword e.g. "Call"), nor does it
    specify the name of the association used to attach an instance of the
    stereotype with the instance of the metaclass. And, of course, is there
    actually a Profile object (or objects) that contains these stereotypes?
    Can users consider this Profile already applied to any UML model or does
    it have to be explicitly done or is this a variation point?

    Finally, Appendix B is not properly referenced: 7.14.1 refers to the
    "Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
    Standard Profile".

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition

  • Key: UML14-480
  • Legacy Issue Number: 6925
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

    Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

    Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

  • Reported: XMI 2.0 — Sun, 18 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The contents of the Interfaces package is shown in Figure 51

  • Key: UML14-479
  • Legacy Issue Number: 6913
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

    Should be "Figure 58"

  • Reported: XMI 2.0 — Fri, 16 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / navigability of enclosingOperation

  • Key: UML14-482
  • Legacy Issue Number: 6928
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

  • Reported: XMI 2.0 — Sun, 25 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Dependencies / Abstraction should have an optional mapping

  • Key: UML14-481
  • Legacy Issue Number: 6926
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

  • Reported: XMI 2.0 — Wed, 21 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / subsetting templateParameter

  • Key: UML14-478
  • Legacy Issue Number: 6911
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Idenitfy sections specifying run-time semantics

  • Key: UML14-477
  • Legacy Issue Number: 6902
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes /

  • Key: UML14-476
  • Legacy Issue Number: 6901
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    on page 115 (section 7.15.3) when talking about the Notation of an
    interface, the third paragraph (between figure 59 and 60) says:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *implements* this interface (see Figure 60).
    "

    And I think it should say:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *requires* this interface (see Figure 60).
    "

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

importedMember property

  • Key: UML14-473
  • Legacy Issue Number: 6897
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    The importedMember property is derived from the ElementImports and the PackageImports.

    self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

    The query importedMembers(...) should be importMembers(...). A fixed version is:

    self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / Two typos

  • Key: UML14-475
  • Legacy Issue Number: 6900
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 408 there is text that says:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335.

    I think it should say:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

    On page 414 there is text that says

    See example of the usage of collaboration occurrences in Figure 345.

    I think it should say:

    See example of the usage of collaboration occurrences in Figure 339.

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing closing bracket

  • Key: UML14-474
  • Legacy Issue Number: 6898
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) )

    The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) )

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"• value : InstanceSpecification

  • Key: UML14-472
  • Legacy Issue Number: 6896
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corrections and improvements to glossary definitions

  • Key: UML14-377
  • Legacy Issue Number: 6447
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: Consider the following corrections and improvements to Terms
    and Definitions:

    Activation ­ Consider changing from “the execution of an action” to
    “initiating the execution of an action”.

    Analysis ­ Delete the term “software”.

    Artifact ­ Delete the term “software”.

    Comment ­ Replace term “note” with “comment”.
    Runtime. run-time for a physical system, to imply execution of the
    operational system. (S-pg 252)

    Deployment diagram ­ Replace “software artifacts as nodes” with “artifacts
    on nodes”. Delete the term software and change as to on.

    Design ­ Delete the term “software”. Delete “required functional and
    quality”. This is too restrictive, and doesn't include physical
    requirements, etc.

    Design time - Delete the term “software”.

    Development process - Delete the term “software”.

    Diagram ­ Update the types of diagrams to be consistent with the proposal
    (i.e. timing diagrams, structure diagrams, information flow, etc)

    Generalization ­ Insert “indirect” prior to “instance of the general
    classifier”.

    Inheritance ­ Delete last fragment “related by behavior”.

    Interaction diagram ­ Include reference to timing diagram.

    Interaction overview diagram ­ delete “s” on nodes

    Layer ­ Don’t restrict the use of the term partition to reflect a vertical
    slice of the architecture. This is too limiting. Add a qualifier such as
    may.

    Modeling time - Delete the term “software”.

    Module - Delete the term “software”.

    Object diagram ­ should this be replaced with Instance diagram.

    Part ­ Add the following after classifier instance “or roles of a
    classifier”. Reference the definition for “Role”, which provides
    clarification.

    Partition - Don’t restrict the use of the term partition too much. Partition
    can reflect the grouping of any set of model elements based on a set of
    criteria.

    Run time ­ Insert after “computer program” “or a system”.

    Specification ­ Consider changing the definition to “a set of requirements
    for a system or other classifier.

    Subsystem ­ Replace “See package” with “See system”

    System ­ Replace system definition with the following: A component which
    contains parts, and has observable properties and behaviors.

    Trace ­ Add the following ­ A dependency between a derived requirement and a
    source requirement

    Use case diagram ­ Change from “A diagram that shows the relationships among
    actors and use cases within a system” to “A diagram that shows the
    relationships among actors, the subject (system), and use cases

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The name "required interface" is misleading

  • Key: UML14-376
  • Legacy Issue Number: 6443
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The name "required interface" is misleading
    Description: The name "required interface" is misleading, since a required
    interface is not really an interface; it is a usage of an interface.
    Recommendation: Rename "required interface" to something more descriptive

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 significant typo - collaboration diagram

  • Key: UML14-373
  • Legacy Issue Number: 6439
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In the UML 2.0 Superstructure final adopted specification
    document 03-08-02 (and all previous versions), the phrase
    "collaboration diagram" appears in the last row of Figure 464 on
    page 590, and in no other place in the entire document. This
    occurrence probably missed the global change from "collaboration
    diagram" to "communication diagram". This is a key figure that is
    likely to be reproduced in many articles and slide sets, and
    should be fixed.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same as issue 6066.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

targetScope on StructuralFeature and AssociationEnd

  • Key: UML14-372
  • Legacy Issue Number: 6437
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x supported targetScope on StructuralFeature and AssociationEnd. This does not seem to be present in UML 2.0 when looking at Property or elsewhere. For backward compatibility this should be reinstated or alternatively at least be a standard tag in Appndix B.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of parametric models

  • Key: UML14-375
  • Legacy Issue Number: 6442
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: It is unclear how to specify parametric models as they are used
    in systems engineering. In particular, it is unclear how to specify
    mathematical or logical equations (e.g., Force = mass * acceleration) that
    constrain the values of classifier attributes/properties. Systems engineers
    must be able to:
    a) Specify the dependencies between parameters and expressions or
    constraints. This must support arbitrarily complex and continuous time
    equations.
    b) Allow parameters to be passed into expressions.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Excessive syntactic and semantic overlap between structured Classifiers

  • Key: UML14-374
  • Legacy Issue Number: 6440
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    There is excessive syntactic and semantic overlap between two
    kinds of structured Classifiers: StructuredClasses::Classes and Components.
    It is confusing to users how to choose between these constructs, and how to
    apply them correctly. The confusion extends to how Ports and Interfaces are
    used with these constructs, since it is unclear how to use both of these in
    a complementary manner.
    Recommendation: Remove one of these structured Classifiers, or clarify how
    to choose between and apply them. Also explain how to apply Ports and
    Interfaces in a complementary manner for both black-box and white-box views
    of structured Classifiers.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 / <>

  • Key: UML14-371
  • Legacy Issue Number: 6434
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Definition mismatch:

    p. 108/109:
    "...dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class."

    p. 595:
    "A usage dependency among classifiers indicating that
    operations on the client create instances of the supplier."

    Either use a <<create>> dependency on p. 108/109 or change definition on p. 595.

    I think the instantiate dependency is a relationshp between an instance and its specification.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6159

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort

  • Key: UML14-370
  • Legacy Issue Number: 6432
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 3, Composite Structures, Table 3, p. 151: The "Reference"
    column for Port refers to ComplexPorts. ComplexPorts are not defined in the
    specification.

    Recommendation: Delete the reference to ComplexPorts and clarify the
    language in the Reference column for Port accordingly

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint

  • Key: UML14-369
  • Legacy Issue Number: 6431
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures,
    constraint [1], p. 146, which says: "The multiplicities on connected
    elements must be consistent." This seems too vague. Consistency needs to be
    defined more precisely.

    Recommendation: The English statement of the constraint should be expressed
    directly in terms of the properties of the metamodel. (The constraint
    should be expressed in OCL too, of course.)

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity

  • Key: UML14-368
  • Legacy Issue Number: 6429
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures, third
    paragraph of the Notation section, which starts on page 142: This paragraph
    discusses how to notate the multiplicity of a Port (last line of p. 142),
    referring to Figure 3-35 on page 143. However, the semantics of Port
    multiplicity do not appear to be spelled out.

    Recommendation: Define the semantics of the multiplicity of a Port.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6090 correction

  • Key: UML14-553
  • Legacy Issue Number: 7561
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6090 correction. The following sentence should have been added to the last paragraph of the resolution to issue 6090: "An action may not put more values on an output pin in a single execution than the upper multiplicity of the pin."

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Classes / Operation constraints

  • Key: UML14-543
  • Legacy Issue Number: 7366
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, the UML 2 specification defines Operation properties precondition, postcondition, and bodyCondition that are owned constraints. However, these properties do not subset the Namespace::ownedRule property, but rather the Namespace::ownedMember property.

    The opposites of these properties are preConstraint, postConstraint, and bodyConstraint, all of which are non-navigable and subset Constraint::context and Constraint::namespace.

    Also, the Constraint::namespace property, which is non-navigable, subsets Constraint::context, which is navigable. This is inconsistent, and in fact violates the UML's own constraint on property subsetting which stipulates that a navigable property can only be subsetted by a navigable property (constraint [4] of metaclass Property).

    The consequence of all this is that a Constraint that is the precondition (for example) of an Operation does not have a context . This means that a constraint such as an OCL expressions in pre-conditions cannot be parsed against the context namespace.

    There are (at least) two ways to solve this problem:
    let Operation::precondition and its cohorts subset Namespace::ownedRule instead of Namespace::ownedMember (which would leverage the eContainer() "cheat" that EMF offers to get the owner of an element that doesn't have a navigable owner property)
    let Constraint::namespace redefine NamedElement::namespace and make it navigable, thus making the subset relationship with Constraint::context valid

    The first option seems preferred, for two reasons:
    It makes sense that all constraints that a namespace owns should be included in the ownedRule property
    This would be consistent with the Behavior metaclass, whose precondition and postcondition properties do subset ownedRule

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / ordering of association ends

  • Key: UML14-542
  • Legacy Issue Number: 7365
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems to me the the following properties should perhaps be ordered (currently they are not):

    ApplyFunctionAction::argument
    Association::endType
    CombinedFragment::operand
    ConnectableElement::end
    InteractionOccurrence::argument
    Message::argument
    StringExpression::subExpression
    StructuredClassifier::ownedAttribute
    TemplateSignature::parameter

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Q re Parameter

  • Key: UML14-541
  • Legacy Issue Number: 7355
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There appears to be an inconsistency in the specification as to what it
    means to be a formal parameter or a return result. Please choose between the
    following two interpretations:

    A. A return result is a parameter that is specially indicated to be the
    return result. All other parameters are formal parameters.

    B. A return result is any parameter with direction return, out, or inout. A
    formal parameter is any parameter with direction in or inout.

    You could view (A) as focusing on the syntactical role the parameters play,
    while (B) focuses on when they communicate data.

    The difficulty arises from that the infrastructure and the superstructure
    have differing machineries of dealing with parameters.

  • Reported: XMI 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 7344

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/interactions

  • Key: UML14-537
  • Legacy Issue Number: 7301
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf: page 412: consider/ignore - I can find no explanation of how
    the message types to be considered/ignored are modeled. The spec should be
    clear on this issue, probably in the description of combined fragment.

  • Reported: XMI 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / invalid multiplicity

  • Key: UML14-536
  • Legacy Issue Number: 7277
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 428 says that TemplateParameterSubstitution::ownedActual has a multiplicity of (0..1). However, the association description on page 549 states that the multiplicity is (1..). However, it seems to me that the multiplicity was intended to be 0.. despite what the diagram (and Rose model) seem to suggest.
    This is because a template substitution may not necessarily own any of its actual parameter values.

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Profiles / problem with name collisions

  • Key: UML14-535
  • Legacy Issue Number: 7276
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new rule for extension end role names as adopted in ballot 10 (specifically for metaclass extension role names) is likely to lead to name collisions. For example, a stereotype that extends the Package metaclass with a property named 'basePackage' would conflict with the recommended role name of the metaclass extension end ('basePackage'). The recommended role names should be less likely to collide with names that might be chosen for stereotype properties, for example, base$"ExtendedMetaClassName" (i.e. base$Package).

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema (02)

  • Key: UML14-548
  • Legacy Issue Number: 7402
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema." [2] The requirement to comply with an XMI schema may be ambiguous. If this is intended to require that a compliant implementation correctly create a model from an XMI file written according the the XMI scheam and write an XMI file from a model according to that schema, this ought to be spelled out.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This aspect has been clarified as part of the resolution to issue 6248

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about Enumeration and EnumerationLiteral

  • Key: UML14-547
  • Legacy Issue Number: 7379
  • Status: closed  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    Enumeration is a subtype of DataType, and DataType allows both Properties and Operations. And since Enumeration has no additional constraints, this means that Enumeration also allows owned Property and Operation instances. Is there a reason why this is so? I would have expected an OCL constraint that limited the owned members of Enumeration to be only EnumerationLiteral instances.

    EnumerationLiteral is a subtype of InstanceSpecification, which itself is a subtype of PackageableElement. Because Package and own any number of PackageableElements, Package can actually own EnumerationLiteral. Is there a reason why this is so? The sematics talk about EnumerationLiteral being in the scope of an Enumeration, but it is somewhat vague about whether that is a constraint (there are no additional constraints). I would have expected an OCL constraint stating that EnumerationLiteral is only valid in the context of an Enumeration.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / missing owners of concepts

  • Key: UML14-540
  • Legacy Issue Number: 7336
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined

  • Reported: XMI 2.0 — Fri, 14 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / state should be a namespace

  • Key: UML14-539
  • Legacy Issue Number: 7323
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, a State is not a namespace, even though it contians things such as entry and exit pseudostates, substates, etc. all of which are in the context of a State. Therefore, State should be made a kind of Namespace as well as being a kind of Vertex. (Note that Vertices in general do not need to be Namespaces.

  • Reported: XMI 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6207.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Connector

  • Key: UML14-538
  • Legacy Issue Number: 7321
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 163:
    Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or it may represent the
    possibility of the instances being able to communicate because their
    identities are known by virtue of being passed in as parameters, held in
    variables, created during the execution of a behavior, or because the
    communicating instances are the same instance.

    Doesn't this imply a semantic variation point?

  • Reported: XMI 2.0 — Fri, 7 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Common Behavior / Trigger should be a named element

  • Key: UML14-546
  • Legacy Issue Number: 7369
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 317, Trigger is defined as a specialization of Element. However, it seems reasonable for triggers to have names, so it really should be a subclass of NamedElement

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Use cases / navigation from subject to use case

  • Key: UML14-545
  • Legacy Issue Number: 7368
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current model of use cases does not allow navigation from a subject classifier of a use case to its use case. It should be possible to do this, so that a classifier can easily identify which use cases apply to it. The proposed resolution is to make Classifier::useCase navigable.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / superclass pointers

  • Key: UML14-544
  • Legacy Issue Number: 7367
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It would greatly improve readability if every metaclass had a section that listed all the immediate superclasses of that class. This would also make the document consistent with the resolution to issue 7156, which indicates that such a subsection should exist.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6094 correction.

  • Key: UML14-552
  • Legacy Issue Number: 7560
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6094 correction. The resolution to Issue 6094 made action concrete, but left the assocations input and output as unions, which are derived and cannot be used in a a direct instance of Action (the input and output associations were changed to nonderived, but this is inconsistent). Restore original model and introduce OpaqueAction instead

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Need unattached lifelines

  • Key: UML14-551
  • Legacy Issue Number: 7553
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At present, a lifeline always requires a corresponding ConnectableElement. For informal users of UML this requires that have to declare a specific structure for every interaction diagram that they want to draw. However, there are many uses of UML who want a less formal approach. For example, people may want to attach scenarios to use cases informally, that is, without having to talk about any specific connectable elements.

    Therefore, the multiplicity of the Lifeline::represents association end should be changed from 1 to 0..1.

  • Reported: RAS 2.0b1 — Wed, 30 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transition is simply never enabled

  • Key: UML14-534
  • Legacy Issue Number: 7256
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Maybe this is a stupid question. But I could not find an answer ... A transition is not required to have a trigger. If the source of the transition is a composite state, its triggering is described by the rules about "completion transitions". But what happens if the source is just a simple state: It would seem that the transition cannot be considered as a "completion transition", but at the same time, the transition never satisfies the rules about "enabled transitions". Hence it woulds seem that the transition is simply never enabled. Is this interpretation correct? If so, it this behaviour really intended?

  • Reported: XMI 2.0 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Sequence diagram

  • Key: UML14-533
  • Legacy Issue Number: 7253
  • Status: closed  
  • Source: Independence Blue Cross ( Janardhanam Venkat)
  • Summary:

    In the UML Sequence diagram there are asynchronous message that is very useful in designing application. I am trying to create an activity diagram between 4 asynchronous system. Why cant we have asynchronous arrow in activity diagram between swim lanes? That is the true representation of a flow in a distributed system.

  • Reported: XMI 2.0 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property strings on association ends

  • Key: UML14-550
  • Legacy Issue Number: 7404
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The drawings show property strings on association ends, which consist of a comma separated list of property strings. This is not authorized by the Notation section of 7.11.2.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

change trigger

  • Key: UML14-549
  • Legacy Issue Number: 7403
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value of one or more attributes or associations." [13.3.8] Does this intend to mean a change in value not of of one or more attributes, but of one or more slots? If so, then does it also intend to mean a change in value not of of one or more associations, but of one or more links? But, can the value of a link change? "A link is a tuple with one value for each end of the assocaition, where each value is an instance of the type of the end." [7.11.2] With a different value, we have a different tuple. Perhaps the text intends: A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value in one or more slots or the creation of destruction of one or more links.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify termination of asynchronous invocations

  • Key: UML14-405
  • Legacy Issue Number: 6486
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that asychronously invoked behaviors/operations aren't
    terminated by activity final

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A Diagrams

  • Key: UML14-404
  • Legacy Issue Number: 6485
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 464 includes a Collaboration Diagram. Is this a carryover error from UML 1.x or a reference to a diagram that contains Collaborations and CollaborationOccurrences

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6066

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 17

  • Key: UML14-403
  • Legacy Issue Number: 6484
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Page 534 states, "When it is attached to an information channel, a black triangle on the information channel indicates the direction." What is an information channel? This is the only sentence in the document in which this phrase is used.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.3 Realization

  • Key: UML14-396
  • Legacy Issue Number: 6477
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The text states, "A component realization is notated in the same way as the realization dependency, i.e. as a general dashed line with an open arrow-head." What is an open arrowhead. Compare and contrast that with the "stick arrowhead" described in the Presentation Options section of Class in Composite Structures (page 156). Stick arrowhead can be found 6 times in the spec, while open arrowhead can be found 4 times. They all appear to refer to the same notation. I recommend that you chose one term.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.1 Component

  • Key: UML14-395
  • Legacy Issue Number: 6476
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 89 and 90. The text states "A component is shown as a Classifier rectangle with the keyword «component». Optionally, in the right hand corner a component icon can be displayed." Some of the example components do not have the <<component>> included, just the icon is present. My reading of the text is that this is incorrect. The icon is optional but the <<component>> designation is required

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams

  • Key: UML14-401
  • Legacy Issue Number: 6482
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In the text describing Figure 345 it states, "Thus the appearance of a w message after the v is an invalid trace." There is no w message in the diagram.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams

  • Key: UML14-400
  • Legacy Issue Number: 6481
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 15. The text describing message states, "asynchronous message, a call and a reply" but the graphic shows them in the order of call, asynchronous, reply. The text should match the graphic.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.1 Component

  • Key: UML14-394
  • Legacy Issue Number: 6475
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 81 should have identifiers for the provided interfaces. Figure 83 is not consistent with section 7.15.3 in that it uses a realization instead of a dependency as described in the text related to Figure 62. The examples in this section are not cohesive. It is not clear how Figure 85 relates to the rest of the examples.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.3.14 Message

  • Key: UML14-399
  • Legacy Issue Number: 6480
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The semantics section states, "There will normally be a return message from the called lifeline..." while the Notation section refers to "The reply message from a method has a dashed line." If the return message and the reply message are the same ting then only use one name. If they are differnt, then explain the difference

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10 Deployments

  • Key: UML14-398
  • Legacy Issue Number: 6479
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 130 and 131. If these are meant to be two representations of the same node, then make the contents the same or explain the differences. Figure 136 should be <<ExecutionEnvironment>> vice <<container>>. Either that or the text is incorrect and needs to be changed

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.1 Overview

  • Key: UML14-393
  • Legacy Issue Number: 6474
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams (02)

  • Key: UML14-402
  • Legacy Issue Number: 6483
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 19 the Message entry- it is unclear which message is which and I don't think any of them are reply messages

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.4 Diagrams

  • Key: UML14-397
  • Legacy Issue Number: 6478
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 6. The Collaboration and CollaborationOccurrence notation is incorrect

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Ports

  • Key: UML14-450
  • Legacy Issue Number: 6669
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 168 - isBehavior: Boolean Specifies whether requests arriving at this
    port are sent to the classifier behavior of this
    classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383).
    Such ports are
    referred to as behavior port. Any invocation of a behavioral feature
    targeted at a behavior
    port will be handled by the instance of the owning classifier itself, rather
    than by any
    instances that this classifier may contain. The default value is false.

    This needs to be backed up by a constraint that ensures that no
    ownedConnectors may connect to such a Port.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Connector

  • Key: UML14-449
  • Legacy Issue Number: 6668
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    If as has been suggested structured classes completely encapsulate their
    parts, then I would expect to see a constraint against Connector, which
    states that the parts associated to its ends via "role" or "partWithPort"
    should be owned by the same StructuredClassifier as owns the Connector.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / association end naming

  • Key: UML14-457
  • Legacy Issue Number: 6679
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityNode::interruptibleRegion should probably be renamed to ActivityNode::inInterruptibleRegion so as to be consistent with ActivityNode::inGroup, ActivityNode::inPartition, and ActivityNode::inStructuredNode.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See changes for 6678.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / inconsistency in representing subsetting

  • Key: UML14-456
  • Legacy Issue Number: 6678
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Instead of subsetting ActivityEdge::inGroup with an ActivityEdge::interruptibleRegion property (as is done with ActivityNode), a completely new association (ActivityEdge::interruptibleRegion<->InterruptibleActivityRegion::interruptingEdge) is introduced. Why the inconsistency?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/assocition end specialization consistency

  • Key: UML14-454
  • Legacy Issue Number: 6676
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents are redefined by subclasses ActivityPartition (Figure 183), InterruptibleActivityRegion (Figure 191), and StructuredActivityNode (Figure 192), but the opposites of these properties are subsetted instead. Would make more sense to apply either redefinition or subset constraints to both ends of the associations rather than a mixture of both?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

subsettedProperty->forAll(sp | isDerivedUnion) ?

  • Key: UML14-452
  • Legacy Issue Number: 6674
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    As used in UML 2 Infra and Super is it intended that all properties that are subset by some other properties be derived unions?

    So that the following constraint would be true for the Class PropertyÂ…

    subsettedProperty->forAll(sp | isDerivedUnion) ?

    I understand this may not be a requirement but am just trying to understand if this is how it is used in the Spec.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Connector End

  • Key: UML14-451
  • Legacy Issue Number: 6670
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    p 165, partWithPort: Property [ 0..1 ] Indicates the role of the internal
    structure of a classifier with the port to which the connector
    end is attached.

    Is there any significance to the fact that the term role is used, or is part
    meant here? There seems to be no constraint that makes it explicit that
    partWithPort must associate to a part (i.e. a property with
    isComposite=true.)

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/invalid multiplicity 0

  • Key: UML14-455
  • Legacy Issue Number: 6677
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    InterruptibleActivityRegion::edgeContents redefines the multiplicity of ActivityGroup::edgeContents to be 0, which violates the constraint that an upper bound must be greater than 0

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Structured Classes

  • Key: UML14-447
  • Legacy Issue Number: 6666
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf

    Figure 95 - the term

    {subsets redefinit ionContext}

    appears in an odd place - I assume it belongs as a complement to
    redefinedConnector, rather than ownedConnector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/end naming consistency

  • Key: UML14-453
  • Legacy Issue Number: 6675
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents should probably be renamed to ActivityGroup::edgeContent and ActivityGroup::nodeContent so as so be consistent with the rest of the specification.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 164 - there are two constraints sections for Connector

  • Key: UML14-448
  • Legacy Issue Number: 6667
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Page 164 - there are two constraints sections for Connector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Delete the section “Constraints” at the top of p. 164 of adtf/03-08-02.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure Derived Union vs. derivationExpression?

  • Key: UML14-444
  • Legacy Issue Number: 6646
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The use of the latter would eliminate the isDerivedUnion Property from the Class Property and would eliminate the subsets and union property strings from all the associations. Also would allow for the definition of more complex derivations other than simple unions. A Property could be overridden/redefined for each child class to update the derivation for that class.

    Most importantly the information would be stored in a more appropriate location. When attempting to determine a value for a property one simply need look at the derivationExpression and not look at all other properties to determine which properties subset this derived union. Given the number of mistakes using derived union in the UML 2.0 Spec it seems apparent that this is error prone.

    Implementation would also be easier. Most modeling tools could simply add a couple of tagged values to allow for the definition of derivationExpression. Also languages would be able to generate a standard function call to calculate the derivationExpression.

    Example:

    The Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement. In order to determine how to actually derive the value of ownedMember one has to currently iterate all the properties to determine which ones subset the derived union property and then perform the union. Also, one would have to ensure the property strings are on each subsetting member.

    Using the derivationExpression one would only need the following in one location:

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

    If desired, but not required, the derivation expression could be displayed on a diagram via a comment.

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is really a continuation of issue 6644, not a separate issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure reccomendation (derived unions)

  • Key: UML14-443
  • Legacy Issue Number: 6644
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / incorrect comments in notation section

  • Key: UML14-442
  • Legacy Issue Number: 6643
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML 2.0 Superstructure ptc/03-08-02

    In table 22, in the Notation cell associated to the "Include" Note Type,
    the comments associated to the two Use Case shoud be exchanged :
    the Whidraw UC should be the including UC; the Card Identification should
    be the included UC.

  • Reported: UML 1.5 — Sat, 29 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in definition of PackageMergeKind

  • Key: UML14-441
  • Legacy Issue Number: 6642
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    Figure 9-11 specifies that the two values for PackageMergeKind are 'extent' and 'define'. This is probably an editorial error. I suppose the same error exists in the OMG Standard petal file(s).

    Under PackageMerge, Properties, the sentence, 'mergeType: PackageMergeKind Specifies the kind of package merge to perform, define, or extend.', has an extra comma, the last, which should be removed. This sentence might better be written with a colon in place of the first comma:

    mergeType: PackageMergeKind Specifies the kind of package merge to perform: define or extend.

  • Reported: UML 1.5 — Thu, 27 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/parts

  • Key: UML14-446
  • Legacy Issue Number: 6648
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 174:part: Property References the properties specifying
    instances that the classifier owns by composition.
    This association is derived, selecting those owned properties where
    isComposite is true.

    This seems to imply that /parts can only reference Properties whose types
    are Class, Interface, Templateable Class., i.e. only those subtypes of
    Classifier that denote instances. Is this correct - if so then it should be
    more explicit in the constraints (I couldn't see any other reference to this
    constraint).

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Classes

  • Key: UML14-445
  • Legacy Issue Number: 6647
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    pg 168: The provided and required interfaces completely characterize any
    interaction that may occur between a classifier and its
    environment at a port.

    If the type of a port is a class, perhaps with superclasses, then I don't
    see how the above statement can be true.

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 9 (State Machines) of 3rd revision

  • Key: UML14-437
  • Legacy Issue Number: 6626
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    In section 9 (State Machines) of 3rd revision

    Page 454 - The Description of the class “Transition” associations fails to list the association “container” depicted on the drawing on page 415.
    Drawing on page 415 displays

    {redefines owner}

    for both container of Vertex and for Transition. I believe these should be

    {subsets owner}

    (also in mdl file)

  • Reported: UML 1.5 — Sun, 23 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Actions/PrimitiveFunction missing properties

  • Key: UML14-436
  • Legacy Issue Number: 6625
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PrimitiveFunction is missing formalParameter and returnedResult properties, as referenced by ApplyFunctionAction on page 222. Should it be a specialization of Behavior?

  • Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See resolution of 7405.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time trigger notation in state machines

  • Key: UML14-434
  • Legacy Issue Number: 6607
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In activity diagrams a time expiration event can be notated using a special "time consumation" icon.
    For state machines it is not clear whether the same icon can be used.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No way to represent "uninterpreted" actions

  • Key: UML14-433
  • Legacy Issue Number: 6606
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Within a state machine we would like refer to an action defined rather "informally" using natural language.
    Among the list of actions metaclasses, we did not see any one that could be used to map our "informal"
    action.
    Suggestion for resolution: Add a UninterpretedAction metaclass in the metamodel.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Actions/non-existent feature "multiplicity"

  • Key: UML14-438
  • Legacy Issue Number: 6627
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The third constraint on StructuralFeatureAction (page 258) uses the very non-existent feature "multiplicity" of the InputPin metaclass. Not only that, but because this "multiplicity" feature doesn't exist, who is to tell what kind of element it is that defines the "is(lower, upper)" operation! Recall that the InputPin is a specialization of ObjectNode, which is not a MultiplicityElement, but defines a single attribute "upper : ValueSpecification." Where is the corresponding "lower"?

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This duplicates 6090.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation when guards are used in conjunction with triggers in transitions

  • Key: UML14-435
  • Legacy Issue Number: 6608
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    According to the metamodel, a transition may have a guard and a trigger. However the specification
    does not say how to draw a transition that has both. Should we put the guard, (1) near the arrow
    which is before the "input" symbol representing the trigger signal, or (2) near the arrow which is after
    the "input" symbol or (3) inside the symbol representing the trigger?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure 3rd revision - Owner of triggers?

  • Key: UML14-440
  • Legacy Issue Number: 6629
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Trigger specializes Element which has the constraint self.mustBeOwned() implies owner->notEmpty()

    And defines mustBeOwned = true

    Trigger and all of its specializations

    1. never define any relationship that

    {subsets owner}

    2. Do not override mustBeOwned

    Therefore Trigger and all specializations will violate the constraint.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6206

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Action/featuringClassifier misinterpreted

  • Key: UML14-439
  • Legacy Issue Number: 6628
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature!

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UseCase - Constraint for non-circular include relation

  • Key: UML14-493
  • Legacy Issue Number: 6965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Constraint for non-circular include relation

    I suggest to add the following fragments to the sections "Additional Operations" and "Constraints":

    Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases.

    UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) )

    Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self)

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What level of MOF 2.0 is the metamodel for UML 2.0?

  • Key: UML14-492
  • Legacy Issue Number: 6959
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    UML 2.0 does not state which level of MOF (EMOF, CMOF, or
    whatever else) provides its meta-meta-model. Therefore, there is
    no formal statement defining which Class definition (Basic or
    Constructs package level) and so forth is the basis for the
    definitions in the UML 2.0 specification. UML tools implement
    this class, so it's probably a good idea to know which one it's
    supposed to be. (Proof, in case you're wondering: The names
    EMOF and CMOF do not occur anywhere in the Superstructure
    final adopted specification 03-08-02. The name MOF does, but
    not in the context of which version of MOF defines the
    UML metametamodel.)

    If there is an ambiguity in which it is, the FTF needs to resolve
    it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it
    should be stated clearly in the specification.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Realize keyword-stereotype

  • Key: UML14-484
  • Legacy Issue Number: 6930
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired.

    The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this.

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / Properties owned by properties

  • Key: UML14-483
  • Legacy Issue Number: 6929
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers)

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367

  • Key: UML14-489
  • Legacy Issue Number: 6949
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Top of page 367, text says:
    Activity diagrams have graphical elements for containment. These
    are included in Table 13.

    In the next line, the table caption says:
    Table 13 - Graphic nodes included in activity diagrams

    Proposed resolution:
    These are inconsistent, although not necessarily wrong. They should be
    made consistent.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366

  • Key: UML14-488
  • Legacy Issue Number: 6948
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Middle of page 366, text says:
    The graphic paths that can be included in structural diagrams are
    shown in Table 12.

    In the next line, the table caption says:
    Table 12 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365

  • Key: UML14-487
  • Legacy Issue Number: 6947
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:

    Issue 1:
    Top of page 365, text says:
    The graphic nodes that can be included in structural diagrams are
    shown in Table 11.

    In the next line, the table caption says:
    Table 11 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Deployments / Invalid cross-references

  • Key: UML14-486
  • Legacy Issue Number: 6946
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / incorrect table title

  • Key: UML14-495
  • Legacy Issue Number: 6969
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UseCase - Include - Constraint for irreflexivity

  • Key: UML14-494
  • Legacy Issue Number: 6967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Include - Constraint for irreflexivity

    I suggest to add the following constraint for Include:

    Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6965.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / Dependency should not be abstract

  • Key: UML14-485
  • Legacy Issue Number: 6945
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some):

    Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown
    Table 4, P.130, defines a visual symbol for it
    Fig. 101, P.155, shown as abstract
    Fig. 126, P.183, shown as abstract
    Fig 130, P.188, shows a pure dependency in an example
    Table 9, P.199, defines a visual symbol for it

    Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 superstructur: actor

  • Key: UML14-496
  • Legacy Issue Number: 6970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML2 superstructure 03-08-02
    p. 513
    "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."

    A subsystem is a component stereotype, so it doesn't make sense to mention it here.

    I would propose the following constraint instead of the above one:
    "[1] An actor can only have associations to classifiers, and these associations must be binary."

    It makes sense that an actor can have binary associations to the subject they are interacting with.
    The subject of an use case is a classifier.

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / specialization labeling convention

  • Key: UML14-491
  • Legacy Issue Number: 6958
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in Collaboration Diagram figure

  • Key: UML14-490
  • Legacy Issue Number: 6950
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443,
    figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs
    a colon, and should be "y:superB" (as it is in the top right box).

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Connector types

  • Key: UML14-386
  • Legacy Issue Number: 6461
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    This is the definition of Connector (Superstructure, p. 163): "Specifies a
    link that enables communication between two or more instances. This link may
    be an instance of an association, or it may represent the possibility of the
    instances being able to communicate because their identities are known by
    virtue of being passed in as parameters, held in variables, created during
    the execution of a behavior, or because the communicating instances are the
    same instance. (...)"

    This paragraph is clearly a reinterpretation of the five old association and
    link stereotypes, now obsolete. Let's rewrite the second sentence as
    follows, inserting those old stereotypes for clarity:

    This link may be an instance of an association, <<association>>
    or it may represent the possibility of the instances being able to
    communicate because their identities are known
    by virtue of being passed in as parameters, <<parameter>>
    (by virtue of being) held in variables, <<???>>
    (by virtue of being) created during the execution of a behavior, <<local>>
    or because the communicating instances are the same instance. <<self>>

    It seems that the concept conveyed by the old <<global>> stereotype has
    completely disappeared (probably an improvement). But the comma between the
    words "variables" and "created" suggests that a new kind of connector, or
    link, has been introduced. But maybe the true intention of the writer was:

    (by virtue of being) held in variables created during the execution of a
    behavior, <<local>>

    That is, the comma between the words "variables" and "created" would be
    superfluous. It is not very important whether the kinds of Connector
    correspond to the old stereotypes, but it is important to know how many
    kinds of Connector there are.

    PROPOSED SOLUTION
    Suppress the comma between the words "variables" and "created".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

glossary

  • Key: UML14-385
  • Legacy Issue Number: 6459
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The glossary included with the appendices of the text that was adopted by the voters has been removed and that text inserted as normative text. There is no authority for the editors preparing the final adopted specification to make this major change. To make matters worse, the change introduces contradictions into the normative part of the specification.
    ...

    Suggested resolution: Move this text back where it came from.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Abandon the OMGS4LMMA

  • Key: UML14-383
  • Legacy Issue Number: 6457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    If the so-called OMGS4LMMA is accepted, it is not possible that an InformationFlow could connect both Classes and Instance Specifications.
    ...

    Suggested resolution: Abandon the OMGS4LMMA. Apply InstanceSpecification uniformly (for example, an informationFlow is used to connect classes and an instanceSpecification of an informationFlow is used to connect instanceSpecifications of classes, that is, to connect objects.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

14.3: StateInvariant and ExecutionOccurrence

  • Key: UML14-382
  • Legacy Issue Number: 6454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    14.3: StateInvariant and ExecutionOccurrence are both subclasses of InteractionFragment. "Each interaction fragment is conceptually like an interaction by itself." [14.3.9] And, indeed, "An ExecutionOccurrence is an instantiation of a unit of behavior..." [14.3.4] But, "A StateInvariant is a constraint on ... state..." [14.3.17] That's not like an interaction by itself, nor like any interaction at all. We've mixed models of behavior with specifications of constraints on state.

    This is an example of a recurrent problem in the specification: subclasses that are not like their superclasses.
    ...

    Suggested resolution: Review the specification with this in mind and correct all improper subtyping

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure FTF issue - Profiles

  • Key: UML14-381
  • Legacy Issue Number: 6453
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    In the Profile chapter, there is no section for "Changes from UML 1.4" for
    stereotypes

    However, one feature of UML1.4 : attaching tagged values independently of
    any stereotype, has disappeared in UML2.0

    The evolution tagged values --> attribute should be discussed and that
    particular case enlighted. a specific pattern for converting UML1.4
    stereotype independant tags into UML2.0 should be provided.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Removal of gratuitous restrictions to software applications

  • Key: UML14-380
  • Legacy Issue Number: 6450
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Removal of gratuitous restrictions to software applications
    Description: UML is being used extensively for systems modeling as well as
    software modeling. Consequently, gratuitous restrictions to software
    applications should be removed from the specification.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.1 ElementImport

  • Key: UML14-388
  • Legacy Issue Number: 6468
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The Semantics discussion includes the statement
    An imported element can be further imported by other namespaces using either element or member imports.

    The phrase "member import" is not defined and does not appear anywhere else in the spec. What does it mean? Provide an example of member import.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Include(s) and Extend(s)

  • Key: UML14-387
  • Legacy Issue Number: 6465
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for the Extend and Include relationships is a dashed arrow with
    open arrow and the keyword <<extend>> or <<include>> (Superstructure, pp.
    516, 518). Nevertheless, the notation examples given in pages 521, 523 and
    524 write "extends" and "includes", with an final "s". The other examples
    are allright.

    PROPOSED SOLUTION
    Fix the notation examples.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram Taxonomy corrections

  • Key: UML14-379
  • Legacy Issue Number: 6449
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The diagram taxonomy should be corrected as follows:
    a) "Collaboration Diagram" as a subtype of "Interaction Diagram" should be
    renamed "Communication Diagram";
    b) "Collaboration Diagram" should be added as a subtype of "Composite
    Structure Diagram";
    c) "Interaction Diagram" should be classified as a subtype of "Sequence
    Diagram" and "Activity Diagram"

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of terms "implement" and "realize"

  • Key: UML14-378
  • Legacy Issue Number: 6448
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The terms “implement” and “realize” are used inconsistently
    throughout the specification. These terms should be defined in the glossary
    (Preface, Terms and Definitions) and applied consistently throughout the
    specification.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.18 Diagrams

  • Key: UML14-392
  • Legacy Issue Number: 6473
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 4 - the Package Import dependency should be <<access>> not <<uses>>.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.15.3 Interfaces

  • Key: UML14-391
  • Legacy Issue Number: 6472
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The text states "Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62)." Figure 62 has an association and a generalization relationship, not dependencies.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6069.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change 'Part' to 'Role.

  • Key: UML14-384
  • Legacy Issue Number: 6458
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 1 specification, "every time a word coinciding with the name of some construct in UML is used, that construct is referenced." [UML 1 2.3.4]

    In the UML 2 specification, the word, 'part,' is used both to mean a Part and with its ordinary meaning.

    This is an example of a recurrent problem in the specification: words that name UML 2 concepts are used both to refer to that concept, or an instance of that concept, and with their ordinary meaning. The rule of the UML 1 specification needs to be both stated and carefully followed.
    ...

    Suggested resolution: Change 'Part' to 'Role.' This permits the use of 'part' to mean part. Add the rule of the UML 1 specification. Carefully follow that rule.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.13.2 Package Merge

  • Key: UML14-390
  • Legacy Issue Number: 6471
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 47. Some of the relationships appear to be generalization and some appear to be realization. It is not clear when Package Merge is useful or necessary. A more concrete example would help

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.5 PackageImport

  • Key: UML14-389
  • Legacy Issue Number: 6469
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    This section is unique because it does not have a Notation section like all of the others

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concurrent vs. parallel ExpansionRegions

  • Key: UML14-412
  • Legacy Issue Number: 6506
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The 3rd rev. draft of UML 2's superstructure document introduces the
    keywords "parallel", "iterative", and "stream" for ExpansionRegions
    (p.
    292).

    But the example figures given at page 296 uses "concurrent" instead of
    "parallel" without any introduction.

    Finally, the metamodel type ExpansionKind (p. 248) solely defines
    "parallel" and the other two keywords mentioned above. "concurrent" is
    completely missing.

    Sure, there is a distinction between concurrency (pseudo-parallel
    execution of processes or threads on one single CPU) and parallelity
    (parallel execution of processes or threads on multiple CPUs) but I'm
    not convinced if we should introduce this distinction at the
    specification level.

    Any ideas?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6099.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use Case Metamodel - UML2 Superstructure issue

  • Key: UML14-411
  • Legacy Issue Number: 6505
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    I tried to understand some parts of the Use Case metamodel but get
    stucked ...

    Looking at figure 10-49 (p. 468) of the current (i.d. 3rd rev)
    Superstructure document it is not clear or at least not that obvious
    to
    me how the Actor is related to the Use Case.

    The only possibility seems to be the relationship where the UseCase
    participates taking the role useCase connected to the Classifier. But
    I
    don't think that the Actor should play the role subject ...

    Further, the relationship connecting Actors with UseCases allows the
    placement of Multiplicities but users are not encouraged to use roles.
    Why is this asymmetry introduced? I could imagine situations
    (especially
    for business models) where roles would perfectly make sense even for
    Actors. This would be the case always when a actor acts on behalf of
    another entity or an actor is to be specialized w.r.t. a specific
    context.

    Any ideas?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation without - UML2 Superstructure

  • Key: UML14-420
  • Legacy Issue Number: 6514
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Page 55 of the current superstructure document lists the operation's
    syntax as "visbility name (parameter-list) : property-string" and
    states
    that "property-string optionally shows other properties of the
    operation
    enclosed in braces".

    I wondering where the good old return type or the property enclosed in
    curly brackets might have gone.

    If the "property-string" mentioned in the operation's syntax quoted
    above is the return type the possibility to add operation wide
    properties (like "query") is gone.

    If the "property-string" is the way to add properties it should be
    enclosed in curly brackets and the separation by the colon from the
    parameter list containing also the return type could be misleading.
    Hence the colon should be dropped or exchanged by another symbol.

    Or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components and artifacts: Dependency problem - UML2 Superstructure

  • Key: UML14-419
  • Legacy Issue Number: 6513
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Reading the component section of the specification I come across a
    dependency
    problem. Figure 2-9 shows a white-bix representation of a component.
    The bottom
    compartment lists the related artifacts. But the direction of
    manifest dependency
    is from the artifact as source to the component as target. So the
    component
    does not know anything about its implementing artifacts.

    In my opinion the artifacts compartment is wrong.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcitivityEdge: weight=all vs weight=null - UML2 Superstructure

  • Key: UML14-416
  • Legacy Issue Number: 6510
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    there is a mismatch in the specification.

    On p. 262 about the weight attribute on activity edges:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But Fig. 6-39 on p. 265 specifies

    {weight=all} for the same purpose.


    Which one is the correct one?


    I think {weight=all}

    is the better alternative to express the
    semantic.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6096.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Large diamond for binary associations legal? - UML2 Superstructure issue

  • Key: UML14-415
  • Legacy Issue Number: 6509
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Reviewing the current Superstructure spec I noticed that it allows the
    usage of the large diamond in the middle of an association also for
    binary associations which significantly changes to notation compared
    to
    UML 1.x

    By doing so UML class diagrams become Entity-Relationship flavoured
    but
    do not have the semantics of those notation (identity, multiplicities,
    etc.) and also the notation is still different (multiplicity,
    association name, etc.).

    Is it really intended to allow the usage of the large diamond also for
    binary associations?

    Personally, I'm quite reluctant accepting these change ...

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard conditions at fork nodes - UML2 Superstructure issue

  • Key: UML14-418
  • Legacy Issue Number: 6512
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I have a question about the token flow traffic rules within activity
    models:

    It is allowed to have guards at outgoing edges from fork nodes.
    The specification says about fork nodes:

    "When an offered token is accepted on all the outgoing edges,
    duplicates of the token
    are made and one copy traverses each edges."

    This means that the fork node offers tokens to its outgoing edges, if
    all guard
    conditions evaluates to true. So there is a dependency between the
    parallel flows
    after a fork node.

    Is that true?

    I think the fork node should offer tokens on all outgoing edges that
    accept the token.
    If there is a guard condition at an outgoing edge, it is possible
    that the flow continues
    only on two of three outgoing edges.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Token flow semantics: Implicit fork and join - UML2 Superstructure

  • Key: UML14-417
  • Legacy Issue Number: 6511
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As mentioned on p. 250 an action execution is created when all its
    object flow and control flow prerequisites have been satisfied
    (implicit
    join). Same for outgoing egdes (implicit fork).

    Is it the same semantic for object nodes?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiobject in UML2

  • Key: UML14-409
  • Legacy Issue Number: 6499
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I am looking for the multiobject in the UML2 spec.

    It is defined in the UML1.5 spec. as part of the collaboration
    diagram. The multiobject is shown as two rectangles in which
    the top rectangle is shifted slightly vertically and horizontally.

    Is this still valid for UML2? Where can I find the definition in the
    spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outputting constants

  • Key: UML14-408
  • Legacy Issue Number: 6491
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are constants introduced in a flow, eg, to output a constant to an
    activity parameter node? UML 1.5 had GetLiteralAction to output a
    constant. Reintroduce it or some construct that has the same effect.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue

  • Key: UML14-414
  • Legacy Issue Number: 6508
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    While trying understand the jungle of diagrams offered by UML I
    probably
    discovered an inconsistency within the most recent Superstructure
    document.

    Page A-546 shows a class digram giving a taxonomy of structure and
    behavior diagrams. The figure (numbered A-5) is accompanied with some
    descriptive text at the same page.
    The diagrams includes a box (class) for a diagram called the
    "collaboration diagram" which is not mentioned in the document set
    elsewhere. But the text mentiones a "communication diagram" which is
    completely missing in the figure.

    Additionally, shouldn't the "protocol state machine" be shown as a
    specialization of the "state machine diagram"?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binary associations decorated with large diamonds legal?

  • Key: UML14-413
  • Legacy Issue Number: 6507
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Superstructure document states that "Any association may
    be
    drawn as a diamond ...". This changes the behavior present in UML 1.x
    significantly which only allowed the diamond for n-ary (n>2)
    associations.

    As a consequence of this change a UML diagram may look more like an
    Entity-Relationship model with some changes (placement of the
    association's name, multiplicity notation, and all the semantics)
    than a
    upward compatible UML digram.

    Is this intended?

    I tend to retain UML's former behavor to allow the large diamond only
    for n-ary associations.

    Any ideas or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Protocol machines do not subset state invariant

  • Key: UML14-407
  • Legacy Issue Number: 6490
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Protocol machines subset guards, but not state invariant. What's the
    difference?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conditions for parameter sets (02)

  • Key: UML14-406
  • Legacy Issue Number: 6488
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Parameter sets need conditions for pre/postconditions

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ActivityFinalNode and running actions - UML2 Superstructure issue

  • Key: UML14-410
  • Legacy Issue Number: 6504
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Reaching an ActivityFinalNode terminates the activity.
    What happens to running actions within the activity?

    Is there an interruption? Or do they run to completion?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

adopt a single notation to specify text strings used in the notation

  • Key: UML14-518
  • Legacy Issue Number: 7135
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three different ways to specify text strings used in the notation and two variations.

    The three ways:

    1. a sort of Bakus-Naur form as in: multiplicity ::= <multiplicity_range> [ ‘

    {‘ <order_designator> ‘}

    ’ ] see Super 7.4.1

    2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [

    { property-string }] see Super 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown.

    3. a third way, combining features of both as in: visibility name ‘<‘ template-parameter-list ‘>’ ‘<<‘binding-expression-list ‘>>’‘( ‘ parameter-list ‘)’ ‘:’ property-string see Super 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.)

    Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }

    ] {{ [ name ] ‘:’ classname } | name } [ ‘[‘ multiplicity ‘]’ ] see Super 17.5.7

    The two variations:

    a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [

    { property-string }

    ] see Super 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see Super 7.10.1

    b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see Super 7.10.1

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A of the superstructure spec

  • Key: UML14-517
  • Legacy Issue Number: 7125
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Appendix A of the superstructure spec specify the usage of frames
    in diagrams. The text says:
    "Each diagram has a frame, a contents area, and a heading, see Figure 460."

    This statement implies that frames are normative. The text later says
    that "In cases where not needed, the frame may be omitted and implied by the border of the diagram area provided by a tool."

    This entire explanation distorts the common intent and practice of UML
    diagramming. Text should present the frames as an optional presentation
    option in the first place. Also, in all cases mentioned (ports, entry points)
    it is possible to notate the context using class boxes or states, so in none of these cases frames are "needed". It is a mere presentation option that might be

    used as an alternative to using prime container symbols.

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / Fig.192 constraint duplicated

  • Key: UML14-516
  • Legacy Issue Number: 7099
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In Fig. 192 on pg. 277, the association end StructuredActivityNode::activity, the constraint

    {redefines activity}

    is duplicated

  • Reported: XMI 2.0 — Fri, 5 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of isStatic - resubmission of issue 4446

  • Key: UML14-515
  • Legacy Issue Number: 7098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6974

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / Invalid subsetting for enclosingOperand

  • Key: UML14-514
  • Legacy Issue Number: 7069
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious model consistency issue with InteractionFragment::enclosingOperand because it is currently constrained to be a subset of NamedElement::namespace, but its type (InteractionOperand) is not a specialization of Namespace. Also, InteractionOperand::enclosingInteraction does not subset NamedElement::namespace (it probably should; Interaction is already an indirect specialization of Namespace).

    The simplest solution is to make InteractionOperand a specialization of Namespace

  • Reported: XMI 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / makesVisible () operation incorrect

  • Key: UML14-513
  • Legacy Issue Number: 7068
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there appears to be a bug in the specification with respect to the definition of the makesVisible() OCL query on packages. Here is the OCL expression from the specification (page 100):

    Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
    pre: self.member->includes(el)
    makesVisible = el.visibility->isEmpty() or el.visibility = #public

    As you can see, this definition makes even imported elements visible based on their own visbility rather than the visibility of the import
    relationship. The same applies to elements made visible indirectly via a package import.

  • Reported: XMI 2.0 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition

  • Key: UML14-512
  • Legacy Issue Number: 7056
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is an issue with the hasVisibilityOf(NamedElement) operation on Classifier. In particular, it doesn't consider visibilities when determining if a member is visible:

    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf =true

    One might logically expect the operation to exclude, for example, members with private visibility.

  • Reported: XMI 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and derived attributes

  • Key: UML14-526
  • Legacy Issue Number: 7219
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()Â… what makes the lowerBound() operation required?

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of stereotypes

  • Key: UML14-525
  • Legacy Issue Number: 7213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Today, the reason for this mail is that in my UML certification I was asked a question regarding the include and extend relationship between use cases.
    I was (and am still a bit) confused, because one question was dealing with the extend and include notation between use cases. I think the 640 pages UML 2 documnet 03-08-02.pdf is inconsistent here. (I now ask because I think I lost two correct answers in my fundamental UML 2 certification caused by include/includes and extend/extends...): UML 1 used the stereotype notations "extends" and "includes". Im UML 2, the classifiers are now called "include" and "extend". But confusingly enough, some association arrows inside the OMG document 03-08-02.pdf
    "UML Superstructure 2.0 Draft Adopted Specification" use the stereotypes (see <<extends>> and <<includes>> in Fig 406 p. 521 and twice <<extends>> and one time <<includes>> in Table 22 on page 523/524.)

    Who to report these inconsistencies to? Or are the stererotypes still allowed to be labeled <<extends>> and one time <<includes>> ?

  • Reported: XMI 2.0 — Fri, 26 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6465.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Appendix A / Typos

  • Key: UML14-524
  • Legacy Issue Number: 7162
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    p587 para 2 line 2 "UML diagrams contains graphical elements" (should be "contain")
    p587 para 5 line 1 "symbols defines the type" (should be "define")
    p587 last para "C1 and C1" (should be "C1 and C2")
    p588 para 1 line 2 "a graphical symbols" (should remove "a")
    p588 para 1 line 4 "assocition"

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Alternative with all false guards

  • Key: UML14-523
  • Legacy Issue Number: 7160
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Semantics of the alternative CombinedFragment (page 410) does not describe what happens if all branches are guarded, and
    all guards are false.
    Does this means: a) empty trace, or b) (dynamically) invalid trace ?
    I suggest to add a sentence, defining such traces as dynamically invalid.
    This will be consistent with the behavior of a ConditionalNode in Activities (page 313): "if no test section yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node".

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Classes chapter organization

  • Key: UML14-522
  • Legacy Issue Number: 7159
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Classes chapter is organized differently from all other chapters in the document – it should be made consistent with the organization of all the other chapters

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / State machines / incorrect navigation specifications

  • Key: UML14-521
  • Legacy Issue Number: 7158
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 354 on page 457, it is shown that it is not possible to navigate back from Region towards either the state machine that owns it or the state that owns it. However, it is often necessary to know who the owner of a region is, therefore these associations need to be made navigable in both directions.

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / consistent formatting conventions

  • Key: UML14-520
  • Legacy Issue Number: 7157
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Different chapters in different parts of the spec use different conventions for naming, headings, layout etc. These should all be made consistent based on one shared convention.

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is resolved by the resolutions to issue 6958 and 7190.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Dcoument conventions

  • Key: UML14-519
  • Legacy Issue Number: 7156
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The document needs an explanation of how it is laid out and how the format and meaning of the various sections in the individual class descriptions

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML14-528
  • Legacy Issue Number: 7221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In my interpretation of the current semantics description of UML
    activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
    have identified some rather unpleasant properties of the current
    traverse-to-completion semantics. The full discussion together with
    examples can be found in the attached .pdf, the short of it is:

    *) the current semantics does not prevent deadlocks (as it is
    supposed to do)

    *) it rather induces deadlocks even in simple examples (e.g. examples
    in the UML spec are wrong)

    *) it makes for a very complex evaluation and introduces unnecessary
    synchronization in the (basically asynchronous) notation of Activiy
    Diagrams.

    I therefore propose to relax the semantics of token flow by dropping
    the constraint that every Action has to accept all tokens for all its
    input pins at once. MergeNodes should als be able to buffer tokens
    until their conditions are satisfied. This is a more natural way of
    interpreting ADs.

  • Reported: XMI 2.0 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/Deployments/CommunicationPath

  • Key: UML14-530
  • Legacy Issue Number: 7228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 10.3.2 and Figure 125 the constraint is given that a
    CommunicationPath can only associate Nodes.
    This seems too restrictive and does not, for example, allow
    CommunicationPaths between actual servers (Instance Specifications).

    Proposed resolution:
    Relax constraint such that a CommunicationPath can link
    DeploymentTargets.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State machines / name of transitions association end

  • Key: UML14-529
  • Legacy Issue Number: 7226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::StateMachines::BehaviorStateMachines::Region::transitions should be renamed to transition (i.e. made singular) to be consistent with the naming convention for other association ends.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Structure

  • Key: UML14-532
  • Legacy Issue Number: 7231
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 178, table 6 - the entry for port shows the only option for a port as
    being on the boundary of an enclosing box whereas the notation section for
    ports (169) states that port boxes may be shown inside the boundary of the
    enclosing box. The port entry on table 6 should amended so that it includes
    all cases.

    page 179, the table is headed table 6 but should be table 7.

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1 activities

  • Key: UML14-531
  • Legacy Issue Number: 7230
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    figure 274 - should the arrow between Award Quote and Quote Responses be the
    other way round

  • Reported: XMI 2.0 — Fri, 9 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite Structures, 03-08-02.pdf

  • Key: UML14-527
  • Legacy Issue Number: 7220
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Can a connector be typed by an association one of whose ends are composite
    or shared? I can't see anything in the spec that prohibits this but I'm not
    sure that it makes a lot of sense to do so.

  • Reported: XMI 2.0 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect usage/definition of "emergence" in Common Behavior Chapter

  • Key: UML14-431
  • Legacy Issue Number: 6527
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    PROBLEM STATEMENT

    In section 13.1 of the Common Behaviors chapter, the following paragraph is
    contains an incorrect definition of "emergent behavior":
    "Emergent behavior results from the interaction of one or more participant
    objects. If the participating objects are parts of a larger composite
    object, an emerging behavior can be seen as indirectly describing the
    behavior of the container object also. Nevertheless, an emergent behavior is
    simply the sum of the executing behaviors of the participant objects."

    The current area of scientific study know as Complex Adaptive Systems, or
    Complexity Science", describes emergent behavior as "the appearance of a
    coherent pattern that arises out of interactions among simpler objects, that
    is MORE than just their summed behavior." (emphasis mine) Furthermore,
    Complexity Science expressly states that a behavior that is limited to the
    sum of its behavior is NOT emergent. (See references, below.)

    Emergence is a primary area of study at the Santa Fe Institute and has Nobel
    Laureates and MacArthur geniuses studying the effect. Therefore, I think
    that the use of the terms "emergence" (used once) and "emergent behavior"
    (used 9 times) are not correct for Common Behavior chapter. If left in,
    they will cause confusion, because the terminology is already
    well-established in both science and industry.

    PROPOSED SOLUTION
    1) Common Behavior Domain Model (Fig. 306) to contain the classed called
    BehaviorEmergence. Therefore, the class should wither be removed or another
    tem substituted.
    2) Remove, or rename, all 9 usages of "emergent behavior" if the chapter and
    appendix.

    References (to name a few) :

    Holland, J.H., Emergence: From Chaos to Order. 1998, Reading, MA:
    Addison-Wesley. (MacArthur Fellowship Genius Award)

    Gell-Mann, M., The Quark and the Jaguar: Adventures in the Simple and the
    Complex. 1994, New York: W. H. Freeman. (Nobel Laureate in Physics)

    Kauffman, S., At Home in the Universe: The Search for the Laws of
    Self-Organization and Complexity. 1995, New York: Oxford University Press.
    (Professor, Santa Fe Institute)

    Coveney, P. and R. Highfield, Frontiers of Complexity: The Search for Order
    in a Chaotic World. 1995, New York: Fawcett Columbine.

    Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and
    Chaos. 1992, New York: Simon and Schuster. (PhD in elementary particle
    physics)

    The Emergence of Everything: How the World Became Complex
    by Harold J. Morowitz

    Emergence: The Connected Lives of Ants, Brains, Cities, and Software – by
    Steven Johnson

    A New Kind of Science by Steve Wolfram

  • Reported: UML 1.5 — Sun, 9 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The node "Order cancel request" that appears in figure 6-86

  • Key: UML14-427
  • Legacy Issue Number: 6521
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    I would really appreciate an answer to the following questions
    regarding the
    3rd revised submission of UML 2.0 superstructure from April 10, which
    I hope
    is the most recent one:

    1. The node "Order cancel request" that appears in figure 6-86 (page
    304),
    and the node "Ready to award bid" and "Bid arrives that appear in
    figure
    6-39 (page 265) are of the type "Object nodes for tokens with signal
    as
    type", presented in page 316?
    If they are then there is a discrepancy between the respective
    graphical
    notation in page 316 and page 331 (table 1), and pages 304 and 265.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GeneralizationSet Description clarification - UML2 Superstructure

  • Key: UML14-426
  • Legacy Issue Number: 6520
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    On page 121 of 03-08-02 the GeneralizationSet description reads:
    7.17.3 GeneralizationSet (from PowerTypes)

    A GeneralizationSet is an AutonomousElement (from Foundation ::
    Kernel ::
    PackagingNamespaces) whose instances define

    partitioned sets of Generalization relationships.

    Description

    Each Generalization is a binary relationship that relates a specific
    Classifier to a more general Classifier (i.e., a subclass).

    For clarification, should the parenthetical read "(i.e., a subclass
    to a
    superclass). As written, it may convey to some that the subclass is
    the
    more general Classifier.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos

  • Key: UML14-429
  • Legacy Issue Number: 6523
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    page 261, on the Description of complete activities:
    "Edges support controlling token flow and be contained in
    interruptible
    regions."

    page 269, second line says "It covers invocation nodes, control nodes
    (...)". I believe it should read "It covers executable nodes, control
    nodes
    (...)"

    page 282, second line:
    "A control flow is an edge starts an activity node after the previous
    one is
    finished."

    page 286, in constraints [2]:
    "The input parameter must be the same as or a supertype the type of
    object
    token coming along the incoming edge."

    page 301, in Semantics:
    "This is equivalent interposing a CentralBufferNode between the
    initial node
    and its outgoing edges."
    page 307, second line:
    "A loop node is a costructured activity node that represents a loop
    with
    setup, test, and body sections."
    page 331, Table 2 caption should be "Graphic paths (...)" instead of
    "Graphic nodes (...)". Table 3 caption should also be made more
    specific.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Order cancel request

  • Key: UML14-428
  • Legacy Issue Number: 6522
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    2. Assuming that, for example, "Order cancel request" that appears in
    figure
    6-86 (page 304), is an object nodes with signal as type, from where
    or how
    does it get the respective token which is then subtracted by the arc
    ending
    in Cancel order?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Package Extensibility <> - UML2 Superstructure issue

  • Key: UML14-423
  • Legacy Issue Number: 6517
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When merging packages... How are associated state machines handled?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency notation for interfaces - UML2 Superstructure

  • Key: UML14-422
  • Legacy Issue Number: 6516
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Comparing figure 1-63 (Superstructure document page 92) with the text
    placed above describing it and the presentation guidelines for
    interface
    relationships (i.e. the relationships connecting an interface with its
    requiring and/or providing classes) it seems that the dashed lines
    announced in the text are gone in the figure.

    Reading the text the arrow pointing from TheftAlarm to ISensor should
    be
    realized as a dependency relationship and also the arrow pointing from
    ProximitySensor to ISensor. The latter is currently realized as a
    generalization arrow which is solely a valid presentation option for
    relationships connecting a Component and their Interface. According to
    the spec the arrow should be a dependency relationship that is
    stereotyped with realizes having ProximitySensor as client and Isensor
    as supplier.

    Or am I just misreading the spec?
    Any help and clarification appreciated

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Resolved by the resolution to issue 6069

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency concerning VisibilityKind - UML2 Superstructure

  • Key: UML14-421
  • Legacy Issue Number: 6515
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor point, but still annoying to the reader ...

    The superstructure lists at page 16 all four possible types (i.e.
    "public", "private", "protected", and "package") but within the
    Infrastructure document (page 73) solely "public" and "private" are
    mentioned. The same for the enumeration example at page 116.

    Also it would be helpful to shift the visual presentation options
    ("+",
    "-", "#", and "~") for VisibilityKind from the chapter describing
    attributes (Superstructure p. 41) to more general description at page
    16
    which is multiple referenced from other parts of the spec.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see abov e

  • Updated: Fri, 6 Mar 2015 20:58 GMT

does "is not instantiable" imply "isAbstract"? - UML2 Superstructure

  • Key: UML14-424
  • Legacy Issue Number: 6518
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor graphical typo: Page 487 of the superstructure document
    specifies an InformationItem as not instanciable. But the classifiers
    taxonomy provided at page E-565 of the same document depicts it as
    instanciable class.

    I guess it should be italicized.

    Or am I just misinterpreting the sentence "is not instanciable"? I
    guessed it implies "isAbstract == true".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity nodes and Stereotypes - UML2 Superstructure issue

  • Key: UML14-425
  • Legacy Issue Number: 6519
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The new Profiles package and the respective Stereotypes still seem
    very
    "class-oriented" when it comes to notation (maybee my fault?).
    Specifically,
    I have the following doubt:

    If I want to define a Stereotype for an activity node, e.g. a
    ForkNode, is
    the notation in the attached file correct?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing actual arguments in submachines states

  • Key: UML14-432
  • Legacy Issue Number: 6605
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A state machine, as a behavior, has formal parameters. When referencing it in a submachine state, we
    may need to pass actual arguments. However, nothing seems to be specified for that purpose in the
    UML2 metamodel. Is this a bug? If not, how can we send/retrieve data to/from a referenced submachine?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

/pages 485,487,495/mixed names for state machine diagram

  • Key: UML14-430
  • Legacy Issue Number: 6526
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 1 terminology "StateChart" and another term "state diagram" also occurs.

    Appendix A of the Superstructure spec makes it clear that the UML 2 name is "state machine diagram"

    Recommendation: All occurrences of "statechart" and "state diagram" must be replaced with "state machine diagram"

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous example of a local action on a Lifeline in Figures 334, 335

  • Key: UML14-511
  • Legacy Issue Number: 6988
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 415-6 Figures 334,335 use a rectangular box with the text "DoSth" in it. The meaning of this symbols is not explained in the corresponding section, nor in Table 14 graphical nodes in Sequence Diagrams.
    In ITU Message Sequence Charts this would mean an informal action, local to the Lifeline.

    The syntax and semantics of local actions is the key issue in "executable sequence diagrams", and in proper alignment of semantics between Interactions, Activities and State Machines (and Actions).

    As a minimum, Figures 334, 335 need to be explained, and table 14 updated.
    It would be better to illustrate formal use of Actions.
    Ideally, Interactions will benefit from a data sublanguage based on Actions, in order to have a capability to fully specify flows of data between Lifelines:

    • message parameters (including composite values)
    • local attributes (storing data in Lifeliens; in data structures like lists, sets, tables, etc.)
    • identities of objects (input and output pins for actions)
    • actions (manipulations on data, access to data structures and composite values)
    • proper usage of data in guards and state invariants
    • proper usage of data in loop expressions
  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ambiguous definition of the scope of a break CombinedFragment

  • Key: UML14-510
  • Legacy Issue Number: 6987
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 410 mentions that "Break CombinedFragments must be global relative o the enclosing InteractionFragment".

    This is ambiguous and needs to be explained in more precise way, involving InteractionOccurences and Interaction Overview Diagrams. There were debates on the scope of a similar construct in the ITU language.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/inconsistent spelling for InteractionOperator

  • Key: UML14-509
  • Legacy Issue Number: 6986
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    The enum type name InteractionOperator is often misspelt (e.g. interactionOperator or interaction operator). It is also used inconsistently when referring to a particular operator, e.g. InteractionOperator alt.
    I suggest using a single typigraphic convention:
    InteractionOperator <italic> alt </italic>

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous sentence and typo in description of EventOccurence

  • Key: UML14-502
  • Legacy Issue Number: 6979
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 416:

    The sequences of Eventoccurences are the meanings of Interactions. >>Messages are sent through either asynchronous signal sending or operation calls.<<
    Likewise they are >>>recieved<<< by >>Receptions or actions of consuption.<<

    typo needs to be corrected.
    highlighted parts need to be re-phrased and terminology aligned with the rest of the spec.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

graphic nodes for state invariant and continuation are not always distingui

  • Key: UML14-501
  • Legacy Issue Number: 6978
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    It is not possible to visually distinguish between a continuation (oval with a name) and a simple state invariant (also oval with a state name). Compare Figure 345 and 334.

    One possibility is to use guard syntax for state invariants.
    Another possibility is to use a different graphic for continuations

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of isStatic

  • Key: UML14-498
  • Legacy Issue Number: 6974
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

self-activation notation in Sequence diagrams missing

  • Key: UML14-497
  • Legacy Issue Number: 6972
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.

    E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56

    This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

  • Reported: XMI 2.0 — Fri, 6 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/rationale subsections not informative

  • Key: UML14-505
  • Legacy Issue Number: 6982
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Most sections in chapter 14 on Interactions do not have a Rationale subsection, while the remaining few only contain the text "not applicable". This is not informative.
    I suggest to remove the Rationale subsections altogether.

    Pages 414 421 423 425 428 430 433

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the empty “Rationale” sub-sections on pages 414, 421, 423, 425, 428, 430, 433.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect grammar for

  • Key: UML14-504
  • Legacy Issue Number: 6981
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Grammar for <state-info> at page 434 has a typo:
    <state-info>::=<region}

    {, <region> }*


    must be:
    <state-info>::=<region> {, <region> }

    *

    It is not clear, how to define <region-name> in Sequence Diagrams.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

word "execute" in definition of alternative CombinedFragment is ambiguous

  • Key: UML14-507
  • Legacy Issue Number: 6984
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 410 The word "execute" is used to describe the Alternative CombinedFragment i nthe context "operand will execute", etc. This word is ambiguous. I suggest changing it to "operand is chosen", etc.
    Or even the full description, like "the meaning of the InteractionOperator alt is a trace corresponding to only one of its operands".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Ambiguous description of state invariants

  • Key: UML14-506
  • Legacy Issue Number: 6983
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 433 has the following text: "A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of >>eventual attributes<< of the Lifeline".

    The term >>eventual attribute<< may be ambiguous.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect text and table title for Table 19

  • Key: UML14-500
  • Legacy Issue Number: 6977
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 450 has the following text:
    "The graphic nodes that can be included into >>structural diagrams<< are shown in Table 19". Table 19 has the following title "Graphic nodes and paths included in >>sequence diagrams<<"

    The text needs to be changed into "The graphic nodes >>and paths<< that can be included into >>timing diagrams<< are shown in Table 19"

    Title of Table 19 should read "timing diagrams" instead of "sequence diagrams".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect text before Table 14

  • Key: UML14-499
  • Legacy Issue Number: 6976
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 436 has the following text:
    "The graphic nodel that can be included in >>structural diagrams<< are shown in Table 14."

    Table 14 is called "Graphic nodes included in sequence diagrams".

    Text needs to be changed into "sequence diagrams"

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6934, already resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect spelling of EventOccurence

  • Key: UML14-503
  • Legacy Issue Number: 6980
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    There are multiple places in the Interaction section, where class name EventOccurence is spelt incorrectly (usually as Eventoccurence).

    pages 403 410 411 416 417 419 420 422 427 429 431

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text differs from metamodel for critical region InteractionOperator

  • Key: UML14-508
  • Legacy Issue Number: 6985
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    On page 411 subsection for Critical Region mentions the InteractionOperator "critical", while the metamodel uses the enum "region".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / incorrect property redefinition

  • Key: UML14-466
  • Legacy Issue Number: 6871
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constraints 9 and 10 in section 15.3.8 (page 470) refer to the owner property, but the owner property is redefined by Vertex::container, as shown in Figure 354 on page 457. Vertex::container should probably subset owner instead

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of issue 6626 and is resolved by the same resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / non-existent property reference

  • Key: UML14-465
  • Legacy Issue Number: 6870
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constraints 4 and 6 in section 15.3.8 (page 470) refer to the non-existent stateMachine property on PseudoState (i.e. self.stateMachine).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambuiguity in value pin evaluation

  • Key: UML14-462
  • Legacy Issue Number: 6865
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When the value specification of a ValuePin is an expression, when is the
    expression evaluated?

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 136, "BasicComponents",

  • Key: UML14-461
  • Legacy Issue Number: 6728
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    Superstructure, final adopted spec 03-08-02, page 136, "BasicComponents",
    contains this inscrutable phrase in the first paragraph:

    In addition, because a itself Class is a subtype of an
    EncapsulatedClassifier,...

    This should be fixed up in the final version, if you can
    figure out what you meant to say

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / non-existent return type

  • Key: UML14-468
  • Legacy Issue Number: 6873
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The LCA operation, defined in section 15.3.12 (page 194) has a non-existent return type, CompositeState

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / misplaced operation definition

  • Key: UML14-467
  • Legacy Issue Number: 6872
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The containingStateMachine() operation is defined in the "Additional Operations" for StateMachine (see section 15.3.12, page 491) rather than in the corrsponding section(s) for the type(s) to which it applies.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / subsetting two properties

  • Key: UML14-458
  • Legacy Issue Number: 6680
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::structuredNode subsets two properties, Activity::node and Actvity::group. This is among the few, if not the only, cases in the metamodel where a containment property subsets two superset containment properties. What is the semantic intent of this constraint? Should Activity::structuredNode be derived from the set of structured activity nodes in Activity::node and Actvity::group (StructuredActivityNode is both a group and a node)?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistent Naming

  • Key: UML14-460
  • Legacy Issue Number: 6691
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Associations with and end on the class Value Specification that subset owner have inconsistent names:

    ownerUpper

    ownerLower

    owningConstraint

    owningInstanceSpec

    owningParameter

    owningProperty

    owningSlot

    I would recommend renaming ownerUpper and ownerLower to owningUpper and owningLower to be consistent.

    All other properties that subset owner on other classes should be renamed consistently:

  • Reported: UML 1.5 — Thu, 11 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / oclIsKindOf arguments error

  • Key: UML14-464
  • Legacy Issue Number: 6869
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The syntax of the oclIsKindOf() is not correct in all occurrences. For example, constraints 4 and 6 in section 15.3.8 (page 470) use the syntax oclIsKindOf(self.stateMachine, ActivityGraph) whereas constraints 9 and 10 use the syntax owner.oclIsKindOf(Region).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Signal

  • Key: UML14-459
  • Legacy Issue Number: 6690
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    13.3.21 suggests that Signal has no additional associations, and yet in
    Figure 316 it has ownedAttribute.

    I also note that in the mdl file Signal inherits from BehaviouredClassifier
    but I can't see that on Figure 316

    If it is a BehaviouredClassifier it seems odd that it has no concrete
    BehaviouralFeatures.

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/State machines/pseudostate name consistency

  • Key: UML14-463
  • Legacy Issue Number: 6868
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The specification refers to a PseudoState type (page 469), but in the Rose model, it is named "Pseudostate".

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / invalid subsetting

  • Key: UML14-469
  • Legacy Issue Number: 6874
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UseCase::extensionPoint subsets Classifier::feature, but ExtensionPoint is not a specialization of Feature.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2

  • Key: UML14-366
  • Legacy Issue Number: 6427
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: In the definition of Connector in Chapter 3, Composite Structures, p.
    137, the "end" Association's multiplicity is 2..*. It is not clear what the
    notation should be when the multiplicity is greater than 2.

    Recommendation: Define a notation for Connectors when multiplicity is
    greater than 2, or constrain the multiplicity to be 2..2.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation

  • Key: UML14-365
  • Legacy Issue Number: 6426
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 118: The figure caption
    says that the figure is an example of connector wiring, but the text
    directly below the caption says that the figure "may be used as a notation
    option for dependency based wiring." These two statements appear to be
    contradictory.

    Recommendation: To avoid having an ambiguous notation, specify that
    dependency notation should be used for dependency based wiring. (This
    recommendation may be affected by the resolution of the issue submitted
    about semantic distinctions between different ways to wire components
    together).

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics

  • Key: UML14-367
  • Legacy Issue Number: 6428
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Connector in Chapter 3, Composite Structures,
    third paragraph of the Semantics section, which starts on p. 137 with "If
    the type of the connector is ommitted...": This paragraph is inpenetrable.

    Recommendation: Re-write the section around concrete examples for each
    point.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infras./Interactions/ execution occurrence should not be abstract

  • Key: UML14-364
  • Legacy Issue Number: 6425
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ExecutionOccurrence should not be abstract, as it has no specializations

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos

  • Key: UML14-219
  • Legacy Issue Number: 6162
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On the Description of complete activities: :Edges support controlling
    token flow and be contained in interruptible regions."

    "It covers invocation nodes, control nodes (...)". I believe it should
    read "It covers executable nodes, control nodes (...)"

    "A control flow is an edge starts an activity node after the previous
    one is finished."

    "The input parameter must be the same as or a supertype the type of
    object token coming along the incoming edge."

    "This is equivalent interposing a CentralBufferNode between the initial
    node and its outgoing edges."

    "A loop node is a costructured activity node that represents a loop with
    setup, test, and body sections." page 331, Table 2 caption should be
    "Graphic paths (...)" instead of "Graphic nodes (...)". Table 3 caption
    should also be made more specific.

    Add constraint numbers to ExceptionHandler.

    In ActivityNode, the entry for interuptibleRegion should be under a
    heading Associations (CompleteActivities).

    In semantics of ActivityEdge move sentence about guards from
    (IntermediateActivities) to basic.

    "in invoked" => "is invoked"

    Constraint 5 for ActivityParameterNode should read: "Activity parameter
    object nodes with no outgoing edges and one or more incoming edges must
    have a parameter with out, inout, or return direction."

    Text should list mustIsoloate under StructuredActivityNode, not
    ActivtyNode.

    Local pre/postcondition semantics: "must" => should.

    Local pre/postcondition semantics: "locaprecondition" =>
    "localPrecondition".

    Semantics of streaming parameter, third bullet/execution rule: replace
    "activity" with "behavior". Also in second bullet, remove "for" from
    "that is, for all". Also add analogous sentence after "not just at the
    beginning" for outputs.

    Search on "wil exist", replace with "will exist".

    Search on "(str-adv)" and remove.

    In ConditionalNode: "the modeler asserts that at least one true section
    will yield a true value." Should be "test section".

    IsReadOnly is in basic activities in the metamodel diagrams, but should
    be in complete, according to the attribute list on Activities.

    In ReclassifyObjectAction and elsewhere, replace "error" with "undefined
    semantics".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.4.1 Multiplicity

  • Key: UML14-225
  • Legacy Issue Number: 6169
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Options

    The BNF for the syntax for the multiplicity string seems to have a couple of things wrong. First, the 'lower' is specified as an 'integer' whereas it is specified to be unlimited natural from Notation part. Second, it does not allow for multiplicities to include a uniqueness designation. The first sentence defining the 'multiplicity' non-terminal only contains <order_designator> and does not include <uniqueness-designator>. Also, if both a uniqueness designation and order designation are specified the BNF should probably specify a delimiter (as in Figure 11). Perhaps the following:

    multiplicity ::= <multiplicity_range> [ '{' <order_designator> | <uniqueness_designator> |

    {<order_designator> ',' <uniqueness_designator>}

    '}' ]

    In addition, the multiplicity specification for Purchase is different between Figure 11 and 12, the former uses a comma to separate ordered and unique and the latter seems to be missing the comma.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.1 ElementImport

  • Key: UML14-224
  • Legacy Issue Number: 6168
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The next to last sentence states: "A member may be further imported by other namespaces using element or member imports." What are member imports? Should this be package imports?

    Notation

    The difference between public import using <<import>> and private import using <<access>> is not explicitly stated, nor is an example of <<access>> given in the Examples part. My understanding is that <<import>> adds an element to importing namespace using public visibility, i.e., the imported element can be accessed without qualification within the importing namespace and any namespace the importing namespace encloses. My understanding of <<access>> is that it adds an element to the importing namespace using private visibility which does not allow the imported element to be further imported. Does the last sentence of the Description, "It is also possible to control whether the imported element can be further imported", refer to <<access>> element import?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify that profiles can contain model libraries

  • Key: UML14-218
  • Legacy Issue Number: 6161
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of <<modelLibrary>> says it is:

    A package that contains model elements which are intended
    to be reused by other packages. A model library differs from
    a profile in that a model library does not extend the
    metamodel using stereotypes and tagged definitions. A
    model library is analogous to a class library in some
    programming languages.

    However, profiles can contain model libraries. UML 1.x has an explicit
    dependency to model this (called <<modelLibrary>> also). It should be
    clarified that in 2.0 this is done by including model library pacakages
    in profile packages. The above text should be clarified. Suggestion:

    A package that contains model elements which are intended to be
    reused by other packages. A model library can be contained in a
    profile package, but the classes in a model library are not
    stereotypes stereotypes and tagged definitions extending the
    metamodel. A model library is analogous to a class library in some
    programming languages.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for anonymous instance

  • Key: UML14-217
  • Legacy Issue Number: 6160
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the notation for anonymous instance

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure 03-08-02: Loop node notation missing

  • Key: UML14-221
  • Legacy Issue Number: 6165
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the loop node on page 341 is missing.
    I saw the notation in an older version of the specification

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 -- typos

  • Key: UML14-220
  • Legacy Issue Number: 6164
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 32, 2nd/3rd semantics paragraph
    "element" instead of "ele-ment" (twice)
    "qualified" instead of "qual-ified"

    p.38, presentation options:
    "identifies" instead of "identi-fies"

    p. 108, fig. 53:
    "<<dependencyName>>" instead of "<<dependecyName>>"

    p. 109, fig. 54:
    "An example of a instantiate dependency" instead of "An example of a instantiatedependency"

    p. 110, Description:
    First and second paragraph are the same.

    p. 114, 3rd line:
    "...mapping to a property of..." instead of "...mapping to a propertyof..."

    p. 117, fig. 65:
    Class name is "DoorBell" instead of "oorBell"

    p. 137, last paragraph, first line:
    "...by a component that offers equivalent..." instead of "...by a component that offers that offers equivalent..."

    p. 170, first line:
    "...while the figure on the right..." instead of "...while the figure onj the right..."

    p. 172, semantics paragraph:
    Reference to ""StructuredClassifier" on page 171" seems to be wrong (twice)

    p. 325, stream description:
    "..., in order of..." instead of "..., in oprder of..."

    p. 403, last but one paragraph:
    "...UML language..." instead of "...UML languatge..."

    p. 537, PrimitiveTypes, first paragraph:
    "These include primitive types..." instead of "These includes prmitive types..."

    p. 587, paragraph below fig. 460, last line:
    "..., the heading is..." instead of "..., the headning is..."

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for attributes

  • Key: UML14-215
  • Legacy Issue Number: 6158
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The notation for attributes is given in Kernel::Classifier, but the
    abstract syntax for classifiers have no features

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property string undefined

  • Key: UML14-214
  • Legacy Issue Number: 6157
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The BNF for property-string is missing in Property and Operation. Eg,
    how are the properties delimited (a comma?)? How are property values
    shown (property-name property-value)?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceSpecification

  • Key: UML14-226
  • Legacy Issue Number: 6170
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    The first paragraph indicates that both the instance name and the classifier can be omitted from an instance specification. This informal description leads open the possibility of specifying just the colon with neither the instance name nor the classifier. Is this what is intended? BNF should be used to clarify.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a more detailed version of Issue 6160.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Instantiates stereotype

  • Key: UML14-216
  • Legacy Issue Number: 6159
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 54 (An example of a instantiatedependency) shows the instantiates
    stereotype/keyword being used as an instance-of relation, whereas the
    entry for the instantiates stereotype in the standard stereotypes table
    says "A usage dependency among classifiers indicating that the
    operations on the client create instances of the supplier".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No notation defined for suppressing attributes or operations

  • Key: UML14-223
  • Legacy Issue Number: 6167
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    There is a mention that attributes and operations may be supressed for clarity, but no mention as to how. In UML 1.4 this was shown by including '...' in the compartment, to indicate that there was more information. Is this still viable?

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation mismatch for the realization dependency

  • Key: UML14-222
  • Legacy Issue Number: 6166
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the realization dependency is described on p. 110:
    "A Realization dependency is shown as a dependency with the keyword <<realize>>
    attached to it."

    On p. 130 the Realization dependency is shown as a dashed line with
    a hollow triangle as an arrowhead.

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 3

  • Key: UML14-177
  • Legacy Issue Number: 6117
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Examples are incorrect in implying that parameter sets can replace
    merges. They are separate parameters, not a single input as would come
    from a merge.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Streaming

  • Key: UML14-181
  • Legacy Issue Number: 6121
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Separate streaming from optionality and multiple tokens being input or
    output during action execution.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 6

  • Key: UML14-180
  • Legacy Issue Number: 6120
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that semantics for paramater sets on operations is the same as
    for behaviors.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 5

  • Key: UML14-179
  • Legacy Issue Number: 6119
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Rule 2 for parameter sets conflicts with nonoptional inputs: "If a
    behavior has input parameters that are in a parameter set, then any
    inputs that are not in a parameter set must be streaming. Same for
    output parameters." Just disallow parameters not in parameter sets in
    the presence of parameter sets. Since parameters be in more than one
    set, there is no need for parameters out of a set in this case

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 4

  • Key: UML14-178
  • Legacy Issue Number: 6118
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are parameter sets notated in classes? Parameter sets can be
    referred to by their names.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outgoing edges of initial nodes

  • Key: UML14-332
  • Legacy Issue Number: 6358
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint on initial nodes that its outgoing edges can only be
    control.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port is a Property in XMI

  • Key: UML14-331
  • Legacy Issue Number: 6357
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Port is a Property in the XMI, but not in the spec. This is because in
    MDL file Port is a Property, but it is only visible in the object
    browser. It was only hidden from the diagrams instead of being deleted.
    U2P internal history live on. Search on name="Port"

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6281.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InformationFlow realization

  • Key: UML14-326
  • Legacy Issue Number: 6351
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    InformationFlow realization should be to more than relationships. It
    could be to any set of elements

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency multiplicity to CollaborationOccurrence

  • Key: UML14-325
  • Legacy Issue Number: 6350
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Figure 100 says Dependency must be in exactly one
    CollaborationOccurrence. Presumably there are dependencies that are not
    in collaboration occurrences

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The multiplicity of the end at CollaborationOccurrence should be changed to “0..1”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ports as properties

  • Key: UML14-330
  • Legacy Issue Number: 6356
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Ports should be properties (better yet parts), to participate in
    composite association when desired.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

partWithPort without ports

  • Key: UML14-329
  • Legacy Issue Number: 6355
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Seems like partWithPort should be able to connect parts of parts without
    needing to use ports. Just use partWithPort to part, connectorEnd to
    part of part. Loosen constraint 2 of ConnectorEnd to allow all parts

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6251.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Control pins

  • Key: UML14-323
  • Legacy Issue Number: 6348
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There should be a special kind of pin for control tokens. This will
    allow parameter sets to be used with control, for example. Also
    resolves issue of where control is bufferred when it is direceted at a
    join. Can be implemented as a pin that has no parameter, by making them
    the last in the ordering of pins, so no parameter corresponds to them.
    This is also a request of the SysML team.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles in fixed repositories

  • Key: UML14-322
  • Legacy Issue Number: 6347
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Do profiles working for fixed repositories in UML 2? My understanding
    is that they are at M3 now, so they wouldn't. If that's the case, then
    what is their purpose? The other feature of dynamically changing
    metaclasses is something a repository could provide if it was useful,
    instead of using stereotypes.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association end names and part types

  • Key: UML14-328
  • Legacy Issue Number: 6354
  • Status: closed  
  • Source: MITRE ( Dr. Bruce Powel Douglass)
  • Summary:

    In the notation of composite structure, are association end names
    allowed to be presented on connectors? If so, how are they
    distinguished from port type?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment location

  • Key: UML14-327
  • Legacy Issue Number: 6352
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In Deployments, the spec uses "location" as an association end name, but
    "node" in MDL file.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guards on initial nodes

  • Key: UML14-333
  • Legacy Issue Number: 6359
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Carify whether guards can be used at initial nodes.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Control at joins

  • Key: UML14-324
  • Legacy Issue Number: 6349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Where are control nodes buffered when directing control to a join?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.11.2 Association

  • Key: UML14-228
  • Legacy Issue Number: 6172
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    I cannot find where the hollow diamond notation for aggregation is specified. It is shown in Table 5 but specified in the body. Is this now called 'shared' aggregation?

    The second to last sentence states;" The notation for an attribute can be applied to a navigable association end name." By full notation is it meant the full attribute syntax specified in section 7.81. Classifier under Notation part can be used? This would allow redundant specification of multiplicity. Should it be stated that if attribute notation is used, then other types of association end adornments cannot be used?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.10.1 Operation

  • Key: UML14-227
  • Legacy Issue Number: 6171
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Semantics

    The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added).

    Notation

    BNF should be used for specifying the syntax of an operation string.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::IntermediateActivities/redundant merge error

  • Key: UML14-234
  • Legacy Issue Number: 6179
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BehaviorStateMachines/missing owningState end name

  • Key: UML14-233
  • Legacy Issue Number: 6178
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BehaviorStateMachines has association :State[0..1] c-> stateInvariant: Kernel::Constraint[0..1] is missing the owningState end name as defined in ProtocolStateMachines owningState:State[0..1] c-> stateInvariant: Kernel::Constraint[0..1]

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel::DataTypes/missing renames

  • Key: UML14-238
  • Legacy Issue Number: 6183
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AuxiliaryConstructs::Templates::Operation/extra space

  • Key: UML14-237
  • Legacy Issue Number: 6182
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::AuxiliaryConstructs::Templates::Operation had a space at the end of the class name. This causes some matching algorithms to fail

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicBehaviors/package merge issue

  • Key: UML14-232
  • Legacy Issue Number: 6177
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.15.3 Interface

  • Key: UML14-231
  • Legacy Issue Number: 6175
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Option

    In Figure 62 the relationship between TheftAlarm and ISensor should be a dependency relationship (dashed arrow) with the <<use>> stereotype rather than a unidirectional association. The relationship between ProximitySensor and ISensor should be an implementation relationship (probably same as realization consisting of dashed arrow with open arrowhead) rather than a generalization relationship (Table 5).

    Figure 63 shows attribute visibility notation for non-navigable association ends. The second from last sentence in section 7.11.2 Association under the Notation part indicates that attribute notation can only be applied to a navigable association end name.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Communications/redundant merge error

  • Key: UML14-235
  • Legacy Issue Number: 6180
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: IntermediateActivities should not merge both StructuredActivities and BasicActivities as StructuredActivities already merges BasicActivities. IntermediateActivities both merges BasicActivities and explicitly references types in it (:Clause[0..1] -> decider:BasicActivities::OutputPin[0..1]). This makes resolving the type reference for association end named decider ambiguous

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 7436

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.14.1 Abstraction

  • Key: UML14-229
  • Legacy Issue Number: 6173
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Examples

    The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Nodes/redundant merge error

  • Key: UML14-236
  • Legacy Issue Number: 6181
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.14.6 Realization

  • Key: UML14-230
  • Legacy Issue Number: 6174
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The notation of a dashed arrow with hollow arrow head at the supplier is not mentioned. However, Table 5 shows this notation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins on structured nodes 2

  • Key: UML14-195
  • Legacy Issue Number: 6136
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Is it really intended that all StructuredActivityNode's have pins, such
    as ExpansionRegions?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins on structured nodes 1

  • Key: UML14-194
  • Legacy Issue Number: 6135
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 193 - Structured nodes (CompleteStructuredActivities) shows
    StructuredActivityNode, LoopNode, and ConditionalNode inheriting from
    Action, but LoopNode and ConditionalNode already inherit from
    StructuredActivityNode (Figure 192 - Structured nodes).

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action packaging

  • Key: UML14-203
  • Legacy Issue Number: 6145
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Structured actions should depend on structured activities for
    variables. In general, actions should be in smaller packages to

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BroadcastSignalAction

  • Key: UML14-202
  • Legacy Issue Number: 6144
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether BroadcastSignalAction returns after the signals are sent
    or after they are received.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time spec text

  • Key: UML14-196
  • Legacy Issue Number: 6138
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The overview of Activity says: "The UML does not provide for the
    specification of a time metric, but only describes sequences of
    executions.", but UML does have a time model that can be applied to
    activities. Remove sentence.

    It also says: "Execution is not instantaneous, but takes place over a
    period of time." Seems like activities should be agnostic on this.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update actions for isUnique

  • Key: UML14-200
  • Legacy Issue Number: 6142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Update structural feature and associations actions for isUnique. For
    example, the semantics description of the class
    AddStructuralFeatureValueAction says: "Reinserting an existing value at
    a new position moves the value to that position (this works because
    structural feature values are sets)".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegion

  • Key: UML14-193
  • Legacy Issue Number: 6134
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why does ExpansionRegion have its own input/output metaassociations,
    rather than the ones on actions? (BTW, these associations are
    misnomers, they are not just elements). ExpansionRegion inherites pins
    from StructuredActivityNode in complete activities

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Partition semantics

  • Key: UML14-197
  • Legacy Issue Number: 6139
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that behaviors outside of actions, such as on decision nodes,
    guards, etc, that are contained in a partition, have the same semantics
    as behaviors invoked by actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity frame and parameter nodes 1

  • Key: UML14-198
  • Legacy Issue Number: 6140
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An object node with no input or no output notation should map to an
    ActivityParameterNode, so that frame isn't required.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

actions on properties that are association ends

  • Key: UML14-201
  • Legacy Issue Number: 6143
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Clarify semantics for (or lack thereof) for modifying properties that
    are association ends

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity frame and parameter nodes 2

  • Key: UML14-199
  • Legacy Issue Number: 6141
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter nodes can overlap frame as defined in the
    diagram appendix.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flows across SAN boundaries

  • Key: UML14-347
  • Legacy Issue Number: 6375
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify that control and object flows can cross SructuredActivityNode
    boundaries (we need this).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initial nodes in structured actions

  • Key: UML14-346
  • Legacy Issue Number: 6374
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify whether structured actions can have initial nodes

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameters in Features and Common Behavior

  • Key: UML14-345
  • Legacy Issue Number: 6373
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Features model (Figure 28) shows BehavioralFeature with the
    parameter association presumably derived from formalParameter and
    returnResult, whereas the Common Behavior model (Figure 312) shows
    Behavior formalParameter and returnResult derived, derived from the
    parameter association. These parameter models for operations and
    behavior should be the same.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify join specs referencing control flow edges

  • Key: UML14-342
  • Legacy Issue Number: 6369
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that join specs reference to control flow edge names as being
    boolean.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Combining joined tokens

  • Key: UML14-341
  • Legacy Issue Number: 6367
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Join nodes should have an option to combine tokens with identical
    values. For example, when joining flows created by a fork duplicating
    tokens.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcceptCallAction in SAN

  • Key: UML14-349
  • Legacy Issue Number: 6377
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    What is the behavior when a SAN contains an AcceptCallAction with no
    incoming control links. Is the accept only enabled once when the SAN
    receives a control token, or it it enabled for the lifetime of the SAN?
    Either way, how do you model the other behavior.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminating a SAN

  • Key: UML14-348
  • Legacy Issue Number: 6376
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    How do you end a SructuredActivityNode in the way that an
    ActivityFinalNode ends an Activity?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Join example

  • Key: UML14-344
  • Legacy Issue Number: 6371
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The example for join, Figure 263, doesn't make sense from a domain point
    of view. Orders aren't accepted and shipped concurrently.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify join rules

  • Key: UML14-343
  • Legacy Issue Number: 6370
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that a successful non-and join spec still combines the incoming
    tokens by the same rules as "and".

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Side effects of value specifications

  • Key: UML14-336
  • Legacy Issue Number: 6362
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether guards and other value specification can have side
    effects

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity final clarification

  • Key: UML14-335
  • Legacy Issue Number: 6361
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the effect of an activity final node when only some of the
    non-streaming output parameters have tokens.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReadSelfAction with no host

  • Key: UML14-339
  • Legacy Issue Number: 6365
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Extend ReadSelfAction to return behavior object if there is no host.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Decision behaviors on control tokens

  • Key: UML14-338
  • Legacy Issue Number: 6364
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that decision behaviors work on control tokens. Suggest that
    control tokens invoke behaviors with no input parameters. Behavior can
    use ReadSelfAction to access host if necessary

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify ReadSelfAction in activity behaviors

  • Key: UML14-340
  • Legacy Issue Number: 6366
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the semantics of ReadSelfAction for behaviors used in activities
    (decision input, etc).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard evaluation

  • Key: UML14-337
  • Legacy Issue Number: 6363
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that not all the guards are required to be evaluated, only that
    one succeed (expand on race condition sentence).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Caption typo

  • Key: UML14-334
  • Legacy Issue Number: 6360
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Caption to Figure 251 (Final node example) should be flow final
    example

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusion regarding XMI for use of stereotypes

  • Key: UML14-291
  • Legacy Issue Number: 6242
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I've been looking at Figure 458 and can't quite get it, but don't know if
    it's an issue -the problem I have is that the instance model seems to mix
    meta-levels; we have an instance of the UML (meta) class, Class and an
    instance of the user stereotype(class) Clock - yet on the diagram this jump
    in metalevels is not mentioned. I can't see how this can be the true
    Instance model. Could someone provide me with the XMI fragment that this
    figure is intended to produce - I think that this would give me more of a
    clue about what's going on.

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actors that are outside and inside the system

  • Key: UML14-290
  • Legacy Issue Number: 6241
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a fundamental problem with the Actor element.
    It is defined as
    "An Actor models a type of role played by an entity that interacts with the subject
    (e.g., by exchanging signals and data), but which is external to the subject."

    Now put your modeling focus on a subsystem. Use cases of that subsystem can have
    external subsystems as actors. Let A be an actor of a use case. A is an external subsystem.

    But now put your modeling focus on the whole system. Now A isn't an actor anymore, but
    a subsystem. The same "real world" entity is defined twice in my model: as an actor and
    as a subsystem. It depends on my modeling focus, but that's more a topic of the view and
    not of the model.

    The problem is common in business process modeling. In the BPM view a employee is a
    stereotyped class, e.g. business worker. In the system analysis view (for a system
    that should support parts of my business processes) the employee is an actor of the system.

    We solved that problem by not using actors, but stereotyped classes. But I'm not feel
    happy with that solution, because it just a workaround.

    Any ideas?

  • Reported: UML 1.5 — Tue, 9 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pgs.17 + 598/"topLevel"

  • Key: UML14-289
  • Legacy Issue Number: 6240
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Subject: topLevel standard stereotype is referred to on pg 17 and retired on pg 598.

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the complete entry for “top level” in the Glossary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor

  • Key: UML14-288
  • Legacy Issue Number: 6239
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Three sentences define actor differently. One of these (or a fourth) shold be chosen.

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Regions owning Transitions

  • Key: UML14-287
  • Legacy Issue Number: 6238
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    The multiplicity of Regions owning Transitions shall be changed from 0..1 to 1, as Transitions can only be owned by Regions

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State list

  • Key: UML14-286
  • Legacy Issue Number: 6237
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Statelist has to be done differently, as transitions outgoing from a junction point cannot have triggers

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 serious layout problems with activity diagrams

  • Key: UML14-285
  • Legacy Issue Number: 6236
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In UML 1.x you can draw several outgoing transitions from an action state
    with guard conditions. That's semantically equivalent to a decision.
    The semantic changes in UML 2.0. Several outgoing edges from an action node
    are semantically equivalent to a fork. The new semantic is absolutely ok,
    but I have problems with the notation.

    Especially in business process modelling it is common that a decision
    follows each action. Now I have to draw a decision node after each action
    node. That blows up the diagrams and makes them hard to read. With UML 2 I
    need two pages for a diagram that fits on half a page with UML 1.x.

    Is it possible to use a notational shortcut to keep the diagrams small and
    readable?
    I heard from several people that they think about workarounds for that problem.
    But I think that's the wrong way.

    Any solutions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotypes for Actions

  • Key: UML14-284
  • Legacy Issue Number: 6235
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I just recognized a change in UML 2.0 from UML 1.x.
    Stereotypes can only be attached to elements derived
    from Class. In UML 1.x a stereotype can be attached to
    elements based on ModelElement.

    Does that mean that I cannot define a stereotype for Actions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6199

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 / Typos

  • Key: UML14-283
  • Legacy Issue Number: 6234
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some more typos:

    p. 191, figure 134
    Figure 134 does not show a deployment specification.

    p. 194, Manifestation
    "A manifestation is the concrete physical unit of one..." instead of "A manifestation is the concrete physical of one..."

    p. 200, table 9
    The manifestation relationship is shown with a solid line. Notation definition on p. 195 specifies a dashed line.

    p. 228, Presentation Option, last line
    "...than the operation name,..." instead of "...than the operaiton name,..."

    p. 233, CreateObjectAction
    The definition is not quite clear. The first constraint says "The classifier cannot be abstract". But
    the description says "The semantics is undefined for creating objects from abstract classifiers."
    The last one means that abstract classifiers are allowed, but the semantic is undefined. So the constraint
    is wrong. On the other hand if the constraint is correct, the sentence about the abstract classifier
    is suerfluous.

    p. 259, TestIdentifyAction, first line
    "...are identical objects." instead of "...are identical objects.t"

    p.286, 3rd paragraph from bottom
    "An activity with a classifier context..." instead of "An activity with a a classifier context..."

    p. 304, Semantics, first line
    "When an activity is invoked,.." instead of "When an activity in invoked,..."

    p. 355, Examples
    "The diagram on the left uses a decision diamond; the one on the left uses parameter sets
    to express the same notion".
    Text refers twice to the diagram on the left. The figure 279 does not show what the text describes.

    p. 473, below figure 373
    "A choice pseudostate is shown as a diamond-shape symbol as exemplified by Figure 374".
    Fig. 374 does not show a diamond-shape symbol, but the circle notation.

    p. 497, Rationale below figure 394
    "The rationale for statemachine extension..." instead of "The rationale for statemachie extension..."

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Compliance points/confusing and redundant

  • Key: UML14-282
  • Legacy Issue Number: 6233
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain:

    There is no facility provided to indicate which particular compliance points are assumed in a given model – hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard.
    The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java.
    Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant.

    This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6248.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition

  • Key: UML14-281
  • Legacy Issue Number: 6232
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 81: Association: subsetting, generalization, redefining: Just what is the precise difference among subsetting, specialization, and redefining? The explanations are vague and don't offer distinctions or examples showing the difference. They seem to do the same thing. If there is no semantic difference, why do we have them all? This is an important thing to clarify, preferably with examples for each of the possibilities. Other people are confused about this too.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.379/anyTrigger clarifications

  • Key: UML14-280
  • Legacy Issue Number: 6231
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 379: AnyTrigger: It is obviously illegal to have 2 anyTriggers in the same state (but the specification should say that, which it doesn't). What about multiple anyTriggers in nested states? The specification is silent on this point. It should probably be allowed with the most specific state taking precedence. This is a useful situation. Need to define it in any case.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg. 556/notation for template binding inconsistency

  • Key: UML14-279
  • Legacy Issue Number: 6230
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 556: Classifier (in templates): Bound collaboration (Fig. 435): Separator should be arrow (->) not backslash () to be consistent with text on TemplateBinding on pg. 548

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg. 471/choice pseudostate notation

  • Key: UML14-278
  • Legacy Issue Number: 6229
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoState/Semanctics Choice – The text says the symbol is a diamond but the figure 374 on pg. 473 shows a circle. Probably an error in the figure but make them consistent. In UML1 it is a diamond so a circle would be a bad idea

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.471/unclear terminate state semantics

  • Key: UML14-277
  • Legacy Issue Number: 6228
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoStatel/Semancis terminate – What are the semantics of terminate? Are exit actions performed (to return to the root state) or is the object just killed outright with no clear up? Probably need a SVP. In any case, the wording is too spare. It isn't very useful as it stands with vague semantics.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.519/multiplicity semantics of use case associations

  • Key: UML14-276
  • Legacy Issue Number: 6227
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 519: UseCase – semantics of multiplicity on Actor-UseCase association not explained. State what the multiplicity means and show an example

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about InterruptibleActivityRegion

  • Key: UML14-295
  • Legacy Issue Number: 6247
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I am not sure about the semantics of the InterruptibleActivityRegion.

    If I have such a region with an Accept Event Action to wait for an
    event to terminate the region, what happens if there is no token
    flow within the region, but the event occurs?

    I think the Accept Event Action is active. I did not found another
    statement in the specification. That means that all outgoing
    egdes get tokens after event occurence.

    Normally that is not the semantic the modeler wants. Nothing should happen
    if there is no token flow in the activity region.

  • Reported: UML 1.5 — Thu, 11 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <

  • Key: UML14-294
  • Legacy Issue Number: 6246
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    medium significance

    The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities.

    This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs."

    This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction. Yet the Figure 175 says otherwise

    Suggested resolution:

    The root of this problem may be:

    a. Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed.
    b. In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages." It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages. This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages" is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction.
    c. Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two. This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept.

  • Reported: UML 1.5 — Wed, 10 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metamodel for applying a stereotype

  • Key: UML14-293
  • Legacy Issue Number: 6244
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What part of the metamodel is for applying a stereotype to a single
    element in a user model? I can only find the appliedProfile association
    for applying profiles to packages. Figure 458 shows a repository model
    for it, but doesn't give the name of the relation between a class and
    the Clock stereotype.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the solution to issue 6347.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association not affecting ends

  • Key: UML14-292
  • Legacy Issue Number: 6243
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Restore UML 1.x capability of modeling associations without modifying
    the end types. This is needed for database modeling, for profiles to be
    used with fixed-schema repositories, and is the differentiator of UML
    over OWL, etc.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.427/missing notation description for lifelines

  • Key: UML14-275
  • Legacy Issue Number: 6226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 427: Lifeline/Notation—need to add text stating that multiple activation rectangles (overlapped and offset) may be used to represent recursion. This shows in some examples but not in the text.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.429/incorrect constraint for Message

  • Key: UML14-274
  • Legacy Issue Number: 6225
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 429: Message/Constraint 5: It says that relations sendEvent and receiveEvent are mutually exclusive. The rest of the entry suggests that they are normally both present. The constraint appears erroneous

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.416/incorrect multiplicities for event occurrence

  • Key: UML14-273
  • Legacy Issue Number: 6224
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 416: Associations EventOccurrence::startExec and finishExec should have multiplicity * as in figure 328 on pg.407

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.395/multiple meaning of exception

  • Key: UML14-272
  • Legacy Issue Number: 6223
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.235/missing semantics of destroy action

  • Key: UML14-271
  • Legacy Issue Number: 6222
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 235: DestroyAction: Must destroy links involving the object, at least, as they no longer have valid referents after the destruction. This is needed even if parts are not destroyed automatically. It is part of the essential semantics of links and objects, not an optional semantic variation point (as automatic part destruction is).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.130/incorrect stereotype name

  • Key: UML14-270
  • Legacy Issue Number: 6221
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: – private package import shown as «use» in chart, but should be «access» according to previous text for private import

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.109/Permission redundant

  • Key: UML14-267
  • Legacy Issue Number: 6218
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 109: Permission – this used to be a superclass of access and import. Doesn't serve a useful purpose otherwise. It now seems to be a useless relict. Get rid of it. There is no need to give "permission" to access another element—the fact of the access itself means that you meant to do it. Giving "permission" is more of a tool thing to prevent errors, not a modeling thing. In any case, it now seems obsolete.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.64/Classifier redefinition notation

  • Key: UML14-265
  • Legacy Issue Number: 6215
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a <redefines> statement

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.95/attributes in data types clarification

  • Key: UML14-266
  • Legacy Issue Number: 6217
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 95: DataType::ownedAttribute – is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.99/misnamed "packageMerge" attribute

  • Key: UML14-268
  • Legacy Issue Number: 6219
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 99: Packages Diagram – association to PackageMerge should be called packageMerge, not packageExtension (as in text on pg. 100)

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is addressed by the proposed resolution to Issue 6190

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.130/missing notation explanation

  • Key: UML14-269
  • Legacy Issue Number: 6220
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: Realization/Notation –dashed generalization notation is not mentioned, but it is shown in the chart on pg. 130. Add it to the text

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.79/underlined operation syntax missing

  • Key: UML14-264
  • Legacy Issue Number: 6214
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 79 Operation/Notation: Syntax for operation does not show underlining but example does show it.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageMerge (from Kernel)

  • Key: UML14-312
  • Legacy Issue Number: 6279
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    A package merge defines how one package extends another package by merging their contents.

    Description

    A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable.

    This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions.

    It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified."

    The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set.

    This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with .

    This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extendedÂ…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name."

    Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards .

    A reductio ad absurdum argument can be posed, as follows:

    Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2.

    Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1.

    If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2.

    Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T.

    Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source.

  • Reported: UML 1.5 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence diagram conditions on Message arrows

  • Key: UML14-311
  • Legacy Issue Number: 6278
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Sequence diagrams in UML 1.x supported a conditional expression to a
    message arrow that was inadvertently omitted from the UML 2.0 Superstructure
    specification. This annotation enabled the modeler to – in essence –
    place guards on messages. Such guards, or more properly ConditionalActions,
    would be evaluated at run time to determine which message arrow(s) would be
    executed. In particular, the UML 1.5 Superstructure document specifies the
    following:

    -In Section 3.60.5.1: "Any condition ... expression attached to the arrow
    becomes, in a detailed action model, the test clause action in a
    ConditionalAction ... in the dispatching Procedure.

    -In section 3.63.2: "An arrow may also be labeled with a condition and/or
    iteration expression."

    -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single
    point, each possibly labeled by a condition. Depending on whether the
    conditions are mutually exclusive, the construct may represent
    conditionality or concurrency."

    -In 3.72.2.4: "A condition represents a Message whose execution is
    contingent on the truth of the condition clause. The condition-clause is
    meant to be expressed in pseudocode or an actual programming language; UML
    does not prescribe its format. An example would be: [x > y]."
    A "branch" condition, or ConditionalAction, is expressed in the form:
    Œ[¹ condition-clause Œ]¹

    Recommendation:

    The UML 2.0 Superstructure FTF team should determine how to reinstate
    ConditionalActions for Sequence Diagrams, given the new abstract syntax for
    Sequence Diagrams. There are two reasons for this:
    1) To maintain backward compatibility with UML 1.0 through 1.5 is important.
    2) Pragmatically, it offers a graphically simple technique to express
    messaging situations that involve branching. Granted, the ALT operation
    supports the equivalent notion; however, it comes with a graphical
    complexity that is not always desired.

    Discussion:

    {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't}
  • Reported: UML 1.5 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Instances

  • Key: UML14-319
  • Legacy Issue Number: 6317
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf

    In Figure 120, "l1", which I believe is an InstanceSpecification appears to
    be nested inside another (anonymous) InstanceSpecification, ":Car". However,
    looking at the metamodel for Instances, one InstanceSpecification cannot own
    another. So, in the repository for the diagram in Figure 120, which model
    element owns the InstanceSpecification "l1"? This is important because for
    example when it comes to delete ":Car" how does the repository know to
    delete "l1"?

  • Reported: UML 1.5 — Wed, 15 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Ports

  • Key: UML14-318
  • Legacy Issue Number: 6316
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf:

    This from the descrciption of Ports(p169):
    "For a behavior port, the instance of the owning classifier will handle
    requests arriving at this port (as specified in the behavior
    of the classifier, see Chapter 13, "Common Behaviors"),"
    Is how this works a semantic variation point - if so then it should say so.

    IMO, the very least we should allow is that Port can participate in an
    Association so that its class can have an association end that points to its
    parent, and so can delegate behaviour appropriately

  • Reported: UML 1.5 — Tue, 14 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recommendation for InteractionOccurrences

  • Key: UML14-310
  • Legacy Issue Number: 6264
  • Status: closed  
  • Source: Northrop Grumman ( Brian Willard)
  • Summary:

    Recommend for InteractionOccurrences be equated to ActivityNodes of Activity
    Diagrams rather than ObjectNodes as currently specified. This spec
    reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447):

    Interaction Overview Diagrams are specialization of Activity Diagrams that
    represent Interactions Interaction Overview Diagrams differ from Activity
    Diagrams in some respects.
    1. In place of ObjectNodes of Activity Diagrams, Interaction Overview
    Diagrams can only have either (inline) Interactions or
    InteractionOccurrences. Inline Interaction diagrams and
    InteractionOccurrences are considered special forms of ActivityInvocations.

  • Reported: UML 1.5 — Fri, 26 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / No way to model reply messages

  • Key: UML14-309
  • Legacy Issue Number: 6263
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is no direct way to specify a "reply" message in the UML metamodel for Interactions – even though there is a notation for this concept (dashed arrow).

  • Reported: UML 1.5 — Fri, 26 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of Component on page 137

  • Key: UML14-321
  • Legacy Issue Number: 6338
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description of Component on page 137 says that the provided and required
    interface associations are derived both directly, from implement and use
    dependencies, and from realizing classifiers and owned ports. What isn't
    clear to me is whether the cup and ball notation can be used for all
    provided and required interfaces, or just for those directly implemented and
    used. If it can be used for all then it isn't clear whether you can
    distinguish between direct and derived interfaces. However, I note on Figure
    89 that /orderedItem is preceded by a slash - is that how the difference is
    notated?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 61

  • Key: UML14-320
  • Legacy Issue Number: 6337
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 61 - shows a ball connected to a cup, but this notation is not shown
    in the Diagrams section (7.18). It's not clear whether this is actually an
    Assembly Connector, or some other concept. The spec should be clear on
    whether this is an additional notation or not.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.super (or infra)/Profiles-Stereotype (18.3.7)

  • Key: UML14-313
  • Legacy Issue Number: 6280
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram
    customization mechanism

    This feature was supported in UML1.4 by an attribute called "icon:string".
    At the time of the design of the Profile metamodel for UML2.0, it has been
    argued this this was a mechanism to be treated by the diagram interchange
    proposal. To my knowledge, this is not the case, or if it is this is not
    eplained.
    This is at least a backward compatibility issue
    Two options can at least be envisaged :
    1 if that is supported by the global "2.0" specifications, explain in the
    profile chapter how
    2 introduce back this "icon:string" attribute. In that cas, thenotation
    ch^pter has to be extended to explain how this icon can be displayed, and
    how multiple stereotype can be handled.

  • Reported: UML 1.5 — Wed, 1 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Components & Deployment chapters missing OCL constraints

  • Key: UML14-317
  • Legacy Issue Number: 6315
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The constraints in the Component and Deployment chapters are expressed in verbal English. They should ideally also be represented in OCL

  • Reported: UML 1.5 — Mon, 13 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Profiles

  • Key: UML14-316
  • Legacy Issue Number: 6310
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In figure 446, only packages that specialise Constructs::Package can contain
    a Profile Application. Whereas I think that the packages to which we need to
    apply profiles are those packages that specialise Kernel::Package

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Structures

  • Key: UML14-314
  • Legacy Issue Number: 6281
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Divergence between XMI/MDL and the PDF/FM
    The XMI and MDL files for UML 2 super both state that Port is a subclass of
    Property and yet the appropriate diagram in the spec (fig 97) doesn't - this
    fragment of the adopted XMI spec illustrates the point:

    <ownedType xsi:type="cmof:Class"
    xmi:id="_UML_CompositeStructures_Ports_Port" name="Port"
    > > superClass="_UML_CompositeStructures_InternalStructures_Property
    > > _UML_CompositeStructures_InternalStructures_ConnectableElement
    > > _UML_Classes_Kernel_StructuralFeature">

  • Reported: UML 1.5 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The resolution of issue 6356 removes this problem.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructur 03-08-02: Notation for ConditionalNode is missing

  • Key: UML14-308
  • Legacy Issue Number: 6261
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Notation and Presentation Options sections of
    the ConditionalNode are empty (p. 315).

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071 (Conditional Node and Loop Node notation missing

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Kernel::Classifier

  • Key: UML14-315
  • Legacy Issue Number: 6309
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 03-08-02.pdf, page 62, attribute should be /attribute

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.78/missing return types syntax

  • Key: UML14-263
  • Legacy Issue Number: 6213
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    78 Operation/Notation: Syntax for operation omits the return types

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same as issue 5951 and has been solved by the resolution to issue 7315.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.78/operation redefinition

  • Key: UML14-262
  • Legacy Issue Number: 6212
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 78 Operation/Constraints: Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements

  • Key: UML14-258
  • Legacy Issue Number: 6208
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Properties UseCase::extend and UseCase::include subset property Namespace::ownedMember, but classes Extend and Include are not types of NamedElement

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing namespaces for metaclasses

  • Key: UML14-257
  • Legacy Issue Number: 6207
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious namespaces:

    ActivityPartition
    ConnectionPointReference
    Duration
    InstanceValue
    Interval
    LiteralBoolean
    LiteralInteger
    LiteralNull
    LiteralString
    LiteralUnlimitedNatural
    OpaqueExpression
    Pesudostate
    State
    TimeExpression
    Transition

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/Mis-named Manifestation class

  • Key: UML14-254
  • Legacy Issue Number: 6204
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of class Manisfestation is misspelled; it should be "Manifestation"

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Correct the typo in figure 124 FAS.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Templates/missing return type

  • Key: UML14-253
  • Legacy Issue Number: 6203
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    OCL operation UML::AuxiliaryConstructs::Templates::TemplateableElement::parameterableElements() is missing a return type

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Spec/completing mandatory sections

  • Key: UML14-261
  • Legacy Issue Number: 6211
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new OMG document structure requires certain mandatory sections (Scope, Confromance, Normative References, Terms and Definitions, and Symbols). Since these sections were not in the original submissions spec (or at least not in the form expected by the new OMG document structure), they need to be completed by the FTF.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::CommonBehaviors/redundant class?

  • Key: UML14-252
  • Legacy Issue Number: 6202
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class UML::CommonBehaviors::Communications::Call is in the model, but does not participate in any associations, is not referenced, and does not appear in any diagrams

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Delete the above-mentioned class from the mdl file.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing owners for metaclasses

  • Key: UML14-256
  • Legacy Issue Number: 6206
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious owners:

    AnyTrigger
    CallTrigger
    ChangeTrigger
    InformationFlow
    PrimitiveFunction
    SignalTrigger
    TimeTrigger

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/mis-spelled implementingClassifier"

  • Key: UML14-255
  • Legacy Issue Number: 6205
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of property Implementation::implementatingClassifier is misspelled; it should be "implementingClassifier".

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing source and target for InformationFlow

  • Key: UML14-260
  • Legacy Issue Number: 6210
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class InformationFlow specifies neither its source(s) nor its target(s).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ProtocolStateMachines/ProtocolStateMachine not a type of Feature

  • Key: UML14-259
  • Legacy Issue Number: 6209
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Property Interface::protocol subsets property Classifier::feature, but class ProtocolStateMachine is not a type of Feature

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Protocol state machines are not pre/postconditions

  • Key: UML14-209
  • Legacy Issue Number: 6152
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text in the semantics of ProtocolStateMachine says:

    The protocol transition can always be translated into pre and post
    conditions of the associated operation. For example, the transition
    in Figure 9-13 specifies that:

    1. the operation "m1" can be called on an instance when it is in
    the state S1 under the condition C1,

    2. when m1 is called in the state S1 under the condition C1,
    then the final state S2 must be reached under the condition
    C2.

    The above translation is not possible by the definition of protocol
    machines. Protocol machines are a client-side view, independent of the
    the internal behavior machine of the instance. This means the protocol
    states are not necessarily the same as the internal states of the
    intance. The protocol machine is keeping track of the operations that
    have been called to enforce and order, but the internal behavior machine
    may or may not be the same. If they are the same, there would be no
    purpose to the protocol machine.

    The spec actually makes the same point at the beginning of the semantics of
    PSM:

    Using pre and post conditions on operations is a technique well
    suited for expressing such specifications. However, pre and post
    conditions are expressed at the operation level, and therefore do
    not provide a synthetic overview at the classifier level. Protocol
    state machines provide a global overview of the classifier protocol
    usage, in a simple formal representation.

    That is, If PSM's were easiy mappable to operation pre/postcondtions,
    there would be no point to having PSMs.

    Suggested change to the text:

    A protocol state machine could in theory be translated to pre- and
    postconditions on operations, but the conditions would need to account
    for the operation call history on the instance, which may or may not
    be straightforwardly represented by its internal states. A protocol
    machine provides a direct model of the state of interaction with the
    instance, so that constraints on interaction are more easily
    expressed.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace "initial value" with "default value".

  • Key: UML14-212
  • Legacy Issue Number: 6155
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    "Default values" should be called "initial values", for example in
    property values. Defaults are values that are assumed if no value is
    available on the instance. This can be at any time during the life of
    the object. An instance may have a value for a property at one time and
    when the value is removed, the default takes over until another value is
    given.

    The current semantics is that the "default" value is put in the property
    only when the object is created. If the value is later removed, the
    "default" value does not return. This is normally called an "initial
    value".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeObservationAction can't return values

  • Key: UML14-211
  • Legacy Issue Number: 6154
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    TimeObservationAction says it returns a value, but it is a kind of
    WriteStructuralFeatureAction, which doesn't return values. Does it
    write the value to a structural feature? I assume the semantics should
    be more like DurationObservationAction

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diamond notation for merge junctions

  • Key: UML14-208
  • Legacy Issue Number: 6151
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Merge junctions should have a diamond notation option, for readability
    and backward compatibility

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity attributes on Behavior

  • Key: UML14-207
  • Legacy Issue Number: 6149
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The attributes of Activity defined in CommonBehavior look like they
    belong on Behavior.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Kernel::Classifier missing "attribute"

  • Key: UML14-213
  • Legacy Issue Number: 6156
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Kernel::Classifier lists the feature "attribute", and gives semantics
    and notation, that isn't shown in the abstract syntax for
    Kernel::Classifier. There isn't an "attribute" in the MDL file.

    Kernel::Classes abstract syntax refers to "attribute" in the subsetting
    of ownedAttribute.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions view of state machines/activities

  • Key: UML14-210
  • Legacy Issue Number: 6153
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Interactions should be able to show a message passing view on a state
    machine or activity, by referring directly to the invocation actions in
    those models. UML 1.4 worked this way.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concrete Behavior

  • Key: UML14-206
  • Legacy Issue Number: 6148
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Behavior should be a concrete class so behaviors can be defined without
    committing to which model will be used to specify them later

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite structure dependent on Behavior

  • Key: UML14-204
  • Legacy Issue Number: 6146
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Composite structure uses Classifier from Communications, but composite
    structure should be usable without behavior.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Complex port

  • Key: UML14-205
  • Legacy Issue Number: 6147
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ComplexPort is referred to in Diagrams section of composite structures,
    but it is not in the metamodel.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / no create message

  • Key: UML14-307
  • Legacy Issue Number: 6260
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I am trying to find a mechanism to create a message that represents creation of lifeline. It used to be modeled as a relationship 'action' between Message and Action in UML 1.4.

    Note: There is a mechanism in UML 2 to create a message that represents destruction of lifeline. Its modeled as 'Stop' metamodel element.

    Shouldn't we have something symmetrical to represent creation of lifeline message?

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Primitive Types / implementation issue

  • Key: UML14-306
  • Legacy Issue Number: 6259
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects.

    As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them.

    There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2.

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML super/Section 2/Compliance points

  • Key: UML14-296
  • Legacy Issue Number: 6248
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The actual compliance levels as given on p. 1 ("no", "partial", "compliant", "interchange") are inadequate.

    For example, it is unclear what it means to "comply to the semantics", since semantics is generally stated in the proposal in terms of the system being modeled. Does a tool that simply provides a way to draw syntactically well-defined UML diagrams "comply to the semantics"?

    Furthermore, it is also unclear what it means to "comply to abstract syntax". What about a tool that presents the notation, but does not use the abstract syntax as its internal representation? Would such a tool only be able to claim "partial compliance", even if it provides 100% of the UML notation? If not, what is the criteria for compliance with abstract syntax?

    Even more problematic, XMI compliance is only required at the "interchange" level, which also requires compliance to abstract syntax, notation and semantics. This would seem to exclude any tool that processes XMI, but does not use the notation-for example, an execution engine that runs off XMI input or a tool that configures itself using an XMI-formatted UML model. There should be a way to claim XMI compliance without being a full modeling tool.

    In general, the compliance levels do not seem to be defined in a way that will be useful for the range of tools that may want to usefully claim UML compliance.

    Recommendation:

    The 2U proposal (ad/2003-01-08) contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. The UML 2.0 specification as adopted should compliance discussion based on the 2U approach.

  • Reported: UML 1.5 — Thu, 11 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defenition of redefines?????

  • Key: UML14-300
  • Legacy Issue Number: 6252
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Redefinition of Associations is causing me some concern. I have a attached a RoseModel which expresses it better than verbiage.

    This is my first post to this group and I would appreciate a reply upon receipt just to let me know it is being reviewed

  • Reported: UML 1.5 — Mon, 15 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super/Composite Classes/Connecting parts of parts

  • Key: UML14-299
  • Legacy Issue Number: 6251
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Consider a model where a composite class, CC, has two parts A and B, both
    typed by class CT. If CT has a part PT, then can I describe a connection
    between A.PT and B.PT? It seems to me that the metamodel can't capture this
    because Connections can only be associated to parts, not parts of parts (i.e
    the metamodel for parts has a flat structure) . So the connection would end
    up being just a reflexive connection from PT to itself, which would be typed
    by a reflexive association on the type of PT.

    If there is a way of connection parts of parts I would like to see more
    explanation somewhere in the spec.

  • Reported: UML 1.5 — Mon, 15 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / association end naming convention

  • Key: UML14-303
  • Legacy Issue Number: 6256
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To be consistent with the convention of other names in the spec, the names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent).

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Classes/ Incorrect reference to "access"

  • Key: UML14-302
  • Legacy Issue Number: 6255
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are several places in the draft spec that refer to an "access" relationship when it should refer to a "uses" relationship instead. The access relationship according to the appendix is obsolete. The the incorrect reference I have found are on page 39, page 32.

  • Reported: UML 1.5 — Wed, 17 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / State machines-CommonBehavior / undefined owner of triggers

  • Key: UML14-305
  • Legacy Issue Number: 6258
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It is not clear which kind of model element owns a Trigger specification (the Behavior to which it applies or something else?)

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6629.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / SimpleTime package / missing multiplicities

  • Key: UML14-304
  • Legacy Issue Number: 6257
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicities for the various constraints are unspecified in the documentation and the metamodel:

    Specifically, the multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fig236 Datastore example/Datastore should not directly linked with actions

  • Key: UML14-298
  • Legacy Issue Number: 6250
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A datastore is a specialized CentralBufferNode. But in figure 236
    the datastore node is directly linked with action nodes. That is not
    allowed.

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/p125 and p126/typos

  • Key: UML14-297
  • Legacy Issue Number: 6249
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 125, last paragraph, first line
    "As it turns out, this seemis redunadancy..."

    p. 126, second line
    Figures 23.4 and 23.5 are not there

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does redefines mean in package extensibility?

  • Key: UML14-301
  • Legacy Issue Number: 6253
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    What does redefines mean in package extensibility?

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interfaces / Cannot nest classes in interfaces

  • Key: UML14-356
  • Legacy Issue Number: 6399
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Java spec says that it is legal to have Java Classes nested in Interfaces:

    9.1.3 Interface Body and Member Declarations
    The body of an interface may declare members of the interface:

    InterfaceBody:

    { InterfaceMemberDeclarationsopt }

    InterfaceMemberDeclarations:
    InterfaceMemberDeclaration
    InterfaceMemberDeclarations InterfaceMemberDeclaration

    InterfaceMemberDeclaration:
    ConstantDeclaration
    AbstractMethodDeclaration
    ClassDeclaration
    InterfaceDeclaration
    ;

    But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / restriction on redefining transitions

  • Key: UML14-355
  • Legacy Issue Number: 6397
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 502, there is a constraint that says that if a transition has a non-unique par <source state, trigger> it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo on Notation for CombinedFragment?

  • Key: UML14-352
  • Legacy Issue Number: 6380
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    On page 413 of Superstructure spec (Adopted) – section concerning notation for CombinedFragments of Sequence diagram, for the Operator Ignore/Consider, the Textual Syntax seems to have a typo – should that be straight brackets surrounding the last <message name> to denote optional, rather than the curly brackets?

    In other words:

    Textual syntax: (ignore | consider ){ <message name>

    {,<message name>}

    * }

    Should Be:

    Textual syntax: (ignore | consider )

    { <message name>[,<message name>]* }
  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Visibility of a Package

  • Key: UML14-351
  • Legacy Issue Number: 6379
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    Under notation (top of page 100), says that “The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (‘+’ for public and ‘-’ for private).”

    This statement does not mention protected () or package (~) visibility; only public and private.

    Cross Reference:

    On page 31 of Adopted Superstructure spec, figure 6, the VisibilityKind enumeration class has attributes public, private, protected

  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Simple Time / incorrect multiplicities

  • Key: UML14-359
  • Legacy Issue Number: 6402
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6257

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interface / missing owner of operation

  • Key: UML14-358
  • Legacy Issue Number: 6401
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Package Templates / StringExpression inconsistency

  • Key: UML14-361
  • Legacy Issue Number: 6404
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / inconsistent naming

  • Key: UML14-360
  • Legacy Issue Number: 6403
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent) to be consistent with the rest of the specification

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is duplicate with 6256.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 395 requires a lot more explanation

  • Key: UML14-353
  • Legacy Issue Number: 6381
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 395 requires a lot more explanation. The abstract syntax claims that
    the effect of a transition be expressed as an Activity and so I suppose this
    is what this diagram represents, but I don't recognise the rectangle
    notation from activities. It's also not clear whether the arrows represent
    flows or transitions - if fact they can't be either, because some of the
    arrows start on states and end on actions. It also isn't clear whether there
    are any rules about the construction of these transitions; for example, I
    assume that there can only be one signal receipt and that it has to be the
    first symbol encountered, but that isn't stated. There may be an explanation
    that I missed, in which case it should be placed nearer the figure, or an
    appropriate reference inserted. The various symbols should also appear in
    the diagrams section.

  • Reported: UML 1.5 — Thu, 23 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Templates / parameters cannot have names

  • Key: UML14-363
  • Legacy Issue Number: 6407
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The specification refers to template parameters by their names, implying that they are named elements; however, TemplateParameter is defined as a specialization of Element. Should TemplateParameter be a type of NamedElement?

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6262.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Deployments / node composition

  • Key: UML14-362
  • Legacy Issue Number: 6406
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Node::nestedNode should be an aggregate (containment by value) property

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the composition to the MDL and the spec.in figure 125

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Questions about CentralBufferNode semantic

  • Key: UML14-350
  • Legacy Issue Number: 6378
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I have a question about the flow semantic according to
    a CentralBufferNode.

    p.312 (Examples) says:
    "...because each token can only be drawn from the object node
    by one outgoing edge."

    What exactly happens if a CentralBufferNode has more than one
    outgoing edge. Is it defined which one is used?

    In the example on p. 312 I cannot see why the edge leading to
    the action "Use parts" is prefered to the action "Pack parts" as
    described in the text ("All the parts that are not used will be packed...").

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / state machines / entry and exit actions cannot be redefined

  • Key: UML14-354
  • Legacy Issue Number: 6396
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the current metamodel it does not appear as if state entry and exit actions can be redefined. Since transition actions can be redefined, this restriction does not make sense and should probably be removed.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Activities / structured activity node contradiction

  • Key: UML14-357
  • Legacy Issue Number: 6400
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::structuredNode subsets both node and group, but structured activity nodes can only be contained in one place (either group or node); should it be derived?

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Section 5.9/missing merge rules

  • Key: UML14-244
  • Legacy Issue Number: 6190
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML2 Infrastructure specification says in section 5.9 Packages Diagram, under Package Merge Semantics: "If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve conflicts." These rules don't appear to be defined anywhere. RedefinableElement indicates one redefining element may redefine multiple inherited redefinable elements.

    Clean Model Rule 8 says "An attrubute must be explicitly redefined in any cases where more than one attribute of the same name would be inherited from different superclasses, unless one of them already redefines the other." Rule 7 says "Attribute redefinition will be done by redeclaring an attribute in the subclass with the same name." This means that a redefinition in a subclass redefines all the inherited properties of the same name in all superclasses, and hides those inherited properties in the subclass. However, no common OO language supportes these semantics.

    As a result, performing the transformation specified by package merge semantics on UML2 Superstructure results in many name collisions caused by multiple inheritance of merged classes. This causes problems for XMI Schema and Java API generation.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/package merge and visibility

  • Key: UML14-243
  • Legacy Issue Number: 6189
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The package merge rules say that private elements from the merged package are not merged into the merging package. However, this can result in inconsistencies if for example, an association is public but its ends are private. And it would not work at all for define merge since the merged types are not retained. The merge implementation currently ignores visibility

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicActivities/inGroup problem

  • Key: UML14-247
  • Legacy Issue Number: 6193
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicActivities has edgeContents:ActivityEdge <--> inGroup:ActivityGroup. CompleteActivities has edgeContents:ActivityEdge

    {redefines edgeContents} <--> inGroup:InterruptibleActivityRegion {subsets inGroup}. inGroup ends up redefining and subsetting the inherited inGroup Should this have been interruptingEdge:ActivityEdge {redefines edgeContents}

    <--> interruptibleRegion:InterruptibleActivityRegion

    {redefines inGroup}

    and the other association removed? Or does inGroup need a new name?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::StructuredClasses/erroneous association

  • Key: UML14-246
  • Legacy Issue Number: 6192
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package StructuredClasses contains class Class and an association +:Class ->+ownedAttribute:InternalStructures::Property which does not appear on any diagram. This association does not match the similar one in Constructs: +class:Class <->+ownedAttribute:Property because it is missing an end name and navigability in both directions. It is not clear if this was intended to constrain the Constructs association so that a property does not know the class that contains it, or if the association was meant to be deleted. It cannot simply be corrected by adding the missing end and making it navigable in both directions as this would result in Property having two properties called class. Either the association should be removed, or StructuredClasses needs to redefine Property instead of referencing it directly from InternalStructures

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package Merge/redefinition rules and standard OO languages

  • Key: UML14-245
  • Legacy Issue Number: 6191
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around.

    A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute."

    This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Constructs/inconsistency with Kernel

  • Key: UML14-241
  • Legacy Issue Number: 6186
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constructs has association mergingPackage:Package[1..1] c-> packageMerge:PackageMerge[0..*] while Kernel has mergingPackage:Package[1..1] c-> packageExtension:PackageMerge[0..*] without a renames. Should this be changed to packageMerge to be consistent with Constructs?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Resolved as part of the resolution to issue 6918.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicBehaviors/missing redefinition

  • Key: UML14-240
  • Legacy Issue Number: 6185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicBehaviors has association context:BehavioredClassifier[0..1] c-->ownedBehavior:Behavior[0..*]. BehaviorStateMachines has :BehavioredClassifier[0..1]

    {subsets redefinitionContext}

    c--> ownedStateMachine: StateMachine[0..*]

    {redefines ownedBehavior}

    . StateMachine specializes Behavior thereby inheriting context:BehavioredClassifier. Property redefinitionContext comes from RedefiningElement, but the inherited property context is skipped. Is the role name missing? Should context:Behavior subset redefinitionContext?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package Merge/missing rule for operations

  • Key: UML14-250
  • Legacy Issue Number: 6198
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package merge rules do not specify how operations match when being merged, or how they are merged if they do match

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The appropriate rules for this case are now spelled out in the resolution to issue 6279.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Compliance::L3/Missing merges

  • Key: UML14-249
  • Legacy Issue Number: 6196
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::Compliance::L3 doesn't merge: InfrastructureLibrary::Profiles, UML::AuxiliaryConstructs.Templates, UML::CompositeStructures.StructuredActivities, UML::Profiles, UML::StateMachines::MaximumOneRegion

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/merging of non-redefinable model elements

  • Key: UML14-242
  • Legacy Issue Number: 6188
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Model elements, like Constraint, that are not RedefinableElements are always copied from the merged model element to the merging model element. When a package like Kernel is merged into many packages which are then in turn merged into another common package, these non-redefinable elements are copied down multiple times in the leaf merging package. For example, L3::Classifier has a large number of ownedRules named general_equals_parent which it gets from Dependencies::Classifier. Dependencies is merged into Kernel which is merged into many packages in Superstructure. Perhaps a Constraint should be a RedefinableElement, or package merge should only copy down these elements once

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel::Packages/missing redefinition

  • Key: UML14-239
  • Legacy Issue Number: 6184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/Packages has association package:Package <--> ownedClassifier:Type without a redefinition while its ownedType in Basic and Constructs

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6918.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::StructuredActivities/double redefinition

  • Key: UML14-248
  • Legacy Issue Number: 6195
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StructuredActivities has association activity:Activity

    {redefines activity, redefines activity}

    <--> structuredNode:StructuredActivityNode. It should only redefine activity once.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile/inability to attach a stereotype to an element

  • Key: UML14-251
  • Legacy Issue Number: 6199
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package Profile does not specify any way to attach a Stereotype to an Element.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the solution to issue 6347.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SendObjectAction

  • Key: UML14-191
  • Legacy Issue Number: 6132
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clean up SendObjectAction so it doesn't refer to signals. It can send
    any object, including a signal.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of insert

  • Key: UML14-190
  • Legacy Issue Number: 6131
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in AddStructuralFeatureAction, etc, that insert is not needed
    when isReplaceAll = true.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Colon notation for pins

  • Key: UML14-185
  • Legacy Issue Number: 6125
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter notation can be used for pins even when they
    aren't invocation actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local pre/postcondition example

  • Key: UML14-184
  • Legacy Issue Number: 6124
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a local pre/postcondition example that is really local

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter semantics clarification

  • Key: UML14-182
  • Legacy Issue Number: 6122
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of parameters "Either all non-stream outputs must be
    posted when an activity is finished, or one of the exception outputs
    must be." Reword and clarify that exception outputs are non-streaming.
    Also state that exception outputs cannot be streaming.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExceptionHandler 1

  • Key: UML14-192
  • Legacy Issue Number: 6133
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add a constraint to ExceptionHandler that the input of the exception
    handler body must be one value of same type as the exception input
    object node, and constraint that the input object node must be a pin
    on/part of the protected node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No-token activity termination clarification

  • Key: UML14-189
  • Legacy Issue Number: 6130
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that activities terminate if there are no tokens in it,
    including tokens inside actions. The semantics of Parameter only states
    the necessary conditions now.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for for global pre/postconditions actions

  • Key: UML14-187
  • Legacy Issue Number: 6128
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for actions invoking beahviors with global
    pre/postconditions

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior execution instances

  • Key: UML14-183
  • Legacy Issue Number: 6123
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Executing behavior creates an instance of the behavior class.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for isSynchronous

  • Key: UML14-188
  • Legacy Issue Number: 6129
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for isSynchronous on CallAction.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Value Pin notation

  • Key: UML14-186
  • Legacy Issue Number: 6127
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for value pins.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectFlowEffect

  • Key: UML14-171
  • Legacy Issue Number: 6109
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ObjectFlowEffect requires edges from pins to actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional parameters

  • Key: UML14-170
  • Legacy Issue Number: 6108
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics for invocation actions on behaviors that have
    parameters with multiplicity with lower bound of zero? Currently, the
    execution semantics requires all data inputs to arrive.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6105.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 2

  • Key: UML14-176
  • Legacy Issue Number: 6116
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that two parameter sets should not have exactly the
    same parameters in them

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode.isUnique

  • Key: UML14-174
  • Legacy Issue Number: 6113
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that ObjectNode.isUnique = false

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reentrancy 3

  • Key: UML14-173
  • Legacy Issue Number: 6112
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a notation for isReentrant.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin multiplicity

  • Key: UML14-169
  • Legacy Issue Number: 6107
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics of pin multiplicity? If it has no execution
    effect, then remove it. If it is the same as the multiplicity inherited
    from TypedElement, then use that. If multiplicity has the same
    semantics as bound, then multiplicity should be used instead of bound

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See discussion and resolution to Issue 6090.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 1

  • Key: UML14-175
  • Legacy Issue Number: 6115
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The end names on the association between Parameter and ParameterSet
    are reversed.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutableNode, ControlNode should be abstract

  • Key: UML14-172
  • Legacy Issue Number: 6110
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExecutableNode, ControlNode should be abstract

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML's use of the word "unique" for multiplicity is ambiguous

  • Key: UML14-133
  • Legacy Issue Number: 5976
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    UML's use of the word "unique" for multiplicity is ambiguous. It means
    "distinct", but it could be mistaken to mean "unique across all instances".
    For example, if someone says that the employee-number attribute of employee
    is unique, it would likely be understood to mean that each employee has an
    employee-number that is different from every other employee. But that's not
    what UML defines "unique" to mean. I recommend that the FTF change
    "

    {unique}

    " to "

    {distinct}

    " or "

    {set}

    ".

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure: Operation vs. Attribute notation

  • Key: UML14-132
  • Legacy Issue Number: 5951
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    For reference, my copy here is ad/03-04-01.

    I wonder about an inconsistency between the notations for attributes
    (section 1.8, page 41, in "Classifier (from Kernel, Dependencies,
    PowerTypes)") and operations (section 1.10, page 55, in "Operation
    (from Kernel)").

    For attributes, the notation is (slightly simplified)

    visibility name : type [multiplicity]

    {property-string}


    and for operations, it is


    visibility name (parameter-list) : property-string


    So in the case of attributes, a colon separates the name from the
    type, and the property-string is in curly braces, whereas for
    operations, the colon separates the name and signature from the
    property-string, which is not in braces.


    I think this discrepancy is counter-intuitive, I would expect the
    same atoms to be used in both blaces. I realize that the syntax for
    operations changed from UML 1.5 because of promoting the "return
    value" to a parameter.


    My suggestion is to change the notation for operations to


    visibility name (parameter-list) {property-string}

    i.e. to remove the colon, and to add braces around the property-
    string. This would be more consistent with both the attribute
    notation and the old UML 1.x notation.

  • Reported: UML 1.5 — Fri, 13 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The description of DataType is plainly wrong in the specification

  • Key: UML14-135
  • Legacy Issue Number: 5979
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of DataType is plainly wrong in the specification. A
    data type is a classification of data values. The identity of a data value
    is based on the value itself. And the identity definitely exists.
    Otherwise you would not be able to know when you had two occurrences of the
    same value. If a value has no identity, it would not be possible to
    distinguish different values of the same data type. Someone has confused
    the concept of having identity with the concept of having a memory address.
    Note also that an instance specification is capable, according to the
    specification, of identifying a data value, so it is a contradiction to say
    a data value has no identity. Perhaps the specification is using the word
    "identity" in a way that is completely different from anything in my
    dictionary. The key point to make is that a data value is not to be
    confused with a data variable or a slot in an object that can hold a data
    value.

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

notation for shared aggregation

  • Key: UML14-134
  • Legacy Issue Number: 5978
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    3. The notation for shared aggregation appears to be missing from the
    association notation section

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add text to explain the so-called “white diamond” notation for shared aggregation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question on Connectors - fig 2-17

  • Key: UML14-139
  • Legacy Issue Number: 5995
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On fig 2-17, the left-hand of the diagram shows Order with two interfaces,
    OrderableItem and OrderEntry. On the right hand, the assembly connector
    lists only OrderableItem. Yet, the text above -

    "When this notation is used to connect "complex" ports that are typed by
    multiple provided and/or required inter-faces,
    the various interfaces are listed as an ordered set, designated with

    {provided}

    or

    {required}

    if needed."

    might be interpreted as indicating that on the Order side of the assembly
    connector, the adornment should read "OrderableItem,OrderEntry" (as an
    aside, the text above seems to indicate that this list is ordered, but I
    don't know what the order should be). There are a number of possible
    explanations for the current figure:

    • It's a mistake and both interfaces should be listed;
    • Only interfaces supported by both sides of the connector need to be
      listed, (but how about compatible interfaces that are not related by
      classification?)
    • The text above does not apply to parts, but that seems unlikely -
      they are connectable elements after all and can implement and use multiple
      interfaces
    • Something I haven't though of

    Can someone please enlighten me?

  • Reported: UML 1.5 — Fri, 11 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState

  • Key: UML14-138
  • Legacy Issue Number: 5992
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    There appears to be a typo on page 2-148, in section 2.12.2.13 on StubStates. In this section it states that StubState is a child of State. However, in Figure 2-24 on page 2-141 it shows StubState as derived from StateVertex

  • Reported: UML 1.5 — Tue, 8 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-Formedness Rules for Procedure on Common Behavior Package

  • Key: UML14-137
  • Legacy Issue Number: 5982
  • Status: closed  
  • Source: Freelance Developers ( Francisco Araujo)
  • Summary:

    Well-Formedness Rules for Procedure on Common Behavior Package are wrong, document is actually showing same content as Abstract Sintax for Procedure on Common Behavior Package.

  • Reported: UML 1.5 — Tue, 24 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An error in Figure 464

  • Key: UML14-141
  • Legacy Issue Number: 6066
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I found there still is an error in Figure 464 from ptc/03-07-06 to 03/08/02 of UML 2.0 Superstructure Specification, ie. Collaboration Diagram should be replaced with Communication Diagram

  • Reported: UML 1.5 — Fri, 15 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageableElement

  • Key: UML14-140
  • Legacy Issue Number: 6049
  • Status: closed  
  • Source: Anonymous
  • Summary:

    there was declared and inheritance relationship between NamedElement and
    PackageableElement defining in both cases an attribute "visibility". I
    suggest to suppress the declaration in PackageableElement because it is
    inherited from NamedElement

  • Reported: UML 1.5 — Thu, 31 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 63 missing notation

  • Key: UML14-145
  • Legacy Issue Number: 6070
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Also Figure 63 is missing "<<" from in front of Interface>> IAlarm

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface Figure 62 uses wrong notation

  • Key: UML14-144
  • Legacy Issue Number: 6069
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Figure 62 uses the wrong notation. The text says that it is using dependcy arrows - they are solid - one of them has a generalization arrow head. Also the interface 'ISensor' rectangle does not include <<interface>> with the name

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of GeneralizationSet

  • Key: UML14-136
  • Legacy Issue Number: 5980
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of GeneralizationSet uses the words "general" and
    "specific" to mean "specific" and "general" respectively. The description
    also uses unclear terms like "maps to classifier" without identifying which
    association. Also, the semantics has: "All of the Generalization links that
    share a given general Classifier are divided into disjoint sets (that is,
    partitions) using the generalizationSet association." This statement is
    nonsense. First, the metamodel does not require all generalizations to be
    put into partitions using "the generalizationSet association". Second,
    partitions are not required by the metamodel to be disjoint - the same
    generalization can be in multiple generalization sets (as should be the
    case).

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01

  • Key: UML14-142
  • Legacy Issue Number: 6067
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In this section the following statement appears:

    "An imported element can be further imported by other namespaces using either element or member imports."

    This is the first and only reference I have found to "member import." Please provide a definition of member import and include an example if it may be required to complete the understanding of the concept.

  • Reported: UML 1.5 — Mon, 18 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete notation used in state machine - transition examples

  • Key: UML14-143
  • Legacy Issue Number: 6068
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Section 15.3.14 Transition

    Figures 395 and 396 use lozenge shapes (a rectangle with rounded ends - the notation for an activity in UML 1.4). However, these are state machine examples and this notation is meaningless in this context.

  • Reported: UML 1.5 — Wed, 20 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Notation

  • Key: UML14-55
  • Legacy Issue Number: 4219
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    I raised this issue at the AB level. I didn't recommend holding up approval
    of UML 1.4 over this but we agreed that the new RTF would take this matter
    up with dispatch.

    Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
    and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
    issue. I can speak to this as a practical matter based on the profiling
    work I've done. When I define a Stereotype on a UML metamodel element, as
    in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
    of the UML metamodel element. I don't want to have to define it again
    before defining the relationship between my new Stereotype and that UML
    metamodel element. Thus, requiring the <<metaclass>> Stereotype on the UML
    metamodel element means that, in the UML metamodel itself, I would have to
    Stereotype all the metaclasses this way so that, if I need to, I can reuse
    them in VMMs. True, I could opt not to display the <<metaclass>>
    Stereotype in a pure UML metamodel diagram and opt to display it a VMM
    diagram, but all the UML metamodel elements would be carrying the
    <<metaclass>> Stereotype.

    The best solution I can think of to this problem is to to drop the
    requirement to use the <<metaclass>> Stereotype in VMM diagrams. As long as
    the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
    is adhered to, it should be pretty clear in a VMM diagram what is a
    Stereotype and what is a UML metamodel element. Also, the the standard
    metamodel Stereotype of Package indicates that the elements in the
    Package are elements of a metamodel.

    I am open to other suggestions as to how to resolve this issue.

  • Reported: UML 1.3 — Fri, 9 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A, UML Standard Elements

  • Key: UML14-54
  • Legacy Issue Number: 4218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

  • Reported: UML 1.3 — Thu, 8 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Conflicting WFRs on Transition

  • Key: UML14-58
  • Legacy Issue Number: 4298
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    UML 1.4 Specification, Section 2.12.3, p. 2-165

    Description:
    WFR 5 for the class Transition states that "Transitions outgoing
    pseudostates may not have a trigger" and the OCL supports this absolute
    statement. However, WFR 6 is intended to allow transitions out of initial
    states, which are a kind of pseudostate, to have "a trigger with the
    stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
    legal.

    Recommendation:
    Change WFR 5 as follows.

    [5] Transitions outgoing pseudostates other than initial states may not have
    a trigger.

    self.source.oclIsKindOf(Pseudostate) implies
    self.source.oclAsType(Pseudostate).kind<>#initial implies
    (self.trigger->isEmpty())

  • Reported: UML 1.3 — Thu, 10 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Multiplicity to Parameter.

  • Key: UML14-57
  • Legacy Issue Number: 4292
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Adding multiplicity to Parameter would enable modeling of arrays,
    collections, sequences etc. I would like to model BehavioralFeatures that
    can return an array and take an array as an argument.
    The notation would simply add the [multiplicity] after the Parameter type.
    The initial value syntax would be

    { initial-value, initial-value..}
  • Reported: UML 1.3 — Tue, 1 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Events, signals, stimuli, etc.

  • Key: UML14-56
  • Legacy Issue Number: 4263
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Shane Sendall)
  • Summary:

    Here is my understanding of communication between instances on an
    example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
    An instance i1 performs a SendAction, according to the spec: "A send
    action is an action that results in the (asynchronous) sending of a
    signal". Then, the signal is delivered to say instance i2, and as a
    consequence of the receipt, a SignalEvent is generated (according to the
    spec, "A signal event represents the RECEPTION of a particular
    (asynchronous) signal")
    Now the problems:
    1) the spec goes on further to say about the signal event that "A signal
    event
    instance should not be confused with the action (e.g., send action) that
    generated it". The problem I have with my above understanding is that
    the send action should not be the one generating the send event but
    rather the reception of the signal should be the one generating it.
    2)According to the spec: "A signal is a specification of an asynchronous
    stimulus communicated between instances" where a stimulus is more
    general "In the metamodel Stimulus is a communication, i.e. a Signal
    sent to an Instance, or an invocation of an Operation". Thus, I conclude
    that the things sent between instances are stimuli.
    However, I'm a little confused of the relationship between events and
    stimuli with the following sentence taken from the spec "Event instances
    are generated as a result of some action either within the system or in
    the environment surrounding the system. An event is then conveyed to one
    or more targets. The means by which event instances are transported to
    their destination depend on the type of action, the target,..."
    Furthermore, how are stimuli and signals related in the metamodel?

  • Reported: UML 1.3 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Predefined datatypes

  • Key: UML14-61
  • Legacy Issue Number: 4452
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The various datatypes that are the result of expressions are not
    defined in UML. For example, there is no subtype of Datatype
    called Boolean. This means users will all define their own Boolean,
    Integer, etc., breaking interchangeability.

    The datatypes defined in the Datatypes packages are not model
    elements, so theoretically cannot be used in M1 models. However,
    the interchange model for UML includes these types, making them
    available for user models. If this is the case, it should be made
    clear in the UML spec. The overview of the Datatypes package
    (section 2.7.1) says it contains types used in defining UML, so
    they formally belong to the MOF.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The definition of Multiplicity in Datatypes does not list the range associa

  • Key: UML14-60
  • Legacy Issue Number: 4449
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of Multiplicity in Datatypes does not list the range association

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component notation: logical compartments

  • Key: UML14-65
  • Legacy Issue Number: 4464
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current component notation does not provide for separate
    logical compartments when nesting implementation classes and artifacts in a
    component, as shown in Notation, Figure 3-95. It would be useful to provide
    separate logical compartments for this, as we do for subsystems and classes.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exceptions do not correspond to common usage

  • Key: UML14-64
  • Legacy Issue Number: 4457
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions in UML are signals, but the normal usage of the term is
    for non-local flow of control that is trapped in procdural code.
    No signal is normally sent with exceptions.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the origin of an Action in a Collaboration.

  • Key: UML14-53
  • Legacy Issue Number: 4123
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Actions seem to be owned by the Message in the following paragraph.

    Section 2.10 page 2-130. "In the metamodel a Message defines one specific
    kind of communication in an Interaction. A
    communication can be e.g. raising a Signal, invoking an Operation, creating
    or destroying an
    Instance. The Message specifies not only the kind of communication, but also
    the roles of the
    sender and the receiver, the dispatching Action, and the role played by the
    communication
    Link. Furthermore, the Message defines the relative sequencing of Messages
    within the
    Interaction."

    Is the Action a reference to a Action in the Sender, as the meta-model
    suggests, or is it owned by the Message as the above suggests?

    Please clarify.

  • Reported: UML 1.3 — Mon, 18 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of classifier targetscope

  • Key: UML14-59
  • Legacy Issue Number: 4447
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier targetscope is ambiguous for
    associations with participating classifiers that have children. It
    is not defined whether this specifies links for the classifier and
    all its descendants, or links for the classifier and each
    descendant separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Event => Event Specification

  • Key: UML14-63
  • Legacy Issue Number: 4456
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The event metaclass would better called "event specification". Or
    at least the runtime event should be called "occurences" rather
    than instances.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6682.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The text and OCL of rule #5 for Method do not say the same thing.

  • Key: UML14-62
  • Legacy Issue Number: 4455
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text and OCL of rule #5 for Method do not say the same thing.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Another State machine issue

  • Key: UML14-37
  • Legacy Issue Number: 3202
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines

    The metaclass StateVertext, including its subclasses PseudoState,
    StubState and SyncState is not owned by a StateMachine.

    The associations from StateVertext to

    • container : CompositeState
    • outgoing : Transition
    • incoming : Tranision
      can all be empty.
      If they are all empty in a model, we do not know to which statemachine
      this StateVertex belongs. IS this the intention ?
  • Reported: XMI 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Data Types Misplaced in the "Physical" Metamodel (uml-rtf)

  • Key: UML14-36
  • Legacy Issue Number: 3127
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    All data types used in the UML metamodels are clumped together in a
    Data_Types package in the Foundation metamodel. When a new type is needed
    by some other metamodel, such as for Activity Graphs, the type is added into
    Foundation. This breaks the whole concept of extensibility. Data types,
    like other model elements, should be defined in the specific packages where
    they are needed. A new package that requires new types should include those
    types itself and not impose a change on UML Foundation.

    Recommendation: In the "physical" metamodel, put data types into the
    packages where they are first used. For example, PseudostateKind should be
    defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance violation in "Auxiliary Elements"

  • Key: UML14-30
  • Legacy Issue Number: 2361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
    1999 and the associated Rational Rose model files

    Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
    Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
    2.5.3, pp.2-49

    Nature: Clarification

    Severity: Medium
    Summary: In the 1.1 model file, there is an inheritance relationship
    between
    "Presentation" (in "Auxiliary Element") and "Element" (in "Core").
    "Presentation" is an association class and "Element" is a normal class.
    The two types are not the same, this this brings up the following
    constraint in the semantic document:

    self.subtype.oclType = self.supertype.oclType

    Question:
    1) Is "Presentation" suppose to inherit from "Element"? The other
    association classes "ElementOwnership" and "ElementReference" do no
    appear to do so.

    2) If the answer to (1) is yes, then isn"t it a violation of the UML
    semantics" well-formedness rule.

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class EnumerationLiteral issue

  • Key: UML14-33
  • Legacy Issue Number: 2582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that the class EnumerationLiteral should be an heir of DataValue
    (this inheritance relationship is currently missing).

    Once this is fixed, the association between EnumerationLiteral and Enumeration
    should be seen as a refinement of the association between DataValue and DataType
    (itself implicitly inherited from the association between Instance and classifier),
    with a supplementary OCL constraint in the case of EnumerationLiteral,
    namely that self.classifier.oclIsKindOf(Enumeration)
    (to ensure covariance, as is done for DataValue wrt DataType).

    BTW, shouldn"t there be a symetric OCL constraint in DataType
    specifying that its Instances are all DataValues,
    and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?

  • Reported: XMI 1.0 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and Constraints Missing from "Physical" Metamodels

  • Key: UML14-35
  • Legacy Issue Number: 3126
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The "physical" metamodel should include the OCL constraints and operations
    defined in the UML Specification. This has been done in the MOF 1.3
    specification. The operations provide valuable capabilities and should be
    part of the standard UML facility interfaces. Making the operations part of
    the "physical" metamodel allows them to be used when defining new
    constraints in extension metamodels, such as in CWM.

    Recommendation: Add the specification's constraints and operations to the
    "physical" metamodel.

    Note that adding constraints and operations will affect IDL, but it will not
    affect XMI DTDs.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete Inheritance Specification

  • Key: UML14-31
  • Legacy Issue Number: 2362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta

    Specification section reference: None

    Nature: Clarification

    Severity: Minor

    Summary: There is an oddity in the inheritance relationship of
    "Classifier" in "Core". Is "Classifier" suppose to inherit from
    "Taxon-Datatype", but the specification is incomplete. Rational Rose
    and Rose98 raises an error for this association during a "Check Model".

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Datatypes: Expression

  • Key: UML14-32
  • Legacy Issue Number: 2541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the metaclass Expression includes an attribute called "language" of type
    Name. To enable tools to check OCL expressions, it is neccesary to
    define a standard value for this attribute, which denotes the fact that the
    expressions is an OCL expression.
    Without such a standard defined value tools cannot distinguish OCL
    expresions and cannot interpret them (for purposes of typechecking,
    code generation, etc....)

    I propose to add the value "OCL" as a standard value for the attribute
    "language" of metaclass "Expression" to the chapter on datatypes.

  • Reported: XMI 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interfaces on Nodes

  • Key: UML14-34
  • Legacy Issue Number: 2613
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot
    determine if interfaces are allowed on Nodes. Since a Node is a kind
    of classifier, it seems possible that a Node can realize an interface.
    However, since this relationship is not explicitly mentioned as allowed
    or not, I am unclear as to the intention.

  • Reported: XMI 1.0 — Mon, 19 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Dynamic concurrency arguments

  • Key: UML14-38
  • Legacy Issue Number: 3276
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions in dynamically concurreny states in activity graphs need
    some way to access the arguments provided by the concurrency
    expression. The Reference manual suggests the "implicit" event,
    but does not define what that is (p 437). Perhaps it is an the
    action language issue.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Parallel action iteration

  • Key: UML14-39
  • Legacy Issue Number: 3285
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should have a isParallel attribute to specify if the iteration
    is sequential or parallel.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 4

  • Key: UML14-168
  • Legacy Issue Number: 6106
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in CallBehaviorAction and CallOperationAction that the operation
    and behavior may have out or results and still be called asynchronously.
    The constraints on these actions regarding pin/parameter matching only
    applies in the synchronous case.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 3

  • Key: UML14-167
  • Legacy Issue Number: 6105
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    If the multiplicity of a parameter has zero lower bound, how does that
    affect the execution semantics of an invocation action on the
    behavior/operation? If the pin value is optional in this case, then it
    violates the current semantics.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Weight=all

  • Key: UML14-158
  • Legacy Issue Number: 6096
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The weight attribute on activity edges says:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But a figure specifies

    {weight=all} for the same purpose.


    Which one is the correct one?


    I think {weight=all}

    is the better alternative to express the
    semantic.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide notations for Loop and Conditional

  • Key: UML14-157
  • Legacy Issue Number: 6095
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notations for Loop and Conditional

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071 (Conditional Node and Loop Node notation missing)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple outputs of object flow transformations

  • Key: UML14-163
  • Legacy Issue Number: 6101
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    It would be useful to allow object flow transformations to produce
    multiple tokens from one token.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Keywords or properties

  • Key: UML14-162
  • Legacy Issue Number: 6100
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    Should the keywords "parallel", "iterative", and "stream" for
    ExpansionRegions be in guillemets like localPrecondition? Or is it a a
    property that should be in curly braces, like streaming parameters.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tokens at fork

  • Key: UML14-159
  • Legacy Issue Number: 6097
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Fork won't let tokens pass on all outgoing edge unless all outgoing
    edges accept the copied token. Guards or backed up flows may prevent a
    token from being accepted on an outgoing edge. This causes a dependency
    between the outgoing edges.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is duplicate with 6512.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegions keywords

  • Key: UML14-161
  • Legacy Issue Number: 6099
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The keywords "parallel", "iterative", and "stream" are defined for
    ExpansionRegions, but the example figures use "concurrent" instead of
    "parallel". The metamodel type ExpansionKind solely defines parallel"
    and the other two keywords mentioned above, not "concurrent".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 1

  • Key: UML14-165
  • Legacy Issue Number: 6103
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are pins matched to parameters for invocation actions when there is
    only one parameter list for behaviors and two for actions? There should
    be a general action-pin association specialized for inputs and outputs.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ActivityFinalNode

  • Key: UML14-160
  • Legacy Issue Number: 6098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What happens to running actions within the activity when a token reaches
    an ActivityFinalNode? Are the actions terminated immediately or do they
    run to completion. Would prefer that they are terminated immediately

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6504.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 2

  • Key: UML14-166
  • Legacy Issue Number: 6104
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What kind of pin is used for inout parameters? If two pins are used,
    how are they matched to the same parameter?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6103.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins owned twice

  • Key: UML14-164
  • Legacy Issue Number: 6102
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Pins are owned twice: by activities and actions

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

representation of arrays of values in an action language

  • Key: UML14-131
  • Legacy Issue Number: 5924
  • Status: closed  
  • Source: FAU Erlangen ( Martin Jung)
  • Summary:

    While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23];

    However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict?

    Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics.

  • Reported: UML 1.5 — Wed, 30 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.29 Node

  • Key: UML14-130
  • Legacy Issue Number: 5805
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "resident The set of resident elements may differ. Often it is more restrictive on the child." has no corresponding association or attribute in any diagram.

  • Reported: UML 1.4 — Fri, 20 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.15 Dependency

  • Key: UML14-128
  • Legacy Issue Number: 5802
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15).

    The same issue applies to the supplier association end and its documentation.

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above and below - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-123
  • Legacy Issue Number: 5797
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The binary association between ModelElement and Flow is undocumented both in the ModelElement and Flow documentation.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 2.5.2.10 Classifier

  • Key: UML14-122
  • Legacy Issue Number: 5796
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    specifiedEnd Indicates an AssociationEnd

    does not agree with the cardinality * on the association end specifiedEnd between Classifier and AssociationEnd in Figure 2-6 Core Package - Relationships on page 70.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-129
  • Legacy Issue Number: 5803
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named container that belongs to the aggregation association between Component and ModelElement (Figure 2-8) is not documented in Section 2.5.2.27 ModelElement.

    2.5.2.27 ModelElement DOES document implementationLocation as "The component that an implemented model element resides in." This association is not on any of the Class Diagrams in Section 2.5.2.

    Should the implementationLocation association be renamed to container in Section 2.5.2.27 ModelElement?

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Designates a Generalization (02)

  • Key: UML14-121
  • Legacy Issue Number: 5795
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    Designates a Generalization whose child GeneralizableElement is the immediate descendant of the current GeneralizableElement.

    disagrees in plurality with the * cardinality of the specialization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

  • Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.27 ModelElement

  • Key: UML14-125
  • Legacy Issue Number: 5799
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    implementationLocation The component that an implemented model element resides in.

    disagrees with the * cardinality of the implementationLocation association end of the ModelElement - Component association in Figure 2-8 Core Package - Classifiers on page 2-16.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.10 Classifier

  • Key: UML14-126
  • Legacy Issue Number: 5800
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    "specifiedEnd Indicates an AssociationEnd..."

    disagrees with the cardinality * on the association end labeled specifiedEnd of the association between Classifier and AssociationEnd. (Figure 2-6 on page 2-14)

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.16 Element

  • Key: UML14-124
  • Legacy Issue Number: 5798
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    Element cannot have tagged values. There is no tagged values attribute or association for class Element. Should the taggedValue feature be moved from ModelElement to Element?

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-127
  • Legacy Issue Number: 5801
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named typedParameter that belongs to the association between Classifier and Parameter is not documented in the Classifier section (2.5.2.10 Classifier on page 2-28).

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: ClassifierRole contents problem

  • Key: UML14-82
  • Legacy Issue Number: 4736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
    "...specifies a restricted view of a [base] classifier.." and defines "...a
    set of Features, which is a subset of those available in the base
    classifier, as well as a subset of ModelElements contained in the base
    classifier...".

    The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
    "feature" association inherited from Classifier must be empty - instead the
    ClassifierRole must select features from the base classifier using the
    "availableFeature" association [UML 1.4, pp. 2-121].

    The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
    2-121] indicating "the subset of ModelElements contained in the base
    Classifier, which is used in the Collaboration". There is however no
    restriction in the wellformedness rules restricting the ownedElements
    contents of the ClassifierRole itself, meaning that a ClassifierRole can
    contain the following meta-elements:

    Method
    Attribute
    Operation
    Reception
    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState
    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction
    ExtensionPoint
    Stimulus
    Parameter
    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    So the question is: is this lack of restriction intentional? And if so, why
    are ownedElements handled differently from features? And what is the
    semantic difference between entities selected using the "availableContents"
    association and those contained directly?

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Node, Artifact, Package and Model contents problem

  • Key: UML14-81
  • Legacy Issue Number: 4735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, the abstract metaclass Namespace
    compositely contains any type of ModelElement, but does however state that
    subclasses may restrict this containment [UML 1.4, pp. 2-45].

    The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
    1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
    however.

    This means that Node, Artifact, Package and Model can compositely contain
    the following concrete metaclasses as ownedElements:

    Method
    Attribute
    Operation
    Reception

    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState

    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction

    ExtensionPoint
    Stimulus
    Parameter

    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    The question is: are all these ownedElement types intended for all the
    mentioned containers? Especially the first 28 in the list appear out of
    place.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest that alternate syntax used in section 6.5.5 be adopted thoughout

  • Key: UML14-89
  • Legacy Issue Number: 4816
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification.

    This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away.

    Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

  • Reported: XMI 1.3 — Tue, 29 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid XMI.link.atts in UML 1.4 DTD

  • Key: UML14-88
  • Legacy Issue Number: 4810
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
    XMI.link.att declaration as follows:

    <!-- _______________________________________________________________ -->
    <!-- -->
    <!-- XMI.link.att defines the attributes that each XML element that -->
    <!-- corresponds to a metamodel class must have to enable it to -->
    <!-- function as a simple XLink as well as refer to model -->
    <!-- constructs within the same XMI file. -->
    <!-- _______________________________________________________________ -->

    <!ENTITY % XMI.link.att
    'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
    CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
    xlink:actuate (show|user) #IMPLIED xlink:content-role
    CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
    (embed|replace|new) #IMPLIED xlink:behavior CDATA
    #IMPLIED'>

    The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
    these (p4-81 of formal/00-11-02).

    The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
    (this appendix was removed at XMI 1.2 since it was wrong and misleading).

    Many of the above link attributes seem actually to be invalid:

    • xml:link is invalid since this is not part of the xml namespace
    • xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
      namespace
    • xlink:actuate has invalid values - the standard values are
      (onLoad|onRequest|other|none)
    • xlink:show is missing values - the full set is
      (new|replace|embed|other|none) [I guess it is not so much of a problem to
      exclude certain values]
  • Reported: XMI 1.3 — Mon, 21 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4.1 should use MOF 1.4

  • Key: UML14-95
  • Legacy Issue Number: 4946
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the case of MOF 1.4 there are far more important reasons for moving to
    it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
    opposed to CORBA datatypes hidden away in typeCodes. Because of this:
    a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
    Java APIs to metamodels and is being adopted by a number of repository and
    UML tool vendors. Without an official version of UML expressed in MOF 1.4
    people will have to do their own conversion with subsequent interoperability
    problems

    b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
    Without being expressed in MOF 1.4, the UML interchange definition cannot be
    expressed as an XML Schema.

    c) the proper datatype model provides the opportunity to 'clean up' a
    number of datatype-related issues in UML (e.g. issue 4452). And represent
    UML's datatypes such as Multiplicity and MultiplicityRange as MOF
    (structure) datatypes rather than MOF classes.

    I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
    be willing to draft a proposal for this. Is there a version of this with
    already-agreed 1.4.1 changes incorporated?

  • Reported: XMI 1.3 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add action for invoking an activity

  • Key: UML14-94
  • Legacy Issue Number: 4940
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add action for invoking an activity

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Wrong target for StateMachine.top association

  • Key: UML14-84
  • Legacy Issue Number: 4739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A StateMachine compositely contains a State through the "top" association
    [UML 1.4, pp. 2-147, fig. 2-24].

    However, the wellformedness rules for StateMachine state that "A top state
    is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
    2-158].

    If that is the case, the top association should target a CompositeState, not
    the more general State.

    Note: of course this is not an error as such, but if a wellformedness rule
    can be expressed just as easily in UML, there is no reason to complicate
    matters

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: AttributeLink containment error

  • Key: UML14-83
  • Legacy Issue Number: 4738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
    2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
    fig.2-17].

    The former containment obviously prevents the latter from ever being
    realized.

    Note: If changing the former containment from mandatory to optional, please
    remember to exclude AttributeLink from other composite containments
    implicitly enabled by such a change - such as being an ownedElement of a
    Namespace, or a parameter of a template.

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definitions in glossary don't conform to any standard for definitions

  • Key: UML14-87
  • Legacy Issue Number: 4800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS.

    For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words.

    Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right.

    People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it.

  • Reported: XMI 1.3 — Wed, 2 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite relationship between Event and StateMachine

  • Key: UML14-86
  • Legacy Issue Number: 4746
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    As previously mentioned in issues 3558 (Who owns an Event?) and
    4734 (Event containment problem).
    Based upon issue 3558 response I believe that an Event should be owned by a
    StateMachine.
    A composite relationship should be added between Event and StateMachine in
    the UML Meta-Model.

  • Reported: XMI 1.3 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify inputs/outputs of procedures

  • Key: UML14-92
  • Legacy Issue Number: 4927
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
    they point at inputs/outputs of contained actions. Groups referred
    input pins together that receive the value from the same parameter.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

match/correspond clarfication

  • Key: UML14-91
  • Legacy Issue Number: 4917
  • Status: closed  
  • Source: International Business Machines ( Mr. Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes. The
    specification text does not clearly explain how 'match' and 'correspond'

    • dependencies are to be used. See figure 2-57, page 2-307 are used in
      the spec. Are these intended to be illustrative? Are they constraints
      on the values passing thru input and output pins. What is the
      difference between 'match' and 'correspond'?
  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StartStateMachine clarification

  • Key: UML14-93
  • Legacy Issue Number: 4936
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock] Does StartStateMachine cause the intial state to be
    entered and its outgoing transition taken? Ie, what is the semantics in
    relation to the RTC step.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace.contents

  • Key: UML14-90
  • Legacy Issue Number: 4848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current definition of the operation Namespace.contents is:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement -> union(self.namespace, contents)

    (UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

    The last line of this definition seems wrong, since the "union" operation
    must have a single parameter.

    The former definition of this operation did not present any contradiction
    between text and OCL expression:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement

    (UML Semantics, version 1.1 page 32)

  • Reported: XMI 1.3 — Tue, 26 Feb 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adding events to the class definition

  • Key: UML14-85
  • Legacy Issue Number: 4740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The proposal is to add an optional fourth compartment to the
    class artifact that lists events that are accepted by that
    class.

    If a class is 'Active', it will have an associated
    state/activity model. This state/activity model will respond to
    events sent to that class. At the moment the only way to
    determine what events can be accepted by a class is to observe
    its state/activity model. Very clumsy!

    A workaround is to list events in the operations compartment
    and label them with an appropriate stereotype <<event>> for
    example. This should only be a temporary solution, since events
    are no more operations than they are attributes.

    Events need to be part of the class definition.

  • Reported: XMI 1.3 — Fri, 7 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parametrizable model elements not shown

  • Key: UML14-17
  • Legacy Issue Number: 1209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
    ModelElements". Implicitly not to all ModelElements. Which ModelElements
    can
    and which cannot be templates?
    Some clarifications would be welcome, in what concerns the
    parametrisation of other kind of model elements, such as packages,
    operations and methods.

  • Reported: XMI 1.0 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency regarding guards on forks

  • Key: UML14-119
  • Legacy Issue Number: 5745
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards.
    The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

    However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

    Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines?

  • Reported: XMI 1.3 — Fri, 1 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

spelling of the word Use Case

  • Key: UML14-118
  • Legacy Issue Number: 5744
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    I have a question about the spelling of the word Use Case. The different
    >spellings used everywhere are a little bit irritating to me (but this may
    >not be the case for other people). I think that it should be one fixed
    >spelling of the word defined i UML. But even in the UML specification I
    >found three different spellings on the same side: Use Case, use case and
    >UseCase. In a book I'm reading they use the following spelling: Use Case
    >and, when used with other words, Use-Case (Realization for example).

  • Reported: XMI 1.3 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is an unnecessary condition in rule 1 of the Namespace element

  • Key: UML14-110
  • Legacy Issue Number: 5732
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rule 6 of the Method element isn't formulated well

  • Key: UML14-109
  • Legacy Issue Number: 5731
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is a misprint in rule 2 of the Object element: “Stimuli” instead of “

  • Key: UML14-115
  • Legacy Issue Number: 5738
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are misprints with numeration of rules of the Instance element

  • Key: UML14-114
  • Legacy Issue Number: 5737
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There are misprints with numeration of rules of the Instance element

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

there is something wrong with rule 3 of the Trace element

  • Key: UML14-112
  • Legacy Issue Number: 5735
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The first sentence is not consistent with figure 2-9 on page 2-17

  • Key: UML14-120
  • Legacy Issue Number: 5763
  • Status: closed  
  • Source: Combitech Systems ( Per Tengdahl)
  • Summary:

    The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1.." and not "".

  • Reported: XMI 1.3 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong alphabetical order: DataValue section should be before DestroyAction

  • Key: UML14-113
  • Legacy Issue Number: 5736
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Wrong alphabetical order: DataValue section should be before DestroyAction section.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add rule to Namespace element

  • Key: UML14-111
  • Legacy Issue Number: 5734
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is a misprint in rule 1 of the SubsystemInstance element

  • Key: UML14-116
  • Legacy Issue Number: 5739
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

font sizes

  • Key: UML14-117
  • Legacy Issue Number: 5740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Using or implementing an interface of a Subsystem

  • Key: UML14-69
  • Legacy Issue Number: 4619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem.

    Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen.

    Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications.

    Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility.

  • Reported: UML 1.4 — Mon, 15 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD

  • Key: UML14-68
  • Legacy Issue Number: 4617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The cited sections refer to the property "isPolymorphic" for operations of a class (2.5.4.3), operations in an interface (2.5.4.6), and receptions (2.9.2.17). Issue 1165 indicates that "Operation:isPolymorphic" was renamed to "Operation:isLeaf" in UML 1.3. The XML attribute "isPolymorphic" does not exist in either the UML 1.3 or UML 1.4 XMI DTD. The cited sections should be changed to accurately describe the means by which polymorphism is indicated.

  • Reported: UML 1.4 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optimize Instance data values

  • Key: UML14-67
  • Legacy Issue Number: 4504
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations.

    There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances.

    Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode.

    NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost).

  • Reported: XMI 1.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component notation: showing delegation of messages

  • Key: UML14-66
  • Legacy Issue Number: 4465
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current notation does not provide for showing how method calls
    or messages to a component interface are delegated (or propagated) to the
    interfaces in components or implementation classes that reside in the
    component. This is sometimes referred to as the "wiring problem."

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: State containment problem

  • Key: UML14-75
  • Legacy Issue Number: 4729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a State can either be contained as a
    "subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
    a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
    2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
    concrete subclasses of Namespace restrict their owned elements to exclude
    State). The latter containment does not seem to make a lot of sense.

    Fortunately, the description of a StateMachine states that "This means that
    a state machine owns its transitions and its top state. All remaining states
    are transitively owned through the state containment hierarchy rooted in the
    top state." [UML 1.4, pp. 2-153].

    The question is: does this mean that a State is restricted to being
    contained in a CompositeState or a StateMachine? If not, please explain the
    meaning of e.g. a State contained directly in an otherwise empty Package?

    If the mentioned restriction is intended, it should be stated
    unambiguously so in the wellformedness rules for State:

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Action problem in Collaborations

  • Key: UML14-74
  • Legacy Issue Number: 4728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    n UML 1.4, an Action is only used in the context of a StateMachine or a
    CollaborationInstanceSet.

    In a CollaborationInstanceSet, an Action is required as the cause of a
    Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
    a Namespace (or in the context of a StateMachine, which is irrelevant here),
    it cannot be contained in the Stimulus, nor in the Instances the Stimulus
    connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
    are part of. The "nearest" possible container is the Package that happens to
    contain the CollaborationInstanceSet.

    Intuitively, this makes no sense - used in this context, the Action is
    clearly part of the InteractionInstanceSet, or the participating Instances
    or Stimuli.

    If this error report is rejected, please elaborate on the intended
    containment structures for Collaboration instances.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Event containment problem

  • Key: UML14-80
  • Legacy Issue Number: 4734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, an Event is defined as "...a
    specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
    is used exclusively in the context of state machines, as triggers of state
    transitions [UML 1.4, pp. 2-147, fig. 2-24].

    Because Event is a direct subclass of ModelElement - and because no other
    composite containments are specified for Event or any of its subclasses - it
    must be compositely contained as an ownedElement in a ClassifierRole, Model.
    Package, Artifact or Node (all other concrete subclasses of Namespace have
    restricted their owned elements to exclude Event).

    The question is: is this containment intended, or should an Event be
    contained in e.g. the StateMachine in which it is used? If the currently
    allowed containment IS intended, please explain the semantics of e.g. an
    Event contained in an otherwise empty Package (or even Model).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Stimulus containment

  • Key: UML14-79
  • Legacy Issue Number: 4733
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Stimulus is a ModelElement representing
    a communication between two instances [UML 1.4, pp. 2-106]. It is used
    exclusively in the context of collaborations, as part of an
    InteractionInstanceSet [UML 1.4, pp. 2-120].

    Because Stimulus is a direct subclass of ModelElement - and because no other
    composite containments are specified for Stimulus - it must be compositely
    contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
    or Node (all other concrete subclasses of Namespace have restricted their
    owned elements to exclude Stimulus).

    Having the Stimulus be part of any of these classes makes no sense, as it is
    intuitively part of the InteractionInstanceSet.

    Proposed remedy: change the association between InteractionInstanceSet and
    Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
    containment (with Stimulus as the part).

    Alternatively, please clarify the intended semantics of each of the
    currently allowed containments listed above

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Transition containment problem

  • Key: UML14-77
  • Legacy Issue Number: 4731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
    contained either as an "internalTransition" in a State, as a "transition" in
    a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
    Package, Artifact, Node or ClassifierRole (other containers excluded because
    of restrictions they make on the "ownedElement" containment in their
    wellformedness rules). The latter containment does not seem to make a lot of
    sense.

    The question is: is the containment of a Transition as an "ownedElement"
    intended? If so, please explain the meaning of e.g. a Transition contained
    directly in an otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Transition, e.g.:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: ExtensionPoint containment problem

  • Key: UML14-76
  • Legacy Issue Number: 4730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
    can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
    Artifact, Node or ClassifierRole (other containers excluded because of
    restrictions they make on the "ownedElement" containment in their
    wellformedness rules).

    The questions are: what is the intended meaning of an ExtensionPoint in eg.
    an otherwise empty Package? Why isn't the ExtensionPoint contained in the
    UseCase it extends, as would appear more logical to the uninitiated?

    Suggestion: change the association between ExtensionPoint and UseCase [UML
    1.4, pp. 2-135] to an unconditional composite containment (with
    ExtensionPoint as the part).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Feature containment problem

  • Key: UML14-78
  • Legacy Issue Number: 4732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
    contained either as an "feature" in a Classifier, or as an "ownedElement"
    [UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
    (other containers excluded because of restrictions they make on the
    "ownedElement" containment in their wellformedness rules). In addition an
    Attribute (subclass of Feature) may be contained as a "qualifier" in an
    AssociationEnd [UML 1.4, pp. 2-14].

    The question is: is the containment as an "ownedElement" intended? If so,
    please explain the meaning of e.g. an Operation contained directly in an
    otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Feature:

    self.namespace = null

    Remarks:
    ========
    It should be noted that the standard does make a number of partly
    contradictory statements which seem to indicate that Features can not be
    used as ownedElements:

    Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
    Classifier."
    Page 2-36: "A feature [...] is encapsulated within a Classifier."
    [contradicts with the statement below].
    Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
    case it is a feature) or an AssociationEnd (in which case it is a qualifier)
    but not both."
    Page 2-42: "Method is a declaration of a named piece of behavior in a
    Classifier"
    Page 2-45: "Operation is a BehavioralFeature that can be applied to the
    Instances of the Classifier that contains the Operation.".

    These statements could however be made unambiguous by adding the mentioned
    wellformedness rule.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance to the UML" pp xxxi -- Editorial?

  • Key: UML14-72
  • Legacy Issue Number: 4662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was just reading the intro to UML 1.4, and may have found a typo. In the
    "Compliance to the UML" pp xxxi, it shows a table of package dependencies
    and states that complying with a package requires compliance with it's
    dependent packages.

    Core is shown as dependent on Data Types and Extension Mechanisms, and
    Extension Mechanisms is shown as dependent on Data Types and Core, leading
    to a circular relationship.

  • Reported: UML 1.4 — Sun, 21 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nameclash in UML 1.4

  • Key: UML14-71
  • Legacy Issue Number: 4645
  • Status: closed  
  • Source: University of Technology, Sydney ( Brian Henderson-Sellers)
  • Summary:

    As far as I can see there is a name clash in UML 1.4.
    <<implementation>> is used as both
    (1) a stereotype of Generalization to mean implementation (or private)
    inheritance
    and
    (2) a stereotype of Class to mean the coding or implementation details of
    a Class

  • Reported: UML 1.4 — Sat, 27 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Using OCL at the meta-model level

  • Key: UML14-70
  • Legacy Issue Number: 4626
  • Status: closed  
  • Source: Colorado State Univ, Dept of Computer Science ( Robert France)
  • Summary:

    A. page 2-55; 2.5.3.6 Binding
    constraint [1]

    self.client.oclIsKindOf(self.supplier)

    Using my current understanding of OCL this seems wrong for the following
    reason:
    1. self.client returns an element at the M1 level (a UML model construct)
    2. the oclIsKindOf predicate compares the type of self.client
    (I assume the type of self.client is a metaclass at the M2 level) with the
    argument (which I assume from the definition of the predicate
    is a type and is thus an M2 element).
    3. self.supplier is not an M2 element.

    B. page 2-61 constraint [5] (similar comments as above)

    Am I misinterpreting self, OclIsKindOf, ...?

  • Reported: UML 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Action containment error

  • Key: UML14-73
  • Legacy Issue Number: 4727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Because Action is a ModelElement, it may be contained as an ownedElement
    [UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
    Node or Collaboration (all other concrete subclasses of Namespace restrict
    their owned elements to exclude Action).

    Because Actions are only used in the context of either a StateMachine or a
    CollaborationInstanceSet, this containment does not seem to make sense.

    In order to exclude these containments, the wellformedness rules for Action
    could include the following statement:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard in current metamodel can be replaced by Constraint with stereotype

  • Key: UML14-19
  • Legacy Issue Number: 2020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Guard metatype in the current metamodel contains only one attribute
    of type BooleanExpression. Since a guard is semantically equivalent to
    a Constraint on the transition, we can remove the Guard metaclass and
    add e standard stereotype <<guard>> for Constraints, with the same
    semantics.

    It simplifies the metamodel by unifying the Guard and Constraint concepts.
    It also allows OCL as the optional language to write the guard expression.

    Within the OCL specification, it should be checked if there are any
    additions that need to be made to support everything neded to express
    udseful guards.

  • Reported: XMI 1.0 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for notation for dealing with evolution of UML models

  • Key: UML14-18
  • Legacy Issue Number: 1512
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:

  • Reported: XMI 1.0 — Mon, 8 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing OCL

  • Key: UML14-25
  • Legacy Issue Number: 2289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to note that in the UML Semantics specification (versions 1.1
    and 1.2) the third well-formedness rule for Association does not have an
    OCL expression. It has only the natural language expression.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL needs to be added

  • Key: UML14-24
  • Legacy Issue Number: 2278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only binary associations may be aggregates. There needs to
    be OCL added to do this.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the missing OCL

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ElementOwnership

  • Key: UML14-26
  • Legacy Issue Number: 2290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
    declares ElementOwnership as an AssociationClass. This appears to be a
    violation of MOF compliance, since the MOF meta-meta-model does not support
    the notion of an AssociationClass.

    Of course one could extrapolate AssociationClass from the MOF
    meta-meta-model since it does support both Association and Class, and one
    could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
    extrapolated MOF AssociationClass. However, two architects might
    extrapolate these mappings in perfectly valid but different manners, since
    there is no standard mapping for a MOF AssociationClass. Apparently such
    an extrapolation has been performed in order to derive the IDL for the UML
    meta-model that concerns ElementOwnership, but doing this without a
    standard mapping seems dangerous.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

extension to the notation for a transition

  • Key: UML14-28
  • Legacy Issue Number: 2336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to make an appeal for an extension to the notation for a transition
    to allow its effect to be specified declaratively rather than only imperatively by
    means of an action sequence, e.g.

    e() / [p]

    While I realize there are ways to work around this (e.g. by writing "e() / pTrue()"
    where the query pTrue() has the postcondition "result = p and in targetState"), I
    think the issues are readability and ease of use.

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 19 semantic doc. name

  • Key: UML14-23
  • Legacy Issue Number: 2277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 19 semantic doc. name is described here but is not shown as
    a metalevel attribute on Figure 6. It should be.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.1.section 4.2:editorial

  • Key: UML14-22
  • Legacy Issue Number: 2276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Aggregation: "when on target end, specifies whether target end
    with respect to source end". I think target and source are the wrong
    way round here.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

User-defined symbols for tagged values and properties

  • Key: UML14-27
  • Legacy Issue Number: 2291
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties

    {ordered}

    ,

    {frozen}

    and

    {add only}

    may define they own user-defined icons for those properties, because UML does not define them.

    Suggested Solution:
    UML users should be allowed to define specific symbols and icons for tagged values and properties.

  • Reported: XMI 1.0 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associate a predicate with a state

  • Key: UML14-29
  • Legacy Issue Number: 2337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Related to the previously submitted issue regarding the declarative specification of
    the effects of transitions, I would like to suggest that it be possible to associate
    a predicate with a state.

    Such a predicate (e.g. written in OCL) would appear within the state box in the
    notation, just below the name of the state.

    Rather than extend the notation directly, I suggest this be a predefined property,
    e.g.

    {predicate = boolean-expression}

    .

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7 p. 43 of the UML semantics guide

  • Key: UML14-21
  • Legacy Issue Number: 2208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On Figure 7 p. 43 of the UML semantics guide,
    Template is described as a shared aggregate of its templateParameters,
    while Binding (representing an instantiation of a Template) is described
    as a composite aggregate of the actual arguments.

  • Reported: XMI 1.0 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationEnd needs ownerScope

  • Key: UML14-20
  • Legacy Issue Number: 2083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
    model a static (as in Java) relationship? Currently, it appears to only be
    possible using an Attribute of Classifier.

  • Reported: XMI 1.0 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

running a “Check Model” in Rose you get the following errors

  • Key: UML14-151
  • Legacy Issue Number: 6089
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When running a “Check Model” in Rose you get the following errors. Of which I am sure you are aware of. But do these errors indicate the absence of the parent element in the particular package or should the Specialize relation be deleted?

    12:52:41| [Check Model]

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Packages

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Classes

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Collaborations"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "InternalStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "CompositeStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "ActivityEdge"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "OutputPin"

    12:52:42| to Item with name Logical View::UML::Infrastructure::Core::Foundation::Classifiers::TypedElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Message"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Type"

    12:52:42| to Item with name Logical View::InfrastructureLibrary::Core::Constructs::Type

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "State"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

  • Reported: UML 1.5 — Sat, 9 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify wording on executable activity nodes

  • Key: UML14-154
  • Legacy Issue Number: 6092
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Name: Jim Frank
    Company: IBM
    mailFrom: joachim_frank@us.ibm.com
    Nature: Clarification
    Severity: Significant
    Subject: Clarify wording on executable activity nodes

    In the Activities chapter, an action "is an executable activity node
    that is the fundamental unit of executable functionality in an activity,
    as opposed to control and data flow among actions." Aren't control and
    data flow required to execute an action? The clause after the comma
    should be removed, and perhaps replaced with a sentence saying actions
    are used with control/data flow.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outgoing edges from input pins

  • Key: UML14-153
  • Legacy Issue Number: 6091
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    (Quote from Semantics of CompleteStructuredActivities) "An object
    node attached to a structured activity node is accessible within the
    node. The same rules apply as for control flow. An input pin on a
    structured activity node implies that no action in the node may begin
    execution until all input pins have received tokens. An output pin on
    a structured activity node will make tokens available outside the
    node only after no tokens left in the node or its contained nodes
    recursively."

    So input pins on structured activity nodes are "accessible within the
    node" (as one would expect), but a constraint on InputPin says "input
    pins have incoming edges only". So how are they accessed from within
    the structured activity node? Analogous question for output pins of
    structured activity nodes, which can have outgoing edges only.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pg. 580/Stereotype typo

  • Key: UML14-150
  • Legacy Issue Number: 6076
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The second paragraph of subsection "Notation" reads "When a stereotype
    is applied to a model element (an instance of a stereotype is linked to
    an instance of a metaclass), the name of the stereotype is shown within
    a pair of guillemets above the name of the Stereotype."

    I think the sentence should end with "... name of the model element".
    Otherwise the stereotype's name would be mentioned twice.

  • Reported: UML 1.5 — Wed, 27 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    End the sentence with “name of the model element”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pg.470/entry and exit points for composite states

  • Key: UML14-149
  • Legacy Issue Number: 6075
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Two OCL constraints for entry and exit pseudostates of state machines (numbered [9] and [10]) only allow these psuedostates to be defined for the topmost regions of a state machine. This restriction is completely unnecessary and precludes common design patterns and should be removed. (In fact, from discussions with the authors of the spec, it seems that they were included due to a misunderstanding between two of the authors.)

  • Reported: UML 1.5 — Fri, 22 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicities diagram in section 7.4

  • Key: UML14-148
  • Legacy Issue Number: 6074
  • Status: closed  
  • Source: DeveloPeer Inc. ( Javier Estrada)
  • Summary:

    The Multiplicities diagram in section 7.4 defines two associations with ValueSpecification, namely upperValue and lowerValue. However, the constraints stated in section 7.4.1 for MultiplicityElement, are defined in terms of upperBound() and lowerBound()

  • Reported: UML 1.5 — Tue, 19 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action should be concrete

  • Key: UML14-156
  • Legacy Issue Number: 6094
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Action should be concrete. The description of the "effect" attribute
    says: "An optional text specification of the effect of the action. This
    may be used to indicate the behavior of an action without specialization
    into a subclass, ... " We think this is a good concept, and would like
    to instantiate Action for activity nodes whose behavior is only verbally
    described. Behavior, too.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    In Figure 176, make Action concrete.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Edge constraint for control nodes

  • Key: UML14-155
  • Legacy Issue Number: 6093
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The constraint for ControlNode ("The edges coming into and out of a
    control node must be either all object flows or all control flows.") is
    inconsistent with the semantics for JoinNode, which permit mixed types
    of incoming edges. Likewise a merge node can merge control and data
    flows. What type of edge should be outgoing in this case?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove constraint [1] for Control Node, p 317.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Strange notation in Figure

  • Key: UML14-146
  • Legacy Issue Number: 6072
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The figure showing a use case with an associated state machine behaviour use lozenges (rectangles with rounded ends). This notation is obsolete

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Variable and Pin multiplicity

  • Key: UML14-152
  • Legacy Issue Number: 6090
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text refers to multiplicity of Variable and Pin, but they do not
    inherit from MultiplicityElement

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Glossary in 03-08-02

  • Key: UML14-147
  • Legacy Issue Number: 6073
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The certification includes the glossary. However, it is missing from 03-08-02, it was there in in 03-07-06.

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initial state for composite states - OCL example and missing constraint

  • Key: UML14-100
  • Legacy Issue Number: 5273
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue was triggered by what seemed to be an ill-formed state machine
    example which revealed a deeper lack of rigor in the spec.

    The example state machine in section 6.5.10 (illustrating oclInState) does
    not have an initial pseudostate within the 'Off' state. Section 3.80.2
    indicates that this is mandatory:
    "A transition drawn to a composite state boundary indicates a transition to
    the
    composite state. This is equivalent to a transition to the initial
    pseudostate within the
    composite state region. The initial pseudostate must be present."

    [Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
    object.oclInState(Off:NoPower) should have a double colon:
    object.oclInState(Off::NoPower)].

    If indeed it is mandatory to have an initial state where there is a
    transition to a composite state (this does seem sensible for
    predictability), this should be reflected in a constraint within the
    abstract Syntax (section 2.12) to the effect that a CompositeState with
    'incoming' Transitions must contain an initial PseudoState.

    For example 2.12.4.3 contains the following which implies an initial
    pseudostate, though uses the ill-defined 'default transition' as well as
    'initial transition':
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, the
    default
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

    Proposed Resolution
    -------------------

    1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
    composite with a transition to 'Standby'.

    2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
    should have a double colon: object.oclInState(Off::NoPower)

    3. Add the following constraint to section 2.12.3.1
    [7] A composite state with an incoming transition must have an initial
    state.
    self.incoming->notEmpty() implies
    self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
    Pseudostate | p.kind = #initial)->size = 1

    4. Alter the section in 2.12.4.3 to read as follows:
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, there
    must be an initial state and the initial
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

  • Reported: XMI 1.3 — Thu, 9 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 - Partition relates to nothing

  • Key: UML14-99
  • Legacy Issue Number: 5269
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 1.4 has no association for showing what a Partition relates to.
    Typically this would be something representing a role in a process.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In v1.4, section 3.84.1 the paragraph on semantics

  • Key: UML14-104
  • Legacy Issue Number: 5657
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    "An Activity Diagram is a special case of a state machine in which the
    states represent performance of actions or subactivitities and the
    transitions are triggered by the completion of actions or subactivities. It
    represents the state machine of a procedure itself."

    But in Section 2.13.1 it says:

    "An activity graph is a special case of a state machine that is used to
    model processes involving one or more classifiers. Its primary focus is on
    the sequence and conditions for the actions that are taken, rather than on
    which classifiers perform those actions. Most of the states in such a graph
    are action states that represent atomic actions; that is, states that invoke
    actions and then wait for their completion. Transitions into action states
    are triggered by events, which can be

    • the completion of a previous action state (completion events),
    • the availability of an object in a certain state,
    • the occurrence of a signal, or
    • the satisfaction of some condition.
      "

    The latter statement implies that (a) events other than completion of prev
    activity can be triggers and (b) entire processes, not just procedures can
    be modeled in ADs.

    Which one is it?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.13.4.3

  • Key: UML14-103
  • Legacy Issue Number: 5656
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    2) Section 2.13.4.3 says

    "Unless there is an explicit "fork" that creates orthogonal obect
    states only one of an object flow state's outgoing transitions will fire as
    determined by the guards of the transitions",

    which seems to require that if you want to "feed" the object to multiple
    actions, you will need a "fork" bar. But then 3.90.2.2 says:

    "The same object may be (and usually is) the output of one action
    and the input of one or more subsequent actions".

    This would seem to suggest that a "fork" bar is not required. Please
    clarify.

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Issue - Inconsistency between UML 1.3 XMI and DTD

  • Key: UML14-101
  • Legacy Issue Number: 5525
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
    exist in the UML metamodel XMI file. This causes problems for my product
    which is metamodel-driven so reports an error when an import attempts to
    supply a value for the non-existent reference. This is strictly speaking a
    bug in the DTD (since it's not generated according to the XMI rules):
    however changing the DTD might cause inconvenience for vendors who are
    making use of it, and because not having the reference would make processing
    the tags much harder.

    At UML 1.4 the reference has been added to the metamodel, which suggests
    that the metamodel rather than the DTD be fixed. However this could require
    a restructuring to avoid circular package dependencies [see UML issue 3735].

    The same issue applies to the 'stereotype' reference on ModelElement - again
    it should ideally be added to the metamodel.

    The reason I'm raising the issue on UML 1.3 is that this is the chosen
    version for interoperability work. A decision is needed as to which way to
    resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
    1.4.

  • Reported: XMI 1.3 — Fri, 19 Jul 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section number duplicated

  • Key: UML14-107
  • Legacy Issue Number: 5685
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    Probably an Action Semantics RTF Issue, but one that may be addressed
    in an UML RTF.

    In the UML 1.5 spec in the action semantics chapter, sections numbers
    2.16 and 2.17 are duplicated. The section content appears all right
    but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.

    The document simply needs consistent renumbering of that chapter.

  • Reported: XMI 1.3 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.90.2.2

  • Key: UML14-106
  • Legacy Issue Number: 5659
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    Section 3.90.2.2 says

    "In other words when a state prodices an outpout that is input to the
    subsequent state, that object flow relationship implies a control
    constraint."

    I take it that this is not the same as isSynch being true? That is isSynch
    means that an object in an object flow is rather like a token in a Petri
    net. ie once it flows out to the consuming state, its gone from its place.
    Is that correct?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState

  • Key: UML14-97
  • Legacy Issue Number: 5267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
    oclIsKindOf, which should only take a single argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_context_raisedSignal

  • Key: UML14-96
  • Legacy Issue Number: 5005
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    The
    association in question is not named in the UML 1.4 interchange model. The
    name "A_context_raisedSignal", is an artificial one that was created by the
    program that created the DTD. It was using an algorithm recommended by the
    MOF RTF for naming unnamed associations. However, it would seem to be wise
    policy for this association to have a name. This would remove any
    dependency on the vagaries of various MOF tools.

  • Reported: XMI 1.3 — Tue, 19 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How does one indicate the target object for a CallState

  • Key: UML14-102
  • Legacy Issue Number: 5655
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    How does one indicate the target object for a CallState (i.e. the actual
    object that executes the stated action/method)? If the target action takes
    no parameters then it may be possible to say that the target object is just
    the object flowing into the CallState. But what if it does take parameters?
    (e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
    more than one object to be flowing into the CallState and leads to an
    ambiguity about which constitutes the target and which the parameter.

    P.S. The actual object may be passed around by the activity diagram, so it
    is not possible to show it statically on a swimlane (even if that is the
    recommended way)

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

parameters of object flow states

  • Key: UML14-105
  • Legacy Issue Number: 5658
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    parameters of object flow states – The Notation section of the UML 1.4
    Spec does not discuss it, nor is an example provided. I am still in the dark
    about how parameters are supposed to be used in the context of object flow
    states. Are output parameters supposed to be like reference parameters in
    the Algol style languages?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-formedness rules for 2.12.3.8

  • Key: UML14-98
  • Legacy Issue Number: 5268
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
    incorrect use of oclIsKindOf, which only takes one argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Swap rule 2 and rule 3 of the Binding element

  • Key: UML14-108
  • Legacy Issue Number: 5730
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Swap rule 2 and rule 3 of the Binding element. It improves readability

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF rules should disallow certain composition relationships

  • Key: UML14-49
  • Legacy Issue Number: 3735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF rules should disallow composition relationships in instance metamodels
    where the container is in one MOF Package and the contained item is in
    another MOF Package and a dependency of the first package on the second is
    not allowed by the physical version of the metamodel due to MOF-imposed IDL
    generation rules.

    Reason for the issue:

    In the process of implementing an XMI-based interchange for UML 1.3, I have
    encountered a serious problem.

    This problem has to do with a divergence between the "Logical" and
    "Physical" model for UML 1.3 caused by rules imposed by MOF.

    In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
    version), "Preconditions for IDL Generation", requires that there be no
    cyclical dependencies between ModelElements in a meta-model.

    However, the UML 1.3 specification (June 1999) has a cyclical dependency
    between the Core and the Extension Mechanisms packages in the metamodel (See
    Figure 2-4). This cyclical dependency is explicitly disallowed by the
    precondition cited above.

    This circular dependency was removed from the "Physical Model" for UML 1.3
    in order to allow CORBA IDL and XMI DTD declarations in conformance with the
    precondition. As a result of the removal of this dependency, there are
    tremendous difficulties expressing the composition relationship between the
    UML ModelElement and the UML Tagged Value (see figure 2-10). In fact, the
    TaggedValue XML elements cannot even be in the exported UML Package element
    – they must be placed outside of it. This greatly complicates the export
    and import of UML 1.3 model files.

  • Reported: UML 1.3 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for inherited associations

  • Key: UML14-48
  • Legacy Issue Number: 3682
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The CWM submitters needed to display inherited associations on some class
    diagrams to enhance understandability. These were not intended to be
    derived associations; that is, there was no intention to specify additional
    computational machinery when showing these inherited associations.
    Unfortunately, the MOF and UML have no succint way to display inherited
    associations. The CWM submitters placed the "/" derived prefix on the
    association end names in the class diagrams. At the same time, in order to
    prevent the generation of additional computational machinery, they omitted
    the inherited association from the normative XMI rendition of the metamodel.
    This was probably a reasonable choice under the circumstances. However, it
    means that the class diagrams and the XMI representation of the metamodel
    conflict with one another.

    It is very common to need to show inherited associations on a class diagram.
    We ran into this when we specified the CORBA metamodel for the CORBA
    Component Model submission. We used derived associations in the class
    diagrams as well. However, we retained the derived associations in the XMI
    rendition of the metamodel. In order to prevent additional computational
    machinery from being generated, we stereotyped the associations as
    <<implicit>>. This stereotype is defined in the UML specification but not
    in the MOF specification and says that an association is only conceptual and
    not manifest. We then made sure that the generator producing the IDL and
    XML DTDs was sensitive to the <<implicit>> stereotype. This had the
    advantage of maintaining consistency between the class diagrams and the XMI
    rendition of the metamodel. Of course this is also a non-standard
    approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
    generators to understand it.

    The lack of a standard means for representing inherited associations in
    class diagrams is thus resulting in a proliferation of non-standard
    approaches in adopted OMG metamodels. This could become unmanageable as the
    number of metamodels grows. A standard means should be specified.

  • Reported: UML 1.3 — Mon, 3 Jul 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conflicting constraint between ActivityGraph and StateMachine.

  • Key: UML14-52
  • Legacy Issue Number: 4083
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Since an ActivityGraph is derived from a StateMachine its
    constraints must be consistent with that of a StateMachine. If an
    ActivityGraph has a Package as its context it violates the constraint
    inherited from StateMachine.

    ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
    (self.context.oclIsTypeOf(Package) xor
    self.context.oclIsKindOf(Classifier) xor
    self.context.oclIsKindOf(BehavioralFeature))

    StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
    self.context.oclIsKindOf(BehavioralFeature) or
    self.context.oclIsKindOf(Classifier)

    One way to avoid this problem is to change the StateMachine constraint to be
    applicable when self is oclIsTypeOf(StateMachine) so the constraint is not
    applied to it children.

    A general mechanism to disable inherited constraints could also solve the
    problem.

  • Reported: UML 1.3 — Wed, 29 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes obsolete in UML 1.3

  • Key: UML14-51
  • Legacy Issue Number: 3999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    the association between StructuralFeature and Classifier should be
    removed. Attributes can not describe more information than
    Associations/AssociationEnds can. Therefore it is obsolete and confuses
    the user of UML, which to choose when modeling.

    On page 3-40 in the UML 1.3 specification it says: "Note that an
    attribute is semantically equivalent to a composition association;
    however, the intent and usage is normally different."

    If the semantics are equivalent, then it is impossible to distinguish
    between them. There is no extra layer of meaning above the semantics
    layer that can distinguish between two things with equal semantics.
    Semantics is meaning. I think this sentence is contradictory. I have not
    been able to find out what the difference in "intent and usage" is. If
    this is defined, it will obviously make the semantics of the two
    different.

    To improve the readability of class diagrams when everything is
    associations, I propose that associations should be possible to
    represent as text in the compartment where attributes are written today.

  • Reported: UML 1.3 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface of an object

  • Key: UML14-50
  • Legacy Issue Number: 3783
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    This is a request for an interpretation of UML 1.3.

    The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

    -------- Background -------

    Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

    The UML submission said:

    "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."

    UML 1.3 says:

    "2.5.4 Semantics

    "Interface

    "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

    [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

    --------

    I am hoping this is easy to interpret and can be resolved quickly.

  • Reported: UML 1.3 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why is a StateMachine's top a State instead of a CompositeState?

  • Key: UML14-46
  • Legacy Issue Number: 3569
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Every StateMachine must have one top State. However, there is an
    OCL constraint that says that the top State must be a CompositeState
    (Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
    2-141). So, why not make the top relationship from StateMachine to
    CompositeState instead of from StateMachine to State. The constraint can
    then be eliminated.

  • Reported: UML 1.3 — Tue, 18 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-45
  • Legacy Issue Number: 3391
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

    The various places that uninterpreted strings are used in UML should
    support multiple languages. For example, the Expression metaclass has
    an metaattribute for language and another for the uninterpreted string.
    This should be a set of such pairs. Then code generators can target
    multiple languages from the same model.

  • Reported: XMI 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Efficient diagrammatic notation for Collaboration Specifications

  • Key: UML14-42
  • Legacy Issue Number: 3368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

    Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

    I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling ) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Statemachine/state as Namespace

  • Key: UML14-41
  • Legacy Issue Number: 3341
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    I am not sure if this qualify as an Issue, but I what just wondering
    why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: XMI 1.1 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Missing notation mapping for association in composite

  • Key: UML14-40
  • Legacy Issue Number: 3291
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    No mapping for this in mapping section, p 3-77:

    [p 3-75, Notation section for Composition] An association drawn
    entirely within a border of the composite is considered to be
    part of the composition.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document 99-06-08 - UML Spec

  • Key: UML14-47
  • Legacy Issue Number: 3632
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'd find the document easier to digest if Chap 2 had some pictures in it.
    >>
    >>I know that the semantics is supposed to be independent of the
    >>representation. However, Chap 3 does contain some semantics in it for
    >>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
    >>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
    >>picture of the diamond shaped association end for aggregations, it would be
    >>easier to follow what the document is talking about.
    >>
    >>At least sections 3.55.1 and 2.11.4 for instance might have links, even if
    >>only footnotes, to connect actor notation and semantics.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ClassifierRoles should be independent of specific underlying base Classifi

  • Key: UML14-43
  • Legacy Issue Number: 3376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example.

    Collaboration Templates don't do the trick; templates serve a different purpose.

    Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 issue: Top state in activity graphs

  • Key: UML14-44
  • Legacy Issue Number: 3382
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Top state in activity graphs

    The state machine meta-model currently requires a top state, whereas
    activity graphs should not. Composite states are not required for
    activity graphs (wf [2] for PseudoState, p 2-166).

  • Reported: XMI 1.1 — Tue, 29 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issues and bugs on the UML 1.4 Draft

  • Key: UML14-7
  • Legacy Issue Number: 4300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

    Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

    ---Begin of issues---------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

    (p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

    (p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

    (p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

    (p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

    ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

    Please clarify or correct the statement.

    (p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

    (p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

    (p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

    (p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

    (p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

    (p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

    (p. 3-3) Typographical/Editorial: There is no Part 8.

    (p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

    (p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

    (p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

    (p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

    (p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

    (p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

    (p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

    (p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

    (p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

    Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

    Please clarify

  • Reported: UML 1.3 — Sun, 13 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class TaggedValuewill two association-ends with the same name "stereotype"

  • Key: UML14-6
  • Legacy Issue Number: 4187
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    In the physical metamodel for extensions (Figure 6-8) the class
    TaggedValuewill have two association-ends with the same name "stereotype".
    One
    from the association with the superclass ModelElement
    (extendedElement-stereotype) and one on its own (requiredTag-stereotype).

  • Reported: UML 1.3 — Wed, 31 Jan 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    in Uml 1.4 final, there is only one association end with this name

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2-15 of the uml 1.4 spec

  • Key: UML14-14
  • Legacy Issue Number: 4531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

  • Reported: UML 1.3 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix in diagram: metaclass name is truncated (ModelElement => ModelÂ…). Duplicate of 4349

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 2-163, the statemachine semantics escription

  • Key: UML14-13
  • Legacy Issue Number: 4508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty

    I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state.

    On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add?

    On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

  • Reported: UML 1.3 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isPolymorphic is never in a diagram

  • Key: UML14-16
  • Legacy Issue Number: 5923
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic);

    2.5.4.3 Class has methods which can be polymorphic (isPolymorphic)

    2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic)

    But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

  • Reported: UML 1.3 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This is a duplicate of issue 4617,

  • Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rule for Package is missing inUML 1.4

  • Key: UML14-15
  • Legacy Issue Number: 4534
  • Status: closed  
  • Source: Enea Business Software ( Karin Palmkvist)
  • Summary:

    A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

  • Reported: UML 1.3 — Fri, 24 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    The rule seems to have unintentionally disappeared from 1.3 to 1.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

it's => its on page 3-150.

  • Key: UML14-10
  • Legacy Issue Number: 4453
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    it's => its on page 3-150.

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wf 2 for AssociationEnd

  • Key: UML14-9
  • Legacy Issue Number: 4450
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The second wf rule for AssociationEnd uses the OCL operation
    applied to the wrong type (max applied to multiplicities).

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    obvious error, OCL only fix.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.9.2 Abstract Syntax

  • Key: UML14-8
  • Legacy Issue Number: 4349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'.

    This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

  • Reported: UML 1.3 — Mon, 18 Jun 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix : Rose truncating the diagram, Previously fixed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation example typo in Fig. 3-99

  • Key: UML14-12
  • Legacy Issue Number: 4463
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    In the example the dependencies between the focus class and the two
    auxiliary classes should connect to the target interfaces of the auxiliary
    classes, rather than their class rectangles. (Note: this typo may be
    corrected in the formal version of the UML 1.4 specification, which is not
    yet available.)

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Diagram to be fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The glossary entry "call" should be "call state".

  • Key: UML14-11
  • Legacy Issue Number: 4454
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The glossary entry "call" should be "call state".

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Change the name of the glossary entry

  • Updated: Fri, 6 Mar 2015 20:58 GMT

elimination of the Association Class TemplateParameter

  • Key: UML14-3
  • Legacy Issue Number: 3803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9.

    My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version:

    1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association

    B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1

    2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement

    B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of *

    3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances

    B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind

    Can you help me to solve this trouble?

  • Reported: UML 1.3 — Tue, 5 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2) Page 2-49, additional operation #7 for Classifier

  • Key: UML14-2
  • Legacy Issue Number: 3531
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
    follows:

    1 oppositeAssociationEnds : Set (AssociationEnd);
    2 oppositeAssociationEnds =
    3 self.association->select ( a | a.associationEnd->select ( ae |
    4 ae.type = self ).size = 1 )->collect ( a |
    5 a.associationEnd->select ( ae | ae.type <self ) )->union
    6 (
    7 self.association->select ( a | a.associationEnd->select ( ae |
    8 ae.type = self ).size 1 )->collect ( a |
    9 a.associationEnd) )

    In line 5, the expression 'ae.type <self' is clearly wrong. I believe the
    intention may have been to test for inequality, i.e. 'ae.type <> self'.

    In line 8 'size 1' doesn't parse. I'm not sure what the intent was.

    A greater concern is that, even if corrected to address these flaws, this
    logic doesn't seem right in the case where we are dealing with an
    association where both ends are of the same type. It appears to be relying
    on detecting whether an end is opposite by testing the end's type. A fair
    number of other well-formedness rules leverage this operation in one way or
    another, so they are affected by this apparent flaw. Correcting this would
    require comparing the end instances, i.e. something like 'ae <> self' which
    does not have the same problem as 'ae.type <> self'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This issue has been fixed in UML 1.4. The correct operator is "<>"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove uses of multiple inheritance from UML meta model

  • Key: UML14-5
  • Legacy Issue Number: 3931
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model.

    Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It’s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

  • Reported: UML 1.3 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Who owns a Comment?

  • Key: UML14-4
  • Legacy Issue Number: 3860
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
    Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2, p. 2-17, Figure
    2-9 Core Package - Auxiliary Elements
    Nature: Revision
    Severity: Minor
    Summary: A Comment is shown as having a relationship to ModelElement
    (annotatedElement). However, the ownership of a Comment is not specified
    anywhere. If it should reside in a Package the OCL-WellFormedness rule for
    Package should be updated. Also, shouldn't a Comment have a text field to
    hold the annotation?

  • Reported: UML 1.3 — Mon, 18 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Add Comment to wfr listing what may be owned by a Package

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 2-47, well-formedness rule #2 for Classifier

  • Key: UML14-1
  • Legacy Issue Number: 3530
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    In the UML 1.3 specification (ad/99-06-08) there are the following problems:

    1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
    operation 'oppositeEnds' which is not defined. This probably should be
    'oppositeAssociationEnds'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT