Software System Analysis and Design（4）用例建模 - 绘制用例图

最新推荐文章于 2026-06-24 07:48:57 发布

原创最新推荐文章于 2026-06-24 07:48:57 发布 · 649 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

homework

本文详细介绍了用例的概念，包括简要、简便和完整三种形式，探讨了用例与场景的关系。用例图作为系统功能的模型图，包括参与者、用例、系统边界和它们之间的关系。文章还阐述了用例图的基本元素、绘制步骤及价值，强调了在复杂业务中编制完整用例的挑战。最后，通过建模练习题展示了如何利用用例图来识别系统功能和创新点。

简答题
1. 用例的概念
  - 用例是一个相关的成功和失败场景的集合，描述了一个角色使用系统完成目标。
2. 用例和场景的关系？什么是主场景或 happy path？
  - 一个用例表示一个场景的集合：主场景，加上零个或更多的可选场景。
  - 主场景对应主要的系统交互，通常是“成功”场景。
3. 用例有哪些形式？
  - 简要（Brief）：简单的一段式摘要，通常是主要的成功案例。在早期需求分析期间，快速了解主题和范围。创建可能只需几分钟。
  - 简便格式（Casual）：非正式段落格式。多个段落覆盖各种场景。
  - 完整（Fully）：所有的步骤和变化都写得很详细，并有辅助的部分，如前提条件和成功保证。
4. 对于复杂业务，为什么编制完整用例非常难？
  - 复杂业务涉及的场景数量会变得很多，场景之间也有各种关联，业务流程复杂，用例的编写需要对这些场景熟悉。
5. 什么是用例图？
  - 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
6. 用例图的基本符号与元素？
  - 参与者（Actor）
  - 用例（Use Case）
  - 系统边界（System Boundary）
  - 关系（Communication）
    - 关联（Association）
    - 泛化（Inheritance）
    - 包含（Include）
    - 扩展（Extend）
7. 用例图的画法与步骤
  1. 确定研讨的系统
    - 使用用例图 System框表示一个待研究的系统
    - 正确命名系统或子系统，例如 Reserve Hotel。
    - 千万不要将研究的系统的名称起的太泛，如“网上商店”。正确的姿势是“网上书店”，以避免业务空泛问题
  2. 识别 Actors
    - 识别使用系统的主要参与者（primary actors）/角色(roles)
      - 使用用例图 actor符号表示，通常放在系统的左边
      - 企业应用可以通过企业组织架构，业务角色与职责识别
      - 互联网应用则必须通过市场分析，确定受众范围
      - 千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同
    - 识别系统依赖的外部系统
      - 使用用例图 Neighboursystem框表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别
        
        <<system>> 例如：Account System（财务系统），教务系统
        
        <<service>> 例如：第三方身份认证、地理信息服务、短信服务等第三方在线服务
        
        <<device>> 或 <<sensor>> 例如：GPS 等等
      - 要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统，除了订单配送、支付、销售账单由其他专业系统完成外，房源管理都应由独立系统完成，以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一
  3. 识别用例（服务）
    - 识别用户级别用例（user goal level）
      - 以主要参与者目标驱动
      - 收集主要参与者的业务事件
      - 必须满足以下准则
        
        boss test
        
        EBP test
        
        Size Test
      - manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
    - 识别子功能级别的用例（sub function level）
      - 子用例特征
        
        业务复用。例如：现金支付
        
        复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现
        
        强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的
      - 正确使用用例与子用例之间的关系
        
        <<include>> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！
        
        <<extend>> 表示子用例是父用例的可选场景或技术特征。
        
        <<include>> 箭头指向子用例；<<extend>> 箭头指向父用例。箭头表示的依赖关系！
  4. 建立 Actor 和 Use Cases 之间的关联
    - 请使用无方向连线，表示两间之间是双向交互的协议
8. 用例图给利益相关人与开发者的价值有哪些？
  - 明确系统的业务范围、服务对象（角色）、外部系统与设备
  - 帮助识别技术风险，提前实施关键技术原型公关与学习
  - 易于评估项目工作量，合理规划迭代周期，规划人力需要

建模练习题（用例模型）

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。

然后，回答下列问题：

为什么相似系统的用例图是相似的？

这是因为用例图由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。
如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术。

提供民俗预订服务，结合用户出租房屋的功能，使旅行者与本地人都能使用并获益。
如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

用例图中对创新用例使用某种颜色进行高亮标记。

请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

ID	Name	Imp	Est	How to demo	Notes
1	搜索房源	50	4	通过地图、条件等让用户筛选房源	通过谷歌地图API划定范围
2	查看行程	30	4	查看所有行程，并对已预订的行程作出修改、评价等行为	需要与房源的退订策略匹配
3	生成订单	50	10	根据所选的房源、日期等信息生成订单	生成后可跳转支付界面，同时将通知房东
4	支付订单	80	2	根据订单金额支付订单	调用用户所选支付手段的API
5	信息管理	50	2	用户可更改个人信息	身份证、护照等信息需核实

根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算

用例	事务	计算	原因	UC权重
搜索房源	2	4	搜索条件多，包括模糊搜索	平均
查看行程	2	2		简单
生成订单	3	4	需要与房源确认信息	平均
支付订单	3	2	调用API	简单
信息管理	2	1		简单