UML建模语言及工具

第 4 章用例建模 Use-Case Modeling

Review: A Practice of Visual Modeling with UML

学习线路图 OO UML OOA OOD DP … Case-Study … …… …… …… …… 学 习 线 路 图

UML 摆脱符号烦恼 1. 用UML画图很容易 但知道要画什么是困难的！ 全心面对问题 2. UML仅仅是一种表达形式 用好UML首先需要掌握OOAD的基本原则和方法，并在一定的软件开发过程（如统一过程UP/USDP/RUP、XP等）的指导下进行有取舍的运用

认识问题 分析问题 解决问题 以开发者的身份站在开发团队的角度分析问题 解决需求—面向对象设计 以用户的身份站在用户的角度认识问题 获取需求—用例建模技术 以开发者的身份站在用户的角度分析问题 分析需求—用例分析技术 最终用户(提出问题) 开发团队(解决问题)

内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程

需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 非功能性需求 功能性：详细描述了系统必须有能力执行的动作，通过详细说明所期望的输入和输出条件来描述系统行为 非功能性： 使用性：人为因素（审美学、易学性、易用性）和用户界面、用户文档、培训资料的一致性 可靠性：失败的频率和失败严重性、可恢复性、可预测性和准确性 性能：在功能性需求上施加的条件，如需求详述了交换率、速度、有效性、准确性、响应时间、恢复时间和内存使用，同时还加上了必须执行某个活动的条件 可支持性：易测性、可维护性和其它在系统发布以后维持系统更新需要的质量。

内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程

需求：石头问题 小一点的蓝色大理石 我要一块石头… 差不多，但我要小一点的… 难捕获，易变！ 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 难捕获，易变！ 小一点的蓝色大理石

需求：如此脆弱 验 收 客户/用户的要求/想法/期望 软件产品 分析和设计 编码和测试 没价值的 软件需求 软件设计 补文档

需求：也需要开发 客户/用户的要求/想法/期望 软件产品 开发 验收 编码和测试 有价值的 软件需求 软件设计 分析和设计

获取好的需求 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 需求价值

内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程

需求问题：对策 难捕获 从用户视角看问题 用例 易变 合理的结构

以用例为中心组织需求 性能 可用性 界面约束 可靠性 用例 硬件接口 网络协议 …… 业务规则

内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程

基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 3 详细、完整地描述需求 4 重构用例模型 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包

基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 3. 详细、完整地描述需求 4. 重构用例模型 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包

获取需求的技巧（MSF） 技巧 描述 实地观察 直接观察个人工作的情况，以发现现存的实践方式和问题 访谈 从个人处收集特定信息 特定群体调查 对一组人员进行调查，以便了解工作态度和共同看法 问卷调查 收集详细数据和统计意义上比较重要的数据 用户指导 让最终用户告诉你，他们是如何操作系统的 原型制作 模拟一个无法直接测试的系统 统计版本 使用具有统计功能的应用程序来记录用户完成任务的方式

获取需求：考勤卡应用程序 初次访谈记录 开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 …… 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ …… 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ……

基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 3. 详细、完整地描述需求 4. 重构用例模型 2.1 识别参与者 2.2 识别用例 2.3 构建用例图：确定参与者和用例之间的关系 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包

2.1 识别参与者 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物

参与者要点 系统外 系统边界 有意义的交互 任何事物 参与者代表在系统边界之外的真实事物，并不是系统的成分 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 任何事物 人、外系统、外部因素、时间 系统边界问题：业务建模 定义业务活动，识别相关的业务参与者 有意义的系统交互：图书馆、读者（感兴趣的，用户所关心的，要解决的）， 如系统的打印功能，与打印机的交互，这些交互已经被别人解决了，我们并不需要考虑细节 是责任边界，非物理边界

题外话：小人与圣小猪(1)

小人与圣小猪(2) 众所周知，use case 图里的actor 用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的Actor 是小猪。那么在use case 图里用小猪代替原来的小人不是更易于交流吗？ 1、actor 是pig actor 的泛化(generalization) 2、此观点得到来自于Rational Rose 的官方支持，因为Rose 完全赋予了用户画出这种use case 图的能力。 3、Rational 只是默许用户这样做，但目前还没有迹象表明他们鼓励用户这样做。我们或 许可以期待在将来的UML 版本中，以明确的方式规定actor 完全应该按照实际情况画成 小猪。 1、准备好四副猪的图片放到 ~rose/stereotypes/下的四个目录中 color: 24bit 色wmf 格式任意大小，用棕色填充空白部份 list:16 或256 色bmp 格式16x16 点 medium：256 色bmp 格式24x24 点 normal：24bit 色wmf 格式任意大小 small：256 色bmp 格式16x15 2、打开~rose/defaultstereotypes.ini 在[Stereotyped Items]节加上行： Class:pig actor 在文件末尾加上： [Class:pig actor] Item=Class Stereotype=pig actor Metafile=&\stereotypes\normal\pig.wmf SmallPaletteImages=&\stereotypes\small\pig.bmp SmallPaletteIndex=1 MediumPaletteImages=&\stereotypes\medium\pig.bmp MediumPaletteIndex=1 ListImages=&\stereotypes\list\pig.bmp ListIndex=1 ToolTip=Creates a pig actor\npig actor 启动rose，在use case 图中加入一个actor，然后将其stereotype 设成pig actor

思考：参与者与系统边界？ 某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分

在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？ 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？ 时间 气温不是，仅是一个条件

识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 ……

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

参与者地位 识别用例之前—重要 开始书写用例文档以后—不重要 测试和部署阶段—重要 有助于识别用例，宁多勿少 涉及的参与者太多 需要从参与者的角度考虑

参与者的泛化：责任重叠 Generalization – A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B 如系统中经理可以参加雇员的所有用例

泛化关系的误用 专业实践二级：荣瑞公司网站

2.2 识别用例 关键词：价值 定义 简洁：参与者使用系统达到目标 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 简洁：参与者使用系统达到目标

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

用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度

要点：用例止于系统边界 描述交互，而不是内在的系统活动

要点：有意义的目标 系统的存在是因为：参与者有一些需要使用它来满足的目标

要点：结果值由系统生成 系统需要处理的，由系统生成 用户可以看见的，是由系统生成的

要点：业务语言而非技术语言 用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C++等

要点：用户观点而非系统观点 用户观点 系统观点

用例 VS. 功能 呼叫某人 接听电话 发送短信 记住电话号码 …… 传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理 …… 用户观点 系统观点

用例的命名 执行者视角： （状语）动词+（定语+ ）宾语

要点：用例粒度-1 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言

用例粒度-2 把步骤当用例 把系统活动当用例

用例粒度-3 “四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的

用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示

用例粒度-5 灵活处理CRUD 可以把包含复杂交互的路径独立出去形成用例

思考：识别用例-1 Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件 用例是一个完整的交互，用例之间没有顺序的关系

思考：识别用例-2

2.3 构建用例图

定义系统：POST 销售点终端（Point-Of-Sale Terminal，POST）系统 是一个计算机自动化系统 用来记录商品销售信息 处理客户的支付信息 客户可以使用现金、信用卡、支票等多种支付手段 主要用于零售的百货商店 包括计算机和条形码扫描仪等硬件设备和系统运行软件 ……

识别参与者 谁使用系统的主要功能 出纳员Cashier 谁改变系统的数据出纳员Cashier 谁从系统获取信息出纳员Cashier，顾客Customer，系统管理员SystemAdmin 谁需要系统的支持以完成日常工作任务出纳员Cashier，系统管理员SystemAdmin 谁负责日常维护、管理并保证系统正常运行系统管理员SystemAdministrator 系统需要应付（处理）那些硬设备无 系统需要和那些外部系统交互可与库存系统Inventory、信用卡系统CardProcessingCompany、支票处理系统CheckProcessingCompany等交互 谁（或什么）对系统运行产生的结果（值）感兴趣出纳员Cashier，顾客Customer

候选参与者

识别用例：POST

基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 3 详细、完整地描述需求 4 重构用例模型 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包

进行用例阐述：写用例规约 用例规约：更进一步的精度 用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值 用例图是骨架，而用例规约则是其内在的肉

谁来写用例文档 最完美：业务人员接受训练，写出优美的用例文档 最现实：业务人员提供素材，开发人员写用例文档 最糟糕：业务人员不管，完全由开发人员杜撰

用例规约组成 用例名称 用例标识 涉及的参与者 描述 用例的规格说明 其它 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题

前置、后置条件-1 前置条件约束在用例开始前系统的状态 后置条件约束用例执行后系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件

前置、后置条件-2 某些用例依赖于其他用例 有助于识别漏掉的用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）

用例交互四部曲-事件流 系 统 1. 动 作 2.改变 3.验证 4. 回 应 写：可观测的、体现客户利益的文字

事件流描述要点 1.只书写“可观测”的（说人话） 2.使用主动语句 3.句子必须以参与者或系统作为主语 4.不要涉及界面细节 5.分支和循环

要点1：只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息

要点2：主动语句 欧文从贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 出纳员…… 系统……

要点3：以参与者或系统作主语 参与者…… 系统…… 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据

要点4：不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮

要点5：分支和循环 分支：放到扩展路径 参与者的选择 另一条成功线路 系统进行验证 …… 循环：直接描述

用例规约：记录时间 UC01：“Record Time”用例文档 用例名称：Record Time（记录时间） 用例标识：UC01 涉及的参与者：雇员、系统管理员 描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记时间 前置条件：用户必须已经登录到这个系统 后置条件：系统将雇员的工时正确的记录到数据库中

用例规约：记录时间(续) 正常事件流： 雇员查看当前时间之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流1：雇员更改他的时间 雇员选择一个已有的条目； 雇员改变工时； 在视图中更新这个信息，并在以后的视图中都可以看到。

用例规约：记录时间(续) 非功能需求：无 设计约束：无 部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙 未解决的问题 雇员是否可以在以前的考勤卡上输入和更改时间 雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？

活动图-简述用例流程

活动图Activity Diagram 通过动作来组织，主要用于描述某一方法、机制或用例的内部行为 活动（Activities）, which are steps in the workflow. 动作（Actions）, which are steps within an activity. Actions may occur when entering the activity, exiting the activity, while inside the activity, or upon a specific event. 转移（Transitions）、决策点（Decision points）、同步条（Synchronizations） 业务对象（Business objects） 起始状态（The start state）、终止状态（The end state）

活动图-推荐的使用场合 分析用例：能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系。一张完整的活动图是所有用例的集成图 理解牵涉多个用例的工作流：在难于区分不同用例而对整个系统的工作过程又十分清楚时，可以先构造活动图

基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 3 详细、完整地描述需求 4 重构用例模型 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包

4.1 用例关系 Extend Include Generalization <<extend>>

通过关系整理文档 Extend Include Generalization 分离扩展路径 提取公共步骤，便于复用 同一业务目的的不同技术实现

扩展关系 基用例路径本身是完整的，可能是一条扩展路径 扩展路径步骤多 扩展路径内部还有扩展点－扩展之扩展 扩展路径未定或容易变化－分离以“冻结”基用例

扩展关系误用

识别扩展点思路 执行者的选择 系统验证 步骤失败 ……

包含关系 某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化（慎用）

包含关系误用

泛化关系 同一业务目的不同技术实现： 一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例） UML 1.5: 用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系

重构后的用例图：POST 是include还是extend

重构后的用例图：考勤卡系统 是include还是extend

4.2为什么要对用例进行分类 用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例 开发周期 开发周期 开发周期 用例B 用例A -简化版本 用例A -完整版本 用例C

用例分类原则 用例分类的一个基本原则 提高用例级别的特性： 高级别的用例是那些对系统核心体系结构影响最大的用例 a. 对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例

用例分类实施策略(1) 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级

用例分类实施策略(2) 依照上述的影响用例级别的特性给用例打分（用例也可能带有权值

用例的组织 对用例进行分包 常见的分包方式 可以先按主题分包，主题内再按开发团队和发布情况分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 可以先按主题分包，主题内再按开发团队和发布情况分包

补充需求规约 Supplementary Specification 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 词汇表Glossary 描述数据

题外话：何时适用用例建模 用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然它们不是非常有效的 用例捕获功能需求，因此它们对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时，用例是一个糟糕的选择： 系统有非功能需求所主导（如：google） 系统具有很少的用户 系统具有很少的接口（非内部功能） 如：嵌入式系统、算法复杂但接口少的系统等

下一步？ 需求 用例 面向对象 分析设计 结构化 分析设计 其它方法 自己的 土方法 系统