"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
