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]
----- Original Message -----
From: Topcased user list where issues are discussed
To: [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]
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
[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
