Issue 6275: raisedException (uml2-rtf) Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com) Nature: Uncategorized Issue Severity: Summary: Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well. I believe this violates a well-formedness rule that all structural features must be distinguishable. Resolution: See issue 8461 for disposition Revised Text: Actions taken: September 18, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: The spec explicitly states that such redefinitions need to be made explicitly. This is related to the resolution to more general issue 8461. Any resolution to this issue will be resolved as part of the resolution to 8461. End of Annotations:===== ubject: raisedException Date: Thu, 18 Sep 2003 10:20:21 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: raisedException Thread-Index: AcN99PSvrrXVoKS+Sa+2O3G41TvKRA== From: "Steven T. Cramer" To: Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well. I believe this violates a well-formedness rule that all structural features must be distinguishable. Steven T. Cramer TimeWarp Engineering Ltd. 12255 Jones Park Court Colorado Springs, Colorado 80921 GMT-7 719.487.1623 www.TimeWarpEngineering.com SCramer@TimeWarpEngineering.com Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 11:15:55 -0700 To: UML-RTF From: Joaquin Miller Subject: Ballot 1 draft Please review the proposed ballot 1 resolutions. I sent out a batch yesterday and others will, presumably, send some out later today and tomorrow. If you have any problems with any of the resolutions, this is the time to raise them, not when the ballot has been issued and the vote started. Issue 6275 This would have been clearer had there been an explicit {redefines raisedException} constraint on Operations::raisedException, so let's add that. Or, let's make explicit the reasonable policy that we have limited resources, so we will fix actual errors but not work to improve usability. Issue 6616 The isLeaf feature seems unnecessary, since it is easy to determine if something is a leaf classifier simply by checking whether it is included in the .generalization. meta-attribute of any classifier. In contrast, the .isRoot. property, on the other hand is necessary since it defines a constraint that defines that a classifier must not have any further generalizations. Or is it our intention that UML 2 does not have the capability to specify that the authors of a model intend that users are not to generalize from certain classifiers? Or, perhaps, is it explicit or implicit or assumed in the UML 2 specification that users can't or won't generalize existing classifiers, but that they can and will specialize existing classifiers? Issue 8075 Our audience includes readers of paper documents. If this happens only in a few places, let's correct this usability problem. If it is our policy to cater only to readers using Acrobat or Acrobat Reader, well... Maybe it is too late to change that policy. Issue 8082 Does the proposed resolution describe a best practice? Wouldn't the spec shine even more brightly if it stuck to a single style, even in examples? This is a pedagogical question, and very much worth our time to consider. Issues 8081, 8085, and 6502 I don't want to make work, but do have a question: Is there a positive reason to use integer instead of unlimited natural in the specification of lower bound, and then backpedal with a constraint? (I bet there is a positive reason not to use unlimited natural, and a good one; but then let's mention that reason in the resolution. If we had more resources, i'd urge adding natural to our armamentarium. ) Cordially, Joaquin www.joaquin.net