Book a Demo

Author Topic: Fragments in sequence diagrams  (Read 3784 times)

Jayson

  • EA User
  • **
  • Posts: 363
  • Karma: +1/-0
    • View Profile
Fragments in sequence diagrams
« on: February 10, 2020, 04:13:50 am »
Hey all

I am getting ready to throw my laptop across the room trying to get Sparx to behave remotely rationally when it comes to fragments.
Here is what I am trying to do:

1. Create a sequence diagram with multiple entry points (diagram gates) depending on what type of product is being fulfilled.
2. Use the OPT fragment in order to indicate that some of the processing is specific only to some product types.

So far, so good.
However, where my laptop comes close to being turned into a shot put is in the implementation of this.

When I add the fragment, there seems to be no logic to which messages are part of that fragment and which are not.
When I try to drag down the separator between the two options, the stupid message lifelines grow so that I can NEVER get them contained ONLY in that option.

Help please, if for only my laptop's sake!

Cheers :-)

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Fragments in sequence diagrams
« Reply #1 on: February 10, 2020, 09:12:22 am »
Any hint on your EA version?

q.

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
Re: Fragments in sequence diagrams
« Reply #2 on: February 10, 2020, 02:38:32 pm »
"1. Create a sequence diagram with multiple entry points (diagram gates) depending on what type of product is being fulfilled."

I would advise you to NOT use gates to describe the interaction logic. 
I would create a separate sequence diagram for each scenario (the sequence diagram would be the child of a separate use case describing the scenario, preferably using <<include>> and <<generalization>> to make the use case and sequence diagrams both as simple as possible.

If you have to use complex logic in the sequence diagram, it may be sign of a poor functional model.  Also, combined fragments are the best way to show interaction logic (like you are doing with OPT; also consider REF; but use sparingly!  Again, a complicated interaction can be an indication that the model is poorly constructed - often use case refactoring can help!!)