1

Object B contains a bunch of public events.

Object A subscribes to these events.

What is the UML relationship between these?

Currently I have a directed association from Object A to Object B. Is that correct? Or should the direction go the other way?

rygo6
  • 1,929
  • 22
  • 30
  • Welcome to StackOverflow, @rygo6. If you found an answer to your question, please consider [accepting it](http://meta.stackexchange.com/q/5234/179419) (by clicking the check-mark), and consider up-voting it (by clicking the up arrow). Accepting an answer indicates to the wider community that you've found a solution, gives yourself some reputation points, and gives some reputation points to the person who answered your question. If you did not find a satisfactory answer to your question, please leave a comment. – Jim L. May 13 '16 at 02:32

3 Answers3

0

Both A and B probably maintain references to one another. A may want to unsubscribe, and B certainly has to be able to notify A of events. Thus, I would model it as a bidirectional relationship. You might even want B to compose all the subscribing instances. Check out the well known Observer Pattern.

Jim L.
  • 6,177
  • 3
  • 21
  • 47
0

It depends on what you want to express.

Logically, the subscriber A must know the publisher B, and the other way round, so you have a bidirectional relationship.

Technically, often the subscriptions are not managed by the publisher B but by some dispatcher D. The subscriber A knows the dispatcher D and the other way round. But the publisher B doesn't know A and, depending on the platform offering the broadcasting mechanism, maybe not even the dispatcher D. So, if you have a particular platform in mind, find out which types of objects need instance variables to reference other objects, and model the relationships according to that.

TAM
  • 1,731
  • 13
  • 18
0

There should be a dependency relationship from A to B (a dashed arrow pointing from A to B). Chapter 7.8.4.1 of the UML spec version 2.5 reads:

A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation.

In your case, A requires B to exist, but B does not require A to exist. Maybe B requires A to implement a particular interface. In that case, B depends on the interface, but not on A itself.

You propose to have an association from A to B. An association is stronger than a dependency. It means that A has a property of type B (well, the definition is a bit more complex, see chapter 11.5.3.1 of the UML spec). This implies that A depends on B, like a dependency, but a dependency does not require A to have a property of type B.

To summarize:

  • The arrow should point from A to B, not from B to A (unless your particular implementation of B depends on the existence of a class called A, which is unlikely).
  • A dependency is enough, but if you want A to have a property of type B, then you may draw an association (solid line) instead of a dependency (dashed line).
www.admiraalit.nl
  • 5,768
  • 1
  • 17
  • 32