使用用例建模的全面指南

什么是用例建模？

这是一种在软件开发和系统工程中使用的技术，用于描述系统的功能需求。它侧重于从最终用户的角度理解并记录系统应有的工作方式。本质上，它有助于回答这个问题：“系统应该做什么才能满足用户的需求和目标？”

用例建模的关键概念

功能需求：功能需求是系统为实现其预期目的必须具备的功能、操作和行为。用例建模主要关注以结构化的方式定义和捕捉这些需求。

最终用户视角：用例建模从与系统交互的人或实体（称为“参与者”）的视角出发来审视系统。理解这些参与者如何使用系统来实现其目标或完成任务至关重要。

交互：用例建模强调捕捉这些最终用户（参与者）与系统之间的交互。这不仅仅是系统独立运作的情况；而是关注系统如何响应用户操作或请求。

用例的基本概念：

• 用例是系统与一个或多个外部实体（称为参与者）交互以实现特定目标的描述。
• 根据所需细节和复杂程度的不同，用例可以以文本或图示形式编写。
• 用例应捕捉交互中的关键和相关方面，例如前置条件、后置条件、主流程、备选流程和异常情况。

什么是用例图？

用例图是用例建模中用于可视化和沟通这些交互与关系的图形表示。在用例图中，通常会看到参与者以小人形象表示，用例（特定功能或特性）以椭圆或矩形表示。线条和箭头将参与者与用例连接起来，展示它们之间的交互方式。

 

• • 参与者：这些是与系统交互的系统外部的实体或用户。它们可以是人、其他系统，甚至是外部硬件设备。每个参与者在系统中都有特定的角色或职责。
  • 用例：用例代表系统为满足参与者需求而能够执行的特定功能或过程。每个用例通常都有一个名称和描述，有助于理解其完成的内容。
  • 关系：图中连接参与者和用例的线条和箭头展示了参与者如何通过这些用例与系统交互。可以使用不同类型的关系，如关联关系、扩展关系和包含关系，来说明这些交互的性质。

如何进行用例建模？

1. 要理解一个用例，需要识别系统中涉及的参与者和用例。
   参与者是与系统交互中扮演角色的外部实体。参与者可以是人、另一个系统，或一个时间事件。
2. 用例是一组场景，描述系统与参与者如何协作以实现共同目标1。场景是描述特定情境下发生事件的一系列步骤1。
   用例建模中的参与者：
3. 参与者在用例图中以小人形象表示。
   参与者可以具有泛化关系，表示一个参与者继承另一个参与者的特征和行为。例如，学生参与者可以是本科生参与者和研究生参与者的泛化。
4. 参与者还可以具有关联关系，表示一个参与者参与某个用例。例如，教师参与者可以与成绩分配用例相关联。

参与者与用例之间的关系：

• 用例可以具有包含包含关系，表示一个用例在其正常执行过程中包含另一个用例的行为。例如，登录用例可以被许多需要认证的其他用例所包含。
  • 包含关系是两个用例之间的依赖关系，其中一个用例（基础用例）在其正常执行过程中包含另一个用例（包含用例）的行为。
  • 包含关系通过从基础用例指向包含用例的带«include»构造型的虚线箭头表示。
  • 包含关系可用于重用通用功能、简化复杂用例或抽象底层细节

• 用例也可以具有扩展扩展关系，表示在特定条件下，一个用例向另一个用例添加可选或异常行为。例如，如果用户决定取消预订，取消预订用例可以扩展预订用例。
  • 扩展关系是两个用例之间的依赖关系，其中一个用例（扩展用例）在特定条件下向另一个用例（基础用例）添加一些可选或异常行为。
  • 扩展关系通过从扩展用例指向基础用例的带«extend»构造型的虚线箭头表示。
  • 扩展关系可以有一个扩展点，即基础用例中可以插入扩展的位置。
  • 扩展点可以用名称和条件进行标记

创建有效的用例：

• 识别系统边界：
  • 系统边界是一个包围用例的框，显示系统的范围。
  • 系统边界有助于区分系统内部（用例）和系统外部（参与者）。
  • 系统边界应明确标注系统名称及其版本号1。
• 定义用例目标和场景:
  • 用例目标是总结用例为参与者实现内容的陈述。
  • 用例目标应具体、可衡量、可实现、相关且可测试。
  • 用例场景是描述参与者与系统如何交互以实现目标的一系列步骤。
  • 用例场景应完整、一致、现实且可追溯。
• 编写清晰简洁的用例描述:
  • 用例描述是一份文本文档，提供更多关于用例的细节，例如前置条件、后置条件、主流程、备选流程和异常情况。
  • 用例描述应清晰简洁，使用简单准确的语言，避免术语和歧义，并遵循一致的格式。
  • 用例描述还应具有连贯性和全面性，涵盖所有可能的场景、结果和变体，并满足所有相关需求。
• 用例模板和文档:
  • 用例模板是一种标准化的格式，有助于以一致且结构化的方式组织和呈现用例信息。
  • 用例模板可以包含多个部分，例如用例名称、ID、目标、参与者、优先级、假设、前置条件、后置条件、主流程、备选流程、异常情况等。
  • 用例文档是一组用例的集合，从不同角度描述系统的功能。
  • 用例文档可用于多种目的，例如沟通、验证、确认、测试、维护等。

用例建模最佳实践：

• 一些用例建模的最佳实践包括：
  • 识别 关键利益相关者 及其目标，并让他们参与用例开发过程
  • 采用 自上而下 方法来识别和优先处理最重要的用例
  • 采用 命名规范 以确保用例和参与者命名的一致性、意义性和描述性
  • 使用 图表 和 文字描述 相互补充，提供不同层次的细节
  • 使用 关系 如扩展、包含和泛化，以展示用例之间的依赖关系和共性
  • 审查并 验证 与利益相关者一起审查用例，确保其与系统需求保持一致

使用用例模板进行用例建模

问题描述：大学图书馆系统

大学图书馆系统正面临一系列运营挑战，这些挑战影响其效率以及为学生、教职员工提供的服务质量。这些挑战包括：

1. 手动借还流程：图书馆依赖纸质流程进行图书借阅、归还和到期日跟踪。这种手动方式容易出错，导致记录不一致，并偶尔引发图书馆工作人员与用户之间的纠纷。
2. 库存管理：当前管理图书馆大量图书和资料的系统已经过时。缺乏高效的库存管理系统，使得查找特定物品变得困难，导致图书馆用户感到沮丧并造成不必要的延误。
3. 逾期费用追踪：追踪和收取逾期图书的滞纳金是一项具有挑战性的任务。图书馆工作人员缺乏自动化系统来准确监控到期日并评估罚款。这导致收入损失，并给用户带来不便。
4. 用户账户管理：用户账户（包括借书卡的发放与管理）依赖人工流程。这导致新学生获取图书馆资源的访问权限出现延迟，也使得现有成员的信息更新变得困难。
5. 访问受限：当前图书馆系统缺乏用户在线搜索图书、预约或远程续借已借出书籍的功能。这一限制阻碍了现代学生和教职员工所期望的便利性和可访问性。
6. 资源分配效率低下：图书馆工作人员常常面临优化资源（如图书、期刊和学习空间）分配的挑战。缺乏实时数据和分析，使得难以做出关于资源分配的明智决策。
7. 沟通障碍：图书馆工作人员与用户之间存在沟通障碍。用户常常不了解图书馆政策、新书到馆信息或营业时间的变动，导致误解和不满。
8. 安全问题：图书馆系统缺乏足够的安全措施来保护用户数据，并防止资源被盗或未经授权访问。

这些挑战共同导致图书馆工作人员和用户都面临次优的图书馆体验。解决这些问题并现代化大学图书馆系统，对于提供高效服务、提升用户满意度以及改善大学社区的整体学术体验至关重要。

用例模板：

以下是大学图书馆借书用例的模板和示例，以表格形式呈现：

用例名称	借书
用例编号	UC001
主要参与者	学生
次要参与者	图书管理员，图书库存系统
前置条件	– 学生持有有效的图书馆卡。
	– 该书在图书馆的库存中可借。
后置条件	– 该书在系统中标记为已借出。
	– 学生已持有该书。
主流程	1. 描述： 学生希望借阅一本
	大学图书馆的书。
	2. 参与者操作：
	– 学生向图书管理员出示其图书馆卡。
	图书管理员。
	– 图书管理员扫描借书证以
	验证其有效性。
	– 学生提供想要借阅的书籍的书名或ISBN号。
	他们希望借阅的书籍。
	– 图书管理员在图书馆目录中搜索该书。
	这本书。
	– 图书管理员确认该书的可借性。
	– 图书管理员将该书借给学生。
	学生。
	– 学生拿走书籍并离开图书馆。
	图书馆。
	3. 系统操作：
	– 系统验证借书证的有效性。
	– 系统将书籍状态更新为
	“已借出”。
	– 系统记录书籍的到期日期。
	借阅。
	– 系统为该交易生成收据。
	交易。
	4. 替代流程：
	– 如果学生的借书证无效，图书管理员将告知学生，用例结束。
	图书管理员告知学生，用例终止。
	用例终止。
	– 如果所请求的书籍不可用，图书管理员将告知学生，用例结束。
	图书管理员告知学生，用例终止。
	用例终止。
扩展	– 如果学生有逾期未还的书籍，系统将发出通知。
	发送给学生。
	– 如果学生想要续借这本书，他们可以
	通过图书馆网站申请续借。
特殊要求	– 系统应有一个安全的
	图书馆持卡人数据库。
	– 到期日和滞纳金应由系统计算并
	由系统执行。

用例示例：从大学图书馆借书

用例名称	借一本书
用例编号	UC001
主要参与者	学生
次要参与者	图书管理员，图书库存系统
前置条件	– 学生持有有效的图书馆卡。
	– 该书在图书馆的库存中可借。
后置条件	– 该书在系统中标记为已借出。
	– 学生已持有该书。
主流程	1. 描述： 学生想要借一本书
	从大学图书馆借一本书。
	2. 参与者操作：
	– 学生向图书管理员出示他们的借书证。
	图书管理员。
	– 图书管理员扫描借书证以
	验证其有效性。
	– 学生提供他们想要借阅的书籍的书名或ISBN。
	他们想要借阅的书籍。
	– 图书管理员在图书馆目录中搜索该书。
	这本书。
	– 图书管理员确认该书的可借性。
	– 图书管理员将该书借给学生。
	学生。
	– 学生拿走书籍并离开图书馆。
	图书馆。
	3. 系统的操作：
	– 系统验证借书证。
	– 系统将书籍的状态更新为
	“已借出”。
	– 系统记录书籍的到期日。
	借阅。
	– 系统为该交易生成收据。
	交易。
	4. 替代流程：
	– 如果学生的借书证无效，图书管理员会告知学生，用例终止。
	图书管理员会告知学生，用例终止。
	用例终止。
	– 如果所请求的书籍不可用，图书管理员会告知学生，用例终止。
	图书管理员会告知学生，用例终止。
	用例终止。
扩展	– 如果学生有逾期书籍，会发送通知
	给学生。
	– 如果学生想续借书籍，他们可以
	通过图书馆网站申请续借。
特殊要求	– 系统应有一个安全的数据库，包含
	图书馆持卡人信息。
	– 还书日期和滞纳金应由系统计算并
	强制执行。

以上表格以结构化和有序的方式呈现用例模板和示例，使阅读和理解用例的关键要素更加容易。

用例的粒度

用例粒度定义：用例粒度指的是用例规范中的详细程度和组织程度。它本质上描述了在记录用例时，你将系统功能分解到何种精细程度。简单来说，它关乎你将一个用例分解为更小部分或步骤的程度。

用例粒度的重要性:

1. 沟通增强：用例粒度在改善软件项目中不同利益相关者（如业务分析师、开发人员、测试人员和最终用户）之间的沟通方面起着关键作用。当用例定义清晰且粒度适当时，各方都能更好地理解系统的功能和需求。
2. 项目规划：用例的粒度水平会影响项目规划。更小、更精细的用例有助于更准确地估算开发任务所需的时间和精力。这有助于项目经理制定更精确的项目进度和资源分配。
3. 清晰性和精确性：达到适当的粒度水平可确保用例清晰且精确。如果用例过于高层和抽象，可能缺乏有效开发所需的必要细节。相反，过于详细的用例可能变得难以管理。

示例：让我们通过一个电子商务应用程序中“用户注册”功能的示例来说明用例粒度：

• 高粒度：一个名为“用户注册”的单一用例涵盖了从开始到结束的整个注册过程。它包括所有步骤，例如输入个人信息、创建密码、确认密码以及提交注册表单。
• 中等粒度：用例被划分为更小且更专注的部分。例如，“输入个人信息”、“创建密码”和“提交注册”可以是独立的用例。每个用例都专注于用户注册的某个特定方面。
• 低粒度：最低粒度可能涉及将单一步骤中的操作进一步分解。例如，“输入个人信息”可以进一步分解为“输入名字”、“输入姓氏”、“输入电子邮件地址”等。

适当的粒度水平取决于项目需求以及利益相关者的具体需求。找到合适的平衡点至关重要，以确保用例易于理解、易于管理，并能有效地向所有相关方传达系统功能。

在《编写有效用例》一书中，艾拉斯泰尔·科本提供了一个简单的类比，帮助我们直观地理解目标达成的不同层次。他建议用海洋的类比来思考这些层次

参考文献：

1. 什么是用例图？（visual-paradigm.com）
2. 什么是用例规范？