小型网上书店用例图

<think>好的，用户需要设计一个小型网上书店系统的用例图，使用UML。首先，我得明确用例图的基本元素：参与者（Actors）和用例（Use Cases），以及它们之间的关系。参与者通常包括用户、管理员等角色，而用例则是系统提供的功能。 首先确定主要参与者。对于网上书店，最基础的参与者应该是顾客，可能还有访客（未注册用户）。管理员也是一个重要角色，负责管理书籍和订单。另外，可能还需要考虑第三方支付系统，但用例图通常更关注用户与系统的直接交互，第三方可能作为外部系统参与。 接下来列举用例。顾客可以搜索书籍、查看书籍详情、注册账户、登录、添加到购物车、下单、支付、查看订单状态、取消订单、评价书籍等。访客可能需要注册或浏览书籍，但无法进行购买。管理员需要管理书籍（添加、编辑、删除）、处理订单（确认发货）、管理用户账户、查看销售报告等。 然后需要确定用例之间的关系。比如，“下单”可能包含“选择配送地址”和“选择支付方式”作为子用例，使用包含关系（include）。而“支付”可能会扩展（extend）一些异常流程，比如支付失败后的重试。 需要注意用例的粒度，不能太细也不能太泛。例如，“管理书籍”可以分解为添加、编辑、删除书籍，但如果系统较简单，可能直接作为用例。另外，是否有需要泛化的角色？比如，顾客和访客是否继承自一个通用用户角色，但通常用例图中可能直接分开。 还要考虑系统边界，确定哪些是系统内部功能，哪些是外部。比如支付可能涉及第三方，但用例图可以将其表示为外部系统参与者的交互。 现在需要整理这些用例，绘制成图。参与者放在左右两侧，用例在中间，用连线表示关系。使用包含、扩展、泛化等关系。例如，顾客在“下单”时必须“选择配送地址”，所以包含关系；而“支付”可能扩展“处理支付失败”的用例。 检查是否有遗漏的用例。比如，用户修改个人信息、查看购物车、使用优惠码、物流跟踪等是否需要添加？根据小型书店的需求，可能不需要太复杂，但基本功能要覆盖。 最后确保每个用例名称是动词短语，参与者明确，关系正确。可能还需要考虑非功能需求，比如安全性，但用例图主要关注功能需求。 可能的问题：用户是否需要分注册和未注册的不同权限？比如，访客可以浏览书籍，但不能购买，必须注册后才能下单。这需要在用例图中体现，比如“注册”用例，之后才能执行购买相关用例。 总结，用例图应包括顾客、访客、管理员三个主要参与者，各自对应的用例，以及他们之间的关系。然后根据这些绘制出结构清晰的UML用例图。</think>### 小型网上书店系统用例图设计指南 #### 一、核心参与者 1. **顾客**（注册用户） 2. **访客**（未注册用户） 3. **管理员** 4. **支付系统**（外部系统） #### 二、主要用例及关系 $$ \begin{array}{|l|l|} \hline \text{参与者} & \text{用例} \\ \hline 访客 & 浏览书籍目录、注册账户、查看书籍详情 \\ 顾客 & 登录系统、搜索书籍、管理购物车、下单购买、支付订单、查看订单状态、评价商品 \\ 管理员 & 管理书籍信息、处理订单、生成销售报告、管理用户账户 \\ 支付系统 & 处理支付请求 \\ \hline \end{array} $$ #### 三、关键关系说明 1. **包含关系** - 下单购买 $\supset$ 选择配送地址 - 支付订单 $\supset$ 选择支付方式 2. **扩展关系** - 支付订单 $\rightarrow$ 处理支付失败（异常流程） 3. **泛化关系** - 顾客继承自访客的浏览书籍目录能力 #### 四、典型用例图结构 ``` +-------------+ +-----------------+ | 访客 | | 支付系统 | +-------------+ +-----------------+ | ▲ | 浏览书籍目录 | 处理支付请求 ▼ | +-------------+ +-----------------+ | 顾客 | | 管理员 | +-------------+ +-----------------+ | ▲ | ▲ | └─管理购物车 | └─管理书籍信息 ▼ ▼ 下单购买─────────────────>处理订单 ``` #### 五、设计建议 1. **权限控制**：通过«extend»标注访客升级为顾客的注册环节，例如： $$ \text{下单购买} \xleftarrow{\text{«extend»}} \text{注册账户} $$ 2. **异常处理**：为支付失败场景添加单独的扩展用例[^1] 3. **系统边界**：使用方框标注"网上书店系统"范围，外部系统单独放置