Foundations

Every grid view, table or matrix, is a sysml view usage element that visualizes a subset of the model. Tables and matrices share the same foundations, covered on this page:

• The SysideViews library

• SysML v2 Expose and Filter mechanisms

• The ContentView attributes that broaden what a view collects

• The Definition-Usage pattern behind hierarchical tables and editable matrices

SysideViews Library

Grid views are built on top of types and attributes defined in the SysideViews SysML library. There is a prompt to add the library to the workspace when the SysMLv2 Views panel is opened. The library is pulled into a model file with a single import, just like any other sysml namespace:

package MyViews {
    private import SysideViews::*;

    view myTable : SV::TVD::TableView {
        expose MyModel::**;
        filter hastype SysML::RequirementUsage;

        view QualifiedName :> columnViews {
            attribute :>> featureToRender = CT::qualifiedName;
        }
        // additional columns below
    }
}

The library is also available from the sysand registry.

SysideViews library provides the base view types (TableView, HierarchicalTableView, MatrixView), column type catalogue, editable matrix presets, and all configuration attributes that shape how views render.

Short Names and Imports

Referencing the library follows standard SysML v2 name-resolution semantics. The library declares a SysML short name for its package, sub-packages, and enums (for example library package <SV> SysideViews). Every definition is therefore reachable through both its long and short name. How much qualification is needed depends only on what the import brings into scope:

• private import SysideViews::*; puts the top-level members in scope, so TVD::TableView (or SV::TVD::TableView) resolves

• private import SysideViews::**; imports recursively, so plain TableView resolves

All of SysideViews::TableViewDefinitions::TableView, SV::TVD::TableView, TVD::TableView, and TableView name the same definition; examples throughout these docs use the forms interchangeably. The short names defined by the library:

Short name	Full name	Contains
SV	SysideViews	The library package itself
TVD	SysideViews::TableViewDefinitions	TableView (TV), HierarchicalTableView (HTV)
MVD	SysideViews::MatrixViewDefinitions	MatrixView (MV) and the editable matrix presets
CT	SysideViews::ColumnType	Column type catalogue for featureToRender
CL	SysideViews::ColumnType::constraintLanguage	The ConstraintType (ConT) enum
Dir	SysideViews::MatrixTraceabilityDirection	Matrix direction values
Rep	SysideViews::MatrixElementRepresentation	Matrix header representation values

Expose and Filter

Every grid view selects model elements using the standard SysML v2 expose and filter statements. These behave the same way they do for diagram views. For the full mechanics see Understanding Exposing and Understanding Filters. Grid views layer additional inclusion rules on top through the ContentView attributes.

Note

Grid views currently do not support inline filter clauses on the exposed namespace (see inline filters), use the filter statement on the view instead.

ContentView Attributes

Every TableView, every MatrixView row or column view, and every matrix cellView inherits from ContentView. It provides boolean attributes for finer control over which elements a view collects, in addition to the sysml expose and filter statements. Each one defaults to false, and the defaults are the right choice for most views.

Attribute	Default	Effect
includeLibraryElements	false	Include elements defined in the SysML standard library.
includeReferenceElements	false	Include reference (non-composite) usages.
includeAbstractElements	false	Include abstract type definitions.
exposeFeaturesAndHeritage	false	Recursively expand each exposed element to include its features and heritage chain.

Note

Specialised view definitions in the library can redefine these defaults. For example, MatrixView’s cellView defaults includeReferenceElements to true, and HierarchicalTableView fixes exposeFeaturesAndHeritage to true. The SysideViews.sysml file in the workspace documents every attribute and its effective default inline. Treat it as the authoritative reference.

includeLibraryElements

Elements defined in the SysML standard library (ScalarValues, SysML, etc.) are excluded even when an expose statement would otherwise reach them. Set this flag to include them.

includeReferenceElements

Controls whether non-composite features are included in the view. Non-composite features are declared explicitly with the ref keyword, or implicitly when they appear at package level rather than as features of a Type.

Example Use Case

Consider a model where a DroneSystem part has a ref part externalSensor : Sensor convenience reference. A requirements table over DroneSystem::* will exclude externalSensor by default, keeping the view focused on owned elements. Set this to true when references are themselves the subject of the view:

part def DroneSystem {
    part sensor : Sensor;
    ref part externalSensor : Sensor; // non-composite feature, excluded by default
}

view allParts : TableView {
    expose DroneProject::DroneSystem::*;
    attribute :>> includeReferenceElements = true; // include externalSensor
    ...
}

includeAbstractElements

Abstract type definitions are excluded by default. Set this flag to include them.

Example Use Case

Consider a model that defines an abstract BaseRequirement definition that several concrete definitions specialise. The table will show only the concrete definitions unless this flag is set:

abstract requirement def BaseRequirement {
    doc /* Common requirement properties. */
}
requirement def MaxAltitude :> BaseRequirement { ... }

view allRequirements : TableView {
    expose DroneProject::*::**;
    filter hastype SysML::RequirementDefinition;
    attribute :>> includeAbstractElements = true; // include BaseRequirement
    ...
}

exposeFeaturesAndHeritage

When set to true, each element in the exposed pool is expanded to include its features and full heritage chain: supertypes, their supertypes, and so on, recursively. Standard-library elements are skipped during this traversal regardless of the includeLibraryElements setting.

Warning

Heritage traversal can noticeably slow down view population on large models. Scope expose as tightly as possible when using this attribute.

Example Use Case

Consider a model where definitions form a hierarchy through usages typed by other definitions:

part def Engine;
part def Transmission;
part def Powertrain {
    part engine : Engine;
    part transmission : Transmission;
}
part def Vehicle {
    part powertrain : Powertrain;
}

The hierarchy is expressed through usages:

• Vehicle owns powertrain : Powertrain

• Powertrain owns engine : Engine and transmission : Transmission

A plain expose of Vehicle returns only Vehicle. With exposeFeaturesAndHeritage = true, the view follows each usage to its type and collects every definition along the way. Adding filter hastype SysML::PartDefinition narrows the result to a flat table of every part definition reachable from Vehicle:

view allParts : TableView {
    expose MyPackage::Vehicle;
    filter hastype SysML::PartDefinition;
    attribute :>> exposeFeaturesAndHeritage = true;

    view Name :> columnViews { attribute :>> featureToRender = CT::name; }
    view Owner :> columnViews { attribute :>> featureToRender = CT::owner; }
}
// Rows: Vehicle, Powertrain, Engine, Transmission

The Definition-Usage Pattern

Hierarchical table views and editable matrix views share the same modelling pattern where definitions carry the data and usages establish the structure.

Definitions own the content a view renders and edits, such as documentation, attribute values, and constraints. They are what the view displays: the rows of a hierarchical table, the axes of an editable matrix. Usages typed by those definitions express the structure between them inside a context type. Usage nesting forms the tree of a hierarchical table; connections or allocations between usages mark the cells of a matrix.

// Definitions carry the data shown in the view
requirement def <'SYS-001'> CruisingSpeed {
    doc /* The drone shall reach a cruising speed of at least 60 km/h. */
}
requirement def <'SUB-001'> MotorPower {
    doc /* Each motor shall output at least 150 W continuously. */
}

// Usages establish the structure, here through nesting
item def RequirementContext {
    requirement speed : CruisingSpeed {
        requirement motor : MotorPower;
    }
}

The view collects the definitions by following usages from the exposed context, using the exposeFeaturesAndHeritage traversal. It then keeps only the definitions themselves, via filter istype SysML::Definition. View definitions built on this pattern (HierarchicalTableView, the editable matrix presets) bake in both behaviours, so neither needs to be written explicitly (though users can narrow this down further by adding more filter clauses).

Edits made through such a view are written to the definition; the usages only locate it. A definition represented by more than one usage in the context is therefore ambiguous: hierarchical tables disable editing for it, and editable matrices disable relationship creation (see Disabled Cells).