RHAPSODY4YOU

I can just about remember learning about mealy and moore state machines at University.
In Rhapsody you can do actions on transitions and/or do entry/exit or reactions-in-state.

What rules do people on this forum use?
I thought it might be nice to favour actions on transitions because they are more visible on the diagram.
Alternatively you could minimise (or completely ban?) actions on transitions and favour actions on entry/exit/in-state.

Is there a problem with missing events if you have an action on a transition which is a lengthy operation and consequently the statechart is 'between states' when an event is received? I suspect Farquad could answer this question pretty easily!

If I understand what you are asking the answer is that you would not miss an event. The events are processed when in a state and queued up while you are in a transition. You could ofcourse overflow the event queue if the transition takes too long.

Personally I tend to use entry if there are several transitions into a state that all want the same entry. Otherwise I tend to put the code in an operation and call that on the transition. Just gives me a better overview of what is going on.

There is also the case where you have multiple transitions into a state that want to run different code. Can't, afaik, use entry then.

David Harel's UML statecharts are where it's at. Rhapsody is top of the UML tools because of its support for behavioural modelling. The event driven framework in the OXF is a work of art. Those that doubt its credentials are missing out on the next stage of software and system engineering. Just as many thought that assembler was the end game 25 years ago I guess.

You will never miss an event. As Nizztos says, there is only one way into the code generated for a statechart and it is non-reentrant. A reactive object's active context ensures run-to-completion before returning to handle the next event. Of course an active context may, and usually does, service many reactive objects. If you have no active objects then the only active context is the main thread and it will start servicing events after construction and starting behaviour.

On the subject of actions taking too long, this is bad. If you have an 'activity' to perform then drop into a waiting state and pass the activity to an active object which then passes back a completion event. Often these workers are created dynamically and have a bi-directional relationship to their manager. Also they are often specified as a class within the manager because of their dependency on the manager. Alternatively, if they can justify their independence, they tend to communicate back via an interface rather than a bi-directional association.

Great. Thanks for the replies - just what I was looking for.
We had come to the same conclusions really.

How about Triggered Operations?
These are event-like in that they can trigger transitions but are synchronous and not queued.

So are all Triggered Operations just ignored unless we are idling in a state?

Who uses triggered ops and when and why?

Thanks.

I can't see a reason to use triggered ops. Using them inflicts a different mechanistic design ethos that is questionable. I think they're just in there to satisfy someone who didn't understand, and perhaps feared, the event driven framework. Often I come across scaremongering over events. Some say using events will cause context switching, extra threads to be created etc. If you come across this, often the person saying it has limited experience. The OXF is merely an implementation of a concept common in virtually all successful software companies I have worked in since 1986.

If you want determinism then events with a single thread is as deterministic as, and better than, triggered ops. The ultimate for determinism is the IDF (interrupt driven framework) but it still respects the concept of a run-to-completion event.

As you say the non-reentrant nature of statechart processing means that triggered ops can be lost.

Just don't use them...

One possible use case for triggered operation are synchronous service calls to lower layers in layered applications, where a statemachine can/will be used to perform a state based access control to (private) primitive operations via its (public) triggered operations.

Instead of having a logical check at the entry point of each single service operation in the lower layer (e.g. is it allowed to call that operation right now, or not?), such service operations could be made private (not accessible from outside) and corresponding triggered operations would then delegate the external (triggered operation) calls to the internal operations, if (and only if) it is allowed in the current state.

Many services do have such a state based behavior. Explicitly capturing the behavior and filtering the access to services is a much more visible and better understandable way of implementation vs. a "distributed state machine", where the state based access control code is literally distributed among many operations.

Secondly, triggered operations are typically used in top down service calls within layered applications, while asynchronous calls (decoupling realtime dependencies from driver level to apllication level) are typically done in bottom up answers.

It is not common, to mix asynchronous event receptions with synchronous triggered operations within the same statemachine.

Communication between objects on the same layer within an application is typicall done asynchronously based on event receptions.

-Luke.

Should all interactions between objects be based on event receptions really ? Then why does "guarded" property exist for both attributes and operations ?

Could you please explain when one needs to/should use those guarded things ?

No, not all interaction between objects in general. Only interactions where you have a kind of a request & asynchronous answer (when done) interaction will use state based behavior and events.

Guards are typically used when it must be possible, to modify the same set of non-atomic data from different threads, and where the likelyhood of a collission is rather low (e.g. modifying setup data of a system). If the likelyhood of collisions is rather big (e.g. database access), then a transaction controller, which queues incoming requests may be the better approach.

Typical use cases for guarded access could be:
* writing to a queue from different threads (so yes, the transition controllers input queue will implicitly use a guard),
* protecting a resource like a memory pool while elements get added and removed,
* protecting access to a non-shareable device,
* protecting complex data sets in order to be able to update them in a consistent way.

Depending on the use case, guards for data access can either just protect against parallel writing, or they can also protect reading against writing and vice versa.

Guards are not needed at all, if all readers and writers to a shared element execute on the same thread.

-Luke.