Zurück zu Willert.de

Event-driven vs "Normal way"

Rhapsody Model or Codegeneration topics

Event-driven vs "Normal way"

Beitragvon fsjunior » Juni 27th, 2013, 2:33 pm


I use Rhapsody and MDD for 1 year to develop the software of the company that I work, but I still have some difficulties with it. I don't have any training and all my knowledge of the tool I acquired with some old slides of Essencials Course, the online manuals and principally only reading the posts of this forum. :lol:

Basically, the greatest difficulty that I have is in find a way to use modeling and the "common way" of C++ programming. I don't know very well how I can explain my question, but, I have a abstract question question about this: if I use the "event-driven" programming paradigm of Rhapsody, I have to abandon some "common paradigm" of C++?

I will try to explain a example.

I made a Class called "UDPSenderSocket". It is a active class, with a statechart with two main states: Disconnected and Connected. In the connected state, there is a substate that go into a infinite loop that receives an evSendData event and calls the send socket function (<sys/socket.h>). The class is active because I don't want that the program "hangs" while doing IO in the send function.

I think that is interesting to see class behaviour with this statechart. But I cannot find a easy and, let's say, a "standardized" way of do some things:

How I can check and respond the sender of evSendData of errors in socket? Lets suppose that occurs some problem with the socket, as events doesn't have any return type and are asynchronous, the only way to do this is to respond the class that send the event with an event evError, or some like this, I'm correct?

So, if I am right, this way is not more error prone and REALLY HARD to do a simple thing that can be made with a simple exception and a return code of the function? There is another (and better) way of modelling and implement the example that I showed? Also, the is some "design patterns" that exists only for event-driven programming paradigm of Rhapsody and can help me to "correct" modeling on it?

Event-driven looks to be a interesting programming "paradigm" (I am correct saying this? :) ), but I think that is, someway, "incomplete". It prevents the use of other tools of the programming language (like exceptions or return values of functions?) and some already standardized way of doing things (like call-and-check-returned-value-for-error).

I am right or I'm simply conceptually wrong?

I thank you in advance. :)

Ps. Sorry for my english. :)
Beiträge: 19
Registriert: März 22nd, 2013, 8:15 pm

Re: Event-driven vs "Normal way"

Beitragvon shanz » Juni 28th, 2013, 10:51 am

2 points immediately spring to mind...

1) Asynchronous (non-blocking) events and synchronous(blocking) primitive operations aren't mutually exclusive.
You will probably want to use both in your program.

2) Events can carry arguments (eg: pointers) which can be used to support callbacks.
Beiträge: 178
Registriert: Mai 7th, 2008, 5:50 pm
Wohnort: Horsham, W Sussex, England

Re: Event-driven vs "Normal way"

Beitragvon fsjunior » Juni 28th, 2013, 4:22 pm

Hi shanz!

I think that your sugestion of using arguments to callback in events a good example of I want to say: I have to use callback to do a simple thing that, in "normal way", can be done with a exception or a simple check of return value of the function. This is more hard to do, to test, to document and is more error prone, IMHO.

Although I actually mix both, this doesnt look "correct" to me. How I choose between one and another? There is a simple rule that I can follow to make this choice? There is a way to make my program "consistent"? Also, chosing by one or another is not the only problem: working with non-blocking and blocking operations in the same time is really hard.

For a example. I cannot send an event to an object and call a blocking function that check the status of the same object in the next statement. I know that this is obvious, that it is the definition of asynchronous communication. But my point is: is hard to isolate "event-driven" from "normal" code if you use one or another. In this case, my solutions are both use an argument to callback in event, like you sugest to me, or make the "calling" class reactive to handle with events.
Beiträge: 19
Registriert: März 22nd, 2013, 8:15 pm

Zurück zu Modelling with Rhapsody

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste