Issue 4936: StartStateMachine clarification (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: [Conrad Bock] Does StartStateMachine cause the intial state to be entered and its outgoing transition taken? Ie, what is the semantics in relation to the RTC step. Resolution: Revised Text: [Action Semantics FTF]: The 1.4 is contradictory is a couple places: - State machine can't rest in pseudostate, but transition wf 5 says transitions from initial states may not have trigger event. - and wf 6 says it may have a call event stereotyped as «create». Defer the above to UML RTF. Reword StartObjectStateMachine semantics to say it starts the executions of the object's state machines. Discussion for UML 2.0: ??The resolution to issue 4298 has removed wf 5, so the contradiction noted above is no longer an impediment ??The action StartObjectStateMachine has been generalized to StartOwnedBehaviorAction. The semantics of starting state machines are fully described in section 15.3.11 on page 499 (the case of Composite state). Disposition: Closed, no change Actions taken: March 5, 2002: received issue October 22, 2002: Deferred December 28, 2004: resolved by the UML 2.0 Superstructure FTF March 9, 2005: closed issue Discussion: The 1.4 is contradictory is a couple places: - State machine can't rest in pseudostate, but transition wf 5 says transitions from initial states may not have trigger event. - and wf 6 says it may have a call event stereotyped as «create». Defer the above to UML RTF. Reword StartObjectStateMachine semantics to say it starts the executions of the object's state machines. End of Annotations:===== Summary: StartStateMachine clarification Text: [Conrad Bock] Does StartStateMachine cause the intial state to be entered and its outgoing transition taken? Ie, what is the semantics in relation to the RTC step. From: "Rumbaugh, James" To: conrad.bock@kabira.com, ActionFTF Subject: RE: Draft Action FTF ballot, #3 Date: Fri, 29 Mar 2002 09:13:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !/P!!/h2!!D>!!!:=\d9 See comments below on some items: > > VOTE (YES|NO|ABSTAIN): > > Issue 4936: StartStateMachine clarification > http://cgi.omg.org/issues/issue4936.txt > > Resolution: Accept > > Discussion: > > Clarify that StartStateMachine is used when the > transition from top > initial state has no trigger. In this case, no > constructor arguments > are needed. Otherwise, in 1.4 an event with stereotype > create must be > sent, and this can have constructor arguments. > Clarify that, in the case in which the state machine has a create event, the sending of the create event actually starts the state machine (and thereupon triggers the initial transition). The implicit create of the state machine has not been explicitly described yet. Reply-To: From: "Conrad Bock" To: "ActionFTF" Subject: RE: Draft Action FTF ballot, #3 Date: Mon, 1 Apr 2002 15:56:06 -0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Jim, > > Issue 4936: StartStateMachine clarification > Clarify that, in the case in which the state machine has a create event, > the sending of the create event actually starts the state machine > (and thereupon triggers the initial transition). I'd rather leave that to the state machine chapter, and not have it redundantly in the actions. The UML 1.4 is actually leaves open the question of when the create event must be sent. The object can be created and resting in a pseudo state receiving events, in contradiction to the RTC semantics. It would be better not to get into that area in the action semantics. > > VOTE (YES|NO|ABSTAIN): > > > > Issue 4938: include Actions.idl > > http://cgi.omg.org/issues/issue4938.txt > This should be DECLINE. The rest of UML should not include Actions.idl, > because we packaged it > to avoid dependencies. OK, I'll take it as editorial that StateMachine.idl should not have Actions.idl in it. > > Issue 4939: Hard/soft deletion actions. > > http://cgi.omg.org/issues/issue4939.txt > > > > Resolution: Decline with clarification > > It might help to point out that normally the compiler or tool would > generate the code to first force the state machine to exit to the > outermost state and then would destroy the object when all of its > context is quiescent. > > Typo: It is DestroyObjectAction, not DeleteObjectAction. Rather than making suggestions to vendors, we can just point out that soft destruction can be achieved by sending an event for a transition out of a state containing all the substates of the top state (presumably the top state cannot have a transition going out of it). Conrad From: "Rumbaugh, James" To: conrad.bock@kabira.com, ActionFTF Subject: RE: Draft Action FTF ballot, #3 Date: Mon, 1 Apr 2002 16:11:31 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@kabira.com] > Sent: Monday, April 01, 2002 3:56 PM > To: ActionFTF > Subject: RE: Draft Action FTF ballot, #3 > > > Jim, > > > > Issue 4936: StartStateMachine clarification > > > Clarify that, in the case in which the state machine has a > create event, > > the sending of the create event actually starts the state machine > > (and thereupon triggers the initial transition). > > I'd rather leave that to the state machine chapter, and not have it > redundantly in the actions. The UML 1.4 is actually leaves open the > question of when the create event must be sent. The object can be > created and resting in a pseudo state receiving events, in > contradiction > to the RTC semantics. It would be better not to get into that area in > the action semantics. > > I'm still a bit troubled that, in the action semantics part, we discuss how to create a state machine that does not have an initial transition but we don't do it for one that does have an initial transition. The asymmetry of the situation is unsettling. It seems that either actions semantics should say nothing about creating state machines or it should create them in some raw form that the state machine part then describes. I'm not sure how to approach this in a clean way, however. My best suggestion is to allow a create state machine action to operate on a state machine with an initial state, and leave it up to the state machine part to emphasize that the state machine does not actually start until it receives an initial transition. I'm not sure I buy the objection that this means that the start pseudostate IS a state; we would be saying that the state machine is in some kind of raw form. OMG Issue No: 4936 Title: StartStateMachine clarification Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Does StartStateMachine cause the intial state to be entered and its outgoing transition taken? Ie, what is the semantics in relation to the RTC step. Discussion: [Action Semantics FTF]: The 1.4 is contradictory is a couple places: - State machine can't rest in pseudostate, but transition wf 5 says transitions from initial states may not have trigger event. - and wf 6 says it may have a call event stereotyped as «create». Defer the above to UML RTF. Reword StartObjectStateMachine semantics to say it starts the executions of the object's state machines. Discussion for UML 2.0: · The resolution to issue 4298 has removed wf 5, so the contradiction noted above is no longer an impediment · The action StartObjectStateMachine has been generalized to StartOwnedBehaviorAction. The semantics of starting state machines are fully described in section 15.3.11 on page 499 (the case of Composite state). Disposition: Closed, no change - Jim