统？
②谁从系统获取服务或信息？
③谁对系统有操作权限？
④谁需要接收系统的通知或更新？
参与者（Actor）是用例图中的关键元素，它们代表了与系统交互的不同实体，可以是人，也可以是外部系统。在识别参与者时，需要考虑他们的角色、职责和交互方式。例如，对于一个购物系统，参与者可能包括顾客、管理员、供应商等。
知识点3：用例的概念
用例（Use Case）是用例图的核心，它代表了系统或子系统提供的一个功能或服务，是从用户视角看系统如何响应参与者的行为。用例描述了一个特定的、有价值的结果，这个结果是通过系统和参与者之间的交互产生的。用例通常由以下几部分组成：
1. 名称：简洁明了地概括了用例的目的。
2. 参与者：描述与用例交互的实体。
3. 前提条件：用例开始前需要满足的条件。
4. 主要场景：描述用例的典型流程。
5. 扩展场景（异常或备选流）：描述可能发生的异常情况或额外步骤。
6. 后置条件：用例执行后系统或环境的状态变化。
知识点4：识别用例图
识别用例图的过程通常涉及以下步骤：
1. 定义范围：明确系统边界，确定哪些功能属于系统，哪些不属于。
2. 识别参与者：通过与利益相关者的交流，找出所有可能的参与者。
3. 描述用例：为每个参与者确定与系统交互的一系列行为，形成用例。
4. 描述关系：分析用例间的关联，如泛化、包含、扩展等。
5. 绘制用例图：将参与者、用例和它们的关系可视化，便于沟通和理解。
知识点5：用例与事件流
事件流是用例的主要场景，它描述了参与者如何启动一个用例，系统如何响应，以及可能的分支路径。事件流通常以顺序图或活动图的形式呈现，详细展示了系统行为的流程。
知识点6：用例之间的关系
用例间的关系主要有三种：
1. 泛化（Generalization）：表示一个更通用的用例（父用例）被一个或多个更具体的用例（子用例）继承。
2. 包含（Inclusion）：一个用例（包括者）包含了另一个用例（被包括者）的逻辑，使得用例更易于管理和重用。
3. 扩展（Extension）：一个用例（扩展者）在另一个用例（被扩展者）的基础上添加了额外的行为，通常是在特定条件下的附加步骤。
知识点7：实例-购物系统中的用例视图分析
在购物系统中，可能的用例包括：
- 注册/登录：顾客创建账户或登录系统。
- 浏览商品：顾客查看各种商品信息。
- 添加到购物车：顾客选择商品并将其加入购物车。
- 结算：顾客确认购物车中的商品，进行支付。
- 订单管理：顾客查看、修改或取消订单。
- 客户服务：顾客寻求帮助或反馈问题。
这些用例与不同类型的参与者（如顾客、管理员）相关联，并可能存在如泛化、包含和扩展的关系。例如，"结算"用例可能扩展自"浏览商品"，在特定条件下提供优惠券应用或礼品包装选项。
用例图是UML中一种重要的需求建模工具，它通过图形化的方式展示了系统、参与者及它们之间的交互，帮助我们理解和沟通系统的功能需求。正确地理解和使用用例图，对于软件开发的早期阶段至关重要，因为它直接影响到后续的设计、开发和用户满意度。
我的内容管理
展开
