| 编辑推荐: |
文章主要介绍了SysML的基础知识，探讨SysML提出的特定构造，以对需求和可追溯性进行建模，并给出使用建议。
本文来自于re-magazine.ireb，由火龙果软件Luca编辑、推荐。 |
|
在本文中，我们将展示SysML建模语言如何对需求过程进行补充，即更好地定义和跟踪需求。系统建模语言(SysML)是一种通用的图形建模语言，由对象管理小组(OMG)根据著名的统一建模语言(UML)定义。它用于指定，分析，设计和验证复杂的系统，旨在为建模各种系统工程问题提供简单而强大的构造。它在指定需求方面特别有效：支持工程分析的系统属性的结构，行为，分配和约束。
本文将深入探讨SysML提出的特定构造（与UML相比），以对需求和可追溯性进行建模。我们将看到需求图如何允许捕获需求层次结构和派生，以及“满足”和“验证”关系如何允许建模人员将需求关联到满足需求的设计元素或验证需求的测试用例。我们还将就如何最好地使用这些特定的建模结构给出实用的建议。
1.什么是SysML？
1. SysML的起源
在所有领域中，那些构建复杂系统的模型已经进行了很长时间的建模：
·利用复杂性
·降低风险
·沟通。
SysML™是一种通用的图形建模语言，用于指定，分析，设计和验证可能包括硬件，软件，信息，人员，过程和设施的复杂系统。它是专门用于系统工程的UML概要文件。
为了可视化UML和SysML语言之间的关系，请考虑图1所示的维恩图，其中构成这些语言的语言结构集分别显示为标有“
UML”和“ SysML”的圆圈。由标记为“ SysML重用UML”的区域所示的两个圆圈的交点表示SysML重用的UML建模构造。图1中标记为“
SysML到UML的扩展”的区域表示为SysML定义的新的建模构造，该构造在UML中没有对应项，或替代了UML构造。请注意，UML的一部分也不需要实现SysML，这由标记为“
SysML不需要UML”的区域显示。
图1： SysML和UML之间的关系–来自[OMG1]
2. SysML图类型
图2（白框）中标识了九种SysML图表类型，并在下面进行了总结。
图2： SysML图类型–来自[OMG2]
行为图包括用例图，活动图，序列图和状态机图。用例图提供了功能的高级描述，该功能是通过系统或系统部件之间的交互来实现的。活动图表示活动之间的数据流和控制。顺序图表示系统协作部分之间的交互。状态机图描述了系统或其部分响应事件而执行的状态转换和操作。
系统结构由块定义图和内部框图表示。块定义图描述了系统层次结构和系统/组件分类。内部框图以部件，端口和连接器的形式描述了系统的内部结构。包图用于组织模型。参数图表示对系统属性值（如性能，可靠性和质量属性）的约束，并用作将规格和设计模型与工程分析模型集成在一起的方法。
SysML包括一个图形结构，用于表示基于文本的需求，并将它们与其他模型元素相关联。下一章将详细介绍需求图及其所有相关概念。
2.基于文本的需求建模的sysml新结构
SysML定义了用于建模需求及其关系的特定元素，而在更为知名的UML中则不存在。为了可追溯性，它还包括与其他工件（如测试用例或设计块）的关系。
这些所有构造将在以下段落中详细解释。
1. SysML中的需求概念
让我们引用SysML规范：“需求指定必须(或应该)满足的能力或条件。需求可以指定系统必须执行的功能或系统必须达到的性能条件。”。
用例（UML中存在）可以有效地捕获功能需求，但不适合表达非功能需求。将基于文本的需求合并到SysML中可有效适应各种需求。
标准SysML需求
标准SysML要求包括用于指定其唯一标识符和文本要求本身的属性，如图3所示。其他属性（例如，验证状态，优先级等）也可以由用户指定。
图3： SysML要求
需求子类
建模人员可以通过定义需求原型的附加子类来定制需求分类。例如，建模人员可能希望定义需求类别，以表示操作、功能、接口、性能、物理、存储、激活/停用、设计约束和其他专门需求，例如可靠性和可维护性，或者代表高层涉众需求。原型使建模者能够添加约束，限制为满足需求而分配的模型元素的类型。例如，功能需求可能受到约束，因此只能由SysML行为(如活动、状态机或交互)来满足。
需求包
需求可以组织成一个包结构。典型的结构可能包括满足所有要求的顶层程序包。此顶级软件包中的每个嵌套软件包都可能包含来自不同规范（系统，子系统，组件等）的需求。每个规范包都包含该规范的基于文本的要求。此包结构对应于典型的规范树，这是描述项目要求范围的有用工件。
2.需求关系
在系统模型中捕获需求非常有用。但是，更大的价值在于在需求和其他模型元素之间创建的关系。
指定了七个需求关系，使建模者能够将需求彼此关联以及与其他模型元素关联。这些关系包括定义需求层次结构、派生需求、满足需求、验证需求和细化需求的关系。然而，这些关系的语义并不是在形式上定义的，而是可以解释的。因此，有必要定义一些关于如何使用这些关系的启发式、指南和实践，以便有一个一致的模型。
下一节将详细说明SysML中所有可用的关系。
遏制（复合需求）
复合需求可以包含使用名称空间包含机制指定的需求层次结构中的子需求。复合需求可以声明系统应执行A和B，可以将其分解为系统应执行A和系统应进行B的子需求（如图4所示）。
图4： SysML的复合要求
将复合需求划分为更简单的需求有助于建立完全的可追溯性，并显示单个需求如何成为进一步推导的基础，以及如何满足和验证它们。
派生关系
派生的需求通常对应于系统层次结构下一级的需求。一个简单的例子是车辆加速需求，该需求被分析以导出发动机动力等方面的需求，如图5所示。
图5： 派生关系示例
它还被用于表示在层级的相同级别但在不同的抽象级别之间的要求之间的关系。例如，由系统工程团队最初指定的硬件或软件需求可以由硬件或软件团队分析，以获得更详细的要求，该更详细的要求反映额外的实施考虑或约束。硬件或软件团队的更详细的要求可能与系统团队指定的原始要求相关，通过导出关系。
改善关系
细化需求关系可用于描述如何使用模型元素或元素集进一步细化需求。例如，可以使用用例或活动图来细化基于文本的功能需求，如图6所示。或者，可以使用它来显示基于文本的需求如何细化模型元素。在这种情况下，可以使用一些阐述的文本来细化不太精细的模型元素。
图6： 细化关系示例
细化应阐明需求的含义或上下文。与派生关系的区别在于，需求与任何其他模型元素之间可以存在细化关系，而派生关系只能存在于需求之间。另外，派生关系旨在基于分析施加其他约束。
满足关系
满意关系描述了设计或实现模型概念如何满足一个或多个要求。然后，系统建模者可以指定旨在满足要求的系统设计元素，如图7所示。
图7： 满足关系的示例
但是，重要的一点是断言不构成证明。满足关系只是将需求分配给结构的一种机制。证明确实满足了要求的证据来自测试用例（请参阅下一段）。
验证关系
验证关系定义了测试用例或其他模型元素如何验证需求，如图8所示。在SysML中，测试用例或其他命名元素可以用作表示任何标准检验方法的通用机制，分析，演示或测试。
图8： 验证关系示例
复制关系
真正需要跨产品系列和项目重用需求。典型的方案是适用于产品和/或产品系列中重复使用的项目和要求的法定法规或合同要求。
SysML引入了从属需求的概念，如图9所示。
图9： 复制关系示例
复制的需求的text属性是源需求的text属性的只读副本，但是复制的需求具有不同的ID，并且可以包含在不同的命名空间中。
追溯关系
通用追溯需求关系提供了需求和任何其他模型元素之间的通用关系，如图10所示。追溯的语义不包含任何实际约束，因此非常弱。因此，我通常建议您改用之前介绍的其他（更有意义的）需求关系之一。
图10： 跟踪关系示例
但是，追溯关系对于将需求与源文档相关联或在规范树中的规范之间建立关系可能很有用。
警告：箭头方向！
SysML中的大多数需求关系都基于UML依赖关系。箭头从从属模型元素（客户端）指向独立模型元素（供应商）。因此，在SysML中，箭头的方向与通常用于需求流的方向相反，其中较高级别的需求指向较低级别的需求。建立关系时请多加注意！
3.需求图和表格
SysML提供了建模构造来表示基于文本的需求，并将其与其他建模元素相关联。需求图可以图形，表格或树形结构格式描述需求。需求也可以出现在其他图表上，以显示其与其他建模元素的关系。
当查看大量需求时，需求图有一个明显的缺点。与在图表中查看需求相比，查看文本文档中需求的传统方法是一种更为紧凑的表示形式。
SysML包含在表中显示模型查询结果以及将表用作数据输入机制的概念，但是生成表的细节留给工具实现者。该表格格式可以用来表示需求，它们的属性和关系，如图11所示，并且可以包括：
·需求及其列中的属性
·包含任何依赖关系（派生，验证，优化，追溯）的供应商的列
·包含满足要求的模型元素的列
·等等。
图11：需求表示例
实际上，能够要求高效的建模工具生成需求跟踪和验证矩阵，并在需求发生变化时执行自动影响分析，是一个非常重要的节省时间的工具。
3.表示需求的其他方式
几乎所有其他SysML图表类型也可以用于指定需求！
·用例图
·顺序图
·状态机图
·活动图
·块定义图
·内部框图
·参数图
1.用例图
用例图描述了系统（主体）的参与者（环境）对实现目标的使用。
2.顺序图
顺序图可以描述特定用例的给定场景下参与者与系统之间的控制流（被视为黑匣子）。此图表示交互实体之间的消息发送和接收，称为生命线，其中时间由垂直轴表示。
3.状态机图
状态机软件包定义了一组概念，可用于通过有限状态转换系统对离散行为进行建模。状态机根据对象的转变和状态将行为表示为对象的状态历史。它可以用于根据外部事件和响应来指定系统所请求的行为。
4.活动图
活动建模强调协调其他行为的输入，输出，顺序和条件。它可用于详细指定系统在特定用例期间所请求的操作顺序。
5.块定义图
块定义图定义了块的功能以及块之间的关系，例如关联，概括和依赖性。可以在规范级别使用它来捕获代表系统环境的块的定义。
6.内部框图
内部框图根据属性和属性之间的连接器来捕获块的内部结构。端口是一类特殊的属性，用于指定块之间交互的允许类型。这样的图可以在规范级别用于精确捕获系统与其环境之间的接口。
7.参数图
参数图可用于指定将在系统上强制执行的域或项目约束。
结论
需求模型可以提供有助于确定需求是否满足其期望属性的信息（例如，明确，可理解，正确，简洁，可追溯，与设计无关，可验证，唯一，完整，一致等）。此外，需求图是SysML的主要介质，用于传达需求之间的可追溯性以及系统模型中从需求到结构和行为的可追溯性。当您向模型中添加新元素时，您将创建从这些元素到驱动其创建需求的需求之间的关系。以这种方式建立需求可追溯性是贯穿设计和开发的一项持续活动。您可能需要创建一个需求图，以在此工作中的任何时候显示这些关系。因此，对于尚未掌握工具需求管理流程的人来说，这是一个真正的突破。
需求管理工具（如DOORS，RQA等）被广泛用于管理需求及其之间的关系。需求通常存储在数据库中。这些工具旨在有效地管理需求信息，即处理属性，过滤数据以及建立和分析需求可追溯性。
SysML包括需求建模功能，可以在需求管理工具中可以维护的基于文本的需求与系统模型之间建立桥梁。工具自动化，需求管理过程和配置管理过程的组合用于在需求管理工具和模型之间同步需求。此功能旨在通过在基于文本的需求和代表系统分析，设计，实现和测试用例的模型元素之间进行严格的可追溯性，来显着改善整个系统生命周期中的需求管理。那么，为什么不尝试利用这两个的有点呢？ |
