Appearance
UML 概述
UML（统一建模语言）是可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发全过程。
三大结构
UML 三大结构：
| 组成部分 | 说明 |
|---|---|
| 构造块 | 事物（thing）+ 关系（relationship）+ 图（diagram） |
| 规则 | 构造块如何放在一起的规定 |
| 公共机制 | 达到特定目标的公共 UML 方法 |
事物
- 结构事物：模型的静态部分，如类、接口、用例、构件等：
- 行为事物：模型的动态部分，如交互、活动、状态机：
- 分组事物：模型的组织部分，如包；
- 注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。
关系
| 关系 | 说明 | UML 表示 |
|---|---|---|
| 依赖（Dependency） | 一个事物发生变化会影响另一个事物，短暂非持久 | 虚线箭头 |
| 关联（Association） | 类之间的某种联系，通常是双向的 | 实线 |
| 泛化（Generalization） | 一般与特殊的关系（继承） | 实线空心三角箭头 |
| 实现（Realization） | 类实现接口 | 虚线空心三角箭头 |
聚集 vs 组合（关联的特殊类型）：
| 对比 | 聚集（Aggregation） | 组合（Composition） |
|---|---|---|
| 关系强度 | 较弱 | 较强 |
| 整体-部分 | 部分可脱离整体独立存在 | 部分不能脱离整体单独存在 |
| 示例 | 大学→学生（学生可独立存在） | 大学→系（系不能脱离大学） |
口诀：聚集整体散，组合整体断。
关系 UML 图形代号
聚合
用例建模
参与者（Actor）：与系统交互的外部实体，可以是人、外部系统、时间、设备（如打印机）。
UML 图关系
用例关系包括：
用例关系三种类型：
| 关系 | 说明 | 典型场景 |
|---|---|---|
| 包含（Include） | 一个用例无条件使用另一个用例的行为 | 注册课程必先登录系统 |
| 扩展（Extend） | 一个用例在特定条件下扩展另一个用例 | 不及格才参加补考 |
| 泛化（Generalization） | 用例之间的继承关系 | 一般用例→特殊用例 |
建模过程
?? 这个 是哪个部分的内容
利用 UML 构建三类模型：
| 模型 | 构建方式 | 产物 |
|---|---|---|
| 用例模型 | 分析需求行为，按 OO 原则划分为用例 | 用例图 + 顺序图 |
| 分析模型 | 在用例基础上抽象类，明确关系构建类图 | 类图 + 领域概念模型 |
| 设计模型 | 补充状态图/活动图/协作图等描述内部处理细节 | 完整 UML 模型 |
UML 图
UML2.0图，书上是13种，实际还包含制品图，一共14种，了解即可，总分类如下：
静态图（描述系统静态结构）
| 图 | 说明 | 关键记忆 |
|---|---|---|
| 类图 | 系统的静态设计视图，展现类及其关系 | 最核心的静态图 |
| 对象图 | 展现某一时刻一组对象及关系 | 类图的实例 |
| 用例图 | 描述系统功能需求和参与者 | 需求分析阶段使用 |
| 构件图（组件图） | 展现一组构件之间的组织和依赖 | 物理实现层面 |
| 部署图 | 系统静态部署视图，软硬件映射 | 拓扑结构、系统安装 |
类图
类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和它们之间的关系。
UML类图如下：
对象图
对象图：静态图，展现某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。如下：
用例图
用例图：静态图，展现了一组用例、参与者以及它们之间的关系。
用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。
如下：
构件图
构件图（组件图)：静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖。如下：
部署图
部署图：静态图，为系统静态部署视图，部署图物理模块的节点分布。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。
如下：
动态图（描述系统动态行为）
| 图 | 说明 | 关键记忆 |
|---|---|---|
| 序列图（顺序图） | 按时间顺序展示对象间交互 | 强调时间顺序 |
| 通信图（协作图） | 强调参加交互的对象的组织 | 强调对象组织结构 |
| 状态图 | 描述对象状态及状态转换 | 关注对象生命周期 |
| 活动图 | 特殊的状态图，描述活动流程 | 类似流程图，支持分支汇合 |
口诀：类对用构部 = 静态；序通状活 = 动态。序列看时间，通信看组织。
序列图
序列图：即顺序图，动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。
- 有同步消息（进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示)，
- 异步消息（发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示)、
- 返回消息（由从右到左的虚线箭头表示）三种。
如下：
上方的对象对应下方箭头上的的成员和方法。
通信图
通信图：动态图，即协作图，强调参加交互的对象的组织。如下：
状态图
状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。
转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念，
如下：图中方框代表状态，箭头上的代表触发事件，实心圆点为起点和终点。
活动图
活动图：动态图，是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。
活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。
活动图中能够并行执行的是在一个分岔粗线下的分支上的活动，如下：
UML 5 种视图
4+1 视图模型 ★
4+1 视图从 5 个视角描述软件架构，5 个视图结合才能反映全部内容。
| 视图 | 关注点 | 对应 UML 图 | 关心者 |
|---|---|---|---|
| 逻辑视图 | 系统功能需求 | 类图、对象图、状态图 | 最终用户 |
| 进程视图 | 运行特性、并发/分布/容错 | 活动图 | 系统集成人员 |
| 实现视图（开发视图） | 软件模块组织管理 | 包图、组件图 | 程序员 |
| 部署视图（物理视图） | 软件→硬件映射、拓扑结构 | 部署图 | 系统工程师 |
| 用例视图（场景） | 使4个视图有机联系 | 用例图 | 分析师/测试人员 |
SysML
SysML是一种通用图形建模语言，用于指定，分析，设计和验证可能包括硬件，软件，信息，人员，程序和设施的复杂系统。特别是，该语言提供了图形表示，其具有用于建模系统需求，行为，结构和参数的语义基础，用于与其他工程分析模型集成。
系统建模语言(SysML)已成为基于模型的系统工程(MBSE)应用程序的事实上的标准系统架构建模语言。
SysML是UML2的一种方言，它扩展了软件密集型应用程序的统一建模语言(UML)标准，使其可以成功应用于系统工程应用程序。
其实提到SysML不得不提另外一个概念：基于模型的系统工程(MBSE)。
又称基于模型的系统开发(MBSD),是一种系统工程过程范例，强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期(SDLC)中的系统工程活动。这些系统工程活动包括但不限于需求分析，功能分析，性能分析，系统设计，贸易研究，系统架构规范以及系统验证和验证。
与UML相比，SysML为系统工程师提供了以下优于指定系统的优势：
- SysML比UML更好地表达系统工程语义（符号解释）。它减少了UML的软件偏差，并为需求管理和性能分析添加了两种新的图表类型：需求图和参数图。
- SysML比UML更小，更容易学习。由于SysML删除了许多以软件为中心和无偿的构造，因此在图表类型(9对13)和总结构中测量的整体语言较小。
- SysML模型管理构造支持模型，视图和视点的规范，这些规范在架构上与1EEE-Std-1471-2000(IEEE推荐的软件密集型系统架构描述实践)保持一致。
- SysML和UML间存在交集，即SysML语言中的部分图是和UML中的相应图是一致的，例如用例图。同时，SysML也有基于UML扩展而来的图，例如活动图。另外，还有一部分图是SysML所特有的，这些图与UML间没有关系，例如需求图。
SysML 图
好的，以下是与图片内容完全一致的表格文本版：
| SYSML 图 | UML 图 | 目的 |
|---|---|---|
| 活动图（ACT 或行为）：一种行为图，主要关注控制流程，以及输入转化为输出的过程。 | 活动图：对系统中任何位置的流进行建模。特别是，描述正常用户交互以及替代和例外的用例中的流程由这些活动图很好地建模。 | [行为图]活动图显示了作为控制和数据流的系统行为。 用于功能分析。 比较流程图（FBD）和扩展功能流程图（EFFBD），已经在系统工程师中常用。 |
| 模块定义图（BDD 或 bdd）：一种结构图，与内部模块图及参数图互补，用于描述系统的层次以及系统/组件的分类。 | 类图：类图表示类，它们的定义和关系问题空间中的类和实体也是解决方案空间中的详细技术实体。定义类的属性和操作包含在此类图中。类图中的关系说明了类如何与其他类交互，协作和继承。类还可以表示关系表，用户界面和控制器。 | [结构图]模块定义图将系统结构显示为组件及其属性，操作和关系。 对系统分析和设计很有用。 |
| 内部模块图（IBD 或 ibd）：一种结构图，与模块定义图及参数图互补，通过组件（Parts）、端口、连接器来用于描述系统模块的内部结构。 | 复合结构图：在运行时模拟组件或对象行为，显示系统执行期间组件的布局，关系和实例。 | [结构图] 内部模块图显示了系统组件的内部结构，包括其部件和连接器。 对系统分析和设计很有用。 |
| 包图（PKG 或 pkg）：一种结构图，以包的形式组织模型间的层级关系。 | 包图：表示系统组织的子系统和区域。它还可以模拟包之间的依赖关系，并帮助将业务实体与用户界面，数据库，安全性和管理包分开。 | [结构图]包图显示了如何将模型组织到包，视图和视点中。 对模型管理很有用。 |
| 参数图（PAR或par）：SysML特有的图，与模块定义图及参数图互补，用于说明系统的约束。 | （无对应） | [结构图]参数图显示结构元素之间的参数约束。对性能和定量分析很有用。 |
| 需求图（REQ或req）：用于表述文字化的需求、需求间的关系，以及与之存在满足、验证等关系的其他模型元素。 | （无对应） | [需求图]需求图显示了系统需求及其与其他元素的关系。 适用于需求工程，包括需求验证和确认（V&V）。 SysML还包含了分配关系的表述，包括功能到组件的分配、软件到硬件的分配以及逻辑到物理的分配。 |
| 序列图（SD或SD）：一种行为图，主要关注并精确描述系统内部不同模块间的交互。 | 序列图：根据对象的时间轴模拟对象之间的交互。对象可以在这些图上具体显示，也可以是属于类的匿名对象。 | [行为图]序列图显示系统行为作为系统组件之间的交互。 对系统分析和设计很有用。 |
| 状态机图（STM或stm）：一种行为图，主要关注系统内部模块的一系列状态以及在事件触发下的不同状态间的转换。 | 状态机图：显示内存中对象的运行时生命周期。这样的生命周期包括对象的所有状态以及状态改变的条件。 | [行为图]状态机图将系统行为显示为组件或交互响应事件时所经历的状态序列。 对系统设计和模拟/代码生成很有用。 |
| 用例图（UC或uc）：一种黑盒视图，是系统功能的高层描述，用于表达系统执行的用例以及引起系统执行行为的参与者。 | 用例图：从用户的角度提供系统或业务流程功能的概述。用户“使用”系统的方式是创建用例图的起点。 | [行为图]用例图将系统功能需求显示为对系统用户有意义的事务。 用于指定功能要求。（注意潜在的语义重叠与需求图中指定的功能需求。） |
简述版本
| SysML 图 | UML 图 | 目的 |
|---|---|---|
| 活动图（ACT 或行为图） | 活动图 | [行为图] 活动图显示了作为控制和数据流的系统行为。用于功能分析。比较流程图（FBD）和扩展功能流程图（EFFBD），已经在系统工程师中常用。 |
| 模块定义图（BDD 或 bdd） | 类图 | [结构图] 模块定义图将系统结构显示为组件及其属性、操作和关系。对系统分析和设计很有用。 |
| 内部模块图（IBD 或 ibd） | 复合结构图 | [结构图] 内部模块图显示了系统组件的内部结构，包括其部件和连接器。对系统分析和设计很有用。 |
| 包图（PKG 或 pkg） | 包图 | [结构图] 包图显示了如何将模型组织到包、视图和视点中。对模型管理很有用。 |
| 参数图（PAR 或 par） | （SysML 特有） | [结构图] 参数图显示结构元素之间的参数约束。对性能和定量分析很有用。 |
| 需求图（REQ 或 req） | （SysML 特有） | [需求图] 需求图显示了系统需求及其与其他元素的关系。适用于需求工程，包括需求验证和确认（V&V）。SysML 还包含了分配关系的表述，包括功能到组件的分配、软件到硬件的分配以及逻辑到物理的分配。 |
| 序列图（SD 或 sd） | 序列图 | [行为图] 序列图显示系统行为作为系统组件之间的交互。对系统分析和设计很有用。 |
| 状态机图（STM 或 stm） | 状态机图 | [行为图] 状态机图将系统行为显示为组件或交互响应事件时所经历的状态序列。对系统设计和模拟/代码生成很有用。 |
| 用例图（UC 或 uc） | 用例图 | [行为图] 用例图将系统功能需求显示为对系统用户有意义的事务。用于指定功能需求。（注意潜在的语义重叠与需求图中指定的功能需求。） |
需求图：标准SysML需求包括用于指定其唯一性的标识符和需求文本两个属性，如图所示。其他属性（例如，验证状态，优先级等）也可以由用户指定。
需求关系
SysML规定了七个需求关系
1) 复合关系
复合需求可以包含需求层次结构中的子需求。复合需求可以声明系统应执行A和B,可以将其分解为系统应执行A和系统应进行B的子需求
2）派生关系
派生关系：派生的需求通常对应于系统层次结构下一级的需求。一个简单的例子是车辆加速需求，该需求被分析以导出发动机动力等方面的需求
3) 细化关系
细化关系：细化关系可用于描述如何使用模型元素或元素集进一步细化需求。例如，可以使用用例或活动图来细化基于文本的功能需求
4) 满足关系
满足关系：满足关系描述了设计或实现模型如何满足一个或多个需求。然后，系统建模者可以指定旨在满足要求的系统设计元素
5) 验证关系
验证关系：验证关系定义了测试用例或其他模型元素如何验证需求。在SysML中，测试用例或其他元素可以用作表示任何标准检验方法的通用机制，分析，演示或测试。
6) 复制关系
7) 追溯关系
模块定义图BDD和内部模块图IBD
创建 IBD是为了指定单个模块的内部结构。和BDD一样，IBD是系统或者系统一个组成部分的静态（结构化）视图。和BDD不同的是，IBD不会显示模块，它会显示对模块的使用一一也就是在 IBD头部命名的模块的组成部分属性和引用属性。
在BDD中也可以显示组成部分属性和引用属性一一或者是作为模块分隔框中的字符串，或者是作为关联一端的角色名称。但是 IBD可以表达在BDD中无法表达的信息：组成部分属性和引用属性之间的连接：在连接之间流动的事件、能量和数据的类型：以及通过连接提供和请求的服务。
IBD会表达模块的组成部分必须如何组合才能够创建有效实例。它还会显示模块的实例必须如何与外部实体（引用属性）连接，以在整体上创建系统的有效实例。
参数图
略