UML 学习笔记

需求阶段主要是靠用例图，通过对用例来分析开发周期；软件设计(概设和详设)起点是部署图，部署图里是各个组件之间的关系，然后分析每个组件应该有哪些类

一、4+1视图模型

1. 软件架构={元素，形式，关系/约束}

2. 单一的视图无法完整的表达架构，因此需要具备完整的视图集

• 逻辑视图(Logical View)，设计的对象模型

• 过程视图(Process View)，捕捉设计的并发和同步特征

• 物理视图(Physical View)，描述了软件到硬件的映射，反映了部署特性

• 开发视图(Development View)，描述了在开发环境中软件的静态组织结构

• 场景视图(scenarios)，描述用例场景

1. 4+1视图模型之间的关系

1. 逻辑视图

• 相关方：客户、用户，开发组织管理者

• 视角：系统的功能元素，以及它们接口、职责、交互

• 主要元素：系统、子系统、功能模块、子功能模块、接口

• 用途：开发组织划分，成本/进度的评估

功能模块(逻辑视图的一种)图示例如下：

1. 开发视图

• 相关者：开发相关人员、测试人员

• 视角：系统如何开发实现

• 主要元素：描述系统的层、分区、包、框架，系统通用服务、业务通用服务，类和接口，系统平台和相关基础框架

• 用途：指导开发组织设计和开发实现

类图示例如下，相关开发人员可以根据类图直接进行开发：

1. 物理视图

• 相关者：系统集成商、系统运维人员

• 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

• 主要元素：物理节点以及节点的通信

示例图如下：

1. 过程视图

• 相关者：性能优化、开发相关人员

• 视角：系统运行时线程、进程情况

• 主要元素：系统进程、线程以及处理队列等

示例图如下：

1. 场景视图

• 相关者：用户、设计和开发人员

• 视角：概括了架构上最重要的场景(最典型或最有风险)及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式

示例图如下：

二、模型及UML

1. 模型及作用：模型就是系统的完整抽象。人们对某个领域特定问题的求解及解决方案，对他们的理解和认识都蕴涵在模型中。通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程就是从领域问题到计算机系统的映射。解决方案就是最终的系统软件

1. 建造模型的原因：

• 为了验证某件事务能否工作

• 建造模型的成本远低于实物成本

• 开发中先对领域问题抽象做出模型，然后通过系统评审判断是否可行

1. 建造模型的目的：

• 方便与他人沟通，通过模型让老板对系统解决方案做出决策，或让其他专家对系统提出意见

• 可以保存软件设计最终成果，当了解到软件设计的初衷后，便于以后的开发者进行维护和迭代更新，避免以后对系统开发或维护的开发者依照自己的想法改变功能设计，最终会导致系统不可维护

1. 何时画图、用什么画

• 在讨论问题时，可以在白板或纸上画图，最终目的是让大脑有个清晰的系统设计

• 只保留最重要的，避免涉及过多内容和实现细节

• 真正做评审或给老板看的时候，可以用绘图工具，如Visio、Aastah、draw.io等画

1. UML，Unified Modeling Language，统一建模语言，以图形方式描述软件概念

• 建模过程是对业务领域和系统软件的抽象，建模最终是将这两个抽象通过图形方式展现出来

三、UML，软件架构建模的方法和工具

1. UML静态图，通过描述类、对象以和数据结构以及他们之间存在的关系，来描述软件要素中不变的逻辑结构

• 用例图(Use Case Diagrams)

• 对象图(Object Diagrams)

• 类图(Class Diagrams)

• 组件图(Component )

• 包图(Package Diagrams)

• 部署图(Deployment Diagrams)

1. UML动态图，通过描绘执行流程或实体状态变化的方式，来展示软件实体在执行过程中的变化过程

• 时序图(Sequence Diagrams)：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例行为

• 活动图(Activity Diagrams)：着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种

• 状态图(State Diagrams)：用例描述对象、子系统、系统的生命周期

• 合作图(Collaboration Diagrams)：描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系

1. 图中使用的概念统称为模型元素，每个模型元素在图中都有对应的视图元素(符号)表示，如下图

模型元素之间的关系也是模型元素，常见的有关联(association)、泛化(generalization)、依赖(dependency)和聚合(agrregation)。

符号图如下：

• 依赖和关联都是表达两个对象之间的关系，关联相对依赖表示的关系更紧密，如成员变量就是关联关系，方法内局部变量依赖另一个对象就是依赖关系

• 继承和实现，继承通常是继承父类，而实现表示实现接口，接口的方法只是描述没有实现

• 聚合和组合比较相近，聚合是由多个成员聚合而成一个对象，当这个对象不存在后，其成员还可以单独存在，如汽车，当汽车被分解不存在后，汽车的轮子、发电机等还是可以独立存在的；组合是表示成员与对象之间有更强的关系，当对象不存在后，成员也就不存在了，如动物，动物不存在了，其各个组织也就不存在了

1. 用例建模：用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例分析，使开发者能够有效地了解用户需求，用例图示例如下

• 方框表示用例边界，方框内表示当前用例有哪些功能

• 方框外的小人表示执行者，可以是人或外部系统，是对当前用例功能的使用者

• 用例用椭圆表示，表示的是一个功能，通常使用动宾或宾动短语描述，表示的是一个动作。用例一定表示的是去做一件事

• 用例中可以使用另一个功能，用例还可以被扩展，表示一个功能拥有另一个功能

• 需求分析阶段主要产生的架构图就是用例图

• 用例图可以自顶向下不断精化，抽象出不同层次用例图。当一个用例无法解释全功能时，可以继续分解功能，做出更细粒度的用例图

1. 类与对象：面向对象开发方法的基本任务是建立对象模型，是软件系统开发的基础。UML中的类图和对象图表达了对象模型的静态结构，能有效地建立专业领域的计算机系统对象模型

常用的是类图，如下，成员变量和方法的访问控制：+表示public，-表示private，没有表示protect。类图主要用在详设阶段，类图设计出来后就可以进行代码落地了

1. 组件图：系统的逻辑组件图，通常对于Window编程的有dll文件，对于Java系统有jar包。系统会遵从一组接口且提供其实现的物理的、可替换的部分。

1. 部署图：软件设计中最大的一张蓝图，在系统设计之初，也就是概要设计的时候，架构师头脑中最先有的就是部署图。系统是什么样的，和外部服务关系是怎样的。要有哪些服务系统，各系统关键组件有哪些，画出组件图后，再画出组件时序图，描述出组件之间的动态交互关系，然后再分析组件里应该有哪些主要类，这样类图也就出来了

1. 时序图：描叙对象之间动态交互的图，此处的对象可以表示类的对象，组件的对象，也可以表示子系统对象或其他服务对象，此处的对象是广义的，可以描述不同维度下的对象。当描述的是类对象之间交互时，表示对象的时序图，描述组件之间的交互时表示组件时序图。如类对象时序图如下。

时序图可以使用在需求、概设和详设三个阶段。需求阶段，可以通过各个系统时序图表示本系统和其他系统之间的交互关系；概设阶段可以通过时序图表示本系统内各个子系统之间或组件之间的调用关系；详设阶段主要就是画类图的时序图了，表示类对象之间的交互关系

1. 活动图：既可用来描述操作(类的方法)的行为，也可以用来描述用例和对象内部的工作过程，并可用于表示并行过程。活动图描述了系统中各个活动执行顺序。刻画一个方法所要进行的各项活动的执行流程。活动图中一个活动结束后，立即进入下一个活动(状态图中的状态变迁可能需要事件触发)。

活动图中的泳道：进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互方式，描述采取何种动作，做什么(对象状态的改变)，何时发生(动作序列)，以及在何处发生(泳道)。泳道也是一种分组机制。一个泳道也可以看作一个领域，领域中的某个动作或功能可能跨多个领域完成。需求分析阶段，泳道图用来描述业务处理流程；概要设计阶段，要把需求中的功能设计成具体的功能或服务模块，描述一个功能要经过哪些模块来完成，调用哪些服务，其中泳道就是每个服务；详细设计阶段，如果某个方法逻辑复杂，也可以根据方法调用画泳道图，经过各种判断分支逻辑处理描述方法具体逻辑。

1. 状态图：当描述复杂情况状态变迁时候使用的图。需求分析阶段可以根据需求中的相关状态变迁部分功能进行画图；详细设计阶段，可以由开发任务根据具体的枚举类型画状态图