SysML trace relation ship in V16 - Am I being special

[i]

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:

Code: [Select]

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

[KP]

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.

[Paolo F Cantoni]

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

[i]

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.

[KP]

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