Compliance ambiguity

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

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

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

  duplicate

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

There is a bug in additional operation 1 of the Namespace element

• Key: UML14-1041
• Legacy Issue Number: 5733
• Status: closed  
• Source: St. Petersburg State Technical University ( Nikolai Andreev)
• Summary:

  There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: “contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)”.

• Reported: UML 1.4 — Thu, 31 Oct 2002 05:00 GMT
• Disposition: Resolved — UML 1.4.2
• Disposition Summary:

  Issue 4848 also raises a similar problem with Namespace.contents

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

How to properly designate exception returned from message sent to Java obje

• Key: UML14-1040
• Legacy Issue Number: 5433
• Status: closed  
• Source: ObjectShare ( Rebecca Wirfs-Broc)
• Summary:

  I am trying to properly designate an exception returned from a message sent to a Java object.

  In UML a return is drawn as a dashed line with an open arrow. But is that the same for an exception returned? I can stereotype a return with the <<exception>> which is fine , but how do I properly draw the returned exception. I don't think the exception should be drawn the same as an asynchronous signal because control pops out from the exception raiser and returns to the callee at the exception handling point (it is the result of the original call, but the exception return is to a different point in the flow).... so it isn't exactly a signal.... but it does alter the control flow..

  So in my mind, if I wanted to show a returned exception, I should draw it like a return (dashed line with open stick arrowhead) labelled <<exception>>

  But I defer to someone with more expertise to untangle this for me. I spent time and could not find an answer to this in the UML 1.4 docs

• Reported: UML 1.4 — Mon, 17 Jun 2002 04:00 GMT
• Disposition: Resolved — UML 1.4.2
• Disposition Summary:

  This is a subset of the issue addressed by issue 7397.

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

In 3.23.1 "Notation" (Internationalization issues)

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

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

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

  No Data Available

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

No servant with object . minorcode=0 completed=NO

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

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

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

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

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

  No Data Available

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

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4

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

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

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

  It would appear that the fourth level carries on from 2.9.3.24

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

  No Data Available

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

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

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

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

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

  No Data Available

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

Who owns an Event?

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

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

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

  No Data Available

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

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