Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

  • Acronym: UML
  • Issues Count: 3
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Creation of an expansion node under an activity is allowed by UML and SysML specifications

  • Key: UMLR-242
  • Legacy Issue Number: 15849
  • Status: open  
  • Source: Safran Engineering Services/Airbus ( gautreault fabien)
  • Summary:

    Which semantic for an expansion node owned by an activity (instead an expansion region)?

    According OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Chapter 12.3.26

    An expansion node is an object node used to indicate a flow across the boundary of an expansion region.

    An expansion region is a structured activity region that executes multiple times corresponding to elements of an input collection. This specific structured activity node is using expansion node as input and output. From outside the expansions regions the elements of expansion nodes only appear as a collections, the elements of collection are only accessible from "inside the collection".

    Semantic of an expansion node owned by an expansion region is then well defined. However, in abstract syntax nothing prevents to create an expansion node owned by an activity instead of an expansion region. In this case semantic is questionable.
    If this kind of construction is not expected, a specific constraint should be added in UML specification in order to prevent an activity to owned expansion nodes. On the contrary, if this construction allowed, associates semantic should be defined.

  • Reported: UML 2.3 — Mon, 29 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Constraint for multiple associations

  • Key: UMLR-239
  • Legacy Issue Number: 15763
  • Status: open  
  • Source: Oracle ( Antonio Petri)
  • Summary:

    There isn't a constraint that prevents multiple associations from being specified between the same Actor and Use Case. Multiplicity is handled already by the multiplicity at the association's ends, so having two or more different associations seems to be redundant.

  • Reported: UML 2.3b1 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigability orthogonal to end ownership or not?

  • Key: UMLR-257
  • Legacy Issue Number: 16350
  • Status: open  
  • Source: gmail.com ( Adam Ciążyński)
  • Summary:

    At one point (page 42) the specification reads:
    "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation."

    The same thought can be found here: http://www.omg.org/issues/issue15128.txt :
    "... an old constraint from UML 1.x when navigability meant the same as ownership of property"

    However at another place (page 38) the specification reads:
    "An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends; otherwise, the association is not navigable from the opposite ends."

    So is navigability orthogonal to end ownership or not? I think that the specification is somewhat unclear concerning these issues.

    The descriptions of ownedEnd and navigableOwnedEnd don't clarify much and seem to be too brief.

  • Reported: UML 2.3 — Tue, 28 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT