Modeling publish subscribe signals in UML

[Paul Lotz]

What is the best way to model signals between components when the signals are sent using a publish-subscribe model (so that there can be more than one subscriber to given signal)?

The method I am using is to have a provided interface on the publishing component, a realized interface on the subscribing component, and a signal with associations to the interfaces.  This works but I'm not sure it's entirely correct and since the signals aren't part of the interface implementing the interface in the next step will be require a bit more work.  This may be the best solution, though.

An alternative is to create a single interface for the publisher with all its signals and then have inheriting interfaces or realizing classes use certain signals.  This means that the signals belong as well to the new structure so changes made in one location do not show up in the others.  Is there a better way?

[Geert Bellekens]

Can you elaborate a bit more on how you model this "signal"?
Is that a class with associations to the interfaces? In that case that looks a bit weird, and wrong in view of depencendies. (It seems to me that the interfaces are dependend on the signals and not the other way around). I would only use the signals as parameters on the operations of the interfaces. (If I'm correct in my interpretation of you "signal")

[Paul Lotz]

Geert,

Yes, I am modeling signals as using the signal metamodel.  The signals exist only in the publishing system.  I drag a linked version of the signal onto a class diagram and then draw association lines to the provided and required interfaces of the proper components.  (OK, I got this idea from the DDS add-in, where topics are associated with ports, not interfaces.)  I suspect this is not really correct in my case in terms of interfaces, but I'm not sure how to do this correctly with interfaces.  In particular, I want to make sure that one signal can be shared, perhaps between multiple interfaces?!?!, so that if I edit the signal in one place it will update properly everywhere....  I can create an interface and add operations with the <<signal>> stereotype--which is a more compact representation as well--but again I don't know how this will allow for proper sharing of each signal, since each signal belongs to that specific interface.  I searched on-line for a useful example of modeling publish-subscribe signal interfaces with UML but I haven't find anything helpful yet.

Paul

[Geert Bellekens]

No, sorry not really getting it.   A picture would surely help.
Anyways from what I see you are trying to implement one of the classical GoF patterns: Observer.
Check http://en.wikipedia.org/wiki/Observer_pattern
and http://www.dofactory.com/Patterns/PatternObserver.aspx for more information. (the abstract class observer can ofcourse be changed into an interface that is provided by you publication component and required by the user components)

[Paul Lotz]

OK, here is a picture of what I am doing:
.
(The signals themselves are defined on a separate diagram, just like the Topics in the DDS model.  The advantage to this is that they exist in only one place, so any changes I make will take effect everywhere.)

Here is a picture of the alternative method I was describing:
.
This approach has several advantages but a major disadvantage in that each signal exists in more than one place in the project.  Any changes I make in the Subsystem1 interface will not propagate to the inheriting interfaces (or classes, if I choose that option).

Paul

[Paul Lotz]

http://en.wikipedia.org/wiki/Observer_pattern[/url]
and http://www.dofactory.com/Patterns/PatternObserver.aspx for more information. (the abstract class observer can ofcourse be changed into an interface that is provided by you publication component and required by the user components)

Yes, the GoF Observer pattern is the model here, and I have seen these pages already, but they have to do with how a listener subscribes to a message, which is not actually the point of what I am trying to model in the present instance.  I want to detail which messages go to which subsystems.  The only real reason the Observer pattern is  important here is that there can be more than one listener for each signal.  I don't know how to represent that relationship effectively in UML.

[Paul Lotz]

OK, here is a modified approach that I think is at least legal and sensible (there are associations between the interfaces and the signals, and between the provided and realized interfaces, and the signals exist only in one place), even if it isn't any more useful (if I realize the interface I have to determine which signals to use manually).


I'd love to hear there is a better way.

Paul

[jeshaw2]

Have you given any thought to Statemachine Diagrams?
The publishing of a signal would be an event causing state changes across many diagrams.  Just a thought...

[Paul Lotz]

Yes, certainly!  I will do state machine diagrams when the time comes.  That does not negate the need to model interfaces in class diagrams, however.  Thanks!