FYI
about the sequence
diagram editor.
Dr.
Sébastien Gérard
Head
of MDD for DRES
research project
CEA LIST,
Laboratoire d’Ingénierie
dirigée par les modèles pour les Systèmes Embarqués (LISE)
Boîte
courrier 94, GIF SUR YVETTE
CEDEX,
F-91191 France
Phone/fax
: +33 1 69 08 58
24 / 83 95
Leader
of the Eclipse Component
Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org
http://www.eclipse.org/modeling/mdt/?project=papyrus
Before
printing, think
about the environment
Could you guys shed some
light in this area?
Every tool vendor has
different ideas (and
implementation) what event types should be used at message ends for
call
message, reply message, create message or destroy message.
Thanks,
--
Nerijus Jankevicius
SysML Product Manager
OMG-Certified UML Professional
No Magic Europe
Savanoriu pr. 363, LT 49425 Kaunas, Lithuania
P.O. box 2166, LT- 3000, Kaunas
Phone: +370-37-324032 Fax: +370-37-320670
e-mail: nerijus@xxxxxxxxxxxxx
WWW: http://www.magicdraw.com
--
MagicDraw - Architecture made simple!
----- Original Message
-----
Sent: Tuesday, March 09,
2010 11:49 AM
Hi Everybody,
I would like
to start a discussion concerning message
events, and my interpretation of this situation.
The first
case to study should be the cOperation1 and
its reply message denoted by this picture:
cOperation1 is
a message with a event (1)
sent,
and event(2) receipted.
Then there
is a ExecutionSpecification with start
Occurrence (3) and a
finish
Occurrence (4).
Finally
cOperation1, the reply message with an event (5) sent and an event (6) receipted.
First some
definitions from UML2.2 spec:
SendOperationEvent:
-
Description:
A
SendOperationEvent models the invocation of an
operation call.
- Semantic:
A send
operation event specifies the sending of a
request to invoke a specific operation on an object. The send operation
event may
result in the occurrence of a call event in
the receiver object (…).
ReceiveOperationEvent:
-Description:
This
specifies the event of receiving an operation
invocation for a particular operation by the target entity.
-Semantic:
A receive
operation event occurs when an operation
invocation is received by the target object.
CallEvent:
-Description:
A call event
represents the reception of a request to
invoke a specific operation.(…)
-Semantic:
A call event
represents the reception of a request to
invoke a specific operation on an object.(…) A call event
makes available any argument values
carried by the received call request to all behaviors caused by this
Event(…).
ExecutionEvent:
-Description:
An
ExecutionEvent models the start or finish of an
execution occurrence.
-Semantics:
An execution
event represents the start or finish of
the execution of an action or a behavior.
My
understanding:
At (1)
bb:B requests for the invocation of cOperation1, so SendOperationEvent seems the
best element.
At (2) cc:C
receipts this request, here the best definition is the one of CallEvent.
Concerning (3)
and (4) I have some
doubts:
In the
UML2.2 specification:
An ExecutionSpecification
is a specification of the execution of a unit of behavior or action
within the
Lifeline. The
duration of an
ExecutionSpecification is represented by two
ExecutionOccurrenceSpecifications,
the start
ExecutionOccurrenceSpecification
and the finish ExecutionOccurrenceSpecification.
è It
means that ExecutionSpecification.start and
ExecutionSpecification.finish
should be ExecutionOccurrenceSpecification.
So why it is
just typed to OccurenceSpecification?
In the other
way the semantic says:
Typically the
start occurrence and the finish occurrence will represent
OccurrenceSpecifications such as a
receive
OccurrenceSpecification (of a Message) and the send
OccurrenceSpecification (of
a reply Message).
è Here it
seems that it should be the MessageOccurrenceSpecification.
My
understanding for (3)
and (4)
The
ExecutionSpecification starts/finishes with a
ExecutionOccurenceSpecifications which represent the receive/send
MessageOccurenceSpecification of cOperation1/itsReply
That would
mean the ExecutionOccurrenceSpecification
will share the same event that the MessageOccurrenceSpecification. But
in fact
no : the Event of an ExecutionOccurrenceSpecification is restricted to
ExecutionEvent:
è No
direct relationship between (2)
and (3), and between (4) and (5)
è (3) is an
ExecutionOccurenceSpecification
with event=ExecutionEvent
è (4) is an
ExecutionOccurenceSpecification
with event=ExecutionEvent
At (5) the
invocation is done. Which event to set to (5)?
My choice will be the ExecutionEvent of (4) saying
that the execution is finished. But in fact, this point does seem clear
for me.
At (6) bb:B
should receive the result of the invocation. Here is really not clear
too, so I
made an own interpretation of the “ReceiveOperationEvent” which
would mean “the reception of the (resulting) operation invocation.
è By this
way I resolve the (6) issue,
but I
possibly misunderstand the definition…
Any comments?
It does not
resolve other questions about how to
manage CreationEvent and DestructionEvent.
Thanks,
Mickael
