Hi all,

I need some advice about how to drive the object oriented design of classes with event-driven approach. Please let me talk about a specific design problem to point out clearly what my question is and how I am confused.

Think of 3 classes: CommandCenter, MonitoringService, Monitor.

CommandCenter asynchronously sends commands to MonitoringService. So, it is natural to make the communication between these two services based on event passing. MonitoringService, upon receiving the command, for example, evEnableMonitors(vector<int> monitorsToBeEnabledList), should enable those monitor objects and report to the command sender that command has been successfully completed or not, for each monitor object. Monitor objects, seem to have 2 basic states, st_enabled and st_disabled, with evEnable and evDisable events capable to change states accordingly. There exists some specific monitor classes, generalized from the Monitor class, so its statechart is simply inherited.

MonitoringService, sends evEnable for each monitor, specified in evEnableMonitors parameter list. This will mean that it will request from that specific Monitor object to perform the enabling operation asynchronously, that is to say, whenever the active context in which Monitor object runs handles this event. The active context of each Monitor object may or may not be the same of MonitoringService, depending on the design and needs of that specific monitoring activity ( some parameters should be specifically monitored, so one may choose to make a specific monitor class, for example, TemperatureMonitor, to have its own context). Any monitor object, getting evEnable, uses this event to see if a transition occurs or not. So the statemachine design of Monitor class seems to be nice, clearly expressing the states and transitions.

MonitoringService, needs the result of each enable operation, to be able to prepare a report and send back to the command sender. This means that if Monitoring Service sends the enable request via evEnable, it should get the result later, probably via another event ( evEnableResult) sent by Monitor.
In such a case, MonitoringService should wait and handle all incoming reply events and prepare the report only after all replies from all Monitor objects has been received. This complicates the design in MonitoringService ( it should know that it is in a waiting state, keep how many monitor objects are waited to send the reply, etc.)

However, if MonitoringService requests the enable operation in synchronous way, that is using simple method call ( pMonitor -> enable() ) and checks the return value accordingly, the design is kept simple. This, on the other hand, thinks me that states in the Monitor class ( st_enabled, st_disable ) to be useless now and a single enumarated attribute mStatus is sufficient.( Assuming triggered operations are not utilized due to their limitations and some drawbacks) This time, guarded attributes and operations may come into the scene since the approach of processing events in an order is now broken.

Briefly, at the beginning of design, I set two states for Monitor objects, decided to send enable/disable operations asynchronoulsy, but later I found it may be better to remove them since synchronous way of communication keeps the overall design simple.

So, I wonder if some explicit rules may be set about when event-based asynchronous communication should be preffered over synchronous way.

Is it true to say that, events should be used whenever the sender object is not immediately interested in the outcome of processing of that event ?

Thanks in advance.

Farquad, any comment ?

Been on holiday so only just read your post. I'll need to draw what you're describing before I can comment. I'm not very good at reading and picturing. That's why I like UML

Just an additional clarification about the post..

When designing based on event-driven paradigm, should we design objects so that all interactions be via events ? If not, does using synchronous method calls mean breaking the rules of event-driven programming ? Why guarded operations are there if events should be the only way of communicating ?

Systems are a mixture of event passing and direct calls.

There may be 2 mechanisms but there are more reasons to communicate.

1. Ask question and get answer now (blocking)
2. Ask question then receive answer later (non-blocking)
3. Provide Information that may change state and perhaps data (non-blocking)
4. Provide Information that will only change data (blocking)

2 and 3 are supported with events and 1 and 4 via normal method calls. The normal method calls may inspect the state of the object, i.e. read-only, to achieve their function.

The reason you might do 2 rather than 1 is that you want to ensure that, at the time of asking, all information that has gone before has been processed by the object. The question therefore needs to be queued.

There are times when data needs to be guarded but the state behaviour of an object is non-reentrant and therefore can only be affected by one thread at a time. Sticking to events ensures that only the object's owning thread affects the statechart. Mixing in triggered ops allows other threads to access the state chart but not in a guarded way. They will simply be ignored, rather than set to pending, if they attempt to access a busy state chart, it's not like guarded in that respect.

I don't think there are 'rules of event-driven programming' that apply all the time.

One more great answer. Thanks.

I'm fully with Farquad. Only one little thing that can be added here.

It is not widely known, but possible, to guard triggered operations via the property CG:Operation:Concurrency, so that they access the state chart in a guarded way. Under that condition the triggered operation calls will not be ignored, but pend while an asynchronous event or while another triggered operation call from yet another thread context to that state chart is handled.
Nevertheless, I would not recommend mixing asynchronous and synchronous triggers to access the same statemachine if possible. The required use of guards can have negative impact on realtime behavior and increases the risk to inadvertendly create locks.

-Luke