Foundations

Every grid view, table or matrix, is a SysML view usage element that visualises 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 also available from the sysand registry.

SysideViews library provides the base view types (TableView, HierarchicalTableView, MatrixView), the navigation step and representation catalogues, editable matrix presets, and all configuration attributes that shape how views render.

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 Collecting elements with expose and Narrowing the set with filter.

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.

Grid views layer additional inclusion rules on top through the ContentView attributes as described below.

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:

Attribute	Default	Effect
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.

One default differs downstream: a matrix cellView overrides includeReferenceElements to true.

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 always skipped during this traversal.

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;

    ...
}
// 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 bake parts of it in: HierarchicalTableView fixes both behaviours, while the editable matrix presets fix the Definition filter on both axes and the traversal on the cell view only, so an axis that should collect definitions through usages still sets exposeFeaturesAndHeritage itself. Users can narrow the selection further with additional 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).