Issue 4932: Starting state machine (uml2-rtf) Source: Industrial Internet Consortium (Mr. Stephen J. Mellor, mellor(at)iiconsortium.org) Nature: Uncategorized Issue Severity: Summary: [Steve Mellor] The action semantics has an action that starts a state machine. The state machine starts in some known initial (pseudo-)state. There are many cases where one wants to initialize a state machine so that starts in a specified (non-initial) state. Therefore the StartStateMachineAction needs to accept a state (possibly multi-leveled) as an input. The state machine will not execute any procedures or actions until after the state machine is in the target state and then detects an event. Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Discussion This can be resolved by having the initial transition terminate on a choice point with guards that use the input parameter values used to start the state machine. There does not appear to be a need to add new features to state machines to support this. Disposition: Closed - No Change Actions taken: March 5, 2002: received issue October 22, 2002: Deferred February 20, 2015: closed issue Discussion: Application: restoring state. Requires static specification of state, so complexity will be the same as having transitions to each state, and sending an event. Would make a dependence of actions on state machines. Similar problems with restoring attribute values, etc, of objects. Requires tracking and restoring execution execution. Too much for FTF to do consistently [Action Semantics FTF]: Application: restoring state. Requires static specification of state, so complexity will be the same as having transitions to each state, and sending an event. Would make a dependence of actions on state machines. Similar problems with restoring attribute values, etc, of objects. Requires tracking and restoring execution execution. Too much for FTF to do consistently [UML 2 FTF] There is too much debate around this for the FTF to resolve. The use case is to bring up a software system that is embedded in a larger physical system. The embedded system has objects reflecting the state of the physical objects. The filer would like to start the software system by instantiating classes, with the new instance reflecting the state of the physical objects. Using triggers/guards on constructor inputs makes too cumbersome a model. There was some concern about referring to states from actions outside the object. However, states are not always internal. There was also concern that the details of restarting an application are not properly part of modeling. However, modeling is not limited to a particular level of implementation. There was debate on whether entry points could be used for the applications, but in any case, the action would need to refer to a state. End of Annotations:===== Summary: Starting state machine Text: [Steve Mellor] The action semantics has an action that starts a state machine. The state machine starts in some known initial (pseudo-)state. There are many cases where one wants to initialize a state machine so that starts in a specified (non-initial) state. Therefore the StartStateMachineAction needs to accept a state (possibly multi-leveled) as an input. The state machine will not execute any procedures or actions until after the state machine is in the target state and then detects an event. From: "Rumbaugh, James" To: "Stephen J. Mellor" , "Rumbaugh, James" , conrad.bock@kabira.com, ActionFTF Subject: RE: Draft Action FTF ballot, #3 Date: Mon, 1 Apr 2002 12:59:13 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Steve, A creat event is an event on the initial transition from the initial pseudostate to the initial state. In that case, you can't just create the state machine and then send the event separately (although I argued for doing just that) because a state machine cannot be IN a pseudostate. > > (0) // initial pseudostate > | > | create event > \/ > |----------| > State > |----------| > | > | > | > \/ > The example you show is NOT a create event, because it is on a transition leaving a real state, and the state machine can be started without it. - Jim > -----Original Message----- > From: Stephen J. Mellor [mailto:steve@projtech.com] > Sent: Monday, April 01, 2002 12:14 PM > To: Rumbaugh, James; conrad.bock@kabira.com; ActionFTF > Subject: RE: Draft Action FTF ballot, #3 > > > Jim wrote: > > > 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. > > > Steve says: > > What is a create event? Is it this: > > (0) // initial pseudostate > | > | [ create event would have to be here ] > \/ > |----------| > State > |----------| > | > | > | create event? [NO, just an ordinary event ] > \/ > > If not, what is it? > > -- steve > From: "Stephen J. Mellor" To: "Rumbaugh, James" , , "ActionFTF" Subject: RE: Draft Action FTF ballot, #3 Date: Mon, 1 Apr 2002 13:14:08 -0700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Jim wrote: 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. Steve says: What is a create event? Is it this: (0) // initial pseudostate | | \/ |----------| State |----------| | | | create event? \/ If not, what is it? OMG Issue No: 4932 Title: Starting state machine Source: Project Technology (Mr. Stephen J. Mellor, steve@projtech.com) Summary: The action semantics has an action that starts a state machine. The state machine starts in some known initial (pseudo-)state. There are many cases where one wants to initialize a state machine so that starts in a specified (non-initial) state. Therefore the StartStateMachineAction needs to accept a state (possibly multi-leveled) as an input. The state machine will not execute any procedures or actions until after the state machine is in the target state and then detects an event. Discussion: [Action Semantics FTF]: Application: restoring state. Requires static specification of state, so complexity will be the same as having transitions to each state, and sending an event. Would make a dependence of actions on state machines. Similar problems with restoring attribute values, etc, of objects. Requires tracking and restoring execution execution. Too much for FTF to do consistently [UML 2 FTF] The issue refers to the StartOwnedBehaviorAction, which is incorrectly named, since it starts the classifier behavior of an object, not all the owned behaviors. Rename and specialize for starting state machines classifier behaviors, as follows. Section 11.1, last sentence, top of Page 205: replace .StartOwnedBehaviorAction. with .StartClassifierBehaviorAction.. Insert .classifier. before .behavior.. In Figure 151, change the name of StartOwnedBehaviorAction to StartClassifierBehaviorAction, and add a child of StartClassifierBehaviorAction called StartOwnedStateMachineAction with an association to BehaviorStateMachines:State as shown below. In StartOwnedBehaviorAction class Change name to StartClassifierBehaviorAction. First sentence, replace .StartOwnedBehaviorAction. with .StartClassifierBehaviorAction.. Replace .owned. with .classifier.. Constraints, replace the first constraint with [1] The multiplicity of the input pin is 1..1. Add second constraint: [2] If the input pin has a type, then the type must have a classifier behavior. Semantics, first sentence, replace .StartOwnedBehaviorAction. with .StartClassifierBehaviorAction.. Replace .owned. with .classifier.. After the comma, add .or the object has no classifier behavior,.. Rationale, replace .owned. with .classifier.. Changes from previous UML, replace the first sentence with .StartOwnedBehaviorAction is a generalization of UML 1.5 StartStateMachineAction.. Add new class entry in Actions chapter: StartClassifierStateMachineAction StartOwnedStateMachine Action is a start classifier behavior action that starts the classifier state machine of the input object in the states specified. Attributes None. Associations startState : State [1..*] The states in which to start the state machine of the input object. Constraints [1] The type of the input pin is same as the type that as the state machine that owns the specified state. [2] The state machine that owns the specified state must be a classifier behavior of the type of the input pin. [2] Multiple start states must be in separate concurrent regions of the same state machine. Semantics In addition to the semantics of StartClassifierBehaviorAction, this starts the classifier state machine of the input object, putting the object immediately in the state specified by the action. Notation None. Examples Suppose a software system is meant to reflect the state of a factory, but does not presistently store that state. When the system starts up, it accepts the current state of the factory and creates objects, and starts their state machines in the states specified. Rationale In addition to the rationale of StartClassifierBehaviorAction, StartClassifierStateMachine is to simplify applicatioins that use state machines with dynamically chosen start states. Changes from previous UML StartClassifierStateMachine is an extension of UML 1.5 StartStateMachineAction. 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. > To: Cc: "uml2ftf" Subject: Re: Activity/action resolutions for ballot 19 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 10 Jul 2004 18:31:54 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/10/2004 18:31:58, Serialize complete at 07/10/2004 18:31:58 Conrad, I have to say that I have misgivings about the proposed resolution to 4932. First of all, this is an action that belongs in the state machines chapter. There are sections in that chapter that already deal with this issue and they should be aligned. Second, it s incorrect in using State as the target of StartClassifierStateMachineAction. The target should be Pseudostate, since the starting state for state machines is an initial pseudostate. Thirdly, it's relationship to protocol state machines needs to be understood. I also think the name is incorrect: you are not starting the state machine of the classifier but the state machine of an instance of the classifier. In some systems, such as Smalltalk in which the class itself is an object, this name will be ambiguous. State machines are the responsibility of the state machines working group who have been working on these issues for many years and know what they need and they should NOT be handled by the action semantics team. I think that the right response for this is to leave out state machines altogether from this resolution and only deal with the general case of what it means to "start" an owned behavior. Alternatively, I can transfer the issue to the state machines group. Which would you prefer? Cheers, Bran From: "Thomas Weigert" To: "Branislav Selic" , Cc: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Sat, 10 Jul 2004 17:44:30 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, you make a very good point. Moreover, this action, I believe, drastically changes state machines as behavioral descriptions by exposing the state to the client. Up to this point, clients could not alter the defined behavior other than by (i) passing parameters upon creation and (ii) causing triggering events that would fire transitions. The notion of entry points was explicitly added in UML 2.0 to allow clients to request different starting states of the state machine, but only, if the behavior provides for this. In general, actions that leverage other packages, both structural or behavioral, should be added by the teams managing those packages, rather than by the action team, to ensure consistency with the existing capabilities of those packages. For example, in the solution to 4932 the fact that this capability would be better provided through leveraging the entry points was missed. I think there is a broader rule hiding here: In general, the philosophy should be that no package should add to packages that are not dependent on it (either directly or via package merge). Some of the issues filed are due to not adhering to this guide line. (E.g., stream behavior added in activities to all behaviors.) Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, July 10, 2004 5:32 PM To: conrad.bock@nist.gov Cc: uml2ftf Subject: Re: Activity/action resolutions for ballot 19 Conrad, I have to say that I have misgivings about the proposed resolution to 4932. First of all, this is an action that belongs in the state machines chapter. There are sections in that chapter that already deal with this issue and they should be aligned. Second, it s incorrect in using State as the target of StartClassifierStateMachineAction. The target should be Pseudostate, since the starting state for state machines is an initial pseudostate. Thirdly, it's relationship to protocol state machines needs to be understood. I also think the name is incorrect: you are not starting the state machine of the classifier but the state machine of an instance of the classifier. In some systems, such as Smalltalk in which the class itself is an object, this name will be ambiguous. State machines are the responsibility of the state machines working group who have been working on these issues for many years and know what they need and they should NOT be handled by the action semantics team. I think that the right response for this is to leave out state machines altogether from this resolution and only deal with the general case of what it means to "start" an owned behavior. Alternatively, I can transfer the issue to the state machines group. Which would you prefer? Cheers, Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sun, 11 Jul 2004 11:18:31 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Bran, Regarding 4932, I'll need to leave more replies to Steve M. His use case seems reasonable: the initialization phase of software that is supposed to reflect the state of the real world. These intialization states can only be determined dynamically and require an action to initialize the objects in that state. The only workaround is cumbersome, using transitions to every possible state, responding to an initialization event. It would be better if the action were introduced in state machines to remove the dependency of actions on state machines (CompositeStructure also modifes actions for its particular purposes). If you think it has alot of interactions with state machine semantics, you could reassign it there, but I'd be concerned that the issue would languish, as it has since the Action Semantics FTF. As to the cleanup of StartOwnedBehaviorAction, I will file a separate issue and respond to that. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 10:15:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > Moreover, this action, I believe, drastically changes state machines > as behavioral descriptions by exposing the state to the client. Up to > this point, clients could not alter the defined behavior other than > by (i) passing parameters upon creation and (ii) causing triggering > events that would fire transitions. The notion of entry points was > explicitly added in UML 2.0 to allow clients to request different > starting states of the state machine, but only, if the behavior > provides for this. The action is for such a narrow case (intialization) that I don't think it conflicts with the constructs above. > In general, actions that leverage other packages, both structural or > behavioral, should be added by the teams managing those packages, > rather than by the action team, to ensure consistency with the > existing capabilities of those packages. For example, in the solution > to 4932 the fact that this capability would be better provided > through leveraging the entry points was missed. But that would apply to all the actions. For example, the link actions defined the semantics of n-aries in UML 1.5, before this was carried over to classes in UML 2. Your approach would be an extremely broad change to implement. > I think there is a broader rule hiding here: In general, the > philosophy should be that no package should add to packages that are > not dependent on it (either directly or via package merge). Some of > the issues filed are due to not adhering to this guide line. (E.g., > stream behavior added in activities to all behaviors.) You defined the rule to explicitly make Common Behavior exempt, which currently imposes semantics on the specialized behaviors that only some of them can support. State machines do not support accessing parameters, yet Commmon Behavior requires them to. A generalization like Behavior should not be placing undue burden on its specializations. Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 09:15:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Every behavior supports parameters, by definition. The actions in the transitions can access the parameters exposed by the state machine as behavior. Don't understand why you think otherwise. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, July 12, 2004 9:16 AM > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19 > > State machines do not support accessing > parameters, yet Commmon Behavior requires them to. A generalization > like Behavior should not be placing undue burden on its > specializations. Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 10:49:12 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > Every behavior supports parameters, by definition. The actions in the > transitions can access the parameters exposed by the state machine as > behavior. Don't understand why you think otherwise. How? There is no standard way for state machine to read or write to a parameter. Can you give an example and the repository model? You response underscores my point: Common Behavior establishes, by definition, capabilities that are not supported in a standard way by some of the specialized behaviors. Common Behavior is imposing unimplementable semantics on these behaviors. Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 09:54:21 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, I think this is quite clear in the specification: 1. Parameter passing is explained in common behavior 2. Parameter access is explained in actions In other words, invoking a behavior makes a set of parameters available to the behavior. The internals of the behavior access the parameters. The mechanism that is defined in the UML is that of variable actions. Thus, a statemachine would use variable actions to access the parameters passed in upon invocation. The mechanism is the same as in activities. I don't understand your question, nor the point you are trying to make below. What is unimplementable? There already exist implementations that do this.... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, July 12, 2004 9:49 AM > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19 > > > Thomas, > > > Every behavior supports parameters, by definition. The actions in the > > transitions can access the parameters exposed by the state machine as > > behavior. Don't understand why you think otherwise. > > How? There is no standard way for state machine to read or write to a > parameter. Can you give an example and the repository model? > > > You response underscores my point: Common Behavior establishes, by > definition, capabilities that are not supported in a standard way by > some of the specialized behaviors. Common Behavior is imposing > unimplementable semantics on these behaviors. > > Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 11:12:10 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > Conrad, > > I think this is quite clear in the specification: > > 1. Parameter passing is explained in common behavior > 2. Parameter access is explained in actions There is no action for accessing parameters. > I don't understand your question, nor the point you are trying to > make below. What is unimplementable? There already exist > implementations that do this.... Not standard ones. How could there be? There is no standard way for state machines to access the parameters they inherit from Behavior. Conrad From: "Mellor, Stephen" To: conrad.bock@nist.gov, uml2ftf X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Mon, 12 Jul 2004 18:45:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Conrad has correctly described the rationale for my concern. Many real systems face this problem and the workaround (transitions to possible states-in-which-one-appears) is cumbersomne to say the least. I am sensitive to the fact that the initializing code would have to know about the target state, but I do not find that to be a killer argument. When it comes down to it, you--the application modeler--are the only one who can know what state you should establish. This especially true for those states you have to infer. (Example: the outlet valves of a tank are open, and the inlet valves closed. What state is the Tank in?) Putting any logic inside the state chart makes any generalization of the initialization difficult. Who does it? I'm agnostic. But it's a real issue. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2004-07-11, Sunday 08:19 > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19, 4932 > > > Thomas, Bran, > > Regarding 4932, I'll need to leave more replies to Steve M. > His use case seems reasonable: the initialization phase of > software that is supposed to reflect the state of the real > world. These intialization states can only be determined > dynamically and require an action to initialize the objects > in that state. The only workaround is cumbersome, using > transitions to every possible state, responding to an > initialization event. > > It would be better if the action were introduced in state > machines to remove the dependency of actions on state > machines (CompositeStructure also modifes actions for its > particular purposes). If you think it has alot of > interactions with state machine semantics, you could reassign > it there, but I'd be concerned that the issue would languish, > as it has since the Action Semantics FTF. > > As to the cleanup of StartOwnedBehaviorAction, I will file a > separate issue and respond to that. > > Conrad > From: "Mellor, Stephen" To: Thomas Weigert , conrad.bock@nist.gov, uml2ftf X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 18:45:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Excuse me. I thought that the "parameters" (i.e the data passed in with an event) was made available to all actions within the activity (nee procedure) directly on the pins. There is no variable action, and if there were, it would break the flow model. --stephen > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 2004-07-12, Monday 07:54 > To: conrad.bock@nist.gov; uml2ftf > Subject: RE: Activity/action resolutions for ballot 19 > > Conrad, > > I think this is quite clear in the specification: > > 1. Parameter passing is explained in common behavior 2. > Parameter access is explained in actions > > In other words, invoking a behavior makes a set of parameters > available to the behavior. The internals of the behavior > access the parameters. The mechanism that is defined in the > UML is that of variable actions. Thus, a statemachine would > use variable actions to access the parameters passed in upon > invocation. > > The mechanism is the same as in activities. > > I don't understand your question, nor the point you are > trying to make below. What is unimplementable? There already > exist implementations that do this.... > > Th. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: Monday, July 12, 2004 9:49 AM > > To: uml2ftf > > Subject: RE: Activity/action resolutions for ballot 19 > > > > > > Thomas, > > > > > Every behavior supports parameters, by definition. The > actions in > > the > transitions can access the parameters exposed by the state > > machine as > behavior. Don't understand why you think otherwise. > > > > How? There is no standard way for state machine to read or > write to a > > parameter. Can you give an example and the repository model? > > > > > > You response underscores my point: Common Behavior establishes, by > > definition, capabilities that are not supported in a > standard way by > > some of the specialized behaviors. Common Behavior is imposing > > unimplementable semantics on these behaviors. > > > > Conrad > From: "Mellor, Stephen" To: conrad.bock@nist.gov, uml2ftf X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Activity/action resolutions for ballot 19 Date: Mon, 12 Jul 2004 18:45:18 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2004-07-12, Monday 08:12 > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19 > > > Thomas, > > > Conrad, > > > > I think this is quite clear in the specification: > > > > 1. Parameter passing is explained in common behavior > 2. > Parameter access is explained in actions > > There is no action for accessing parameters. There is no need. They are available directly on the pins. > > > I don't understand your question, nor the point you are > trying to > make below. What is unimplementable? There > already exist > implementations that do this.... > > Not standard ones. How could there be? There is no standard > way for state machines to access the parameters they inherit > from Behavior. > I *believe* that the 1.5 spec set up data on pins with flows-from-nowhere with "parameters." This should not have changed in 2.0 To: "Mellor, Stephen" Cc: conrad.bock@nist.gov, uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 12 Jul 2004 23:03:25 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/12/2004 23:03:27, Serialize complete at 07/12/2004 23:03:27 Steve, I am a bit confused here: > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer argument. The issue, as I see it, is a different one than you present here. In UML state machines, you don't start off in a state but in an initial pseudostate. Since these are clearly identified by default in a state machine, there is no need to identify them explicitly. However, more generally, my primary conern was that this resolution was being pushed without input from the state machine group, who should, at the very least, be consulted for such an important issue. My view is that it is the responsibility of this group to provide a solution. You, Conrad, and anyone else interested are more than welcome to participate in the resolution. > When > it comes down to it, you--the application modeler--are the only one who can > know what state you should establish. This especially true for those states > you have to infer. (Example: the outlet valves of a tank are open, and the > inlet valves closed. What state is the Tank in?) Putting any logic inside > the state chart makes any generalization of the initialization difficult. Not if you use initial points. Note that you can pass parameter values to the initial transition which can then branch off to the appropriate state. This is the reason why initial transitions (transitions coming out of the initial state can have guards. It's not an issue. Cheers...Bran From: "Thomas Weigert" To: "Mellor, Stephen" , , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Mon, 12 Jul 2004 23:28:08 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Stephen, this requirement would be more consistently met with relying on entry points to the state machine, and having an action that starts up the state machine by entering through an entry point that leads to the desired state. In that manner, the state machine can be designed to facilitate that special initialization, without it being purely imposed from the use. On who is responsible for the state, in your example below, it is the designer of the state machine, not the client of the state machine. Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentorg.com] > Sent: Monday, July 12, 2004 5:45 PM > To: conrad.bock@nist.gov; uml2ftf > Subject: RE: Activity/action resolutions for ballot 19, 4932 > > > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer > argument. When > it comes down to it, you--the application modeler--are the only > one who can > know what state you should establish. This especially true for > those states > you have to infer. (Example: the outlet valves of a tank are > open, and the > inlet valves closed. What state is the Tank in?) Putting any > logic inside > the state chart makes any generalization of the initialization difficult. > > Who does it? I'm agnostic. But it's a real issue. > From: "Mellor, Stephen" To: Branislav Selic Cc: conrad.bock@nist.gov, uml2ftf X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sat, 17 Jul 2004 16:05:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Hi Bran, I'm happy to pursue this is the state machine group, as I said before. In UML, you start off in an initial pseudostate, but this does not address my concern. Indeed it is a good part of my problem. Placing guards on transitions from said initial pseudostate is incredibly messy, and it doesn't work for those us who use entry actions. Moreover, conceptually--even if I were willing to model it that way and distort the style of state machines we use--it is not what we need. Consider a system that is caused to run; it creates objects and they have state. All is cool so far. Now the system dies for whatever reason, and we need to restablish the system in the state it was in status quo ante. Modeling that as you suggest is conceptually not on. Now, if we didn't keep a warm failover copy, what can we do? We can see what's happening in the real world, and put all Valve objects in their state as determined by the real world. When building a conceptual model, as we do, the object "started" in that state. It carried out no actions, it just reappeared after being absent for a time. Reincarnated, if you like. I hope this clarifies the problem. -- stephen -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2004-07-12, Monday 20:03 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Steve, I am a bit confused here: > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer argument. The issue, as I see it, is a different one than you present here. In UML state machines, you don't start off in a state but in an initial pseudostate. Since these are clearly identified by default in a state machine, there is no need to identify them explicitly. However, more generally, my primary conern was that this resolution was being pushed without input from the state machine group, who should, at the very least, be consulted for such an important issue. My view is that it is the responsibility of this group to provide a solution. You, Conrad, and anyone else interested are more than welcome to participate in the resolution. > When > it comes down to it, you--the application modeler--are the only one who can > know what state you should establish. This especially true for those states > you have to infer. (Example: the outlet valves of a tank are open, and the > inlet valves closed. What state is the Tank in?) Putting any logic inside > the state chart makes any generalization of the initialization difficult. Not if you use initial points. Note that you can pass parameter values to the initial transition which can then branch off to the appropriate state. This is the reason why initial transitions (transitions coming out of the initial state can have guards. It's not an issue. Cheers...Bran From: "Thomas Weigert" To: "Mellor, Stephen" , "Branislav Selic" Cc: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sat, 17 Jul 2004 15:21:46 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Stephen, two comments on your modeling problem... 1. If you are modeling a system abstractly, the ability to recover into the previous condition would not be explicitly modeled, but imposed by the implementation. For example, our code generator would generate special code that adds the ability to restart into the previous state of the system. However, for the modeler of the application that is, and should be, totally transparent (this is how our engineers model such applications). 2. If you do want to explicitly model these high-availability features, then you probably should do it with an eye on a real-life implementation. In real life high availability systems, the ability to return to the state has to be carefully programmed into the statemachine. Just assuming that you can start the statemachine in an arbitrary state is wishful thinking. In fact, in most systems, there are only a few states to which you recover (often referred to as "stable states" of a system). For (1) you just need a good code generator. For (2), UML2 added the feature of entry points to a state machine. What you need to support that from actions is the capability of entering a state machine through an entry point. That could easily be added in a profile, or in the UML2. Th. -----Original Message----- From: Mellor, Stephen [mailto:Stephen_Mellor@mentorg.com] Sent: Saturday, July 17, 2004 3:06 PM To: Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Hi Bran, I'm happy to pursue this is the state machine group, as I said before. In UML, you start off in an initial pseudostate, but this does not address my concern. Indeed it is a good part of my problem. Placing guards on transitions from said initial pseudostate is incredibly messy, and it doesn't work for those us who use entry actions. Moreover, conceptually--even if I were willing to model it that way and distort the style of state machines we use--it is not what we need. Consider a system that is caused to run; it creates objects and they have state. All is cool so far. Now the system dies for whatever reason, and we need to restablish the system in the state it was in status quo ante. Modeling that as you suggest is conceptually not on. Now, if we didn't keep a warm failover copy, what can we do? We can see what's happening in the real world, and put all Valve objects in their state as determined by the real world. When building a conceptual model, as we do, the object "started" in that state. It carried out no actions, it just reappeared after being absent for a time. Reincarnated, if you like. I hope this clarifies the problem. -- stephen -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2004-07-12, Monday 20:03 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Steve, I am a bit confused here: > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer argument. The issue, as I see it, is a different one than you present here. In UML state machines, you don't start off in a state but in an initial pseudostate. Since these are clearly identified by default in a state machine, there is no need to identify them explicitly. However, more generally, my primary conern was that this resolution was being pushed without input from the state machine group, who should, at the very least, be consulted for such an important issue. My view is that it is the responsibility of this group to provide a solution. You, Conrad, and anyone else interested are more than welcome to participate in the resolution. > When > it comes down to it, you--the application modeler--are the only one who can > know what state you should establish. This especially true for those states > you have to infer. (Example: the outlet valves of a tank are open, and the > inlet valves closed. What state is the Tank in?) Putting any logic inside > the state chart makes any generalization of the initialization difficult. Not if you use initial points. Note that you can pass parameter values to the initial transition which can then branch off to the appropriate state. This is the reason why initial transitions (transitions coming out of the initial state can have guards. It's not an issue. Cheers...Bran From: "Mellor, Stephen" To: Thomas Weigert , Branislav Selic Cc: conrad.bock@nist.gov, uml2ftf X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sat, 17 Jul 2004 16:24:20 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Please explain an "entry point". Thanks -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 2004-07-17, Saturday 13:22 To: Mellor, Stephen; Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Stephen, two comments on your modeling problem... 1. If you are modeling a system abstractly, the ability to recover into the previous condition would not be explicitly modeled, but imposed by the implementation. For example, our code generator would generate special code that adds the ability to restart into the previous state of the system. However, for the modeler of the application that is, and should be, totally transparent (this is how our engineers model such applications). 2. If you do want to explicitly model these high-availability features, then you probably should do it with an eye on a real-life implementation. In real life high availability systems, the ability to return to the state has to be carefully programmed into the statemachine. Just assuming that you can start the statemachine in an arbitrary state is wishful thinking. In fact, in most systems, there are only a few states to which you recover (often referred to as "stable states" of a system). For (1) you just need a good code generator. For (2), UML2 added the feature of entry points to a state machine. What you need to support that from actions is the capability of entering a state machine through an entry point. That could easily be added in a profile, or in the UML2. Th. -----Original Message----- From: Mellor, Stephen [mailto:Stephen_Mellor@mentorg.com] Sent: Saturday, July 17, 2004 3:06 PM To: Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Hi Bran, I'm happy to pursue this is the state machine group, as I said before. In UML, you start off in an initial pseudostate, but this does not address my concern. Indeed it is a good part of my problem. Placing guards on transitions from said initial pseudostate is incredibly messy, and it doesn't work for those us who use entry actions. Moreover, conceptually--even if I were willing to model it that way and distort the style of state machines we use--it is not what we need. Consider a system that is caused to run; it creates objects and they have state. All is cool so far. Now the system dies for whatever reason, and we need to restablish the system in the state it was in status quo ante. Modeling that as you suggest is conceptually not on. Now, if we didn't keep a warm failover copy, what can we do? We can see what's happening in the real world, and put all Valve objects in their state as determined by the real world. When building a conceptual model, as we do, the object "started" in that state. It carried out no actions, it just reappeared after being absent for a time. Reincarnated, if you like. I hope this clarifies the problem. -- stephen -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2004-07-12, Monday 20:03 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Steve, I am a bit confused here: > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer argument. The issue, as I see it, is a different one than you present here. In UML state machines, you don't start off in a state but in an initial pseudostate. Since these are clearly identified by default in a state machine, there is no need to identify them explicitly. However, more generally, my primary conern was that this resolution was being pushed without input from the state machine group, who should, at the very least, be consulted for such an important issue. My view is that it is the responsibility of this group to provide a solution. You, Conrad, and anyone else interested are more than welcome to participate in the resolution. > When > it comes down to it, you--the application modeler--are the only one who can > know what state you should establish. This especially true for those states > you have to infer. (Example: the outlet valves of a tank are open, and the > inlet valves closed. What state is the Tank in?) Putting any logic inside > the state chart makes any generalization of the initialization difficult. Not if you use initial points. Note that you can pass parameter values to the initial transition which can then branch off to the appropriate state. This is the reason why initial transitions (transitions coming out of the initial state can have guards. It's not an issue. Cheers...Bran From: "Thomas Weigert" To: "Mellor, Stephen" , "Thomas Weigert" , "Branislav Selic" Cc: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sat, 17 Jul 2004 15:35:28 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Please take a look at p.471 of the FAS. Take a look at the pseudo-state entry point. By default, a state machine is entered at its initial state pseudo-state. However, it is possible to define that the state machine is entered elsewhere (the entry point) and begins thus in a different state. For all special situations that you would like your state machine to handle that are different from the default situation, you would define an entry point and model your state machine accordingly to take advantage of that. An entry point can be the target of a transition, but in your example below you would want the "start state machine action" to be able to say that the state machine should be fired up at that entry point, rather than in the initial state. I think this is a good compromise between having no control over the state machine from the outside (the 1.x situation) and having the client interfere with the designed behavior of the state machine (the proposal of allowing arbitrary states to be chosen as the first state). Does this help? Th. -----Original Message----- From: Mellor, Stephen [mailto:Stephen_Mellor@mentorg.com] Sent: Saturday, July 17, 2004 3:24 PM To: Thomas Weigert; Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Please explain an "entry point". Thanks -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 2004-07-17, Saturday 13:22 To: Mellor, Stephen; Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Stephen, two comments on your modeling problem... 1. If you are modeling a system abstractly, the ability to recover into the previous condition would not be explicitly modeled, but imposed by the implementation. For example, our code generator would generate special code that adds the ability to restart into the previous state of the system. However, for the modeler of the application that is, and should be, totally transparent (this is how our engineers model such applications). 2. If you do want to explicitly model these high-availability features, then you probably should do it with an eye on a real-life implementation. In real life high availability systems, the ability to return to the state has to be carefully programmed into the statemachine. Just assuming that you can start the statemachine in an arbitrary state is wishful thinking. In fact, in most systems, there are only a few states to which you recover (often referred to as "stable states" of a system). For (1) you just need a good code generator. For (2), UML2 added the feature of entry points to a state machine. What you need to support that from actions is the capability of entering a state machine through an entry point. That could easily be added in a profile, or in the UML2. Th. -----Original Message----- From: Mellor, Stephen [mailto:Stephen_Mellor@mentorg.com] Sent: Saturday, July 17, 2004 3:06 PM To: Branislav Selic Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Hi Bran, I'm happy to pursue this is the state machine group, as I said before. In UML, you start off in an initial pseudostate, but this does not address my concern. Indeed it is a good part of my problem. Placing guards on transitions from said initial pseudostate is incredibly messy, and it doesn't work for those us who use entry actions. Moreover, conceptually--even if I were willing to model it that way and distort the style of state machines we use--it is not what we need. Consider a system that is caused to run; it creates objects and they have state. All is cool so far. Now the system dies for whatever reason, and we need to restablish the system in the state it was in status quo ante. Modeling that as you suggest is conceptually not on. Now, if we didn't keep a warm failover copy, what can we do? We can see what's happening in the real world, and put all Valve objects in their state as determined by the real world. When building a conceptual model, as we do, the object "started" in that state. It carried out no actions, it just reappeared after being absent for a time. Reincarnated, if you like. I hope this clarifies the problem. -- stephen -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2004-07-12, Monday 20:03 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Steve, I am a bit confused here: > Conrad has correctly described the rationale for my concern. Many real > systems face this problem and the workaround (transitions to possible > states-in-which-one-appears) is cumbersomne to say the least. > > I am sensitive to the fact that the initializing code would have to know > about the target state, but I do not find that to be a killer argument. The issue, as I see it, is a different one than you present here. In UML state machines, you don't start off in a state but in an initial pseudostate. Since these are clearly identified by default in a state machine, there is no need to identify them explicitly. However, more generally, my primary conern was that this resolution was being pushed without input from the state machine group, who should, at the very least, be consulted for such an important issue. My view is that it is the responsibility of this group to provide a solution. You, Conrad, and anyone else interested are more than welcome to participate in the resolution. > When > it comes down to it, you--the application modeler--are the only one who can > know what state you should establish. This especially true for those states > you have to infer. (Example: the outlet valves of a tank are open, and the > inlet valves closed. What state is the Tank in?) Putting any logic inside > the state chart makes any generalization of the initialization difficult. Not if you use initial points. Note that you can pass parameter values to the initial transition which can then branch off to the appropriate state. This is the reason why initial transitions (transitions coming out of the initial state can have guards. It's not an issue. Cheers...Bran To: "Mellor, Stephen" Cc: conrad.bock@nist.gov, uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 18 Jul 2004 01:08:42 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/18/2004 01:08:47, Serialize complete at 07/18/2004 01:08:47 Hi Steve, In reply to your e-mail: > In UML, you start off in an initial pseudostate, but this does not > address my concern. Indeed it is a good part of my problem. > > Placing guards on transitions from said initial pseudostate is > incredibly messy, and it doesn't work for those us who use entry actions. I don't see that entry actions have anything to do with this. You can have any number of initial transitions coming from the initial pseudostate to each separate state. Graphically, they can all be disjoint, or, as I am guessing you might prefer, you can choose not to show them. Each of these transitions would have a guard that is keyed on the state that it terminates on and is driven by the value of the parameter of the state machine. This will give you exactly what you want. As I said, if you are working with a profile (as you obviously are), you can have all of that generated automatically by a tool and nicely hidden so that the "messiness" is not visible to the user. > Moreover, conceptually--even if I were willing to model it that way > and distort the style of state machines we use--it is not what we need. I don't think that you need to distort anything. From what I recall from one of your books, the state machines that you are interested in are a pure subset of UML state machines. You will just have to get constrain a lot of things out. This seems fairly straightforward. > Consider a system that is caused to run; it creates objects and they > have state. All is cool so far. Now the system dies for whatever > reason, and we need to restablish the system in the state it was in > status quo ante. Modeling that as you suggest is conceptually not on. The sceme I outlined above will work as far as I can tell. > Now, if we didn't keep a warm failover copy, what can we do? We can > see what's happening in the real world, and put all Valve objects in > their state as determined by the real world. When building a > conceptual model, as we do, the object "started" in that state. It > carried out no actions, it just reappeared after being absent for a > time. Reincarnated, if you like. > > I hope this clarifies the problem. I really don't think there is a problem. Perhaps we can get together in Montreal and I will explain how this can work. Cheers....Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Sun, 18 Jul 2004 11:52:13 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, > Please take a look at p.471 of the FAS. Take a look at the > pseudo-state entry point. By default, a state machine is entered > at its initial state pseudo-state. However, it is possible to > define that the state machine is entered elsewhere (the entry > point) and begins thus in a different state. As I read it, entry points are can only be used on submachines (or composite states with Bran's recent change). If a classifier is being instantiated, how can an entry point be used to put the classifier state machine in a particular state? Conrad Reply-To: From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Mon, 19 Jul 2004 02:44:30 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-OriginalArrivalTime: 19 Jul 2004 07:44:50.0710 (UTC) FILETIME=[45B89B60:01C46D64] Conrad, an entry point is just a pseudo state, so there is nothing that would prevent the top region of a state machine to have an entry point. I think what leads you to believe that they are limited to submachines/composite states is that you cannot show connection point references on the state machine, as these can only be given on states. But that makes sense, as connection point references are just the targets of transitions that would lead to entry points. In order to leverage entry points on a state machine as behavior we would need an action like the one you proposed, but linked to an entry point pseudostate rather than to a state. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 18, 2004 10:52 AM > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19, 4932 > > > > Hi Thomas, > > > Please take a look at p.471 of the FAS. Take a look at the > > pseudo-state entry point. By default, a state machine is entered > > at its initial state pseudo-state. However, it is possible to > > define that the state machine is entered elsewhere (the entry > > point) and begins thus in a different state. > > As I read it, entry points are can only be used on submachines (or > composite states with Bran's recent change). If a classifier is being > instantiated, how can an entry point be used to put the classifier state > machine in a particular state? > > Conrad > From: "Eran Gery" To: , Cc: "'uml2ftf'" Subject: RE: Activity/action resolutions for ballot 19, 4932 Date: Mon, 19 Jul 2004 11:01:23 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Thomas Your idea can work (an may also be useful) but to be fair it was not a use case that was on the table when the entry/exit points have been introduced into the spec. Currently the spec mostly refers to them as being used in the context of submachines. However, there is no OCL that precludes entry/exit points on the top behavior statemachine (meaning owned by a behaviored classifier) , nevertheless the text doesn't say what is the meaning of that. So bottom line if we add that capability it may require some rewording the spec in addition to the start action extension. Eran -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Monday, July 19, 2004 10:45 AM To: conrad.bock@nist.gov; uml2ftf Subject: RE: Activity/action resolutions for ballot 19, 4932 Conrad, an entry point is just a pseudo state, so there is nothing that would prevent the top region of a state machine to have an entry point. I think what leads you to believe that they are limited to submachines/composite states is that you cannot show connection point references on the state machine, as these can only be given on states. But that makes sense, as connection point references are just the targets of transitions that would lead to entry points. In order to leverage entry points on a state machine as behavior we would need an action like the one you proposed, but linked to an entry point pseudostate rather than to a state. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 18, 2004 10:52 AM > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19, 4932 > > > > Hi Thomas, > > > Please take a look at p.471 of the FAS. Take a look at the > > pseudo-state entry point. By default, a state machine is entered > > at its initial state pseudo-state. However, it is possible to > > define that the state machine is entered elsewhere (the entry > > point) and begins thus in a different state. > > As I read it, entry points are can only be used on submachines (or > composite states with Bran's recent change). If a classifier is being > instantiated, how can an entry point be used to put the classifier state > machine in a particular state? > > Conrad To: Cc: conrad.bock@nist.gov, "uml2ftf" Subject: RE: Activity/action resolutions for ballot 19, 4932 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 20 Jul 2004 20:24:54 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/20/2004 20:24:58, Serialize complete at 07/20/2004 20:24:58 Thomas, The entry-point stuff that you are proposing is not intended to be used the way that you describe. Perhaps it could be adjusted for that purpose, but that was not its intent and would likely require some rework of current semantics (I believe Eran said the same thing). Furthermore, I see absolutely no reason to muddle about with that, since the mechanism that I explained to Steve, will do everything he wants without introducing any new semantics. Cheers, Bran "Thomas Weigert" 07/19/2004 03:44 AM Please respond to thomas.weigert To , "uml2ftf" cc Subject RE: Activity/action resolutions for ballot 19, 4932 Conrad, an entry point is just a pseudo state, so there is nothing that would prevent the top region of a state machine to have an entry point. I think what leads you to believe that they are limited to submachines/composite states is that you cannot show connection point references on the state machine, as these can only be given on states. But that makes sense, as connection point references are just the targets of transitions that would lead to entry points. In order to leverage entry points on a state machine as behavior we would need an action like the one you proposed, but linked to an entry point pseudostate rather than to a state. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 18, 2004 10:52 AM > To: uml2ftf > Subject: RE: Activity/action resolutions for ballot 19, 4932 > > > > Hi Thomas, > > > Please take a look at p.471 of the FAS. Take a look at the > > pseudo-state entry point. By default, a state machine is entered > > at its initial state pseudo-state. However, it is possible to > > define that the state machine is entered elsewhere (the entry > > point) and begins thus in a different state. > > As I read it, entry points are can only be used on submachines (or > composite states with Bran's recent change). If a classifier is being > instantiated, how can an entry point be used to put the classifier state > machine in a particular state? > > Conrad > Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve." -- steve