模块 6：OOSEM
面向对象的系统工程方法 — 从利益相关者需求分析到逻辑架构与物理架构，以家庭安防系统为贯穿案例。
OOSEM 的起源与理念
OOSEM — 面向对象的系统工程方法（Object-Oriented Systems Engineering Method）— 由 Sanford Friedenthal、Alan Moore 和 Rick Steiner 共同开发。他们也是广受认可的参考书 A Practical Guide to SysML 的作者。该方法的诞生源于一个认知：面向对象的思想已经深刻改变了软件工程，但系统工程领域还缺少一种能充分利用 SysML 等建模语言能力的、结构化的工程方法。
核心理念
OOSEM 将面向对象思想中的几个基本原则引入系统工程领域：
- 封装 — 每个系统元素通过定义良好的接口隐藏内部复杂性，使团队可以独立开发各子系统。
- 抽象 — 方法刻意将系统"做什么"（逻辑架构）与"怎么做"（物理架构）分离。这种分离是 OOSEM 最重要的核心概念。
- 层级与分解 — 系统被逐步分解为更小、更可管理的元素，每个元素都以与整体相同的严谨度进行建模。
- 复用 — 定义（类型）只需创建一次，可在多处实例化，从而保证模型的一致性。
OOSEM 的权威参考文献为：Friedenthal, S., Moore, A., & Steiner, R., A Practical Guide to SysML: The Systems Modeling Language（第三版，Morgan Kaufmann 出版）。该书将 OOSEM 与 SysML 一同介绍，但 OOSEM 本身是语言无关的 — 它可以配合任何系统建模语言使用。
为什么"面向对象"对系统工程很重要？
传统系统工程通常采用纯功能分解 — 先将系统拆分为功能，再将功能分配给组件。OOSEM 增加了面向对象的维度：系统同时被分解为拥有结构和行为的对象（逻辑实体）。这种功能加结构的双重视角，能够产生更模块化、更易追溯、需求变更时更容易演进的架构。
OOSEM 过程概述
OOSEM 将系统工程工作组织为五个主要活动。虽然以顺序方式呈现，但该过程本质上是迭代的 — 随着理解的深入，你会反复回到前面的活动。
- 分析利益相关者需求 — 识别谁关心这个系统，以及他们需要什么。以结构化的形式捕获需求。
- 定义系统需求 — 将利益相关者需求转化为精确的、可验证的系统需求，约束设计空间。
- 定义逻辑架构 — 基于功能将系统分解为逻辑子系统。这是"做什么"的视角，与技术选择无关。
- 综合候选物理架构 — 将逻辑功能映射到物理组件，生成多个候选方案。
- 优化与评估 — 进行权衡研究，根据需求和约束选出最佳候选架构。
OOSEM 是迭代的，而非严格顺序的。实践中，定义逻辑架构时往往会发现遗漏或模糊的需求，促使你回到第 2 步。同样，第 5 步的权衡研究可能揭示没有任何候选架构能满足所有需求，从而需要修改逻辑分解。请将这五个活动视为一个循环，而非瀑布。
贯穿案例：家庭安防系统
在后续各节中，我们将把 OOSEM 应用于一个家庭安防系统。该系统需要检测入侵、提醒房主，并可选择性地通知执法部门。它足够简单以适合教程，又足够丰富以展示 OOSEM 的每个活动。
利益相关者需求与需求分析
OOSEM 的第一个活动是理解谁关心这个系统，以及他们需要什么。这并非走形式 — 利益相关者需求是验证每个设计决策的最终真实来源。
识别利益相关者
对于家庭安防系统，关键利益相关者包括：
- 房主 — 主要用户，希望感到安全并在入侵发生时收到警报。
- 安保监控公司 — 7x24 小时监控警报并在必要时调度警方的组织。
- 安装人员/技术员 — 负责实际安装、配置和维护系统的人员。
捕获需求与推导系统需求
每个利益相关者都用自己的语言表达需求。系统工程师必须将这些需求翻译为正式的、可验证的需求。下表展示了我们案例中的映射关系：
| 利益相关者 | 需求 | 推导出的系统需求 |
|---|---|---|
| 房主 | 检测入侵 | 系统应在 2 秒内检测到通过任何门窗的未授权进入。 |
| 房主 | 提醒房主 | 系统应在检测到入侵后 5 秒内向房主的移动设备发送推送通知。 |
| 安保公司 | 通知警方 | 系统应在检测到入侵后 10 秒内向监控中心发送报警信号。 |
| 安保公司 | 可靠通信 | 系统应支持至少两个独立通信通道（如蜂窝网络和 Wi-Fi）。 |
| 安装人员 | 易于安装 | 对于标准三居室住宅，系统应可由一名技术员在 4 小时内完成安装。 |
| 安装人员 | 远程诊断 | 系统应提供可通过移动应用访问的诊断接口，用于故障识别。 |
将利益相关者需求分析想象成医生问诊。患者（利益相关者）说"我胸口疼"（需求）。医生将其翻译为精确的诊断和可衡量的检验标准 —"血压低于 140/90，心电图在正常范围内"（推导出的系统需求）。没有这种翻译，你就无法验证治疗方案（设计）是否真正有效。
逻辑架构
需求确定后，OOSEM 要求你设计逻辑架构 — 纯粹基于系统做什么来分解系统，而非基于物理实现方式。这是 OOSEM"关注点分离"理念的核心。
家庭安防系统的逻辑子系统
分析第 3 节的需求，我们可以识别出三个主要逻辑功能：
- 检测功能 — 负责感知未授权进入事件（门、窗、移动）。
- 警报功能 — 负责在检测到入侵时通知房主和监控公司。
- 控制功能 — 负责系统的布防/撤防、管理传感器状态，以及协调检测和警报功能。
注意，在这个阶段我们不提及摄像头、运动传感器、警报器或云服务器。我们只描述能力。检测功能负责检测；警报功能负责警报；控制功能负责协调。这是刻意为之的。
为什么要分离逻辑与物理？
逻辑架构充当稳定的骨架。物理技术会变化 — 今天的运动传感器明年可能被雷达模块取代 — 但"检测入侵"这一逻辑功能保持不变。通过先将需求锚定到逻辑功能，你可以确保：
- 需求追溯清晰 — 每个需求映射到逻辑功能，每个逻辑功能映射到一个或多个物理组件。
- 技术变更只影响物理层，而非整个架构。
- 多个候选物理架构可以在同一逻辑基线上进行评估。
逻辑 vs. 物理 — 石蕊测试：如果你发现自己在命名具体技术（如"PIR 传感器"、"AWS Lambda"、"Zigbee 无线电"），那你就已经进入了物理架构的领域。逻辑架构使用技术中立的语言："检测"、"通信"、"处理"。在综合物理候选方案之前，请保持两个层级的分离。
物理架构与权衡研究
逻辑架构确定后，OOSEM 的下一个活动是综合候选物理架构。这意味着将每个逻辑功能映射到具体的、可实现的组件 — 然后评估哪种组合最能满足需求。
从逻辑到物理的映射
对于家庭安防系统，"检测"逻辑功能可以通过多种物理技术实现：被动红外（PIR）运动传感器、门/窗磁接触传感器、带视频分析的安防摄像头，或它们的组合。同样，"警报"功能可以使用本地警报器、基于云的推送通知服务、直接连接监控中心的蜂窝链路，或三者兼用。
OOSEM 鼓励生成多个候选架构，然后进行权衡研究以选出最佳方案。下面是一个比较两个候选方案的简化权衡研究：
| 评估准则 | 权重 | 候选方案 A：仅传感器 | 候选方案 B：传感器 + 摄像头 |
|---|---|---|---|
| 检测准确性 | 30% | 良好 — PIR + 磁接触传感器覆盖入口点 | 优秀 — 摄像头增加视觉验证，减少误报 |
| 安装成本 | 25% | 低 — 传感器价格低廉且支持无线 | 中等 — 摄像头需要供电和定位 |
| 持续成本 | 15% | 低 — 带宽需求小，传感器电池供电 | 较高 — 视频存储和带宽成本 |
| 隐私影响 | 15% | 极小 — 无视频录制 | 中等 — 室内摄像头引发隐私顾虑 |
| 可扩展性 | 15% | 良好 — 易于增加更多传感器 | 良好 — 摄像头和传感器可独立扩展 |
| 加权总分 | 72 / 100 | 81 / 100 | |
在此示例中，候选方案 B 总分更高，因为检测准确性的提升（减少误报并实现视觉验证）超过了额外的成本和隐私考虑。权衡研究使决策依据明确且可追溯。
真实的权衡研究会包含定量评分、敏感性分析和利益相关者评审。上面的简化版本展示的是该活动的结构。在 OOSEM 中，权衡研究不是事后想法 — 它是一个正式的、有文档记录的决策关口，将物理架构与需求和利益相关者需求相关联。
OOSEM 总结与适用场景
OOSEM 提供了一种全面的、文档完备的方法，用于将面向对象思想应用于整个系统工程生命周期。让我们总结它的优势、劣势和理想使用场景。
优势
- 覆盖全面 — OOSEM 涵盖了从利益相关者需求到逻辑和物理架构，再到基于权衡研究进行选择的完整路径。
- 文档完备 — 该方法在 A Practical Guide to SysML 中有详尽描述，附有实例和模板。
- 语言无关 — 虽然最初与 SysML 一同介绍，但 OOSEM 的活动和产出物不绑定任何特定建模语言。它可以配合 SysML v1、SysML v2，甚至领域专用语言使用。
- 强追溯性 — 逻辑层与物理层的清晰分离创建了自然的追溯链：利益相关者需求 → 系统需求 → 逻辑功能 → 物理组件。
劣势
- 对小项目而言过于重量级 — 包含正式权衡研究的完整五活动过程对于小型系统或快速原型开发可能过于繁琐。
- 学习曲线 — 不熟悉面向对象概念的团队在初期可能难以掌握逻辑/物理分离。
- 对图表类型规定较少 — OOSEM 告诉你每个阶段需要产出什么，但对使用哪种图表类型的规定较少（不像 MagicGrid 规定了具体的视图矩阵）。
何时使用 OOSEM
OOSEM 最适合以下场景：
- 大规模复杂系统 — 逻辑架构与物理架构的分离在管理复杂性方面效益显著。
- 需要多个候选方案的项目 — 需要正式的权衡研究来论证架构决策。
- 首次采用 MBSE 的组织 — 书籍级别的参考资料和实例使其成为实用的入门通道。
- 多学科团队 — 在进入物理设计之前，需要一个共享的、技术中立的框架。