✍️ 第一章：系统需求分析与用例建模设计#

1.1 需求层次划分与捕获工具 [PDF 4]#

软件需求是一个从宏观商业价值向微观操作步骤逐步分解的演进过程：

$\text{业务目标} \rightarrow \text{业务流程} \rightarrow \text{操作流程} \rightarrow \text{业务规则}$

• 业务目标（Business Goal）：回答系统“为什么存在”。
• 业务流程（Business Process）：实现业务目标所涉及的多角色、跨部门的协同活动。
• 操作流程（Operation Flow）：单一角色在系统界面上的具体交互路径。
• 业务规则（Business Rule）：限制或指导业务行为的约束条件（如：余额不足禁止取款）。

1.2 用例模型（Use Case Model） [PDF 4]#

用例用于描述外部参与者（Actor）与系统之间为了达到特定业务目标而进行的安全、完整的交互序列。

1.3 用例规约（Use Case Specification）结构 [PDF 4]#

用例图仅展示结构，其详细的交互逻辑必须在用例规约中详细阐述。一份标准的用例规约应包含以下要素：

• 用例名称（Name）：动宾短语（如：提交新闻采集任务）。
• 用例级别（Level）：用户目标级、子功能级。
• 主要参与者（Primary Actor）：发起该交互 of 外部角色。
• 前置条件（Pre-conditions）：用例开始前系统必须满足的全局状态（如：用户必须处于登录状态）。
• 后置条件（Post-conditions）：用例成功执行后，系统状态发生的改变（持久化改变）。
• 主要流程（Basic Flow）：没有出现 any 异常的黄金交互路径。
• 替代/扩展流程（Alternative Flows）：分支条件、输入错误或异常流程的处理路径。
• 非功能性需求（Non-functional Requirements）：安全、性能、可用性等约束。

1.4 分析类与系统交互建模 [PDF 1, PDF 4]#

在分析阶段（OOA），系统结构被抽象为“鲁棒图”（Robustness Diagram）中的三类分析类：

• 边界类（Boundary Class）：代表系统与外界（用户、其他系统、设备）的接口，负责接收输入和呈现输出（如：前端页面、API路由、网络套接字 RegisterDialog） [PDF 4, PDF 5]。
• 控制类（Control Class）：代表系统内部的协调、业务逻辑控制、流程编排逻辑（如：TaskController, AccountController） [PDF 4, PDF 5]。
• 实体类（Entity Class）：代表系统需要保存的长期数据结构和领域模型（如：Account, WithdrawalTransaction） [PDF 4, PDF 5]。

1.5 系统操作契约（System Operation Contract） [PDF 4, PDF 5]#

系统顺序图（SSD）描述了参与者触发的系统事件。针对每一个重要的系统事件，分析人员需编写系统操作契约。

• 契约的核心要素：系统操作签名、前置条件、后置条件 [PDF 5]。
• 后置条件的黄金三法则：后置条件必须是用过去时态描述的、执行完毕后系统状态的客观物理改变。只存在以下三种情形 [PDF 5]：
  1. 对象被创建或销毁（Instantiated or Destroyed）：如 WithdrawalTransaction 的实例 transaction 被创建。
  2. 对象的属性值发生变更（Attribute modified）：如 transaction.status 被修改为 SUCCESS。
  3. 对象之间的连接关系（关联/链接）被创建或销毁（Link formed or broken）：如 transaction 关联到了当前的 Account 实例。

1.6 典型图表绘制实战：以“扫码租车”为例#

为了方便理解用例建模与系统顺序图（SSD）的具体绘制方法，以下提供对应的标准 UML 例图：