1

I like to document my signal slot connections (e.g. the connections in a special situation) with UML. I'm using the Enterprise Architect, and when having more than 5 Signals and/or Slots per class, it's getting very confusing. I tried the Flow Diagram and the Component Diagram:

Flow Diagrams: I modeled my classes as Processes and used the Ports for my signals/slots.

Component Diagrams: I used the Components for my classes and the Interfaces for my signal slots.

Do you have any experience with modeling signal/slots and what would you suggest? Are there any solutions which fit better for signal/slots?

Charly

Christophe
  • 68,716
  • 7
  • 72
  • 138
Charly
  • 1,270
  • 19
  • 42

2 Answers2

1

I've always used the Sequence Diagram because I've found the 'lifelines' system of showing a transfer of flow between objects a natural fit to the signal/slots pattern. A quote from the wikipedia article linked to above:

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

Seems to agree with this viewpoint, and it's pretty easy to read.

As for the order in which slots are called, the Qt documentation clarifies this:

If several slots are connected to one signal, the slots will be executed one after the other, in the order they have been connected, when the signal is emitted.

Timing is a relative term, and can be used to designate whatever you want it to: just so long as you're consistent and clear about what you're communicating, nobody will mind.

Liam M
  • 5,306
  • 4
  • 39
  • 55
  • But a Sequence Diagram contains much more information, than just the signal/slots. E.g. I don't know the timing and sequence of the signal slots. And if I have 5 objects, where each communicates with the others - the sequence diagram gets rapidly very huge! – Charly Jan 11 '12 at 16:53
  • @Charly I've amended my answer, rather than write a reply down here :). – Liam M Jan 12 '12 at 03:24
0

In a simple class diagram you would document the relation between classes (or interfaces) and signals:

  • A signal is represented with a classifier symbol bearing the keyword «signal». It may have parameters that are represented with attributes that correspond to the content of the message.
  • A signal is usually sent by an operation. This is represented with a «send» dependency from the relevant operation to the signal
  • A class can indicate that it can process a given signal with a reception, i.e. like an operation but preceded by «signal» and named exactly as the signal, with its attribute appearing in its parameter list. Receptions may be visually separated in a separate compartment. This corresponds to the Qt slots

In an activity diagram (it's better than a "flow diagram" from an UML perspective, since flow diagrams are not UML and not standardized), you could specify the dynamics of the signals:

  • a send object node that corresponds to a signal that is emmitted in a flow of activity.
  • an accept event node that corresponds to signal that may be received and the subsequent actions when it happens.
  • You can link the two with a dependency, but you do not have to (especially if there are many signals send / accepted between many objects.

Finally, the advantage with this kind of modeling, is that you can use the signals as events in a state diagram, and express rather complicated things in a very simple, implementation independent abstract way.

Christophe
  • 68,716
  • 7
  • 72
  • 138