SysML trace relation ship in V16 - Am I being special

[ClockwiseMango]

Is the SysML trace relationship the wrong way around in the SysML MDG
The quick link seems to wok as expected  - arrow at the source of the info thats driving the requirement

The SysMl trace appears to be back to front in the trace window



can't get the image thingy to work (newbie alert)
https://www.dropbox.com/s/zpj0f8xeumx8b2f/Package1.bmp?dl=0

[qwerty]

I'm no expert either, but it might well be that the trace from/to is interpreted differently. Like in Karate you have styles where the uchi/soto uke (inside/outside block) are interpreted as either from or towards. I'd guess you need to look into OMG's SysML specs to find that out.

q.

[ClockwiseMango]

I'm no expert either, but it might well be that the trace from/to is interpreted differently. Like in Karate you have styles where the uchi/soto uke (inside/outside block) are interpreted as either from or towards. I'd guess you need to look into OMG's SysML specs to find that out.

q.

That's the point when I look at the SysML spec, Delligatti or Friedenthal its head of the arrow at the "supplier" (parent) and tail at the "Client" (child). But thats not what the words are saying in the traceability window for a SysML trace.

[qwerty]

Consider sending a bug report. Maybe waiting a few days form some wiser guy to know what it means and answering here :-)

q.

[KP]

Yeah, EA gets it wrong. A trace relationship from A to B means that B is "traced to" A and A is "traced from" B.

[ClockwiseMango]

Another one for the bucket

Hello Ian,

Thank you for the enquiry.

Our developers have confirmed that this is a bug and it is logged to be fixed. We cannot yet say when (in which build) the fix will be implemented.
The issue id is : 22052061

If you have further questions or issues please let us know.

Best regards,

Anil Onattu
Sparx Systems Pty Ltd
[email protected]
http://www.sparxsystems.com

Join the community: http://community.sparxsystems.com
Subscribe to our newsletter: http://www.sparxsystems.com/press/newsletter/

[ClockwiseMango]

Oh Boy now what do we do 

[Paolo F Cantoni]

Oh Boy now what do we do 

n this type of situation, we rewrite our custom shapescript to draw the incorrect relationship in the correct way, but we don't extend other MDGs (usually) so it's easier for us.
An alternative might be to reverse the direction in the repository (via SQL).  Then when the fix arrives (if ever), you can revert.

Sorry if that's not much help.

Paolo

[qwerty]

You could as well resort to the "standard" trace relation. Can be altered with a script too once the fix is there (which might take a while).

q.

[KP]

Oh Boy now what do we do 

n this type of situation, we rewrite our custom shapescript to draw the incorrect relationship in the correct way, but we don't extend other MDGs (usually) so it's easier for us.
An alternative might be to reverse the direction in the repository (via SQL).  Then when the fix arrives (if ever), you can revert.

Sorry if that's not much help.

Paolo

No, the relationship isn't incorrect, the words in the Trace window and on the quicklinker menu are wrong. The OP doesn't need to do anything to his model except carry on modeling...

[Paolo F Cantoni]

No, the relationship isn't incorrect, the words in the Trace window and on the QuickLinker menu are wrong. The OP doesn't need to do anything to his model except to carry on modelling...

Thanks for clarifying, KP.  I was a little confused since the "standard" Trace relationship is fine.


Paolo

[i]

Yeah, EA gets it wrong. A trace relationship from A to B means that B is "traced to" A and A is "traced from" B.

"A trace relationship from A to B" means literally that:

• A traces to B
• B is traced from A

which is just the opposite to what you captured in your comment quoted above.

can't get the image thingy to work (newbie alert)

You may try uploading the image to imgur (or similar) instead, and copy the image url like this

Code: [Select]

[img]https://i.imgur.com/2PCdxUg.gif[/img]
which results in:

[KP]

Yeah, EA gets it wrong. A trace relationship from A to B means that B is "traced to" A and A is "traced from" B.

"A trace relationship from A to B" means literally that:

• A traces to B
• B is traced from A

which is just the opposite to what you captured in your comment quoted above.

No, I'm right. See SysML 1.6 (formal-19-11-01) section 16.3.2.1

AbstractRequirement has a derived attribute:

/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.

[i]

No, I'm right. See SysML 1.6 (formal-19-11-01) section 16.3.2.1

AbstractRequirement has a derived attribute:

/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.

Well... you aren't.

In "A traces to B", the client is A and the supplier is B. Do we agree on that?
(B is the supplier because a modification in B might impact A...)

The arrow in the graphical representation of the relationship of course points from the client to the supplier.



Then Sparx EA calls the client "Source" and the supplier "Target" and "Destination", which is really unfortunate because anyone could erroneously identify "source" and "supplier" as synonyms, when in this case I'm afraid they are not.



I hope it's clearer now.

Best Regards,
i

[Paolo F Cantoni]

Then Sparx EA calls the client "Source" and the supplier "Target" and "Destination", which is really unfortunate because anyone could erroneously identify "source" and "supplier" as synonyms when in this case I'm afraid they are not.

I wrote on this problem (of term inconsistency) over a decade ago.  I try to ALWAYS used "origin" and "destination" to remove ambiguity.
You should also note that some of the standards we use have got the relationship naming incorrect.  Normally, the client is the origin and the supplier the destination.  However, UML incorrectly names a specialization relationship "Generalization".  This was rectified in ArchiMate (notionally based on UML), where the (same) relationship is named "Specialization".

HTH,
Paolo