第3章用例和用例图.ppt
66页
第第3 3章章 用例和用例图用例和用例图 3.1 用例□ 用例(use case) Ivar Jacobson于20世纪60-70年代在爱立信公司开发AKE、AXE系列系统时发明的○ 定义1：对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列○ 定义2：用例是系统、子系统或类和外部的参与者(actor)交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列 3.1 用例□ 在UML中，用例是用一个椭圆表示，用例名往往用动宾结构或主谓结构命名(如果是英文命名，则往往是动宾结构)例3.1】 3.1 用例【例3.2】在一个银行业务系统中，可能会有以下一些用例： ·浏览账户余额 ·列出交易内容 ·划拨资金 ·支付账款 ·登录 ·退出系统 ·编辑配置文件 ·买进证券 ·卖出证券 3.1 用例□ 使用用例进行需求分析的特点： ① 从使用者的角度描述系统中的信息 站在系统外部看系统 ② 描述了用户提出的一些可见需求 对应一个具体的用户目标 ③ 对系统行为的动态描述 属于UML的动态建模部分 3.1 用例UML建模： ① 静态建模 ② 动态建模 ◇ 静态建模：类图、对象图、构件图和部署图 ◇ 动态建模：用例图、顺序图、协作图、状态图和活动图。
3.1 用例□ 理论上可以把一个软件系统的所有用例都画出来，但实际开发过程中，进行用例分析时只需把那些重要的、交互过程复杂的用例找出来□ 用例描述的是系统的功能性需求 3.1 用例□ 用例的需求大纲 ·系统的目的和范围 ·系统中的术语表 ·用例 ·系统采用的技术 ·开发过程中的参加人员、业务规则、系统运行所依赖的条件、安全要求、文档要求等各种其它需求 ·法律、政治、组织机构等方面的问题 3.1 用例□ 用例这种技术很容易使用，但也很容易误用正确使用用例分析来做好领域建模（domain modeling），以确保定义正确的需求（right requirements），然后开发出正确的系统（right system），是保证OO软件开发成功的基础对于初学者来说，掌握用例的概念并不难，但要在具体的项目中灵活地使用用例来捕获用户的需求，并不是一件容易的事情，往往需要用户的经验、沟通能力、丰富的领域知识等 3.1 用例□ 本质上，用例分析是一种功能分解（functional decomposition）的技术，并未使用到面向对象思想。
因而有人认为用例分析只是面向对象分析与设计（Object-Oriented Analysis/Object-Oriented Design，OOA/OOD）的先导性工作，并非OOA/OOD过程的一部分，但也有人视其为OOA/OOD的一环 3.1 用例□ 用例是与实现无关（implementation independent）的关于系统功能的描述在UML中，可以用协作（collaboration）来说明对用例的实现 图3.3 用例及其实现 3.1 用例□ 在UML中，协作用虚线椭圆表示在图3.3中，对用例Login共有两个实现，一个是简单的实现，另一个是带有安全验证功能的实现，这里没有显示协作的内容结构和行为方面的内容协作的内部由两部分组成：一是结构部分，如类、接口及其他一些建模元素等；另一部分是说明类、接口以及其他建模元素如何协同工作的行为部分，如协作图（collaboration diagram）、顺序图（sequence diagram）、类图（class diagram）等 3.2 参与者□ 参与者（actor）是指系统以外的，需要使用系统或与系统交互的东西，包括人、设备、外部系统等。
3.2 参与者【例3.3】在一个银行业务系统中，可能会有以下参与者：·客户：从系统获取信息并执行金融交易·管理人员：开办系统的用户获取并更新信息·厂商：接受作为转帐支付结果的资金·mail系统 3.2 参与者□ 参与者的3种表示形式 3.2 参与者□ 参与者之间可以存在泛化关系 3.3 脚本□ 脚本（scenario）也被翻译为情景、场景、情节、剧本等在UML中，脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊情况□ 脚本是用例的实例（instance），如果与类和对象之间的关系作比较，则脚本与用例的关系相当于对象与类的关系 3.3 脚本【例3.4】：在“订货”这个用例中，包含着几个相关的脚本 一个是订货进行顺利的脚本；一个是相关货源不足的脚本；一个是涉及购物者的信用卡被拒的脚本，等等这些脚本的组合构成了一个用例□ 一个脚本使用具体的文字描述来表示 3.4 用例间的关系□ 用例之间的关系包括： ① 泛化关系(generalization) ② 包含关系(include) ③ 扩展关系(extend) 3.4.1 泛化关系□ 泛化（generalization）代表一般与特殊的关系。
■ 在泛化关系中，子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或父用例中的行为和含义 3.4.2 包含关系□包含（include）关系指的是两个用例之间的关系，其中一个用例（称作基本用例，base use case）的行为包含了另一个用例（称作包含用例，inclusion case）的行为 3.4.3 扩展关系□ 扩展（extend）关系的基本含义与泛化关系类似但在扩展关系中，对于扩展用例（extension use case）有更多的规则限制，◇ 即基本用例必须声明若干“扩展点”（extension point），而扩展用例只能在这些扩展点上增加新的行为和含义 3.4.3 扩展关系□ 包含用例和扩展用例 3.4.4 用例的泛化、包含、扩展关系□ 泛化关系和扩展关系 表示的是用例之间的“is a”关系 泛化关系 扩展关系 比泛化关系多了扩展点□ 包含关系 表示的是用例之间的“has a”关系 3.4.4 用例的泛化、包含、扩展关系□ 在扩展关系中，基本用例一定是一个well formed的用例，即是可以独立存在的用例一个基本用例执行时，可以执行，也可以不执行扩展部分。
□ 在包含关系中，基本用例可能是、也可能不是well formed在执行基本用例时，一定会执行包含用例（inclusion use case）部分 □ 使用条件① 如果需要重复处理两个或多个用例时，可以考虑使用包含关系，实现一个基本用例对另一个用例的引用② 当处理正常行为的变型而且只是偶尔描述时，可以考虑只用泛化关系③ 当描述正常行为的变型而且希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系 参与者、用例间的关系类型□ 下表是参与者、用例之间关系（relationship）的总结 3.4 用例间的关系□ 关系 模型元素之间的语义联系□ 关联 两个或多个类元之间的关系 描述了类元的实例之间的联系□ 泛化关系 两个类元之间的关系 特殊和一般的关系□ 依赖关系 两个元素或元素集之间的一种关系 目标元素: 被依赖的元素 改变 源 元素: 依赖元素 相应的改变 3.5 用例图□ 用例图：是显示一组用例、参与者以及他们之间关系的图在UML中，一个用例模型由若干个用例图描述。
3.5 用例图 3.6 用例的描述□ UML初学者 缺少用例的描述或用例的描述不完整□ 用例是一个“文字描述序列”□ 用例是“动作序列的说明”□ 用例的描述才是用例的主要部分 是后续的交互图分析和类图分析必不可少的部分 3.6 用例的描述□ 用例的描述应该包含哪些内容，并没有一个统一的标准，不同的开发机构可能会有不同的要求，但一般应包括以下内容： ① 用例的目标 ② 用例是怎么启动的 ③ 参与者和用例之间的消息是如何传送的 ④ 用例中除了主路径外，其他路径是什么 ⑤ 用例结束后的系统状态 ⑥ 其他需要描述的内容 3.6 用例的描述 □ 描述用例的原则是尽可能写得“充分”，而不是追求写得形式化、完整或漂亮 □ 作为OOA文档的一个组成部分，用例的描述应该有一定的规范格式，但目前并没有一个统一的标准在统一的标准出现之前，人们可以采纳适合于自己的用例描述格式，但不管怎样，在一个开发机构内部应该采用统一的格式 3.6 用例的描述描述项说明用例名称表明用户的意图或用例的用途，如“划拨资金”标识符[可选]唯一标识符，如“UC1701”，在文档的别处可以用标识符来引用这个用例用例描述概述用例的几句话参与者与此用例相关的参与者列表优先级一个有序的排列，1代表优先级最高状态[可选]用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查 3.6 用例的描述前置条件一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足后置条件一个条件列表，如果其中包含条件，则这些条件将在用例完成以后得到满足基本操作流程描述用例中各项工作都正常进行时用例的工作方式可选操作流程描述变更工作方式、出现异常或发生错误的情况下所遵循的路径被泛化的用例此用例所泛化的用例列表被包含的用例此用例所包含的用例列表被扩展的用例此用例所扩展的用例列表 3.6 用例的描述修改历史记录[可选]关于用例的修改时间、修改原因和修改人的详细信息问题[可选]与此用例的开发相关的问题列表决策[可选]关键决策的列表，将这些决策记录下来以便维护时使用频率[可选]参与者访问此用例的频率，如用户是每日访问一次还是每月访问一次 3.6 用例的描述□ 表3.3 是对“处理订单”这个用例的描述。
具体内容见书P31. 3.6 用例的描述□ UML初学者易犯的错误·只描述系统的行为，没有描述参与者的行为·只描述参与者的行为，没有描述系统的行为·在用例描述中就设定对用户界面的设计的要求·描述过于冗长 3.6 用例的描述 A．Cockburn在[Coc00]中给出了很多错误的用例描述的例子下面给出几个典型的例子为了说明问题，在给出描述时并没有完全按照表3.2中用例描述模板的格式，只给出了操作流程的描述 3.6 用例的描述【例3.5】下面是一个用例描述的片断：Use Case：Withdraw Cash参与者：Customer主事件流：⑴ 储户插入ATM卡，并键入密码⑵ 储户按Withdraw按钮，并键入取款数目⑶ 储户取走现金，ATM卡并拿走收据⑷ 储户离开 3.6 用例的描述【例3.6】下面是一个用例描述的片断：Use Case：Withdraw Cash参与者：Customer主事件流：(1) ATM系统获得ATM卡和密码2) 设置事务类型为Withdrawal3) ATM系统获取要提取的现金数目4) 验证账户上是否有足够储蓄金额5) 输出现金、数据和ATM卡6) 系统复位。
正确的用例描述主事件流：(1) 通过读卡机，储户插入ATM卡2) ATM系统从卡上读取银行ID、账号、加密密码、并用主银行密码验证银行ID和账号3) 储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证4) 储户按FASTCASH按钮，并键入取款数量，取款数量应该是5美元的倍数5) ATM系统通知主银行系统，传递储户账号和取款数量，并接收返回的确认信息和储户账户余额6) ATM系统输出现金、ATM卡和显示账户余额的收据7) ATM系统记录事务到日志文件 3.6 用例的描述【例3.7】下面是一个用例描述的片断：Use Case：Buy Something参与者：Customer主事件流：(1) 系统显示ID and Password窗口2) 顾客键入ID和密码，然后按OK按钮3) 系统验证顾客ID和密码，并显示Personal Information窗口 3.6 用例的描述(4) 顾客键入姓名、街道地址、城市、邮政编码、号码，然后按OK按钮5) 系统验证用户是否为老顾客6) 系统显示可以卖的商品列表7) 顾客在准备购买的商品图片上单击，并在图片旁边输入要购买的数量选购商品完毕后按Done按钮。
8) 系统通知库存系统验证要购买的商品是否有足够的库存．．．．．．（后续描述省略） 3.6 用例的描述□ 上述描述中存在的问题是对用户界面的描述过于详细对于需求文档来说，详细地用户描述对捕获需求并无帮助改进的描述如下所示：Use Case：Buy Something参与者：Customer主事件流： 3.6 用例的描述(1) 顾客使用ID和密码进入系统2) 系统验证顾客身份3) 顾客提供姓名、地址、号码4) 系统验证顾客是否为老顾客5) 顾客选择要购买的商品和数量6) 系统通过库存系统验证要购买的商品是否具有足够库存．．．．．．（后续描述省略） 3.6 用例的描述【例3.8】下面是一个用例描述的片断：Use Case：Buy Something参与者：Customer主事件流：(1) 顾客使用ID和密码进入系统2) 系统验证顾客身份3) 顾客提供姓名4) 顾客提供地址 3.6 用例的描述(5) 顾客提供号码6) 顾客选取商品7) 顾客确定商品的数量8) 系统验证顾客是否为老顾客9) 系统打开到库存系统的连接10) 系统通过库存系统请求当前库存量11) 库存系统返回当前库存量12) 系统验证购买商品的数量是否少于库存量。
．．．．．．（后续描述省略） 3.6 用例的描述□ 上述描述中存在的问题是对于用例的描述过于冗长可以采用更为简洁的描述方式如合并类似的数据项（步骤（3）至步骤（5）），提供抽象的高层描述（步骤（9）至步骤（12））等改进的描述可以如下所示：Use Case：Buy Something参与者：Customer主事件流： 3.6 用例的描述(1) 顾客使用ID和密码进入系统2) 系统验证顾客身份3) 顾客提供个人信息（包括姓名、地址、号码），选择要购买的商品及数量4) 系统验证顾客是否为老顾客5) 系统使用库存系统验证要购买的商品数量是否少于库存量．．．．．．（后续描述省略） 3.7 寻找用例的方法□ 用例分析的步骤可以按下面的顺序进行：(1) 找出系统外部的参与者和外部系统，确定系统的边界和范围2) 确定每一个参与者所期望的系统行为3) 把这些系统行为命名为用例4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 3.7 寻找用例的方法(5) 编制每一个用例的脚本6) 绘制用例图7) 区分主事件流和异常情况的事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理8) 细化用例图，解决用例间的重复与冲突问题。
◇ 当然上述这个顺序并不是固定的，可以根据需要进行一些调整 3.7 寻找用例的方法□ 采用用例分析法捕获用户的需求，其中一个比较困难的工作是确定系统应该包含哪些用例，以及如何有效地发现这些用例事实上，在做用例分析时，并没有一个固定的方式或方法来发现用例，而且对于同一个系统，往往会有很多种解决方案，但其中某些方案会比另一些方案好 3.7 寻找用例的方法□ 与设计和实现阶段相比，需求分析阶段更多的还是依赖于分析人员的个人经验和领域知识例如，如果某分析人员以前做过类似的系统分析和开发工作，那么以后再做类似的工作时就比较容易，但如果是针对一个全新的领域，往往会觉得很难入手，这时就需要领域专家的帮助 3.7 寻找用例的方法□ 下面的这些启发性原则可以帮助分析人员发现用例：·和用户交互·把自己当作参与者·确定用例和确定参与者不能截然分开 3.7 寻找用例的方法□ Jacobson作为用例方法的提出者，也提出了一些原则来帮助发现用例，如通过回答下列问题来帮助发现用例：① 参与者的主要任务是什么？② 参与者需要了解系统的什么信息？需要修改系统的什么信息？③ 参与者是否需要把系统外部的变化通知系统？④ 参与者是否希望系统把异常情况的变化通知自己？ 3.8 常见问题分析(1) 用例的粒度问题。
对于一个系统来说，不同的人进行用例分析后得到的用例数目有多有少如果用例粒度（granularity）很大，那么得到的用例数就会很少，如果用例粒度很小，那么得到的用例数就会很多那么用例数目多少比较合适？ 答：这是很多人争论的问题例如：Ivar Jacobson认为，对于一个10人年的项目，他需要大约20个用例，而在一个相同规模的项目中，Martin Fowler则用了100多个用例Martin Fowler是流行的UML入门书“UML distilled”的作者之一[FS99]，该书在UML领域的影响很大 3.8 常见问题分析(2) 在一个系统中，有几个相似的功能，那么是将他们放在同一个用例中，还是分成几个用例？假设有这样的需求，在学生档案管理中，管理员经常需要做3件事：增加一条学生记录、修改一条学生记录、删除一条学生记录如果要画出用例图，则以下两种方法哪种更合适？ 3.8 常见问题分析方法方法1：：用例图如图3.10所示，并分成3个脚本，分别画3个交互图脚本1为增加学生记录，脚本2为修改学生记录，脚本3为删除学生记录 3.8 常见问题分析方法方法2：：用例图如图3.11所示，以后每个用例画一个交互图。
3.8 常见问题分析(3) 三层结构如何采用用例表示？答：这也是一个非常典型的问题一般初学者在进行用例分析时，往往很容易会考虑到实现的问题事实上，用例是用来描述系统需求的，一般不在用例分析阶段考虑系统的实现问题如果需要描述系统的三层结构，则在类图、部署图等中表示 3.8 常见问题分析(4) 如图3.12所示的用例图和如图3.13所示的用例图有何区别，在表示用例的包含关系方面是否正确？ 图3.12 用例图1图3.13 用例图2 3.8 常见问题分析答：用例间的包含关系是依赖关系的版型，因此图3.12是正确的表示方法对于图3.13，C和D之间存在泛化关系，而<
4．系统需求一般分为功能性需求和非功能性需求两部分，用例只涉及功能性方面的需求 3.9 小结5．用例之间可以有泛化关系、包含关系、扩展关系等6．脚本是用例的实例7．参与者是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等8．参与者之间可以有泛化关系 3.9 小结9．用例的描述是用例的主要部分10．用例的描述格式没有一个统一的标准，不同的开发机构可以采用自认为合适的格式11．用例分析结构的好坏与分析人员的个人经验和领域知识有很大的关系。
