第5讲 用例建模

涉众无法直接提供需求的现象

涉众无法陈述自己的需要


涉众说的是解决方案而不是需求
涉众难以构想新的工作方法


涉众的利益矛盾
涉众抵制变更


“最好也要有”—过度的要求
需求引发新的需求
获取需求的技巧——需求启发技术
技巧 描述 直接观察个人工作的情况，以发现现存的实践方 实地观察 式和问题，提供最直观的业务细节，但耗时 访谈 从个人处收集特定信息，直接沟通，信息真实性 特定群体 对一组人员进行调查，以便了解工作态度和共同 看法 调查 收集详细数据和统计意义上比较重要的数据，可 问卷调查 以获得匿名答复 用户指导 让最终用户告诉你，他们是如何实现业务流程的 原型制作 模拟一个无法直接测试的系统，便于沟通 记录用户完成任务的方式，便于了解用户习惯， 统计版本 及时改进

倾听这些相关人员的描述，并从他们的角度来理解 系统——理解需求
利用一个容易理解的模型来描述用户如何使用这个 系统以及为他们提供的价值服务——需求建模 详细地描述系统和客户、以及系统和外部系统之间 的交互——动态行为建模



重构上述详细描述以保证它易读易懂——重构模型
解决需求问题的对策
难捕获
从用户视角看问题

1. 寻找业务改进点——从业务用例模型中寻找 系统改进点； 2. 定义项目远景——结合系统远景，获取系统 用例来表达需求； 3. 导出系统需求——采用需求启发技术，从涉 众中获得


1. 寻找业务改进点

业务模型描述业务现状，这些现状可能是：

有些可能一直运转的很好，不需要改进，也就 没有必要作为软件需求来由系统实现
参与者之间的关系：泛化

参与者之间的关系可 以通过泛化来定义， 一个参与者的抽象描 述可以被一个或多个 具体的参与者所共 享——责任重叠

用例A 雇员 用例B
如系统中经理可以参加 雇员的所有用例
经理
用例C
泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
场景1：某企业要求开发一个企业信息管理 系统，并与原来已有的库存系统相连接

系统之外，重点明确新老系统间的接口

场景2：某企业要求开发一个企业信息管理 系统，并把原来已有的库存管理系统加以 改造，成为企业信息管理系统的一部分

系统之内，新系统存在一个“改造库存系统” 用例，工作量要比上述大很多
参与者的命名

如果是，则作为软件需求而存在，并把相应地模型 （用例模型）作为系统模型；

如果不是，则不作为需求而存在——可能作为一项潜 在的需求考虑、也可能直接被抛弃
实例分析：旅店系统开发远景

随着旅店声誉日益提高，住宿人员越来越多，旅客为了能 够获得好的房间，均提前预订房间 然而，随着预订的增多、预订周期的拉长，前台服务员工 作压力也日益增大，还经常出现工作的失误，使得已经预 订好房间的旅客也不能按期入住，这给酒店的声誉带来不 好的影响
2 识别参与者(Actor)

从需求中识别参与者

参与者：在系统之外，通过系统边界与系统进 行有意义交互的任何事物
要点：任何事物
任何事物举例：小人与圣小猪-1
如果我开发一个猪圈自动供食供水系统 ，猪的 前蹄触发一个开关系统就供食或供水。很显然 这里的参与者是小猪。通常，用例图中的参与 者用一个小人表示。
查询用户
删除用户

用例粒度-4——采用管理用例解 决四轮马车问题

如果确实是CRUD，怎么消除？
初次需求：我要一块石头… 再需求：差不多，但我要小一点的… 再需求：很好，不过我要蓝色的… 再需求：啊，没有那么小… 再需求：咳，还是原来那个好了…
难 捕 获 ， 易 变 ！
真实的需求：小一点的蓝色大理石
如何获取好的需求——做好需求收集

需求收集包括五个关键步骤

找到可以帮助你理解这个系统的人——领域专家

更多的业务在运转过程中存在这样或那样的问
题，这些问题就成为业务待改进的改进点，也
就很可能作为软件需求而存在——需求的重点

如：操作实现复杂、劳动效率低
2. 远景(Vision)

系统改进点不等同于软件需求，需从远景入手

用户的远景：用户根据自身的工作特点和支付能力
决定哪些应该改进，哪些不需要改进。它表明用户 改进的目标，也将成为软件项目的开发目标
5.4 编写用例文档 5.5 重构用例模型 5.6 其他问题
1.需求从何而来——获取原始需求

需求只能来自涉众(stakeholders) 、或相关利 益者、或角色等等

最终用户、客户
政府、法律、文化 开发人员、管理人员 竞争对手 … 你们的需求是什么？根据远景确定需求

但并不是直接从涉众中来
最终用户(提出问题)
开发团队(解决问题)
第5讲 用例建模
5.1 理解需求
5.2 从业务模型获取需求
5.3 建立用例模型 5.4 编写用例文档 5.5 重构用例模型 5.6 其他问题
需求——建造“正确”的系统

什么是需求？客户可接受的、系统必须满足的 条件或具备的能力——由用户提出 RUP中的FURPS + 软件质量准则

识别参与者：考勤卡系统
开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 Employee …… 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表 格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代 码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ …… 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理 Administrativ e User 总会告诉他的下属应该填写什么。 ……
多，反之则包含的功能越少。

最常犯错误：粒度过细，陷入功能分解。
用例粒度
比较下列两 图用例的粒 度，哪个粒 度大？哪个 粒度小？
用例粒度-2——常见错误

把步骤当用例
会员 输入用户名
<<include>>
会员
登录
验证用户名和密码

把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
Pig
Water supply or for food
但是这个小人具有一定的误导性，往往让初学 者(包括客户)理解为一个真实的人。
小人与圣小猪问题的解决方法

从实际应用出发来确定参与者——引入适当的 构造型进行扩展，如图中的<<pig actor>>
思考：参与者与系统边界？

“已有的库存系统”是一个 参与者

业务模型描述了“现实是什么”，远景则描述 “希望的改进” ，主要体现为：

远景表达了 “为什么要开发这个系统” ，即在业 务现状(业务模型)下，开发系统是为了达到什么目标？
3. 导出系统需求

从业务改进点入手，结合项目远景，导出系统 需求，具体措施为：

对于每一个业务改进点，明确是不是为了达到远景 目标的需要？
获取需求：考勤卡应用程序
开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都 将通过他的表格填好，然后用电子邮件发给我。这个表格相 当标准：纵向是收费项目代码，横向是日期。雇员可以在每 个条目上填写说明。 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理 总会告诉他的下属应该填写什么。 ……
参与者之间泛化关系的实例：
参与者：经理、安全主管、保安 用例：管理人事、批准预算、批
准安全证书、监视周边
实际业务：
安全主管可以担任经理和保安 的角色，也即能够参与经理和 保安参与的工作。但经理或者 保安却不能担任安全主管的角 色。系统模型如右图：
3 识别用例

关键词：提供的价值——业务功能

用例的特征：


功能性（Functionality）
可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability）
需求定义的重点
非功能性需求
Biblioteka Baidu
+，意为设计约束、实施、接口以及物理需求等
需求难在何处：石头问题




A很荣幸地成为项目经理，并被要求在两个月之内发布该系 统的第一个版本，同时还被要求要为后续的开发提供必备 的接口 结合现状和老板的要求，考虑到项目可扩展的要求，A首先 进行了简单的业务建模——了解了业务现状的工作流程 之后，A初步定义了项目的远景（项目的目标）



方便、快捷、准确地为旅客预订房间 旅客可以方便的取消预订的房间
用例
易变 建立合理的结构
以用例为中心组织业务需求
性能 界面约束
可用性 可靠性 网络协议 业务规则
用例
硬件接口
……
第5讲 用例建模
5.1 理解需求
5.2 从业务模型获取需求
5.3 建立用例模型 5.4 编写用例文档 5.5 重构用例模型 5.6 其他问题
从业务模型获取需求的方法

从业务用例模型中获取系统需求，来构建 系统用例模型。主要有3个步骤：

用例实例是系统执行的一系列动作(执行过程)， 这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景）


简介：参与者使用系统达到某个目标
记住了，我是(系统) 用例
识别用例：考勤卡系统
开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 …… Record Time 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的 表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项 目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ …… 开发者：谁来管理收费项目代码？ Create Charge Code 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经 理总会告诉他的下属应该填写什么。 ……
高级软件工程
兰州理工大学计算机与通信学院
张秋余
zhangqylz@163.com
学习路线图
2 OO
3 UML 4 5 6 9 7 OOP DP 8 10
:
:
… Case-Study …
学习路线图
11 …… …… …… ……
业务分析与设计过程
认识问题
分析问题 解决问题
以用户的身份站在用户的 角度认识问题 获取需求—用例建模技术
用例的命名

参与者（执行者）视角：

动宾结构：（状语）动词+（形容词 ）宾语
顾客
购买商品
<<extend>>
信用卡支付
要点：用例粒度-1

用例是一组用例实例的抽象。其内部要有路径， 路径要有步骤；

用例的粒度指的是用例所包含的系统服务或功能
单元的多少。

注意事项：用例的粒度越大，用例包含的功能越

对参与者赋予能表达其角色(作用)的名称

不规范的参与者命名：用职务名称和个人姓名来命 名

例如，张三、老李、校长、科长… 若使用系统的人（职务名称）变化的话，就不是参与 者了 例如，学生、订单管理员、维护部门… 即使使用系统的人改变，从系统来看，使用者的角色 （作用）是相同的。

规范的参与者命名：用能知道其角色的名称来命名

旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整 房间的价格
及时、快速地计算房间费用、预订费用、取消预订后退款金额等信 息 预留接口：可为以后的网络版，以及其它业务系统的开发提供支持


结合远景，获取系统需求(本质)
第5讲 用例建模
5.1 理解需求
5.2 从业务模型获取需求
5.3 建立用例模型
用例粒度-3——常见错误

“四轮马车”问题的避免

C(Create)、R(Read) U(Update)、D(Delete) CRUD能为Actor提供什 么价值？ CRUD会掩盖业务，锐变 成关系数据库的建模：

增加用户 修改用户


管理员
系统就是数据的增删改 查 关心数据的存储和维护， 反而忽略了用户的目的


为此，旅店老板想到了用计算机来管理——希望能够通过 计算机来自动管理这些预订业务，但由于目前资金的问题， 目前只开发一个单机版的系统，不提供网上业务；并且旅 店方面的其它业务暂不考虑信息化问题
旅店老板委托某计算机公司开发该系统，并承诺如果系统 运转良好的话，将会考虑进一步合作事宜

远景：旅店预订系统