SysML 1.2 RTF Avatar
  1. OMG Issue

SYSML12 — use of derived in Requirements

  • Key: SYSML12-3
  • Legacy Issue Number: 12751
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    (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 RequirementRelated attributes should not be declared

    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."

  • Reported: SysML 1.1 — Thu, 7 Aug 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT