Actor Framework Discussions
Help on AF design
Solved!
Hi all,
I am currently creating a very very tiny application, where I wish to try out the AF. This a good exersise for me to get try and understand it better. I have the last weekends been reading a lot, trying out stuff and now lets try to make this reality.
The application has the following setup:
1 - it shall monitor an amplifier. This amplifier may at random intervalls spit out an message. This application shall only register this message (like in a log), but shall not respond in any way back to the device.
2 - On user interaction, the application sends a message to this device, depending on what button the user has pressed, a different message is sent. The device responds to this message either ACK or NACK.
3 - The communication shall be RS232. Ive also given myself the criteria that it may support TCP/IP.
Now regarding the design I have sofar thought the following:
Hardware communication classes:
- TCP/IP - Holds all functions for TCP/IP communication (basically a wrapper around the LV TCP functions)
- RS232 - Holds all functions for serial RS232 communication (basically a wrapper around the LV Serial functions)
These two use dynamic displatch so its caller either can use TCP IP or RS232 depending what class its caller wants to use.
I have given myself the possibility that the amplifier may consist of more than one model. I will have a top level "amplifier actor". This actors responsibility is to always read its communication ports for incoming messages, and sending a message when the user wishes to send out an message to the amplifier.
Since we may have several types of amplifiers, that might use a different protocoll, or other, each "amplifier type" will be a class that inherits from the "amplifier actor". This class would hold the protocoll information when reading or writing to the amplifier, and the configuration if it uses the TCP/IP class or RS232 class (or other) for communication
Since the "amplifier actor" always shall monitor the communication, it will inherit from an anchestor metronome class that stands for the polling and trigger a regular read at the "amplifier actor"
The "amplifier actor" would get a read message from the metronome at a regular interval. However it may also recieve a write message from a GUI actor (havent really come that far in the design, but there shall be a GUI actor). As of my understanding, since this messages go into the same AF message queue, they will be performed in sequence, unless one of them gets a higher priority and is pushed forwards in its queue (unsure if it will clear the Queue, or just push the message forward) (I havent looked into how the AF is built up).
Some questions have arised:
My RS232 and TCP/IP can inherit from only one class. Now, lets say I get another class in the system that also uses TCP/IP. The TCP/IP class can not inherit from this "new class" due to it already inherits from another (the "amplifier type" class). That would mess up my dynamic dispatching? 
I dont have a good drawing tool atm, besides powerpoint, so cant draw the flowchart/actor design I thought of, but is this solution a good solution from your point of view or is it really messed up, or is written such it is impossible to understand? Am I thinking OK or am I going down the wrong path in the thinking process? 
Also, before I always monitored the actions a QSM would do in a system log. It has simply been a "must"- each QSM must hold a queue reference to this logger. this is for backtracking and debugging, also for virtual launched QSM's. Is there any way to implemenent such a "system log" class in a good manner so that it would not mess up the re-usability of my actors and functions? (like a queue reference it always must have - if the queue is invalid, it is ignored (indicates that either the system logger is not implemented, or not simply not running)? I am not fond of using a reference to a GUI element to a textbox or similar all over the place)
Update:
Ladies and gent's - I now know how the AF works and how to design it, and have "gotten" it. 
It somehow helped posting on this forum, and your own answers came after posting it, the bricks fell in place.
How to however delete this discussion, I dont know.
Sure Lossless Larry, but not before it is re-written (any other would be embarrising 
). The software is created during self-learning, and was not exactly very planned. (How can you plan a software design when you dont know the design you wish to use?). Kind of planned when I went underway and got on with it, but also got lazy changing stuff you otherwise would have changed when finding out of new stuff.
The thing what I learned when doing this, is that I simply got disturbed by all the dynamic displatching, and OOP in the AF examples. When having dynamic displatching and OOP more under control, one would see how the AF works when trying it yourself. Begin from the bottom and work yourself up. Basically the AF itself could have been written as well without using OOP I guess.
If I should explain it with one sentence I would phrase out: "It's all about the messages". 
I will re-write the application from the beginning, for training purposes, due to planning is very important (if not the most important part) when I have time for that (usually the weekends), and then I can post the result from the re-write.
By the way - does anyone know a good UML sequence editor, that is fast and easy to use?!?! (and if it is free/open source even better?)
