统一建模语言——UML（第9-20课时）（cont.）

UML概述

UML是什么

UML全称Unified Modeling Language(统一建模语言)，是一种由图形符号表达的建模语言，是用于描绘软件蓝图的标准语言，它有属于自己的标准表达规则。
UML的诞生是在当人们意识到建模、以及标准地、统一地建模的重要性。
建模的作用——
建模用通俗易懂的话来说，就是用图形和符号表示系统。通过建模可以将复杂问题分解，可以实现对系统结构的可视化控制。
UML的特点（自行在词组后加“化”字，如工程化）：
工程/规范/可视/系统/文档/智能

UML能做什么

可见，UML是不能够完全取代文字的。但是文字有其问题存在：①自然语言的二义性②文字对于创作的人要求跟高③对于阅读的人不够直观形象。


说明：
模型元素在UML所有图中保持相同的内涵。
通用机制是额外的注释、修饰和语义等。用途：允许用户对UML进行扩展。

为什么要学UML

UML的适用人群（包括但不限于）：
客户，需求分析师，系统分析师，系统设计师，架构设计师，开发工程师，测试工程师，维护工程师（对应部署图）。当中有看图也有画图的。

我们只学8种UML图，分为两大类

UML构造需求模型

用例建模技术

用例建模是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。

绘制用例图

识别执行者

1. 定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物。
2. 引入执行者目的：帮助确定系统边界
3. 识别思路：一共三类
   找“人”：
   谁使用系统？
   谁改变系统的数据？
   谁从系统获取信息？
   谁需要系统的支持以完成日常工作任务？
   谁负责维护、管理并保持系统正常运行？
   找“其它系统”：
   系统需要和哪些外部系统交互？
   例如：电商网站需要和支付系统进行交互，支付系统是电商网站的执行者
   找“自动发生的事件”：
   这些事件可以被时间、温度、湿度触发
4. 解题时窍门：把名词划线或标红，再筛选

识别用例

1. 定义：用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
2. 对于定义的理解：用例不是用例图中一个小椭圆那么简单，可以把它当作是一条由很多段“步骤”组成的路径，其中任何一小段拿出来，由于不能够实现有价值的结果，因而都不能够称作用例。注意，这个结果是要由系统能够完成的。
3. 用例要点
   ①有意义的目标
   
   注：这里涉众指的是关心系统执行的结果，但又不是执行者。例如酒店管理系统通过前台预定酒店的顾客。
   ②价值结果由系统生成
   
   图中两件事显然不是软件能直接做得到的。
   ③尽量使用业务语言，而不是只有有相关背景的人才懂的技术语言
   
   ④用户观点而非系统观点
   
   ⑤注意用例的命名（语法）
   动词+宾语
   如果不够，那就再加上状语和宾语，一定要让用例满足其他要点
   
   并且慎用意义很广的弱动词、弱名词，它们会掩盖真正的业务。
   例如
   
   ⑥用例的“粒度”
   最常犯的错误是把步骤（执行者动作/系统活动）当作用例
   
   还要警惕CRUD(增删改查)四轮马车泛滥，如果上来直接这样
   
   会使得用例图非常复杂。
   解决方案：
   ① CRUD合一成管理用户信息。
   但这样做会使得用例文档变得复杂。
   ② 善用扩展关系，把常用的当作基用例，未必执行的当作扩展用例指向基用例。

检查形式

【执行者】使用系统来【用例】

关联关系

1. 定义：在用例图中，执行者和用例，用例和用例，执行者和执行者之间的关系用一根直线来表示，称为关联关系或通信关系。
   
2. 辨析
   泛化关系：特殊指向一般
   包含关系：当多个用例间有公共行为，使用虚线+include（写在书名号内），包含指向被包含
   扩展关系：用于在基用例之上添加新的行为（扩展点），可能把基用例整个替代，扩展点指向基用例，未必执行

编写用例文档

用例文档的组成部分

其中红色是必须

详细说明

① 用例编号 最好有意义 可以采用：项目名+模块名+编号 如ROS_uc001 POS001
② 至少有一个执行者（主执行者）
③ 前置、后置条件

注意：系统必须能检测到
前置条件-开始用例前系统的环境状态（可以无）
ex:修改密码的前置条件是用户已登录（√）
ex:取款的前置条件是用户账户中有足够的余额（×，用例开始前系统检测不到余额，这个是产生扩展路径的条件）
后置条件-用例成功结束后系统应该具备的状态（必须有，否则用例无意义）
ex:取款的后置条件为更新余额（√）
④ 涉众利益：涉众可以是执行者和非执行者，但一定关心用例执行的结果
⑤ 基本路径：又叫开心路径、正常路径 是客户最想看到、最关心的路径
书写基本路径注意事项

1. 只书写“可观测”的（说人话）
   
2. 使用主动语句
   
3. 执行者应该作为动作的发出者
   
4. 每一句都要朝目标迈进
   
5. 分支和循环
   对于分支-放到扩展路径（注意可能“扩”中有“扩”）
   对于循环：直接描述
6. 不要设计页面细节
   不要出现像下拉框、按钮这样的细节，毕竟需求设计时李细节还很远，别给自己埋坑
   ⑥ 拓展路径：包括替换路径和异常路径（要非常关注扩展和异常）
   
   扩展路径是为啥有的用例可以写4面文档的原因。
   ⑦ 字段列表
   建数据库的依据
   “用户输入个人信息，个人信息详情见字段列表”
   ⑧ 业务规则
   针对字段列表中出现的数据进行约束
   ex:打折折扣在0~1之间
   ex:可按配送点名称模糊查询
   ⑨ 非功能需求
   ex:响应时间小于1s
   ⑩ 设计约束
   技术难点
   剩下的四个在一起为补充约束，当发现多个用例的补充约束相同，可以单独集中到另外文档，从用例文档指向

检查用例模型

重点检查
功能需求的完备性-有没有漏掉功能需求（非功能需求可检查其是否出现在文档）
模型是否易于理解-好的模型正确又好懂
是否存在不一致性-特别当有的图不是同一人画的
避免语义二义性

用例跟踪矩阵

状态图

定义

对于那些具有重要交互行为的类，使用状态图来描述其所有可能状态及其引起状态转移的事件。
状态图适合用于表述在不同用例之间的对象行为。
并不需要给出每个对象的状态图，实际的做法是把注意力集中在整体系统或少数关键的对象上，特别是那些状态比较多的对象。

组成元素

1. 初始状态
   往往只有1个，实心圆圈表示。
2. 终止状态
   可以有多个，内实外空的同心圆表示。
3. 中间状态
   简称状态。表示为圆角矩形，含上下两部分，上格放置状态名称，下格放置动作列表，即对象处于该状态时具有的行为/要进行的活动。
4. 转移
   用连线表示。线上标注格式 事件名[条件]/动作名/ event[condition]/action。（3部分都可缺）
   事件又称过渡事件，对应对象的动作或活动(对应中间状态的动作列表)。
   条件又叫守护条件，只有当它满足时，状态转移才会发生。
   动作对应动作列表。发生的事件可通过对象的动作进行处理。

复杂一点

1. 复合状态
   又称组合状态，可将若干状态组织在一起得到一个复合状态，包含在其中的称为子状态
   
2. 同步条
   表示同步关系，可用来分支和合并
   

活动图

定义

活动图(Activity Diagram)用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。
活动图依据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果。活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。
利用文本描述用例的事件流是很有用的，但如果事件流的逻辑复杂且有许多其他事件流，则文本形式可能较难阅读和理解，这时可使用活动图来描述事件流。
活动图是UML中的流程图，它是事件流的另一种建模方式。活动图用于以图形化的方式描述一个业务过程或者一个用例的活动的顺序流，它也可以用于建模一个操作要执行的动作，以及那些动作的结果。
活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么（对象状态改变）、何时发生（动作序列）以及在何处发生（泳道）。

作用

①描述业务流程
②描述用例路径
③描述方法执行流程（程序流程图）
其中1是活动图最主要的作用，可认为是把用例串起来。
②用顺序图更专业，但使用活动图来描述用例路径更加直观。

组成元素

1. 起始活动(start activity)
   往往只有1个，实心圆圈表示。
2. 终止活动(end activity)
   可以有0个或多个，内实外空的同心圆表示。
3. 活动(activity)
   圆角矩形表示。
   内部的文本串用来说明采取的动作。活动是指一组动作，是实现操作的一个步骤。
4. 转移(transition)或流(flow)
   活动之间的转移用箭头来表示，称为转移或流，转移是由事件的发生所引起的活动的改变，用带有箭头的实线表示。
5. 决策(decision)
   菱形符号表示。
   判定符号可以有一个或多个进入转移，两个或更多的带有守护条件的发出转移。
6. 守护条件(condition)
   需要用中括号括起来
   守护条件用来约束转移，守护条件为真时转移才可以开始。
7. 同步条(synchronization)
   一条粗黑线表示将转移分解成多个分支(fork)，同样用粗黑线来表示分支的合并(join)，这种粗黑线称为同步条。
   可以将一个转移分解成两个或更多的转移，从而导致并发的动作。所有的并行转移在合并之间必须被执行。
8. 泳道(swimlane)
   一般用垂直实线绘出，垂直线分隔的区域就是泳道。
   泳道用于划分活动图，有助于更好地理解执行活动的场所。泳道划分负责活动的对象，明确地表示哪些活动是由哪些对象进行的，每个活动只能明确地属于一个泳道。
9. 对象流
   对象流是活动与对象之间的依赖关系，可以将与活动涉及的对象放在活动图中，用一个依赖将其连接到相应的活动中，对象的这种使用方法构成了对象流。
   对象流使用带箭头的虚线表示，对象用矩形表示，矩形内是该对象的名称，名称下的方括号表示该对象此时的状态。

绘制技巧

首先要对主要的业务流建模，然后再标出分支、合并和对象流。

例

略，待加

顺序图

定义

顺序图一般用于确认和丰富一个使用情境的逻辑。
一个使用情境的逻辑或是一个用例的一部分；或是一条扩展路径；或是一个贯穿单个用例的完整路径，例如动作基本过程的逻辑描述；或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述；或是包含在几个用例中的路径。
顺序图将交互关系表现为一个二维图，纵向是时间轴(体现了“顺序”)，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色，类元角色的活动用生命线表示。

作用

①描述用例路径（for需求）
②描述对象间交互(for设计)

组成元素

1. 生命线
   一条纵向虚线表示。
2. 对象
   矩形表示。当中的对象名称标有下划线。
3. 激活
   长条的矩形表示。
   激活是过程的执行，包括等待过程执行的时间。
4. 消息
   消息是对象之间的通信，是两个对象之间的单路通信，是从发送者到接收者之间的控制信息流。
   消息分为以下几类
   
5. 交互片段
   由一个大方框包围。常用的操作符有五个
   
   其中最常用的是alt(ernative),opt,loop。分别对应if…else…,if和循环结构。

对比
状态图是一个对象跨多个用例。
顺序图是一个用例中有多个对象交互。
活动图也跨用例。
小结
复杂的图可以在活动图中套顺序图。

UML构造设计模型

类图

类的定义

类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。

单一职责原则(SRP)

single responsibility principle
这里职责指的是类承担了什么义务，包括数据职责(类的属性)和行为职责(类的操作)
违反该原则可能后果：
①难以复用
②难以维护

类图的定义

类图使用需要出现在系统内的不同的类来描述系统的静态结构(如果描绘对象动态结构则用顺序图)，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。

类图中类的表示

1. 类使用具有类名称、属性、操作分隔的长方形来表示
   其中类名称使用Pascal命名规范(每个单词首字母大写)
   属性和操作使用Camel命名规范
   
2. 类的属性
   可见性 名称：类型[= 默认值]
   其中可见性又分为
   
   类型可以是用户自定义的
   注意：名称在类型前
3. 类的操作
   可见性 名称([参数列表])[: 返回类型]

类图中的关系

对于类图中的关系，需要从以下三个方面掌握：含义、表示、实现。
含义，表示情况如下图所示。

这些关系在代码中的体现（实现）如下所示——
关联：一个类的对象作为另一个类的属性。
多重性关联中一个类的对象与另一个类的对象连接个数有以下几种情况：

提示：见到*想到可以用数组或列表表示。
例如

聚合与组合：都表示类与类之间整体与部分的关系。
不同的是：聚合关系的对象可以脱离整体对象独立存在，而组合关系中整体和部分具有统一的生命周期（同生共死）。
建议：能用聚合就不用组合。
提示：聚合关系和组合关系都属于关联关系，在PD中画图时应当先确定association，再进一步确定是aggregation还是composition。
实现：聚合关系的实现有构造注入和设值注入两种方式，组合关系的实现只能是构造注入（联系同生共死）。
例如


依赖：依赖关系的实现可以有三种方式
首先依赖不会让一个类的对象充当另一个类的成员变量
①某个类的方法使用另一个类的对象作为参数
②某个类的方法使用另一个类的对象作为局部变量
③某个类调用另一个类的静态方法



继承/泛化：这种关系在实现时对应面向对象的继承机制。Java中使用extends关键字
实现：当一个抽象类的方法全是抽象的，成员变量都是public static final，这个抽象类称为接口。接口可以继承接口，实现(implenments)则需要类来实现。

除了上述的几种关系，类图中还有一条没有箭头的虚线，称为“注释”。

包图

包图能够体现体统的分层架构。

包是什么

包是一种把元素组织到一起的通用机制，包可以嵌套于其他包中。
提示：不要想当然的认为包就是Java中的package。

包图用途

包图用于描述包与包之间的关系，包的图标是一个带标签的文件夹。

包与包之间的关系

绘制技巧

1. 两种组包方式：
   ①根据系统分层架构组包**（推荐）**
   ②根据系统业务功能模块组包
2. 参照类之间的关系确定包之间的关系
3. 包的层次控制在三层以内，子包个数控制在7±2个

组件图

定义

component diagram 又称构件图(与体系结构三要素中的构件不是一回事)
组件，即实际物理文件，可以有以下几种类型

组件图可以用来显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。

关系

泛化和依赖，取决于组件中的类之间是否存在泛化和依赖关系。

组成元素

<常用>

1. 组件
   系统中可以替换的部分，一般对应一个实际文件，如exe、jar、dll等文件，它遵循并提供了一组接口的实现。
2. 接口
   一组操作的集合，它指明了由类或组件所请求或者所提供的服务。
   说白了，就是告诉外界组件能实现的一组功能。
   
   <不常用>
3. 部件
   组件的局部实现。
   也就是组件的组成部件。
4. 端口
   被封装的组件与外界的交互点，遵循指定接口的组件通过它来收发消息。
5. 连接件
   在特定语境下组件中两个部件之间或者两个端口之间的通信关系。

使用时机

当需要把系统分成若干组件（构件），希望借助接口或组件将系统分解为低层结构并表示其相互关系时需要使用组件图。

绘制技巧

1. 注意组件的粒度，粒度过细导致系统庞大，造成管理困难。
2. 侧重于描述系统的静态实现视图的一个方面，图形不要过于简化，应该为组件图取一个直观的名称，在绘制时避免产生线的交叉。

部署图

定义

deployment diagram ，也称为实施图。和组件图一样，是面向对象系统的物理方面建模的两种图之一。
组件图是说明组件之间的逻辑关系的，而部署图则是在此基础上更进一步，描述系统硬件的物理拓扑结构及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、节点上运行的软件组件。
在UML中，部署图显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。部署图通常被认为是一个网络图或者物理架构图。

组成元素

1. 节点
   节点(Node)代表一个物理设备。在 UML 中，使用一个立方体表示一个节点。
2. 连接
   节点之间的连线表示系统之间进行交互的通信路径，在 UML 中被称为连接。
3. 组件
   组件代表可执行的物理代码模块，如一个可执行程序，逻辑上它可以与类或包对应。
   

绘制技巧

1. 部署图用于表示何者部署于何处，任何复杂的部署都可以使用部署图描述。
2. 一个部署图只是系统静态部署视图的一个图形表示，在单个部署图中不必捕获系统部署视图的所有内容。
3. 部署图一般用于：
   对嵌入式系统建模（硬件之间的交互）
   对客户端/服务器系统建模（用户界面与数据的分离）
   对分布式系统建模（多级服务器）

UML补充知识

UML总结