下载掌阅APP，畅读海量书库
立即打开
SysML是一种通用的可视化建模语言，它基于另一种通用的可视化建模语言 UML 。UML是一种深深植根于软件工程领域的语言，它的出现源于一种非常务实的需求。在1997年UML的第一个版本发布之前，有大量的建模符号和方法被用于软件工程。当时总计有超过150种不同的公认方法可供使用。
使用建模符号的目标之一是提供一种基本的通信机制。但是可用的符号太多了，这使得符号的选择既令人困惑又艰难。因此，在20世纪90年代中期，软件行业集体决定，应该使用一种单一的、标准化的、每个人都可以使用的通用语言来取代当前为数众多的语言。重要的是，该语言不应该是专有的。因此，决定由拥有、管理和配置与对象技术相关标准的国际标准机构 对象管理组 （Object Management Group，OMG）来拥有这种新语言。1997年，UML正式在软件工程界发布。
由于UML是一种通用建模语言，它实际上比软件的范围要广得多，因此它在系统工程社区中被广泛使用（Holt，2001）。UML在当时被广泛采用，以至于2004年INCOSE决定应该有一个UML的变体，可以专门应用于系统工程领域，因此SysML就诞生了。
SysML仍由OMG拥有、管理和配置，标准本身可从OMG网站下载。
SysML在技术上是UML的一种 表现方式 。可以将这两种语言之间的关系视为UML是母语，而SysML是该语言的一种方言。
本节将从讨论SysML是什么和不是什么入手。这一点很关键，因为关于SysML的性质存在许多神话。然后，本节将在较高层次上介绍九种SysML图，并提供具体的结构和行为模型示例。
许多之前的建模符号实际上是方法论，因为它们有一个内置的流程，这个流程要求它们与符号一起使用，而符号能够指出在开发中需要使用哪些图以及需要在哪个点使用。
SysML纯粹是一种表示法，没有这一流程。能否清楚地理解这一点非常重要。回顾一下图2.7和图2.8中“MBSE in a slide”的内容，SysML位于 可视化 组的右侧。SysML只是整个MBSE解决方案中的一部分，尽管是必不可少的一部分，但它并不是MBSE。
SysML可以被认为是一个包含9种图的工具箱，这些图共同实现了模型中结构和行为方面的可视化。
结构图有以下几种：
❍块定义图 （block definition diagram，bdd），它是迄今为止所有SysML图中使用最广泛的图。每个模型都会用到bdd来进行可视化，因此必须很好地掌握该图的基本知识。
❍内部块图 （internal block diagram，ibd），它是bdd的变体，用于显示特定块和配置内部的结构。
❍需求图 （requirement diagram，rd），它是一种包含特殊符号和元素的块图，可用于指定基于文本的需求或目标，以及每个元素的一组预定义属性。需求图主要用于 需求管理 ，而不是 需求工程 。
❍参数图 （parametric diagram，par），它通过使用约束（如方程和启发式）来推理块（包含在块定义图和内部块图中）的属性。par构成了MBSE建模的可视化世界与 基于模型的工程 （Model-Based Engineering，MBE）建模的形式化数学世界之间的桥梁。
❍包图 （package diagram,pd），它将其他图上的元素组收集在一起并进行分区。它是SysML图表中较少使用的一种，但“包”也可以出现在其他图表上，这是一种更典型的用法。
这里需要注意的关键点之一是，所有的结构图都是紧密相关的。其实它们都是bdd的变体，或者与bdd密切相关。当开始使用SysML时，对于模型的结构方面，最好直接默认使用bdd，并在需要时引入其他图。
行为图有以下几种：
❍用例 （use case，uc） 图 可以将高级行为可视化，例如上下文。uc图是使用更为广泛的SysML图之一，但毫无疑问也是所有SysML图中使用最为糟糕的！
❍序列图 （sequence diagram，sd）可以对场景进行建模，并关注模型元素（例如块）之间的交互。sd通常用于模型的高层，是系统模型的关键工具。
❍状态机图 （state machine diagram，smd）主要关注块自身及其实例内部的行为。状态机图通常在较低的细节级别上使用，由状态或事件驱动，在整个系统工程中广泛使用。
❍活动图 （activity diagram，ad）对特定操作中非常具体的行为进行建模。ad常用于对遗留系统进行建模和执行逆向工程。活动图基于经典的 流程图 （flow chart），而语义则基于令牌流语义，例如Petri网。由于很多人之前对该种图已经非常熟悉了，因此使用它时会感到很舒服。
行为图通常应用于不同的抽象级别，而结构图允许在同一个图上显示多个抽象级别。
同一类型（结构图或者行为图）之间以及不同类型（结构图和行为图）之间都存在着非常密切的关系。正是这些关系构成了符号和一致性检查的基础，可以用来对任一SysML模型进行检查，验证它是否符合底层SysML符号。
不过这本书不是一本专注于SysML的书，而是一本使用SysML作为首选符号的书。考虑到这一点，本书不会详细介绍SysML的完整语法，但会在使用SysML的基础知识时对其进行介绍。
下一小节将通过分析一个现有的汽车示例系统来介绍一些主要的SysML图。但本次将要使用的是SysML，而不是在本书中一直使用的“方块和直线”这类普通符号。
上文中提到，SysML中结构建模的首选图是bdd，它是术语 块定义图 的缩写。本节将介绍和讨论bdd的基础知识。不过这些都只是最基本的知识，并不是对bdd元素的详尽描述。
bdd包含以下两个主要元素：
❍块： 代表了构成系统组成部分的事物的概念。用矩形来表示块，并在其内部包含文字<<块>>。<<块>>用来说明它的构造型是UML中的 类（class） 。构造型是本书后面将讨论的高级建模概念。现在只要理解术语<<块>>是用来标识一个块的就足够了。
❍关系： 用来将系统中的一个或多个块彼此关联起来。随着本节的深入，将讨论各种类型的关系。
下面将使用具体的图来解释这两个元素（见图2.11）。
图2.11 bdd：块和块关联的简单示例
图2.11中有 司机 和 汽车 两个块，它们在某种程度上是相关的。这些块用带有术语<<块>>的矩形来表示，并且通过只在两个块之间画一条线来表示两者之间被称为 关联 的关系。
SysML图都应该能够被大声朗读出来，而且图也应该是有意义的。如果朗读这张图，将会被读作“有两个块，司机和汽车，它们之间存在某种关系”。这句话听起来不错，但没有传达太多关于汽车或司机以及他们之间关系的信息。通过添加更多与两者之间关系有关的信息，我们可以轻松强化该图，如图2.12所示。
图2.12 bdd：为关联命名
图2.12中包含了对关系的一些修饰，关联现在已被赋予了名称和方向。名称叫作 驾驶 ，方向表明该关联是从左到右来读的，由关联线上方的小三角来表示。现在该图可以被读作“司机驾驶汽车”，远比图2.11展示的内容精确得多。
块表示某种事物的概念，因此 司机 和 汽车 都表示这些名词的概念，而不是指具体的、真实的例子。对于块特定的、现实生活中的示例被称为实例。例如， 汽车 是一个概念，Jon的汽车是一个具体的、现实生活中存在的汽车的例子，因此是一个实例。
在横线上为关联命名时，通常使用动词，朗读出来的时候就形成了一个句子。本图“司机驾驶汽车”是一个非常正确的句子，几乎人人都能听懂和理解。
方向指示器表示从哪个方向来朗读关联名称，这对于图的整体含义非常重要。也可以通过省略小矩形来表示双向关联。必须小心谨慎，千万不要不小心忽略了方向，方向在SysML中是有意义的！
这张图还可以通过增加两个块之间的数字来进一步增强，如图2.13所示。
图2.13 bdd：多样性
图2.13展示了如何将数字添加到关联的各端，这在SysML中称为 多样性 。图2.13可以读作“一名司机驾驶一辆汽车”。这句话没错，但是编号有一个微妙之处，很容易被弄错。关联两端的数字不是指绝对数字，而是指关联两端每个块实例的比例。这张图乍一看只有一名司机和一辆车，但图的含义并非如此。真正的含义是，对于每一名 司机 的真实实例，都会对应一个 汽车 的真实实例。关键就在“每一名”这个词，它传达的意思比使用“一名”要明确得多。所以，图2.13应该读作“每一名司机都驾驶一辆汽车”。
关联的每一端都显示了其多样性，并且有很多标准选项可供使用：
❍1 表示1个实例，如本例所示。
❍1...＊ 表示1到多个实例。
❍0...1 表示0～1个实例。
❍0...＊ 表示0到多个实例。
❍1...10 表示范围介于1～10个实例之间。
❍2,4,6,8 表示一组实例中的某一个。
例如图2.14所示。
图2.14 bdd：添加更多的块和多样性
图2.14中增加了一个新块—— 乘客 ，并且与 汽车 相关联。图2.14中这部分读作“每辆汽车有0～4名乘客”。这次多样性表示为0...4，说明乘客是可选的，可以没有乘客。而司机是必选的，必须始终存在。
要注意的是，在编写块名称和组成关联的词时，应始终使用单数。所以块叫作乘客而不是 乘客们 ，表述关联的动词在使用英文书写时应该采用单数形式。始终以单数形式描述块和动词，同时使用多样性来暗示复数的存在。
关联通常用来表示多个块之间的关系，但是也可以用来表示自关联，即从块出发返回到自身的关系，而且多样性规则同样适用于此。
还有一种关联的变体，它表示了从一个块到一个关联而不是到另一个块的关系，如图2.15所示。
图2.15 bdd：关联块
图2.15展示了一个名为 控制面板 的 关联块 。关联块将一个块关联到一个关联上，而不是关联到另一个块上。它用来展示块之间关系或交互的详细信息。朗读关联块时可使用“通过”一词。因此图2.15读作“每一名司机通过控制面板驾驶一辆汽车”。
块可以通过识别和定义其特征来详细地描述——主要是通过描述块外观的 属性 和描述块作用的 操作 。
在描述块时，可以通过识别一些描述块特性的属性来补充更多细节，如图2.16所示。
图2.16 描述块：识别属性
图2.16为 汽车 块添加了一些用来描述其特定功能的属性，属性是通过在块名称下面添加一个独立空间来表示的，然后可以在该空间内添加很多属性。每个属性都应该只描述块的单一特征，并且使用单数名词。本例中添加了三个属性，分别是：
❍制造： 指的是汽车的制造商。
❍型号： 指的是可供购买的汽车的具体配置。
❍注册号： 指的是实际分配给汽车的唯一注册号。
每一个属性都可以采用许多不同的值，并且这些值是在块初始化时定义的。通过具有三个属性的 汽车 块来进行阐释，这三个属性会作用于所有 汽车 的实例。让我们使用“Jon的汽车”作为 汽车 块的实例，其中的属性会被赋予实际的值。如属性 制造 可以设置成 “马自达” ，属性 型号 可以设置成 “Bongo” ，以此类推。
当属性被确定后，有必要进一步详细地定义它们，以避免不必要的歧义，如图2.17所示。
图2.17 描述块：定义属性
图2.17中使用了具有三个属性的同一 汽车 块。但这一次添加了更多的信息来定义每个属性可能采用的值的性质或 类型 。在SysML中，一切东西都是“类型化的”，这意味着所有东西都必须定义它可能采用的值的类型。这些类型可能很简单，也可能很复杂。
简单类型类似于软件工程领域的标准变量类型，例如：
❍ 整数类型。
❍ 字符类型。
❍ 实数类型。
❍ 布尔类型。
这个类型列表还在持续完善，但这些都是众所周知且广为人知的成熟类型。
类型通过在属性名后加一个冒号来表示，在冒号后立即显示类型名称。还可以显示每个属性的取值范围和默认值，这些内容将在本书后续适当的地方进行描述。
也可以定义更为复杂的类型。此时可以创建另一个块，标识并定义其属性，然后将其用作类型。图2.17中块 注册号类型 就是一个示例。 注册号 属性不是一个简单类型，而是一组具有特定含义、特定顺序的字母-数字的字符构造。在英国，标准的注册号包括以下三个要素：
❍区域ID： 一组两个字母，表示汽车的产地。
❍年份ID： 一组由两个个位数组成的数字，表示汽车是哪一年、哪半年生产的。
❍号码ID： 汽车唯一标识符的最后一部分，由三个字母组成。
该块可以用作 汽车 块上 注册号 属性的类型。
在定义属性集时，SysML认为它们应该按照字母顺序而不是逻辑顺序出现。严格来说，不应该从属性集推断出任何顺序。
块的属性描述了块的外观，还可以通过描述块的操作来展示块的作用，如图2.18所示。
图2.18 描述块：识别操作
图2.18展示了一个更为完整的图，显示了到目前为止已经识别的块的更多属性。要注意的是， 司机 和 乘客 中都为 年龄 属性设定了默认值，通过在类型定义后加上等号（=）来表示。
除了属性之外， 司机 块还显示了一个额外的独立空间，其中有一个名为 驾驶 的操作。操作用来定义与特定块相关联的行为元素。应该注意的是，操作显示的是行为是什么，而不是它们如何执行行为。执行行为是通过使用SysML中的行为图来实现的。
每个操作都应该是一个动词，以反映其行为性质。操作后面有一个括号，允许定义 返回值 和各种 参数 。同样，这些内容将在本书后续内容中适时加以介绍。
与详细描述块方式相同，有几种特殊类型的关系可以将更详细的信息添加到图中。
前面已经讨论过，关系的基本类型是关联，它显示了一个或多个块之间的简单关系。在此基础上还介绍了关联块，它可以加入“通过”这一关系。
另一种标准类型的关系是SysML中的一种特殊类型的关联，称为 组合 。用于显示结构层次结构，如图2.19所示。
图2.19 描述关系：组合
图2.19展示了组合的概念，在关联的一段以实心菱形图表示。当看到这个符号时，读图时应使用 “由……组成” 或 “包括” 字样。组合应从菱形一端读起，多样性规则同样适用于此。
所以本图应读作“汽车由一个车身、一个底盘、一组内饰和一个传动系统组成”。
图中其实有四组独立的组合，每个下层块都可以被认为和上层块是一个组合。出于清晰和可读性方面的考虑，通常会把这些组合合并在一起显示，就像本图中显示的一样。
组合允许将块分解为低层级的块，以便显示其结构的层级。本图中虽然只有一级分解，但在同一个图上可以显示多个层级的分解，而且这种方式也很常见。
组合也有一种变体，被称为 聚合 。聚合也可以表达“包括”的类型关系。但主要区别在于所有权方面，如图2.20所示。
图2.20 描述关系：聚合
图2.20展示了一个更完整、更复杂的视图，是对 传动系统 块的分解。这种复杂性的增加是由于图中加入了更多的块，还显示了各块之间的关联以及组合。其中还有一个聚合，用空心菱形表示，与组合关系的实心菱形相对应。我们从以下几方面来说明组合关系和聚合关系之间的区别：
❍传动系统由一个变速器，一个或两个发动机，一个控制单元和一个电池组成。 通过组合说明该块拥有组成传动系统的四个部分。也就是说，传动系统拥有变速器、发动机、控制单元和电池。
❍传动系统包括充电器 。这是用聚合表示的，说明充电器是传动系统的一部分，但是它不属于传动系统。
这是一个十分细微而又极其重要的区别。图2.20实际上展示了传动系统由五个块组成，其中四个是它所拥有的，而另外一个不是它所拥有的。也就是说，需要充电器来确保传动系统的完整性，但充电器又属于其他的系统元素。传动系统也需要充电器，否则它将无法工作，因为没有东西可以为电池充电。
可能是由于机缘巧合，其他系统元素碰巧拥有一个充电器。因此，组合和聚合之间的区别在于所有权的不同。
组合和聚合都是特殊类型的关联，还有一种使用广泛的关系类型，它不同于关联类型。这种关系类型相当于 特殊化（specialization） 或 一般化（generalization） ，如图2.21所示。
图2.21 描述关系：特殊化和一般化
图2.21展示了对一般化和特殊化关系类型进行建模，使用一个空心三角形来表示。这是一个非常强大的概念，因为它可以对 分类层次结构（Classification Hierarchy） 或 分类法（Taxonomy） 建模。图2.21中显示 有两种类型的发动机：内燃机和电动机。此外，内燃机有两种类型：汽油发动机和柴油发动机 。
这两种不同的关系类型术语可能会引起混淆。事实上这很容易理解，一般化和特殊化之间的区别只是这种关系在阅读方向上的不同。可以通过以下两种方式来理解：
❍内燃机和电动机都是发动机的类型 。当向上阅读关系时（朝向三角形方向），块变得更抽象或更普适，这就是一般化。
❍发动机的类型分为内燃机和电动机 。当向下阅读关系时（远离三角形方向），块变得不那么抽象或变得更为具体，这就是特殊化。
所以，这种区别仅仅是阅读方向的不同，纯粹是读图人的个人偏好。当一个块存在两个特殊化的时候，必须用一些东西将它们彼此区分开来，或者使它们变得“特殊”。通常是特殊化块中特定的一组属性、操作或关系。
在展示一般化和特殊化时，有一个非常重要的概念，称为继承。它适用于分类法中与块相关的属性、操作或关系。发动机块定义了一个名为额定功率的属性。由于内燃机和电动机都是发动机的类型，因此可以假设它们也具有相同的属性，因为它们是发动机的特殊化。这就是继承，它表明与块关联的所有特殊化都会继承其所有的属性和操作。
由于内燃机和电动机都是发动机的类型，所以它们都将继承发动机块的额定功率属性。由于内燃机有两种类型——汽油发动机和柴油发动机，它们也将继承额定功率属性。继承的概念适用于所有层级的特殊化。
请注意，内燃机块拥有自己的属性即燃料类型，它只能由其特殊化继承而不能被其一般化块发动机继承。继承仅适用于特殊化而不适用于一般化。
继承的属性和操作通常不会显示在块上，因此尽管电动机块具有额定功率属性，但却没有显示在块上。例外情况是当继承的属性在某种程度上受到限制时，例如汽油发动机和柴油发动机块中继承的属性如下：
❍ 汽油发动机块显示了其继承的属性，因为属性值总是设置为 汽油 并且永远不能更改。
❍ 柴油发动机块显示了其继承的属性，因为属性值总是设置为 柴油 并且永远不能更改。
当属性具有永远无法更改的值时，它在SysML中称为 不变量 ，不变量通常是两个特殊化块之间的区别特征。
另一个在建模中需要对模型进行考虑的方面是 行为 。到目前为止，已经讨论了模型的结构方面，但是如果不对行为进行建模，模型就无法完成。
正如在使用bdd的建模结构中所看到的那样，通过组合、聚合和一般化或特殊化可以在同一个图上显示多个抽象级别。这有助于将结构展示成一个垂直的、多层级的抽象。
然而行为不是这样的。行为视图应用于单层抽象结构。这有助于将行为展示成一个水平的、单层级的抽象。
通常可以通过以下方式来应用水平层级：
❍最高的上下文层级： 侧重于系统与系统或者干系人之间的交互，并允许对跨系统边界的交互进行建模。在这个级别上使用的SysML图最典型的就是用例图和序列图。
❍高层级，系统元素之间： 关注系统元素之间的交互，如bdd中的各个块。在此级别使用的典型图是序列图。
❍中层级，系统元素内： 侧重于单个系统元素内的交互，如bdd中的单个块。在此级别使用的典型图是状态机图。
❍低层级，系统元素行为内： 侧重于单个系统元素行为内的交互，如对bdd中块的操作。在此级别使用的典型图是活动图。
需要强调的是，上述提到的图都是各个层级中使用的最为典型的图。此外列举的各个层级也是普适的。
所有这些的共同点是交互一词，因为行为建模关注的是交互如何在不同的抽象层级上发生。
为了说明行为建模，在第一个示例中将只考虑其中的两个层级：系统元素内和系统元素之间的交互建模。
要考虑的第一个抽象级别是中层级，在这里我们将会研究系统元素内的交互。
在SysML中，块图中的块都可以使用状态机图来定义其行为，如图2.22所示。
图2.22 关于充电器和电池
图2.22展示的bdd是图2.20中的子集，但特意只展示了 电池 和 充电器 块。请留意每个块中定义的功能，包括属性和操作。通常情况下，会先展示一个不含任何特性的高层级视图，然后将重点放在显示这些特性的单独视图的子集上。
每个块都可以用状态机图来定义其行为，如图2.23所示。
图2.23展示了系统元素内的行为，本例是使用状态机图来表示的电池块的行为。为在概念级别具有行为的每个系统元素创建状态机。在SysML术语中，这意味着将为特定块定义状态机图。这个状态机跟块一样都是概念性的。当块被实例化时，它的状态机就会被执行。
图2.23 系统元素内的行为建模——电池的状态机图
如果一个块被多次实例化，那么相同的状态机会被多次复制并执行。因此可以同时执行同一状态机的多个副本，这也是常见的做法。为块定义一次状态机，然后为每个实例执行。
状态机的基本模型元素如下：
❍状态 ，描述了块在执行流程中特定时刻的情况。
❍转换 ，表示离开一种状态并执行另一种状态的合法路径。
❍事件 和 条件 ，显示必须满足哪些场景才能执行并完成一次转换。
如图2.23所示，状态分为三种：
❍开始状态 ，由实心圆圈表示，代表实例的创建或块的诞生。
❍结束状态 ，由同心圆圈表示，代表块的销毁或生命周期的结束。
❍状态 ，由圆角框表示，代表块满足特定条件、正在执行操作或正在等待其他事情发生的特定时刻。
图2.23中有许多转换，通过带有箭头的有向线条来表示。这些转换代表了各种状态直接可能的执行路径。
除此之外还有两种类型的事件可以用图来表示，分别是：
❍发送事件 ，表示在状态机边界之外发送某种 消息 ，用具有凸出部位的五边形表示。
❍接受事件 ，表示从状态机边界外接收某种消息，用具有凹进部位的五边形表示。
图2.23中还显示了两个条件，每个条件都用 方括号（[]） 表示。用菱形表示逻辑判断。当做出决策并检查属性的值时，该属性必须存在于拥有状态机图的块上。
这是关于两种不同类型图之间一致性众多示例中的第一个。当考虑多个图时，检查的关键点之一就是不同图之间的一致性。请记住，图片和模型的区别在于一致性。在图2.23中，可以看到决策检查中会被检查的属性也出现在父块中。下面我们将会讨论更多关于一致性的例子，如图2.24所示。
图2.24 系统元素中的行为建模——充电器的状态机图
图2.24显示了充电器的状态机图，展示了关于充电器父块的更多细节和一致性。
图2.24展示了一些明确的可执行行为，这些行为可以在SysML中定义为两个粒度级别。
❍行动 （Action）：原子行为。一旦开始，就无法中断。因此，就执行行动所花费的时间而言，行动通常很短，但也并非总是如此。许多人认为行动是瞬时的，不需要花费时间，尽管这是不可能的。表示行动时由/符合开头，后跟具体的行动。图2.24中，这些行动用于显示状态属性的值如何在状态机中的不同位置进行设置。行动可能存在于转换过程或状态内部。
❍活动 （Activity）：非原子行为。即使开始，也可能会被中断。因此，活动通常被视为很耗时。表示活动时由do关键字开头，然后是/，接着引用来自父块的操作。活动显示在块内，不会显示在转换过程。
在使用行动和活动时，可以将行为添加到状态机上，并强制与父块保持一致。
在收发事件时同样要强制保持一致性，这些事件可以跨状态机边界来进行收发。例如发送 开始充电 和 开始放电 事件时，肯定会有某些地方来接收这些事件。
让我们再回到图2.23所示的 电池 状态机图。我们也可以看到相同的消息，但这次是接收事件。请记住，发送事件和接收事件会显示广播和消息的接收方，这些内容都必须保持一致。
使用序列图对系统元素之间的行为进行建模，我们可以在更高的抽象级别对行为建模进行观察，如图2.25所示。
图2.25 系统元素之间的行为建模——基本充电场景的序列图
图2.25显示了一个使用序列图在系统元素之间进行行为建模的例子。序列图是所有行为图中使用最为广泛的。它的用途有很多种，本书将不断对其进行探索。在第一个实例中，序列图旨在帮助我们理解在简单的 场景 中消息是如何在系统元素之间传递的。场景可以显示导致特定结果的特定事件序列，并可以探索“有哪些可能的情况”。不同于状态机图，它不能在一个图上显示所有可能的执行路径，这就是为什么对于交互块的不同组合通常会有好几个场景（使用序列图）。
组成序列图的基本建模元素如下：
❍生命线： 表示要显示的实例。用前面带有冒号的块名的方框来表示。方框下面有一条虚线，表示逻辑上时间的流逝或者进入或离开生命线的交互序列。由于生命线代表实例的集合，因此它必须直接与块相关。
❍交互： 表示不同生命线之间的交流，并使信息流可视化。交互是来自块图的关联实例，并显示可以在其他行为图（如状态机图）中看到的消息。
❍门： 表示序列图的入口点，但不一定显示它来自哪里，用小方框来表示。
图2.25中序列图所展示的内容如下：
❍ 生命线 ：电池 和 ：充电器 与bdd中的 电池 和 充电器 块一致。
❍ 交互 插入 和 开始充电 与bdd中的关联 充电 一致。
❍ 自交互 关闭 与bdd中的操作 关闭 一致。
❍ 交互 开始充电 和 开始放电 与状态机图中的事件 开始充电 和 开始放电 一致。
该序列图显示了一个简单常规场景，插入 充电器 后， 电池 成功充电。当然，还有许多其他常规场景，例如放电。场景建模的强大用途之一是显示异常或非典型的场景，例如出现错误的情况。常规场景和异常场景的组合通常被称为 晴天 和 雨天 场景建模。当考虑需求建模时，我们将更详细地探讨这一点。