UML解析

面向对象是符合人们对现实世界的思维模式，利用面向对象设计，特别是采用各种设计模式来解决问题时，会设计多个类，然后创建多个对象，一个设计良好的类，应该是兼顾信息和行为并且高内聚。而不同的类之间，应该做到松耦合。

参与者定位：事件的第一驱动者，也是系统的服务方。比如你在电商网站购物，你就是参与者。
用例定位：系统执行的一系列操作，并生成参与者可以观察的值。比如你在电商网站交易，会生成在线订单，用户下单就是一个用例。
业务用例：用于需求阶段业务领域建模。与计算机系统建模无关，比如下单可以不依赖在线服务，而只是线下签署协议。业务建模的目标是让需求人员和客户能够达成共识。
业务用例实现：业务用例的一种实现方式，一个业务用例可以有多种实现方式。比如下单后的支付，可以用现金，也可以银行卡转账，还可以第三方支付。
概念用例：用于获取业务模型中的关键概念，分析出核心业务结构。业务架构就是概念建模阶段产生，同时为系统建模阶段提供重要指导。比如用户下单这个用例，可以从实现过程中获得一些核心业务，并把它们展现出来。
系统用例：用于定义系统范围、获取功能性需求。也就是我们常挂在嘴边的用例。像业务用例中提到的线下签约的方式，就不会纳入到系统用例中，但如果是电子签约的话，就可以成为系统用例了。
系统用例实现：系统用例的一种实现方式，一个系统用例可以有多种实现方式。比如下单后的支付，可以接入微信支付接口，也可以接入支付宝支付接口。
边界定位：用于业务建模和系统建模阶段的分析，保证分析粒度在一定的范围内，不会扩散。
业务实体定位：它代表参与者执行业务用例时所处理或使用的事物，特别用于在业务建模阶段建立领域模型。业务实体是类（class）的一种版型。
业务实体的结构：包含属性和方法。属性用来保存业务实体特征，方法用来访问业务实体。比如一台电视，把它看成一个业务实体的话，它的属性有运行状态和音量，它的方法就是遥控器，我们可以开、关、调声音，但是我们不可以试图让它飞起来——因为它没有这样的方法。
包定位：容纳并为其他 UML 元素分类。比如 Java 后端经常会提供 jar 包给接入方使用。
分析类定位：用于代表系统中主要的职责簇，由此产生系统的设计类和子系统。
边界类：用于对系统外部环境和内部运作之间的交互进行建模。比如现实世界的窗户，计算机世界的网页。
控制类：用于对用例特有的控制行为进行建模。比如显示逻辑和业务逻辑通过控制层分离的 MVC 架构。
实体类：用于对需要存储的信息和相关行为进行建模。源于业务模型中的业务实体。
分析类的抽象层次较高，比设计和实现要稳定很多，因此方便维护，也更容易获得一个稳定架构来指导整个软件的开发。
设计类定位：是系统实施中一个或多个对象的抽象，由此映射到实现代码，依赖于实施语言。
设计类结构：
类型：对对象某一方面特征的归纳和抽象。映射到编码中的 class。
属性：对象特征。映射到编码中的 field。
方法：访问对象属性的唯一途径。映射到编码中的 method。
关联（association）
关系：是一种拥有的关系，即一个类知道另一个类的属性和方法；比如老师与学生可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
箭头和连线：带普通箭头的实心线，指向被拥有者。
适用场景：类图。
依赖（dependency）
关系：是一种使用的关系，即一个类的实现需要另一个类的协助，是一种弱关系，随运行场景变化。比如削苹果时，人依赖于刀，脱离了这个场景，依赖关系就不存在了。
箭头和连线：带箭头的虚线，指向被使用者。
适用场景：类图。
泛化（generalization）
关系：是一种继承的关系，比如猫是动物的一种。
箭头和连线：带三角的实线，箭头指向父类。
适用场景：类图。
实现（realization）
关系：是一种实现的关系，比如用例和用例实现的关系，接口与实现类的关系。
箭头和连线：带三角的虚线，箭头指向用例实现或接口类。
适用场景：用例图，类图。
聚合（aggregation）
关系：是整体与部分的关系，且部分可以离开整体而单独存在。生命周期各自独立。如车和轮胎是聚合关系，轮胎离开车仍然可以存在。
箭头和连线：带空心菱形的实线，菱形指向整体。
适用场景：类图。
组合（composition）
关系：是整体与部分的关系，但部分不能离开整体而单独存在。同生同灭。如公司和部门是组合关系，没有公司就不存在部门。
箭头和连线：带实心(黑色实心：要死一起死，良心是黑的)菱形的实线，菱形指向整体。
适用场景：类图。
关联关系和依赖关系的区别：
关联关系是静态天然的联系，依赖关系是动态临时的联系。
此外还有只用于用例中的关系：
扩展（extends）
关系：用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。
箭头和连线：带箭头的虚线加版型<<extends>>。
特点：用例可选。
包含（include）
关系：用于在用例模型中说明在执行基本用例的用例实例过程中插入的行为段。
箭头和连线：带箭头的虚线加版型<<include>>。
特点：用例必需。
组件定位：实现特定功能的逻辑代码模块。比如分布式应用架构下，将业务目标拆成多个功能，每个功能作为组件独立部署。这样这些组件也能被其他场景复用。
节点定位：表示应用程序的部署单元。比如分布式应用的环境中，服务器或设备会有很多，就需要通过节点来体现物理部署的情况

当面对应用系统或者需要解决的问题经常是复杂的、高度抽象的，我们创建的多个对象往往是有联系的，通常对象之间的关系可以分为以下几类：

泛化关系
实现关系
依赖关系
关联关系
聚合关系
组合关系

①结构性图形
静态图（包括类图、对象图、包图）：类图是最常用的UML图，它描述了系统中类的静态结构，包括类的属性和方法以及类之间的关系。对象图则描述了系统中对象的实例以及它们之间的关系。包图描述了系统的模块结构，以及模块之间的依赖关系。
实现图（包括组件图、部署图）：组件图用于描述系统的物理结构，包括系统的软件组件以及它们之间的关系。部署图描述了系统的硬件结构，包括系统的节点以及它们之间的通信关系。
剖面图：剖面图用于描述系统的内部视图。
复合结构图：复合结构图则用于描述复杂结构的内部组织。
②行为式图形
活动图：活动图描述了系统的动态行为，包括系统的业务流程以及流程之间的控制和数据流关系。
状态图：状态图描述了系统中对象的生命周期，包括对象的状态以及状态之间的转移条件。
用例图：用例图描述了系统的功能需求，包括系统的参与者、用例以及它们之间的交互关系。
③交互性图形
通信图：通信图描述了系统中对象之间的交互，包括对象之间的消息传递顺序。
交互概述图：交互概述图是用于描述多个交互图之间的关系。
时序图：时序图描述了系统中对象之间的交互，强调交互发生的时间顺序。
时间图：时间图描述了系统中的事件或者状态在时间轴上的分布。