Harmony概述
引言
基于模型的系统工程（简称MBSE，英文全称Model based System Engineering ）的实践至少需要三个维度的支撑：建模语言、建模方法论和建模工具。建模语言为模型的表述提供了统一的支撑，建模方法论为建模的行为提供了更为一致的准则，建模工具为建模的实现提供了更为自动化的支撑。今天要讨论的主题 “IBM Rational Harmony” 正是MBSE建模方法论之一。
IBM Rational Harmony 架构
Harmony全称为 “Rational Integrated Systems / Embedded Software Development Process Harmony ” ，Harmony的整体架构如下图所示。与经典的系统V模型类似，左侧“下降沿”表示为系统分解，右侧的“上升沿”表示为系统侧层层验证。
引自 Harmony SE handbook
在Harmony方法轮中，V模型包含需求分析、系统功能分析、设计综合、软件分析及设计、软件实现以及与之相对应的单元测试、模块集成及测试、（子）系统集成及测试、系统验收测试。涉众需求作为输入，会经过需求分析、系统功能分析、设计综合、软件分析设计、软件实现等阶段，各阶段的输入和输出都以模型的形式提现。同时，系统的演化以迭代的方式进行，系统的变更会触发新的迭代循环。例如新的需求的加入，会重新经历需求分析、系统功能分析......等其他阶段。除此之外，Harmony还引入了统一的配置仓储，用于支撑模型数据的存储及复用。
同样，从上图中还可以看出，Harmony将整个V模型阶段划分为两个松耦合的部分：
-
Harmony for Systems Engineering：需求分析、系统功能分析、设计综合
-
Harmony for Embedded Real TimeDevelopment：软件相关的分析、设计、实现及相应的验证
Harmony for Systems Engineering
本文主要对 “Harmony for System Engineering” 进行简要论述，即对需求分析、系统功能分析、设计综合进行简要说明，后续系列文章中会对各个阶段进行详细说明。
需求分析阶段
需求分析阶段的主要目标是对系统的输入需求进行分析，作为需求工程的一部分，需求分析一个非常大的范围，期内包含的诸多的活动、方法，在此不做详细论述。在Harmony的上下文中，对如下图所示的范围进行论述。
-
输入：
-
涉众需求：涉众需求是从用户的角度描述系统的需求，包含用户对系统的功能需求和性能需求的期望。该层级的需求一般是比较零散的、不规范的。
-
输出
-
涉众需求规范：该需求是对涉众需求的规范化描述。基于客户输入的涉众需求，以及工程师所遵循的需求分析准则（如何）对涉众需求进行重新定义和整理，并生成理解一致的、清晰的、正确的、可验证的需求。
-
系统需求规范：系统需求规范是对涉众需求的工程化语言描述的转换，将从用户角度出发描述的需求转化为工程师角度的需求。
-
用例模型：模型是MBSE的主要交付物形式，用例模型是Harmony需求分析阶段的关键交付物。同时，Harmony要求对系统用例进行分组和优先级划分。
-
除了删除可见部分外，输出物还包含了模型间的关联关系，具体的是系统需求和涉众需求间的关联。用例模型和系统需求间的关联。
系统功能分析阶段
系统功能分析阶段主要目标是将需求分析阶段产生的功能性的系统需求转化为更加精确的系统描述。该阶段是用例驱动的，每个用例都会被分析，并产生可执行的模型，模型通过执行的方式进行验证。
该阶段基于每个用例，会对其设计相应的黑盒活动图、黑盒序列图以及黑盒的状态机图。
设计综合阶段
设计综合阶段的目标是系统物理机构的开发，该架构需要满足性能需求前提下保证系统功能需求的实现。设计综合阶段包括架构分析和架构设计两个阶段。
-
架构分析阶段
-
系统功能分析用于定义系统“做什么”，架构分析用于定义系统“如何做”。如何进行架构分析在Harmony有一套建议的工作流可供参考，后续会详细介绍。
-
架构设计阶段
-
架构设计阶段的重点是功能需求和非功能需求到架构结构的分配。
-
该阶段将用例相关的黑盒视图转化为白盒视图。
小结
Harmony是支持MBSE的建模方法论之一，其定义了基于模型的系统工程的建模工作流和典型模型输出物。整个方法论基于系统V模型展开，系统模型贯穿系统研发的整个生命周期。
关于每个阶段的详细工作流及最佳实践会在后续文章总给出，请关注“系统工程实验室”微信订阅号。
