个人见解_用例图类图活动图等

图示主要参考如下文章：
UML小结以及基于领域模型的系统设计初步：https://www.cnblogs.com/colder/archive/2012/03/06/2381653.html

用例图(一句话需求,要啥功能)

它从外部角色的视角来展示系统的功能，用例视图是系统中与实现无关的视图。

用例的价值
系统分析员在接手一个系统后﹐首先要做到的事情就是得出系统的服务和服务场景。也就是我们经常所讲的用例(use case)
很多人不清楚清晰的用例的价值，只是因为看别人有漂亮的图形，所以自己也画一个，其实自己都不去看它。这样的用例分析只能糊弄一下老板，给别人show一下Demo﹐而不会对系统开发什么实质作用。
用例表示的是使用系统的一个场景﹐其本质在于详细描述了系统用户(actor)与系统是如何交互的﹐以及交互的后果是什么﹐详细而完善的用例将指导您进行系统开发的全过程。

用例图是从用户角度描述系统功能， 是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元

用例之间的关系：
1、包含：含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
2、扩展：在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。
3、泛化：用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。

活动图(某功能的页序列,页级流程图,复杂ctrl流程图,函数)

用例涵盖过程和工作流分析，所以活动图能够成为编写用例文本的有用的辅助措施。
在UML中，活动图本质上就是流程图.它用于描述系统的活动，判定点和分支等.

活动图表示的是一种流程。

常被用来建立算法模型，使用流程图可以表示一个算法的执行序列、过程、判定点、分支和循环

用例描述(包含多个”场景”的集合)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

范围：NextGen POS 应用（销售时点信息系统）
级别：用户目标
主要参与者：收银员
涉众及其关注点：

收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收贷款，将从薪水中扣除。
售货员：希望自动更新销售提成。
顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。
公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新账务和库存信息。
经理：希望能够快速地执行超控操作，并易于更正收银员的不当操作。
政府税收代理：希望能从每笔交易中抽取税金，可能存在多级税务代理，比如国家级、省级、市级。
支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。
前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。
主成功场景（或基本流程）：

顾客携带所购商品或服务到收银台通过POS机付款。
收银员开始一次新的销售交易。
收银员输入商品条码。
系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。
收银员重复3~4步骤，直到输入结束。
系统显示总额。
收银员告知顾客总额，并请顾客付款。
顾客付款，系统处理支付。
系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
系统打印票据。
顾客携带商品和票据离开。
扩展（或替代流程）：例如系统在某一步失败、无效的商品、顾客告知免税状况、需要手工输入类别和价格、顾客要求取消销售交易等。这些情况和步骤需要结合实际的场景进行详细的描述，例如：

在主成功场景的第3步，出现无效商品ID，第一个描述条件及响应扩展被标记为“3a”，第二个标记为“3b”，以此类推。
  3a.无效商品ID：
  1.系统提示错误并拒绝输入该标识。
  3b.多个商品属于同一类别时，不必记录每个商品的唯一标识：

当一组步骤中都出现相同条件时，可以如下表示：
  3-6a.顾客要求收银员从所购商品中去掉一项：
  1.收银员输入商品ID并将其删除。
  2.系统删除该项目并显示更新后的累计额。

在任何或大多数步骤都可能发生的扩展条件，可以用“*a”和“*b”这样的标记，另外在复杂的扩展中还可以另外使用单独的用例来表达该扩展，即扩展是可以嵌套的。
  *a. 系统在任意时刻失败：
  保证所有交易的敏感状态和时间能够从场景的任何一步中完全恢复。
  1.收银员重启系统，登录，请求恢复上次状态。
  2.系统重建上次状态。
    2a.系统在恢复过程中检测到异常：
    1.系统向收银员提示错误，记录此错误，并进入一个初始状态。
    2.收银员开始一次新的销售交易。

特殊要求：使用大尺寸平面显示器触摸屏、90%的信用卡授权响应时间小于30秒、支持文本显示的语言国际化等。
技术与数据变元表：商品ID可以用扫描枪输入或键盘输入、信用卡账户信息可以用读卡器或键盘输入等。
发生频率：可能会不断地发生。
未决问题：税法如何变化、研究远程服务的恢复问题、顾客是否可以直接使用读卡器，还是必须由收银员完成等。

类图(略,很明确)

描述系统的静态特征
类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构(类的属性和操作)

对象图( Object Diagram )

对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。

从这个件角度看：对象图标识特殊数据结构时，较为有用。比如一个对象由多个子对象构成。但实际从uml图的一对多（多对一）关系中，也能看出来，所以感觉这个意义不大！感觉对象图可以被类图取代！！

状态图(实际，抽象对象的某个复杂属性)

状态图用来描述一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移，方框是状态，箭头为事件。

顺序图,时序图(UML复杂操作的动态化)

时序图(Sequence Diagram)，又名序列图、循序图，是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

组件图

用来描述软件组件以及组件之间的关系，组件本身是代码的物理模块，组件图则显示了代码的结构。

组件的类型：
构件是定义良好的接口实现单元，它可以是一下几种类型：

1
2
3
4

源代码构件：源代码文件.h（库文件）/.cpp
二进制构件：目标码文件、静态链接库.lib、动态链接库.dll
可执行构件：可执行程序.exe
数据文件或文档

组件的关系

实例：

部署图

在软件按照需求开发出符合要求的软件产品就可以使用了吗？不是的！软件开发人员还需要保证开出的软件产品能够在合适的硬件系统上运行。部署图的作用就是如何显示运行软件系统的物理硬件，以及如何将软件部署到硬件上。例如计算机和设备，以及它们之间是如何连接的

元素：
节点（Node）：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点
节点分为两种类型：处理器（Processor）和设备（Device）
处理器：是能够执行软件、具有计算能力的节点，服务器、工作站和其他具有处理能力的机器都是处理器。
设备：是没有计算能力的节点，通常情况下都是通过其接口为外部提供某种服务，哑终端、打印机和扫描仪都属于设备。

关联关系

实例

对象图和类图差别(?)

对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。
在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类，连线表示对象之间的关系：

类图和对象图的区别

参考文章：UML之类图和对象图：www.uml.org.cn/modeler/201909124.asp
类图:

对象图（一般用户）示例图：（这些图应该是错误的，不符合对象图定义，此处不管哈，不关注名字，只关注带来了那种信息增益）

对象图（操作员）示例图：

对象图（管理员）示例图：

从这里依然看不出二者差距，类的方法，自然需要关联底层table，所以把此案例中对象图中table信息，融入到类图的中，可表达相同意思。不确定其存在必要性！

对象图

来自：UML 类图与对象图：https://www.jianshu.com/p/2899f93a484a
下半部分是对象图，其信息从上面的类图中就以及体现了。所以其并没有给我们带来额外的信息。

从下面这张图中看，有一点点端倪。图中a实例（类型:University）包含3个部门，3个部门名字不同，但都属于同种类型的class(Department)。但这种情况下，仅仅通过类图，显然无法清晰表达出此种关系（类图可以看到，这2类有关联关系而已，不论是一对一还是一对多，都无法充分表达这种关系）

来自：UML学习之对象图和类图：https://blog.51cto.com/u_10750710/1739548

对系统的设计视图建模时，可以使用一组类图完整地描述抽象的语义以及它们之间的关系。但是使用对象图不能完整地描述系统的对象结构。对于一个个体类，可能存在多个实例，对于相互之间存在关系的一组类，对象间可有的配置可能是相当多的。所以，在使用对象图时，只能在一定意义上显示感兴趣的具体或原型对象集。这就是对对象结构建模，即一个对象图显示了某一时刻相互联系的一组对象。
这里，先笼统的理解为，对个别复杂类的快照，提高表达能力吧。

使用staruml绘制这些图形

设计模式1 UML基本使用 用例图,类图时序图,活动图,包图,组件图：https://blog.51cto.com/990487026/1868742

参考

UML图-（用例图、类图、状态图、活动图、时序图）:https://www.cnblogs.com/wu-wu/p/14583462.html
UML 对象图、时序图、活动图 、状态图、协作图 、包图、组件图及部署图：https://blog.csdn.net/baidu_41388533/article/details/107586092
组件图和部署图的绘制：https://zhuanlan.zhihu.com/p/109292946