uml9大图：
一、结构型图（5 种）：描述系统的静态组成与关系
结构型图聚焦 “系统由哪些部分构成”，不涉及时间或交互过程，是系统的 “蓝图”。
- 类图（Class Diagram）：最核心的静态模型
核心用途：描述系统中 “类” 的定义（属性、方法），以及类与类之间的关系，是面向对象设计的基础。关键元素：
类：用 “三层矩形” 表示（上层：类名；中层：属性，格式[可见性] 属性名: 类型，如- name: String；下层：方法，格式[可见性] 方法名(参数): 返回值，如+ login(username: String): boolean）。
可见性：+（public，公有）、-（private，私有）、#（protected，保护）。
类间关系：关联（如 “学生 - 课程” 的选课关系）、继承（空心三角箭头，如 “大学生→学生”）、实现（空心三角+虚线，如 “UserService→IUserService”）、聚合（空心菱形+实线，整体与部分可独立，如 “班级 - 学生”）、组合（实心菱形+实线，整体与部分不可独立，如 “人 - 心脏”）。
典型场景：需求分析后，设计系统的 “领域模型” 或 “业务实体模型”。示例：电商系统中，User类（属性：id/name/phone；方法：login ()/pay ()）与Order类（属性：orderId/totalPrice；方法：create ()/cancel ()）通过 “关联关系” 连接（一个用户可创建多个订单）。 - 对象图（Object Diagram）：类图的 “实例快照”
核心用途：描述某一特定时刻，类的实例（对象）及其之间的关系，是类图的 “动态实例”。关键元素：
对象：用 “两层矩形” 表示，类名后加实例名（格式类名#实例名，如User#user1），属性需填写具体值（如name: "张三"）。
关系：与类图一致，但仅反映当前实例的关联（如user1关联order001）。
典型场景：调试时展示对象状态、或文档化某一特定场景的实例交互（如 “用户张三创建订单 001” 的瞬时状态）。示例：某时刻的对象快照：User#user1（id:101, name:"张三"）关联Order#order001（orderId:001, totalPrice:299），order001关联Product#prod202（prodId:202, name:"耳机"）。 - 包图（Package Diagram）：模型元素的 “文件夹”
核心用途：将复杂系统的模型元素（类、用例、组件等）按功能或模块分组，展示模块间的依赖关系，实现 “模块化管理”。关键元素：
包：用 “带标签的文件夹图标” 表示，标签为模块名（如 “用户模块”“订单模块”）。
依赖：用 “虚线 + 箭头” 表示（如 “订单模块依赖用户模块”，因创建订单需先获取用户信息）。
典型场景：大型系统的 “模块划分”，避免模型元素混乱。示例：电商系统的包图可分为：用户管理包（含 User 类、LoginService 类）、商品管理包（含 Product 类、InventoryService 类）、订单管理包（含 Order 类、OrderService 类），其中订单管理包依赖用户管理包和商品管理包。 - 组件图（Component Diagram）：系统的 “物理模块” 视图
核心用途：描述系统中的 “可复用物理组件”（如 Jar 包、DLL 文件、微服务、接口），以及组件间的接口依赖关系，聚焦 “如何拆分可部署的模块”。关键元素：
组件：用 “矩形 + 右侧两个小矩形” 表示（如 “支付组件”“日志组件”）。
接口：分 “提供接口”（组件对外提供的功能，用 “圆圈 + 实线” 连接组件，像 “棒棒糖”）和 “需求接口”（组件依赖的外部功能，用 “半圆 + 虚线” 连接组件，像 “插座”）。
依赖：用 “虚线 + 箭头” 表示组件间的接口依赖（如 “订单组件” 依赖 “支付组件” 的 “支付接口”）。
典型场景：系统架构设计阶段，规划可复用、可部署的物理模块。示例：支付系统中，订单组件（需求 “支付接口”）依赖支付宝组件（提供 “支付宝支付接口”）和微信支付组件（提供 “微信支付接口”），日志组件被所有其他组件依赖（提供 “日志记录接口”）。 - 部署图（Deployment Diagram）：系统的 “物理部署” 视图
核心用途：描述系统的 “硬件节点”（如服务器、客户端）和 “软件组件” 在硬件上的部署关系，是 “从设计到上线” 的桥梁。关键元素：
节点：用 “带虚线边框的矩形” 表示，标注硬件类型（如 “Web 服务器（Tomcat）”“数据库服务器（MySQL）”“用户 PC”）。
组件：部署在节点内的软件（如 “订单组件” 部署在 “Web 服务器”）。
通信路径：用 “实线” 表示节点间的网络连接（如 “Web 服务器” 与 “数据库服务器” 通过 TCP/IP 连接）。
典型场景：系统上线前，规划硬件资源分配和软件部署方案。示例：电商系统部署图：用户PC（部署 “前端页面”）→ 连接 Web服务器（部署 “订单组件 / 商品组件”）→ 连接 数据库服务器（部署 “MySQL 数据库”），同时Web服务器连接 支付服务器（部署 “支付组件”）。
二、行为型图（4 种）：描述系统的动态交互与行为
行为型图聚焦 “系统如何运作”，涉及时间、流程、状态变化等动态过程。 - 用例图（Use Case Diagram）：系统的 “功能需求” 视图
核心用途：描述 “用户（参与者）” 与 “系统” 的交互，清晰展示系统的核心功能（用例），是需求分析的核心工具。关键元素：
参与者（Actor）：用 “小人图标” 表示，指与系统交互的人 / 外部系统（如 “读者”“图书馆管理员”“支付系统”）。
用例（Use Case）：用 “椭圆” 表示，指系统提供的一个完整功能（如 “借书”“还书”“查询图书”）。
关联：用 “实线” 表示参与者与用例的交互（如 “读者” 关联 “借书”）。
包含 / 扩展：用 “虚线 + 箭头 +<>/< >” 表示用例间的关系（如 “借书” 包含 “验证读者身份”，“查询图书” 可扩展 “高级筛选”）。
典型场景：需求调研阶段，向客户确认系统功能范围（“做什么，不做什么”）。示例：图书馆系统用例图：参与者 “读者” 关联 “借书”“还书”“查询图书”；参与者 “管理员” 关联 “添加图书”“删除图书”“统计借阅量”；“借书” 用例包含 “验证读者身份” 和 “扣减库存”。 - 时序图（Sequence Diagram）：交互的 “时间顺序” 视图
核心用途：按 “时间先后顺序” 描述对象之间的消息传递过程，强调 “何时交互”，是最常用的动态图之一。关键元素：
对象：顶部用 “矩形” 表示，下方延伸 “生命线”（虚线，代表对象的存在时间）。
消息：用 “箭头” 表示对象间的交互（同步消息：实心箭头；异步消息：空心箭头，无需等待响应）。
时间轴：自上而下为时间流逝方向（上方是早期，下方是后期）。
激活期：生命线上的 “矩形块”，表示对象正在执行操作（如 “认证服务” 的激活期对应 “验证账号密码” 的过程）。
典型场景：详细设计阶段，拆解某一功能的执行流程（如 “用户登录”“订单创建” 的步骤）。示例：用户登录时序图（时间从上到下）：
用户 → 登录界面（消息：输入账号 / 密码）；
登录界面 → 认证服务（同步消息：请求验证（username, password））；
认证服务 → 数据库（同步消息：查询用户（username））；
数据库 → 认证服务（消息：返回用户信息）；
认证服务 → 登录界面（消息：返回验证结果（成功 / 失败））；
登录界面 → 用户（消息：显示登录结果）。 - 协作图（Communication Diagram）：交互的 “结构关系” 视图
核心用途：与时序图互补，描述对象间的交互，但更强调 “对象的结构关系”（如何连接），而非时间顺序，通过 “消息序号” 体现执行顺序。关键元素：
对象：用 “矩形” 表示，标注对象名（如User“LoginUI”“AuthService”）。
关联：用 “实线” 表示对象间的连接（如 “LoginUI” 与 “AuthService” 关联）。
消息：用 “带序号的箭头” 表示交互（序号如 “1”“2”“2.1”，体现嵌套或顺序）。
典型场景：当需要关注 “对象如何连接” 而非 “时间先后” 时（如复杂对象网络的交互），与时序图可互相转换。示例：用户登录协作图：
对象：User、LoginUI、AuthService、DB；
关联：User-LoginUI、LoginUI-AuthService、AuthService-DB；
消息：1. User→LoginUI：输入账号密码；2. LoginUI→AuthService：验证请求；2.1. AuthService→DB：查询用户；2.2. DB→AuthService：返回数据；3. AuthService→LoginUI：验证结果；4. LoginUI→User：显示结果。 - 状态图（State Diagram）：对象的 “生命周期” 视图
核心用途：描述单个对象从 “创建” 到 “销毁” 的全生命周期中，状态的变化过程，以及触发状态变化的 “事件”。关键元素：
状态：用 “圆角矩形” 表示（如 “待支付”“已支付”“已发货”）；
初始状态：用 “实心小圆” 表示；
终止状态：用 “实心小圆 + 外圈” 表示。
事件：用 “箭头” 标注，描述触发状态变化的条件（如 “用户支付”“超时”“商家发货”）。
转换：用 “箭头” 连接两个状态，表示状态间的切换（如 “待支付”→“已支付”，触发事件为 “用户完成支付”）。
典型场景：描述有复杂状态变化的对象（如订单、流程实例、设备状态）。示例：订单状态图：
初始状态 → 待支付（触发事件：用户创建订单）；
待支付 → 已支付（触发事件：用户完成支付）；
待支付 → 已取消（触发事件：订单超时 / 用户取消）；
已支付 → 待发货（触发事件：系统确认支付）；
待发货 → 已发货（触发事件：商家点击发货）；
已发货 → 已签收（触发事件：用户确认收货）；
已签收 → 终止状态（触发事件：订单完成）；
已取消 → 终止状态。