用于产品和系统开发的系统建模语言的概述，第 1 部分： 需求、用例和测试用例建模
本文来自于 Rational Edge：这是一个三部分组成的系列文章中的第 1 部分，本文介绍了系统建模语言 （SysML，一种对于产品和系统开发的通用的图形建模语言）。 第 1 部分描述了 SysML 需求图、用例图和测试用例图。
今天的竞争压力和其他市场压力迫使发动机制造公司不断的改善其设计制造的产品和系统的效率。 在产品生命周期中，缺乏效率支持的是概念阶段，而正是在这个阶段决定了功能架构（有时还包括物理架构）。
概 念阶段是把用户需求转变为产品功能和实际使用，在不考虑工程规则（例如，机械、电子、软件等等）的前提下设计这些功能。在产品概念过程中，缺乏支持将会为 有效地实现跟踪产品需求带来困难。对于概念缺乏正规化的描述也会导致产品在系统级别缺乏足够的作出决定的能力，比如在可行性研究阶段。此外，对于产品架构 缺乏清晰的视图会影响团队间的理解和交流，而这常常增加了整合问题的风险。SysML正是被设计用来缓解这些和其他在产品和系统开发的概念阶段期间面临的 挑战。
在这个三部分系列的文章的第 1 部分中，我把它与统一建模语言（UML）相比较，解释了SysML的基本目的和价值， 并且描述了它的需求图、用例图和测试用例表示。在后续部分中，我将描述SysML的结构图和行为图，还有它的分配机制。在整篇文章中，我将探讨SysML 中可用的所有的图以及与每个图相关的构造。我将利用一种嵌入系统的真实例子（某种汽车所应用的 Rain Sensing Wipe 系统），以说明所讨论内容的前后关系。
SysML 标准为系统工程师和架构师提供了他们所急需的合作方式，这种方式通过使用专门设计的用以支持这种工作的通用语言得以实现。作为一种对于系统工程的标准建模语言，SysML 实现了开发小组间更好的沟通，同时大幅度增强了我们管理越来越复杂的系统的能力。此外，通过实现产品设计的电子化表示， SysML 打开了这样一扇大门，它使得在整个系统开发周期中可以更快更有效的进行决策分析。
SysML 和 UML
SysML 基于统一建模语言（UML），是对象建模组织（OMG）联盟软件工程开发的事实上的标准。 SysML 是2003年三月针对建议请求（RFP）问题进行的开发。开发小组包括十多个公司的代表。IBM通过编写部分规范内容而在标准的制定过程中起了领导作用。
图 1：SysML 1.0 与 UML 2.0之间的比较
图 1中的文字概述了SysML中可用的各种图表。需求图、参数图以及分配图是UML中所没有的新图。活动图和模块图来自于UML 2.0的重用，并在SysML中进行了扩展。最后，状态机图，交互图以及用例图都是来自于UML 2.0的重用，没有进行修改。
SysML 一种是用来表示系统和产品架构，以及它们的行为和功能的建模语言。它是基于UML中构造软件架构（想一想经典的类图）的软件工程学科中所获得的经验。 SysML架构描述了实现系统功能元素的表示。物理方面有时候也会被表示出来；例如，当架构表述软件是如何在一组计算资源上被部署时。
我 会通过一个实例探讨SysML的能力： Rain Sensing Wiper （RSW） 系统。本实例的灵感来源于现实产品，在最初的开发阶段经历了一些挑战。（请参看RSW项目背景 附录 A 。） 为避免由于代价高昂的产品召回所造成的失败，本实例形象地说明了在子系统级别理解产品的重要性。在这种情况下，RSW制造商必须忍受漫长的（因此是代价高 昂的）根源分析过程，并最终改变设计。在本文所使用的实例中，我提出了一种可以避免制造商经历失败的模型。
RSW 的目标是无论任何时候挡风玻璃外表面检测到液滴时，都能够自动化的进行擦洗（无需用户干预）。此外，依据检测到的液滴量调整雨刷器的速度。这个系统拥有三 种主要部件：（1）控制雨刷器行为的软件，（2）执行软件的电子控制单元，（3）固定在挡风玻璃内表面的传感器，它的任务是通过挡风玻璃感应液滴。
本文中，我提出了一个详细描述本系统各个方面的模型。本实例由汽车工业中的嵌入式电子领域内的实际产品组成，这种设计大量吸收了SysML表示的优点。
当为一个系统建模时，一项重要的任务就是决定哪部分属于系统，哪部分不属于。环境图不是一种正规的（从某种意义上说它没有包括精确的语义）表示系统边界的方式。 我们注意到图1中并没有表示环境图，因为它实际上是使用模块（定义）图创建的。图2 展示了RSW的环境图。
图 2： Rain Sensing Wiper系统的环境图
环境图构建了系统的范围。在本例中，它为系统确定了三类角色：Maintenance （维修用途）， Car Electrical System （启动汽车中的系统）， Driver （例如手动关闭系统）。需考虑三种外部系统：雨刷器接口，挡风玻璃，和汽车电子系统。注意用户定义的关键字 "external" 是用来限制外部部件的。还要注意汽车电子系统也要为RSW提供电力。因此，它应同时属于角色和外部系统。
如上所述， 开发周期的概念阶段被分离到用户需求分析过程中，这就形成了产品需求。传统的需求都被表示为文档的形式，它们经常与数据和图表联系在一起，存储在文件或数据库中。需求描述了所有产品功能，并且定义了实现这些功能的约束条件。
SysML 允许需求描述作为模型元素。因此，需求变为产品架构的一部分。这种语言灵活的表达了任何种类、任何关系的基于文本的需求。图3展示了RSW的需求图。
图 3：Rain Sensing Wiper系统的SysML需求图
我 们注意到需求图包含功能和非功能需求。SysML中的需求是抽象类别的 —— 就是说，它们不能被实例化——不包括操作或属性。然而我们可以通过为需求原型增加属性来实现为需求元素增加属性的目的。原型属性的使用允许在设计阶段设置 这些属性值。1需求不能加入到关联与泛化中；但是，一套预定义的关联关系可以帮助描述需求间的关系。我会在下面回顾这些关联关系。
子需求通过使用交叉关系来与它们的父需求关联起来，这些关系指明了嵌入式命名空间。例如，在图 3中，Automatic Wiping内的部分子需求通过交叉关系与它联系在一起。 父需求相当于封装了嵌入的需求。在某种意义上说，删除父需求将会自动删除所有嵌入其中的需求。另一个封装其他需求的例子是 Core Functions，它包含了两个子需求。为了模型的可读性，用户定义的关键字 "package" 被提供给 Requirement 原型。
在需求分析阶段（例如，分解与细化），依据来源创建新的需求。这些新的需求都与最初的DeriveRqt 依赖有关。例如，在图3中，一组产品的核心功能源自于Automatic Wiping下的需求组。选择 DeriveRqt 的名字是为了避免与UML 2.0中的Derive依赖标准发生混淆。其他例子的起源需求都是对于每个功能的技术性选择（参照图3中的Technical Choices）。我们注意到设计师利用Rationale 来解释使用固定在挡风玻璃上的传感器的原因。最后一个起源需求是质量需求System Calibration，它指出系统应被校准。这是在声明狼籍的RSW失败之后被加入产品中的需求。 这一需求的满足确保了产品不改变传感器与雨刷器的特性。
需求间的另一种关系是细化（Refine）。 需求细化的例子如图3所示。快速启动的需求由可能的速度选择细化：慢速、中等或快速。最后，一种通用的跟踪（Trace） 依赖关系用以强调需求是通过不同方式被联系在一起的。图3中，手动减速的需求与自动减速联系在一起。
需求拥有大量的源属性以存储上文中提到的关系状态。正如我在本系列的第2部分解释的那样，当需求关系在需求图外被提出时，这些属性将会变的非常便捷。
通常情况下，总会在整个产品周期中提出需求，并且需要额外的需求图加以表示。因此，产品需求一般规定为一组需求图。
SysML提出了允许功能与非功能需求建模的通用模型。在OMG SysML规范的附录中提出了一种非标准的需求类型。2 特殊的需求类型（例如，与时间或计划有关等等）由语言扩展项处理。SysML 支持概要文件机制以扩展语言。OMG 已经发布了一系列的建模标准，它指出了在性能与质量方面，非功能需求建模与测试建模的特殊需要3, 4 。5 这些概要文件可在SysML中不受限的加以使用。
SysML 提供了继承于UML 2.0的用例图。在图4中，我们用主要的用例（由椭圆图显示）展示了外部角色的交互作用。
图 4： Rain Sensing Wiper 系统的SysML 用例图
用例图展示了三类角色并分别介绍了各自的用例。被称为Automatic Wiping的关键用例是由一系列子用例组成。这种等级关系通过包括（Include）依赖关系形成。
SysML 还具有表示测试用例的能力，并把它们与相关需求或是用例联系起来。测试用例可以是一种操作或一种行为模型（交互图、状态机图或活动图）。
图 5 和图 6 显示了RSW的测试用例。这种测试验证了System Calibration需求（参看图 3）。按照如下步骤实现：
- 首先，检索不同部件的特性（传感器、挡风玻璃和软件配置文件）。
- 第二，运用这些特性计算传感器和挡风玻璃的操作范围，以此评估它们的兼容性。如果传感器和挡风玻璃是相互兼容的，那么测试是成功的。否则，会触发警报。在行为图中的动作会被附在解释说明框中（参看图5）。
图 5：System Calibration质量需求的SysML 用例图。测试用例是通过一个活动图实现的。
第一步通过Web服务访问包含不同部件的库得以实现（参看图5中的左边）。更确切的说，需查询材料清单库（比如存储于产品数据管理系统中）以了解传感器和挡风玻璃的特性。然后，配置文件从软件配置管理系统中得到。
第二步（参看图5中的中间部分）通过在 SysML 参数图中定义传感器和挡风玻璃属性的约束条件得以实现。我将在本文第 2部分解释这些图是如何构建的。
在图 6中，创建测试环境以适应Web服务和其他必需功能的原型。这种环境与需求相关。活动图（如文中第 2 所描述的）执行时使用测试环境的功能。
图 6: System Calibration质量需求的SysML 测试用例图：需求与测试的可追踪性
在本月的第 1 部分，我已经介绍了SysML，并且展示了它的建模需求、用例和测试用例的能力。接下来的部分，我将展示如何用SysML创建一个满足某些需求的产品结构，以及如何使用它的分配机制。
1 为类别属性分配类值应是可选择的，因为类别属性在运行时也是为了携带数值，这与SysML中的语义需求相矛盾。
2 SysML 1.0 规范 (ptc/06-05-04)，OMG 最终采纳的规范可从 http://www.omgsysml.org/获得
3 UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms (ptc/04-06-01), OMG 最终采纳的规范可从 http://www.omg.org/docs/ptc/04-06-01.pdf获得
4 [STP] UML Profile for Schedulability Performance and Time (ptc/05-01-02)，OMG 最终采纳的规范可从 http://www.omg.org/technology/documents/formal/schedulability.htm获得
5 UML Testing Profile (ptc/05-07-07), OMG 最终采纳的规范可从 http://www.omg.org/technology/documents/formal/schedulability.htm 获得