第3章模块定义图

常见的一种SysML图就是模块定义图。可以在BDD中显示不同类型的模型元 素和关系，以说明系统结构的信息。还可以采用创建扩展系统结构的设计技术，那种 实践会在利益相关者的需求发生变更时，降低修改设计所需要的时间和成本。

3.1目的

在BDD中显示的模型元素——模块、执行者、值类型、约束模块、流说明、接 口——都是其他模型元素的类型，它们会出现在其他8种SysML图中。把出现在 BDD中的元素叫做定义元素。在实际情况下，定义元素形成了系统模型中其他内容 的基础。这正是首先介绍BDD的原因所在。

定义元素非常重要;它们之间的结构关系——关联、泛化和依赖——可能更重要。 在BDD上也会显示这些关系。使用这些关系，通常会创建说明系统分解和类型分类 的 BDD。

3.2何时创建BDD

经常——你应该经常创建BDD。

这看起来是一种滑头的答案，但很准确。BDD并不会与系统生命周期的特定阶 段或者设计等级绑定。你和团队会在执行所有这些系统工程活动的时候创建它(并参 考它)：利益相关者需求分析、需求定义、架构设计、性能分析、测试案例开发、集 成。你通常会和其他SysML图一起创建BDD,从而为所关注系统的一个方面提供完 整的视图。

简而言之，你应该——也会一经常创建BDD。

3.3 BDD外框

模块定义图的类型缩写是BDD。图的外框代表的模型元素类型可以是以下这些：

□包

□模型 □模型库 □视图 □模块 □约束模块

如2.4节所讨论的，图代表的模型元素会作为图中显示的其他元素的命名空间。命名空 间只是一种模型元素，可以在其中包含其他模型元素。也就是说，它可以包含其他模型层次 结构中的元素。因此，命名空间是在一种只在系统模型中才有意义的概念，它在系统实例中 没有任何意义。

很多类型的SysML元素都可以作为命名空间。然而，包是针对出现在BDD中各种 定义元素常见的命名空间。因此，BDD中头部命名的元素通常是在模型层级结构某处 创建的包。

图3.1中的BDD的名称是“ DellSat-77卫星结构和属性”。图的头部也告诉我们 这个图表示系统模型中的Structure包。因此，Structure包就是图中显示的元素的命名空间。

让我们详细看一下你可以在BDD中显示的元素和关系的种类。

3.4模块

模块是SysML结构中的基本单元。可以使用模块为系统中或者系统外部环境中 任意一种感兴趣的实体类型创建模型。

注意定义和实例(SysML指的是“使用”)之间的区别。这种区别涉及系统设 计基本的概念，并且在SysML中经常出现。某些类型的模型元素(例如：模块、 值类型、约束模块)表示对类型的定义;其他类型的模型元素(例如：组成部分属 性、值属性、约束属性)代表那些类型的实例。打个比方，房屋的蓝图是对房屋类 型的定义;在各个地点根据图纸盖起来的房屋就是那个类型的实例。

知道上面的内容之后，我可以重新说明一下：模块代表的是实体的类型.而不是一个实例的类型。例如，可以在系统模型中创建名为DesktopWorkstation的模块。 那个模块代表一种类型，其中定义了一系列属性——像显示器、键盘、鼠标、CPU、 制造厂商、磁盘空间、价格等——它们对于所有实例都通用。而IT部门为每个办公 室和工位购头的每台桌面工作站都是那个DesktopWorkstation模块的不同实例。

你很容易就能够指出元素的定义和在系统模型中对元素的使用之间的区别。元素 的定义只有一个名称(例如，DesktopWorkstation),而对元素的使用则有名称和类型， 二者之间用冒号分隔(例如，SDXI205LJD : DesktopWorkstation)0模块的注释是带有元类型图1.2所示)。需要显示模块的名称分隔框。通常会显示另外的可选分隔框，其中 会显示模块的特性。

特性有两种：结构特性(也叫做厲性)和行为特性。接下来的两节深人讨论这两类特性。

以下是以选抒显示的分隔框:

□绀成部分

□参考

□ 值

□约朿

□操作

□接受

□标准端口(在SysML vl.2及更早版本中)

□流端口(在SysML vl.2及更早版本中)

□完整端口(在SysML vl.1中)

□代理端口(在SysML vl.1中)

□流属性(在SysML vl.1中)

□结构

结构分隔框只是分隔框，其中不会列举特性。它只是一种图形分隔框，显示模块的内部结构。你可以在那个分隔框中显示所有你能够在内部模块图中显示的相同标记。建模者一般不会显示这些分隔框。

请注意，尽管我们也可以在分隔框中显示模块的端口，但更常见的是把端口显示为模块边框上的小方块(如图1.2所示)。1.4.1节会对其进行详细讨论。

3.4.1结构特性

模块可以拥有五种结构特性(也叫做属性)：

□组成部分属性 □引用属性 □值属性 □约束属性 □端口

1. 组成部分属性

组成部分属性会列在模块的组成部分分隔框中(如图1.1所示)。组成部分属性代表 模块内部的结构。换句话说，模块是由组成部分属性构成的。这种关系是一种所属关系。

然而，SysML并没有定义所属关系，这个概念在不同的领域有不同的意义。在 硬件领域，所属关系通常指的是物理组成关系。例如，图1.1表示通信和数据处理 子系统模块的可用实例是一些必不可少的物理组成部分：飞行电脑、调制器、解调 器、发射机、接收机和天线。而在软件领域，所属关系通常指的是一个对象负责创 建和销毁另一个对象。当为一个复杂对象分配内存的时候，也会为它的每个组成部 分分配;同样，当为一个复杂对象释放内存的时候，也会为每个组成部分释放内存。

但是SysML明确声明，所属关系意味着一个组成部分属性一次只能属于一个复 杂结构。然而，一个组成部分属性可以从复杂结构的一个实例上移除，然后添加到另 一个复杂结构的实例上。例如，我一次只能把特定的天线安装在一个_卫星上，而无法 安装在两个甚至多个上面。但是，那个天线可以从一个卫星上拆除下来，然后在某个 时候重新安装在另一个卫星上。

当你在模块的组成部分分隔框中列举一个组成部分属性的时候，会显示下面这样 的字符串：组成部分名称由建模者定义，类型一般是你在系统模型某处创建的模块的名称。 多重性是一种约束，限制复杂对象中组成部分属性的实例数量，以单个整数或者一系列 整数表示。

例如，图1.1表示通信和数据处理子系统模块的有效实例必须只包含一个飞行计 算机模块的实例——那个实例会起到主要计算机的角色。此外，它必须再包含一到两 个飞行计算机的实例——起到备份计算机的角色。

如果你想要一个组成部分属性代表任意数量的实例，那么就可以把多重注设置为也就是 “0或者多个”。或者，可以把多重性设置为*，那是0..*的缩写。

如果对于组成部分属性没有设置任何多重性，那么默认就是1 (等同于1..1 )。注 意几乎总是SysML中的默认多重性设置。然而，也有一种重要的例外情况，这会 在1.5.2节中讨论。

当一个组成部分属性的多重性的上限大于1的时候(例如：1..2, 0..10, *),我们就称那个组成部分属性为(实例的)集合。关键的问题是组成部分属性和实例意义 并不相同;如果复杂结构的多重性允许，那么其中单独的组成部分属性可能代表多个 实例。

2. 引用属性

引用属性会列举在模块的引用分隔框中(如图1.4所示)。引用属性代表模块外部 的一种结构。

和组成部分属性不同，引用属性并不表示所属关系。引用属性可以大概描述为 “需要”的关系;带有引用属性的模块因为某种目的需要那个外部结构，或者是为了提 供一种服务，或者为了交换事件、能量或者数据。这意味在它们之间必须存在某种联系。

注意，在模块之中出现的引用属性，本身不会说明其目的。如果你需要说明那个 目的，可以在内部模块图中这么做。第4章对其进行深人讨论。

当在模块的引用分隔框中列举一个引用属性的时候，会显示这种格式的字符串：

〈reference name> : []

引用名称由建模者定义。类型必须是你已在系统模型某处创建的模块或者执行者 的名称。多重性是引用属性能够表示的实例的数虽限制。

例如，图1.4显示电子电力子系统模块拥有名为cdhs的引用属性。这个模块表 示电子电力子系统的实例只需要一个通信和数据处理子系统(以满足它的设计目的)。 需要再次说明的是，这个视图本身并没有表达那样做的目的是什么，它只是表示二者 之间必须存在某种类型的关系。

和组成部分属性一样，引用属性的默认多重性是1 (如果没有显示任何多重性设 置)。同样和组成部分属性类似，当多重性的上限大于1时.引用属性代表的是一个 集合。

3. 值属性

值属性列举在模块的值分隔框中(如图1.5所示)。值属性可以代表一个数字(某 种类型)、一个布尔值或者一个字符串。然而，更常见的情况下，可以为值属性赋予 一个数字。当和约束属性结合的时候，值属性会特别有用，那样可以构建系统的数学 模型(更多内容请见第9章)。

当模块的值分隔框中列举一个值属性的时候，它会是下面这种格式的字符串：

值的名称由建模者定义。类型必须是你已在系统模型中某处创建的值类型的名 称。多重性是值属性能够持有的值的数量的限制。默认值是可选信息，代表它所属模 块的实例第一次创建的时候赋予值属性的值。

图1.5屉示DellSat-77卫星模块拥有多个值属性。eventTimes值属性可以持有任 意多个Timestamp值(多重性表示为0..*)。Timestamp是一种值类型，它存在于模型 层级关系的某处(关于值类型的更多信息请见1.9节)。

和组成部分属性及引用属性类似，值属性的默认多重性也是丨(如果没有设置多 重性)。类似地，肖它的多m性的上限大于1时，值属性就代表一个集合。

某些值屈性会持有赋子的值，其他会持有从系统模型中其他值属性继承(计算)得 到的，为了表示一个值屈性是继承得来的，需要在它的名称之前放置一个反斜杠(\)。 例如，图1.5 DellSat-77卫星模块拥有两个继承得到的值属性:mass和period。模型的这种视图不会标识用来计算那些值的等式，也不会显示哪些值属性为那些等式提供 r输人，耑耍使用约束表达式(这会在接下来的小节中讨论)来指定那些数学关系。

4. 约束属性

约束属性会列举在模块的约朿分隔框中(如图1.6所示)。约束属性一般代表一种数学关系(一个等式或者不等式)，它会使用一系列值属性。在这里所需要的模型精确度要比大多数建模项目所需要的都高。然而，对于构建系统的数学模型来说，约束属性是一种核心组成部分，你会在参数图中显示它(更多内容见第9章)。

当在模块的约束分隔框中列举约束属性的时候，它会显示为这种格式的字符串：

约束名称由建模者定义。类型必须是你已在系统模型某处创建的约束模块的名称。

约束模块只是一种特殊的模块——创建它是为了封装可重用的约束表达式。常见的情况下，约束表达式是一个等式或者不等式。例如，图1.7显示了一个名为

Sufficient Memory的约束模块，其中封装了约束表达式：

memoryCapacity >= dataPerOrbit * 1

这个约束模块是作为飞行计算机模块中约束属性sm的类型而存在的(如图1.6所示)。这表示两个值属性中(MemoryCapacity和dataPerOrbit)持有的两个值必须始终满足那个数学关系(在名义上操作的系统中)。

注意，这里并没有要求你使用约束模块来影响值属性上的数学关系。直接在模块的约束分隔框中指定约束表达式也没有问题(如图1.8所示)。当只有一个模块需要那 个约束表达式的时候，你就会这么做(即，不需要在多处重用)。然而，我还是建议 你好总是把等式和不等式封装到约束模块中;如果需求增长，这可以重用。

3.10节详细讨论约束模块。现在，你要记住这些关键点：

□模块可以拥有约束属性(以约束值属性)。

□约束属性的类型是约束模块，其中一般会封装数学关系。

5. 端口

端口是代表结构边缘不同交互点的一种属性，通过那些点外部实体可以和那个结 构交互一或者是提供服务，或者是请求服务，或者是交换事件、能量和数据。

当你为模块添加端口的时候，其实就是把一种结构针对它的环境建模为一个黑 盒;结构的内部实现会对客户端隐藏。那些客户端只知道结构的接口(它所提供和请 求的服务，以及能够流人、流出的事件、能量和数据的类型)。需要特别声明的是， 接口会将模块的客户端与所有特定的内部实现解耦。

使用一系列端口来封装模块，让你可以在稍后重新设计模块的内部实现，而不 会影响系统其他部分的设计。当客户的需求在生命周期后期发生变更的时候，这 种实践会减少系统修改所需要花费的时间，而时间上的节省会转换成为成本上的 节省。

端口可以代表你所需要建模的任意类型的交互点。例如，它可以代表硬件对象 边界上的物理对象(例如：龙头、HDMI接口、燃油喷嘴，或者仪表)。它也可以 代表软件对象边界上的交互点(例如：TCP/IP插槽、消息队列、共享内存片段、图形化用户界面、数据文件)。它还可以代表两家商业组织之间的交互点(例如： 支付汀单、传件员、网站、邮箱)。SysML不会对能够代表什么样的端口做任何 限制。

SysML vl.2 (以及更早版本)定义了两种端口——标准端口和流端口——你可以 把它们添加到模块上，以指定不同类型的接口。标准端口可以指定一个交互点，关注 模块提供或者诸求的服务;流端口可以指定一个交互点，关注能够流入、流出模块的 事件、能S或者数据的类型。

主意 SysML vl.1不再支持标准端口和流端口，作为替代，它定义了两种新的端 口：完整端口和代理端口。我会在附录B中详细讨论这些内容。我在这一 章中会关注标准端口和流端口，因为在我撰写这本书的时候，它们仍是系统 模型中端口的主要类型。此外，当前版本的OCSMP认证考试也覆盖了标准 端口和流端口的内容。另外，某些建模工具没有跟上SysML的改变，暂时 还不支持完整端口和代理端口。

标准端口是模块在边界交互点上提供或者请求的服务(行为)的模型。常见的 情况下，你会把标准端口表示为模块边界上的小方块(如图1.9所示)。你会注意到， 在标准端口分隔框中把标准端口以字符串形式列举也是可以的，但那种标识法并不 常见。

标准端口可以拥有建模者定义的名称(例如：sp_cdhs、sp_eps),以字符串的 形式显示在标准端口旁边(可能在模块边界之内，也可能在之外)。标准端口可以 拥有一种或多种类型;类型是你赋予它的接口(例如：Power Generation、Status Reporting) 和模块类似，接口也是对元素的一种定义——它定义了一系列操作和接收信息， 也就是客户端和提供方需要遵循的行为契约。你可以在BDD中把接口显示为一个矩形框，名称前面带有关键字<> ;你可以在第二个和第三个分隔框中显 示它的操作和接收信息。图3.10用这种标识法显示了 Power Generation和状态报告 接口。

当你为标准端口赋予接口的时候，可能会将其赋予提供接也可能赋请求接 口。提供接口使用圆形标识——和标准端口连接，像棒棒糖一样的符号(如图1.9所 示)。提供接口的模块必须实现接口所有操作和接收信息。例如，图3.9表示通信和 数据处理子系统模块提供了状态报告接口，而这意味着它会实现那个接口中的两个 操作和两种接收信息。

请求接口使用槽状的标识来表示——和标准端口连接，带有半圆的直线(如 图3.9所示)。请求接口的模块可能会在系统操作的某些时候调用一个或多个——不 一定是所有——操作或者接收信息。例如，图3.9表示电子电力子系统模块需要请求 状态报告接口，这意味着它可能会调用那个接口中四种操作和接收信息中的任意多个 (或者所有)。

使用标准端口建模这种方式，可以对客户端和提供程序提供解耦，让你可以为抽 象而不是具体实现来设计。这种可扩展性让你可以在任何时候添加新的接口提供程 序，而不会影响那些接口的现有客户端。

流端口会为能够在边界交互点流人、流出模块的事件、能量或者数据建模。和标 准端口一样，你通常会把流端口显示为连接在模块边缘上的小方块(如图3.11所示)。 然而，和标准端口不同的是，流端口在小方块中会显示一个符号(我们很快就会讲 到)。把流端口显示为分隔框中的字符串也没有问题——叫做“流端口”的分隔框——但那并不是一种常见的标识法。

流端可以拥有建模者定义的名称(例如：dataOut、dataln);它也可以拥有类型(例如：Housekeeping Data)。名称和类型都显示为流端口附近的字符串，以名称：类型的格式用冒号分隔。你为流端口制定的类型以及显示在方块中的符号取决于你建模的流端口的种类。SysML提供两种流端口：非原子流端口和原子流端口。

图3.11显示了非原子流端口的例子。当你需要为通过端口流人或流出的多种项目类型建模时，就会为模块添加非原子的流端口(符号是 <>)。非原子流端口的类型必须是你在系统模型某处创建的流类别的名称和模块一样，流类别也是对元素的一种定义——它会定义一系列能够流人、流出非原子流端口的流属性。可以在BDD上把流类别显示为一个矩形框，名称前面带有元类型说明Properties)的分隔框中显示它的流属性。图1.12显示了使用种标识法显示的Housekeeping Data流类别。

流属性代表的是能够通过流端口流人、流出模块的特定项目。每个流属性都有 其自身的方向、名称、类型，以下面的格式显示为一个字符串：

方向可以是in、out或incnit。名称由建模者定义。类型必须是你已经在模型层级 关系中某处创建的值类型、模块或者记号的名称。

图3.11显示飞行计算机模块拥有名为dataln的非原子流端口，它的类型是 Housekeeping Data流类别。这个模型表示温度和电压值在系统操作的某个时间点可 以传人到飞行计算机的实例中。

图3.11还显示电子电力子系统模块拥有名为dataOut的非原子流端口，它的 类型也是Housekeeping Data流类别。然而，在这种情况下，类型Housekeeping Data前面有一个波浪线(?)。这个符号表7K dataOut流端口是共耗的。这意味着Housekeeping Data流类别中流属性的方向会针对那个流端口反转。

另一种那个流端口是原子流端口。图1.11显示了这种端口

的例子。当你需要为 能够通过那个端口流人或流出的单一类型项目建模时，就会添加原子流端口。小方块 中的符号是一个箭头，表示流的方向。原子流端口的类型必须是你在模型层级结构某 种定义的值类型、模块或者信号的名称。

图3.13显示Modulator模块和Transmitter模块拥有名为coupler的原子流端口， 类型是同样的值类型Radio Frequency cycle。这些端口只在流的方向上有所不问。这 个模型表示射频信号可以通过耦合器——位于各自边界上的交互点——从发射机传递 到调制器上。

3.4.2行为特性

我在上一部分讨论的所有特性都是结构特性。然而，在大多数建模项目中，仅指 定模块的组成部分、引用、约束、值属性和端口是不够的。它们确实很重要，但只传 递了设计一个方面的信息。同样重要的方面是模块能够执行的一系列行为。通过为模 块添加行为特性，你可以传递设计的这方面信息。

SysML提供了两种类型的行为特性：操作(operation)和接收(reception)。 我之前在3.4.1节讨论接口的时候对其进行了简要的说明。然而，它们不仅限于接 口使用。你还可以为模块添加操作和接收。决定直接把行为特性添加在模块上还 是添加到(模块提供或者需要的)接口上取决于你选择的建模方法以及设计原则。 SysML不会指定任何一种，而且在两种情况下显示操作和接受信息的格式也是一 样的。

现在让我们详细看一下这两种行为特性。

1. 操作

操作代表客户端调用模块的时候它所执行的行为。正式的说法是，操作是由调用 事件触发的。

常见的情况下，操作代表的是一种同步行为。这意味着调用者会一直等待行为 结束，然后再继续自身的执行。然而，SysML不需要这样;你可以把任何行为表示为 操作——即便调用者没有等待它完成。

你会在BDD中把操作表示为模块操作分隔框中的字符串(如图1.14所示)。那个 字符串的格式会是下面这样：

〈operation name> ( ) ; [〈multiplicity〉]

操作名称是由建模者定义的。参数列表是由逗号分隔，拥有零个或多个参数的列 表。(每种参数的格式都会简短显示。)返回值(如果有)必须是你在系统模型中某处 创建的值类型或者模块的名称。多重性会约束操作完成时能够给调用方返回类型的实 例的数量。

参数列表中的参数代表操作的输人和输出。列表中的每个参数都会以下面的格式 显示：

方向可以是in、out或inout。参数名称是由建模者定义的。类型必须是在你的 模型某处存在的值类型或者模块的名称。多重性会约束参数能够代表的类型实例的数 量。当操作被调用时，如果没有指定一个值作为参数，则赋予参数默认值。

图1.14显示电子电力子系统模块和通信及数据处理子系统模块都拥有多种操 作——它们代表的是，如果在系统操作中被调用，这些模块的实例能够执行的行为。 操作的一个例子是processCommand。这个模型表不客户端可以调用通信和数据处理 子系统来执行这种操作。当调用的时候，客户端可以传递给操作一个或多个命令作为 输人，当操作完成时，它会给调用方返回状态值。

给你一些建议：使用动词短语(像processCommand)为操作命名是很好的;毕 竟操作代表的是行为。另外，不要让参数列表过多;只是向模块添加操作(不指定参 数)通常就足够保证模型的准确性了。如果你的团队需要在系统模型中为操作指定参 数，那么一定要准确判断选择哪些显示在特定的BDD上;就算只是显示了几个参数， 操作的完整字符串也会在BDD上占用大量空间。

2. 接收

接收代表一种行为，当客户端发送信号来触发的时候，模块就会执行这种行为。 正式的说法是，接收是由信号事件触发的。

接收和操作之间的关键区别在于，接收总是代表一种异步的行为。这意味着客户 端发送信号——会触发接收操作来接收它——然后立刻继续自身的执行，它不会等待 接收完成(甚至都不会等待它开始)。

另一个关键点是，信号本身也是一种模型元素。你可以使用信号来代表任意类型的事件、能量和数据，它们都是系统的一部分传递给另一部分的 般的目的是要触发接收端的行为。和模块一样，信号可以有属性。大多数情况下，那些属性代表信 号从客户端到目的地所传递的数据。当信号到达目的地并触发接收动作的时候，信号 的属性就会成为接收动作的输入。

图3.15显示了名为AnalogTempDataSampIed的信号。这个信号有两种属性： temp (类型是摄氏度)和time (类型是TimeStamp)。当客户端在系统操作过程中生成这个信号的实例吋，就可以为这两个属性提供值。客户端可以把信号实例发送给接 受它的目的地(例如，图1.16中所显示的通信和数据处理子系统模块)。

如果信号的地拥有和信号名称相同的接收，那么这种结构就是无效的。此 外，接收必须拥有和信号的每个属性类型兼容的参数。通信和数据处理子系统模块符 合这些标准。当操作系统中这个模块的一个实例接收了 AnalogTempDataSampled信 号的实例，那么就会触发接收行为，信号的两个属性中持有的值就会成为那种行为的 输入。

当你在模块的接收分隔框中显示接收的时候，会显示下面这种格式的字符串：

关键字<>必须总是作为接收名称的前缀。正如之前提到的，接收名称 必须与模型中触发它的信号名称匹配。只要有必要，你在参数列表中可以显示任意多 个参数。列表中的每个参数都会以下面的这样格式显示：

参数名称是由建模者定义的。类型必须是在你的模型某处存在的值类型或者模块 的名称。多重性会约束参数可以代表的类型实例的数量。如果在信号相关属性中没有 提供任何值，那么默认值就是赋予参数的值。

和操作不同，接收无法拥有返回值。接收是异步的;发送信号的客户端不会等待 回复。因为同样的原因，接收的参数只能是输入而不可能是输出。

3.5关联：属性的另一种表示法

3.4节关注的是模块以及它能够拥有的各种各样的属性。模块是系统结构化模型 的重要部分，而模块之间的关系至少要和它们同等重要。

在模块之间可以存在三种主要类型的关系：关联、泛化和依赖。1.6节和1.7节分别详细讨论泛化和依赖。这个小节中我会专门讨论关联。

在3.4.1节中讨论引用属性和组成部分属性的部分，顺带提到了模块间的关联。 让我们重新回顾一下关键的知识点：引用属性代表模块外部的结构——模块因为某种 目的需要与之连接的结构。组成部分属性代表的是模块内部的结构——换句话说，是 构成模块的结构。

引用属性和组成部分属性分别和经常在模块之间创建并在BDD中显示的两类关 联相关：引用关联和构成关联。关联只是表示系统中这些结构化关系的另一种标识法。 让我们详细看一下这两种关联。

3.5.1引用关联

两个模块之间的引用关联意味着操作系统的那些模块的实例之间可以存在一种连 接。那些实例可以跨越连接为了某种目的彼此访问。

BDD中引用关联的标识法是两个模块之间的实线。如果一端有箭头表示单向的 访问，如果两端都没有箭头则表示双向访问。

图3.17上面的BDD显示的是电子电力子系统模块与飞行计算机模块之间的引用 关联。关联可以有多种标签。你可以选择在线的中间位置显示关联的名称，还可以选 择在线的任一端显示角色名称和多重性。关联名称是由建模者定义的字符串，描述能 够存在于两个模块的实例之间的关联类型。例如，在图1.17中，引用关联的名称是 电力电缆，这个名称描述的是一种关联类型，它可以存在于正确组装的卫星中电子电 力子系统和飞行计算机之间。

显示在引用关联末尾的角色名称与引用属性的名称相关——引用属性属于另一端 的模块，它的类型是与之连接的下一个模块。例如，在图1.17上面的BDD中，角 色名称eps代表属于飞行计算机模块的一个引用属性，它的类型是电子电力子系统模 块。角色名称fc代表属于电子电力子系统模块的引用属性，它的类型是飞行计算机 摸块。图1.17中下面的BDD显示的是同一模型的等价视图，只是它使用的是引用分 隔框标识法，而不是引用关联。

类似地，在引用关联的一端(接近于角色名称)显示的多重性与同一引用属性的 多.f(性相关。这种相关性也反映在图1.17的两个BDD中。

有时候模块会拥有同样类型的多个引用属性(如图1.18中飞行计算机模块中的引 州分隔框所示)。你也可以通过在同样的两个模块(如图1.18在飞行计算机模块和星 球传感器模块之间所示)之间绘制多个引用关联来表达。每种引用关联都代表不同的 引用厲性。在同一幅图中显示两种标识法是多余的。我之所以在这里这么做，只是为 了说明这些相关概念之间的联系。

选择使用引用分隔框标识法还是引用关联取决于你要在BDD上暴露多少信息。 例如，在图1.18中，引用关联标识法可以暴露星球传感器模块的值属性;与之相比, 引用分隔框标识法就会隐藏星球传感器模块的所有特性。

在做决定的时候，另一个需要考虑的因素是在1BD中是否需要为连接器指定类 型。如果你想要这么做，那么就需要在两个模块之间创建引用关联，并为其命名。在 这种情况下，分隔框标识法无法满足你的需求。

3.5.2组合关联

两个模块之间的组合关联表示结构上的分解。组合端的模块实例由一些组成部分 端模块的实例组合而成。

BDD中组合关联的标识法是两个模块之间的实线，在组合端有实心的菱形。在 组成部分端有箭头表示从组合端对组成部分的单向访问，如果没有箭头则表示双向访 问(也就是说，组成部分拥有对组合的引用)。

图3.19显示了从DellSat-77卫星模块到子系统模块的四种组合关联的例子。(组 合端的实心菱形可以重合为一个，而且这也是常用的方式。)这幅BDD表示正确制造 和组装的DellSat-77卫星会由一个电子电力子系统、一个高度及轨道控制子系统、一 个环境控制子系统以及一个通信和数据处理子系统构成，允许的实例数量由四个组合 关联组成部分端的多重性表示。

在组合关联的组成部分端显示的角色名称与组成部分属性的名称相关，那个属 性由组合端的模块所有，它的类型是组成部分端的模块。例如，在图3.19中，角色 aocs代表DellSat-77卫星模块拥有的组成部分属性，它的类型是高度和轨道控制子系 统模块。这种相关性以类似的方式反映在DellSat-77卫星模块的组成部分分隔框中。 在同一幅图中显示组成部分分隔框标识法和组合关联是多余的;我在此这样做是为了 加强这些概念之间的联系。

组合关联组成部分端的多重性并不是必须的;组合结构可以由任意多个组成部分 的实例组成，然而很多系统都需要说明。

然而，在组合端的多重性是必需的。根据定义，一个组成部分一次只能属于一个 组合体。因此，组合端的多重性的上限必须总是1 (如图3.19所示)。多重性的下限 可以是0或者。下限为0表示组成部分可以从组合结构中移除;下限为1表示不能 移除(在有效的系统实例中，它必须总是依附于组合结构)。

3.4.1节提到过在SysML中，元素的默认多重性总是1。然而，这个规则有一种 重要的例外情况，就在这里：组合关联的组合端默认多重性是0..1。(然而，在组成部 分端，默认的多重性还是通常情况。

有时候模块会拥有相同类型的多个组成部分属性(正如图1.20中通信和数据处理 子系统组成部分分隔框中所示)。你也可以通过在相同点两个模块之间绘制多条组合 关联表达这个意义(从通信和数据处理子系统模块到飞行计算机模块的关系如图1.20 所示)。每个组合关联都代表不同的组成部分属性。

3.6泛化

泛化是你通常会在BDD中显示的另一种关系。这种关系表示两种元素之间的继 承关系：一个更加一般化的元素，叫做超类型，以及一个更具体的元素，叫做子类型。 你使用泛化在系统模型中创建分类树(类型层级关系)。

泛化的标识法是一条实线，在超类型的一端带有空心的三角箭头。这种关系 从子类型向超类型读作“……是一种……”。例如，图1.21中的BDD显示从 Gyroscope模块向Sensor模块的泛化关系。这种关系表7示—个陀螺仪是一种传 感器。

如果同一幅BDD中显示一个超类型有多个子类型，那么建模者通常会在超类型 端重叠空心的三角箭头，从而节省图上的空间(如图1.21所示)。纯粹主义者会告诉你，重叠那些箭头实际上表示对子类型的特殊分组，叫做泛化集。这是语言一种稍高 一级的特性，你稍后会发现这很有用。就现在而言，尽管把那些箭头重合了以提高图 的可读性。

一个关键的问题是，泛化是可传递的。图1.21中的模型显示，星球地图仪是一 种星球传感器，而星球传感器又是一种传感器。因此，星球地图仪就是一种传感器。 模塑中的类型层级结构可以达到任意深度。

泛化表示子类型会继承超类型的所有特性：结构化特性(属性)和行为特性(操 作和接收)。除了它继承的特性之外，子类型还可能拥有超类型所不具备的其他特性。 因此，建模者通常会称子类型是超类型的一种特殊情况。

例如，星球传感器模块是传感器模块的一种特殊情况。它从传感器模块继承 了四种值厲性以及三种操作，并且添加了第五种值属性：分辨率(resolution)，而 传感器模块并不具备这种属性。类似地，星球地图仪模块从星球传感器模块继承 了五种值屈性以及三种操作，然后添加了两种新的、超类型并不具备的值属性 (hasAutonomousMode 和 maxNumStarsMapped)你创逑泛化关系是为了在系统设计中定义抽象。一种超类型(像传感器模块)是对 其子类SI的一种抽象，它会抽取子类型中共通的那些特性。抽象让你可以在模型中的 一个地方——在超类型中——定义通用特性，那些通用特性会沿着类型层级关系传播 到所有子类型中。如果之后你需要修改那些通用特性，只需要回到模型中的一个位 置并修改，这样模型中的所有子类型就会马上更新。

抽象是非常强大的设计原则;它表示的是可置换性，意味着在需要超类型的地 方，也会接受子类型。例如，图1.22显示，飞行计算机模块拥有传感器类型名为 sensorArray的引用属性。这个模型表示飞行计算机可能需要访问一个或者多个对所 有传感器通用的特性——结构化或者行为特性。因此，Sensor的五种子类型对于飞 行计算机都是可以接受的，因为所有类型都从超类型Sensor那里继承了那些通用的 特性。

这是针对抽象的设计的例子。这种实践在设计中创造了可扩展性。如果客户的 需求在生命周期中发生变更，你需要向卫星设计中添加一种新类型的传感器，那么 你只需要在系统模型中定义Sensor模块新的子类型，这项添加操作对于所有引用了 Sensor模块的客户端(像飞行计算机)来说都是透明的。因为所有这些原因.把泛化 构建到你的模型中，在生命周期进展，你需要修改系统设计时候，它会大大减少所需的时间——这种功能会直接转化为成本上的节省。

3.8执行者

执行者代表某人或者某件事物，它拥有系统的外部接口。执行者的名称表示人、 组织或者其他系统在与你的系统交互时所扮演的角色。

SysML为执行者定义了两种标识法：一种是火柴人，一种是在名称前面带有关键 字《1￡;1(^>>的矩形。图1.24显示了两种标识法的例子。对于任意类型的执行者—— 人或者系统——使用任意一种标记法都是合法的。然而，建模者通常会采用火柴人图 形标识法来代表人，矩形标识法来代表系统，尽管语言并没有对此做出严格规定。

你偶尔会在BDD中显示执行者，来说明执行者之间或者执行者和模块之间关联 的泛化关系(如图1.24所示)。但是，更常见的是在用例图中显示执行者，其中你表达的是每个执行者参与了哪种用例。我会在第5章中详细讨论这个话题。

当执行者涉及泛化、引用关联以及组合关联这些关系的时候，所有关于那些关系 的关键点也全部适用。但有两条约束：

□你无法在执行者和模块之间定义泛化。

□执行者不能拥有组成部分;也就是说，它无法出现在组合关联的组合端(我们 总是认为执行者是一个“黑盒”)。

3.9值类型

和模块一样，值类型也是一种定义元素 般会定义一种数量类型。我之所以说“一般"，是因为在SysML中有两种值类型——布尔型和字符串型——并不是数量。

你可以在模型中很多地方使用值类型。常见的情况下，它会以值属性——模 块的一种结构化特性——类型出现(1.4.1节中有更多细节)。但是那并不是值类 型出现的唯一地方，在系统模型中它会经常出现。它还可以作为以下情况中的类型 出现：

□模块或者执行者的原子流端口 □流规格中的流属性 □约束模块中的约束参数

□连接器上的条目流和条目属性

□操作的返回值

□操作和接收的参数

□活动中的对象节点、固定点和活动参数

你通常可以在系统模型中定义三种值类型——原始值类型、结构值类型和枚举值 类型。原始值类型没有任何内部结构(它不拥有任何值属性)。它的标识法是名称前 带有元类1 塑?valueType?的矩形。

SysML定义了四种原始值类型：String、Boolean、Integer和Real。当然，你可 以定义向己的原始值类型，作为这四种类型的特殊情况(子类型)。例如，图3.25显 示了三种值类型(。、V和它们都是Real型的子类型。

顾名思义，结构值类型拥有内部结构 般是两种或多种值属性。和原始值类型一样，结构值类型的标识法也是名称前面带有<01丨1^丁706?的矩形。SysML定义/ 一种结构值类型：Complex。它的结构包括两个值属性 realPart和imaginaryPart 二者都是Real类型。一种结构值类型可能会是另一种结构值类型中的值属性类型。这样，你可以创建值类型任意复杂的系统。

枚举值类型——通常叫做枚举——只定义一系列数值(有效的值)。如果一项 操作的参数(或者在之前的项目列表中显示的某种其他类型元素)的类型是枚举， 那么它在任何时候所持有的值必须是枚举中的值。图1.25中的BDD显示了名为 CommandKind的枚举，它定义了两个值：Stored和Real-Time。例如，我可以 使用这个枚举来定义名为buildCommand的操作中名为kind的输人参数的类型。当 客户端(在运行的系统中)调用这个操作的时候，能够通过的有效值只有Stored和 Real-Time。

我之前提到过使用泛化可以建立一种值类型和另一种之间的关系。值类型层级结 构可以有任意深度，而泛化一你可能已经回忆起来——是传递的。例如，图3.25 表示值类型VDC和VAC是Real (间接)的子类型。置换原则在此也适用，就像在模 块之间的泛化情况中适用一样：在需要VDC和VAC的超类型(V和Real)的地方. 这两个类型也是可以接受的。这些超类型都是抽象。针对抽象设计的原则——以及相 关的可扩展性一也对创建值类型层级关系的这种实践适用。这是广泛且强大的建模 实践。

3.10约束模块

和模块一样，约束模块也是一种定义元素——它定义了一种布尔型的约束表达式 (结果要么是true要么是false的表达式)。常见的情况下.你在约束模块中定义的 约束表达式是一个等式或者不等式：用来约束模块的值属性的数学关系。你之所以这 么做，可能是因为以下两种原因：

□为了在操作系统中对可用的系统值指定断言

□为了在生命周期的设计阶段执行工程分析

约束表达式中的变量叫做约束参数。一般它们代表的是数量，所以类型经常是 值类型。例如，图1.26显示的是名为Transfer Orbit Size的约束模块，它定义了 一个约束表达式，其中包含三个约束参数：semiraajorAxis、initialOrbitRadius和 finalOrbitRadiuSo这三个约束参数的类型都是值类型km。

约束参数会从它们绑定的值属性那里获得值——也就是被约束的值属性。在任意 特定的时刻，那些值要么满足约束表达式，要么不满足;系统或者是正常操作，或者 不正常。然而，要注意BDD本身无法传递约束参数和值属性是如何彼此绑定的。你 要在参数图中说明这些信息(第9章对其加以讨论)。

BDD中约束模块的标识法是名称前面带有元类型<>的矩形。约束 表达式在约束分隔框中总是会显示在大括号({})之间。约束表达式中的约束参数会 分别列在参数分隔框中。

有时候你会基于简单的约束模块构建更复杂的约束模块。这样可以从简单的等式 和不等式创建出更加复杂的数学关系。更复杂的约束模块可以把它的组成部分显示为 约束分隔框中的一系列约束属性。回顾一下1.4.1节中的内容，约束属性有名称和类 型，格式是：名称：类型。正如之前所提到的，类型必须是约束模块的名称。

例如，图1.26显示约束模块Hohmann Transfer由两个约束属性 ttof和tos 组成，这代表分别对约束模块 Transfer Time of Flight 和 Transfer Orbit Size的使用。这个模型表示Hohmann Transfer定义了一个约束表达式，它由两个更简单 的约束表达式组成，从而定义更复杂的数学关系。

但是，要注意这个BDD没有(无法)传达的信息：那两个更简单的约束表达式在 哪里指定彼此连接，从而创建组合的约束表达式。参数图会传达这些额外的信息(更 多内容请见第9章)。

你可以使用组合关联替换约束分隔框标识法，来表示一个约束模块由其他更简单 的模块组成(如图1.26所示)。注意，两个组合关联的组成部分端显示的角色名称与 Hohmann Transfer■约束模块中的约束属性的名称相关。这是等价的标识法。当你需要 暴露简单约束模块的细节时，就可以使用组合关联;当图的关注点不是那些细节时,你就可以使用约束分隔框标识法来隐藏它们。

3.11注释

SysML有很多规则(它们之所以存在，是出于一个很实用的目的：让你的设计在 大家传看的时候不会引起歧义)。然而，你有时候需要在图中以不受约束的方式在文 本框中表达一些信息，使用注释就可以做到这一点。

实际上，注释是一种模型元素。它包含唯一的属性：一段文字，我们称之为注释 体。你可以在注释体中传递任何需要的信息，你还可以选择在图中把注释附加给其他 元素，以提供关于它的额外信息。你可以在所有九种SysML图中使用注释。

注释的标识法通常是一个笔记符号：一个矩形，右上角有折角。你可以使用虚线 把注释附加给其他元素(如图1.27显示的BDD的底部所示)。如果需要，你可以把 注释同时附加给多个模型元素，每个使用一条单独的虚线。

建模者有时会在图中放置单独的带有超链接的注释，让读者可以快速导航到模 型的相关图(或者一个外部文档)。图1.27中BDD的左上角就显示了一个这样的例 子。但是，你要清楚，这是你使用的建模工具的一种功能，并非所有工具都支持。而 SysML没有任何对这项功能的叙述。

SysML定义了一些特殊类型的注释：原理、问题和图的描述。它们都显示为笔记 符号，只是注释体前面会分別带有不同的元类型。图1.27在BDD的右上角显示了一 个图描述注释的例子。原理注释通常会和需求关系或分配一起使用。第11章、第12 章会详细讨论这些话题。

小结

当你创建用来沟通系统设计的结构化信息时，BDD是主要的一类用图。BDD 能够说明在系统内部以及系统外部环境中存在的结构类型。你还可以使用BDD来说 明每种结构提供和需要的服务类型、每种结构必须遵循的约束类型，以及可以存在于 运作的系统中的值类型。

元素之间的泛化关系让你可以定义类型的层级关系以及针对抽象设计。这是一 种强大的设计技术——通过解耦服务的客户端和提供那些服务的特定提供者，从而 在系统设计中实现可扩展性。当利益相关者的需求随着时间的推移而发展的时候， 你可以修改现存的提供者，或者添加新的提供者，从而小化对其他系统设计的影响。