软件工程用例图围绕用例图的疑问解答与实践指南

【软件工程用例图】围绕用例图的疑问解答与实践指南

在软件工程的需求分析和设计阶段，用例图（Use Case Diagram）是一个极其重要且常用的建模工具。它帮助我们从最终用户的角度理解系统需要提供的功能。然而，对于初学者或非专业人士来说，用例图可能会引出许多疑问。本文旨在围绕用例图，解答一些基础但核心的问题，帮助您更深入地理解和应用它。

是什么：软件工程中的用例图？

简单来说，用例图是统一建模语言（UML）中的一种行为图，用于描绘系统与外部参与者之间的交互关系，从而捕获系统的功能性需求。它关注的是“系统做什么”以响应外部请求，而不是“系统如何做”。

核心构成要素：

参与者 (Actor)：
代表与系统交互的外部实体。这可以是人类用户、外部系统、甚至硬件设备。参与者不一定是直接使用系统的个人，而是扮演某种“角色”，通过这个角色与系统进行价值交换（输入信息、接收信息）。

例如：在一个网上商城系统中，“顾客”是一个参与者，“管理员”是另一个参与者，“支付系统”也可能是一个参与者。
用例 (Use Case)：
代表系统提供的一个功能单元，是参与者通过系统完成的一个有价值的目标（Goal）。用例通常描述为动宾短语，例如“下订单”、“注册用户”、“处理支付”。每个用例都对应着系统的一系列动作，这些动作共同实现了一个特定的用户目标。

例如：网上商城系统的“下订单”用例，包含了用户选择商品、填写收货地址、选择支付方式、确认支付等一系列步骤。
系统边界 (System Boundary)：
用一个矩形框表示，框内部是用例，框外部是参与者。这个边界明确界定了我们正在建模的系统范围，以及哪些功能被包含在该系统内。

例如：绘制一个网上商城系统的用例图时，矩形框就代表了“网上商城系统”本身。
关联关系 (Relationships)：
连接参与者和用例，或连接用例和用例之间的关系。
- 关联 (Association)：
  参与者与用例之间的主要关系，用一条直线表示。表明参与者与该用例有交互。箭头方向（可选）可以表示交互的主动方或数据流向，但通常简单直线即可。
  
  例如：顾客 ——— 下订单 (顾客可以执行下订单的操作)。
- 包含 (Include)：
  表示一个用例的行为流程中必须包含另一个用例的行为流程。这通常用于提取公共的、必须执行的子流程，以减少重复。用带箭头的虚线表示，箭头指向被包含的用例，标记为<>。
  
  例如：“下订单” <> “用户登录”（在下订单前通常需要登录）。
- 扩展 (Extend)：
  表示在某个特定条件下，基础用例的行为流程可能会“扩展”执行另一个用例的行为流程。这是可选的、条件性的。用带箭头的虚线表示，箭头指向被扩展的基础用例，标记为<>。
  
  例如：“下订单” <> “使用优惠券”（用户可以选择使用优惠券，但不是必须的）。
- 泛化 (Generalization)：
  表示继承关系，用于参与者或用例。一个泛化参与者（或用例）继承了通用参与者（或用例）的行为和关系，并可以有自己独特的行为或关系。用带空心箭头的直线表示，箭头指向父级（通用）参与者或用例。
  
  例如：“VIP顾客” ——|> “顾客” (VIP顾客是一种特殊的顾客)。

为什么需要绘制用例图？

用例图是软件开发初期非常有价值的工具，其重要性体现在以下几个方面：

主要价值与目的：

需求捕获与沟通：
它是连接业务人员、用户和开发团队的桥梁。通过用例图，可以清晰地展示系统将为哪些参与者提供哪些核心功能，确保各方对系统应提供的功能达成共识。

它帮助回答：“谁会使用这个系统？他们用系统来做什么？”
界定系统范围：
系统边界框清楚地定义了项目的工作范围。什么功能包含在当前系统中？什么功能属于外部系统或不在当前迭代范围内？这有助于避免项目蔓延（Scope Creep）。
作为后续开发活动的基础：
用例图是许多其他开发活动的基础。详细的用例描述（用文字或其他图表，如活动图、序列图来描述用例的具体步骤）是开发人员实现功能、测试人员编写测试用例的重要依据。
从用户视角出发：
它强制我们将注意力放在用户如何与系统交互、用户希望通过系统达到什么目标上，而不是一开始就陷入技术细节，这有助于构建真正满足用户需求的系统。

在软件工程流程的哪里使用？

用例图主要应用于软件开发的早期阶段，但其价值贯穿整个生命周期：

应用阶段：

需求分析阶段（核心）：
这是绘制用例图最主要的阶段。在与用户和业务专家交流后，首先识别参与者和核心用例，勾勒出系统的初步功能蓝图。
设计阶段：
用例图可以作为设计的基础。虽然用例图本身不描述内部设计，但每个用例都需要在设计阶段被分解、实现。用例图可以帮助设计师理解需要支持的用户场景。
测试阶段：
用例图是系统测试和验收测试的重要输入。测试人员可以根据用例图和详细的用例描述来设计测试用例，确保系统的每一个功能（用例）都能按照预期工作，并且用户（参与者）能够成功完成他们的目标。
项目管理与沟通：
在整个项目过程中，用例图可以作为一种高层次的沟通工具，向项目经理、客户和其他非技术人员解释系统的功能范围和构成。

需要绘制多少用例图？用例的粒度如何确定？

关于用例图的数量和用例的粒度，并没有硬性规定，但有一些通用的原则可以遵循：

图的数量：

对于一个小型或简单的系统，一个用例图可能就足够了。
对于中等或大型复杂系统，通常需要绘制多个用例图：
- 一个高层次的总览图，显示主要参与者和核心功能领域。
- 针对特定子系统或特定参与者角色的详细图，显示该领域或该角色相关的全部用例。
目标是保持每个图的可读性。如果一个图变得过于拥挤、难以看清，或者包含的用例太多，就应该考虑将其拆分成多个子图。

用例的粒度：

用例的粒度是决定其抽象程度的关键。业界有不同的粒度级别划分，常见的有：

海平面 (Sea Level)：非常高层次的用例，通常对应一个大型业务流程。在一个总览图上可能看到这种粒度。
鱼眼 (Fish Level)：中等粒度的用例，代表用户与系统的一次完整交互，实现一个具体的、有价值的目标。这是最常用的粒度，也是大部分详细用例图采用的粒度。例如“下订单”、“注册用户”。
蛤蜊 (Clam Level)：非常低层次的用例，可能对应用户界面上的一个具体操作或系统内部的一个子功能。这种粒度的用例通常不会出现在用例图中，而是在用例描述中作为步骤或子流程来体现（或者作为<>或<>的被引用用例）。

建议：在用例图中，主要关注“鱼眼”粒度的用例，即那些代表用户完成一个有价值目标的交互。<>关系可以用来抽象出“蛤蜊”粒度的公共子流程。<>关系用来表示可选的“蛤蜊”粒度或变体流程。

确定粒度时，考虑以下因素：

是否代表了参与者通过系统完成的一个有价值的目标？（这是最核心的判断标准）
是否能够清晰地描述其开始和结束点？
与其他用例的关系是否清晰？
这个粒度对于开发、测试和用户沟通是否合适？

如何绘制和使用用例图？

绘制用例图是一个迭代的过程，通常需要与利益相关者密切合作。

绘制步骤：

识别系统边界：明确你正在建模的系统范围是什么。
识别参与者：思考哪些外部实体需要与系统交互？他们扮演什么角色？
识别用例：对于每个参与者，思考他们希望通过系统完成哪些有价值的目标？列出这些目标，并将其表述为用例（动宾短语）。
绘制关联：将参与者与他们相关的用例连接起来，表示他们之间的交互。
识别并添加关系：分析用例之间是否存在公共的、必须包含的子流程（<>），或者可选的、扩展的功能（<>），或者参与者/用例之间是否存在继承关系（泛化）。
添加注释或约束（可选）：使用文本框和虚线箭头添加额外的说明，如用例的简要描述、参与者的特殊条件等。
审查和完善：与用户、业务分析师、开发人员等共同审查用例图，确保其准确、完整且易于理解。根据反馈进行修改和完善。

使用与解读：

从参与者视角解读：解读用例图时，总是从一个参与者开始，看他可以执行哪些用例，以及这些用例通过什么方式相互关联。
结合用例描述：用例图只是一个概览。理解用例的完整含义必须结合详细的用例描述文档，其中会详细阐述用例的前置条件、后置条件、主流程（正常场景下的步骤）、备选流程（异常或不同路径下的步骤）。
聚焦功能，忽略UI细节：用例图关注的是“做什么”，而不是“如何通过界面操作去做”。不要在用例图中试图表达用户界面（UI）的细节。
作为讨论和确认的工具：在会议中展示和讨论用例图，用它来引导关于系统功能的对话，确保所有人的理解一致。

总之，软件工程用例图是一个强大的工具，它以一种用户中心的方式，清晰地表达了系统的功能性需求。通过理解其构成、目的、使用时机以及绘制方法，我们可以更有效地进行需求分析、规划系统范围，并为后续的开发和测试活动奠定坚实的基础。

软件工程用例图