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

UML 2.4 BRM RTF — All Issues

  • Key: UML241
  • Issues Count: 47
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML241-45 Loop notation UML 1.4.2 open
UML241-47 No unambiguous way in UML 2.4 to serialize StructuredActivityNode UML 2.4 UML 2.4.1 Resolved closed
UML241-46 actions UML 2.0 open
UML241-37 Section: 11.3.39 UML 2.0 open
UML241-39 Messages to ports with only one connector UML 1.4.2 open
UML241-38 UML2 Superstructure - profiles UML 1.4.2 open
UML241-41 Section: 9.3.12 UML 2.0 open
UML241-40 UML 2 Super/Interactions/ LOOP construct specifications UML 1.4.2 open
UML241-42 Profiles UML 1.4.2 open
UML241-43 Wrong metamodel for internal transitions UML 1.4.2 open
UML241-44 All single query operations in the spec defined in OCL invalid ? RAS 2.0b1 open
UML241-36 inadequate definition of 'constructor' UML 1.4.2 open
UML241-31 Issue in UML 2 Lifeline class RAS 2.0b1 open
UML241-29 Issue in UML 2 Interaction class : Local attributes RAS 2.0b1 open
UML241-30 Issue in UML 2 Interaction package RAS 2.0b1 open
UML241-34 Composite structures/Unspecified connector features RAS 2.0b1 open
UML241-32 Components UML 2.0 open
UML241-33 What is a mapping that is not computable? UML 2.0 open
UML241-35 DeploymentSpecification - notation for DeploymentSpecification on the insta UML 2.0 open
UML241-26 Issue in UML 2 Continuation RAS 2.0b1 open
UML241-28 Issue in UML 2 Interaction class: Lifeline ordering RAS 2.0b1 open
UML241-27 Issue on UML 2 Interaction class RAS 2.0b1 open
UML241-22 Irritating occurrence of subsystem stereotype in use case example diagrams UML 2.4 UML 2.4.1 Resolved closed
UML241-23 Implicit parameter assignment may cause name clashes UML 2.4 UML 2.4.1 Resolved closed
UML241-25 ChangeEvent::changeExpression should be of type ValueSpecification UML 2.4 UML 2.4.1 Resolved closed
UML241-24 Validity duration of implicitly assigned parameters in SignalEvent/CallEvent UML 2.4 UML 2.4.1 Resolved closed
UML241-21 UML 2.4: NamedElement.ownedRule could be ordered UML 2.4 UML 2.4.1 Resolved closed
UML241-17 XMI in small caps UML 2.4 UML 2.4.1 Resolved closed
UML241-20 UML Appendix A : Figure A.3 Two Diagrams of Packages” UML 2.4 UML 2.4.1 Resolved closed
UML241-18 ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile" UML 2.4 UML 2.4.1 Resolved closed
UML241-19 property.opposite UML 2.4 UML 2.4.1 Resolved closed
UML241-13 Number of Compliance Levels UML 2.4 UML 2.4.1 Resolved closed
UML241-16 Core Package versus Construct Package UML 2.4 UML 2.4.1 Resolved closed
UML241-15 XML Metadata Interchange (XMI) - p9 UML 2.4 UML 2.4.1 Resolved closed
UML241-14 XML Metadata Interchange (XMI) UML 2.4 UML 2.4.1 Resolved closed
UML241-12 UML type Real specification UML 2.4 UML 2.4.1 Resolved closed
UML241-11 Interface element - associations multiplicity not defined UML 2.4 UML 2.4.1 Resolved closed
UML241-10 Missing Namespace in Dependencies package definition? UML 2.4 UML 2.4.1 Resolved closed
UML241-9 Property::isID UML 2.4 UML 2.4.1 Resolved closed
UML241-7 Typo: "joint" should say "join" UML 2.4 UML 2.4.1 Resolved closed
UML241-8 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-3 typo on page 46 UML 2.4 UML 2.4.1 Resolved closed
UML241-4 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-5 No Rules for Element Names UML 2.4 UML 2.4.1 Resolved closed
UML241-6 Wrong package name on several Figures UML 2.4 UML 2.4.1 Resolved closed
UML241-2 Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong UML 2.4 UML 2.4.1 Resolved closed
UML241-1 Can a Generalization really be in multiple GeneralizationSets? UML 2.4 UML 2.4.1 Resolved closed

Issues Descriptions

Loop notation

  • Key: UML241-45
  • Legacy Issue Number: 7590
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    I am putting together an example of a sequence diagram using the loop
    combinedFragment. The spec seems confusing. Just where does a guard
    condition that is not the minint or maxint get placed?

    According the CombinedFragemt definition, I can describe a minimum and
    maximum number of times to perform the loop. "The Guard may include a lower
    and an upper number of iterations of the loop as well as a Boolean
    expression." I can also describe a guard condition. However, the notation
    describes a syntax like LOOP (minint, maxint) with no extra guard.

    Do I place the extra guard as an interaction constraint in a region as shown
    in figure 333. Is this allowed? Do I only get one interaction constraint
    (either the min,maxint or the separate interaction constraint in the body of
    the loop combined fragment?

    I would like to say something like LOOP 1, * [status = notFound] or LOOP
    (1,*,status = notFound). I suppose I could say LOOP (1,[status = notFound]).
    All of these should say that the loop interaction is performed at least
    once. After that if the status is "notFound" then the loop continues
    otherwise the loop terminates.

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Updated: Fri, 19 Aug 2016 09:33 GMT

No unambiguous way in UML 2.4 to serialize StructuredActivityNode

  • Key: UML241-47
  • Legacy Issue Number: 16232
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
    MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
    Does XMI support that?

    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

    fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

    Any suggestions? Don't you think we should fix that somehow?

  • Reported: UML 2.4 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:04 GMT

actions

  • Key: UML241-46
  • Legacy Issue Number: 7549
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the opinion of some, "at present, the spec bases actions on foundations described in the activities section." However the text says: "An action is the fundamental unit of behavior specification." Thus the text contradicts the opinion. If the opinion is correct, the text should be corrected to agree

  • Reported: UML 2.0 — Wed, 16 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 11.3.39

  • Key: UML241-37
  • Legacy Issue Number: 8184
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Messages to ports with only one connector

  • Key: UML241-39
  • Legacy Issue Number: 7654
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The semantics of Port says:

    > If there is a connector attached to only one side of a port, any
    > requests arriving at this port will terminate at this port.

    but it also says:

    > For a behavior port, the instance of the owning classifier will
    > handle requests arriving at this port (as specified in the behavior
    > of the classifier, see Chapter 13, Common Behaviors), if this
    > classifier has any behavior.

    And presumably for non-behavior ports, the message could be forwarded to
    the intefaces of the owning classifier. So the first statement above is
    incorrect, isn't it?

  • Reported: UML 1.4.2 — Tue, 31 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML2 Superstructure - profiles

  • Key: UML241-38
  • Legacy Issue Number: 7780
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    From the current spec I really can't work out what to implement. For what
    it's worth, this is what I think should be there:
    Properties can be typed either by MOF primitive types (the ones used in the
    UML metamodel, such as string, boolean and enumeration and subtypes), or by
    UML metaclasses. This is not only consistent wth UML 1.x, it also is likely
    to be the most easily implemented - vendors already need to provide a UI for
    editing boolean properties etc. and editing properties typed by metaclasses
    is easy - just use a list control to reference existing model elements.
    The spec seems to state that properties can typed by arbitrary model
    elements.("However, it is possible to have
    associations between ordinary classes, and from stereotypes to ordinary
    classes")
    How is a tool supposed to know what to do with it - it looks like the
    current spec allows a stereotype property to be typed by something like an
    Actor, not the actor metaclass, but some specific actor - what use is that?
    The more I read about this the more I'm convinced that we will never get
    interoperability, unless we tighten the rules as I suggested above.

  • Reported: UML 1.4.2 — Thu, 23 Sep 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 9.3.12

  • Key: UML241-41
  • Legacy Issue Number: 7614
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Instance values are depicted using the same icon as for the defining classifier. However, for parts this convenient notational convention is not defined. Allow to use the same icon as for the classifier that is the type of the part, when representing the part (modulo the namestring, which is necessarily different, as is the case with instance value also). As an example, a part that derives from an active class could then optionally be shown with the vertical side bars highlighting its active nature.

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML 2 Super/Interactions/ LOOP construct specifications

  • Key: UML241-40
  • Legacy Issue Number: 7617
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    This issue is submitted on behalf of Craig Larman (see signature at the end fo this e-mail):

    Current: The LOOP keyword, used in sequence diagrams in a frame, has the syntax LOOP, LOOP( repeat ), or LOOP( min, max)

    Problem: Iteration over a collection of objects, sending the same “doX” message to each member is a very very common idiom, so it would be nice if the UML had an easy notation to support this (and otherwise, how will you reverse engineer to code to the right diagram case, or vice versa? It is currently not clear…). AAt present, it is not clear how to say “for i = 1 to collection.size”, nor is there support to allow this ‘i’ loop variable to be reference in a lifeline *selector*

    Solution:
    1. change the LOOP syntax to (in its fullest form), LOOP( <varName>, <start>, <end>, <increment>) e.g., LOOP( i, 1, 10, 1), or LOOP( i, 10, 1, -1). Increment should default to +1.
    a. Also <start> and <end> may be expressions referring to participants in the interaction, such as end = lineItems.size where lineItems is a collection of SalesLineItem objects. Note that there is already syntax for a “max” (similar to <end>), and one aspect of this change is making (or ensuring) it can be an expression involving lifeline participants, not just a constant.

    2. allow a lifeline contained within the frame to have its selector refer to the LOOP var. e.g., “ lineItems[ i ] : SalesLineItem” to indicate selecting one SalesLineItem from the lineItems collection, given the current value of ‘i’. Note that a selector such as “lineItem[ i ]” is already allowed in the spec (and there are examples in the spec). this request is for tying the ‘i’ variable to the LOOP construct.

    Variant Solutions:
    Perhaps the upper-bound can be handled in the LOOP guard instead. E.g., [ i < lineItems.size ]. However, in this case, i still need a way to indicate the incrementing of ‘i’, and the ability to legally refer to “i” in the selector “lineItems[ i ].

    i attach a picture to illustrate.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Profiles

  • Key: UML241-42
  • Legacy Issue Number: 7608
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Issue with tags (i.e. properties of stereotypes); I can't see an example of
    display of multi-valued tags or tags whose types are UML metaclasses. There
    should be a normative mechanism for displaying these.

  • Reported: UML 1.4.2 — Wed, 28 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Wrong metamodel for internal transitions

  • Key: UML241-43
  • Legacy Issue Number: 7593
  • Status: open  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Description: In the UML 2.0 statemachines an internal transition is modeled as a transition owned by a region.

    It is wrong that in order to specify an internal or local transition one needs

    to instantiate a region. This makes any state with local transitions a composite state which is wrong.

    Local/Internal transitions shall be owned directly by states and not via regions.

  • Reported: UML 1.4.2 — Fri, 16 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

All single query operations in the spec defined in OCL invalid ?

  • Key: UML241-44
  • Legacy Issue Number: 7550
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    This seems rather serious, but perhaps some OCL FTF person will reassure me that it's not:

    The UML 2 Superstructure spec defines additional query operations for a number of metaclasses. For example, the following query is defined for the metaclass Element:

    Element::allOwnedElements(): Set(Element);
    allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    Another example is the query defined for ProtocolTransition:

    context Region::belongsToPSM () : Boolean
    result = if not stateMachine->isEmpty() then
    oclIsTypeOf(ProtocolStateMachine)
    else if not state->isEmpty() then
    state.container.belongsToPSM ()
    else false

    Notice the different forms used to define these two queries. The first one uses the name of the operation to store the result while the second uses the OCL reserved word "result". In the spec, there many queries that use the first form and only three cases of the latter form.

    A review of the OCL spec with respect to this issue – as far as I can tell – indicates that there are three valid ways of specifying a query as shown by the following two examples:

    (1) using body expressions (note the 'body:' prefix in the second line):

    context Element::allOwnedElements(): Set(Element);
    body: ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    (2) using postconditions (note the use of the reserved word 'result' following the 'post:' prefix):

    context Element::allOwnedElements(): Set(Element);
    post: result = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    (3) using auxilliary definitions (note the 'def:' prefix in the second line):

    context Element
    def: allOwnedElements(): Set(Element) = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    Unfortunately, neither of the two forms used in the spec conform to any of these formats, which seems to imply that every single query operation in the spec that is defined in OCL is invalid! There are 73 such queries at the moment.

    Can someone from the OCL team shed light on this?

  • Reported: RAS 2.0b1 — Thu, 17 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

inadequate definition of 'constructor'

  • Key: UML241-36
  • Legacy Issue Number: 7866
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The current "definition" of constructor, section 9.3.1 "Notation"
    subsection (page 75) leaves some issues.

    The description proposes a notation for associating an instance
    representation with a "constructor", noting only that a constructor is
    an operation that "must have the class as its classifier."

    Given a list of operations (_ _ is static):

    + newInstance(name:String):Foo
    + getFooForName(name:String):Foo
    + identity():Foo
    + clone():Foo
    + Foo(name:String):Foo
    + Foo(name:String):Foo
    + make(name:String):Foo

    Any of the above operations could be viewed as a constructor under the
    definition provided. The only marker suggested in the superstructure
    specification to clearly specify a constructor is a "<<create>>"
    assocation from the default instance created by the constructor.

    Assuming foo:Foo:
    Foo::newInstance("bar")
    foo.clone()
    Foo::make("bar")
    Foo::Foo("bar")
    In the predominant commercial OO languages, newInstance(...) and clone()
    are delegating the actual creation to Foo::Foo(...), but clone or copy
    may be the vehicles of instantiation in languages like io or self.

    If UML had a specific marker for constructors, like the stereotype
    "<<constructor>>" then OCL and other notations and tools could treat
    constructors specially where useful.

    The OCL specificaion already includes notation for Tuple and Collection
    "constructors" to specify what are essentially Tuple and Collection
    constants. Providing a standard marker for constructors might reliably
    allow similar clear constructs for all other types (ex. if baz >
    Foo(1.30, Currency::USDollars) then ...).

  • Reported: UML 1.4.2 — Sun, 17 Oct 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Lifeline class

  • Key: UML241-31
  • Legacy Issue Number: 7447
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    p. 386, it is written: "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line". Figure 8-144 p. 372 presents several sizes of grey rectangles. Particularly, does it mean that method activation is performed all along the Lifeline ob1:C1? A temporal vertical axis will be added to allow several sizes of rectangles and duration of method activation.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction class : Local attributes

  • Key: UML241-29
  • Legacy Issue Number: 7445
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is possible to represent local attributes to an Interaction (see Figure 8-148 p. 380) but it is not written how these attributes are treated: are they public to all the lifelines? Is it possible to have private attributes and in this case to which lifelines? Are they local to the Interaction? What happens if one of the lifeline is self? Does it mean that these parameters are owned by the self lifeline?

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction package

  • Key: UML241-30
  • Legacy Issue Number: 7443
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    In the UML 2 Interaction package specification (UML
    2 spec, dated 2003/04/10): p. 381, it is written that
    "InteractionFragment is an abstract notion of the most general
    interaction unit. An interaction fragment is a piece of an interaction.
    Each interaction fragment is conceptually like an interaction by itself".

    InteractionFragment is described as an abstract notion and Interaction
    is defined as a specialization of InteractionFragment. Don't we define
    normally in the other way around: the InteractionFragment is the
    abstract notion and is called Interaction and the interaction is called
    InteractionFragment? We can have the definition for Interaction
    (previously called InteractionFragment): "Interaction is an abstract
    notion of the most general interaction unit. An Interaction is composed
    of at least an InteractionFragment".

    Usual semantics for fragments refers to something within something else
    but here, the something else is undefined.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Composite structures/Unspecified connector features

  • Key: UML241-34
  • Legacy Issue Number: 7430
  • Status: open  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    Composite structures/Unspecified connector features between ports having multiple interfaces. What happens when ports have multiple interfaces, that in addition can mix
    required and provided interfaces? This is not specified. In particular, a
    connector could connect two ports using only a specified subset of the
    interfaces from both ports.

    Recommendation:
    Extend the metamodel to allow the specification of the interfaces used for a
    connector between ports having several interfaces.

    or

    Provide a default rule for that situation, such as the connector uses the
    compatible interfaces between the interfaces of both ports.

  • Reported: RAS 2.0b1 — Wed, 2 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Components

  • Key: UML241-32
  • Legacy Issue Number: 7442
  • Status: open  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested.

  • Reported: UML 2.0 — Thu, 3 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

What is a mapping that is not computable?

  • Key: UML241-33
  • Legacy Issue Number: 7412
  • Status: open  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." What is a mapping that is not computable?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

DeploymentSpecification - notation for DeploymentSpecification on the insta

  • Key: UML241-35
  • Legacy Issue Number: 7154
  • Status: open  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    DeploymentSpecification - notation for DeploymentSpecification on the instance level

    There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread)

    See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Continuation

  • Key: UML241-26
  • Legacy Issue Number: 7451
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    Is it not possible to have a symbol for the setting? That could help reading the diagram.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction class: Lifeline ordering

  • Key: UML241-28
  • Legacy Issue Number: 7446
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    Lifelines are associated to Interaction but it is not possible to save the ordering contrary to the fragments.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue on UML 2 Interaction class

  • Key: UML241-27
  • Legacy Issue Number: 7444
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to represent that an Interaction frame represents a design pattern with unbound parameters

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Irritating occurrence of subsystem stereotype in use case example diagrams

  • Key: UML241-22
  • Legacy Issue Number: 16494
  • Status: closed  
  • Source: in.tum.de ( Florian Schneider)
  • Summary:

    Referenced UML Superstructure Version: 2.4 beta2

    Issue:

    In chapter 16 on use cases, a <<subsystem>> stereotype is applied to the subject (or system boundary) in three figures:

    • Figure 16.5 - Example of the use cases and actors for an ATM system (p. 614)
    • Figure 16.8 - Example of a use case for withdrawal and transfer of funds (p. 616)
    • Figure 16.11 - Use cases owned by a package (p. 621)

    According to Table B.1 - UML Keywords (p. 712), that specific stereotype is only applicable to Component. The subject of a use case is of type Classifier.

    So the named diagrams are not syntactically wrong but slightly irritating to the reader because there is no indication that in these examples, the use case subject is actually a more specific type of a classifier, namely a component. The diagrams could lead to misinterpretations like "it is allowed to use the subsystem stereotype for any use case subject".

    The textual description for Figure 16.5 does not clarify but only states "For example, the use cases shown in Figure 16.5 on page 614 apply to the “ATMsystem” classifier"
    Regarding Figure 16.8 the accompanying text makes no clarification.
    Figure 16.11 is even more confusing as it seems to be the case that the component being subject to the use cases is part of a package. Also the package name "ATMtopPkg" does not seem to be a good name for a package.

    Recommendation:

    1) Add textual description to explain the origin of the <<subsystem>> stereotype on the three diagrams
    or
    remove subsystem stereotype as UML examples should not include constructs of any profile (even if it is one of the standard profiles)

    2) Rename "ATMtopPkg" in Figure 16.11 (e.g. to ATMNetwork)

  • Reported: UML 2.4 — Wed, 17 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 18071

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

Implicit parameter assignment may cause name clashes

  • Key: UML241-23
  • Legacy Issue Number: 16648
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <attr-name> is an implicit assignment of the corresponding parameter of the operation to an attribute (with this name)
    UML Superstructure Specification, of the context object owning the triggered behavior"

    This may lead to a situation where name clashes can occurr, if the context object already contains an identically named attibute.
    How should situations like a name clashes be resolved?

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The corresponding wording in the UML 2.5 specification is (from Subclause 13.3.4):
    “<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation
    to a Property or Variable of the context object for the triggered Behavior.”
    The “assigned-name” is the name of a Property or Variable that the context object already contains, not a definition of
    a new attribute. There is therefore no possibility of “name clash”.
    Disposition: Closed - No Change

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

ChangeEvent::changeExpression should be of type ValueSpecification

  • Key: UML241-25
  • Legacy Issue Number: 16896
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    Subsection Associations is not in synch with the abstract syntax depicted in Figure 13.12.

    In the abstract syntax, change expression is typed by ValueSpecification, whereas in Association section it is described as Expression.

    Possible resolution:

    Change changeExpression : Expression

    to

    changeExpression : ValueSpecification.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Validity duration of implicitly assigned parameters in SignalEvent/CallEvent

  • Key: UML241-24
  • Legacy Issue Number: 16649
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <assignment-specification> is optional and may be omitted even if the operation has parameters."

    Does this mean that the parameters of the event are still assigned to attributes of the context object? If so, how long are those implicitly assigned
    attribute values stored in the context object? Since this is just a workaround to be able to express guard conditions that evaluate whether a transition can fire based
    on the recieved trigger, I would assume, the implicitly assigned attribute values are kind of transient or temporarly and will become invalid (or deleted) after all guards of the outgoing state are evaluated. Otherwise, I would like have this paragraph stated
    clearer. It is a vital and crucial part how to deal with triggering events and with guard that refer to those trigger events.

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There is no implication in this notation of “transient” or “temporary” assignment. The values are assigned to the given
    attributes, which retain those values until reassigned. However, the exact mechanism for accomplishing the intent
    behind this notation is not formalized in the specification. The UML 2.5 specification now includes the following
    clarification (from Subclause 13.3.4):
    “<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping
    is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to
    support this notation. If it does, it may provide a mapping to standard UML abstract syntax, e.g., by implicitly inserting
    Actions to carry out the behavior implied by the notation.”
    Disposition: Closed - No Change
    Report

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

UML 2.4: NamedElement.ownedRule could be ordered

  • Key: UML241-21
  • Legacy Issue Number: 16493
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Graphically, Constraints appear independently so the unordered
    characteristric of NamedElement.ownRule seems sensible. However in a textual
    rendering ordering is appropriate.

    For instance, Constraints may sensibly be layered so that simple Constraints
    come first and act as guards against redundant evaluation of later
    Constraints.

    For instance, when auto-generating a specification such as the OCL
    specification, a specific ordering is required in the generated output.

    Please change to

    {ordered}

    .

  • Reported: UML 2.4 — Mon, 15 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The ownedRule property is actually on Namespace, not NamedElement.
    In general, it is not appropriate to add constraints to the abstract syntax in order to capture presentation issues, like the
    textual rendering of an order. Further, the UML semantics provide no requirement that ownedRules be evaluated in
    any particular order, so, as far as UML is concerned, there is no underlying meaning to such ordering.
    Disposition: Closed - No Change

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

XMI in small caps

  • Key: UML241-17
  • Legacy Issue Number: 16363
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 177, Clause 12, second paragraph, in the middle, XMI is written
    in small case, as "...whose xmi serialization...", maybe it's recomended
    to write in upper case as in the rest of the document.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML Appendix A : Figure A.3 Two Diagrams of Packages”

  • Key: UML241-20
  • Legacy Issue Number: 16483
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In “Figure A.3 Two Diagrams of Packages” the left most diagram has a header that says:

    “i) Package symbol (as part of a larger diagram diagram)”

    This text should be (as far as I can figure out)

    “i) Package symbol (as part of a larger package diagram)”

    Similarly, the paragraph before the diagram has the following text

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

    To clarify this, make the following one word change

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a package diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

  • Reported: UML 2.4 — Tue, 2 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Accept the proposals

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

ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile"

  • Key: UML241-18
  • Legacy Issue Number: 16400
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    I noticed that all normative UML2.x infrastructure and superstructure documents have the same bug:

    In ProfileApplications, under Associations, the following property is incorrect:

    • importedProfile: Profile [1]
    References the Profiles that are applied to a Package through this ProfileApplication.
    Subsets PackageImport::importedPackage

    It should describe the following property ProfileApplication::appliedProfile : Profile[1] as follows:

    appliedProfile : Profile[1]
    References the Profile that is applied to a Package through this ProfileApplication.
    Subsets DirectedRelationship::target

    In the UML2.xInfrastructure metamodel and the 2.4 beta2 merged metamodel
    the documentation for ProfileApplication::appliedProfile should be changed from:

    References the Profiles that are applied to a Package through this ProfileApplication.

    to:

    References the Profile that is applied to a Package through this ProfileApplication.

    This affects the following documents:

    UML2.4 Infrastructure & Superstructure beta2 (ptc/2010-11-16 and ptc/2010-11-14)
    UML2.3 Infrastructure & Superstructure (formal/2010-05-03 and formal/2010-05-05)
    UML2.2 Infrastructure & Superstructure (formal/2009-02-04 and formal/2009-02-02)
    UML2.1.2 Infrastructure & Superstructure (formal/2007-11-04 and formal/2011-11-02)
    UML2.1.1 Infrastructure & Superstructure (formal/2007-02-06 and formal/2007-02-05)
    UML2.0 Infrastructure & Superstructure (formal/2005-07-04 and formal/2005-07-05)

    This affects the following normative files:

    http://www.omg.org/spec/UML/20101101/UML.xmi
    http://www.omg.org/spec/UML/20101101/Infrastructure.xmi
    http://www.omg.org/spec/UML/20090901/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof

    The same bug is also in the Documents/Specifications/2.4/Deliverable files in SVN revision 21132

  • Reported: UML 2.4 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

property.opposite

  • Key: UML241-19
  • Legacy Issue Number: 16412
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    It seems there is an issue with derived Property.opposite.

    Spec says:

    / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end.

    By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class.
    It does not work when navigable end is owned by association:

    Constraint #1:
    [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    Any comments?
    Which one is correct? Property description or constraint text?

  • Reported: UML 2.4 — Mon, 1 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Number of Compliance Levels

  • Key: UML241-13
  • Legacy Issue Number: 16359
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    In the OMG Unified Modeling Language (OMG UML), Infrastructure document,
    it is said that this document, and the Superstructure document, should be
    used in conjunction (page 9) as the two volumes cross-reference each other
    and the specifications are fully integrated.

    But on page 2 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document we can find 2 compliance levels. And on page 2 of the OMG Unified
    Modeling Language (OMG UML), Superstructure document (ptc/2010-11-14 version
    2.4) we can find 4 compliance levels. Which is rioght ? Two our four ? As
    both documents are integrated shouldn't them have the same explanation for
    compliance levels ?

    It gets a little confusing to understand this.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Core Package versus Construct Package

  • Key: UML241-16
  • Legacy Issue Number: 16362
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 14, Figure 7.3 of the OMG Unified Modeling Language (OMG UML),
    Infrastructure document, I think there's a small error in the picture.

    The picture details the Core package, as explained in the text. But
    the name in the top of the package is written as "Construct" (please
    note that I'm talking about the name of the whole package, the left-
    hand side one in the picture, and not the name os the sub-package
    Construct itself).

    It gets a little bit confusing that the name of the whole package
    is written as "Construct" instead of "Core".

    Please note also that the Figure "Part II, Figure 2" on page 27 is
    the same. And Figure 9.1 on page 29. And Figure 10.1 on page 91. And
    11.1 on page 103. And maybe others that I couldn't find now.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

XML Metadata Interchange (XMI) - p9

  • Key: UML241-15
  • Legacy Issue Number: 16361
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 9 of the OMG Unified Modeling Language (OMG UML), Superstructure
    document, there is the same error (or maybe, typo) as in the Infrastructure
    document. It's in the seventh bullet at the beginning of the page, where
    it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

XML Metadata Interchange (XMI)

  • Key: UML241-14
  • Legacy Issue Number: 16360
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 5 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document, I think there's a small error (maybe a typo). It's in the last
    line of this page, where it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML type Real specification

  • Key: UML241-12
  • Legacy Issue Number: 16301
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Version 2.4 intruduces a new UML primitive type - Real.

    This information has not been mentioned on page 127 - 7.3.44.

    The package name (I suppose Kernel) has not been defined for LiteralReal - chapter 7.3.29 (page 95); table of contents (page II).

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Interface element - associations multiplicity not defined

  • Key: UML241-11
  • Legacy Issue Number: 16268
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 36, Figure 7.16 shows the content of Interface package. Interface element has associations to four other elements with multiplicity of *. Multiplicity information is not defined on page 89, where the association names for Interface element has been defined.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Missing Namespace in Dependencies package definition?

  • Key: UML241-10
  • Legacy Issue Number: 16267
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 35, Figure 7.15 the Namespace element is described as Namespace from Dependencies package, but (on page 103) Namespace element is defined from Kernel package only.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Property::isID

  • Key: UML241-9
  • Legacy Issue Number: 16210
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Is there a semantic difference between markign an associationEnd with isID=true and putting an upper bound of "1" on its opposite end (i.e., a value of this end is related to a maximum of 1 value on the other end)?

    If there is no semantic difference, is Property::isID only useful for attributes that are not association ends (like primitive attributes that are typically not ends)?

  • Reported: UML 2.4 — Mon, 2 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Assume a classifier A has a property that is an association end typed by B, and assume its opposite end has the
    multiplicity 1..1.
    Even if this implies that, at any time, only one instance of A can be associated with a given instance of B, nothing
    stops this association from changing over time. Thus, a given instance of B cannot be used “a priori” for identifying
    an instance of A. So there is no redundancy with the semantics of Property::isID as suggested by the issue.
    Disposition: Closed - No Change

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

Typo: "joint" should say "join"

  • Key: UML241-7
  • Legacy Issue Number: 16164
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    Typo: say join and not joint.

    The notation for a fork and join is a short heavy bar (Figure 15.25). The bar may have one or more arrows from source
    states to the bar (when representing a joint).

  • Reported: UML 2.4 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    It should indeed be “join” and not “joint”. Correct the text appropriately

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

Figure 15.32

  • Key: UML241-8
  • Legacy Issue Number: 16169
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 16111

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

typo on page 46

  • Key: UML241-3
  • Legacy Issue Number: 16110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    look at Page 46, there is a typo in the word "metaatribute" in the sentence:
    ...
    "AssociationEnd was a metaclass in prior UML, now demoted to a member of
    Association. The metaatribute targetScope"

  • Reported: UML 2.4 — Wed, 6 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Figure 15.32

  • Key: UML241-4
  • Legacy Issue Number: 16111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I downloaded (and partially read) the UML Superstructure file "10-05-05.pdf" from your site. That's one of two defining documents of UML 2.3.

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose.

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Agreed. This is diagram 14.5 in the new text.
    Fix the diagram by replacing the second “entry” label with the label “exit”.

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

No Rules for Element Names

  • Key: UML241-5
  • Legacy Issue Number: 16115
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    UML specification does not provide exact rules for element names. For example, namespace "provides a means for resolving composite names, such as name1::name2::name3." What are the rules for the name1/2/3? Could we use spaces, dashes, digits?
    For the class name we should: "capitalize the first letter of class names (if the character set supports uppercase)." But what are the rules for the class name? "A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse." But what are the rules for the use case name?

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There are no rules for names in UML. The UML standard does not restricted what characters can be used in a name
    or how the name is constructed.
    Disposition: Closed - No Change

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

Wrong package name on several Figures

  • Key: UML241-6
  • Legacy Issue Number: 16120
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Several Figures has wrong package name shown. In all cases package name should be "Core" instead of "Constructs":

    • Figure 7.3 - The Core packages
    • Part II, Figure 2 - The Core package contains the packages PrimitiveTypes, Abstractions, Basic, and Constructs...
    • Figure 9.1 - The Core package is owned by the InfrastructureLibrary pack...
    • Figure 10.1 - The Core package is owned by the InfrastructureLibrary package...
    • Figure 11.1 -The Core package is owned by the InfrastructureLibrary package...

    Also, the package name should be shown on the tab.

  • Reported: UML 2.4 — Tue, 19 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong

  • Key: UML241-2
  • Legacy Issue Number: 16002
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    Figure 15.45 of superstructure v2.3 illustrates the representation of deferred triggers on states. The transition between states "Get Cups" and "Pour coffee" specifies a trigger "light goes out" which is also identified as a deferred trigger of state "Get Cups". Does "light goes out" trigger the transition, or is it deferred? If the figure is not wrong, it would probably be helpful to add a comment in the text (note that figure 15.45 is not referenced in the text).

  • Reported: UML 2.4 — Tue, 1 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Indeed, this is a very confusing example and is also wrong as the submitter points out. Also, there should
    be some explanation of this diagram.
    Replace this diagram with a simpler one and add some explanatory text.

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

Can a Generalization really be in multiple GeneralizationSets?

  • Key: UML241-1
  • Legacy Issue Number: 15993
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    According to the abstract syntax, Generalization::generalizationSet has upper bound *.

    According to the text:

    Package PowerTypes A generalization can be designated as being a member of a particular generalization set.

    There is only one place where the possibility of many sets is mentioned, where it says:

    “The generalizationSet association designates the collection of subsets to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into subsets (e.g., partitions or overlapping subset groups) using the generalizationSet association. Each collection of subsets represents an orthogonal dimension of specialization of the general Classifier.”

    The first of these sentences implies that a Generalization can belong to many (“collection of”) GeneralizationSets. The second sentence contains a phrase “subsets (e.g., partitions or overlapping subset groups)” that makes little sense. Rephrasing “subset groups” as “subsets” gives us “e.g., partitions or overlapping subsets” which seems to imply that the GeneralizationSets may overlap. But then “Each collection of subsets represents an orthogonal dimension of specialization” translates to “each collection of GeneralizationSets represents an orthogonal dimension…” which is obviously wrong. Rephrasing as “Each GeneralizationSet represents an orthogonal dimension …” makes more sense: but if they are orthogonal, how can they overlap?

    Then, in the notation and further explanations, there is no discussion whatsoever of the possibility of a generalization belonging to many GeneralizationSets.

    I think this is clearly an error in the metamodel.

  • Reported: UML 2.4 — Thu, 27 Jan 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The text that the issue complains about is no longer in the spec. It’s clear that a Generalization can belong
    in more than one GeneralizationSet: “The generalizationSet property designates the GeneralizationSets to
    which the Generalization belongs.”
    However, there is a misleading phrase in the Notation that could be improved.

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