模块八:变体与配置
如何在一个统一模型中描述产品家族的多种变体——使用 variation、variant、选项与配置机制——以及这些概念如何映射到 KerML 的类型系统。
KerML → SysML:变体建模概念对应关系
SysML v2 的变体机制建立在 KerML 的类型系统之上。variation 不是独立的元模型元素,而是通过特化(specialization)和重定义(redefinition)在已有类型系统上的约束应用。每一个变体选项本质上都是父定义的一个特化子类型。
| SysML v2 概念(L2) | 底层 KerML 构件(L1) | SysML 额外添加了什么 |
|---|---|---|
variation 修饰符 | 标记为"抽象"的 Usage | 表明该用法有多个可选变体,运行时恰好选择一个 |
variant | 特化父 Usage 的子 Usage | 每个 variant 是一个可选配置项,由约束或配置选择 |
配置(usage 选择) | Redefinition(重定义某个 variation 的绑定) | 在特定产品配置中,将 variation 绑定为某一个 variant |
variant part | 特化并重定义父 Feature | 用于结构部件的变体选择 |
variant attribute | 特化并重定义父 Feature(DataType 类型化) | 用于属性值的变体选择 |
variant action | 特化并重定义父 Feature(Behavior 类型化) | 用于行为的变体选择 |
约束过滤(filter) | ConstraintUsage | 限定哪些 variant 组合是合法的 |
在 KerML 中,变体并非专门的元类。它是对已有类型系统机制(特化、重定义、抽象)的语义约束应用。SysML v2 引入 variation 和 variant 关键字,以便建模者用简洁的语法表达产品家族的可选性。
变体概述
KerML 来源:variation → 抽象 Usage(Abstract Feature)
在系统工程中,一个产品家族通常包含多种变体——同一基础设计的不同版本。例如,一辆汽车可能有汽油版和电动版,同一型号的传感器可能有高精度和标准精度之分。SysML v2 通过 variation 机制在同一个模型中捕获所有这些选项,而不是维护多个独立模型。
想象一家餐厅的菜单:每道菜是一个「变体点」(variation point),比如主食可以选择米饭、面条或面包。你点餐时做出的选择就是一个「配置」(configuration)——你不需要整个菜单都做出来,只需选定每个选项即可。
为什么需要变体建模
- 复用:共享的部分只建模一次,变化的部分用 variant 表示
- 一致性:所有变体共享同一个基础架构,避免模型间不一致
- 可追溯性:每个配置决策都有明确的模型痕迹
- 自动化:工具可以根据约束自动排除不合法的组合
核心术语
| 术语 | 含义 |
|---|---|
| 变体点(variation point) | 模型中需要做选择的位置,用 variation 标记 |
| 变体选项(variant) | 某个变体点的一个可选值,用 variant 声明 |
| 配置(configuration) | 对所有变体点做出选择后得到的具体产品实例 |
变体用法与选项
KerML 来源:variant → 特化父 Usage 的子 Feature
使用 variation 修饰符标记一个用法(usage)为变体点,然后用 variant 声明该变体点的各个选项。每个 variant 在类型系统中是父用法的一个特化。
部件变体
1 part def Vehicle {
2 // 变体点:动力总成可选择不同类型
3 variation part powertrain : Powertrain {
4 variant part ice : ICEPowertrain; // 内燃机
5 variant part ev : EVPowertrain; // 纯电动
6 variant part hybrid: HybridPowertrain; // 混合动力
7 }
8 }
上述代码声明了一个名为 powertrain 的变体点,提供三个选项。在任意具体的 Vehicle 实例中,powertrain 必须恰好绑定为其中之一。
属性变体
1 part def Sensor {
2 // 变体点:精度等级
3 variation attribute accuracy : AccuracyLevel {
4 variant attribute standard : StandardAccuracy;
5 variant attribute high : HighAccuracy;
6 }
7 }
行为变体
1 action def Navigate {
2 // 变体点:导航算法
3 variation action algorithm : NavAlgorithm {
4 variant action astar : AStarNav; // A* 算法
5 variant action dijkstra: DijkstraNav; // Dijkstra 算法
6 }
7 }
variation 可以应用于 part、attribute、action、port 等任何用法类型。每个 variant 必须与变体点的类型兼容(即为其特化或子类型)。
不要将 variation 与 abstract 混淆。abstract 表示该定义不能直接实例化,但不限制子类型数量。variation 表示运行时恰好选择一个 variant,且变体选项是显式枚举的。
配置定义
KerML 来源:配置 → 通过 Redefinition 将 variation 绑定为特定 variant
配置(configuration)是对一个产品家族模型中所有变体点做出具体选择的结果。在 SysML v2 中,配置通过特化父定义并重定义其变体点来实现。
基本配置
1 // 产品家族定义
2 part def Vehicle {
3 variation part powertrain : Powertrain {
4 variant part ice : ICEPowertrain;
5 variant part ev : EVPowertrain;
6 variant part hybrid : HybridPowertrain;
7 }
8 variation attribute market : MarketRegion {
9 variant attribute cn : ChinaMarket;
10 variant attribute eu : EUMarket;
11 variant attribute us : USMarket;
12 }
13 }
14
15 // 配置:中国市场纯电动版
16 part def VehicleCN_EV :> Vehicle {
17 part powertrain redefines Vehicle::powertrain = ev;
18 attribute market redefines Vehicle::market = cn;
19 }
产品家族定义就像汽车官网上的「车型配置器」:你可以看到所有可选项。当你最终下单时,你选择了具体的发动机、颜色、内饰——这就是一个配置。模型中的 redefines 就相当于你在配置器中做出的每一个选择。
部分配置
并非所有变体点都必须在同一个特化中全部绑定。你可以创建部分配置,只绑定一部分变体点,将其余选择留给更下层的特化:
1 // 部分配置:先确定市场,动力总成留给后续选择
2 part def VehicleCN :> Vehicle {
3 attribute market redefines Vehicle::market = cn;
4 // powertrain 仍然是 variation,尚未绑定
5 }
6
7 // 完全配置:中国市场 + 混合动力
8 part def VehicleCN_Hybrid :> VehicleCN {
9 part powertrain redefines Vehicle::powertrain = hybrid;
10 }
部分配置在大型产品线中非常有用。它允许按阶段逐步缩小选项范围——例如先确定市场法规要求,再确定动力平台,最后确定内饰选项。
约束与规则
KerML 来源:约束过滤 → ConstraintUsage
并非所有变体组合都是合法的。例如,电动版可能不支持某些低成本内饰,某些传感器只在高端市场可用。SysML v2 通过约束来限定合法的变体组合。
变体间约束
1 part def Vehicle {
2 variation part powertrain : Powertrain {
3 variant part ice : ICEPowertrain;
4 variant part ev : EVPowertrain;
5 }
6 variation part interior : Interior {
7 variant part basic : BasicInterior;
8 variant part premium : PremiumInterior;
9 }
10
11 // 约束:电动版必须搭配高端内饰
12 assert constraint evRequiresPremium {
13 powertrain == ev implies interior == premium
14 }
15 }
使用 require constraint 过滤
1 part def Vehicle {
2 variation attribute batteryCapacity : BatterySize {
3 variant attribute small : SmallBattery; // 40 kWh
4 variant attribute medium : MediumBattery; // 60 kWh
5 variant attribute large : LargeBattery; // 100 kWh
6 }
7
8 // 内燃机版不需要电池选项
9 require constraint batteryOnlyForEV {
10 powertrain == ice implies batteryCapacity == null
11 }
12 }
约束只声明合法组合,不会自动替你做出选择。如果你创建了一个配置但违反了约束条件,工具应当报告一致性错误。约束是验证规则,不是推导规则。
将变体约束集中放在产品家族定义中,而不是分散在各个配置里。这样当产品线规则变化时,只需修改一处。
特化与变体继承
KerML 来源:特化 → Specialization(类型层次关系)
变体机制与 SysML v2 的特化系统紧密集成。当你特化一个包含 variation 的定义时,所有的变体点和选项都会被继承。你可以在子类型中:
- 绑定变体点(选定一个 variant)
- 缩小变体选项(移除某些不适用的 variant)
- 添加新的变体点(扩展产品线)
缩小变体选项
1 part def Vehicle {
2 variation part powertrain : Powertrain {
3 variant part ice : ICEPowertrain;
4 variant part ev : EVPowertrain;
5 variant part hybrid : HybridPowertrain;
6 }
7 }
8
9 // 城市车型:只提供电动和混合动力
10 part def CityVehicle :> Vehicle {
11 variation part powertrain redefines Vehicle::powertrain {
12 variant part ev : EVPowertrain;
13 variant part hybrid : HybridPowertrain;
14 // ice 选项被移除
15 }
16 }
添加新变体点
1 // 高端车型:继承所有选项,新增自动驾驶等级变体
2 part def PremiumVehicle :> Vehicle {
3 variation attribute autoLevel : AutonomyLevel {
4 variant attribute l2 : Level2;
5 variant attribute l3 : Level3;
6 variant attribute l4 : Level4;
7 }
8 }
变体的继承遵循 KerML 的特化语义:子类型的实例集是父类型实例集的子集。缩小变体选项就是进一步约束这个子集。反之,你不能在子类型中添加父类型没有的 variant 到已有的 variation point——那将扩大实例集,违反特化语义。但你可以添加新的 variation point。
完整示例
以下模型展示了一个完整的智能家居设备产品家族,综合运用部件变体、属性变体、变体约束和多级配置。
1 package SmartHomeProductLine {
2 private import ScalarValues::*;
3
4 // ── 基础定义 ─────────────────────────────────────────
5 part def WifiModule;
6 part def BluetoothModule;
7 part def ZigbeeModule;
8 part def BasicProcessor;
9 part def AIProcessor;
10 part def StandardCamera;
11 part def HDCamera;
12
13 // ── 产品家族定义 ─────────────────────────────────────
14 part def SmartHub {
15 // 变体点 1:通信模块
16 variation part comms : CommsModule {
17 variant part wifi : WifiModule;
18 variant part bluetooth : BluetoothModule;
19 variant part zigbee : ZigbeeModule;
20 }
21
22 // 变体点 2:处理器
23 variation part processor : Processor {
24 variant part basic : BasicProcessor;
25 variant part ai : AIProcessor;
26 }
27
28 // 变体点 3:摄像头(可选)
29 variation part camera [0..1] : Camera {
30 variant part stdCam : StandardCamera;
31 variant part hdCam : HDCamera;
32 }
33
34 // 变体点 4:目标市场
35 variation attribute region : MarketRegion {
36 variant attribute cn : ChinaRegion;
37 variant attribute eu : EURegion;
38 variant attribute us : USRegion;
39 }
40
41 // ── 变体约束 ────────────────────────────────────
42 // HD 摄像头需要 AI 处理器
43 assert constraint hdNeedsAI {
44 camera == hdCam implies processor == ai
45 }
46 // 中国市场必须支持 Zigbee
47 assert constraint cnNeedsZigbee {
48 region == cn implies comms == zigbee
49 }
50 }
51
52 // ── 配置 1:中国市场基础版 ───────────────────────────
53 part def SmartHub_CN_Basic :> SmartHub {
54 part comms redefines SmartHub::comms = zigbee;
55 part processor redefines SmartHub::processor = basic;
56 part camera redefines SmartHub::camera = stdCam;
57 attribute region redefines SmartHub::region = cn;
58 }
59
60 // ── 配置 2:欧洲市场高端版 ───────────────────────────
61 part def SmartHub_EU_Premium :> SmartHub {
62 part comms redefines SmartHub::comms = wifi;
63 part processor redefines SmartHub::processor = ai;
64 part camera redefines SmartHub::camera = hdCam;
65 attribute region redefines SmartHub::region = eu;
66 }
67 }
这个模型展示了:多个变体点(通信、处理器、摄像头、市场)、变体约束(HD 摄像头需要 AI 处理器、中国市场需要 Zigbee)、可选变体(摄像头多重性 [0..1])以及完整配置(将所有变体点绑定为具体选项)。
本模块总结
| SysML v2 概念 | KerML 来源 | 关键规则 |
|---|---|---|
variation | 抽象 Usage | 标记某个用法为变体点;运行时恰好选择一个 variant |
variant | 特化父 Usage 的子 Feature | 每个选项必须与变体点的类型兼容 |
配置(redefines) | Redefinition | 通过重定义将变体点绑定为具体选项 |
| 部分配置 | 部分 Redefinition | 只绑定部分变体点,其余留给下层特化 |
| 变体约束 | ConstraintUsage | 限定合法的变体组合;是验证规则,不是推导规则 |
| 缩小选项 | 重定义 variation 并减少 variant | 子类型可移除不适用的选项,但不能添加到已有变体点 |
| 添加变体点 | 子类型中声明新 variation | 扩展产品线的可选维度 |