Book a Demo

Author Topic: Message (Signal kind) should be from source  (Read 3400 times)

Paul Lotz

  • EA User
  • **
  • Posts: 248
  • Karma: +1/-0
    • View Profile
Message (Signal kind) should be from source
« on: May 08, 2008, 08:41:48 am »
I just sent this to EA support, but I'd be interested to hear from the forum as well:

Issue:
I am creating an interaction diagram to model the behavior of a system that sends signals with a publish-subscribe methodology.

When I create a message between two lifelines, the Message Properties dialog allows me to select from existing operations from the target lifeline.  (This is in principle quite important since it allows me to maintain consistency between the operations/signals in the interaction diagram and the operations/signals in the class model.)  This makes sense if the message kind is Call, but not (I contend) if the message kind is Signal (especially a published/broadcast signal), in which case the Signal should be an operation of the source lifeline.

I explored and found that I could create a signal in the source class and drag and drop the new signal onto the interaction diagram (at least with some limitations--as a self-call first).  (Interestingly the message properties have the defaults Synchronous and Call, which of course are not what I want.)  The dropped message then shows the message name and parameters associated with the source lifeline.  If I drag the message end to a different target lifeline, however, I once again can only choose from messages associated with the target lifeline.  I maintain that this is wrong in principle for signals.

How to reproduce:
Open an interaction diagram.  Add two lifelines with add a signal to each lifeline.  Draw a message line between the two lifelines.  In the Message Properties dialog change Kind to Signal and Synch to Asynchronous, then click on Operations.  The available operations are only those owned by the target lifeline.

Paul

Paul Lotz

  • EA User
  • **
  • Posts: 248
  • Karma: +1/-0
    • View Profile
Re: Message (Signal kind) should be from source
« Reply #1 on: May 15, 2008, 04:12:43 am »
Update:
It seems that in UML even signal messages should be associated with the target.  I have decided for the moment to follow this paradigm without considering a communication methodology.  This does simplify the creation of interfaces on one level.  There is still a serious drawback in that if I change the signal signature I have to change it in the interface definition of every recipient of that signal, which is not ideal.  I'm sure there has to be a better way.  For the moment I will work with what I have.  :-)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Message (Signal kind) should be from source
« Reply #2 on: June 24, 2008, 06:41:21 pm »
Quote
Update:
It seems that in UML even signal messages should be associated with the target.
Hi Paul,

Do you have a reference for this?

TIA,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paul Lotz

  • EA User
  • **
  • Posts: 248
  • Karma: +1/-0
    • View Profile
Re: Message (Signal kind) should be from source
« Reply #3 on: June 25, 2008, 02:19:54 am »
[/quote]Hi Paul,

Do you have a reference for this?

TIA,
Paolo
[/quote]

Well, the support folks referred me to this (from section 13.3.23 in the UML 2.1.2 Superstructure Specification): "A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. The details of handling a signal are specified by the behavior associated with the reception or the classifier itself."

[It's also probably worth pointing out the signals I have defined this way (as operations on a message line with a "signal" stereotype) EA considers receptions and these don't have the same definition as those signals defined using a Signal element.]

I'm still not sure what the best solution is but I have been using asynchronous messages with the signal stereotype associated with the receiver for my model and this has worked reasonably well up to this point.  I bet there is a better way, though.

Paul
« Last Edit: June 25, 2008, 02:20:57 am by pauljlotz »