Harmony相关资料整理

一、前言
系统工程的难点在于保障项目参与者的高效协作，“达成共识”是项目得以快速推进的基石，MBSE通过在建模语言、建模方法论、建模工具三个方面的统一、一致性确保了实现高效协作的可能性。
本文对个人在方法论相关的文章进行了汇总整理。

1. 相关书籍参考：《基于模型的系统工程方法论综述》
2. 一文读懂3种MBSE方法论

二、Harmony概述
因项目工作需要，后续主要基于Harmony方法论开展相关工作，下文主要摘录与Harmony相关内容。

1. Harmony概述
2. MBSE方法论之Harmony

相关问题总结：（以下内容来自知乎朝花“曦”拾：MBSE方法论之Harmony）

Q1：我们知道Harmony过程思想是一个基于功能的工程分析过程，那么在这一从需求图到活动图过程中，怎么确定一个很好的用例粒度？
       霍夫曼给我们的建议是“Don’t Give Engineer Time.”就是说尽可能的缩短SE工程师的用例分析时间，如1～2个礼拜，让各个SE工程师完成用例图的描述；使用例拆分人员处在一个紧迫状态中，这样一来，他们所描述的就是用户最关注的问题，也避免了用例太细，导致后期约束了SW阶段工程师的思想；其后再通过动态模型同用户或者内部人员进行确认，然后进入新的一次迭代。并明确指出，一个用例至少需要5个顺序图去描述。要是凑不够五个，那就说明这个用例有必要同其他用例合并整合。

Q2：怎么体现Harmony工程过程思想是基于功能的分析方法呢？具体体现在那些方面？
       Harmony方法的出发点是“场景”也就是用例，多个用例的整合成为一个或多个活动，活动图中存在很多动作，通过对活动图的细化完成动作到功能的对应；通过对再次细化后的活动图的泳道划分，实现功能到子系统的划分；完成功能到子系统的划分后，各个泳道之间存在信息流的交互，交互过程是一个调用过程，以此来完成功能到操作的对应。这就是Harmony场景驱动的主要过程。

Q3：怎么确定某一功能是内部功能还是外部功能，是功能性需求还是非功能性需求？
       在系统中，在用例图分析的系统边界以内的为内部功能；边界外，需要调用的，耦合度不高的叫外部功能。需要注意功能性需求同非功能性需求，在针对于不同场景下是可能发生变化的，如：一个巡航导弹导航系统是通过一个地面站来协助完成导航。我们要求导弹确认轨迹为5ms，这个要求针对导弹是功能性需求，而针对地面站是非功能性需求。

Q4：SE阶段需求、活动和功能细化分解的方法应该注意那些方面？
       在SE阶段需求的分解细化主要是通过特定的工程师去完成的。我们一般会通过三步三个问题，每步一个问题，去同负责该块的客户/SE工程师进行沟通。首先，“你觉得哪个部分需要再分解细化”？其次，“你认为哪个部分是最重要的” ？最后，“你认为如何分级分解比较合适”？通过以上三个问题，我们可以确定出用户/SE工程师的身份背景，有效定位工作内容。并通过多次向不同人员询问加权平均，确定各个部分的重要程度。最后，有计划的督导SE工程师或者用户进行分层级的系统需求细化分解过程。

Q5：怎么完成用例到系统架构的过渡？
       首先，将用例绑定或者划分到最初的系统Part上；进而，在完成活动图的过程中将功能划分到特定的子系统中去；最后，为每个用例构建一个状态机。

Q6：SE阶段到SW阶段在什么时候交接，都交接些什么？
       SE阶段到SW阶段的交接我们一般称为“White Point”白点，在这个白点Harmony思想中要求SE提交的模型必须是动态的。至于在什么时间或者什么阶段进行交接，并没有一个固定的要求。交接什么是根据具体项目有所不同，针对航空电子领域，除了系统架构的软、硬件架构设计方案外，最重要的就是ICD了。在国外，SE组提出的都是逻辑ICD（Logic ICD），在欧洲会有一个独立的团队介于SE组和SW组之间，进行Logic ICD到物理ICD（OperationICD）然后再将这部分的物理ICD提交给SW组；在美国，这个从Logic ICD到Operation ICD的转换过程是由SW组中相关人员去做的。SE人员不需要做数据包和协议上的设计。

Q7：用例描述中的顺序图同活动图生成的顺序图的关系是什么？
       用例描述的顺序图同状态图生成的顺序图是没有直接关系的。这儿的活动图，可能是一个或者多个用例的整合。一般情况下不会出现同用例发生一对一的情况。也就是说此处的活动图是以用例为基础，但并不是说用例同活动图存在某种本质的联系。