[EMAIL PROTECTED] wrote: > As I understand the reference book on Activity States, there is no > limit on how long an activity state may be active. It usually but not > always terminates on completion of the activity. An Action state > is atomic, but an Activity state is not. I find it hard to reconcile this > with your assertion that Activities can only have control for one tick. > But as I say, I might be getting hold of the wrong end of the stick. >
IMO, most of this trouble comes from the fact that the UML is baroque (it suffers from an excess of gratuitous adornment). Most of the remainder of this trouble comes from the fact that Rose is incompatible. At the risk of going on forever, and never, never stopping: I have been using (silly me) the Rose term, "activity," for what the UML Spec calls an "action state." My bible on the UML is the OMG Spec, Version 1.4. (Search reveals no "activity state" there.) The distinction that interests me is between, in biblical terms, "action state" and "state." See, below, the corresponding sections from "3. UML Notion Guide." The spec could be clearer, but I think that it is pretty clear that an action state has no means of delaying completion of its action when an event arrives -- there will be a transition as quickly as the action state can execute its logic. Thus, the action state can only hold control for one tick. QED. The OMG Spec does include a "subactivity state," which is an action state with an embedded activity graph. It doesn't bear on the distinction that I was trying to make. [Les had the right idea about all this. I'm going to lie down for a while, now.] -Eric ______________________________________ OMG Unified Modeling Language Specification Version 1.4 September 2001 3.75 State 3.75.1 Semantics A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. A composite state is a state that, in contrast to a simple state, has a graphical decomposition. (Composite states and their notation are described in more detail in Section 3.76, �Composite States,� on page 3-141.) Conceptually, an object remains in a state for an interval of time. However, the semantics allow for modeling �flow-through� states that are instantaneous, as well as transitions that are not instantaneous. ~~~~~~ 3.85 Action State 3.85.1 Semantics An action state is a shorthand for a state with an entry action and at least one outgoing transition involving the implicit event of completing the entry action (there may be several such transitions if they have guard conditions). Action states should not have internal transitions, outgoing transitions based on explicit events, or exit actions, use normal states for this situation. [sic] Transitions leaving an action state should not include an event signature. Such transitions are implicitly triggered by the completion of the action in the state. The transitions may include guard conditions and actions. The normal use of an action state is to model a step in the execution of an algorithm (a procedure) or a workflow process. ______________________________________ [EMAIL PROTECTED] wrote: > > (responding to Eric) > > >> (Paul) > >> First point agreed. Second point (though not relevant) is that the > >> 'Activity' is something that goes on until the state machine makes > >> a transition out of the state, so the state machine holds the state > >> for more than one tick. I might be getting the wrong end of the stick > >> here, but I don't think the point is relevant. > > > > (Eric) > > You are not paraphrasing me correctly (could be my fault). Activities > > can only have control for one tick. States can have control for a > > series of ticks. I think that is the crucial difference between > > activities and states. > > As I understand the reference book on Activity States, there is no > limit on how long an activity state may be active. It usually but not > always terminates on completion of the activity. An Action state > is atomic, but an Activity state is not. I find it hard to reconcile this > with your assertion that Activities can only have control for one tick. > But as I say, I might be getting hold of the wrong end of the stick. > > > For me, the unfamiliar thing in this is parallelism. The notion of > > state is hard for me to square with parallel threads of control. In my > > bones, I expect one state per state diagram, unless you embed a > > diagram. A state shouldn't make a transition *and* retain control into > > the next tick, because that means that there is more than one state of > > the FSM waiting for events (which at least *feels* wrong). > > I'm familiar with parallelism, the Petri Net notation covered it well IMHO. > OTOH I agree with you that "A state shouldn't make a transition > *and* retain control into the next tick". Petri Net notation did allow > this but it had to be explicit - the outgoing transition that consumed > the token needed to send a token back to the Place concerned > (where Place is roughly equivalent to State). Example - a Clock > could be represented by a Place and a timed Transition. The > Transition would have an input link and an output link to the place, > so when it fired it would consume a token from the Place, but > immediately replace it. To be useful, there would also be another > output link from the transition to another Place, supplying tokens > that represent ticks of the Clock. > > > Obviously, parallelism is legal in activity diagrams, or there would be > > no synchronization bars, but I'm tempted to stick to old habits, and > > model each potential thread of control as a separate FSM. What do I > > lose by this? > > To do this on a single diagram, you would AFAICS need to > 'manufacture' an artificial state to hold the nested multiple > parallel state chains. Apart from the layout problems, it will > get cumbersome to represent cases where one of the > forked activity chains joins with a chain from a different fork > ( e.g. Fig 9-4 UML Distilled p.137, if you have it handy ). > > Incidentally the UML reference manual strongly hints that > only one outgoing transition from an Activity State will fire; > "If more than one guard condition evaluates to true, the choice > is undefined. It may be nondeterministic, or a rule may be imposed > as a semantic variation point". > > Paul Oldfield ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
