| [mdt-papyrus.dev] TR: MessageEvents |
|
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 De : Nerijus
Jankevicius [mailto:nerijus@xxxxxxxxxxx] 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. See email below. Thanks, ----- Original Message ----- From: Mickaël Albert Sent: Tuesday, March 09,
2010 11:49 AM Subject: MessageEvents 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 |
