You can specify filters for view definitions and/or specific views to narrow down what elements can be displayed by views. Once you have created a view, specified the exposed elements, you can then optionally filter the exposed elements. Views have the capability to filter elements upon exposition based on certain conditions. Only elements that meet all filter conditions are exposed for the view. 

Elements can be filtered for views only via the Textual Editor.

Filtering elements for views

Ways to perform element filtering for views:

  • Specifying filter conditions. You can specify filter conditions directly for the specific view, using the keyword filter.
  • Inheriting filter conditions. You can also filter elements for views through inheritance, e.g., if the view is defined by a view definition that contains filter conditions, the filters are inherited by and applied to the defined view. 

Specifying filter conditions

  • Filter conditions can be used only for package (element import) and view (element exposition) elements.
  • Filter condition expression must be model-level evaluable. Any SysML v2 expression can be used for the filter condition specification, but it must return true/false.
  • @, istype, and hastype classification operators are commonly used to check if an element has the given metadata annotation.
  • Element metaclass metadatas are located in the used projects at Standard Libraries > SysML > Systems. Filter conditions require a qualified name for metadata-based filtering (e.g., @SysML::Systems::PartUsage).

To specify filter conditions 

  1. In the Textual Editor, place the cursor within the body of the view.
  2. Declare the keyword filter followed by filter condition expression, including the needed operator and the qualified name of the element you want to expose.
  3. Click the Synchronize button.

package MetadataDefinitions {
    metadata def Safety {
        attribute isMandatory : Boolean;
    }
}

package Vehicle {
    private import MetadataDefinitions::**;
    part vehicle {
        part interior {
            part alarm;
            part seatBelt [2] { @Safety{isMandatory = true;} }
            part frontSeat [2];
            part driverAirBag { @Safety{isMandatory = false;} }
        }
    }
}

view 'Vehicle Features' {
    expose Vehicle::**;  // exposes package Vehicle 
    // you can use multiple filter condition declarations:
    filter @ SysML::Systems::PartUsage; // exposes part usage elements from the package Vehicle
    filter @ MetadataDefinitions::Safety and MetadataDefinitions::Safety::isMandatory; // exposes elements with Safety metadata attribute isMandatory value true from previously filtered part usage elements exposed from the package Vehicle
}

Inheriting filter conditions

Filters in predefined view definitions:

  • Standard predefined symbolic/tabular view definitions (except for RequirementsTable) do not have any specified filters, meaning, any elements can be exposed by these views. Once you have created such a view, you may want to specify filters to limit the displayed elements.
  • Predefined symbolic view definitions that use expressions contain:
    • Element filters specified in the DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter and DS_Views::SymbolicViewsByExpression::EssentialElementsFilter view definitions, narrowing down what elements can be exposed by the view by discarding various standard library elements and other non-essential elements that are unlikely to be relevant for display in views. 
    • Additionally, most of the predefined symbolic view definitions that use expressions contain additional filters to narrow down the exposed elements, e.g., PartsTreeView view definition contains filters specifying that only part usage elements can be exposed.

Recommendations:

  • The easiest way to filter exposed elements is to reuse predefined symbolic view definitions that use expressions. See Example 1. 
    • Keep in mind that the renderers specified for the view definitions are also inherited.
  • If you only want to discard uncommon library elements from being displayed in a view, you can reuse the DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter and DS_Views::SymbolicViewsByExpression::EssentialElementsFilter view definitions. See Example 2.
Example 1

view def NonStandardLibraryElementFilter {
   // see the DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter view definition in the modeling tool to view all filters specified for it
}
view def TreeView :> EssentialElementsFilter, NonStandardLibraryElementFilter { // the TreeView view definition subclassifies the two view definitions inheriting their filters
   render Views::asTreeDiagram; // the specified renderer will be inherited
}

view def PartsTreeView :> TreeView { // the PartsTreeView view definition subclassifies TreeView inheriting all filters and renderer
   filter hastype PartUsage;
}

view newView : DS_Views::SymbolicViewsByExpression::PartsTreeView { // the specific view is defined by PartsTreeView view definition inheriting all filters and renderer
    expose Vehicle::**;
}

Example 2

view def NonStandardLibraryElementFilter {
   // see the DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter view definition in the modeling tool to view all filters specified for it
}

view newView : DS_Views::SymbolicViewsByExpression::EssentialElementsFilter, DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter { // the specific view is defined by the view definitions inheriting their filters
    expose Vehicle::**;
}

// the view is defined by the Interconnection View view definition (inheriting its renderer) and view definitions specifying filters:
view newView : DS_Views::SymbolicViews::iv, DS_Views::SymbolicViewsByExpression::EssentialElementsFilter, DS_Views::SymbolicViewsByExpression::NonStandardLibraryElementFilter {
    expose Vehicle::**;
}