一、前言
系统工程的难点在于保障项目参与者的高效协作,“达成共识”是项目得以快速推进的基石,MBSE通过在建模语言、建模方法论、建模工具三个方面的统一、一致性确保了实现高效协作的可能性。
本文对个人在方法论相关的文章进行了汇总整理。
- 相关书籍参考:《基于模型的系统工程方法论综述》
- 一文读懂3种MBSE方法论
二、Harmony概述
因项目工作需要,后续主要基于Harmony方法论开展相关工作,下文主要摘录与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:用例描述中的顺序图同活动图生成的顺序图的关系是什么?
用例描述的顺序图同状态图生成的顺序图是没有直接关系的。这儿的活动图,可能是一个或者多个用例的整合。一般情况下不会出现同用例发生一对一的情况。也就是说此处的活动图是以用例为基础,但并不是说用例同活动图存在某种本质的联系。