Issue 6489: Ports in Protocol State Machines (uml2-rtf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Protocol machines should not have ports in them. It should be an extension in the ports package. Otherwise there is a backwards dependency onto composite structure. Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Actions taken: November 7, 2003: received issue Discussion: Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency. Furthermore, creating a dependency from composite structures to statemachines would create a more serious layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done by an RTF at this point. End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Ports in Protocol State Machines Protocol machines should not have ports in them. It should be an extension in the ports package. Otherwise there is a backwards dependency onto composite structure. OMG Issue No: 6489 Title: Ports in Protocol State Machines Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Protocol machines should not have ports in them. It should be an extension in the ports package. Otherwise there is a backwards dependency onto composite structure. Discussion: Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency. Furthermore, creating a dependency from composite structures to statemachines would create a more serious layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done by an RTF at this point. Disposition: Defer Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 19 updates Date: Fri, 16 Jul 2004 14:09:03 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Eran, > I will add two new simple resolutions proposed by Eran to ballot 19 (see > below) The resolution to 6489 says there is no enough time to do this simple bit of layering state machines, but there seems to be enough time to do enormous amounts of layering in activities/actions. I'd like these principles applied more evenly in the spec. To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 19 updates X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 16 Jul 2004 14:35:02 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/16/2004 14:35:05, Serialize complete at 07/16/2004 14:35:05 Conrad, Would you like me to pull the resolution to 6489 from ballot 19, then? Regarding the uneven nature of the principles: you are undoubtedly right, but this is not because of any inherent bias. Had I known that the fix to the activities/actions issue would have required layering, I would have certainly advised against it (in fact, you may recall that I did just that several days ago -- although it may have been too late at this point). However, this was a fix that grew gradually from something relatively small (i.e., a simple specialization of structured activity nodes) into something more substantive. Of course, another reason for the unevenness is the difference in time that various FTF members are investing into FTF work. For whatever reason, the state machine group did not apply themselves to the extent that, say, the actions and activities groups did. Since the chairs are not in a position to dictate to any FTF members, the difference in effort will also manifest itself in this unfortunate unevenness. The only way we could get an "even" application of the principlies is if we asked all members to work at the pace of the slowest one. Bran "Conrad Bock" 07/16/2004 02:09 PM Please respond to conrad.bock To , cc Subject RE: Ballot 19 updates Bran, Eran, > I will add two new simple resolutions proposed by Eran to ballot 19 (see > below) The resolution to 6489 says there is no enough time to do this simple bit of layering state machines, but there seems to be enough time to do enormous amounts of layering in activities/actions. I'd like these principles applied more evenly in the spec. Conrad