Configure Table Views

A table view presents a flat, spreadsheet-like summary of model elements. Each row is an element matched by expose / filter; each column is a child view subsetting columnViews.

This page covers the SysML authoring pieces specific to tables. See also:

Foundations - shared concepts (library, ContentView flags, expose / filter mechanics)
Use Grid Views - in-editor workflows (filter, edit, navigate, create requirements)

Structure

TableView definition combines three things:

An expose / filter clause that selects which elements appear as rows
Child views subsetting columnViews, each defining one column
Optional configuration attributes set on the table or on individual columns

A minimal example (see Example Template for full reference):

package MyViews {
    private import SysideViews::*;

    view myRequirementsTable : SV::TVD::TableView {
        expose ExampleModel::**;
        filter hastype SysML::RequirementDefinition;

        view ID :> columnViews {
            attribute :>> featureToRender = CT::declaredShortName;
        }
        view Description :> columnViews {
            attribute :>> featureToRender = CT::specificDocumentation {
                attribute documentationName = "";
            }
        }
    }
}

By default, columns appear in the order their child views are declared in the SysML source. This order can be overridden through columnOrder or by drag-and-drop in the UI.

The declared name of each child view becomes the column header exactly as written. view ID, view Name, and view Description produce headers ID, Name, and Description.

Hierarchical Table Views

A hierarchical table view is a specialisation of the regular table view that renders model elements in a tree structure, reflecting parent–child relationships in the model. Authoring is identical to a flat table view — the same columns, expose / filter mechanics, and column types all apply — but is typed by HierarchicalTableView instead of TableView.

Hierarchical table views currently support the same modelling pattern as the editable matrix view: Definition elements carry the data, and Usage elements establish the hierarchy. See Supported Modelling Pattern for details on this pattern.

Cell editing works the same as in flat table views. Because the hierarchical table represents Definition elements typed by Usage elements, edits are applied directly to the definitions. Editing is disabled for definitions that appear more than once in the hierarchy (multiple entries), to avoid ambiguous writes.

Column Views

columnViews is a feature defined on TableView. Each view usage that subsets it becomes one column in the rendered table and accepts three attributes:

Attribute	Default	Description
`featureToRender`	`CT::qualifiedName`	Which aspect of each row element to display. The full catalogue of values is in Column Types below.
`defaultValue`	`""`	Fallback text shown when the element has no value for this column. Displayed in italics and greyed out.
`columnWidth`	`150`	Initial column width in pixels. Resizing in the UI updates this attribute via Save View Changes.

Column Types

Each column’s featureToRender attribute selects what to display. The available values come from the SysideViews::ColumnType enum (short alias CT).

Editable Types

Cells in these columns can be edited inline.

Column type	Description
`CT::specificDocumentation`	A single named or unnamed documentation block. Requires `documentationName`. See Parameterised Types.
`CT::attributeValue`	The value of a named attribute. Requires `attributeName`. See Parameterised Types.
`CT::constraintLanguage`	The text body of a constraint usage written in a specific language. Requires `constraintName`, `constraintType`, and `constraintLanguage`. See Parameterised Types.

Read-only Types

Column type	Description
`CT::reqId`	The requirement ID, the `declaredShortName` of a `RequirementUsage`, e.g. `<REQ-001>`.
`CT::declaredName`	The element name exactly as written in the source model.
`CT::declaredShortName`	The short name as written in the source model (the `<…>` form).
`CT::name`	The semantically resolved name of the element (may differ from `declaredName` after redefinition).
`CT::shortName`	The semantically resolved short name of the element.
`CT::qualifiedName`	The fully qualified name of the element, including all enclosing namespaces.
`CT::owner`	The qualified name of the element’s owner (parent namespace).
`CT::documentation`	All documentation blocks on the element, concatenated in declaration order.
`CT::namedFeatureValue`	The value of a named feature. Requires `featureName`. Read-only because `=` assignment is ambiguous for non-attribute features in SysML. See Parameterised Types.
`CT::hierarchy`	The specialisation hierarchy of the element, listed from immediate parent upward, excluding standard-library types.

Parameterised Types

Four column types need extra attributes to identify which value to show.

`CT::specificDocumentation`

Set documentationName to the name of the documentation block to show, or "" for 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 : TableView {
    expose DroneProject::DroneSystem::*;
    filter hastype SysML::RequirementUsage;

    view Rationale :> columnViews {
        attribute :>> featureToRender = CT::specificDocumentation {
            attribute documentationName = "rationale";
        }
    }
    view Body :> columnViews {
        attribute :>> featureToRender = CT::specificDocumentation {
            attribute documentationName = "";
        }
    }
}

`CT::attributeValue`

Set attributeName to the attribute name as declared on the type. The column picks an editor based on the attribute’s declared type; if the type is not explicit, it’s inferred from existing values. The following types are supported:

Attribute type	Editor behaviour
Enumeration	Dropdown listing all enum literals. When the attribute is typed by more than one enumeration, the dropdown concatenates the literals from all of them.
Enumeration (upper multiplicity range > 1)	Multi-select dropdown with the same concatenated literal list. Each selected literal is written as a collection value.
Boolean	Dropdown with `true` and `false` options.
String	Free-text input.
Numeric	Numeric input.

Note

Currently the quantities from SI standard library are supported as read-only and do not display the unit of the quantity.

requirement def MaxAltitude {
    attribute priority : Priority;
    attribute verificationMethod : VerificationMethod;
}

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

    view Priority :> columnViews {
        attribute :>> featureToRender = CT::attributeValue {
            attribute attributeName = "priority";
        }
    }
    view VerificationMethod :> columnViews {
        attribute :>> featureToRender = CT::attributeValue {
            attribute attributeName = "verificationMethod";
        }
    }
}

Note

The default pattern for attributeValue assignment is to bind values using default for Definition owners, and = for Usage owners. An existing binding keyword is not overwritten.

`CT::namedFeatureValue`

Set featureName to the feature name. This type is read-only because = assignment is ambiguous for non-attribute features in SysML:

view AssignedComponent :> columnViews {
    attribute :>> featureToRender = CT::namedFeatureValue {
        attribute featureName = "assignedComponent";
    }
}

`CT::constraintLanguage`

Displays the body of a constraint usage written in a specific constraint language. Identified by three attributes:

constraintName - name of the constraint usage; "" for unnamed
constraintType - one of plain, assumed, asserted, required (from the <ConT> ConstraintType enum)
constraintLanguage - language tag string (e.g. "English")

view EnglishConstraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "";
        attribute constraintType = CL::ConT::required;
        attribute constraintLanguage = "English";
    }
}

Note

attributeValue and constraintLanguage columns represent features that can be inherited. Editing an inherited value creates a redefinition of the inherited feature on the row element.

Table Attributes

Two attributes apply to the table as a whole:

Attribute	Default	Description
`maxRowHeight`	`125`	Maximum height of each row in pixels. Content exceeding this height is clipped and shown in a tooltip on hover.
`columnOrder`	source order	Reference list that overrides the visual column order without reordering the SysML source. Drag-and-drop reordering in the UI updates this attribute via Save View Changes. Columns omitted from `columnOrder` are hidden.
`defaultCollapse`	`false`	Specific to hierarchical table views. When `true`, all rows are collapsed by default on first load. Users can expand individual rows interactively.

The columnOrder attribute in action: showing Description first, hiding ID:

view myTable : TVD::TableView {
    filter hastype SysML::RequirementUsage;

    :>> columnOrder = (Description, Name); // show Description first, hide ID

    view ID :> columnViews {
        attribute :>> featureToRender = CT::reqId;
    }
    view Name :> columnViews {
        attribute :>> featureToRender = CT::declaredName;
    }
    view Description :> columnViews {
        attribute :>> featureToRender = CT::documentation;
    }
}

Example Template

A reference template combining table-level attributes, parameterised and read-only column types, and per-column attributes:

package MyViews {
    private import SysideViews::*;
    private import TableViewExample::*;

    view myRequirementsTable : SV::TVD::TableView {
        expose ExampleRequirements::*;
        filter hastype SysML::RequirementDefinition;

        attribute :>> exposeFeaturesAndHeritage = true;
        attribute :>> maxRowHeight = 300;

        view ID :> columnViews {
            attribute :>> featureToRender = CT::declaredShortName;
            attribute :>> defaultValue = "missing_id";
            attribute :>> columnWidth = 100;
        }
        view 'Summary Name' :> columnViews {
            attribute :>> featureToRender = CT::declaredName;
            attribute :>> columnWidth = 220;
        }
        view Description :> columnViews {
            attribute :>> featureToRender = CT::attributeValue {
                attribute attributeName = "description";
            }
            attribute :>> defaultValue = "n/a";
            attribute :>> columnWidth = 304;
        }
        view Documentation :> columnViews {
            attribute :>> featureToRender = CT::specificDocumentation {
                attribute documentationName = "";
            }
            attribute :>> defaultValue = "n/a";
            attribute :>> columnWidth = 231;
        }
    }
}

Reference Files

Download Requirements Table (ZIP)

Configure Table Views

Structure

Hierarchical Table Views

Column Views

Column Types

Editable Types

Read-only Types

Parameterised Types

`CT::specificDocumentation`

`CT::attributeValue`

`CT::namedFeatureValue`

`CT::constraintLanguage`

Table Attributes

Example Template

Reference Files

Feedback

Legal

Company

Configure Table Views

Structure

Hierarchical Table Views

Column Views

Column Types

Editable Types

Read-only Types

Parameterised Types

CT::specificDocumentation

CT::attributeValue

CT::namedFeatureValue

CT::constraintLanguage

Table Attributes

Example Template

Reference Files

Feedback

Legal

Company

`CT::specificDocumentation`

`CT::attributeValue`

`CT::namedFeatureValue`

`CT::constraintLanguage`