Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA35-265 when is a connection a "bi-directional connection"? UML 2.0 open
UMLR-54 Operation calls on behavior ports UML 2.0 open
UMLR-35 Disjointness should be independent of generalization UML 2.0 open
UML241-46 actions UML 2.0 open
UML241-41 Section: 9.3.12 UML 2.0 open
UML241-37 Section: 11.3.39 UML 2.0 open
UML241-33 What is a mapping that is not computable? UML 2.0 open
UML241-32 Components UML 2.0 open
UML241-35 DeploymentSpecification - notation for DeploymentSpecification on the insta UML 2.0 open
UMLR-75 Page: 107 UML 2.0 open
UMLR-70 Section: Classes UML 2.0 open
UMLR-72 Section: Classes UML 2.0 open
UMLR-71 Section: Activities UML 2.0 open
UMLR-40 Properties on Association for end objects UML 2.0 open
UMLR-39 Notation for classifierBehavior UML 2.0 open
UMLR-38 Contextualized attribute values Figures 121 UML 2.0 open
UMLR-42 ReadStructuralFeatureAction UML 2.0 open
UMLR-34 Section: Classes, Behavior UML 2.0 open
UMLR-37 End objects of a link In the semantics of AssociationClass UML 2.0 open
UMLR-36 Action for retrieving activity instance UML 2.0 open
UMLR-44 Activities section UML 2.0 open
UMLR-43 Section: 16.3.1 UML 2.0 open
UMLR-48 Add constraints on ConditionalNode UML 2.0 open
UMLR-47 ExpansionRegion (behavior in the shorthand notation) UML 2.0 open
UMLR-46 Section: Activities : Why is exception type needed? UML 2.0 open
UMLR-45 Section: Activities - clarification UML 2.0 open
UMLR-103 Section: 7 UML 2.0 open
UMLR-59 Section: 14.3.3 Page: 508+ UML 2.0 open
UMLR-58 Section: 14.3.3 UML 2.0 open
UMLR-51 Section: 10.3.1 UML 2.0 open
UMLR-60 ConditionalNode inputs used by more than one test UML 2.0 open
UMLR-55 Possibility to define a Collection as default Value needed UML 2.0 open
UMLR-49 SequenceNode should have way to set output pins in CompleteStructured UML 2.0 open
UMLR-80 Section: Sequence diagrams UML 2.0 open
UMLR-32 Alternative entry and exit point notation is ambiguous UML 2.0 open
UMLR-3 More explanation needed on Figure 339 UML 2.0 open
UMLR-2 More examples UML 2.0 open
UMLR-4 Parameterization of lifelines UML 2.0 open
UMLR-19 Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R UML 2.0 open
UMLR-27 inconsistency in the action model UML 2.0 open
UMLR-26 large overlap between structural features and variables UML 2.0 open
UMLR-28 metaattribute isReadOnly UML 2.0 open
UMLR-29 surface notation for state machines UML 2.0 open
UMLR-30 Provide exception handling for all behaviors. UML 2.0 open

Issues Descriptions

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

Operation calls on behavior ports

  • Key: UMLR-54
  • Legacy Issue Number: 8748
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Updated: Fri, 20 Apr 2018 14:30 GMT

Disjointness should be independent of generalization

  • Key: UMLR-35
  • Legacy Issue Number: 8014
  • Status: open  
  • Source: NIST ( Mr. Evan K. Wallace)
  • Summary:

    Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Sun, 28 Feb 2016 03:57 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: 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

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

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

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

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

Page: 107

  • Key: UMLR-75
  • Legacy Issue Number: 9145
  • Status: open  
  • Source: University College London ( James Skene)
  • Summary:

    I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-70
  • Legacy Issue Number: 9008
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-72
  • Legacy Issue Number: 9015
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

  • Key: UMLR-71
  • Legacy Issue Number: 9013
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Properties on Association for end objects

  • Key: UMLR-40
  • Legacy Issue Number: 8077
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for classifierBehavior

  • Key: UMLR-39
  • Legacy Issue Number: 8034
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contextualized attribute values Figures 121

  • Key: UMLR-38
  • Legacy Issue Number: 8026
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReadStructuralFeatureAction

  • Key: UMLR-42
  • Legacy Issue Number: 8335
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes, Behavior

  • Key: UMLR-34
  • Legacy Issue Number: 8012
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

  • Reported: UML 2.0 — Wed, 29 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

End objects of a link In the semantics of AssociationClass

  • Key: UMLR-37
  • Legacy Issue Number: 8024
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Action for retrieving activity instance

  • Key: UMLR-36
  • Legacy Issue Number: 8016
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activities section

  • Key: UMLR-44
  • Legacy Issue Number: 8473
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Add presentation option for multiple object flows between two actions, shown as one line.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.1

  • Key: UMLR-43
  • Legacy Issue Number: 8464
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add constraints on ConditionalNode

  • Key: UMLR-48
  • Legacy Issue Number: 8495
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionRegion (behavior in the shorthand notation)

  • Key: UMLR-47
  • Legacy Issue Number: 8489
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities : Why is exception type needed?

  • Key: UMLR-46
  • Legacy Issue Number: 8480
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities - clarification

  • Key: UMLR-45
  • Legacy Issue Number: 8479
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7

  • Key: UMLR-103
  • Legacy Issue Number: 10345
  • Status: open  
  • Source: NUI Maynooth ( Jacqueline McQuillan)
  • Summary:

    There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract)

  • Reported: UML 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3 Page: 508+

  • Key: UMLR-59
  • Legacy Issue Number: 8765
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3

  • Key: UMLR-58
  • Legacy Issue Number: 8764
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator.

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.1

  • Key: UMLR-51
  • Legacy Issue Number: 8693
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ConditionalNode inputs used by more than one test

  • Key: UMLR-60
  • Legacy Issue Number: 8779
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Possibility to define a Collection as default Value needed

  • Key: UMLR-55
  • Legacy Issue Number: 8756
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections.

  • Reported: UML 2.0 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SequenceNode should have way to set output pins in CompleteStructured

  • Key: UMLR-49
  • Legacy Issue Number: 8501
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Sequence diagrams

  • Key: UMLR-80
  • Legacy Issue Number: 9370
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

  • Reported: UML 2.0 — Tue, 21 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Alternative entry and exit point notation is ambiguous

  • Key: UMLR-32
  • Legacy Issue Number: 7952
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

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

More explanation needed on Figure 339

  • Key: UMLR-3
  • Legacy Issue Number: 6086
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More examples

  • Key: UMLR-2
  • Legacy Issue Number: 6083
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameterization of lifelines

  • Key: UMLR-4
  • Legacy Issue Number: 6088
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R

  • Key: UMLR-19
  • Legacy Issue Number: 6922
  • Status: open  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment).

    Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

inconsistency in the action model

  • Key: UMLR-27
  • Legacy Issue Number: 7337
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

large overlap between structural features and variables

  • Key: UMLR-26
  • Legacy Issue Number: 7329
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

metaattribute isReadOnly

  • Key: UMLR-28
  • Legacy Issue Number: 7338
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

surface notation for state machines

  • Key: UMLR-29
  • Legacy Issue Number: 7372
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide exception handling for all behaviors.

  • Key: UMLR-30
  • Legacy Issue Number: 7398
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT