Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: ClockwiseMango on June 18, 2022, 05:29:57 am
-
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
(https://www.dropbox.com/s/zpj0f8xeumx8b2f/Package1.bmp?dl=0)
can't get the image thingy to work (newbie alert)
https://www.dropbox.com/s/zpj0f8xeumx8b2f/Package1.bmp?dl=0
-
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.
-
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.
-
Consider sending a bug report. Maybe waiting a few days form some wiser guy to know what it means and answering here :-)
q.
-
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.
-
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/
-
Oh Boy now what do we do ???
-
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
-
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.
-
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...
-
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
-
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.
(https://www.dropbox.com/s/zpj0f8xeumx8b2f/Package1.bmp?dl=0)
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
[img]https://i.imgur.com/2PCdxUg.gif[/img]
which results in:
(https://i.imgur.com/2PCdxUg.gif)
-
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.
-
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.
(https://i.imgur.com/rmQiySU.png)
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.
(https://i.imgur.com/wtC9LsG.png)
I hope it's clearer now.
Best Regards,
i
-
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
-
Dear KP,
The getTracedFrom operation definition from the SysML 1.6 spec section 16.3.2.8 might also contribute to clarifying this topic:
getTracedFrom (in ref : NamedElement) : AbstractRequirement [0..*]
The query getTracedFrom() gives all the requirements that are clients ("from" end of the concrete syntax) of a
«Trace» relationship whose supplier is the element in parameter. This is a static query.
bodyCondition:
AbstractRequirement.allInstances()->select(tracedTo->includes(ref))
getTracedFrom(Supplier) returns all the Clients of the trace relationship for a given Supplier.
In the case we're discussing here:
a trace from A to B
in which I hope we've already agreed that A is the client and B the supplier, the query:
getTracedFrom(B)will return A as a result, which means that B is traced from A, and not the other way around.
I sincerely hope this helps.
i
-
So I am now convinced that SysML is wrong. 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.
It also has an operation:
getTracedTo () : NamedElement [0..*]
bodyCondition:
Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
The bold text in the latter contradicts the bold text in the former. So which is correct? You would probably assume that OCL takes precedence over natural language, and the section on the Trace stereotype corroborates this. Moral of the story: never trust the specifications.
-
The bold text in the latter contradicts the bold text in the former. So which is correct? You would probably assume that OCL takes precedence over natural language, and the section on the Trace stereotype corroborates this. Moral of the story: never trust the specifications.
I DID warn everyone... ;)
Avagoodweegend, Neil!
Paolo
-
Dear KP,
From my point of view the SysML 1.6 spec is correct, though the wording they chose might be a bit too convoluted sometimes.
This is how I read and undestand the parts you quote.
Let's go with the 1st one:
/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.
Here we have a trace relationship (kind of a dependency really) that involves a requirement (this requirement) which is a supplier of trace relationships (arrowhead end of the trace relationship in its graphical representation), meaning that there are other requirements whose definition depend on this requirement. Those dependant requirements are the clients, which occupy the "from" end of those trace relationships, that is why the relationships are "derived from" them. Hence, all those clients are "traced to" this supplier.
Now the 2nd one:
getTracedTo () : NamedElement [0..*]
bodyCondition:
Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
OK, here it becomes a bit trickier, because honestly, from the name of the method "getTracedTo" you could really understand it in either of the following ways:
- get elements that trace to the one given as input (clients for a given supplier)
- get elements traced to by the one given as input (suppliers for a given client)
If it was up to me, the natural definition for this method would be the 1st one but, if you go to its "body", it is clearly the 2nd one:
- Trace.allInstances() --- "from all trace relationships..."
- ->select(base_Abstraction.client=self) --- "...get those that have as client this requirement (self)..."
- .base_Abstraction.supplier --- "...and for those, get their supplier."
Furthermore, this definition keeps consistency with the getTracedFrom method described with more detail in the spec and quoted previously by me in a comment in this thread. Here you have it again:
getTracedFrom (in ref : NamedElement) : AbstractRequirement [0..*]
The query getTracedFrom() gives all the requirements that are clients ("from" end of the concrete syntax) of a
«Trace» relationship whose supplier is the element in parameter. This is a static query.
bodyCondition:
AbstractRequirement.allInstances()->select(tracedTo->includes(ref))
Wrapping up, I believe the definition of the trace relationship in the SysML spec is consistent but, as I said, probably put in a too convoluted way.
I hope this helps.
Best Regards,
i.
-
Let's go with the 1st one:
/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.
Here we have a trace relationship (kind of a dependency really) that involves a requirement (this requirement) which is a supplier of trace relationships (arrowhead end of the trace relationship in its graphical representation), meaning that there are other requirements whose definition depend on this requirement. Those dependant requirements are the clients, which occupy the "from" end of those trace relationships, that is why the relationships are "derived from" them. Hence, all those clients are "traced to" this supplier.
Now use the same argument for /refinedBy /satisfiedBy and /verifiedBy