Build a table view

This tutorial introduces table views in the Syside VS Code Extension by building one: a table over two requirements, adding one column at a time. Each step introduces one concept briefly and links the page that explains it in depth.

The views below import the SysideViews library, which the SysMLv2 Views panel offers to add the first time you open it, so accept that prompt before writing a view.

To get started, copy and save this model as ExampleModel.sysml. It has two requirement definitions, each with an ID, documentation, and a subject:

package ExampleModel {
    part def Drone {
        doc /* A quadcopter delivery drone. */
    }
    part def Battery {
        doc /* A rechargeable power source. */
    }

    requirement def <'REQ-001'> MaxAltitude {
        doc /* The drone shall not exceed an altitude of 500 m. */
        subject drone : Drone;
    }
    requirement def <'REQ-002'> BatteryEndurance {
        doc /* The battery shall sustain 30 minutes of flight. */
        subject battery : Battery;
    }
}

Choose the rows

The table view is itself a SysML element, written in the same workspace. TVD and ColRep are short names the library declares for its table view definitions and column representations, which is why the view below is typed TVD::TableView.

The view’s expose statement casts a wide net over the model, and filter narrows the catch by type. Save this as MyViews.sysml:

package MyViews {
    private import SysideViews::*;

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

Everything directly under ExampleModel is exposed, and only the requirement definitions survive the filter: MaxAltitude and BatteryEndurance become the two rows (see Select view elements). A set of boolean attributes refines what the selection collects, such as whether abstract definitions are included (see Include flags in grid views).

Open myRequirementsTable from the SysMLv2 Views panel. It opens empty, with Rows: 2 in the status line, since no columns are defined yet.

Add a column

Each child view subsetting columnViews becomes one column, and its declared name becomes the column header, exactly as written. Add this column inside the view to show each requirement’s ID:

view ID :> columnViews {
    attribute :>> featureRepresentation :> ColRep::declaredShortName;
}

The featureRepresentation attribute selects what aspect of the row element the cells render: here the declared short name, which is where a requirement ID lives.

The ID column now shows REQ-001 and REQ-002.

Further columns can render other aspects of the same row element by picking different representations, here the declared name and the documentation body:

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

The full catalog of representations spans names, documentation, attribute values, and more (see Cell representations). Some representations are writable, making their cells editable straight from the table (see Editable representations).

The table now has three columns: ID, Name, and Doc.

Reach related elements

A cell does not have to be about the row element itself. Every column so far implicitly describes baseViewElement, the default feature a cell represents: on each row it is that row’s own element, MaxAltitude on the first and BatteryEndurance on the second. A navigation chain, written in columnFeature, starts from baseViewElement and moves to a related element through steps such as Subject or Owner (see Table navigation chains):

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

columnFeature is written without the attribute keyword, unlike featureRepresentation, because it is not an attribute. Writing attribute :>> columnFeature = … changes the feature’s type and breaks the column.

On the first row the chain runs from MaxAltitude to its subject drone, and the representation then renders that subject’s name. The two halves are independent, so any representation can follow any chain. A quoted view name such as 'Subject Name' allows spaces in the header.

The Subject Name column shows drone and battery.

Steps compose by nesting, so a chain can take several steps. This column continues past the subject to the definition that types it, and renders that definition’s documentation:

view 'Subject Doc' :> columnViews {
    :>> columnFeature = DefinitionsFirst(Subject(baseViewElement));
    attribute :>> featureRepresentation :> ColRep::documentation;
}

A nested chain reads from the inside out: on the first row, Subject runs from MaxAltitude to drone, and DefinitionsFirst continues from drone to the Drone definition, whose documentation the cell shows.

Check the finished table

The finished table has two rows and five columns. Subject Doc shows the documentation from the Drone and Battery definitions.

The complete MyViews.sysml file is:

package MyViews {
    private import SysideViews::*;

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

        view ID :> columnViews {
            attribute :>> featureRepresentation :> ColRep::declaredShortName;
        }
        view Name :> columnViews {
            attribute :>> featureRepresentation :> ColRep::declaredName;
        }
        view Doc :> columnViews {
            attribute :>> featureRepresentation :> ColRep::documentation;
        }
        view 'Subject Name' :> columnViews {
            :>> columnFeature = Subject(baseViewElement);
            attribute :>> featureRepresentation :> ColRep::name;
        }
        view 'Subject Doc' :> columnViews {
            :>> columnFeature = DefinitionsFirst(Subject(baseViewElement));
            attribute :>> featureRepresentation :> ColRep::documentation;
        }
    }
}

What’s next

To extend this table with the columns most tables need, such as attribute values, constraint text and owners, continue with Add frequently used table columns. Each pattern is ready to copy into myRequirementsTable.

The Subject Doc column used a nested navigation chain, and every column picked a representation. Table navigation chains explains how chains are built, and Cell representations lists what a column can show and which cells can be edited.