MBSE中对能力建模

基于模型的系统工程（MBSE）作为一种方法并不直接涉及能力，它描述了系统实现或执行任务或使命的能力。作为问题描述的一部分，能力与系统需求有很强的联系，可以使用类似的方法进行建模。

能力是一个广泛应用的术语。有来自业务架构领域的业务能力和技术能力，有来自系统开发过程领域的解决方案能力，如规模化敏捷框架（SAFe），还有来自DoDAF/MODAF统一概要（UPDM）或统一架构框架（UAF）的能力。这些定义基本上分为两类：（1）描述系统实现或执行任务或使命的能力的高级概念；（2）描述特定业务问题解决方案的技术概念。在这篇博客文章中，将重点介绍第一类能力，这是一个高级概念，将称之为能力。

产品或项目经理在考虑系统的愿景和路线图时，通常会考虑未来或现有系统的能力。在缺乏实施细节的情况下，能力提供了一个全面的图景。与需求一样，能力也是问题描述的要素。能力和需求是紧密相连的，它们相互补充和完善。业务专家通常通过首先回答以下问题来定义业务流程的各个阶段：系统应该能够做什么？从那里，这些能力显现出来。

例如，M.Maier在其1998年的文章《系统体系结构原理》中，将智能交通系统（ITS）描述为系统体系的一个例子。正如梅尔所说，这种系统的商业愿景是：

• 为任何地点的旅行者提供“有关图形条件和交通选项的实时信息”
• “允许旅行者扫描交通状况并选择预测最短旅行时间的交通模式”
• “允许使用从可用信息中优化的策略在大都市地区应用广泛的交通控制策略
• 使用“可能包括整个交通网络中链路时间的实时和预测估计”的信息
• 使用可能包括“驾驶员起点-终点和计划路线的实时统计数据”的信息

从这个业务愿景中，可以提取出几个能力，包括：

• 旅行者管理
• 旅行条件管理
• 交通控制管理
• 信息管理
• 路线管理
• 交通控制策略管理和优化
• 通信管理
  

MBSE明确地提供了一种建模需求的方法，但不提供作为元素类型的能力。 有一个业务需求元素可用于对系统的能力进行建模，如下图1所示。

图1：作为能力的业务需求示例

与系统工程中的许多高级元素一样，能力需要分解。有的文章指出，最多可以有五个级别的能力，级别的数量取决于系统的大小和复杂性。复杂的系统系统可能需要所有五个级别加上一个子级别。图2中的示例仅使用三个级别的能力分解，并调用这些级别的类别。能力可以基于其他原则来组织，例如功能领域或企业结构。 使用包结构、自定义模板和颜色编码可以帮助系统工程师和业务或企业架构师更好地组织能力分解。

图2：用包组织能力示例

如果使用包结构来组织系统的能力，则派生关系显示了来自不同包的能力的分解，如图3所示。对于不同类别的视觉标记功能，自定义原型可能会有所帮助。

图3：自定义构造型的能力分解示例

如图4所示，定制构造型、颜色编码和父子关系的组合也可以组织能力，而无需将它们分成不同的包。

图4：使用颜色编码的能力分解示例

能力的一个作用是覆盖企业或系统所做的事情，而不需要分解成细节。包括功能或约束的用户视图的详细信息来自需求。一个好的模型应该提供能力和需求之间的联系。不用推导表示为业务需求的能力与其他需求之间的关系，可以使用更松散的跟踪关系，如图5所示。

图5：能力到需求的可追溯性示例

将能力与需求联系起来，在两种不同类型的概念问题描述之间建立了重要的联系，有助于管理系统的复杂性。 通过保持高抽象级别，能力允许架构师规划系统演进的各个阶段，而无需记住许多细节。如果这些细节被捕获为需求并追踪到相应的能力，那么它们将不会丢失。

能力和需求之间有一个关键的区别：需求来自不同的来源，由不同的利益相关者赞助，通常在不同的抽象级别捕获。相反，能力应始终代表系统或企业的一致和统一视图。

在它们被捕获和分解之后，必须分析能力。 一种类型的分析是确定能力之间的依赖关系。 即使两个能力可以属于系统的两个不同区域，但一个可以依赖于另一个，如下图6所示。依赖关系的性质也可能不同。由于业务流程、操作顺序或数据传递，一种能力在功能上可能依赖于另一种能力。

图6：能力依赖关系示例

另一方面， 一种能力可以是使用系统现有功能的另一种能力的扩展。 这些能力应该按照适当的顺序开发，如下图7所示。依赖关系捕获模型中的这些基本信息，并确保将其交付到系统开发生命周期的下一阶段。

图7：用于捕获开发依赖的能力依赖关系示例

能力本身不足以理解系统或企业将如何运作。必须通过解释系统展示这些能力时的行为来增强描述。即使停留在高抽象级别，也需要在该级别分析系统或企业的行为。系统建模语言（SysML）活动图是一种以流程形式捕获行为的方法。用于关联能力和活动的关系被细化，如下图8所示。

图8：能力与活动之间的关系示例

作为能力分析的一部分，架构师通常开始考虑系统或模块的一部分来执行分析中的能力，以及用户和人类在与系统交互或作为组织的一部分时将扮演的角色。这里，活动和块SysML元素可能会有所帮助，如下图9所示。

图9：执行者、角色和过程的能力示例

当企业架构师完成能力的分解和分析时，下一个逻辑步骤是为能力开发和发布创建路线图，包括能力的阶段化。为此，SysML不提供任何专用工具。模型捕获的所有关系以及标准分析将帮助架构师找到交付能力和定义路线图的关键路径，如下图10中的示例所示。

图10：路线图分析示例

观察结果和结论

SysML在支持组织和组合架构方面存在一些不足，可以通过架构框架加以克服：

• SysML默认不支持能力。
• 架构师需要创建额外的原型和强制机制来适应能力。
• SysML不支持为能力创建路线图，包括随时间进行规划。

理论上，经验丰富的企业架构师可以创建一个定制的元模型，以在某种程度上实现标准架构框架之一，例如开放式集团架构框架（TOGAF）或国防部架构框架（DoDAF）/统一架构框架（UAF），只使用SysML。 然而，这样做会很耗时，而且几乎不会产生有用的结果。 如果没有难以创建的复杂模型验证规则，这样的元模型将是复杂的，难以实现和遵循，也难以实施。更好的选择是查看现有的SysML扩展，这些扩展实现了所选择的架构框架。MBSE/SysML建模环境的所有主要提供商都支持最流行的架构框架。

使用MBSE的建模功能解决了构建系统体系的几个关键方面。能力建模通过抽象系统的特定特性，帮助系统工程师管理需求的复杂性和数量。这种抽象级别也有助于利益相关者之间的沟通，并有助于创建项目路线图。通过帮助产生分析和理解良好的能力，建模支持创建更好的系统和企业架构。MBSE实践支持能力对需求的可追溯性，以及能力对操作和逻辑架构（从解决方案架构过渡到解决方案架构）的可追溯。增强的可追溯性提高了系统的质量，并确保了系统将按照要求构建的信心。

From：Modeling Capabilities with Model-Based Systems Engineering (MBSE) (cmu.edu)