Yes that's right:

UML = Rhapsody

Signal Event = Event

Call Event = Triggered operation

Time Event = timeout (although indicated with tm() rather than after())

Change event = change event (implemented via flow ports or proxy ports, generating a chXXX event when relevant data changes value)

I found the answer in the Rhapsody modeler documentation. Although Rhapsody uses the same term for Reception as in the UML spec, a UML Signal is an Event in Rhapsody (here it is straight out of the Rhapsody help):

"A reception specifies the ability of a class to react to a certain event (called a signal in the UML). The name of the reception is the same as the name of the event; therefore, you cannot change the name of a reception directly. Receptions are displayed under the Operations category for the class."

The event (signal) is being managed automatically by Rhapsody because it's created as soon as you create a Reception. In other tools such as EA Architect you have to create this separately and keep them consistent as well.

Thanks for the clarification, it definitely helps. I have one follow-up question which applies more to UML as Rhapsody implements it than the SE model. Rhapsody uses Events as constructs for Event passing. Is this the same as the term Signal in plain UML? In the UML spec you have the following types:

Signal

Time

Call

Change

The Harmony handbook uses Rhapsody terms but not everyone uses Rhapsody when applying the method to SE modeling.

Regards

First, the SE model is largely logical in nature, rather than physical. So the logical interface is usually defined with logical flows - these may be events, operation calls (note: both events and operations can carry parameters as desired), or actually flows - data, energy, fluid, or materiel. Since the interfaces are logical, we want to describe only their logical properties and ignore the pesky implementation details. The easiest way for define the logical service invocations are with events - even if they end up later being realized in the physical interfaces as bus messages or operation calls. In that way, a host of issues around synchronization can be completely ignored because asynchronous events are automatically serialized into a FIFO order.

Note that it is STILL important to define the system function(s) (modeled as operations) invoked by the reception of the event because those system functions must implement requirements. Hence, the common practice is to have the interaction between the system and actors done via event passing and the actual behavior of the system (system function or operation call) is invoked upon receipt of the event.

I hope that helps.

- b