Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UML14-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-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-1027 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings 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-1026 UML 1.4 RTF Issue: changeability in associations 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-1022 UML 1.4 RTF issue: OCL: Precedence of relational operators 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-1019 In 2.10.4, semantics of Collaboration, the 1st sentence is confusing 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-1016 Page 2-114, 2nd paragraph. It should be collaboration template 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-1015 Confusing wording 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-1012 2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam". 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-1010 Terminology: Collaboration and Collaboration Template 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-1003 UML RTF 1.4 Issue: Guard condition in collaborations poorly named. 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-1002 UML RTF 1.4 Issue: Multi-objects in collaborations 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-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-997 UML RTF 1.4 Issue: Action composition meta-modelled improperly: 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-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-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-989 UML RTF 1.4 Issue: Deferred event ambiguity 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-987 UML RTF 1.4 Issue: State constraint on host object UML 1.2 UML 1.3 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-978 OCL: Samples of invalid typing 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-975 OCL: String literals 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-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-970 OCL: Feature calls on default target UML 1.2 UML 1.3 Resolved closed
UML14-971 OCL: Enumeration types 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-967 OCL: Are keywords reserved or not 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-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-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-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-955 Error in the third postcondition for String::concat on page 6-31 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-949 The postcondition on set::collect seems to be incorrect UML 1.1 UML 1.3 Resolved closed
UML14-951 page 6-10 of OCL documentation for 1.3alphaR5 UML 1.1 UML 1.3 Resolved closed
UML14-950 The postcondition seems to be incorrect for sequence::subSequence UML 1.1 UML 1.3 Resolved closed
UML14-948 The second postcondition on Integer::div is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-947 (Minor) Activity diagram change recommendation UML 1.1 UML 1.3 Resolved closed
UML14-946 OCL Standard package UML 1.1 UML 1.3 Resolved closed
UML14-945 There is an association between between Constraint and ModelElement UML 1.1 UML 1.3 Resolved closed
UML14-944 OCL should allow one constraint to reference another UML 1.1 UML 1.3 Resolved closed
UML14-942 Dependencies (and other relationships) with role ends UML 1.1 UML 1.3 Resolved closed
UML14-943 UML has symbol for multiobject, not for multi-instances of other classifie UML 1.1 UML 1.3 Resolved closed
UML14-941 action state symbol/state symbol difficult to distinguish when drawn by ha 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-938 Interface issue UML 1.1 UML 1.3 Resolved closed
UML14-937 Only single stereotyping is supported UML 1.1 UML 1.3 Resolved closed
UML14-936 Use of black diamond in the metamodel UML 1.1 UML 1.3 Resolved closed
UML14-935 On aggregation. The white diamond name should be "shareable" UML 1.1 UML 1.3 Resolved closed
UML14-934 Metamodel and semantics for aggregations UML 1.1 UML 1.3 Resolved closed
UML14-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-924 Common operations should be added to collection types in OCL UML 1.1 UML 1.3 Resolved closed
UML14-917 Not instantiable 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-899 Associations as parts of a composite. UML 1.1 UML 1.3 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-888 Text on page 2-49 section 2.2 UML 1.1 UML 1.3 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-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-733 OCL specification 1.1, p. 32 UML 1.1 UML 1.3 Resolved closed
UML14-712 No mapping for swimlanes in Sequence Diagram UML 1.1 UML 1.3 Resolved closed
UML14-705 Well-formedness rules only expressed in English UML 1.1 UML 1.3 Resolved closed
UML14-681 UML 1.0: Template example cannot be representaed in model UML 1.1 UML 1.3 Resolved closed
UML14-675 UML 1.0: instances UML 1.1 UML 1.3 Resolved closed

Issues Descriptions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Key: UML14-1003
  • Legacy Issue Number: 3294
  • Status: closed  
  • Source: NIST ( 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: Messages do not have signatures

  • Key: UML14-1004
  • Legacy Issue Number: 3295
  • Status: closed  
  • Source: NIST ( 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: Multi-objects in collaborations

  • Key: UML14-1002
  • Legacy Issue Number: 3293
  • Status: closed  
  • Source: NIST ( 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

Incorrect example of constraining elements in collaborations.

  • Key: UML14-1001
  • Legacy Issue Number: 3292
  • Status: closed  
  • Source: NIST ( 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: Duplicate association end names from Constraint.

  • Key: UML14-1000
  • Legacy Issue Number: 3290
  • Status: closed  
  • Source: NIST ( 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 ( 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: Action composition meta-modelled improperly:

  • Key: UML14-997
  • Legacy Issue Number: 3287
  • Status: closed  
  • Source: NIST ( 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: What does it mean for ReturnAction to be synchronous?

  • Key: UML14-998
  • Legacy Issue Number: 3288
  • Status: closed  
  • Source: NIST ( 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: Flow relationship has the incorrect semantics

  • Key: UML14-996
  • Legacy Issue Number: 3284
  • Status: closed  
  • Source: NIST ( 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 ( 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: Confusing example of sequence diagram

  • Key: UML14-994
  • Legacy Issue Number: 3282
  • Status: closed  
  • Source: NIST ( 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 ( 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 ( 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: Deferred event ambiguity

  • Key: UML14-989
  • Legacy Issue Number: 3277
  • Status: closed  
  • Source: NIST ( 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: ownerScope and targetScope

  • Key: UML14-991
  • Legacy Issue Number: 3279
  • Status: closed  
  • Source: NIST ( 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: State constraint on host object

  • Key: UML14-987
  • Legacy Issue Number: 3274
  • Status: closed  
  • Source: NIST ( 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: Notation for call state

  • Key: UML14-986
  • Legacy Issue Number: 3273
  • Status: closed  
  • Source: NIST ( 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: 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: 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: Model Driven Solutions ( 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: 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: 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: 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: 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: 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

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

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

"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

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

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

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

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

page 6-10 of OCL documentation for 1.3alphaR5

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

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

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

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

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

    No Data Available

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

The postcondition seems to be incorrect for sequence::subSequence

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

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

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

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

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

    {lower..upper}

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

    The indexing is incorrect.

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

    No Data Available

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

The second postcondition on Integer::div is incorrect

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

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

    i.div( i2 : Integer) : Integer

    The number of times that i2 fits completely within i.

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

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

    No Data Available

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

(Minor) Activity diagram change recommendation

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

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

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

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

    No Data Available

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

OCL Standard package

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

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

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

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

    No Data Available

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

There is an association between between Constraint and ModelElement

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

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

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

    No Data Available

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

OCL should allow one constraint to reference another

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

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

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

    declined

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

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

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

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

Add Responsibilities as a new metatype

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

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

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

    No Data Available

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

Interface issue

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

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

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

    rejected

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

Only single stereotyping is supported

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

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

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

    No Data Available

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

Use of black diamond in the metamodel

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

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

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

    No Data Available

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

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

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

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

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

    No Data Available

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

Metamodel and semantics for aggregations

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

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

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

    No Data Available

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

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

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

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

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

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

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

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

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

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

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

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

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

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