{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 kissjiangs 的文章《【Harmony】概述》','https://www.xiaopingtou.net/article-62170.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
原文来自本人的微信公众号文章 系统工程实验室
引言
基于模型的系统工程（简称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 System Engineering” 进行简要论述，即对需求分析、系统功能分析、设计综合进行简要说明，后续系列文章中会对各个阶段进行详细说明。 需求分析阶段 需求分析阶段的主要目标是对系统的输入需求进行分析，作为需求工程的一部分，需求分析一个非常大的范围，期内包含的诸多的活动、方法，在此不做详细论述。在Harmony的上下文中，对如下图所示的范围进行论述。
引自 Harmony SE handbook
在Harmony方法轮中，V模型包含需求分析、系统功能分析、设计综合、软件分析及设计、软件实现以及与之相对应的单元测试、模块集成及测试、（子）系统集成及测试、系统验收测试。涉众需求作为输入，会经过需求分析、系统功能分析、设计综合、软件分析设计、软件实现等阶段，各阶段的输入和输出都以模型的形式提现。同时，系统的演化以迭代的方式进行，系统的变更会触发新的迭代循环。例如新的需求的加入，会重新经历需求分析、系统功能分析......等其他阶段。除此之外，Harmony还引入了统一的配置仓储，用于支撑模型数据的存储及复用。
同样，从上图中还可以看出，Harmony将整个V模型阶段划分为两个松耦合的部分：
- Harmony for Systems Engineering：需求分析、系统功能分析、设计综合
- Harmony for Embedded Real TimeDevelopment：软件相关的分析、设计、实现及相应的验证
本文主要对 “Harmony for System Engineering” 进行简要论述，即对需求分析、系统功能分析、设计综合进行简要说明，后续系列文章中会对各个阶段进行详细说明。 需求分析阶段 需求分析阶段的主要目标是对系统的输入需求进行分析，作为需求工程的一部分，需求分析一个非常大的范围，期内包含的诸多的活动、方法，在此不做详细论述。在Harmony的上下文中，对如下图所示的范围进行论述。
-
输入：
- 涉众需求：涉众需求是从用户的角度描述系统的需求，包含用户对系统的功能需求和性能需求的期望。该层级的需求一般是比较零散的、不规范的。
-
输出
- 涉众需求规范：该需求是对涉众需求的规范化描述。基于客户输入的涉众需求，以及工程师所遵循的需求分析准则（如何）对涉众需求进行重新定义和整理，并生成理解一致的、清晰的、正确的、可验证的需求。
- 系统需求规范：系统需求规范是对涉众需求的工程化语言描述的转换，将从用户角度出发描述的需求转化为工程师角度的需求。
- 用例模型：模型是MBSE的主要交付物形式，用例模型是Harmony需求分析阶段的关键交付物。同时，Harmony要求对系统用例进行分组和优先级划分。
- 除了删除可见部分外，输出物还包含了模型间的关联关系，具体的是系统需求和涉众需求间的关联。用例模型和系统需求间的关联。
-
架构分析阶段
- 系统功能分析用于定义系统“做什么”，架构分析用于定义系统“如何做”。如何进行架构分析在Harmony有一套建议的工作流可供参考，后续会详细介绍。
-
架构设计阶段
- 架构设计阶段的重点是功能需求和非功能需求到架构结构的分配。
- 该阶段将用例相关的黑盒视图转化为白盒视图。