4+1视图与UML

4+1视图，即逻辑视图，过程视图，实现视图，部署视图，+用例视图。

1. 为什么不用一个视图？
   针对多个用户，即终端用户，设计人员，开发人员，测试人员，集成人员而言，4+1视图更精准对应到用户，清晰全面
2. 为什么是4+1视图而不是5大视图？
   4个视图类似并列关系，从架构设计的4个不同角度设计；用例视图是需求的抽象，正向驱动另外四大视图的设计，逆向检查另外四个视图的正确性和完整性。

逻辑视图

逻辑视图主要关注的是业务逻辑，也就是软件系统的功能性。它描述了系统中的功能元素，功能服务，业务域对象，以及他们之间的交互。
逻辑视图主要通过以下几种UML图来表达：

1. 类图（Class Diagram）：展示系统中的类、接口以及他们之间的静态关系，如继承、依赖、关联和聚合等。
2. 对象图（Object Diagram）：是类图的实例，展示了系统中的对象以及他们之间的关系。
3. 包图（Package Diagram）：展示系统的模块结构，描述类和包的依赖关系。
4. 组件图（Component Diagram）：展示系统的组件以及它们之间的关系。
5. 部署图（Deployment Diagram）：展示系统的物理架构和部署情况。

过程视图

过程视图描述了系统的动态行为，包括系统的并发性和同步性，关注的是系统的运行时行为。
过程视图通常包含一系列的进程以及它们之间的交互。这些进程可能是并发执行的，也可能需要进行同步。过程视图展现了系统的动态行为，如进程的创建，销毁，调度，以及进程之间的同步和通信等。
通常使用以下几种UML图来表达：

1. 活动图：展示系统中各个活动的执行流程和它们之间的关系，通常用于表示并发和同步。
2. 顺序图：展示对象之间的交互顺序，可用于表示进程或线程之间的通信。
3. 状态图：展示系统或系统中某个部分在其生命周期内可能处于的状态，以及由一个状态转换到另一个状态的事件或条件
4. 协作图（通信图）：展示对象间的交互关系，可以用于表示进程或线程之间的通信

开发视图

开发视图主要关注程序或系统的实际组织，提供了程序员需要的详细信息，用以理解，构建和测试系统的软件。开发试图主要包括：

• 源码管理：详细说明如何管理和组织源码
• 软件架构：描述了软件的组织架构，包括软件组件和它们之间的关系
• 数据库架构：描述了数据存储的方式，包括数据库模式和其他相关信息
• 测试：描述了如何测试软件，包括测试策略和测试计划
• 构建：描述如何构建和部署软件，包括构建工具和部署过程
  开发视图可以帮助开发人员理解和实现设计，并为后期的维护和迭代提供指导。

通常由以下几种UML来表达：

1. 包图（Package Diagram）：用于展示系统的模块组织和依赖关系。
2. 组件图（Component Diagram）：用于描述系统的物理组成部分，包括软件组件、硬件组件、接口和它们之间的关系。
3. 类图（Class Diagram）：用于描述系统中的类及其相互之间的关系，包括继承、聚合和关联等。
4. 对象图（Object Diagram）：用于描述系统中的对象及其相互之间的关系，这对于理解和验证系统的静态结构非常有用。

物理视图（部署视图）

物理视图主要关注系统的物理部署及其在硬件上的分布。它描述了系统的硬件组成，网络拓扑，通信和数据传输等信息。物理视图主要包括：
－ 硬件架构：描述了系统所运行的硬件设备，包括服务器，工作站，网络设备等
－ 网络架构：描述了网络的拓扑结构，以及各节点之间的通信方式
－ 部署方案：描述了软件在硬件设备上的部署方式，包括分布式部署，集群部署等
－ 安全性：描述了系统的安全策略，包括数据加密，防火墙设置，访问控制等。
－ 性能：描述了系统的性能需求，包括处理能力，存储能力，网络带宽等
物理视图可以帮助系统管理员和运维人员理解系统的运行环境，进行有效的部署和管理。
部署视图主要由UML中的部署视图来表达，它用于描述物理硬件的配置和软件组件在硬件上的部署情况。包括节点、设备、连接等元素。

用例视图

用例视图主要描述的是系统与外部交互的过程，也就是系统的功能需求。用例视图通常由一些列的用例或场景组成，每个用例或场景代表了一个特定的功能或业务流程。通过这种视图，可以清晰的展现出系统的主要功能和系统与用户或其他系统的交互过程。
用例视图通常是系统分析和设计的起点，它能够帮助我们理解用户的需求，定义系统的功能。主要使用UML中的用例图来表达，它展示了系统的参与者、用例（系统的功能）以及参与者与用例之间的交互关系。用例图是用来捕获系统需求、描绘用户与系统交互的工具。

UML

统一建模语言(Unified Modeling Language)

组件图

组件图（Component Diagram）主要用于描述系统的物理结构。换句话说，它描述了系统中各个组件的组织和关系。

组件图中的主要元素是组件和接口。组件代表系统中的一个模块，它可以是一个物理的实体（如一个文件或一个程序库），也可以是一个逻辑的实体（如一个类或一个服务）。接口则代表了组件之间的交互方式，它可以是一个函数的签名，也可以是一个消息的格式。

组件图中的关系包括依赖关系、关联关系和组合关系。依赖关系表示一个组件依赖于另一个组件的接口，关联关系表示两个组件可以互相通信，组合关系表示一个组件包含了另一个组件。

组件图可以帮助我们理解系统的结构和组织，以及各个组件之间的交互方式。它通常在系统设计阶段使用，以指导系统的实现和维护。

类图

类图中的写法规则如下：

• +表示public
• -表示private
• #表示protected
• ~表示default，可以省略不写
• 字段或返回值的类型非必须
• 抽象类或者抽象函数用斜体表示
• 静态类或静态函数下加下划线
• 如果是接口，在类名前加<>

类图有六种关系：泛化，实现，关联，聚合，组合，依赖

1. 泛化/继承：has-a的关系，子类继承父类，实现了父类的特征和行为，使用三角箭头的实线，箭头指向父类。
   

2. 实现：子类继承自抽象类（接口类），使用三角箭头的虚线，箭头指向抽象父类
   

3. 关联：拥有的关系，使一个类知道另一个类的成员，可以互相关联，也可以单向关联。使用带箭头的实线，指向被拥有者。双向关联可以有两个箭头，或没有箭头，单向关联只有一个箭头

4. 聚合：整体与部分的关系，且整体可以离开部分，即整体的生命周期可以和部分不一致，常见的是类的成员变量，使用空心菱形箭头的实线，箭头指向整体
   

5. 组合/复合：整体与部分的关系，但不同于聚合的是，部分不能离开整体存在，使用实心菱形箭头的实线，箭头指向整体
   

6. 依赖：一个类需要依赖另一个类实现其某些功能，但不像聚合或复合那样需要完全拥有这个依赖类的对象，如局部变量，函数的参数等，使用带箭头的虚线表示，箭头指向被依赖的对象
   
   这几种关系的强弱顺序为：
   泛化=实现 > 组合 > 聚合 > 关联 > 依赖

时序图

时序图的作用：

1. 展示对象之间交互的顺序，将交互行为建模为消息传递，通过描述消息是如何在对象间发送和接收来动态展示对象之间的交互
2. 相对于其他UML图，时序图更强调交互的时间顺序
   可以直观描述并发进程

时序图的组成元素

• 角色
• 对象：代表时序图中的对象在交互中扮演的角色，用矩形表示
  • 顶部：表示在交互开始时对象就已经存在了
  • 中间：说明对象是在交互的过程中被创建的
  • 当一个对象被删除或自我删除时，在其生命线终止点处放置“x”标识
  • 生命线：对象底部中心一条垂直的虚线，对象间的消息存在于两条虚线之间’
  • 激活期：又叫控制焦点，代表时序图中在对象时间线上某段时间执行的操作
  • 消息：两个对象之间的单路通信，从发送方指向接收方，一般有以下几种传递方式：
    • 同步消息：发送人需要等待消息的相应，带实心箭头的实线表示
    • 异步消息：不需要等待响应，带线性箭头的实线表示
    • 返回消息：带线性箭头的虚线表示
    • 自关联消息：自身调用自身的方法，即自我调用的同步消息

组合片段：解决交互执行的条件和方式，共有13种

例：
Alt选择

Opt选项：

Loop循环：

Par并行