On the road again….
Last week I was on tour in Germany by car. Not by myself but together with Andreas. That makes traveling a lot more fun, alone is OK but with someone to talk to (or to listen to Jazz on my Burmester…) is a lot cooler.
S-class Burmester speaker
First evening stage was from home to Bückeburg. Sunday evening is perfect for driving, it is quiet on the road and trucks are only allowed on the street after 22:00u. Then the next morning early to Stuttgart but via Karlsruhe. We had a visit to a partner company, show them our AUTOSAR solution. then to Stuttgart for the hotel.
Next two days was at an automotive customer to help them using Rhapsody to create the architecture for some very cool stuff. Sorry,…can’t tell you any more… sometimes stuff must be kept secret….
During that 2 days I came across an old friend, the Publisher-Subscriber Design Pattern and I decided to write something about it.
Design Pattern
Publisher Subscriber is a design pattern. A design pattern is not just a library function, it is a standard way to solve a problem, you can not give standard code for it but you can give example code that you must adapt to implement in your own realm. (Not always, due to clever inheritance it is possible to give some standard stuff for OO languages.)
What is PS (Publisher – Subscriber) ? It is just what it says. Somebody publishes something and somebody else can subscribe to it.
Suppose you have a button in your system and you want an event when the button is pressed. Easy, just do a CGEN (me->receiver, evOfInterest() )….
If it only were that easy… Of course this is not a solution, you probably want to re-use the button in other applications. If you have solved it like this, you have to change the button each time you want to re-use it. Better is to let the button be unaware of anything from the application and:
Reverse the Relation
Yes. The application should have a relation with the hardware and not the other way around. The hardware should have a “subscribe()” function that allows an interested user to be notified when the event of interest comes by.
*^@#$&*( “C”…
Yes… the old “C” fan starts to see the advantages of “C++”… “C” definitely has its uses but design patterns just work so much easier when you have encapsulation, inheritance templates and overloading.
A very cool example of ‘C’…
The publisher subscriber pattern works as follows, you have a publisher that “publishes” a certain service, let’s say a button can be pressed, you can “subscribe” to that press. This is done by a subscribe function where a function pointer and (We’re using Rhapsody in”C”!) a “me”-pointer are passed. The function stores them in attributes and can call the function via the pointer. Sounds easy but there are some caveats. You have to know the signature of the function to “type” the attribute and the subscribe functions’ arguments. This is a bit awkward since you can not “just” take any function, your compiler will protest. Also the “me”-pointer has to be of type “void *”, you can never predict which object it will be. Depending on the compiler you need some casts… not really elegant.PublSubsc
Elegant C++
Compare that to “C++” where you just create a Publisher Class that has a relation with a subscriber class. The publisher Class has the “subscribe” function that has a pointer to the class as argument. This will be stored in the “Subscriber”, that has an abstract Notify function that needs to be implemented in the inheriting class (Since it is abstract) 
You can use the subscriber type as a template and you have a ready made function that works for most cases. You only have to adapt the subscriber function but you can even make multiple functions with different parameters, the compiler will help you.
To make life easier I have put this in a Rhapsody 8.2.1 model, download here: PublSubsc.
As always: If you need an older Version: please respond.
That was it for today! Happy modeling with Rhapsody!
Walter van der Heiden (wvdheiden@willert.de)
