CPT203 Software Engineering 软件工程 Pt.3 系统建模（中英双语）

5. System Modeling（系统建模）

建模对于简化复杂系统的重要性，它通过将复杂系统抽象成适当级别的细节来简化系统。
软件开发失败主要是由以下因素导致的：
1.需求理解不清晰。
2.开发过程中经常晚期发现问题。
3.复杂性导致性能问题。

系统建模是开发系统的抽象模型的过程，每个模型呈现系统的不同视图或角度。
系统建模现在通常指的是使用某种图形符号来表示系统，而这些符号几乎总是基于统一建模语言（UML）中的符号。
系统建模有助于分析人员理解系统的功能，并且这些模型被用于与客户沟通。

可以同时针对现有系统和待开发系统开发系统模型。
1.现有系统模型用于需求工程阶段，帮助澄清现有系统的功能和用途，并可作为讨论其优势和劣势的基础。这些信息有助于确定对新系统的需求。
2.计划中系统模型用于系统设计阶段，帮助向其他系统利益相关者解释提出的需求。工程师使用这些模型来讨论设计提案，并为实施过程记录系统的相关信息。
在模型驱动的工程过程中，可以从系统模型中生成完整或部分的系统实施。这意味着系统模型可以直接用于系统实施，从而加快开发过程并减少错误。

可以开发不同的模型来从不同的视角表示系统：
1.外部视角，会对系统的上下文或环境进行建模。
2.交互视角，会对系统及其环境或者系统的构件之间的交互进行建模。
3.结构化视角，会对系统的组织或者系统所处理的数据的结果进行建模。
4.行为视角，会对系统的动态行为以及系统如何响应事件进行建模。

UML的类型有13种，但是大部分UML人员认为5种UML图足以表示系统的基本特征了。本章将关注以下5种UML图：
1.activity diagram（活动图），描述一个过程或数据处理中所包含的活动。
2.use case diagram（用况图），描述一个系统与其环境之间的交互。
3.sequence diagram（顺序图），描述参与者与系统之间以及系统构件之间的交互。
4.class diagram（类图），描述系统中的对象类以及这些类之间的联系。
5.state diagram（状态图），描述系统如何对内部和外部的事件做出响应。

在不同的情境下，系统建模有不同的作用和要求：
作为促进关于现有或拟议系统讨论的手段：在这种情况下，不完整和不正确的模型是可以接受的，因为它们的作用是支持讨论。
作为记录现有系统的一种方式：在这种情况下，模型应该是对系统的准确描述，但不一定需要完整。
作为可以用于生成系统实现的详细系统描述：在这种情况下，模型必须既正确又完整。

5.1 Context models（上下文模型）

上下文模型用于说明系统的运行环境，展示系统边界之外的内容。社会和组织上的考虑因素可能会影响决定系统边界的位置。

系统边界的建立用于定义系统内部和外部的范围。它们展示了其他系统是如何使用或依赖正在开发的系统的。
系统边界的位置对系统需求有深远的影响。
确定系统边界是一种政治性判断。在确定系统边界时，可能会受到增加或减少组织不同部分影响或工作量的压力。

下图展示了MHC-PMS系统的上下文模型。

上下文模型简单地展示了环境中的其他系统，而不展示正在开发的系统在该环境中的使用方式。上下文模型通常与其他模型一起使用，比如业务流程模型。UML活动图可以用于显示系统使用所处的业务过程。
下图展示了一个UML图，描述了MHC-PMS系统如何用于一种重要的心理监控问题治疗过程——强制留置。

5.2 Interaction models（交互模型）

建模用户交互对于识别用户需求非常重要。建模系统间的交互可以凸显可能出现的沟通问题。建模组件间的交互有助于我们了解拟议的系统结构是否能够提供所需的系统性能和可靠性。交互建模可以使用use case diagrams（用例图）和sequence diagrams（序列图）等工具。

5.2.1 Use case modeling（用况建模）

用例最初是为了支持需求获取而开发的，现在已经被纳入到UML中。每个用例代表了系统与外部交互中涉及的一个独立任务。
下图展示了MHC-PMS系统的一个用况——传输数据。

参与者可以是与系统进行交互的人员，也可以是其他系统或外部实体。
用例图通常用来图解地提供对用例的概述，以更详细的文本形式呈现。
下图展示了一个用况图。

用况图对于交互给出了一个简单的概览，在此基础上还要增加更多的细节以获得完整的交互描述。这些细节可以是简单的文本描述、使用表格的结构化描述，或者顺序图。可以根据具体的用况以及所需要的详细程度从中选择最合适的格式。
下图展示了一个“传输数据”用况的表格化描述。


复杂的用况图显示了多个不同的用况。有时候可以只是用一个复合用况图包含系统中所有可能的交互。然而，如果用况数量较多那么久无法做到了。在这种情况下，可以开发多个用况图，其中每一个显示相互关联的用况。
下图边显示了MHC-PMS系统所有的用况，其中包含参与者“医疗接待员”。在此基础上应该为其中每一个用况提供更加详细的描述。

5.2.2 Sequence diagram（顺序图）

顺序图是UML的一部分，用于建模系统内部的对象与参与者之间的交互。一个顺序图展示了在特定用例中发生的交互顺序。
在顺序图的顶部列出了涉及的对象和参与者，从它们上方垂直绘制虚线。对象之间的交互通过带有注释的箭头来表示。

下图是一个顺序图的例子。它对查看病人信息用况中所包含的交互进行了建模，其中一个医疗接待员可以看到一些病人信息。

5.3 Structural models（结构模型）

软件的结构模型显示了系统的组织结构，包括构成系统的组件以及它们之间的关系。
结构模型可以是静态模型，展示系统设计的结构，也可以是动态模型，展示系统在执行时的组织结构。
在讨论和设计系统架构时，会创建系统的结构模型。

5.3.1 Class diagrams（类图）

类图用于展示系统中的类以及这些类之间的关联，是面向对象系统模型中的重要工具。
对象类可以被理解为对系统对象一种一般性的定义。关联表示类之间存在某种关系的连接。
在软件工程过程的早期阶段开发模型时，对象代表现实世界中的某些事物，比如病人、处方、医生等。

如下图所示，这是一个简单的类图，其中显示了两个类——Patient（病人）和Patient Record（病人记录），以及它们之间的关联关系。

下一张图进一步发展了上图中的简单类图，以显示Patient类的对象还参与了一系列其他类之间的关系。这个例子中显示了对于关联关系的命名，使读者可以知道所存在的关系的类型。

这两张图都显示了类图的一个重要特性——显示有多少对象参与关联关系的能力。前一张图中关联关系的两端都标注了1，意味着这些类的对象存在一对一的关系，也就是说每个病人有且仅有一个记录，而每个记录保持一个病人的信息。后一张图中可以看到还有其他关于重数的表达。可以精确定义参与关系的对象的数量，或者可以使用一个星号（* ）来表示参与关联关系的对象数量不确定。例如后一张图中Patient（病人）和Condition（症状）之间的关系的重数（1…* )表示一个病人可能存在多种症状，而同一个症状可能与多个病人相关。

UML通过扩展表示类的简单矩形来显示属性和操作。
下图描述了这些，其中显示了一个表示医生和病人之间的诊疗的对象。

1.对象类的名称在顶部。
2.类属性在中间，其中包括属性名以及可选的属性类型。上图没有显示类型。
3.与对象类相关的操作（在Java和其他面向对象语言中称为“方法”）在矩形中最底下的部分。上图展示了一部分但不是所有的操作。

5.3.2 Generalization（泛化）

Generalization（泛化）是用于管理复杂性的一种日常技术。我们在日常生活中并不是从经理的所有事情的详细特征中进行学习的，而是学习通用的类（动物、汽车、房屋等）以及这些类的特性。在此基础上我们通过对事务进行分类来复用这些知识，并关注它们与它们所属的类之间的差异。例如，松鼠和老鼠都是“啮齿类动物”类的成员，因此共享啮齿类动物的特性。通用的陈述适合所有的类成员，例如，所有的啮齿类动物都有咬东西的牙齿。
在Java等面向对象语言中，泛化使用语言内置的类继承的机制来实现。
UML有一个特定类型的关联关系来表示泛化，如下图所示。

医生包含2种类型：Hospitial Doctor（医院医生）和General Practitioner（全科医师）

5.3.3 Aggregation（聚集）

现实世界中的对象经常由不同的部分组成。例如，一个课程的学习包可能包括一本书、PPT、课堂测验、推荐阅读。有时候需要在系统模型种描述这种组成关系。UML为此提供了一种类与类之间的特殊的关联关系类型，称为aggregation（聚集），其意思是一个对象（整体）由其他对象（部分）组成。为了定义aggregation（聚集），在链接关系中表示整体的类的那一端加上一个菱形。
下图表示一个病人记录是一个病人以及不确定数量的诊疗的聚集。也就是说，病人记录保存着病人的个人信息以及每一次医生对其的诊疗记录。

5.4 Behavioral models（行为模型）

行为模型是系统动态行为的模型，展示了系统对来自环境的刺激做出的响应或者预期的响应。
刺激可以分为两种类型：
数据：系统需要处理的数据到达。
事件：触发系统处理的某些事件发生。 事件可能会有关联的数据，尽管这并非总是如此。

5.4.1 Data-driven modeling（数据驱动的建模）

许多业务系统是数据处理系统，主要由数据驱动。它们受到系统输入数据的控制，外部事件处理相对较少。
数据驱动模型展示了处理输入数据和生成相关输出所涉及的动作顺序。
在需求分析阶段，数据驱动模型特别有用，因为它们可以展示系统中的端到端处理过程。
activity diagram（活动图）和sequence diagram（顺序图）通常用于数据驱动建模。

下图是一个简单的活动图，描述了胰岛素泵软件中所包含的处理过程链。从中可以看到表示为活动（圆角矩形）的处理步骤以及表示为对象（矩形）的在步骤间流动的数据。

如果在画顺序图时信息都是从左到右发送，那么顺序图可以描述系统中顺序化的数据处理。下图描述了这一点，使用一个顺序模型描述订单处理以及发送订单给供应商。

5.4.2 Event-driven modeling（事件驱动的建模）

实时系统通常是事件驱动的，数据处理相对较少。例如，固定电话交换系统会对“摘机”等事件做出响应，生成拨号音。
事件驱动建模展示了系统如何响应外部和内部事件。事件驱动建模基于这样的假设：系统有有限数量的状态，而事件（刺激）可能导致从一个状态转换到另一个状态。

状态机模型用于描述系统对外部和内部事件的响应。
状态机模型展示了系统对刺激的响应，因此在对实时系统进行建模时经常使用。
状态机模型将系统状态表示为节点，将事件表示为连接这些节点的弧。当事件发生时，系统会从一个状态转移到另一个状态。状态图是UML的一个重要部分，用于表示状态机模型。

下图展示了一个关于简单的微波炉控制软件的例子来介绍事件驱动的建模。

下图展现了对每个状态以及产生驱动状态转换的激励的表格化描述。

基于状态的建模的问题是，可能的状态的数量会快速增长。因此，对于大的系统模型，需要再模型中隐藏细节。一种隐藏细节的方式是使用“父状态”（superstate）的概念，在其中封装了一些独立的状态。这种父状态看起来像是高层模型中的单个状态，但是可以在另外一个图中展开以显示更多的细节。下图展示了这个概念，将前面那张状态图的Operation状态进行了展开。

Operation状态包含一些子状态。图中表明运转开始于微波炉状态检查，如果发现任何问题则会发出警报并且不允许运转。加热时会按照指定的时间允许微波炉的电机。完成加热后蜂鸣机响起。如果在运转过程中门被打开，那么系统进入不可用状态。

5.5 Summary

模型是对系统的抽象视图，忽略了系统的细节。可以开发补充系统模型来展示系统的上下文、交互、结构和行为。
上下文模型展示了被建模系统在与其他系统和流程的环境中的位置。
用例图和顺序图用于描述正在设计的系统中用户和系统之间的交互。用例描述了系统和外部参与者之间的交互；顺序图通过展示系统对象之间的交互来添加更多信息。
结构模型展示了系统的组织架构和体系结构。类图用于定义系统中类的静态结构及其关联。
行为模型用于描述执行系统的动态行为。这种行为可以从系统处理的数据的角度进行建模，也可以从刺激系统响应的事件的角度进行建模。
活动图可用于建模数据的处理，其中每个活动代表一个处理步骤。
状态图用于描述系统对内部或外部事件的响应行为。

5.6 UML图讲解

5.6.1 Use case diagram

use case由actor（参与者）和use case（用例）组成。其中用例以动词命名，每个参与者必须与一个用例相关联，而有些用例可能不与参与者相关联。
用直线连接actor和use case表示参与者可以触发或执行特定的用例。
矩形框表示系统的边界。

用例之间的关系主要有generalization（泛化）、include（包含）、extend（扩展）。
Generalization（泛化）表示子用例继承了父用例的行为和含义。和类图里的generalization类似，用箭头相连，箭头在父子例一侧。

下图展示了一个例子。

下图展示了一个更复杂的例子。

base use case（基本用例）显式地在指定位置包含另一个用例的行为。included use case（被包含的用例）永远不会独立存在，它只作为包含它的更大基本用例的一部分。与前面不同的是，这里是小箭头和虚线，而且是指向包含。

包含关系的一个重要作用是避免多次描述相同的事件流程，通过将共同的行为放在一个单独的用例中。
如图所示。

标准用例不能独立执行，必须依赖于包含用例，这导致了tight coupling（紧耦合）的关系。
下图展示了一个有关包含关系的例子。

base use case（基本用例）隐式地在特定点（称为扩展点）包含另一个用例的行为。基本用例可以独立存在，但在特定条件下，它的行为可以被另一个用例的行为所扩展。与包含类似，这里是小箭头和虚线，但事实指向被扩展。

扩展关系使得可以对可选行为或在特定条件下的分支行为进行建模。

扩展关系表示了标准用例和扩展用例之间的可选扩展关系，标准用例可以独立执行，而扩展用例是可选的。因此是loose coupling（低耦合）关系。
示例如下。

5.6.2 Sequence diagram

UML顺序图是一种用来描述对象之间消息、事件和行为流程的图表工具。它展示了对象之间交互的顺序和时间轴，并且能够展示并行处理过程和对象的激活状态。顺序图能够清晰地展示其他图表中难以描述的时间顺序。通过顺序图，系统设计者可以更好地理解系统中对象之间的交互过程，从而更好地规划和描述系统的行为。

顺序图由以下几部分组成：
participant（参与者）：在图中扮演角色的对象或实体。
message（信息）：指参与者对象之间的通信，用于表示对象之间的交互和消息传递。
axes（坐标轴）：序列图中的坐标轴包括horizontal（水平轴）和vertical（垂直轴）。horizontal（水平轴）表示参与者对象的行为顺序，vertical（垂直轴）表示时间的流逝，从上到下表示时间的流逝方向。

对象通常用带有对象类型的正方形来表示。对象类型可以是类的名称，表示对象所属的类。
如果对象的名称有助于澄清图示，应该写在正方形内。例如，"Smith:Patient"表示一个名为Smith的Patient类型对象。
对象的“Life line”（生命线）：对象的生命周期或存在时间在图中用虚线表示。生命线是一条垂直的虚线，从对象的创建开始到对象的销毁结束。

对象可以发送消息给其他对象，这些消息通常是对对象的方法调用。
如图所示，这表示 “Hospital” 对象接收到一个消息，要求它执行 “Admit” 方法，并且需要两个参数：病人的ID和房间类型。

虚线箭头表示返回。
不同的箭头头部用于表示正常/并发（异步）调用。
如下图所示。

activation（激活）。这是指在对象的生命周期线上绘制的一个粗框，表示对象的方法正在执行或者正在等待另一个对象的方法执行完毕。如下图所示

嵌套激活来表示递归。如下图所示。

frame（框架）是一个围绕部分图表的矩形框，用于指示if（条件判断）或loop（循环）结构。
if->(opt)[condition]：表示if条件判断。
if/else->(alt)[condition]：表示if/else条件判断。
loop->(loop)[condition or items to loop over]：表示循环结构。
如下图所示。

下图展示了一个以用例场景为角度展示的用户搜索书籍的过程。

5.6.3 Class diagram

类图和之前数据库的ER图比较像，我们可以使用动词名词辨别的方法去辨别类、属性和方法。
前面已经讲的足够详细了，这里补充里面的关系描述。
Composition（组合）和Aggregation（聚合）是关联的两种形式，用于描述一个对象由另一个对象组成的情况。
Composition（组合）表示一个对象是另一个对象的一部分，并且两者的生命周期是相关联的。换句话说，如果一个对象被销毁，那么它的组成部分也会被销毁。比如，一辆汽车由引擎、轮胎和座位等组成，如果汽车被销毁，那么它的组成部分也会被销毁。
Aggregation（聚合）表示一个对象包含另一个对象，但两者的生命周期可以是独立的。

聚合是一种特殊的关联关系。一个对象“包含”或“拥有”另一个对象但这种包含并不意味着完全的控制或所有权。两个对象的生命周期是相互独立的。这意味着一个对象的创建和销毁不会直接影响到聚合对象的生命周期。例如，如果一个部门被关闭，员工仍然可以存在。

组合是一种特殊的关联关系，表示一种“部分-整体”的关系。是一种强关联。
当包含对象结束其生命周期时，部门对象也随之结束。如果公司对象被销毁，那么部门对象也会被销毁。

5.6.4 Activity diagram

下图展示了一个活动图。

Initial Node：初始节点。图中用实心圆表示，代表流程的开始。
Activity：活动。图中用圆角矩形表示，代表一个行为或动作。
Object Node：对象节点。图中用矩形表示，代表流程中的一个对象。
Control Flow：控制流。图中用带箭头的实线表示，代表活动之间的顺序关系。
Decision Node：决策节点。图中用菱形表示，代表流程中的一个决策点。
Guard：守卫。在决策节点中，用方括号表示，代表决策的条件。例如图中，[order accepted]（订单被接受）或[order rejected]（订单被拒绝）。
Join Node：合并节点。图中用两条垂直线的交汇处表示，代表多个控制流的合并。
Merge Node：合并节点。图中用菱形表示，代表控制流的合并，通常在决策之后。
Activity Final Node：活动结束节点。用靶心表示，代表流程的结束。

基础模型如下。

动作代表一个操作、业务流程中的一个步骤，或者整个业务流程。动作是一个命名元素，表示活动中的单个原子步骤，即在活动中不会进一步分解的步骤。
箭头代表从一个活动到下一个活动的转换。实心圆圈表示开始，靶心表示一个终点。

下面两种都是可以的决策流程。但都使用方括号标注条件。

并发路径指的是两个或多个同时运行的路径。使用实心粗线将转换箭头分割为多个同时执行的路径，表示这些路径是并发执行的。同样，实心粗线也用于合并并发路径，表示这些路径的执行将合并为单一路径。如下图所示。

当业务流程需要发送或接收信号时，凸多边形通常用来表示发送信号或输出事件，表示业务流程向外部发送了一个信号或事件。
凹多边形通常用来表示接收信号或输入事件，表示业务流程从外部接收了一个信号或事件。

我们可以使用Swimlanes来显示每个活动的负责人，并且可以展示不同角色在业务流程中的并行执行。
如下图所示。

活动图里的活动可以接受参数，如下图所示。

还有异常处理，如下图所示。

UML2.0中添加了Flow Final Node（流程结束节点），它被用作活动结束节点的替代品，用于终止一个流程。流程结束节点只是终止它所附加的流程，而不是整个活动。例子如下。

时间事件如下。当时间表达式为真时，时间事件开始流动。
每周三会触发备份操作。

下图展示了一个更为复杂的流程结束和时间事件的例子。

5.6.5 State machine diagram

状态机图中的对象会根据事件改变它们的状态。因此我们需要先识别状态，状态分为被动状态和活动状态。
被动状态是指对象所有属性的当前状态。换句话说，它代表了对象的静态状态，不涉及对象的行为或处理过程。举例来说，对于学生类（Student class），学生的ID、姓名、入学日期等属性就代表了学生对象的被动状态。
活动状态则表示对象在持续变化或处理过程中的当前状态。举例来说，对于学生类，学生的状态可以是“新生”、“已注册”、“暂停”、“毕业”等，这些状态代表了学生对象正在经历的不同阶段或状态。
事件（有时称为触发器）的发生会迫使对象从一个活动状态转换到另一个活动状态。
现在我们回到状态机图。
举例来说，当你按下汽车的点火按钮时，汽车的引擎会从停止状态转换为启动状态；或者当烤面包机经过一定时间后，会弹出烤好的面包。这些都是对象状态根据事件发生而改变的例子。
UML状态机图记录了这些状态的变化。它展示了对象可能处于的各种状态，以及状态之间的转换过程。
状态机图显示了状态变化序列的起点和终点。它清晰地展示了对象在不同状态之间的转换路径，以及何时以及如何从一个状态转换到另一个状态。
下图展示了一个基础的状态机图。状态机图由start state（开始状态）、terminate state（终止状态）、state（状态）、transition（转换）、action（操作） and activities（活动）组成。

Start State（开始状态）表示对象的创建过程。Terminate State（终止状态）表示对象的销毁过程。

每个类都有一个或多个状态，不同的状态会导致类的不同行为。类可以通过Transition（转换）从一个状态转换到另一个状态。每个状态必须有进入和离开的转换。

转换是指从一个状态变换到另一个状态。转换的触发原因是事件或者事件满足的条件。在转换期间可能执行一些操作。
如下图所示。

三种活动：
1.Entry/Action（进入/动作）：这表示在进入状态时执行的离散动作。这些动作只会在进入状态时执行一次。
2.Do/Activity（执行/活动）：这表示在状态持续期间执行的连续活动。这些活动在状态处于活动状态时持续执行。
3.Exit/Action（退出/动作）：这表示在退出状态时执行的离散动作。这些动作只会在退出状态时执行一次。
如前面图中Heating下面的entry / Heater.start：进入加热状态时，加热器开始工作。
do / Display “Heating”：在加热过程中，显示“正在加热”的信息。
exit / Heater.stop：退出加热状态时，加热器停止工作。

关于superstate和substate在前面就讲述过。这里再给一个例子。