《基于模型的系统工程最佳实践》- 读书笔记（一）

总结构：
       第一章至第二章：《基于模型的系统工程最佳实践》- 读书笔记（一）
       第三章相关笔记：Rhapsody项目结构
       第四章：《基于模型的系统工程最佳实践》- 读书笔记（二）

一、前言
       在摸索应用Rhapsody的过程中目前遇到的最大问题是可供参考学习的资料相对稀缺，面对的更多的可能是少的可怜的samples或前人已经做好的工程、模型，但已建成的工程中眼花缭乱的文档结构及各种看似熟悉但又陌生的图表，潜意识还是急切的想知道其具体的实现过程，包括哪些是系统自动生成的，哪些是使用者主动创建的。但心急吃不了热豆腐，在开始依葫芦画瓢之前，对其方法论做一些基本的了解，还是有助于后续对Rhapsody的应用。之所以选择《基于模型的系统工程最佳实践》这本书，是个人目前所参与的项目后续确定基于Harmony方法论开展相关工作，在合作的小伙伴们的推荐下，另外确实也是可以有的其他选择也不多，因此在开始动手实施项目前，抽时间啃一遍。本文主要为个人的随读笔记，以方便后续随时查阅。
       本书假设的前提是读者对sysML、Doors、Rhapsody已有一定的接触和了解。阅读之前，还是需要花一些时间跟度娘稍微熟悉了解一下sysML、Doors、Rhapsody相关内容，初步建立起一些基本概念，以便于理解书中内容。

项目越大，上下游、同级间的沟通成本越高，特别是在部门强比较坚固的公司，借助统一的语言、方法论、工具，规范化、标准化的推进业务开展，可有效的降低沟通成本，也能确保项目处于可控状态。

二、Harmony SE基础
2.1 Rational 集成系统/嵌入式实时开发流程 Harmony
       下图为Harmony V模型。

       系统工作流的三个阶段：需求分析、系统功能分析、系统综合设计，迭代的过程基于用例来完成，这个应该是Harmony方法论的核心内容之一。

       对于复杂的工程而言，传统的串行开发肯定是无法满足项目需求的，引入敏捷开发，自上而下的从需求、实施、测试各环节进行迭代，同时基于现有经验自下而上实施回归测试，进行集成，可能是比较合理的一种选择。

       Harmony支持模型驱动开发的流程，模型是开发流程的核心交付物以及成果，在不同的阶段输出特定的模型：
需求分析阶段：

• 需求模型：将需求可视化； —— 模型不可执行
• 系统用例模型：将需求以用例方式组织； —— 模型不可执行

系统功能分析阶段：

• 架构分析模型：分析模型相关，阐述架构理念； —— 模型可执行
• 系统架构模型：系统操作分配；——模型可执行

模型驱动开发流程中的必要元素是模型/需求库，如：

• 需求文档；
• 需求跟踪性信息；
• 设计文档；
• 测试定义；

2.2 基于模型的系统开发流程
Harmony系统工程的主要目标是：

• 识别并推导所需的系统功能；
• 识别系统相关的模型和状态；
• 把系统模型、功能/状态分配到子系统结构中；
  
  2.2.1 需求分析

需求分析的根本目的是将市场语言、用户语言转化为半工程语言，通过系统需求定义系统必须做什么以及做到何种程度。

需求分析工作流见下图：

需求分析阶段的起始为涉众需求规格说明书，需求应聚焦于所需要的能力上，之后是将这些需求转化为系统需求，并建立系统需求规格说明书，通过适合的方式（如Doors）将系统需求与涉众需求进行关联以便于跟踪。
系统用例应基于黑盒视点描述干系角色的行为以及角色与用例的信息流，这里的角色可以是人、系统或系统外部的硬件等。用例可以分层，但用例不是功能（但用例使用功能），不能按功能分解的方法去分解用例。用例重点放在“正常情况”的场景识别上，异常或例外的场景交由系统功能分析去做。
2.2.2 系统功能分析
该阶段的重点工作是把功能性需求转换为一个连续的系统功能描述，即从需求到模型以及对模型的执行验证。系统功能分析工作流如下：

用例模型的上下文在内部模块图（bdd）中定义，描述用例与其相关的角色。下一步是定义用例模块的行为，通过以下三个图进行展现：

• 活动图：Activity Diagram； —— 功能流
• 序列图：Sequence Diagram；—— 信息流
• 状态图：Statechart Diagram； —— 行为流

本阶段生成图的顺序依赖于我们所获取的信息以及建模者个人的喜好，书中给出了三种可参考的选择。

序号	说明	适用
方法一	基于用例场景，先捕捉场景，将识别出的功能流体现在活动图中。	场景多，功能状态相对简单
方法二	基于用例功能流，先定义功能流，再使用活动图导出用例场景。	功能多，场景相对较少，需要详细阐述需求的工程
方法三	基于状态行为，先定义状态，由状态图导出用例场景，活动图可以省略。	状态多，场景相对少的工程

用例模块状态图是所有方法中最重要的生成物，它包含了活动图和序列图中的信息，并可通过模型执行来确认。
当“正常情况”的用例模型和功能需求被验证后，便可开展异常和错误用例模型的创建工作，其工作流如下图：

2.2.3 设计综合
本阶段关注点是对物理架构所实施的能的开发，包含两个子阶段的工作：

• 架构分析：提炼功能需求和非功能需求，系统应该怎么做；
• 架构设计：把功能需求和非功能性需求分配到架构结构中，谁来做；

工作流见下图：

总结：
需求分析阶段：可理解为将离散的信息汇总并“翻译”或导入到软件中变成软件能读懂的元素；
系统功能分析：分析“要我做什么？”
设计综合：“怎么做？”以及“谁来做？”