Configure Table Views

A table view presents a spreadsheet-like summary of model elements. It can be a flat table, or a collapsible tree with hierarchical table views. 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; for shared concepts see Foundations, and for in-editor workflows see Use Grid Views.

Structure

A TableView definition has an expose / filter clause that selects which elements appear as rows. The ContentView attributes gives additional control over which elements are included. Child views subsetting columnViews each define one column. There are also optional configuration attributes that can be 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. It is typed by HierarchicalTableView instead of TableView, but authoring is otherwise identical to a flat table view: the same columns, expose / filter mechanics, and column types all apply.

Hierarchical table views are built on the Definition–Usage pattern: definitions carry the row data, and the nesting of usages typed by them defines the tree. HierarchicalTableView bakes in the mechanics this needs. It fixes exposeFeaturesAndHeritage = true and filters rows to istype SysML::Definition, so only definitions appear as rows and neither setting needs to be written explicitly.

Cell editing works the same as in flat table views, with edits applied directly to the definitions. Editing is disabled for a definition that appears more than once in the hierarchy, 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 the following 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.
`columnFilter`	unset	Persisted filter text for this column. Typically maintained through the search bar and Save View Changes rather than authored by hand.

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, selected by `documentationName`; when omitted, the unnamed body is shown. 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::heritage`	The heritage of the element: its specialisation chain listed from immediate parent upward, excluding standard-library types.

Parameterised Types

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

`CT::specificDocumentation`

Set documentationName to the name of the documentation block to show. The attribute defaults to "", which selects the unnamed body. It can therefore be omitted entirely when the unnamed documentation is the target. 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	Single-select 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 (multiplicity upper bound above 1)	Multi-select dropdown with the same concatenated literal list. See Single-select vs multi-select dropdowns.
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.

Single-select vs multi-select dropdowns

Whether an enumeration column renders a single-select or a multi-select dropdown is decided by the attribute declaration in the model, not by the view. The attribute’s declared multiplicity is what matters. With the default multiplicity of one, the cell edits as a single-select dropdown. Declare an upper bound above one, or an unbounded multiplicity such as [0..*], and the same column renders a multi-select dropdown:

enum def Category { safety; performance; usability; }

requirement def MaxAltitude {
    attribute mainCategory : Category;        // single-select dropdown
    attribute categories : Category [0..*];   // multi-select dropdown
}

Selected literals from a multi-select cell are written back as a collection value, for example (Category::safety, Category::usability). If the attribute declares no multiplicity of its own, the multiplicity is inherited from the attribute it redefines.

`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 these attributes:

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

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

view EnglishConstraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "altitudeLimit";
        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

These 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.
`globalFilter`	unset	Persisted global search-bar filter, applied across all columns. Typically maintained through the search bar and Save View Changes rather than authored by hand. Per-column filter text is persisted separately, in each column’s `columnFilter` attribute (see Column Views).
`columnOrder`	source order	Reference list that overrides the visual column order without reordering the SysML source. Drag-and-drop reordering and the Shown columns dropdown in the UI update this attribute via Save View Changes. Columns omitted from `columnOrder` are hidden.
`defaultCollapse`	`true`	Specific to hierarchical table views. When `true` (the default), all rows are collapsed on first load; users can expand individual rows interactively. Set to `false` to start with all rows expanded.

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

The example imports the SysideViews library, which is not included in the download. Open the example in the Views Explorer, or export it with syside table export.

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`

Single-select vs multi-select dropdowns

`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

Single-select vs multi-select dropdowns

CT::namedFeatureValue

CT::constraintLanguage

Table Attributes

Example Template

Reference Files

Feedback

Legal

Company

`CT::specificDocumentation`

`CT::attributeValue`

`CT::namedFeatureValue`

`CT::constraintLanguage`