第3章用例和用例图
第3章用例及用例图-案例精品PPT课件
● ② 确定各参与者所期望的系统行为。
管理员： 增加课程 修改课程 删除课程
学生： 查询课程 选择课程 网上付费
10
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
11
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
12
● ⑤ 绘制用例图。
5
案例1： • 用例图
6
案例1： • 优化
7
案例2：
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统，建立本学 期要开设的各种课程，将课程信息保存到系统中， 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统，选择课程：可 以查询课程，选择课程，支付课程费用。
8
● ① 找出系统外部参与者，确定系统边界和范围。
You Know, The More Powerful You Will Be
谢谢大家
荣幸这一路，与你同行
It'S An Honor To Walk With You All The Way
演讲人：XXXXXX 时 间：XX年XX月XX日
2
3.7 业务用例图
• 业务角色（Business Actor）
– 机构（组织）外部参与者
• 业务工人（Business Worker）
– 机构内部参与者所起作用的表示
• 业务用例（Business Use Case）
– 业务功能（无论是手工还是自动处理）
• 业务机构（Business Organization）
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
UML概述
UML建模基础——UML概述东软人才实训中心3 Sept. 2008©Neusoft Confidential课程结构1第五章：状态图和活动图2第三章：类图1第四章：交互图1第二章：用例图1第一章：UML 概述、Rose 简介课时（H ）内容培训目标•能够使用Rose工具画UML类图•能够看懂用UML表示的设计第一章：UML 概述、Rose 简介学时：1学时教学方法：讲授ppt ＋上机练习目标:本章旨在向学员简要介绍UML建模的重要性、UML的概念模型,通过本课的学习，学员应该掌握如下知识：1）了解UML的概念模型2）简要介绍UML的“4+1view ”3）了解Rose工具UML概述•什么是UML?–UML: 统一建模语言Unified Modeling Language–UML是由Rational公司三位世界级面向对象技术专家Grady Booch，Ivar Jacobson和Jim Rumbaugh提出的。
–UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。
•什么是UML?–不是一种可视化编程语言，而是一种可视化建模语言–不是工具或知识库的规格说明，而是建模语言的规格说明，是一种表示的标准–不是过程，也不是方法，但是允许任何一种过程和方法使用它•什么是模型?–模型就是真实世界的简化–为我们提供一个系统的原型•为什么要建模?–为了更好的理解我们将要或正在开发的系统–是把复杂的系统变成小的系统，采用“各个击破”的原则逐一解决–因为我们通常无法理解一个复杂系统的全部–模型能为我们做什么?•帮助我们对系统进行可视化•允许我们详细说明系统的结构或行为•给出一个指导我们构造系统的模板•对我们做出的决策进行文档化业务流程计算机系统可视化建模可视化建模就是用标准的图形表示法来建模“建模获取系统的关键部分”UML•什么是可视化建模?可视化建模的作用•可视化建模获取业务流程–用例（use case）分析是一种从用户的角度获取业务流程的技术–使用相同的语言，不至于产生歧义–用例分析能让分析师在构建系统之前理解要构建什么可视化建模的作用(续)•可视化建模是一个交流工具–使用相同的语言，不至于产生歧义业务领域计算机领域Logical ViewPhysical View User InterfaceBusiness Logic Database Java JSPC++ JavaSQL•管理复杂性–把3000多个类放在一张图中不好–可视化建模的“包”（package）•把元素模型化成有意义的组合•为不同的人提供不同级别的抽象–软件构架(architecture)•促进复用(reuse)–复用是软件的“圣杯”–不止是复用代码，而是复用建立原始工件时需要的所有分析、设计、实现、测试、文档化–可以有一个类复用、多个类（或一个组件）的复用、应用模式等复用方式–可视化建模让你从复用的角度看，如果想复用工件，什么是可用的UML的概念模型•UML的概念模型–UML建模的三个主要元素•构造块：事物、关系、图•规则：命名、范围、可见性、完整性、执行•公共机制：规范说明、通用划分、扩展机制•UML元素–构造块–事物•对模型中最具有代表性的成分的抽象–关系•把事物结合在一起–图•聚集了相关的事物•UML元素–构造块–事物–结构事物：通常是UML模型的静态部分，描述概念或物理元素•类•接口•用例：通常代表一个需求•协作：表示一个用例的实现•主动类：至少拥有一个进程或线程的类•组件：系统中物理的、可替代的部件，如源代码文件•节点：运行时存在的物理元素，如一个设备•UML元素–构造块–事物（续）–行为事物：是UML模型的动态部分，是模型中的动词•交互（interaction）：可描述一个对象群体的行为或单个操作的行为•状态机（state machine）：可描述单个类或一组类之间协作的行为–分组事物：是UML中的组织部分•包（package）–注释事物：是UML中的注释部分•注解（note）•UML元素–构造块–关系–关系•依赖（dependency）：一个事物发生变化会影响到另一个事物。
用例和用例图ppt课件
精选课件
6
参与者间的关系
▪ 在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
▪ 示例：
父参与者
子参与者
子参与者
▪ 子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
▪ 子参与者可以出现在父参
与者能出现的任何位置上
精选课件
7
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
使用扩展关系 ▪ 扩展用例总是在一个或多个扩展点处来扩展基本用例，或
处于特定条件下， 才扩展基本用例。
基本用例
扩展点 扩展点名称
<<extend>>
扩展用例
精选课件
21
扩展关系
使用情形
a.两个用例相似但不完全相同时 b.当要对多个额外情况逐一建模时，使用扩展关
系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始，考虑每个参与者是如何使用系统的。
➢ 参与者要向系统请求什么功能？
➢ 每个参与者的特定任务是什么？
➢ 参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
➢ 是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
会变得十分复杂，应该考虑使用扩展关系
精选课件
22
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]
管理任务
第03章 用例和用例图
5
用例的特点 ① 用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的实现 方式。
储蓄系统
开户 存款
√
√ √ √
取款
转帐
6
用例的特点
② 用例描述用户提出的一些可见需求，对应 一个具体的用户目标。
储蓄系统 √ √ √ 开户 存款 取款 转帐
√
×
数据上传
7
用例的特点 ③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
泛化关系代表一般与特殊的关系, 与继承类似.
在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
20
3.4.2 泛化关系
21
3.4.3 包含关系
包含关系是指一个用例(基本用例)的行为包含了另一 个用例(包含用例)的行为.
包含关系是依赖关系的版型, 但其含义更多.
3.6 用例的描述
用例阐述：写用例规约
用例规约：更进一步的精度
用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值
用例图是骨架，而用例规约则是其内在的血肉
43
3.6 用例的描述
谁来写用例文档 ?
最完美：业务人员接受训练，写出优美的 用例文档 最现实：业务人员提供素材，开发人员写 用例文档 最糟糕：业务人员不管，完全由开发人员 杜撰
3
3.7 寻找用例的方法
3.8 用例的常见问题
15
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本.
UML之用例图
UML之⽤例图⽤例图⽤例图是⽤来描述系统功能的技术，表⽰⼀个系统中⽤例与参与者及其关系的图，主要⽤于需求分析阶段。
⽤例图的基本组成元素：参与者、⽤例、元素之间的关系。
⽤例图使⽤范围：需求分析1.捕获需求。
描述功能需求、⾏为需求（系统要完成什么任务）2.分析需求。
明确类和对象，建⽴之间的关系⽤例图的基本概念1、⽤例图是表⽰⼀个系统中⽤例与参与者关系之间的图。
它描述了系统中相关的⽤户和系统对不同⽤户提供的功能和服务。
2、⽤例图相当于从⽤户的视⾓来描述和建模整个系统，分析系统的功能与⾏为。
3、⽤例图中的主要元素包括参与者、⽤例以及元素之间的关系。
此外，⽤例图还可以包括注解和约束，也可以使⽤包将图中的元素组合成模块。
如：参与者的概念1、参与者是与系统主体交互的外部实体的类元，描述了⼀个或⼀组与系统产⽣交互的外部⽤户或外部事物。
2、参与者位于系统边界之外，⽽不是系统的⼀部分。
3、参与者是从现实世界中抽象出来的⼀种形式，却不⼀定确切对应的现实中的某个特定对象。
符号：如何确定参与者？通过对参与者进⾏关注和分析，我们可以把重点放在如何与系统交互这⼀问题上，便于进⼀步确定系统的边界。
另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下⼏个⾓度来考虑：1）为系统提供输⼊的⼈或事物2）接收系统输出的⼈或事物3）需要接⼊的第三⽅系统或设备4）时间是否会触发某些事件5）负责⽀持或维护系统中信息的⼈系统中的参与者⼀般可以分为四类：主要业务参与者：主要从⽤例的执⾏中获得好处的关联⼈员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联⼈员。
外部服务参与者：响应来⾃⽤例的请求的关联⼈员。
外部接收参与者：从⽤例中接收某些价值或输出的⾮主要的关联⼈员。
参与者的泛化关系当系统中的⼏个参与者既扮演⾃⾝的⾓⾊，同时也有更⼀般化的⾓⾊时，可以通过建⽴泛化关系来进⾏描述。
与类相似，⽗参与者可以是抽象的，即不能创建⼀个⽗参与者的直接实例，这就要求属于抽象⽗参与者的外部对象⼀定能够属于其⼦参与者之⼀。
UML基础及Rose建模实用教程课后习题及答案
UML根底与Rose建模实用教程课后习题及答案第1章面向对象概述1. 填空题〔1〕软件对象可以这样定义：所谓软件对象，是一种将状态和行为有机结合起来形成的软件构造模型，它可以用来描述现实世界中的一个对象。
〔2〕类是具有一样属性和操作的一组对象的组合，即抽象模型中的“类〞描述了一组相似对象的共同特征，为属于该类的全部对象提供了统一的抽象描述。
〔3〕面向对象程序的根本特征是抽象、封装、继承和多态。
2. 选择题〔1〕可以认为对象是ABC。
〔A〕某种可被人感知的事物〔B〕思维、感觉或动作所能作用的物质〔C〕思维、感觉或动作所能作用的精神体〔D〕不能被思维、感觉或动作作用的精神体〔2〕类的定义要包含以下的要素ABD。
〔A〕类的属性〔B〕类所要执行的操作〔C〕类的编号〔D〕属性的类型〔3〕面向对象程序的根本特征不包括B。
〔A〕封装〔B〕多样性〔C〕抽象〔D〕继承〔4〕以下关于类与对象的关系的说法不正确的选项是A。
〔A〕有些对象是不能被抽象成类的〔B〕类给出了属于该类的全部对象的抽象定义〔C〕类是对象集合的再抽象〔D〕类用来在存中开辟一个数据区，并存储新对象的属性3. 简答题〔1〕什么是对象？试着列举三个现实中的例子。
对象是某种可被人感知的事物,也可是思维、感觉或动作所能作用的物质或精神体,例如桌子.椅子.汽车等。
〔2〕什么是抽象？抽象是对现实世界信息的简化。
能够通过抽象将需要的事物进展简化、将事物特征进展概括、将抽象模型组织为层次构造、使软件重用得以保证。
〔3〕什么是封装？它有哪些好处？封装就是把对象的状态和行为绑在一起的机制，使对象形成一个独立的整体，并且尽可能地隐藏对象的部细节。
封装有两个含义；一是把对象的全部状态和行为结合在一起，形成一个不可分割的整体。
对象的私有属性只能够由对象的行为来修改和读取。
二是尽可能隐蔽对象的部细节，与外界的联系只能够通过外部接口来实现。
通过公共访问控制器来限制对象的私有属性，使用封装具有以下好处：防止对封装数据的未授权访问、帮助保护数据的完整性、当类的私有方法必须修改时，限制了在整个应用程序的影响。
用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
第三讲 用例图
用例描述——事件流
1、事件流
事件流描述了一个用例在执行时参与者 与系统之间的交互过程。 其中预期会成功的路线称为基本流，剩 下其他路线称为备选流。
基本流
• 基本流是对用例中常规和预期路径的描 述。
• 执行者通过这个路径来执行用例可以得 到一个有价值的结果。
用例描述——事件流
• 例如，银行自动取款机(ATM)系统中的 “提款”用例可以用事件流表述如下：
•提款─基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
备选流
在用例的执行过程中，不一定都按常规 和预期的路径进行。 由于受到其他一些因素的影响，这时可 能执行了其他的路径，这种路径叫做备 选流。
备选流
•提款─备选事件流：
1.a ：如果用户插入无效信用卡，系统显示错误并 退出信用卡，用例结束。
• 用例分析技术是一种用户需求获取、分 析和描述技术。
• 用例图主要用于需求分析阶段。 • 用例图描述了待开发系统的功能需求。 • 用例图从用户的角度来理解系统，不关
心系统的内部结构。 • 用例图是后继各阶段开发工作的基础。
用例图
• 用例图是显示一组用例、参与者以及它们之间 关系的图。
– 用例图从用户的角度而不是开发者的角度来描 述对软件产品的需求，分析产品所需的功能和 动态行为
用例或关联参与者？
用例之间的关系
泛化关系 包含关系 扩展关系
用例之间的关系
泛化：同一业务目的的不同技术 实现。 包含：表示一个用例使用了另一 个用例的行为或功能。通过包含 用例提取公共交互，提高复用。 扩展：描述某个用例的特殊情况。 “冻结”基用例以保持稳定。
*通过关系提高用例复用
UML面向对象设计与分析 课后习题答案
读卡机 插入IC卡
显示屏
输入设备
接爱IC卡
客户管理
显示输入密码请求
查询密码
输入密码
传送密码
显示服务类型请求 输入取款请求
显示可选的取款金额请求 输入取款金额
查询服务类型 传递取款请求
查询取款金额
传送金额
出钞 取钞
点钞机
事务管理
消息1 确认密码合法
2．为下面打印文件时的工作流建模通信图： 用户通过计算机指定要打印的文件。 打印服务器根据打印机是否空闲，操作打印机打印文件。 如果打印机空闲，则打印机打印文件； 如果打印机忙，则将打印消息存放在队列中等待。 该系统共有四个对象 Computer、PrintServer、Printer 和 Queue。
credit card
+Verify()
0..*
n
sale
+Update()
check n
+verify()
0..*
inventory
+Load()
1
n +Save()
+Update()
第 4 章 活动图
2．运用本书前面介绍有关活动图的相关知识，根据图 4-33 的图书馆管理系统还书用例建模 该用例的活动图。综合运用所学到的标记符，包括活动、转移、控制点、泳道、分叉和汇合
其中，后两个类是 Instructor 类的子类。 （5）建立“一名教师助理可以协助一名教师和一名教授，一名教师只能有一名教师助
理，一名教授可以有 5 名教师助理”的模型。创建 TeacherAssistant 类，并使其与 Teacher 类和 Professor 类都建立关联。
（6）将 TeacherAssistant 类建模为 Graduate 类的派生类。
实验报告1--用例和用例图
中北大学软件学院实验报告
专业：软件工程
方向：软件开发与测试
课程名称： UML
班级：
学号：
姓名：
辅导教师：井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验，我掌握了在课堂上学习的用例图等。
加深了对书本知识的认识和记忆。
在实验中我学会了去如何操作ro se工具图。
通过ro se工具图，可以去清晰的去展示一个关系等。
使用非常方便。
UML用例和用例图
只书写“可观测”的
书写用例文档
——路径交互步骤的描述(2)
系统从会员处获取用户名和密码 会员提交用户名和密码 用户名和密码被验证 系统验证用户名和密码
使用主动语句
书写用例文档
——路径交互步骤的描述(3)
执行者××××× 系统××××× 系统××××× 执行者×××××
句子必须以执行者或系统作为主语
UML用例和用例图
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
Use Case 定义
➢ 定义1：用例是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一 个文字描述序列。
➢ 定义2：用例是系统、子系统或类和外部的 参与者（actor）交互的动作序列的说明， 包括可选的动作序列和会出现异常的动作 序列。
有足够库存 …….（后续描述省略）
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
案例1：ATM系统
建立一个具有基本功能的ATM机软件
客户可以存钱，取钱 客户可以查询帐户余额 客户可以修改密码 客户可以进行转帐
需求建模—用例图
互图分析和类图分析必不可少的部分。
用例的描述
一般说来，用例采用自然语言描述参与 者与系统进行交互时双方的行为，不追求 形式化的语言表达（面向不同人员）。
用例描述的内容
用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外，其他路径是什么 用例结束后的系统状态 其他需要：参与者是指系统以外的、需要使用系统 或与系统交互的东西，包括人、设备、外部系 统等。通过系统边界与系统进行有意义交互。
第3章 信息系统分析与设计 用例及用例图
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
第49页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
①.泛化关系 ②.包含关系 ③.扩展关系
第31页，共87页。
1. 泛化关系
参与者与参与者之间，用例与用例之间存在一般与 特殊的泛化关系。
第32页，共87页。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要用到 另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
②.在基用例执行的过程中，被包含的用例一定要被执行；
扩展关系如果条件不为真，扩展用例可以不执行。
③.包含关系中的基用例必须依赖被包含的用例，它不能
独立存在；扩展关系中的基用例可以独立存在。
第37页，共87页。
3.6 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能，通 过一组用例可以描述软件系统能够给用户提供的功 能。
3. 参与者的表示 参与者可以表示为下面三种形式。
第23页，共87页。
4. 参与者之间的关系 参与者之间可以有泛化关系。
第24页，共87页。
5. 参与者的特性 参与者具有以下特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系 ③.参与者与系统之间存在交互接口
第25页，共87页。
3.4 参与者与用例之间的关系
3.5 用例之间的关系 3.6 用例图
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
UML各章习题
UML各章习题第1、2章面向对象与UML1．简述统一建模语言(UML)统一建模语言(UML)是一种绘制软件蓝图的标准语言。
可以用UML对密集型软件系统的制品进行可视化详述和文档化。
UML是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言（1分）。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计（1分），还支持从需求分析开始的软件开发的全过程（1分）。
UML的作用是用图的形式从静态和动态方面来全面描述将要开发的系统（2分）。
2.简述面向对象分析方法（OOA）的5个基本步骤1）、识别对象，识别对象包括标识潜在的对象和筛选对象两步（1分）2）、识别对象的属性（1分）3）、识别对象的行为（1分）4）、识别对象所属的类（1分）5）、定义主题词（1分）3、什么是高内聚度？高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。
一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。
包括两个含义：一、不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成。
二、不相关的职责不要分派给同一个类。
4、什么是对象间的可见性答:可见性（Viibility）指的是一个对象能够“看到”或者引用另一个对象的能力。
5、领域建模的步骤有哪些？答案：列出候选的概念类；画出领域模型图；加入概念类间的关联；加入概念类的属性。
6、什么是软件生命周期？软件生命周期(SDLC，SytemDevelopmentLifeCycle)是软件的产生直到报废或停止使用的生命周期，周期内包括问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段。
这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。
7、什么是软件开发生命期？软件开发生命期是指软件产品从考虑其概念开始，到该产品交付使用为止的整个时期。
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互，参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者：参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时， 应主要考虑他的角色，而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员，但他们均起着同 一种作用，扮演着相同的角色。 … 一个用户也可以扮演多种角色：一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者：泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例（use case） 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法，是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
用例和用例图
第二页，编辑于星期二：十三点 五十六分。
第三页，编辑于星期二：十三点 五十六分。
第四页，编辑于星期二：十三点 五十六分。
第五页，编辑于星期二：十三点 五十六分。
第六页，编辑于星期二：十三点 五十六分。
第七页，编辑于星期二：十三点 五十六分。
第八页，编辑于星期二：十三点 五十六分。
第二十三页，编辑于星期二：十三点 五十六分。
第二十四页，编辑于星期二：十三点 五十六分。
第二十五页，编辑于星期二：十三点 五十六分。
第二十六页，编辑于星期二：十三点 五十六分。
第二十七页，编辑于星期二：十三点 五十六分。
第二十八页，编辑于星期二：十三点 五十六分。
第二十九页，编辑于星期二：十三点 五十六分。
第十六页，编辑于星期二：十三点 五十六分。
第十七页，编辑于星期二：十三点 五十六分。
第十八页，编辑于星期二：十三点 五十六分。
第十九页，编辑于星期二：十三点 五十六分。
第二十页，编辑于星期二：十三点 五十六分。
第二十一页，编辑于星期二：十三点 五十六分。
第二十二页，编辑于星期二：十三点 五十六分。
第三十页，编辑于星期二：十三点 五十六分。
第三十一页，编辑于星期二：十三点 五十六分。
第三十二页，编辑于星期二：十三点 五十六分。
第三十三页，编辑点 五十六分。
第九页，编辑于星期二：十三点 五十六分。
第十页，编辑于星期二：十三点 五十六分。
第十一页，编辑于星期二：十三点 五十六分。
第十二页，编辑于星期二：十三点 五十六分。
第十三页，编辑于星期二：十三点 五十六分。
第十四页，编辑于星期二：十三点 五十六分。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Telephone Catalog
用例 参与者与用例间的关系
check status
place order
顾客 用例名
fill orders
establish credit
系统边界
参与者 销售员 货运员 监督员
3.2 参与者
参与者指系统外部的、需要使用系统或与 系统交互的一个实体。
参与用例的执行过程。 通过向系统输入或请求系统输入某些事件
一个动词或者一个动词短语，用 于指明关系的类型或者目的。
关联关系表示通信途径
关联关系
用例图的两种类型关联：
1、单向关联
项目管理系统
项目经理
管理项目
2、双向关联
项目数据库
包含关系
将若干用例的相同动作，提取出来单独构成一个 用例。这个用例可以重用
描述的是基本用例需要某种类型的行为，而包含 用例定义了该行为，那么在用例的执行过程中， 就可以调用已经定义好的用例。
父用例表示通用行为序列，通过插入额外的步骤， 子用例特化父用例。
表示方法
例如，
项目经理
泛化关系
项目管理系统
邮件系统
公布项目 进度表
发送邮件 生成Web
站点
项目 数据库
兼职经理
全职经理
Web站点主机
关系数据库
面向对象 数据库
关系的比较
包含 扩展 泛化
特点
若一个用例包含一段定义良好且有可能用于其它 场合的动作序列或几个用例都有共同的一段动作 序列，可把该动作序列定义成一个包含用例。 基本用例没有包含用例是不完整的。 使用时，基本用例无条件调用包含用例。
例如，
项目经理
包含关系
项目管理系统 添加项目 删除项目
<<include>> 查找项目
项目 数据库
扩展关系
指的是一个用例可以增强另一个用例的行为 基本用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基本用例的扩展点上。 当在某个现有用例中插入“可选”行为或“异常”行为时，
3.4 用例间的关系
关系反应了参与者和用例之间、用例和用例之间 以及参与者和参与者之间的相互作用。
1 关联关系 2 包含关系 3 扩展关系 4 泛化关系
关联关系
表示参与者用例之间进行通信。 信息可以双向流动。
关系方向显示的不是信息的流 动方向，而是谁启动信息。
表示
工具箱：
模型图中：
关联命名
3.3 用例
图形表示
用椭圆形表示， 用例的名字显示 在图标的下面
例1，字处理程序
Purchase Ticket
置正文为黑体
左对齐
例2，银行业务系统
创建索引
浏览帐户余额 列出交易内容 划拨资金 支付账款
3.3 用例
注意：
① 不要把所有需求都以用例的形式表示出来， 只把重要的、交互过程复杂的用例找出来
② 用例不是系统的全部需求，全部需求包括： 系统的目的和范围；系统中的术语表；用例； 系统采用的技术；开发过程中的参加人员、 业务规则、系统运行所依赖的条件等；法律、 政治、组织机构等
③ 用例是与实现无关的关于系统功能的描述。 是一种功能分解的技术，并没有使用面向对 象思想。
3.3 用例
协作
是对由共同工作的类、接口和别的元素所组成 的群体的命名，这组群体提供合作的行为。
例如，“提取现金”用例
3.6 事件流及脚本
主事件流
1 插入卡 2 验证卡 3 验证银行客户 4 选择取款 5 在标准数额列表里选
择取款金额
6 与银行系统确认交易 7 支付现金 8 弹出卡
可选事件流
1.1 无法识别卡 3.1 无法识别客户 4.1 不需要取款 5.1 非标准取款数额 5.2 帐户余额不足 5.3 金额超出每日最 高限额
3.6 事件流及脚本
例如：“浏览产品并下定单”用例 主事件流的开始部分
参与者“客户”选择浏览“在售产品目录”时， 启动本用例
用例结束部分
系统询问客户是否还需订购更多产品 如果客户希望订购更多的产品，用例重回到{显
示产品类别}处 如果客户不想再订购其他产品，用例终止
3.6 事件流及脚本
参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
这些事件代表了哪些功能？
用例识别
识别用例
系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？
例 1 参与者客户选择浏览“在售产品目录”时，启
动用例 {显示产品类别} 2 系统显示出“在售产品”，突出显示与客户的
配置文件相关的产品类别
3.6 事件流及脚本
5.定义可选事件流
可选事件流所描述的行为是可选的、特殊的， 他总是依赖于其他事件流中某个明显位置所发 生的条件，他允许在移除行为的同时，不会影 响主事件流或其他可选事件流
与用户沟通系统流 程，并将沟通内容
绘制成用例图
3.1 用例图
用例图包含6元素： ① 参与者（Actor） ② 用例（Use Case） ③ 用例间关系（Association） ④ 脚本（Scenario） ⑤ 描述（Description） ⑥ 系统
3.1 用例图
电话簿销售系统用例图 ：
系统名
对于在某些条件下，或可选情况下的一段动作序 列，可定义为扩展用例。 基本用例本身是完整的。 使用时，基本用例有条件调用扩展用例。
如果一个用例有几种变体，可使用泛化。
常见问题
一个用例应该至少向他的一个参与者提供唯一的、 独立的价值。若发现需要依次执行几个用例来获 取有用的信息，那么一定有问题
用例的粒度大小要合适，过小的用例不会对任何 参与者产生价值，过大的用例其逻辑又比较复杂
3.3 用例
用例特征：
① 用例从使用系统的角度描述系统中的信息，是从系 统的外部查看系统的功能，不考虑系统内部的具体 实现
② 说明了一个参与者与系统执行的一个相关事务序列
③ 用例描述了用户提出的一些可见需求，对应一个具 体的用户目标
④ 用例是对系统行为的动态描述，属于UML的动态建 模部分
⑤ 提供了一种与最终用户和领域专家进行沟通的方法 ⑥ 提供了一种测试系统的方法
不要将用例定义为功能菜单项，所谓CRUD问题
3.5 用例视图
用例图包含的内容
用例 参与者 用例与参与者之间的关联关系 用例之间的包含和扩展关系 参与者的泛化关系 用例图 用例实现 顺序图 协作图
3.5 用例视图
用例图操作
创建新的用例图 打开已有的用例图 删除用例图 链接用例图 重命名用例图
用例：提取现金
1 当参与者“客户”插入银行卡时，启动用例 2 系统从卡中读取银行卡信息 3 执行子事件流“验证客户” 4 系统提示客户输入提取金额
3.6 事件流及脚本
4.定义扩展点
扩展点是事件流中的命名空间，在这里可以插 入或附加其他行为
在事件流内部，扩展点用粗体大括号表示 例如，包含扩展点的“浏览产品并下定单”用
3.定义子事件流
子事件流是用例中一个行为片段，他有明确的 目标，同时是“原子性”的。
子事件流可以将复杂的事件流进一步划分，以 提高可读性
3.6 事件流及脚本
例如，子事件流
S1 验证客户 1 系统查询客户银行，确保该客户的帐户有效 2 系统提示客户输入PIN 3 客户输入PIN 4 系统使用从卡中读取的PIN验证所输入的PIN 5 恢复到下一步骤
特点：由基本用例决定是否调用，包含用例对调 用对象一无所知，且不参与其中的选择判断。
图形表示：
包含关系
使用包含关系的三种情况：
a. 多个用例包含大量类似的行为，应该考虑将这 些类似的行为通过包含关系包含到用例中
b.对两个或多个互相独立的用例建模时做了重复 的工作，可以通过包含关系包含这些重复的工 作
3.6 事件流及脚本
事件流用于描述参与者什么时候激活用例，以及 用例如何完成其任务
1.定义一个事件流
推荐使用叙述式风格，为每一个步骤编号，给每个独 立的部分加标题。
2.定义主事件流
应该覆盖用例执行时，正常发生的情况，是用例事件 流部分所描述的第一个事件流 从定义参与者启动用例的事件着手 描述参与者与系统正常交互 描述用例如何结束
参与者的识别 ① 谁将使用系统的主要功能？ ② 谁将需要系统的支持来完成他们的日常任务？ ③ 谁必须维护、管理和确保系统正常工作？ ④ 谁将给系统提供信息、使用信息和删除信息？ ⑤ 系统需要处理哪些硬件设备？ ⑥ 系统使用了外部资源吗？ ⑦ 系统需要与其他什么系统交互吗？ ⑧ 谁或者什么对系统产生的结果感兴趣？ ⑨ 一个人同时使用几种不同的规则吗？ ⑩ 几个人使用相同的规则吗？ 11 系统使用遗留下来的应用吗？
参与者间的关系
在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
示例：
父参与者
子参与者
子参与者
子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
子参与者可以出现在父参 与者能出现的任何位置上
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
会变得十分复杂，应该考虑使用扩展关系
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]