Author Topic: Modeling shared sequences in Communication Diagram?  (Read 811 times)

Bill Egge

  • EA User
  • **
  • Posts: 93
  • Karma: +0/-0
    • View Profile
Modeling shared sequences in Communication Diagram?
« on: July 03, 2016, 02:57:29 am »
How can I model this communication sequence without duplicating flows.

I have a WINDOW, APPLICATION, and MANAGER.

1)
When the APPLICATION shuts down then it calls WINDOW.Destroy. (This is out of my hands)
When the WINDOW is destroyed, it calls MANAGER.RemoveWindow

2)
When a WINDOW is closed by user (Window is not destroyed), the WINDOW sends a message to MANAGER.DeactivateWindow.
When MANAGER.DeactivateWindow sees that all windows are closed then it calls WINDOW.Destroy.

Thus the problem, APPLICATION.Shutdown and MANAGER.DeactivateWindow both call WINDOW.Destroy but WINDOW Destroy only has one message to MANAGER.RemoveWindow.

I need to see all possible paths that can destroy a window.  Do I have to create 2 identical messages going from WINDOW.Destroy to MANAGER.RemoveWindow, or is there a way that WINDOW.Destroy can simply display all sequences automatically?

This problem exists in any software system, such as change notifications.  In general, multiple in but 1 out.  I still want to see all the possible paths but I don't want to have go and duplicate everything when one more sequence is added.  It is unmanageable.

« Last Edit: July 03, 2016, 02:59:14 am by Bill Egge »

qwerty

  • EA Guru
  • *****
  • Posts: 9022
  • Karma: +137/-126
  • I'm no guru at all
    • View Profile
Re: Modeling shared sequences in Communication Diagram?
« Reply #1 on: July 03, 2016, 07:59:40 pm »
Well, think ;-) If an object receives a message, it will do something. And thus not be able to receive another message the same time (not talking about parallelizing here!). So either message will be the first and the other the second. Now, depending on your implementation, you can react differently. Have a grace period to accept more messages. Die and let the OS raise an exception, Whatever...

q.