3. 模型质量属性体系

在SysML建模中，“模型质量”并不是一个单一指标，而是一组相互制约、需要权衡的属性集合。一个模型可能语法完全正确，却遗漏了关键需求；也可能内容完整，却因命名混乱而难以维护。因此，质量工程的第一步是建立质量属性体系：明确每个属性“是什么、怎么度量、优先级如何”，才能在评审、验证和重构时有据可依。

七个核心质量属性的定义与度量维度

完整性（Completeness）指模型是否覆盖了所有已识别的需求、接口、行为和约束。度量维度包括：需求覆盖率（被至少一个模型元素追溯到的需求数 / 总需求数）、接口完备率（已定义端口与流属性的接口数 / 应定义接口数）、行为覆盖度（每个用例或功能是否都有活动图或状态机描述）。完整性关注“有没有”，不关注“对不对”。

正确性（Correctness）指模型是否准确表达了系统真实语义，且内部无逻辑矛盾。度量维度包括：语法错误数、类型匹配错误数（如流属性方向与端口方向冲突）、约束可满足性（OCL或参数图约束是否存在解）、仿真结果与预期偏差。正确性通常通过工具静态检查和仿真验证来度量。

一致性（Consistency）指不同视图、不同层级之间是否相互吻合。例如，块定义图（BDD）中的部件在内部块图（IBD）中是否都有对应实例；状态机中的事件是否在接口中定义；需求图中的“满足”关系是否与参数图中的约束一致。度量维度包括：跨图引用一致率、命名一致率、类型一致率、冗余定义数。

可理解性（Understandability）指模型是否易于被他人阅读和理解。度量维度包括：命名规范性（是否采用统一术语表）、图元密度（单图元素数量是否超过可读阈值，如30个）、注释覆盖率、层次深度（嵌套层级是否超过5层）、图类型选择是否恰当。可理解性直接影响评审效率和知识传递成本。

可维护性（Maintainability）指模型在需求变更或设计演进时，修改的难易程度和影响范围。度量维度包括：耦合度（跨包引用数量）、内聚度（单个包内元素职责集中度）、变更影响范围（修改一个元素需同步修改的元素数）、模型元素复用率。可维护性差的模型，一处修改可能引发数十处不一致。

可追溯性（Traceability）指模型元素之间是否建立了明确、可导航的追溯链路。度量维度包括：追溯链完整率（从需求到设计到测试的链路是否完整）、追溯粒度（是否细化到具体操作或参数）、双向追溯能力（正向和反向是否都可查询）。可追溯性是变更影响分析和合规审查的基础。

可复用性（Reusability）指模型元素能否被其他项目或模块直接引用。度量维度包括：库化程度（是否封装为可复用库）、参数化程度（是否通过值属性或绑定连接器实现可变配置）、接口标准化程度、文档完备率。可复用性高的模型能显著降低新项目建模成本。

质量属性的优先级与权衡

七个属性并非同等重要，优先级取决于项目阶段和系统类型。在安全关键系统（如航空、医疗）中，正确性和可追溯性通常最高，因为错误可能导致灾难性后果，且需满足DO-178C等标准审查。在快速迭代的产品开发中，可理解性和可维护性可能优先，以便团队快速响应变更。在平台化产品中，可复用性权重上升。

需要强调的是，质量属性之间存在权衡关系。例如，过度追求完整性可能导致模型臃肿，反而降低可理解性；过度追求可复用性可能引入过多抽象层，增加理解成本。因此，实际工程中应设定质量门限：例如“需求覆盖率≥95%”“跨图引用一致率=100%”“单图元素数≤30”“追溯链完整率≥90%”，并在每个迭代评审中检查。

质量门限与检查表示例

将上述属性转化为可执行的质量门限，是模型质量工程落地的关键。以下是一份可直接用于评审的检查表示例，适用于中等规模嵌入式系统项目：

属性之间的典型冲突与处理策略

理解属性间的冲突，有助于在评审中做出合理取舍。例如，某团队为提升可复用性，将大量通用行为封装为库活动，导致活动图层次过深、可理解性下降。处理策略是：为库活动提供清晰的命名和注释，并在主图中使用“引用”而非展开，同时限制嵌套层级不超过4层。又如，为追求完整性而将每个需求都追溯到具体操作，导致追溯链过于细碎、可维护性降低。此时可设定追溯粒度规则：功能级需求追溯到活动图，性能级需求追溯到参数图，接口需求追溯到端口定义。