Author Topic: Sequence diagrams  (Read 531 times)

AECA

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Sequence diagrams
« on: September 14, 2013, 02:50:53 am »
Good afternoon,

in Enterprise Architect I'm creating a UML Sequence diagram and I have the following problem:
- Process A sends a message to B
- Process A waits for the reply message, but this comes from a different process C (different swimline in the diagram)

Enterprise Architect creates a new activation for A, but it should actually continue. Options 'Extend Source Activation Up' or 'Extend Source Activation Down' don't help, process is still split.

Can anyone help me on how to model this?

Gusztav

  • EA User
  • **
  • Posts: 32
  • Karma: +0/-0
  • EA expert
    • View Profile
    • Imprestige. Your issues in safe hands.
Re: Sequence diagrams
« Reply #1 on: October 02, 2013, 03:13:18 am »
Have you tried to set the messages to be async on the message props pane?
------------------------
Imprestige. Your issues in safe hands.

AECA

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Sequence diagrams
« Reply #2 on: October 03, 2013, 03:06:35 am »
Thanks GusT, I tried that already but no luck.
I guess this is a Enterprise Architect software bug, because I have redrawn the diagram again from scratch and now it's shown correctly.

Markro

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Sequence diagrams
« Reply #3 on: December 23, 2013, 10:07:59 pm »
So how do you get this to work as I always get ongoing activation bars interupted by the new event from another object.

I am never sure if this is correct or wrong as I am a bit of a novice with SDs and the underlying meaning/interpretation behind such things and so conveying to the wrong meaning.


Kevin G. Watson

  • EA User
  • **
  • Posts: 217
  • Karma: +0/-0
  • I love EVERYTHING including Microsoft
    • View Profile
Re: Sequence diagrams
« Reply #4 on: December 27, 2013, 06:00:55 pm »
Hi there

I'm seriously confused, in UML you have two types of messages:

Synchroncious ( like you might call an operation, execution stops in the caller context and continues in the called context... If in the called context another call is made, execution similarly stops and continues in the called.  As each inner operation completes it returns to the caller ). Uses a solid filled arrow head.  The convention that of a return message, denoted with a dashed line, is so engrained that it can be assumed to flow from the end of called focus of control (ie you don't have draw them).

Asynchroncious ( like sending a signal or calling an operation that imeadiately returns... The message is sent, and execution in the caller continues.  No assumption that the called operation executes, completes or returns can be made.  This type of message is shown with an open arrow.

An asynchronous message does not have a reply / return flow.

If you send an asynchronous message from A to B, and then wait at A for a message from C.... surely you would show this 'wait' as stacked focus of control;  the foc which sends msg to B, would create a sub foc ( much like a call to op on itself ( perhaps a call to wait ) and when C is complete you would send another asynchronous message to the sub foc.  You could use the dashed line to make the return / reply clear I s'pose.

If your using the Synchroncious type then what your asking to do is just plain wrong.

And while you might wait for a return / reply message, handling that message is always separate from waiting for it.

Anyhows happy new year, I might have been tippling too much of the Christmas sherry ::)

Regards
Kevin [smiley=2vrolijk_08.gif]