Common patterns

Most tables want the same handful of columns: an ID, a name, an attribute value, a piece of documentation, a constraint’s text. This page collects ready-made recipes for exactly those columns, each one short enough to copy into a view and adapt.

Chains and representations combine into a small number of recurring column shapes. Each recipe below is self-contained; those pages cover the machinery in full.

Show a name

For aspects of the row element itself, no chain is needed; pick a representation:

view Name :> columnViews {
    attribute :>> featureRepresentation :> ColRep::declaredName;
}

declaredShortName shows the <…> form (for example a requirement ID), qualifiedName the fully qualified name, and documentation all documentation blocks concatenated.

Show and edit an attribute value

Navigate to the attribute by name, render its value:

view Priority :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "priority",
    UsageKind::attributeUsage);
    attribute :>> featureRepresentation :> ColRep::featureValue;
}

The cell edits with an editor picked from the attribute’s declared type (see Editable representations). If the row element does not declare the attribute at all, the cell shows defaultValue and typing into it creates the attribute on save.

Show and edit documentation

specificDocumentation selects one documentation block by name; the default name "" selects the unnamed body. If a requirement carries both a named rationale block and an unnamed body, two columns can surface them independently:

requirement def MaxAltitude {
    doc rationale /* Altitude limit set by local air-traffic regulations. */
    doc /* The drone shall reach a maximum altitude of 500 m. */
}

view requirementsTable : TVD::TableView {
    expose DroneProject::DroneSystem::*;
    filter hastype SysML::RequirementUsage;

    view Rationale :> columnViews {
        attribute :>> featureRepresentation :> ColRep::specificDocumentation {
            attribute :>> documentationName = "rationale";
        }
    }
    view Body :> columnViews {
        attribute :>> featureRepresentation :> ColRep::specificDocumentation;
    }
}

Show and edit constraint text

Navigate the chain to the constraint, then render its language-specific body with the 'language' representation. For a requirement’s require / assume constraint, which is typically unnamed and singular, use the RequirementConstraints family:

requirement def MaxAltitude {
    require constraint altitudeLimit {
        language "English"
            /* The drone shall not exceed an altitude of 500 m. */
    }
}

view Constraint :> columnViews {
    :>> columnFeature = RequirementConstraintsFirst(
        baseViewElement,
        RequirementConstraintKindSV::required
    );
    attribute :>> featureRepresentation :> ColRep::'language';
}

A named constraint can be reached by name instead:

view 'English Constraint' :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "altitudeLimit",
    UsageKind::constraintUsage);
    attribute :>> featureRepresentation :> ColRep::'language' {
        attribute :>> languageName = "English";
    }
}

Show the owner

view 'Owning Element' :> columnViews {
    :>> columnFeature = Owner(baseViewElement);
    // qualifiedName is the default representation
}

A column named Owner would shadow the step of the same name, hence the header 'Owning Element'.

Show the heritage

The element’s specialisation chain, walked upward breadth-first and excluding standard-library types, all in one read-only cell:

view Heritage :> columnViews {
    :>> columnFeature = HeritageList(baseViewElement);
    attribute :>> featureRepresentation :> ColRep::name;
}

Show the value of any named feature

Without a UsageKind argument, NamedUsage matches a feature of any usage kind. Values of non-attribute features render read-only:

view AssignedComponent :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "assignedComponent");
    attribute :>> featureRepresentation :> ColRep::featureValue;
}

Show a value from a metadata tag

MetadataUsageTag selects the row element’s metadata tag by the tag definition’s name; a chained NamedUsage then reaches a value bound inside the tag:

metadata def Safety {
    attribute level;
}

part marked {
    @Safety {
        :>> level = 10;
    }
}

view Level :> columnViews {
    :>> columnFeature = NamedUsage(MetadataUsageTag(baseViewElement, "Safety"), "level");
    attribute :>> featureRepresentation :> ColRep::featureValue;
}

On an untagged row the chain stops at the MetadataUsageTag step, so the cell shows notApplicableValue.

Show the requirement’s subject

view 'Subject Name' :> columnViews {
    :>> columnFeature = Subject(baseViewElement);
    attribute :>> featureRepresentation :> ColRep::name;
}

For a row that is not a requirement, the cell shows notApplicableValue.

One row per port, part, or other nested feature

A Fan step splits each row into sub-rows, one per target. It must be declared as a named view-level ref (an anchor), which columns then navigate from:

view partsTable : TVD::TableView {
    expose DroneProject::DroneSystem::*;

    ports = UsageFan(baseViewElement, UsageKind::portUsage);

    view Part :> columnViews {
        attribute :>> featureRepresentation :> ColRep::declaredName;
    }
    view Port :> columnViews {
        :>> columnFeature = ports;
        attribute :>> featureRepresentation :> ColRep::declaredName;
    }
    view 'Port Documentation' :> columnViews {
        :>> columnFeature = ports;
        attribute :>> featureRepresentation :> ColRep::specificDocumentation;
    }
}

Each part row splits into one sub-row per port; the Part cell spans its sub-rows as one merged run. See Fanning out rows.