"Thanks for your answer Vincent, I would like to continue our discussion
if you agree. Maybe the mailing list is not the rignt place for that, in
this case, maybe, we can continue on private mail."
Yes it is. Answering on this public mailing list allow people who are
asking themselves the same questions to find the answers. The only
better place I could find is the UML forum, since these are more
UML-related aspects than TOPCASED-editors related. But since I don't
read them often, you have more chances I answer you here...
"is in paragraph 14.3.20 and not in 14.3.18"
I always refer to the latest version. In this one, paragraph "14.3.18
Message (from BasicInteractions)" contains lot of information and
"14.3.20 MessageKind (from BasicInteractions)" very few. But I guess
that does not make a big difference on the content...
"I suppose that in this paragraph an operation call is an operation
invocation or an callOperationAction or a callAction."
There is no UML Action linked to the message. A lifeline 'represents' an
instancied object, which itself is typed (often by a Class). Note that
TOPCASED editor allow you to select directly a UML Class for the
'represents' relation, but automatically creates the Property object
typed by this Class.
Hence, when in the Message's signature, you choose an Operation
(available in the target Lifeline's type), this acts like a
CallOperationAction (with a Message sort 'synchronous call' or
'asynchronous call'):
- the target element on which the action is called is the instancied
object represented on the target Lifeline,
- the Operation specified by the Message is called
- the arguments of the Operation are taken from the message.
"It is said to that if the message is a callAction, there will be
'normally' a reply message. So if I understood correctly, if i use a
synchronous message for a method call, normaly there should be a reply
message. This is not the case with topcased. I wonder what is the
anormal situation witthout a reply message ...."
With the previous explanation, if you consider each of your Lifeline
represents, for example, a Java object, the rest will become obvious...
As an example, I'll take a Model Object "M" and the linked viewer "V"
which handles the way it is printed to the end user (a model tree root,
and the eclipse TreeViewer printing it in an Eclipse treeview).
When M is modified, it asks V to refresh the display. (Call message from
Lifeline L_M, representing M, to Lifeline L_V, representing V)
The refresh method may have arguments, taken from the Message.
Depending on your needs, you can call it synchronously, or
asynchronously, since the refresh occurs in a different thread and does
not impact your model.
If you choose to call it synchronously, you may expect a return value,
which would be a boolean telling whether display has been correctly
refreshed. But the method may also simply return void, or you can simply
not take the result in account ; in such cases return value is not
necessary, nor the reply Message.
TOPCASED editors do not create the reply Message automatically, but
nothing prevents you from drawing it explicitly when you need this result.
"and there is a specific notation for return value and out paramter
which is used for reply message only, section exemple just before
14.3.21 and it seems that arguments and return value are optionnal."
Now, you should understand why.
Best regards,
Vincent.
Le 29/10/2011 23:20, Topcased user list where issues are discussed a
écrit :
Hy,
Thanks for your answer Vincent, I would like to continue our
discussion if you agree. Maybe the mailing list is not the rignt place
for that, in this case, maybe, we can continue on private mail.
Ok for message ordering, even if i do not understand why uml did a
such choice.
Reading the uml specification, I would say :
note : In my document "superstructure UML V 2.3 of may 2010", the
sentence "Return-value and attribute .." is in paragraph 14.3.20 and
not in 14.3.18
I suppose that in this paragraph an operation call is an operation
invocation or an callOperationAction or a callAction.
All these terms are used in section 14.3.20.
I said that because it is said that a message is an operation call or
a sending and reception message. All terms operation call, operation
invocation, callOpration, callAction are not linked to signal
management, then they should reflect a method call ...
This method call may be synchounous ou asynchronous, that another point.
It is said to that if the message is a callAction, there will be
'normally' a reply message. So if I understood correctly, if i use a
synchronous message for a method call, normaly there should be a reply
message. This is not the case with topcased. I wonder what is the
anormal situation witthout a reply message ....
and there is a specific notation for return value and out paramter
which is used for reply message only, section exemple just before
14.3.21 and it seems that arguments and return value are optionnal.
Did I understant correctly ?
Sincerly,
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumône
01 30 37 27 84
[email protected] <mailto:[email protected]>
----- Original Message -----
*From:* Topcased user list where issues are discussed
<mailto:[email protected]>
*To:* [email protected]
<mailto:[email protected]>
*Sent:* Thursday, October 27, 2011 9:11 AM
*Subject:* Re: [Topcased-users] How is the order of a sequence
diagram\'s call messages preserved in sysml?
"Maybe you know another point : returned value."
I think the paragraph 14.3.18 should help you a little on that.
From what I understand (does not mean I assure it is the truth)
from this sentence :
"Return-value and attribute assignment are [...], then arguments
may freely be omitted. Omitted
parameters get an unknown argument-value."
You should fill the "signature" with an Operation or Signal and
the "argument" relationship with all values matching the
parameters. The match should be done according to their order.
Hence, I suppose the return value should match with the last
argument of the Message.
"The point you explained about sequence diagram (id interaction
diagram) "disturbs" me since a long time : when you write code the
order of calls is an important matter, you cannot write method
calls randomly, so why UML does not take this in account ? Another
UML mystery maybe..."
Order makes sense only for a Lifeline, since there is no general
object which sequences the calls...
Best regards,
Vincent.
Le 26/10/2011 14:43, Topcased user list where issues are discussed
a écrit :
Thanks Vincent for your precise answer.
Maybe you know another point : returned value.
I thought that returned values were designed by reply messages
but topcased does not manage return value with reply message.
I thought that in the specification, it was explained that if the
message is a synchronized call then the reply message is the
returned value but maybe I misunderstand the specification ( that
would not be the first time ...)
The point you explained about sequence diagram (id interaction
diagram) "disturbs" me since a long time : when you write code
the order of calls is an important matter, you cannot write
method calls randomly, so why UML does not take this in account ?
Another UML mystery maybe...
Cordialement,
Bernard Granier
CE Plateforme Système
[email protected] <mailto:[email protected]>
01 58 11 32 51
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*Topcased user list where issues are discussed
*Sent:* Wednesday, October 26, 2011 1:52 PM
*To:* [email protected]
*Subject:* Re: [Topcased-users] How is the order of a sequence
diagram\'s call messages preserved in sysml?
Hello,
According to the UML specification, a Sequence Diagram does not
specifies the complete message order.
Order of fragments is fully specified only along a single
Lifeline, hence, when two events on two different lifelines are
not connected, you can not know which occurs first :
For example, if two messages cross each other on 2 Lifelines like
this :
[L1] [L2]
| |
| X |
| |
You only know that One message is sent from a lifeline before the
other is received (for both Lifelines).
You have no clue which one is sent first and which one is
received first, whatever the vertical locations are.
As said in the specification, a Sequence Diagram does not define
a single trace, but a set of valid traces.
This is the main reason why implementing an efficient and elegant
Sequence Diagram modeler is so hard.
Yet, you can find some interesting information in the order of
"fragments" in an Interaction or in an Interaction Operand.
Indeed, this order must be the one of a valid trace (though I can
not find back where it is written in the spec).
Hence, following the fragments order should give you one of the
possible orders.
See "14.3.17 Lifeline" in UML Superstructure specification, at
the Semantics part.
See "14.3.11 Interaction" in UML Superstructure specification for
more information on traces
(http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/)
Of course, what I describe is the global philosophy or
Interaction diagrams. But there are still some local
modifications to this philosophy, like with GeneralOrdering
elements or in a "strict" Combined Fragment...
Best regards,
Vincent.
Le 24/10/2011 20:57, Topcased user list where issues are
discussed a écrit :
Looking at general ordering, it seems that the order of only two
message ends (event occurrences) are preserved.
I will need a way to reflect the order of all of the messages.
The general ordering idea inspired me to look at combined
fragments. The "seq" and "strict" combined fragments specify
order visually. I wondered if the XMI code would record the
messages and message order for the fragment. I created a seq,
and then a strict, fragment that surrounded the messages of a
sequence diagram. This plan didn't work though. The XMI for the
combined fragment showed the lifelines covered by the fragment,
but not the messages.
If anyone has any ideas on how UML/SysML specifies message order
in XMI, I would appreciate it. Thanks Bernard for helping me out.
--
Ebonie Williams
Master IT
UNC Charlotte Graduate
_______________________________________________
Topcased-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont pas
destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les
reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Si ce message vous
a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement
de votre système informatique ce courriel ainsi que tous les documents qui y sont
attachés."
******
" This e-mail and any attached documents may contain confidential or proprietary
information. If you are not the intended recipient, you are notified that any
dissemination, copying of this e-mail and any attachments thereto or use of their
contents by any means whatsoever is strictly prohibited. If you have received this e-mail
in error, please advise the sender immediately and delete this e-mail and all attached
documents from your computer system."
#
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
------------------------------------------------------------------------
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
