SYSML12 — use of derived in Requirements

16.3.2.3:

(2) /derived: Requirement [0..1]
Derived from all requirements that are the client of a «deriveReqt»
relationship for which this requirement is a supplier.

I don't think we can write OCL to derive this value, at least not
without knowledge of the population of Requirements in which this
instance is situated. How would we navigate from this object, a
Requirement, to that population? I note that the version of the
profile XMI I am using doesn't declare this property as derived. It
appears that at least one SysML tool provider didn't derive it, but
maintains it in their tool and XMI.

I think something like the above criticism can be leveled against all
of the
attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master
that are declared derived in the spec 08-05-16. Perhaps we ought to
remove the '/' and use a word other than "derived" in describing
these attributes.

Likewise 16.3.2.4 RequirementRelated attributes should not be declared
derived.

It may be the case that the OMG needs to be clearer regarding what it
means by "derived." There are attributes whose definition can be
expressed in OCL and there are attributes whose value can only be
found by some (perhaps vaguely specified) analysis of the Model (if
Model is the correct context!). The latter notion is, I think, what
you intend throughout Clause 16. That's fine, except I don't think
the attributes for which this notion applies should be annotated with
the slash. Further, it may be useful to identify what population is
being considered when using terms like "all requirements."

RelatedRequirement properties are actually derived since their values are calculated
from existing relationships linking requirements with other kinds of model elements.
The intent of such derived properties is to specify how some characteristics of
interest can be queried from their owner. For instance a requirement can be property is to model that, given a specific requirement, it is possible to know the
element linked to it through a <<satisfy>> relationship.
Nevertheless, the way to retrieve the actual value of those derived property is
currently specified in an informal manner only. This part of the specification can be
improved by adding the corresponding OCL queries.
Since many of those derived values require getting data across non navigable
association end in the metamodel, the practical way to compute them is to browse all
possible candidate instances and select those of interest. When OCL is used for that
purpose we rely on the allInstances() operation that is predefined for each class. The
Annexe A: “Semantics” of the OCL v2.3.1 specifies the scope to be considered:
• “Object models provide information used as context for OCL expressions and
constraints” (§A.1, p193)
• Object models are defined as structures gathering a set of classes and for
each of those classes sets of: attributes, operations, associations and
generalizations (cf. §A.2.1, p193 and following pages)
• A system state is defined as the snapshot of a system at a particular moment
in time. Given an object model M (as defined above), a system state for that
object model has a finite set of objects sCLASS with sCLASS(c) representing the
subset of all objects of a given class c. Such a system provide the complete
context for evaluating an OCL expression (except post and pre conditions, see
§A.3.1.3, p201)
• In such a context, the interpretation of the allInstances() called on a class c is
specified to be equal to sCLASS(c) (cf. §A.4.4.2, p208)
From a practical point of view, the object model on which a tool shall scope the
evaluation of an OCL expression is the one resulting from loading the topmost
UML::Model element that ultimately contains the context defined for that OCL
expression.