第三讲 用例图

识别参与者
客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。 谁是系统的参与者？ 答案： 销售员
识别参与者
寻呼台系统。用户如果预定了天气预报， 系统每天定时给他发天气消息；如果当 天气温高于35度，还要提醒用户注意防 暑。 这个叙述里，谁是寻呼台系统的参与者? 用户？气温？时间？
选修课程用例
用例图图符
系统边界
用例
用例图图符
参与者
关联
用例图图符
包含
扩展
用例图图符
注释体
注释连接
用例的粒度和范围
用例的粒度用来描述用户目标大小的程度。
用例的粒度从大到小可以分成三个层次： • 概述级：商业目标 • 用户目标级：用户使用系统的目的 • 子功能级：细化的用户目标
用例的粒度和范围
答案：用户，气温，时间都是参与者
识别参与者
商品销售系统。顾客通过网络下单之后， 系统计算出总计金额，税金，运费，并 将数目传递给一个外挂的会计系统，该 系统是另外购买的。 有几个参与者？
答案： 顾客，会计系统
用例 (UseCase)
• 用例是对用户需求、用户目标的描述， 用一组序列动作来进行描述系统的功能， 系统执行这些动作将对用例的参与者产 生可以观察的结果。 • 参与者和用例分别描述了“谁来做？” 和“做什么？”这两个问题。 • 用例用实线的椭圆表示
用例描述——事件流
1、事件流wenku.baidu.com
事件流描述了一个用例在执行时参与者 与系统之间的交互过程。 其中预期会成功的路线称为基本流，剩 下其他路线称为备选流。
基本流
• 基本流是对用例中常规和预期路径的描 述。
• 执行者通过这个路径来执行用例可以得 到一个有价值的结果。
用例描述——事件流
• 例如，银行自动取款机(ATM)系统中的 “提款”用例可以用事件流表述如下：
– 参与者对系统而言总是外部的 – 参与者在系统的不同组成部分可能扮演不同 的角色
识别参与者
• 使用以下问题有助于发现系统的参与者
①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？
包含用例是可重用的用例──多个用例的公共 用例。
包含(include)
包含举例（一）：
包含(include)
包含举例（二）：
扩展(extend)
扩展指的是一个用例扩充了另一个用例的功 能，但这个扩充功能不是必需的。
将扩展用例的事件流在一定的条件下按照相 应的扩展点插入到基础用例中。
– 基础用例不必知道扩展用例的任何细节，它 仅为其提供扩展点。 – 扩展用例的行为是否被执行要取决于主事件 流中的判定点。
此时，用例之间的关系称为泛化关系。
泛化(generalization)
泛化举例（一）：
泛化(generalization)
泛化举例（二）：
包含(include)
包含是指基本用例(base use case)会用到包含 用例(inclusion)。 具体地讲，就是将包含用例的事件流插入到基 础用例的事件流中。
用例
用例的识别
• 识别用例的最好办法就是从分析系统的 参与者开始，考虑每个参与者是怎样使 用系统。 • 根据下面的一些问题来识别用例：
①参与者希望系统提供什么功能； ②系统是否存储和检索信息； ③当系统改变状态时，是否通知参与者； ④是否存在影响系统的外部事件，是哪个参 与者通知系统这些外部事件。 ⑤系统的输入和输出
•提款─基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
备选流
在用例的执行过程中，不一定都按常规 和预期的路径进行。 由于受到其他一些因素的影响，这时可 能执行了其他的路径，这种路径叫做备 选流。
备选流
•提款─备选事件流： 1.a ：如果用户插入无效信用卡，系统显示错误并 退出信用卡，用例结束。 2.a：如果用户输入错误密码，系统显示错误并提 示用户重新输入密码，重新回到基本流步 骤2；三次输入密码错误后，信用卡被系统 没收，用例结束。
子功能级
还书 读者 借书
<<include>>
身份验证
“身份验证”用例的基本事件流 1.系统验证用户名称 2.用户输入密码 3.系统检查用户的密码 4.系统给出检查结果
需求建模
• 使用UML对需求建模的优势？
1、帮助项目人员按照实际情况对系统可视化。 2、对系统的描述一目了然，方便与用户的交流 和沟通。 3、不易产生二义性，利于系统的分析和设计。
识别用例
Email客户端（如： outlook express）， A在北京发邮件给深 圳的B，系统提醒B” 你有新邮件”，B收 邮件。
识别用例
一个论坛类的应用， 用户可以提问，别人 来回答，如果有自己 问题被解答的话，就 给发问者发一份邮件 通知。 注意：发邮件这个用例 可以是单独的用例， 也可以是由回答用例 扩展出来的用例
第三讲 用例图
本节目标
• • • • 理解用例图的概念和内容。 理解需求分析与用例图之间的关系。 掌握参与者、用例、关系的概念。 能够对一个简单的系统进行需求分析,学 会通过分析需求画出用例图。
概述
• 用例图是UML的重要组成部分,主要用来 描述用户的需求。
• 用例图侧重从最终用户的角度来理解用 户的需求，强调谁在使用系统，系统可 以完成哪些功能。 • 用例分析技术是一种用户需求获取、分 析和描述技术。
• • • • • • • • • • • • • • • • • • • • • • • • •
1.简要说明 本用例描述学生选择所学课程的过程 2.事件流 1.基本流 1. 学生选择要选修的课程 2. 系统通过财务系统检查学生是否交费 3. 系统更新该学生所选课程 4. 系统显示学生所选课程 5. 学生确认所选课程 6. 系统保存学生所选课程 2.备选流 2.a 如果学生没有交费，给出提示，结束。 5.a 如果学生没有确认，给出提示，结束。 3.特殊需求。 无 4.前置条件 执行“登记”用例 5.后置条件 无 6 扩展点 无 7 相关数据 所选课程 8 问题说明 无
用例描述——前置条件
前置条件是该用例执行的前提条件，它用来描 述在什么条件下可以开始执行一个事件流。 这个条件是正确执行一个事件流的起点，一般 用执行者或系统的状态来表示。 只有当这个条件满足，执行者才能开始执行该 用例。
用例描述——后置条件
后置条件用来说明当用例结束时系统的 状态。 使用后置条件可以明确表明每个用例结 束时系统的状态，从而避免出现系统处 于不明确状态的情况。
用例
• 如何判断一个用例是否是一个优秀的用 例呢？
①用例是否描述了应该做什么，而不是如何 做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联 用例或关联参与者？
用例之间的关系
泛化关系 包含关系 扩展关系
案例描述
随着某大学招生规模的扩大，在校学生人数增 加，学校计划改善包括图书馆在内的各项教学 设施，拟开发《图书管理系统》使其可以满足 学生的要求。
需求建模
•如何描述需求？
《图书管理系统》的需求描述如下：
1．新书入库：当图书馆新进一批新书时， 图书管理员需要登记入库信息，并为每一本 新书制作一个图书卡(书目条)。 2．读者信息维护：包括两个方面的工作： 一是新读者的办证操作，二是读者基本信息 的维护工作。
• 用例图包含的内容（三要素）：
Actor（参与者、执行者、角色）
• 参与者(actor)是使用系统的人或其他系 统，可以是一个人、一个系统、甚至可 以是一个软件实体。
• 需要对参与者进行简要的描述，对其加 以解释说明。 • 参与者用下面的图标表示。
参与者（Actor)
• 参与者是系统外部的一个人或物，它以 某种方式参与了系统的执行过程。
借书登记用例描述
• 用例编号：3.1 • 用例名称：借书登记 • 用例描述：图书管理员对读者借阅的图书进行登记。读者借阅图书的 数据量不能超过规定的数量。如果读者有过期未还的图书，不能借阅 图书。 • 前置条件：读者请求借阅登记 • 后置条件：读者取得借阅的图书 • 活动步骤： • 1.读者请求借阅图书。 • 2.检查读者的状态 • 3.检查图书的状态 • 4. 标记图书为借出状态 • 5. 读者获取图书。 • 扩展点： • 2a. 如果用户借阅数量超过规定数量，或者有过期未还图书，则用 例终止。 • 3a. 如果借阅的图书不存在，则用例终止。 • 异常处理： • 无
• 3．预约借书：当读者想借阅书不在时， 可以通过预约的方式预定不在库的书籍。 • 4．借书：根据借阅者提供的书目编号， 办理借书手续。 • 5．还书：根据借阅者归还书籍的书目编 号，办理归还手续。如果还书超期，则 要扣除罚金。 • 6．图书查询：读者在借书前，通过书目 目录去查询所需书籍的书目编号。
用例之间的关系
泛化：同一业务目的的不同技术 实现。 包含：表示一个用例使用了另一 个用例的行为或功能。通过包含 用例提取公共交互，提高复用。 扩展：描述某个用例的特殊情况。 “冻结”基用例以保持稳定。
*通过关系提高用例复用
泛化(generalization)
当多个用例共同拥有一种类似的结构和行为 的时候，我们可以将它们的共性抽象成为父 用例，其他的用例作为泛化关系中的子用例。
扩展(extend)
扩展举例（一）：
扩展(extend)
扩展举例（二）：
用例之间的关系
• 包含用例与扩展用例的区别
①相对于基础用例，扩展用例是可选的，而 包含用例则不是。 ②如果缺少扩展用例，基础用例还是完整的， 而缺少包含用例，则基础用例就不完整了。
③扩展用例的执行需要满足某种条件，而包 含用例不需要。
需求
• 需求是指系统必须符合的条件或具备的 功能。 • 需求可分为功能需求和非功能需求。
需求描述
用户需求文档一般包括: • 功能需求用例图 • 功能需求用例文档 • 非功能需求文档
非功能需求文档
• • • • • • • • • • • • • • • • • • • • • • 学生选课管理系统 1.简要说明 本文档列出学生选课系统的所有非功能性需求 2.可用性 该系统提供联机帮助文件和良好的用户接口,学生不需要培训即可使用该系统 3.可靠性 该系统要求经过第三方的测试,平均每千行代码的缺陷数小于1 4. 性能 要求系统能够同时支持3000人在线使用,系统的响应时间应该小于2S 5.可支持性 无 6.设计约束 系统使用Java语言进行开发,数据库系统使用SQL Server2000 7.帮助系统需求 要求系统提供在线帮助和详细的软件使用说明书 8.购买构件需求 无 9.接口需求 此系统能够在现有的校园网上运行 10.许可需求 无 11.其他需求 无
④扩展用例的执行会改变基础用例的行为， 而包含用例不会。
用例描述
• 用例的名称应可简要说明该用例的功能。 • 用例描述的是参与者与系统之间的交互， 但是这个交互的细节并没有在用例图中 表述出来，因此需要对用例进行详细的 说明。
用例描述
对用例进行描述的6个主要属性： • 事件流 • 前置条件 • 后置条件 • 特殊要求 • 扩展点 • 问题说明
• 用例图主要用于需求分析阶段。 • 用例图描述了待开发系统的功能需求。
• 用例图从用户的角度来理解系统，不关 心系统的内部结构。 • 用例图是后继各阶段开发工作的基础。
用例图
• 用例图是显示一组用例、参与者以及它们之间 关系的图。
– 用例图从用户的角度而不是开发者的角度来描 述对软件产品的需求，分析产品所需的功能和 动态行为 – 用例图常用来对需求建模，用例图是至关重要 的，它的正确与否直接影响到客户对最终产品 的满意度 – 参与者（执行者、角色） – 用例 – 关系（泛化、扩展和包含）
• 概述级用例的范围是：整个企业。 • 用户目标级用例的范围是：系统的边界。
• 子功能级用例的范围是：一个子系统或 一个组件。
概述级用例
“阅读图书”用例的基本事件 流
读者 阅读图书
1 读者进入图书馆 2 读者借还图书 3 读者离开图书馆
用户目标级
还书 读者
借书
用户目标级“借书”用例的基本事件流 1.用户进入系统 2.用户输入要借图书的书目 3.系统找到相应的图书，进行记录，给出提示 4.用户确认所借的图书 5.系统保存借书结果，给出提示 6.用户离开系统