Draft Documentation

This page is currently under development. Content may be incomplete or subject to change.

Views and Viewpoints: Dynamic Filtering in SysGit

Overview

SysGit's Views and Viewpoints capability enables teams to create persistent, dynamic filters on model elements using SysML v2 metadata and filter expressions. This feature addresses a fundamental challenge in complex systems engineering: different stakeholders need different perspectives on the same underlying model. Rather than creating static copies or reports that quickly become outdated, Views remain synchronized with the model and automatically reflect changes as requirements, parts, and other elements evolve.

Views are particularly valuable in multi-team environments where program managers need approval status visibility, systems engineers need subsystem-specific views, or quality teams need to track verification-related elements. Each View defines filter criteria using SysML v2 expressions that can reference metadata attributes, element types, or any combination of model properties.

Understanding the View Mechanism

Metadata Definitions as Filter Criteria

The foundation of SysGit's View filtering lies in custom metadata definitions. Metadata in SysML v2 provides a standardized way to annotate model elements with structured information beyond the base language specification. For View filtering, teams define metadata definitions that capture workflow-relevant attributes such as approval status, responsibility assignments, maturity levels, or any domain-specific classification.

In the example shown, an Approval metadata definition establishes three attributes: approved (Boolean), approver (String), and level (Natural number). This metadata can then be applied to any requirement, part, or other model element using the @Approval annotation syntax. The metadata becomes queryable through View filter expressions, enabling dynamic selection of elements based on their annotation values.

View Definition Syntax

Views are defined using three key components: a name that appears in the UI, an expose statement that specifies the scope of elements to consider, and a filter expression that determines which elements to display. The expose statement typically uses a wildcard pattern like PackageName::* to include all elements within a package, while the filter expression combines type checks and metadata queries using logical operators.

Filter expressions in SysGit support standard comparison operators (==, !=, >, <), logical operators (and, or, not), and metadata attribute access through dot notation. The @SysML::RequirementUsage type check ensures only requirements are selected, while metadata attribute checks like @Approval and Approval::approved verify both that the metadata exists and that specific attribute values match criteria.

Creating Views for Requirements Management

Setting Up Custom Metadata

The demonstration begins with a complete SysML v2 model that defines both the metadata structure and the requirements that will be filtered. At the top of the model (lines 4-8), the Approval metadata definition establishes the approval workflow schema with three attributes. The Boolean approved flag indicates whether a requirement has been approved, the String approver captures the responsible individual's name, and the Natural number level can represent approval hierarchy or authority level.

This metadata definition follows SysML v2's attribute definition syntax, specifying both the attribute name and its type. The types used (Boolean, String, Natural) come from standard SysML v2 libraries and provide type safety when metadata is applied to model elements. Once defined, this metadata becomes available for annotation throughout the model and for querying in View filter expressions.

Applying Metadata to Requirements

Two requirements demonstrate metadata application with different approval states. Requirement req1 (lines 10-16) includes an @Approval annotation block that sets approved = true, assigns approver = "John Smith", and establishes level = 2. The annotation syntax uses attribute assignment within curly braces, matching the structure defined in the metadata definition.

Requirement req2 (lines 18-23) shows a contrasting approval state with approved = false and approver = "Jane", also at level = 2. This variation in metadata values enables the filtering demonstrated in the Views. The metadata application occurs within the requirement definition itself, ensuring that approval status travels with the requirement through version control and model exchanges.

Defining Approval Status Views

The first View, ApprovedReqs (lines 27-30), demonstrates filtering by approval status. The expose statement expose ApprovalFilterTesting::*; includes all elements within the package for consideration. The filter expression combines three conditions: @SysML::RequirementUsage restricts to requirements only, @Approval ensures the metadata exists on the element, and Approval::approved checks that the approved attribute value is true (which in SysML v2 Boolean logic means the attribute evaluates to true).

This filter will dynamically select only those requirements that have been marked as approved, regardless of who approved them or at what level. As requirements move through the approval workflow and their metadata is updated, this View automatically adjusts its contents without requiring manual intervention or View redefinition.

Defining Approver-Specific Views

The second View, ApprovedByJane (lines 31-34), shows more sophisticated filtering based on metadata attribute values. The filter expression @SysML::RequirementUsage and @Approval and Approval::approver == "Jane" performs a string equality check on the approver attribute. This demonstrates how Views can filter on any metadata attribute, not just Boolean flags, enabling precise stakeholder-specific perspectives.

This pattern extends naturally to more complex scenarios. Teams could create Views for specific approval levels (Approval::level >= 2), combine multiple criteria (Approval::approved and Approval::level > 1), or filter on any combination of metadata attributes and element properties that support their workflow requirements.

Applying Views in the User Interface

Accessing the View Selector

The View selector appears in the upper right section of the SysGit interface, displaying as a dropdown menu labeled "View:" with the currently selected view name. In the default state, the selector shows "General View" which presents all elements without filtering. The presence of custom Views defined in the model causes them to appear as selectable options in this dropdown.

Once Views are defined in SysML v2, they automatically populate the View selector without requiring separate configuration or tool-specific metadata. This direct connection between model definition and UI behavior ensures that Views remain synchronized with the model and can be version controlled, branched, and merged using standard Git workflows along with the rest of the engineering artifacts.

Viewing Filtered Results

When the ApprovedByJane View is selected, the interface updates to display only req2, which matches the filter criteria. The graph view on the right adjusts to show the filtered element prominently, while the card detail on the right displays the full requirement content. Under the "Other" section, the metadata annotation values are visible: {"approved":false,"approver":"Jane","level":2}, confirming why this requirement appeared in the Jane-specific view.

The URL in the browser also updates to reflect the active View: view=ApprovedByJane. This enables direct linking to specific Views, supporting use cases where program managers or stakeholders need bookmarkable access to particular perspectives on the model. The filtered view maintains full interactivity—users can still edit requirements, modify metadata, and perform all standard operations, with the understanding that changes to metadata values may cause elements to move in or out of the current View.

View Persistence and Dynamic Updates

Model Evolution and View Synchronization

Views remain synchronized with model content automatically as the system evolves. When a requirement's approval status changes from approved = false to approved = true, it immediately becomes visible in the ApprovedReqs View without requiring View regeneration. Similarly, if the approver name is changed from "Jane" to "John Smith", the requirement moves from the ApprovedByJane View to a hypothetical ApprovedByJohn View.

This dynamic behavior stems from the View evaluation mechanism. Rather than storing static lists of elements, Views store filter expressions that are evaluated each time the View is accessed. The evaluation operates on the current model state, ensuring that Views always reflect up-to-date information regardless of when or how model elements have been modified.

Views in Collaborative Workflows

In Git-based collaborative environments, Views provide particular value for distributed teams. When a systems engineer on one continent approves a requirement by updating its metadata, a program manager on another continent sees that requirement appear in the approved-requirements View the next time they pull the latest model state from Git. The View definition itself travels through Git as part of the SysML v2 model, ensuring consistent filtering logic across all team members.

Views also support branching workflows naturally. Different feature branches can experiment with different View definitions or different filtering criteria, and when branches are merged, Git's standard conflict resolution applies to View definitions just as it does to requirements or parts. This enables teams to evolve their View structures alongside their models without requiring separate tool configuration or manual synchronization.

Advanced Filtering Patterns

Combining Multiple Metadata Types

While the demonstration shows single-metadata filtering, production systems often combine multiple metadata types in a single View. A verification-focused View might filter using both approval status and verification method: @SysML::RequirementUsage and @Approval and Approval::approved and @VerificationMethod and VerificationMethod::method == "test". This would show only approved requirements that require physical testing, useful for test planning and resource allocation.

Multiple metadata definitions can coexist on a single element, and Views can reference any subset of them. This enables sophisticated filtering logic without cluttering individual elements with redundant annotations. Teams define the metadata definitions that match their workflow needs, apply them selectively to elements, and create Views that surface the right information for each stakeholder role.

Hierarchical and Relationship Filtering

Views can also filter based on element relationships and hierarchy, though the demonstration focuses on metadata-based filtering. A subsystem-focused View might filter by containment relationships, showing only parts within a specific component hierarchy. Similarly, Views could filter requirements based on satisfaction relationships, showing requirements satisfied by specific parts or subsystems.

The combination of metadata filtering, type filtering, and relationship filtering provides comprehensive control over what information each stakeholder sees. A supplier organization might see a View filtered to show only interface requirements and the parts they are responsible for delivering, while an integration team might see a View showing all parts with unresolved interface conflicts.

Practical Applications for Enterprise Systems Engineering

Program Management Dashboards

Program managers benefit from Views that aggregate approval status across entire programs. Rather than manually tracking spreadsheet-based approval records, managers access Views showing requirements by approval state, enabling data-driven decisions about program readiness. Combined with SysGit's Git integration, approval history is fully auditable through Git commit history, showing who approved what and when.

Views for program management often filter by multiple dimensions simultaneously. A program manager might access a View showing high-risk, unapproved requirements at approval level 3 or higher, enabling focused attention on critical approval bottlenecks. These Views update in real time as systems engineers complete their work, eliminating the lag and errors inherent in status report generation.

Subsystem-Specific Engineering Views

Large aerospace and defense programs involve dozens of engineering teams working on different subsystems. Rather than each team maintaining separate requirement documents or model excerpts, Views enable subsystem-specific perspectives on a unified model. A propulsion team View filters requirements related to propulsion components, while an avionics View shows only avionics-related elements.

This approach eliminates the synchronization problems that plague traditional document-based requirements management. When a system-level requirement changes, all subsystem Views reflect the change immediately. When a subsystem engineer derives new requirements from system-level requirements, those new requirements appear in the appropriate subsystem Views without manual propagation or document reissue.

Verification and Validation Workflows

Quality and verification teams use Views to track verification coverage and status. A View might show all requirements with verification method "test" that lack associated test results, highlighting verification gaps. Another View might show requirements with failed verification results, enabling rapid identification and resolution of compliance issues.

Combined with SysGit's verification modeling capabilities (covered in separate documentation), Views provide end-to-end visibility into verification and validation workflows. Test engineers see the requirements they need to verify, program managers see verification status rollups, and certification authorities see compliance evidence, all from different Views of the same unified model.

Implementation Guidelines

Establishing Metadata Definitions

When implementing Views for your organization, start by identifying the workflow-relevant attributes that stakeholders need to filter on. Approval status and responsibility assignment are common starting points, but domain-specific attributes often provide the most value. An automotive organization might need safety integrity level (ASIL) attributes, while an aerospace organization might need criticality classifications.

Define metadata definitions at the appropriate scope in your model hierarchy. Package-level metadata definitions make the metadata available throughout that package and any nested packages. Standard libraries can define commonly-used metadata definitions, promoting consistency across programs and enabling cross-program views and reporting.

Designing View Hierarchies

Views work best when organized hierarchically from general to specific. Start with broad Views like "All Requirements" or "All Approved Items", then create increasingly specific Views like "Approved Requirements at Level 2" or "High-Risk Test Requirements". This progression helps stakeholders navigate from overview to detail without overwhelming them with too many View options.

Document the purpose and intended audience for each View, either in model comments or in separate guidance materials. Views named clearly and documented well reduce onboarding time for new team members and minimize confusion about which View supports which workflow need.

Maintaining Filter Expression Performance

While filter expressions in SysGit evaluate efficiently, overly complex expressions with many logical operators can impact performance on very large models. Test View performance with representative model sizes during implementation, and simplify expressions if evaluation becomes slow. Often, moving some filtering logic from View expressions into metadata attribute values (for example, computing a derived Boolean attribute rather than expressing complex logic in the filter) improves both performance and clarity.

Views and Git-Based Workflows

Version Control for View Definitions

View definitions are first-class model elements, subject to the same version control, branching, and merging as requirements, parts, and verifications. When a team experiments with new View filtering logic on a feature branch, those experimental Views remain isolated from the main branch until merged. This enables safe experimentation with stakeholder perspectives without disrupting ongoing work.

Git history for View definitions provides audit trails showing how filtering logic evolved over time. When stakeholders question why certain elements appear or disappear from Views, the Git history reveals the filter expression changes that caused the behavior shift, supporting transparent and traceable workflow management.

Cross-Repository View Considerations

In multi-repository architectures using Git submodules or similar mechanisms, Views defined in one repository can filter elements imported from other repositories, provided the metadata definitions are accessible across repository boundaries. This enables enterprise-wide Views that aggregate information from multiple program repositories, supporting portfolio management and cross-program dependencies.

Coordinate metadata definitions across repositories carefully to ensure consistency. Establishing standard metadata libraries in dedicated repositories that multiple programs import prevents metadata definition drift and ensures that Views work consistently across the enterprise.