---------------------------------------------------------UML图：---------------------------------------------------------
原博客：https://blog.csdn.net/chengqiuming/article/details/91129569
---------------------------------------------------------UML四种事物：-------------------------------------------------
构建事务（静态部分，常见的结构事物：类、接口、用例、协作、组件、节点）
行为事物（动态部分包括交互、状态机、活动）
分组事物（UML模型的组织部分）
注释事物（UML模型中的解释部分）
---------------------------------------------------------UML中四种主要的关系：---------------------------------------------------------
关联（描述不同类元的实例之间的连接）
依赖（若一个元素的某些特性随某一个独立元素的特性改变而改变）
泛化（类似于面向对象中的继承关系）
实现（描述规格说明和其实现的元素之间的连接的一种关系）
---------------------------------------------------------------------UML的扩展机制---------------------------------------------------------------------------------
构造型（带书名号）、约束、标记值
-----------------------------------------------------------------E—R图-------------------------------------------------------------
E-R图（Enity Relationship Digram）ERD：数据定义 结构 关系特性
---------------------------------------------------------面向对象软件建模概述：---------------------------------------------------------
面向对象方法的优点：
1.它与人类习惯的思维方法一致。
2.稳定性好。
3.集成了可以复用的思想。
4.开发出的软件，具有良好的可维护性。
面向对象建模技术/对象建模技术（OMT， Object Modelng Technology）
面向对象需求分析（Object-Oriented Analysis， OOA）常用的UML技术：
类图、用例图、交互图（顺序图）、状态图等
面向对象设计（Object-Oriented Design， OOD）
静态模型：类图、对象图、构件图、部署图；
动态模型：交互图（顺序图、通信图）、状态图、活动图；
UML基本构造块：事务、关系、图
------------------------------------------------------用例图（关系+用例+参与者+（边界））---------------------------------------------------------
用例之间的关系：
泛化关系（当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象为父用例，其他的用例作为子用例，用例间的这种关系称为用例的泛化关系）
包含关系（当多个用例需要用到同一段行为时，可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例）
扩展关系
----------------------------------------------------
用例的粒度：指用例包含的系统服务或者功能单元的多少。用例的粒度越大，包含功能越多，反之。
（如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分析，使用时看情况）
----------------------------------------------------
构建用例模型：用例图：确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。
用例规约：描述用例的细节内容，针对每一个用例都应该有一个用例规约文档与之对应。
----------------------------------------------------
用例图的作用及组成：（消除歧义，达成共识，主要是客户与设计人员）
用例图组成元素：
参与者（系统外部，是直接与系统进行交互的外部实体的抽象。还可以是其他系统，for instance 硬件设备、时钟等）【图标表示法（人），标签表示法（其他玩 意）】
1.位于系统边界之外2.直接且主动的向系统发出动作并获得反馈。
-------------------------
用例（对一组动作序列的描述，系统执行动作序列来为参与者产生一个可观察的结果值，相同的用例在一个系统中只存在一个）【椭圆形表示，内部或者是下方】
用例的确定：
参与者希望系统提供什么功能？
参与者是否会读取、创建、修改、删除、存储系统中的某种信息
参与者是否会将外部的某些事件通知给系统
系统中发生的事件是否通知给参与者
是否存在影响系统的外部事件
用例的特征：
用例必须位于系统边界内部（从外部用户角度出发用户所提供的功能和服务，定义了系统的行为特征）
用例是以动宾短语形式出现的（用例表达是一次完整的人机交互序列，）
用例是相对独立的（在功能上必须是完备的，不能完整实现参与者目的的行为不能称之为用例）
用例的执行结果对参与者来说是可观测且有意义的（用例描述参与者与系统之间的交互行为，而非内在系统活动，用例为业务功能，而非处理过程）
用例是由参与者启动的（用例不应该自动启动，也不应该主动启动另外一个用例，每个用例至少拥有一个参与者）
-------------------------
系统边界
-------------------------
用例图之间的关系：
依赖关系 （包含和扩展）：包含关系（Include）是指一个用例可以简单的包含其他用例具有的行为（被包含用例的事件流可以插入其他基础用例的事件流中）【带虚线的箭头，指向被包含的用例】。1.多个用例同时使用到同一段必须行为 2.某一个用例功能过多，事件流过于复杂 参与者不允许直接使用包含用例，如果没有包含用例，基本用例是不完整的 被包含用例可以独立存在 包含用例就是被包含用例
扩展关系（Extend）是指一个用例（扩展用例）扩充了另外一个用例（基础用例）的功能（只有在满足特定条件的情况下才会被执行）【带箭头的虚线，扩展用例指向基础用例】1.用例使用到一段用于增强自身功能的可选行为 没有扩展用例，基础用例也是完整的，可以独立执行。 扩展用例必须依赖基础用例
-----------------------------
泛化关系（编程里面的继承）：存在于参与者之间也存在于用例之间（描述了参与者之间特殊与一般的关系，特化用例（子用例）与一般化用例（父用例）之间的关系）【带空心三角箭头实线，指向超类参与者（最基本），子用例指向夫用例】1.多个用例在行为、结构和目的方面存在共性。
-----------------------------
泛化与包含共同点：
从现有的用例的事件流中抽取共有部分，服用现有用例。
泛化与包含区别：
泛化用例是整体相似，子用例启动，父用例不一定被执行。
包含是部分相似，基础用例启动，被包含用例必然执行。
--------------------
关联关系：参与者与用例之间的关系（最重要的关系，消息的传递时双向的）【带箭头的实线，一般来说，从参与者指向用例（如果是设备被使用，是用例指向设备），不带方向的也没问题，指向的是被用的】
----------------------------------------------------------------------------------------------------------------------
