Author Topic: Creating diagram-specific relationships  (Read 4294 times)

Ron Beernink

  • EA User
  • **
  • Posts: 24
  • Karma: +1/-0
    • View Profile
Creating diagram-specific relationships
« on: November 14, 2014, 10:15:51 am »
I would like to recommend that Sparx allows users to create a relationships between elements that are saved as part of that diagram, but not persisted / recorded against the elements that are used in that diagram.

At times I want to model different scenarios using some application elements but showing the different ways they may be able to interact or be realized.  Particularly as these are hypothetical scenarios, I don't want to persist these relationships in our central model repository.

It would be much easier if I would be able to change a setting for a specific diagram to tell it not to update the elements to persist any relationships lines that I draw.  

Yes, this makes Sparx a bit like Visio.  But better that than to be forced to use Visio itself, or Powerpoint!  

Jayson

  • EA User
  • **
  • Posts: 363
  • Karma: +1/-0
    • View Profile
Re: Creating diagram-specific relationships
« Reply #1 on: November 14, 2014, 10:31:30 am »
Hey Ron

As an interim solution, you might want to belt out a simple script that traverses the project structure and removes links of this type from any diagram not of the type that you specify.

Although not automatic, it would offer a similar outcome.

Jays  :)

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: Creating diagram-specific relationships
« Reply #2 on: November 14, 2014, 11:12:58 am »
The OP's wish does not make sense. A diagram is not a model. To mark connectors as temporary apply a stereotype or add a tagged value.

q.
« Last Edit: November 14, 2014, 11:13:26 am by qwerty »

Ron Beernink

  • EA User
  • **
  • Posts: 24
  • Karma: +1/-0
    • View Profile
Re: Creating diagram-specific relationships
« Reply #3 on: November 14, 2014, 01:19:12 pm »
Quote
The OP's wish does not make sense. A diagram is not a model. To mark connectors as temporary apply a stereotype or add a tagged value.

q.
Keen to hear what approach does makes practical sense.  Applying a stereotype or tagged value may work, but is not practical.  

It may help if I try to better explain the actual issue that I've got.  I am creating 3 different diagrams to show what different software procurement approaches you can use to realize a common set of application components (e.g. single vendor/monolithic system, single vendor/best of breed product suite, multi-vendor, best of breed components).  It is purely hypothetical, so don't want the application components in our central model to be loaded with all the resulting relationships.  Hope that explanation does help..  :)

Ron Beernink

  • EA User
  • **
  • Posts: 24
  • Karma: +1/-0
    • View Profile
Re: Creating diagram-specific relationships
« Reply #4 on: November 14, 2014, 01:23:39 pm »
Quote
Hey Ron

As an interim solution, you might want to belt out a simple script that traverses the project structure and removes links of this type from any diagram not of the type that you specify.

Although not automatic, it would offer a similar outcome.

Jays  :)
Not a bad suggestion, except that you are left with diagrams with missing links/relationships.  Even if the project/piece of work may have finished, there's always a chance to someone will look at it at a later stage and go "what the..?"

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8061
  • Karma: +118/-20
    • View Profile
Re: Creating diagram-specific relationships
« Reply #5 on: November 14, 2014, 01:44:44 pm »
Sounds like a perfect situation to use instances.

I would also consider creating a communication diagram for it, which has the advantage that communication messages already only show on one diagram. (But they do require an association to attach to)

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: Creating diagram-specific relationships
« Reply #6 on: November 14, 2014, 08:49:36 pm »
I'd also favor Simon's suggestion in your case. The instances show the concrete cases while the abstracted classes bundle what the ideal approach behind it it would be.

q.