用例图主要描述了自动售货机系统中的两个用例：“购买饮料”和“退还硬币”，这些用例涉及到顾客与自动售货机之间的交互-优快云博客

工作过程描述

顾客选择：顾客选择需要购买的饮料及数量。
投入硬币：顾客从投币口向自动售货机中投入硬币（该自动售货机只接收硬币）。硬币器收集投入的硬币并计算其对应的价值。如果所投入的硬币足够购买所需数量的这种饮料且饮料数量足够，则推出饮料，计算找零，顾客取走饮料和找回的硬币；如果投入的硬币不够或者所选的饮料数量不足，则提示用户继续投入硬币或重新选择饮料及数量。
交易完成：一次购买结束之后，将硬币器中的硬币移走（清空硬币器），等待下一次交易。自动售货机还设有一个退币按钮，用于退还顾客所投入的硬币。已经成功购买饮料的钱是不会退回的。

用例图

图3-1展示了顾客和自动售货机之间的交互关系：

顾客可以选择“购买饮料”和“退还硬币”两个操作。

用例描述

参与者：顾客
主要事件流：
1. 顾客选择需要购买的饮料和数量，投入硬币；
2. 自动售货机检查顾客是否投入足够的硬币；
3. 自动售货机检查饮料储存仓中所选购的饮料是否足够；
4. 自动售货机推出饮料；
5. 自动售货机返回找零。
备选事件流：
- 2a. 若投入的硬币不足，则给出提示并退回到1；
- 3a. 若所选购的饮料数量不足，则给出提示并退回到1。

状态图

根据用例“购买饮料”得到自动售货机的4个状态：“空闲”状态、“准备服务”状态、“可购买”状态及“饮料出售”状态，对应的状态图如图3-2所示。

总结

这张图片详细描述了自动售货机的工作流程、用例图、用例描述以及状态图，帮助理解自动售货机的运作机制和顾客交互过程。

自动售货机软件系统用例图存在以下局限性：

一、参与者与场景覆盖局限

参与者单一：仅体现“顾客” 这一个参与者，实际系统中，像维护人员（补充饮料、维修设备）、系统管理员（设置价格、查看销售数据）等角色与系统有交互，未在图中呈现，难以全面反映系统涉众。
场景描述浅：“购买饮料” 用例虽有基本事件流，但对复杂场景（如投币含多种面值组合、找零涉及多种硬币搭配等）、异常场景（硬币识别故障、饮料卡货）覆盖不足，不能细致指导系统应对多样实际情况。

二、系统功能关联呈现不足

功能交互弱：用例图未清晰展现“购买饮料”“退还硬币” 与系统其他潜在功能（如库存管理系统、支付记账模块）的关联，难以体现系统功能间数据流转、依赖关系，不利于理解系统整体架构。
非功能需求缺失：未涉及性能（如高峰时段响应速度）、安全（硬币支付防篡改）等非功能需求，这些对系统设计与实现至关重要，缺之则无法从用例图层面考量系统健壮性、可靠性。

三、动态行为刻画短板

状态变化简化：仅依据“购买饮料” 用例提炼部分状态，未完整呈现自动售货机全生命周期状态变迁（如故障状态、补货状态及各状态间复杂转换条件），难以精准指导系统状态机设计。
时序细节模糊：用例事件流未体现操作时序严格约束（如投币、选饮料操作顺序调换后的处理），对于需精准时序控制的软件逻辑，无法有效提供设计依据，易导致开发时时序处理漏洞。
要扩展自动售货机软件系统用例图的参与者，可从识别实际与系统交互的不同角色入手，具体如下：

1. 维护人员

补充饮料：维护人员需定期检查饮料库存，当库存不足时，执行“补充饮料” 操作，将新的罐装饮料放入售货机储存仓，对应新增“补充饮料”用例，与维护人员参与者关联，用于更新饮料数量，保障销售。
维修设备：若售货机出现硬币识别故障、饮料推出卡滞等问题，维护人员执行“维修设备” 用例，对硬件（如硬币器、出货装置）和软件系统进行检测、修复，确保售货机正常运行。

2. 系统管理员

设置价格：系统管理员通过“设置价格” 用例，调整不同饮料的售价，可根据成本、市场策略等因素，修改售货机中饮料价格参数，影响顾客购买支付流程。
查看销售数据：管理员借助“查看销售数据” 用例，获取售货机的销售记录，包括各饮料销售数量、营收金额、高峰购买时段等信息，用于运营分析、决策。

3. 支付平台（若拓展线上支付）

线上支付交互：若引入移动支付等线上支付方式，新增“支付平台” 参与者，顾客可通过该平台完成付款，对应新增“线上支付” 用例，涉及与支付平台的数据交互（如付款请求发送、支付结果回调），替代或补充原有的硬币支付流程。

将这些新识别的参与者及对应交互用例添加到原用例图中，就能扩展参与者，更全面反映自动售货机软件系统的实际交互场景。
以下这些角色也可能成为自动售货机软件系统的参与者：

支付平台：若支持移动支付（如微信、支付宝）或银行卡支付等，支付平台作为外部系统，与自动售货机软件系统交互完成付款流程，属于参与者，涉及“发起支付”“接收支付结果”等交互。
供应商：负责给自动售货机补充商品库存，会与系统交互执行“补充库存”操作，还可能查看库存消耗数据，以便合理安排补货，是系统参与者之一。
运营管理系统：企业后台的运营管理系统，可用于远程监控自动售货机状态（如销售数据、设备故障、库存情况），通过与售货机软件系统数据交互，实现“监控设备”“获取销售报表”等功能，作为外部系统成为参与者。
物流配送系统（若涉及）：当自动售货机需要补货、维修部件更换时，物流配送系统与售货机软件系统联动，接收配送任务、反馈配送状态，参与“设备补货配送”“维修件配送”等流程。
会员系统（若有）：要是售货机支持会员体系，会员系统作为外部系统，和售货机软件系统交互，实现“会员身份验证”“积分累计与使用”等功能，属于参与者。
广告投放系统：若售货机带广告展示功能，广告投放系统会向其推送、更新广告内容，与售货机软件系统有“广告内容同步”“广告播放统计反馈”等交互，可作为参与者。

要确保自动售货机软件系统用例图中不同参与者的交互清晰无歧义，需从用例图元素规范设计和场景逻辑细化两方面入手，具体方法如下：

一、用例图元素设计规范

1. 明确参与者类型与边界

区分「人」与「外部系统」：
- 参与者若为实体角色（如顾客、维护人员），用「人形图标」表示，并标注角色名称（如“顾客”“维护人员”）。
- 参与者若为外部系统（如支付平台、运营管理系统），用「矩形图标」表示，并标注系统名称（如“支付平台”“运营管理系统”）。
避免角色混淆：
- 同一实体若有不同职责（如“普通管理员”和“高级管理员”），需拆分为独立参与者（如“系统管理员”“高级管理员”），避免合并导致职责模糊。

2. 用例命名与描述标准化

用例名称：采用“动词+名词”结构（如“购买饮料”“补充库存”“同步广告内容”），明确参与者发起的动作对象。
用例描述：每个用例需附带前置条件、主事件流、备选/异常事件流，确保交互逻辑完整。
- 示例：
  用例名称：线上支付
  参与者：顾客、支付平台
  前置条件：顾客已选择饮料，系统生成支付订单
  主事件流：
  1. 顾客选择“微信支付”，系统向支付平台发送支付请求；
  2. 支付平台返回支付二维码，顾客扫码完成付款；
  3. 支付平台向系统返回支付成功结果，系统出货。

3. 交互关系线标注清晰

用箭头明确交互方向：
- 参与者发起用例时，用带箭头实线连接参与者与用例（如“顾客 → 购买饮料”）。
- 外部系统与用例的双向数据交互（如支付平台与“线上支付”），用双向箭头或两条单向箭头表示。
避免线条交叉冗余：
- 同类参与者（如多个系统）集中排列，用例按功能模块分组（如“支付模块”“维护模块”），减少线条交叉，提升可读性。

二、场景逻辑细化与验证

1. 分层级梳理交互场景

基础层：聚焦顾客核心操作（如购买、退币），确保主流程简洁明确。
扩展层：补充维护人员、管理员等角色的后台操作（如补货、调价），通过包含关系（<>）或扩展关系（<>）关联基础用例，避免重复描述。
- 示例：“补充饮料”用例可通过<>关联“更新库存”逻辑，避免在多个用例中重复编写库存更新步骤。

2. 识别并标注依赖关系

用例间依赖：若一个用例的执行需依赖另一个用例的结果（如“查看销售数据”依赖“记录销售记录”），用依赖关系线（虚线箭头+<>）标注。
参与者间间接交互：若两个参与者不直接交互，但通过系统数据传递产生关联（如维护人员补货后，管理员查看库存数据），可在备注中说明逻辑关系，避免图中线条复杂化。

3. 引入泳道图或时序图辅助说明

当用例图中交互逻辑复杂（如多参与者协同操作）时，可搭配泳道图（展示各参与者职责分区）或时序图（明确操作时序与消息传递顺序），补充说明细节。
- 示例：“线上支付”用例可通过时序图展示顾客、系统、支付平台之间的消息发送顺序（如支付请求→二维码生成→付款通知→出货指令）。

4. 评审与迭代优化

绘制用例图后，组织开发人员、产品经理、实际用户（如维护人员）进行评审，验证以下内容：
- 参与者是否遗漏（如是否需加入“审计人员”查看操作日志）；
- 交互流程是否符合实际业务（如补货流程是否需管理员审批）；
- 异常场景（如支付超时、库存不足）是否有对应处理逻辑。
根据反馈调整用例图，确保逻辑与实际业务一致。

三、工具与文档支持

使用专业建模工具：如Visio、PlantUML、StarUML等，利用工具内置的UML规范模板，自动生成符合标准的用例图元素（如参与者图标、关系线样式）。
编写用例文档：为每个参与者和用例建立详细文档，记录角色职责、用例触发条件、数据输入输出等，作为用例图的补充说明，避免图中信息过载。

通过以上方法，可确保用例图清晰展示不同参与者的交互边界、操作逻辑和依赖关系，减少需求理解偏差，为系统设计提供明确依据。

用例图主要描述了自动售货机系统中的两个用例：“购买饮料”和“退还硬币”。这些用例涉及到顾客与自动售货机之间的交互。

参与者

顾客：是唯一参与交互的外部实体。

用例

购买饮料
- 主要事件流：
  1. 顾客选择需要购买的饮料和数量，投入硬币；
  2. 自动售货机检查顾客是否投入足够的硬币；
  3. 自动售货机检查饮料储存仓中所选购的饮料是否足够；
  4. 自动售货机推出饮料；
  5. 自动售货机返回找零。
- 备选事件流：
  - 2a. 若投入的硬币不足，则给出提示并退回到1；
  - 3a. 若所选购的饮料数量不足，则给出提示并退回到1。
退还硬币
- 顾客可以通过一个按钮来请求退还已投入的硬币。

状态

自动售货机的状态包括：

空闲：自动售货机处于初始状态，等待顾客操作。
准备服务：顾客开始选择饮料和数量。
可购买：顾客已选择饮料和数量，准备投币。
饮料出售：饮料已推出，找零完成。

类图

虽然图片中没有展示具体的类图内容，但提到了类图。类图通常用于描述系统中的类及其关系，包括类的属性、方法和类之间的关系（如继承、关联等）。在自动售货机系统中，类图可能包括如下类：

顾客类：包含顾客的基本信息和操作。
自动售货机类：包含自动售货机的状态、方法（如检查硬币、推出饮料等）。
饮料类：包含饮料的基本信息。
硬币类：包含硬币的基本信息和计算方法。

这些类图和用例图共同构成了自动售货机系统的分析和设计基础，帮助开发人员理解和实现系统的功能。
有许多工具可以辅助生成清晰无歧义的用例图，以下是一些常见的工具介绍：

Lucidchart：这是一款流行的基于云的绘图工具，界面友好，提供了丰富的模板。它支持实时协作，适合团队共同绘制用例图，还能与其他应用程序集成，功能较为多样。
Visual Paradigm：是一款功能强大的UML和绘图工具，支持创建用例图。它具备高级建模功能、模板库以及协作工具，无论是小型项目还是大型项目都适用。
Microsoft Visio：被广泛用于创建各种图表，包括用例图。其界面易于使用，可与其他Microsoft产品集成，并且有大量的形状和模板可供选择，能绘制出专业美观的用例图。
draw.io：这是一款免费的开源绘图工具，提供了一系列创建用例图的功能，适合小型项目或个人使用，成本较低。
Astah UML：是专为软件工程师设计的UML建模工具，支持包括用例图在内的各种UML图表，以用户友好和高效的图表创建功能而闻名。
Creately：在线绘图工具，提供了简单直接的方式来创建用例图，有丰富的模板库和协作功能，界面操作方便，能帮助用户快速生成清晰的用例图。
自动售货机的类图应该包含与自动售货机系统相关的所有主要类，这些类可以描述系统的结构和行为。以下是一些可能包含在自动售货机类图中的类：

VendingMachine（自动售货机）
- 属性：
  - status：表示自动售货机的当前状态（如空闲、服务中、需要维护等）。
  - coinDispenser：硬币分配器，用于处理找零。
  - productInventory：产品库存，存储饮料的数量和种类。
  - coinReceiver：硬币接收器，用于接收顾客投入的硬币。
- 方法：
  - selectProduct(int productId, int quantity)：选择产品和数量。
  - insertCoin(double amount)：投入硬币。
  - dispenseProduct(int productId)：分配产品。
  - returnChange()：返回找零。
  - checkInventory(int productId, int quantity)：检查库存。
Product（产品）
- 属性：
  - productId：产品ID。
  - name：产品名称。
  - price：产品价格。
  - quantity：库存数量。
- 方法：
  - updateQuantity(int newQuantity)：更新库存数量。
CoinReceiver（硬币接收器）
- 属性：
  - collectedCoins：收集的硬币总额。
- 方法：
  - receiveCoin(double amount)：接收硬币。
  - getTotalAmount()：获取总金额。
CoinDispenser（硬币分配器）
- 属性：
  - changeAvailable：可用找零的硬币。
- 方法：
  - dispenseChange(double amount)：分配找零硬币。
InventoryManager（库存管理器）
- 属性：
  - products：所有产品的列表。
- 方法：
  - checkProductAvailability(Product product, int quantity)：检查产品可用性。
  - updateProductQuantity(Product product, int quantity)：更新产品库存。
Customer（顾客）
- 属性：
  - customerId：顾客ID。
  - selectedProducts：选择的产品列表。
- 方法：
  - selectProduct(Product product, int quantity)：选择产品和数量。
  - insertCoin(double amount)：投入硬币。
Transaction（交易）
- 属性：
  - transactionId：交易ID。
  - customer：顾客对象。
  - selectedProducts：选择的产品列表。
  - totalAmount：总金额。
  - change：找零金额。
- 方法：
  - processTransaction()：处理交易。
  - calculateChange()：计算找零。