Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UML14-1045 Compliance ambiguity UML 1.3 UML 1.4 Duplicate or Merged closed
UML14-1039 In 3.23.1 "Notation" (Internationalization issues) UML 1.3 UML 1.4 Resolved closed
UML14-1038 No servant with object . minorcode=0 completed=NO UML 1.3 UML 1.4 Closed; No Change closed
UML14-1037 The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4 UML 1.3 UML 1.4 Resolved closed
UML14-1036 Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics UML 1.3 UML 1.4 Resolved closed
UML14-1035 Who owns an Event? UML 1.3 UML 1.4 Resolved closed
UML14-1034 UML 1.4 RTF Issue: Namespace notation too specific UML 1.3 UML 1.4 Resolved closed
UML14-1033 UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1032 UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1031 UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1030 UML RTF 1.4 editorial comments (Part 2 Diagram Elements) UML 1.3 UML 1.4 Resolved closed
UML22-1075 Issue regarding "Action::effect : String" UML 1.3 UML 2.1 Resolved closed
UML22-473 Specify XMI parameters for the UML / XMI interchange format UML 1.3 UML 2.1 Resolved closed
UML22-1 Semantics of firing compound transitions still appears to be circular UML 1.3 UML 2.2 Resolved closed
UML14-443 UML 2.0 Superstructure reccomendation (derived unions) UML 1.3 UML 1.4.2 Resolved closed
UML14-15 well-formedness rule for Package is missing inUML 1.4 UML 1.3 UML 1.4 Resolved closed
UML14-14 Figure 2-15 of the uml 1.4 spec UML 1.3 UML 1.4 Resolved closed
UML14-16 isPolymorphic is never in a diagram UML 1.3 UML 1.4 Resolved closed
UML14-12 Notation example typo in Fig. 3-99 UML 1.3 UML 1.4 Resolved closed
UML14-13 page 2-163, the statemachine semantics escription UML 1.3 UML 1.4 Resolved closed
UML14-11 The glossary entry "call" should be "call state". UML 1.3 UML 1.4 Resolved closed
UML14-10 it's => its on page 3-150. UML 1.3 UML 1.4 Resolved closed
UML14-9 Wf 2 for AssociationEnd UML 1.3 UML 1.4 Resolved closed
UML14-8 2.9.2 Abstract Syntax UML 1.3 UML 1.4 Resolved closed
UML14-6 class TaggedValuewill two association-ends with the same name "stereotype" UML 1.3 UML 1.4 Resolved closed
UML14-7 issues and bugs on the UML 1.4 Draft UML 1.3 UML 1.4 Resolved closed
UML14-5 Remove uses of multiple inheritance from UML meta model UML 1.3 UML 1.4 Resolved closed
UML14-2 2) Page 2-49, additional operation #7 for Classifier UML 1.3 UML 1.4 Resolved closed
UML14-4 Who owns a Comment? UML 1.3 UML 1.4 Resolved closed
UML14-3 elimination of the Association Class TemplateParameter UML 1.3 UML 1.4 Resolved closed
UML14-1 Page 2-47, well-formedness rule #2 for Classifier UML 1.3 UML 1.4 Resolved closed
UML14-46 Why is a StateMachine's top a State instead of a CompositeState? UML 1.3 UML 1.4.2 Resolved closed
UML14-51 Attributes obsolete in UML 1.3 UML 1.3 UML 1.4.2 Resolved closed
UML14-52 Conflicting constraint between ActivityGraph and StateMachine. UML 1.3 UML 1.4.2 Resolved closed
UML14-48 Notation for inherited associations UML 1.3 UML 1.4.2 Resolved closed
UML14-50 Interface of an object UML 1.3 UML 1.4.2 Resolved closed
UML14-54 Appendix A, UML Standard Elements UML 1.3 UML 1.4.2 Resolved closed
UML14-49 MOF rules should disallow certain composition relationships UML 1.3 UML 1.4.2 Resolved closed
UML14-47 Document 99-06-08 - UML Spec UML 1.3 UML 1.4.2 Resolved closed
UML14-55 Profile Notation UML 1.3 UML 1.4.2 Resolved closed
UML14-58 Issue: Conflicting WFRs on Transition UML 1.3 UML 1.4.2 Resolved closed
UML14-57 Add Multiplicity to Parameter. UML 1.3 UML 1.4.2 Resolved closed
UML14-56 Events, signals, stimuli, etc. UML 1.3 UML 1.4.2 Resolved closed
UML14-53 Clarify the origin of an Action in a Collaboration. UML 1.3 UML 1.4.2 Resolved closed

Issues Descriptions

Compliance ambiguity

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

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

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

    duplicate

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

In 3.23.1 "Notation" (Internationalization issues)

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

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

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

    No Data Available

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

No servant with object . minorcode=0 completed=NO

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

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

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

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

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

    No Data Available

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

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4

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

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

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

    It would appear that the fourth level carries on from 2.9.3.24

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

    No Data Available

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

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

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

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

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

    No Data Available

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

Who owns an Event?

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

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

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

    No Data Available

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

UML 1.4 RTF Issue: Namespace notation too specific

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

    Namespace notation too specific

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

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

    declined

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

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

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

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

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

    No Data Available

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

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

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

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

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

    declined

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

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

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

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

    {ordered}

    . Should this be consistent with AssociationEnd to Association?

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

    No Data Available

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

UML RTF 1.4 editorial comments (Part 2 Diagram Elements)

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

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

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

    No Data Available

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

Issue regarding "Action::effect : String"

  • Key: UML22-1075
  • Legacy Issue Number: 9197
  • Status: closed  
  • Source: Eclipse Foundation ( Kenneth Hussey)
  • Summary:

    What has become of the dropped property : "Action::effect : String" ? ( referenced in Ballot 7319 )

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the UML / XMI interchange format

  • Key: UML22-473
  • Legacy Issue Number: 3898
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When the UML spec standardises an XMI-generated interchange format for
    UML
    models, it should include:

    • the "input" MOF meta-model for UML that was used to generate the
      interchange format, and
    • a formal statement of the other XMI "parameters" used to generate
      the interchange format.

    If possible, the UML spec should include a definitive meta-model for
    UML
    expressed as a MOF / XMI document. This is a MOF alignment issue.

  • Reported: UML 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of firing compound transitions still appears to be circular

  • Key: UML22-1
  • Legacy Issue Number: 4110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

    As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

    On page 2-173 of 2.12:

        • The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

    If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

    [...]

    Once a transition is enabled and is selected to fire, the following steps are carried out in order:

    • The main source state is properly exited.

    • Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

    • If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

    • The main target state is properly entered. ***

    This is certainly much better than 1.3. But I still find it difficult to follow:

    Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

    The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

    If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

    With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

  • Reported: UML 1.3 — Thu, 7 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Remove the paragraph explaining the LCA from the “Transition execution sequence” section and add an
    explanation of LCA to the “Transition ownership” section

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure reccomendation (derived unions)

  • Key: UML14-443
  • Legacy Issue Number: 6644
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

  • Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rule for Package is missing inUML 1.4

  • Key: UML14-15
  • Legacy Issue Number: 4534
  • Status: closed  
  • Source: Enea Business Software ( Karin Palmkvist)
  • Summary:

    A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

  • Reported: UML 1.3 — Fri, 24 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    The rule seems to have unintentionally disappeared from 1.3 to 1.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2-15 of the uml 1.4 spec

  • Key: UML14-14
  • Legacy Issue Number: 4531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

  • Reported: UML 1.3 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix in diagram: metaclass name is truncated (ModelElement => Model…). Duplicate of 4349

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isPolymorphic is never in a diagram

  • Key: UML14-16
  • Legacy Issue Number: 5923
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic);

    2.5.4.3 Class has methods which can be polymorphic (isPolymorphic)

    2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic)

    But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

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

    This is a duplicate of issue 4617,

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation example typo in Fig. 3-99

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

    In the example the dependencies between the focus class and the two
    auxiliary classes should connect to the target interfaces of the auxiliary
    classes, rather than their class rectangles. (Note: this typo may be
    corrected in the formal version of the UML 1.4 specification, which is not
    yet available.)

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

    Diagram to be fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 2-163, the statemachine semantics escription

  • Key: UML14-13
  • Legacy Issue Number: 4508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty

    I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state.

    On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add?

    On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

  • Reported: UML 1.3 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The glossary entry "call" should be "call state".

  • Key: UML14-11
  • Legacy Issue Number: 4454
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The glossary entry "call" should be "call state".

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

    Change the name of the glossary entry

  • Updated: Fri, 6 Mar 2015 20:58 GMT

it's => its on page 3-150.

  • Key: UML14-10
  • Legacy Issue Number: 4453
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    it's => its on page 3-150.

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

    editorial fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wf 2 for AssociationEnd

  • Key: UML14-9
  • Legacy Issue Number: 4450
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The second wf rule for AssociationEnd uses the OCL operation
    applied to the wrong type (max applied to multiplicities).

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

    obvious error, OCL only fix.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.9.2 Abstract Syntax

  • Key: UML14-8
  • Legacy Issue Number: 4349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'.

    This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

  • Reported: UML 1.3 — Mon, 18 Jun 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix : Rose truncating the diagram, Previously fixed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class TaggedValuewill two association-ends with the same name "stereotype"

  • Key: UML14-6
  • Legacy Issue Number: 4187
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    In the physical metamodel for extensions (Figure 6-8) the class
    TaggedValuewill have two association-ends with the same name "stereotype".
    One
    from the association with the superclass ModelElement
    (extendedElement-stereotype) and one on its own (requiredTag-stereotype).

  • Reported: UML 1.3 — Wed, 31 Jan 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    in Uml 1.4 final, there is only one association end with this name

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issues and bugs on the UML 1.4 Draft

  • Key: UML14-7
  • Legacy Issue Number: 4300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

    Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

    ---Begin of issues---------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

    (p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

    (p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

    (p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

    (p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

    ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

    Please clarify or correct the statement.

    (p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

    (p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

    (p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

    (p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

    (p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

    (p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

    (p. 3-3) Typographical/Editorial: There is no Part 8.

    (p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

    (p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

    (p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

    (p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

    (p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

    (p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

    (p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

    (p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

    (p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

    Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

    Please clarify

  • Reported: UML 1.3 — Sun, 13 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove uses of multiple inheritance from UML meta model

  • Key: UML14-5
  • Legacy Issue Number: 3931
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model.

    Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It’s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

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

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2) Page 2-49, additional operation #7 for Classifier

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

    2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
    follows:

    1 oppositeAssociationEnds : Set (AssociationEnd);
    2 oppositeAssociationEnds =
    3 self.association->select ( a | a.associationEnd->select ( ae |
    4 ae.type = self ).size = 1 )->collect ( a |
    5 a.associationEnd->select ( ae | ae.type <self ) )->union
    6 (
    7 self.association->select ( a | a.associationEnd->select ( ae |
    8 ae.type = self ).size 1 )->collect ( a |
    9 a.associationEnd) )

    In line 5, the expression 'ae.type <self' is clearly wrong. I believe the
    intention may have been to test for inequality, i.e. 'ae.type <> self'.

    In line 8 'size 1' doesn't parse. I'm not sure what the intent was.

    A greater concern is that, even if corrected to address these flaws, this
    logic doesn't seem right in the case where we are dealing with an
    association where both ends are of the same type. It appears to be relying
    on detecting whether an end is opposite by testing the end's type. A fair
    number of other well-formedness rules leverage this operation in one way or
    another, so they are affected by this apparent flaw. Correcting this would
    require comparing the end instances, i.e. something like 'ae <> self' which
    does not have the same problem as 'ae.type <> self'.

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

    This issue has been fixed in UML 1.4. The correct operator is "<>"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Who owns a Comment?

  • Key: UML14-4
  • Legacy Issue Number: 3860
  • Status: closed  
  • Source: Model Driven Solutions ( Eugenio Alvarez)
  • Summary:

    Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
    Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2, p. 2-17, Figure
    2-9 Core Package - Auxiliary Elements
    Nature: Revision
    Severity: Minor
    Summary: A Comment is shown as having a relationship to ModelElement
    (annotatedElement). However, the ownership of a Comment is not specified
    anywhere. If it should reside in a Package the OCL-WellFormedness rule for
    Package should be updated. Also, shouldn't a Comment have a text field to
    hold the annotation?

  • Reported: UML 1.3 — Mon, 18 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Add Comment to wfr listing what may be owned by a Package

  • Updated: Fri, 6 Mar 2015 20:58 GMT

elimination of the Association Class TemplateParameter

  • Key: UML14-3
  • Legacy Issue Number: 3803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9.

    My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version:

    1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association

    B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1

    2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement

    B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of *

    3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances

    B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind

    Can you help me to solve this trouble?

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

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 2-47, well-formedness rule #2 for Classifier

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

    In the UML 1.3 specification (ad/99-06-08) there are the following problems:

    1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
    operation 'oppositeEnds' which is not defined. This probably should be
    'oppositeAssociationEnds'.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why is a StateMachine's top a State instead of a CompositeState?

  • Key: UML14-46
  • Legacy Issue Number: 3569
  • Status: closed  
  • Source: Model Driven Solutions ( Eugenio Alvarez)
  • Summary:

    Every StateMachine must have one top State. However, there is an
    OCL constraint that says that the top State must be a CompositeState
    (Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
    2-141). So, why not make the top relationship from StateMachine to
    CompositeState instead of from StateMachine to State. The constraint can
    then be eliminated.

  • Reported: UML 1.3 — Tue, 18 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes obsolete in UML 1.3

  • Key: UML14-51
  • Legacy Issue Number: 3999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    the association between StructuralFeature and Classifier should be
    removed. Attributes can not describe more information than
    Associations/AssociationEnds can. Therefore it is obsolete and confuses
    the user of UML, which to choose when modeling.

    On page 3-40 in the UML 1.3 specification it says: "Note that an
    attribute is semantically equivalent to a composition association;
    however, the intent and usage is normally different."

    If the semantics are equivalent, then it is impossible to distinguish
    between them. There is no extra layer of meaning above the semantics
    layer that can distinguish between two things with equal semantics.
    Semantics is meaning. I think this sentence is contradictory. I have not
    been able to find out what the difference in "intent and usage" is. If
    this is defined, it will obviously make the semantics of the two
    different.

    To improve the readability of class diagrams when everything is
    associations, I propose that associations should be possible to
    represent as text in the compartment where attributes are written today.

  • Reported: UML 1.3 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conflicting constraint between ActivityGraph and StateMachine.

  • Key: UML14-52
  • Legacy Issue Number: 4083
  • Status: closed  
  • Source: Model Driven Solutions ( Eugenio Alvarez)
  • Summary:

    Since an ActivityGraph is derived from a StateMachine its
    constraints must be consistent with that of a StateMachine. If an
    ActivityGraph has a Package as its context it violates the constraint
    inherited from StateMachine.

    ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
    (self.context.oclIsTypeOf(Package) xor
    self.context.oclIsKindOf(Classifier) xor
    self.context.oclIsKindOf(BehavioralFeature))

    StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
    self.context.oclIsKindOf(BehavioralFeature) or
    self.context.oclIsKindOf(Classifier)

    One way to avoid this problem is to change the StateMachine constraint to be
    applicable when self is oclIsTypeOf(StateMachine) so the constraint is not
    applied to it children.

    A general mechanism to disable inherited constraints could also solve the
    problem.

  • Reported: UML 1.3 — Wed, 29 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for inherited associations

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

    The CWM submitters needed to display inherited associations on some class
    diagrams to enhance understandability. These were not intended to be
    derived associations; that is, there was no intention to specify additional
    computational machinery when showing these inherited associations.
    Unfortunately, the MOF and UML have no succint way to display inherited
    associations. The CWM submitters placed the "/" derived prefix on the
    association end names in the class diagrams. At the same time, in order to
    prevent the generation of additional computational machinery, they omitted
    the inherited association from the normative XMI rendition of the metamodel.
    This was probably a reasonable choice under the circumstances. However, it
    means that the class diagrams and the XMI representation of the metamodel
    conflict with one another.

    It is very common to need to show inherited associations on a class diagram.
    We ran into this when we specified the CORBA metamodel for the CORBA
    Component Model submission. We used derived associations in the class
    diagrams as well. However, we retained the derived associations in the XMI
    rendition of the metamodel. In order to prevent additional computational
    machinery from being generated, we stereotyped the associations as
    <<implicit>>. This stereotype is defined in the UML specification but not
    in the MOF specification and says that an association is only conceptual and
    not manifest. We then made sure that the generator producing the IDL and
    XML DTDs was sensitive to the <<implicit>> stereotype. This had the
    advantage of maintaining consistency between the class diagrams and the XMI
    rendition of the metamodel. Of course this is also a non-standard
    approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
    generators to understand it.

    The lack of a standard means for representing inherited associations in
    class diagrams is thus resulting in a proliferation of non-standard
    approaches in adopted OMG metamodels. This could become unmanageable as the
    number of metamodels grows. A standard means should be specified.

  • Reported: UML 1.3 — Mon, 3 Jul 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface of an object

  • Key: UML14-50
  • Legacy Issue Number: 3783
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    This is a request for an interpretation of UML 1.3.

    The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

    -------- Background -------

    Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

    The UML submission said:

    "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."

    UML 1.3 says:

    "2.5.4 Semantics

    "Interface

    "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

    [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

    --------

    I am hoping this is easy to interpret and can be resolved quickly.

  • Reported: UML 1.3 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A, UML Standard Elements

  • Key: UML14-54
  • Legacy Issue Number: 4218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

  • Reported: UML 1.3 — Thu, 8 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF rules should disallow certain composition relationships

  • Key: UML14-49
  • Legacy Issue Number: 3735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF rules should disallow composition relationships in instance metamodels
    where the container is in one MOF Package and the contained item is in
    another MOF Package and a dependency of the first package on the second is
    not allowed by the physical version of the metamodel due to MOF-imposed IDL
    generation rules.

    Reason for the issue:

    In the process of implementing an XMI-based interchange for UML 1.3, I have
    encountered a serious problem.

    This problem has to do with a divergence between the "Logical" and
    "Physical" model for UML 1.3 caused by rules imposed by MOF.

    In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
    version), "Preconditions for IDL Generation", requires that there be no
    cyclical dependencies between ModelElements in a meta-model.

    However, the UML 1.3 specification (June 1999) has a cyclical dependency
    between the Core and the Extension Mechanisms packages in the metamodel (See
    Figure 2-4). This cyclical dependency is explicitly disallowed by the
    precondition cited above.

    This circular dependency was removed from the "Physical Model" for UML 1.3
    in order to allow CORBA IDL and XMI DTD declarations in conformance with the
    precondition. As a result of the removal of this dependency, there are
    tremendous difficulties expressing the composition relationship between the
    UML ModelElement and the UML Tagged Value (see figure 2-10). In fact, the
    TaggedValue XML elements cannot even be in the exported UML Package element
    – they must be placed outside of it. This greatly complicates the export
    and import of UML 1.3 model files.

  • Reported: UML 1.3 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document 99-06-08 - UML Spec

  • Key: UML14-47
  • Legacy Issue Number: 3632
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'd find the document easier to digest if Chap 2 had some pictures in it.
    >>
    >>I know that the semantics is supposed to be independent of the
    >>representation. However, Chap 3 does contain some semantics in it for
    >>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
    >>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
    >>picture of the diamond shaped association end for aggregations, it would be
    >>easier to follow what the document is talking about.
    >>
    >>At least sections 3.55.1 and 2.11.4 for instance might have links, even if
    >>only footnotes, to connect actor notation and semantics.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Notation

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

    I raised this issue at the AB level. I didn't recommend holding up approval
    of UML 1.4 over this but we agreed that the new RTF would take this matter
    up with dispatch.

    Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
    and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
    issue. I can speak to this as a practical matter based on the profiling
    work I've done. When I define a Stereotype on a UML metamodel element, as
    in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
    of the UML metamodel element. I don't want to have to define it again
    before defining the relationship between my new Stereotype and that UML
    metamodel element. Thus, requiring the <<metaclass>> Stereotype on the UML
    metamodel element means that, in the UML metamodel itself, I would have to
    Stereotype all the metaclasses this way so that, if I need to, I can reuse
    them in VMMs. True, I could opt not to display the <<metaclass>>
    Stereotype in a pure UML metamodel diagram and opt to display it a VMM
    diagram, but all the UML metamodel elements would be carrying the
    <<metaclass>> Stereotype.

    The best solution I can think of to this problem is to to drop the
    requirement to use the <<metaclass>> Stereotype in VMM diagrams. As long as
    the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
    is adhered to, it should be pretty clear in a VMM diagram what is a
    Stereotype and what is a UML metamodel element. Also, the the standard
    metamodel Stereotype of Package indicates that the elements in the
    Package are elements of a metamodel.

    I am open to other suggestions as to how to resolve this issue.

  • Reported: UML 1.3 — Fri, 9 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Conflicting WFRs on Transition

  • Key: UML14-58
  • Legacy Issue Number: 4298
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    UML 1.4 Specification, Section 2.12.3, p. 2-165

    Description:
    WFR 5 for the class Transition states that "Transitions outgoing
    pseudostates may not have a trigger" and the OCL supports this absolute
    statement. However, WFR 6 is intended to allow transitions out of initial
    states, which are a kind of pseudostate, to have "a trigger with the
    stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
    legal.

    Recommendation:
    Change WFR 5 as follows.

    [5] Transitions outgoing pseudostates other than initial states may not have
    a trigger.

    self.source.oclIsKindOf(Pseudostate) implies
    self.source.oclAsType(Pseudostate).kind<>#initial implies
    (self.trigger->isEmpty())

  • Reported: UML 1.3 — Thu, 10 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Multiplicity to Parameter.

  • Key: UML14-57
  • Legacy Issue Number: 4292
  • Status: closed  
  • Source: Model Driven Solutions ( Eugenio Alvarez)
  • Summary:

    Adding multiplicity to Parameter would enable modeling of arrays,
    collections, sequences etc. I would like to model BehavioralFeatures that
    can return an array and take an array as an argument.
    The notation would simply add the [multiplicity] after the Parameter type.
    The initial value syntax would be

    { initial-value, initial-value..}
  • Reported: UML 1.3 — Tue, 1 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Events, signals, stimuli, etc.

  • Key: UML14-56
  • Legacy Issue Number: 4263
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Shane Sendall)
  • Summary:

    Here is my understanding of communication between instances on an
    example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
    An instance i1 performs a SendAction, according to the spec: "A send
    action is an action that results in the (asynchronous) sending of a
    signal". Then, the signal is delivered to say instance i2, and as a
    consequence of the receipt, a SignalEvent is generated (according to the
    spec, "A signal event represents the RECEPTION of a particular
    (asynchronous) signal")
    Now the problems:
    1) the spec goes on further to say about the signal event that "A signal
    event
    instance should not be confused with the action (e.g., send action) that
    generated it". The problem I have with my above understanding is that
    the send action should not be the one generating the send event but
    rather the reception of the signal should be the one generating it.
    2)According to the spec: "A signal is a specification of an asynchronous
    stimulus communicated between instances" where a stimulus is more
    general "In the metamodel Stimulus is a communication, i.e. a Signal
    sent to an Instance, or an invocation of an Operation". Thus, I conclude
    that the things sent between instances are stimuli.
    However, I'm a little confused of the relationship between events and
    stimuli with the following sentence taken from the spec "Event instances
    are generated as a result of some action either within the system or in
    the environment surrounding the system. An event is then conveyed to one
    or more targets. The means by which event instances are transported to
    their destination depend on the type of action, the target,..."
    Furthermore, how are stimuli and signals related in the metamodel?

  • Reported: UML 1.3 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the origin of an Action in a Collaboration.

  • Key: UML14-53
  • Legacy Issue Number: 4123
  • Status: closed  
  • Source: Model Driven Solutions ( Eugenio Alvarez)
  • Summary:

    Actions seem to be owned by the Message in the following paragraph.

    Section 2.10 page 2-130. "In the metamodel a Message defines one specific
    kind of communication in an Interaction. A
    communication can be e.g. raising a Signal, invoking an Operation, creating
    or destroying an
    Instance. The Message specifies not only the kind of communication, but also
    the roles of the
    sender and the receiver, the dispatching Action, and the role played by the
    communication
    Link. Furthermore, the Message defines the relative sequencing of Messages
    within the
    Interaction."

    Is the Action a reference to a Action in the Sender, as the meta-model
    suggests, or is it owned by the Message as the above suggests?

    Please clarify.

  • Reported: UML 1.3 — Mon, 18 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT