textual-notation-of-model/packages/methods/de4sdv/de4sdv_method_concerns_and_viewpoints.sysml

Source

1/*2 * DE4SDV reusable method-governance concern and viewpoint kernel.3 *4 * This package contains only DE4SDV-specific method-governance viewpoints5 * that are not part of GfSE SAF. SAF viewpoints are in the separate6 * SAF_Viewpoints package.7 *8 * Method-governance viewpoints (increment framing, product-line9 * classification, regulatory scope) address DE4SDV workflow concerns:10 * increment boundaries, product-line classification discipline, and11 * regulatory visibility without compliance claims. These do not map to12 * any published SAF viewpoint.13 *14 * Note: this package uses a distinct top-level package name instead15 * of nested `DE4SDV::Methods::*` because the current SysIDE validation path16 * reports repeated top-level `DE4SDV` package declarations as shadowed rather17 * than namespace-merged across files.18 */1920package DE4SDV_MethodViewpoints {21  private import Views::*;2223  concern def ProductLineCapabilityClassificationConcern {24    require constraint {25      doc /*26       * Reviewers need model content to distinguish common product-line27       * capabilities from features, candidate features, variability decisions, and28       * deferred variability decisions.29       */30    }31  }3233  concern def RegulatoryScopeWithoutComplianceClaimConcern {34    require constraint {35      doc /*36       * Reviewers need regulatory anchors, source assumptions, missing evidence,37       * and scope boundaries to be visible without implying compliance,38       * certification, or type approval.39       */40    }41  }4243  concern def IncrementBoundaryConcern {44    require constraint {45      doc /*46       * Reviewers need each increment to separate framing, operational context,47       * needs, requirements, functional modeling, logical realization,48       * physical/software realization, and evidence work.49       */50    }51  }5253  concern def MethodStackConcern {54    require constraint {55      doc /*56       * Reviewers need the relationship between viewpoint selection, method flow,57       * ontology terms, SysML v2 expression, and external catalog use to remain58       * explicit rather than collapsed into one method blob.59       */60    }61  }6263  concern def ProductLineConfigurationConcern {64    require constraint {65      doc /*66       * Reviewers need the native SysML v2 variation and variant structure67       * in the model to be visible for review, so that configured choices68       * can be checked against the feature catalogue and bill-of-features.69       */70    }71  }7273  concern def ProductModelAssemblyConcern {74    require constraint {75      doc /*76       * Reviewers need a composite product model's assembly of shared assets77       * (platform stack, sensing, feature realization) and its product-level78       * trace links to be visible for review, so that the composition can be79       * checked for completeness and correctness against the selected80       * configuration.81       */82    }83  }8485  viewpoint def IncrementFramingViewpoint {86    require constraint {87      doc /*88       * An increment framing view shall show the selected stakeholder89       * concerns, system layers, method-stack elements, scope boundary,90       * deferred scope, and decision guardrails for the current increment.91       */92    }93  }9495  viewpoint def ProductLineClassificationViewpoint {96    require constraint {97      doc /*98       * A product-line classification view shall separate common product-line99       * capabilities from features, candidate features, variability decisions, and100       * deferred variability decisions before downstream functional modeling101       * starts.102       */103    }104  }105106  viewpoint def RegulatoryScopeViewpoint {107    require constraint {108      doc /*109       * A regulatory-scope view shall identify regulatory anchors, source110       * assumptions, scope boundaries, and missing evidence while explicitly111       * avoiding unearned compliance, certification, or type-approval claims.112       */113    }114  }115116  viewpoint def ProductLineConfigurationViewpoint {117    require constraint {118      doc /*119       * A product-line configuration view shall expose native SysML v2120       * variation and variant elements in the model so that configured121       * choices can be reviewed against the feature catalogue and122       * bill-of-features. The view frames the variation structure; the123       * YAML feature model and bill-of-features remain the source of124       * truth for configuration decisions.125       */126    }127  }128129  viewpoint def ProductModelAssemblyViewpoint {130    require constraint {131      doc /*132       * A product-model assembly view shall expose how a composite product133       * model assembles shared assets (platform stack, sensing, feature134       * realization) and its product-level trace links, so that the135       * composition can be reviewed for completeness and correctness136       * against the selected configuration. The view frames the assembly137       * and trace structure; the bill-of-features and generated projections138       * remain the source of truth for variant selection.139       */140    }141  }142143  /*144   * Reusable view definitions are intentionally not added yet. A `view def`145   * should define a reusable view-construction recipe with filters, rendering,146   * or composition logic. The current AEBS pilot only needs concrete `view`147   * usages that expose feature-package content and render it for review.148   */149}