Issue 6628: UML 2 Super/Action/featuringClassifier misinterpreted (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature! Resolution: see above Revised Text: Actions taken: November 25, 2003: received issue March 8, 2005: closed issue Discussion: StructuralFeatureAction class, Constraints, add a new constraint: [ ] The structural feature has exactly one featuringClassifier. End of Annotations:===== ubject: UML 2 Super/Action/featuringClassifier misinterpreted X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 25 Nov 2003 08:27:04 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/25/2003 08:27:07, Serialize complete at 11/25/2003 08:27:07 The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature! Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 OMG Issue No: 6628 Title: UML 2 Super/Action/featuringClassifier misinterpreted Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature! Discussion: StructuralFeatureAction class, Constraints, add a new constraint: [ ] The structural feature has exactly one featuringClassifier. Disposition: Resolved From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Sat, 10 Jul 2004 08:14:38 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, some comments.... 4932: This issue resolution does two things: (i) rename StartOwnedBehaviorAction to StartClassifierBehaviorAction and clean up and (ii) introduce StartClassifierStateMachineAction. There are no problems with (i), but I seriously doubt the need for (ii) in the general purpose UML. This is similar to having an action that starts a piece of code in the middle, skipping the first 20 lines, for example. I think this is a coding style that is rather risky. There could be significant parts of the behavior that must be executed in the skipped states for the state machine to make sense. You cannot wantonly start in the middle of a statemachine, or any other behavior for that matter, in general. The behavior would have to be defined in that way. But if you designed a behavior this way, you would have provided appropriate routes from the initial state (e.g., by using a branch right after the initial state). In fact, we already have the capability requested, in the form of the entry points into a statemachine. You could enter the state machine through an entry point that leads to the desired state, effectively allowing execution to begin at that state, rather than starting in the initial state. The difference to your solution is that the non-local entry is designed into the state machine, not wantonly imposed without assuring that it will work. And, of course, it is already in the specification. In summary, while part (i) of the solution is fine, I believe we should not do part (ii). I could see the following middle ground: Add an action that causes the state machine to be started and entered at a specific entry point. 6628: There seems to be some initial text missing in the last line of the discussion, as it starts with "[]". In general, would it not be better to constrain featuringClassifier to 1..1 in Kernel? The infrastructure could keep it general? 6917: It appears to me that there always would be a context for the action. Are there any situations you envision where you would not have a context? If there always is a context, we should change Figure 176, rather than the text. 7378: I agreed in our discussions to defer the solution to this problem, but not to close it. We need to work out a mechanism in the future that packages make localized changes, as in the example of streaming. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Saturday, July 10, 2004 7:21 AM > To: uml2ftf > Subject: Activity/action resolutions for ballot 19 > > > > Hi all, > > Here are some activity/action resolutions for > ballot 19. > Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 6628, 6917, 6917 Date: Sun, 11 Jul 2004 11:18:36 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, (and Bran, see 6628) > 6628: There seems to be some initial text missing in the last line of > the discussion, as it starts with "[]". "[]" meant to insert the appropriate constraint number, will clarify. > In general, would it not be better to constrain featuringClassifier > to 1..1 in Kernel? The infrastructure could keep it general? The action only works in that case, so might as well make it explicit, but I don't want to take the issue from Classes. Bran, should this be reassigned to Classes? > 6917: It appears to me that there always would be a context for the > action. Are there any situations you envision where you would not > have a context? If there always is a context, we should change Figure > 176, rather than the text. OK. > 7378: I agreed in our discussions to defer the solution to this > problem, but not to close it. We need to work out a mechanism in the > future that packages make localized changes, as in the example of > streaming. I reread the issue text and it only says that streaming is inappropriate, because there are other mechanisms to do it. The resolution text explains why this isn't the case. Let me know why if you think this isn't true. Your other issue regarding the scope of application of streaming and packaging around that is separate. Please file it and we can address. Conrad e-mail: bselic@ca.ibm.com