第2章 用例图
Rational_Rose_建模工具及应用
部分对象可以被多个整体对象共享。
组装关系
通过指针引用
组合关系
部分对象只能只属于一个整体对象。
组装关系
通过值
限定词
将多对多的关联转化为多对一的关联。
关联类
具有关联特性的类。
先建立类，然后在工 具栏中选中关联类工 具连接类与关联。
3.1.3 模板
将属性的类型、操作的参 数类型和返回值类型参数 化。
Rational 产品线
Apex Rose SoDA Pure Series ClearCase SQA Suite 集成化软件工程环境 可视化建模 文档自动化 白盒测试 配置管理 黑盒测试
Rational Rose与软件开发阶段
需求分析 Use Case Diagram 和 其它描述 Sequence Diagram Collaboration Digram Class Diagram State Diagram Activity Diagram Component Diagram 和 其它描述
Delete Course Registrar
Modify Course
2.2 活动图
在用例模型中，活动图用来捕捉用例中 的事件，使用框图方式显示动作与结果。 除此外，还可以：描述工作流的方式； 描述对象内部的工作。 活动图由起始状态、终止状态、状态、 活动、转移、分支、对象、同步棒以及 泳道组成。
2.1 用例图
选择工具 文本框
注释 注释连接线
包 用例 参与者 单向关系 依赖关系 泛化关系
在工具栏按鼠标右键，自 定义工具栏
绘图工具栏
添加了关联工具 的工具栏
2.1.1 参与者
第2章 统一建模语言UML
UML 2.0
1997年对象管理组织（Object Management Group
，OMG）采纳UML作为其标准建模语言，并通过严 格有序的OMG过程对其进行修订和维护。 1999，UML 1.3，相对稳定成熟阶段 2001-05， UML 1.4 2003年6月宣告完成了UML 2.0 ： Infrastructure（底层结构） Superstructure（上层结构） OCL（对象约束语言） Diagram Interchange（图形交换）
关联类
关联类用来记录与关联（关系）有关的信息，提
供与关联有关的操作。
+Employee +Employer
Person
* 1
Company
Employment +Contract
（2）包图
包图在UML中可以看作是类图的一部分。
包用来对一组元素进行划分，是对复杂模型的一
种分而治之的层次划分。 常用来描述一个复杂系统逻辑上的子系统划分。 包图主要由包和包之间的关系组成。 包的划分应遵循高内聚、低耦合的原则，一个包 中可以包含多个类和子包。 包图的图元： 包、依赖关系、导入关系、合并关系
UML 2.0的建模机制
类图 (Class Diagram) 包图 (Package Diagram) 对象图 (Object Diagram) 结构建模 (Structure) 构件图 (Component Diagram)
组合结构图 (Composite Structure Diagram)
UML 2.0 建模机制
* 1
OrderItem
Order
泛化（继承）关系
Person
系统分析与设计第2章
计算机
菜单
显示器
CPU
列表框
按钮
内存
键盘
§2.3.2 对象和类的提取和确定
三、类之间的关系 4.接口和实现关系 接口：也是一个类，接口用于描述类或组件必 须实现的契约。 实现关系：一个类元描述了另一个类元保证实 现的契约。
<<interface>> Interface Interface
§2.3.2 对象和类的提取和确定
三、类之间的关系 3.关联关系:关联是一种结构关系，代表类的 对象（实例）之间的一组连接（链）。 （1）关联的属性 ①名称 ②角色：
人员
雇用
公司
§2.3.2 对象和类的提取和确定
三、类之间的关系 ③多重性：通常需要说明一个关联实例中有多少 个相互连接的对象，这就是关联的多重性。
§
2.3.1 对象图、类图
二、对象图 对象图(Object Diagram) 是显示了一组对象和 他们之间的关系。对象图可以看作是类图的一个 实例。 1.对象图的定义 对象图中通常含有：对象和连接。对象图也可 以像其他的图一样，包含注解、约束、包或子系 统。 2.理解对象图的方法 (1) 识别出对象图中所有的类。 (2) 了解每个对象的语义及对象之间连接含 义。
§2.3.2 对象和类的提取和确定
三、类之间的关系 1.泛化（继承）关系 泛化关系指类之间的“一般与特殊关系”。 通常称一般元素为父类，称特殊元素为子类。 子类继承父类的特性（属性、操作、关联等）， 同时可以有自己的特性。 单继承 多继承 继承有传递性
客户 学生
个人客户
团体客户
大学生
中学生
§2.1.3加速系统分析法
加速系统分析法强调构造原型，以便更快速地
UML-超市管理系统
面向对象分析与设计（UML）综合实验报告项目名称：超市管理系统目录第1章系统需求分析41。
1 超市管理系统业务概述41.2 超市管理系统各子系统需求分析51。
2。
1 仓库管理子系统51。
2。
2 采购管理子系统61。
2。
3 财务管理子系统61。
2。
4 人事管理子系统71。
2。
5 销售管理子系统81。
2.6 登录子系统81.2.7 信息管理子系统9第2章系统用例模型112.1 仓库管理用例模型1错误!未定义书签。
2。
1.1 仓库管理用例图错误!未定义书签。
22.1.2 仓库管理用例图相关说明错误!未定义书签。
22.2 采购管理用例模型错误!未定义书签。
22。
2。
1 采购管理用例图错误!未定义书签。
22.2.2 采购管理用例图相关说明错误!未定义书签。
32.3 财务管理用例模型错误!未定义书签。
32.3.1 财务管理用例图错误!未定义书签。
32.3.2 财务管理用例图相关说明错误!未定义书签。
42.4 人事管理用例模型错误!未定义书签。
42。
4.1 人事管理用例图错误!未定义书签。
52.4。
2 人事管理用例图相关说明错误!未定义书签。
52.5 销售管理用例模型162。
5。
1 销售管理用例图162。
5.2 销售管理用例图相关说明162。
6 登陆用例模型162.6。
1 登陆用例图162.6。
2 登陆用例图相关说明172。
7 信息管理用例模型172。
7.1 信息管理用例图172.7。
2 信息管理用例图相关说明18第3章系统静态模型203.1 系统中的类203.1。
1 参与者相关的类203。
1。
2 系统中其他的相关类203。
2 系统中类与类的关系213。
2。
1 仓库管理系统类图2错误!未定义书签。
3.2.2 采购管理系统类图错误!未定义书签。
13。
2.3 财务管理系统类图错误!未定义书签。
13.2。
4 人事管理系统类图2错误!未定义书签。
3.2。
5 销售管理系统类图2错误!未定义书签。
3.2。
6 信息管理系统类图错误!未定义书签。
需求调研必备工具UML-用例图介绍
用例是对包括变量在内的一组动作序列的描述。 系统执行这些动作，并产生传递特定参与者的价值的可观察结果。 简单的说，用例是参与者想要系统做的事情。
4
第一章 用例图的定义
系统边界（子系统）
系统边界是用来表示正在建模系统的边界。 边界内表示系统的组成部分，边界外表示系统外部。 系统边界在画图时也可以省略。
这个事物是什么？ 这个事物能做什么？ 人们能用这个事物做什么？
如何描述自行车？
一种交通工具，它由传动系统、 刹车系统等部分组成。
可以骑行、可以载物。 人们可以用脚蹬踏板前进，也
用手捏刹车使自行车停下来。
8
第二章 用例图和功能的误区
结构性观点
功能性观点
• 即事物的客观存在。 • 不能够说明事物的作用，也就
16
第四章 用例图的绘制
4、扩展(Extend) • 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。 • 将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的
扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。 • 扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前
12
第三章 系统用例和业务用例
业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。 业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而
是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性 需求由这些系统用例构成。
业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。 在业务层面，点菜人员只需要点菜，或者是取消点菜，但是在需求用例中需要体现增
UML复习题选填简答整理
第一章UML入门填空：1、如果把众多事物进行归纳和分类，那么所依据的面向对象的特性是抽象。
2、面向对象中的表示层用于提供给用户使用和显示的界面。
3、UML中的元元模型层位于结构最上层，是组成UML最基本的元素，代表要定义的所有事物。
4、在UML2.0中用来表示类、组件、协作等模型元素内部结构的是组合结构图。
5、UML中的实现关系使用一条空心三角作为箭头的虚线作为其图形表示。
选择：1、下列不属于对象特性的是。
A、对象都是唯一的B、一滴水是一个对象C、一个对象肯定属于某个类别D对象必须是可见的2、如果要解决系统做什么应该使用。
A、面向对象的分析B、面向对象的设计C、面向对象的编程D、面向对象的开发3、面向对象中的描述了系统内部对象及其关系的静态结构。
A、对象模型B、状态模型C、交互模型D、类模型4、UML中的用于描述系统的实现模块以及它们之间的依赖关系。
A、组件视图B、用例视图C、逻辑视图D、部署视图5、下列不属于UML2.0中图的是。
A、协作图B、包图C、交互图D、组合结构图6、下列UML事物中表示协作的是。
A、B、C、D、InterfaceName简答题：1、简要说明UML中视图与图的关系。
答：UML的视图都是由一个或多个图组成的，图就是系统架构在某个侧面的表示，所有的图一起组成了系统的完整视图。
第二章用例图填空题：1、用例图标准关系有扩展、泛化关系、关联关系和包含关系。
2、用例图的组成有关系、系统、参与者和用例。
3、在UML中，用例用一个圆形来表示。
4、泛化关系使用一条实线和一个三角箭头来链接用例。
选择题：1、下列说法正确的是。
A.用例间的关系是后期开发需要的，对用例图没有影响。
B.扩展关系可以是用例间的，也可以是参与者间的。
C.泛化关系可以是用例间的，也可以是参与者间的。
D.包含关系表示为虚线箭头。
2、下列符号中表示扩展的是。
A. B. C. <<extends>>D. <<extends>>简答题：1、用例描述主要包括哪些方面？答：用例描述一般包括有：名称、标识符（可选）、参与者（可选）、状态（可选）、频率、前置条件、后置条件、假设（可选）、基本操作流程、可选操作流程、修改历史记录（可选）2、泛化描述了什么？答：泛化描述的是子用例与父用例的关系，子用例是父用例的特化，它除了可以具有父用例的特性外，还可以有自己的另外特性。
(完整版)UML-银行管理系统
面向对象分析与设计（UML）综合实验报告书题目：银行管理系统第1章需求分析............................................................................. 错误!未定义书签。
1.1 客户子系统的需求分析 (4)1.2 银行管理员系统的需求分析 (4)第2章系统用例模型 (8)2.1 管理员的用例模型 (8)2.2 客户的用例模型 (12)第3章系统静态模型 (16)3.1 系统中的类 (16)3.2 系统中类与类的关系 (17)第4章系统动态模型 (19)4.1银行管理员创建账户 (19)4.2银行管理员修改账户 (20)4.3银行管理员删除账户 (22)4.4 客户取款 (24)4.5 客户存款 (25)4.5 客户转账 (25)4.6 银行管理系统中的状态图................................................................ 错误!未定义书签。
4.7 银行管理系统中的活动图................................................................ 错误!未定义书签。
第5章系统部署模型 (33)5.1 银行管理系统的构件图 (33)5.2客户操作构件图 (34)5.3 银行管理员构件图 (34)5.5 银行管理系统部署图 (33)第6章总结与展望 (36)6.1 总结 (36)6.2 展望 (36)参考文献............................................................................................ 错误!未定义书签。
随着社会的不断发展，计算机越来越普及。
我们正处在一个信息时代，计算机无处不在，它进入各行各业，改变着人们的生活。
第2章 信息系统建模
第2章 信息系统建模 UML采用一组图形符号来描述软件模型，这些图 形符号具有简单、直观、规范的特点。因而UML的特 点是：开发人员学习和掌握起来比较简单；所描述的 软件模型可以直观地理解和阅读；由于具有规范性， 所以能够保证模型的准确、一致。 2. UML的基本内容 作为一种对客观系统的建模语言，UML提供了描 述事物实体、性质、结构、功能、行为、状态、关系 的建模元素，并通过一组图来描述由建模元素所构成 的多种模型。UML的建模元素包括基本建模元素、关 系元素和图三大类，见图2.10。
测试
建立测试模型
细化 迭代1 迭代2
…
…
…
…
…
迭代n -1 迭代n
图2.9 信息系统建模过程
第2章 信息系统建模 2.1.4 信息系统建模语言 信息系统建模语言是描述信息系统模型的规则符号集。 信息系统建模语言与信息系统开发方法和开发过程有关，不 同的开发过程规定了不同的开发步骤和开发工作，不同的开 发方法规定了不同的建模语言。像结构化方法就采用数据流
第2章 信息系统建模
模型分析
需求理解
现实系统
建立模型
模型
图2.1 建模过程
第2章 信息系统建模 2. 信息系统模型 信息系统属于智能性系统，在信息系统中蕴藏着大量的 信息、知识、方法和技术。信息系统无论是在开发过程中， 还是在开发成功之后，都不具备其它简单物质系统的形态外 显性。信息系统这种深刻的包藏性，给信息系统的开发带来 了极大的困难，使得在整个信息系统开发过程中，人们对它 难以把握和描述。为了工程化、有效地开发信息系统，人们 除了寻求有效的开发方法，严密地组织工程过程之外，还需 要在开发的各个阶段，以某种有效的形式把信息系统描述和 表现出来，这样开发人员才能够有针对性地进行交流和讨论。 我们把通过确定的形式，对信息系统本质特性的描述称为信 息系统建模，而所描述的结果称为信息系统模型。
第2章用例和用例图
成绩管理
UML用例图组成( UML用例图组成(续) 用例图组成
饮料销售机
UML用例图组成( UML用例图组成(续) 用例图组成
用例与用例的扩展关联用来表示通过对已有用例增加步 用例与用例的扩展关联用来表示通过对已有用例增加步 扩展关联用来表示 骤创建一个新的用例,即对原有的用例进行了扩展。 骤创建一个新的用例 即对原有的用例进行了扩展。扩展只能 即对原有的用例进行了扩展 发生在基用例的序列中的某个具体指定点上。这个点叫做扩 发生在基用例的序列中的某个具体指定点上。 展点.在UML图中，使用带虚线箭头表示，并在线上标有构造 展点 在UML图中，使用带虚线箭头表示， 图中 带虚线箭头表示 如下图所示： 型<<extend>> 。如下图所示：
UML用例图组成( UML用例图组成(续) 用例图组成
包含关联与扩展关联的区别： 包含关联与扩展关联的区别：
存在包含关联的两个用例,在执行基本用例时 一定会执 存在包含关联的两个用例 在执行基本用例时,一定会执 在执行基本用例时 行包含用例；存在扩展关联的两个用例,在执行基本用例时 在执行基本用例时, 行包含用例；存在扩展关联的两个用例 在执行基本用例时 可以执行,也可以不执行扩展部分 可以执行 也可以不执行扩展部分. 也可以不执行扩展部分
UML用例图的作用( UML用例图的作用(续) 用例图的作用
• 用例图的主要作用： 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 作为开发过程的基础， – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步. 画好用例图是由软件需求到最终实现的第一步.
UML用例图的建模( UML用例图的建模(续) 用例图的建模
UML复习资料(完整)
2011UML复习题纲一、选择、判断、填空第一章UML与面向对象1、UML(Unified Modeling Language,统一建模语言)是软件和系统开发的标准建模语言，它主要以图形的方式对系统进行分析、设计。
2、UML是在多种面向对象分析与设计方法相互融合的基础上形成的，是一种专用于系统建模的语言。
它为开发人员与客户之间，以及开发人员之间的沟通与理解架起了“桥梁”。
3、UML不是开发工具，只是建模语言。
4、OOA三种基本模型：功能模型、对象模型、动态模型。
5、软件是程序、数据和相关文档的完整集合。
6、软件开发过程分为如下几个阶段：需求分析、总体设计、详细设计、编程与测试、维护。
7、面向对象的软件工程方法包括面向对易用的分析（OOA）、面向对象的设计（OOD）、面向对象的编程（OOP）。
8、软件方法学包含3个要素：方法、工具和过程。
9、对象是现实世界中一个实际存在的事物，它可以是看得见摸得着的东西。
10、类是一组具有相同属性的操作的对象集合，它为所有属于该类的对象提供了统一的描述。
11、封装是指将对象属性和操作结合在一起，构成一个独立的对象。
封装使得对象属性和操作紧密结合在一起，这反映了事物的状态特性与动作是事物不可分割的特征。
12、继承是指子类可以拥有父类的全部属性和操作，继承是OO方法的一个重要的概念，并且是OO技术可以提高软件开发效率的一个重要原因。
13、多态性是指在父类中定义的属性和操作被子类继承后，可以具有不同的数据类型或表现出不同的行为。
14、OO开发中的三层设计：问题域类、GUI类和数据访问类。
15、面向对象设计准则：模块化、抽象、信息隐藏、低耦合、高内聚。
16、UML的构成：元元模型层、元模型层、模型层、用户模型层。
17、UML的核心是由视图、图、模型元素、通用机制组成。
18、UML中的视图细分：（1）用例视图（用例视图强调从系统的外部参与者角度需要的功能，描述系统应该具有的功能）；（2）逻辑视图（逻辑视图的使用者主要是设计人员和开发人员，描述用例视图提出的系统功能的实现）；（3）并发视图（并发视图的使用者主要是开发人员和系统集成人员，它主要考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理）；（4）组件视图（组件是不同类型的代码模块，它是构造应用的软件单元。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
包含关系
包含关系使一个用例的功能在另一个用例中使 用: 1. 如果两个以上用例有大量一致的功能,则可以 将这些功能分解到另一个用例中.其它用例可 以和这个用例建立包含关系. 2. 一个用例的功能太多时,可以用包含关系建模 两个小用例. 要使用包含关系,就必须在客户用例中说明 用例行为被包含的详细位置. 例如:某学校信息系统用例图的部分内容.
扩展关系
基础用例即便没有扩展用例也是完整的. 一个用例可能有多个扩展点,每个扩展点 也可以出现多次.一般而言,基础用例的 执行不会涉及到扩展用例,只有在特定的 条件下,扩展用例才被执行. 扩展关系为处理异常或构建灵活的系统框 架提供了一种十分有效的方法.
泛化关系
父用例也可以被特别列举为一个或多个子用例.这被称为 用例泛化. 在UML中,用一个三角箭头从子用例指向父 用例. 子用例表示父用例的特殊形式. 子用例从父用例处继承行为和属性,还可以添加行为或覆 盖,改变继承的行为. 如果系统中一个或多个用例是某个一般用例的特殊化时, 就需要使用用例的泛化关系.
1. 2. 3. 4. 5.
用例与事件流
事件流的目的:为用例的逻辑流程建立文 档,这个文档详细描述系说明 2. 前提条件 3. 事件流(主事件流,其他事件流,错误 流) 4. 事后条件
2.1.4 用例间的关系
1 2 3 4 关联关系 包含关系 扩展关系 泛化关系
2.1.1 概述
① ② ③ ④ ⑤ ⑥ 用例图包含6个元素: 参与者(Actor) 用例(Use Case) 关联关系(Association) 包含关系(Include) 扩展关系(Extend) 泛化关系(Generalization)
2.1.2 参与者
系统外部的一个实体,以某种方 式参与用例的执行过程. 通过向系统输入或请求系统输入 某些事件来触发系统的执行. 由参与用例时所担当的角色来表 示. 每个参与者可以参与一个或多个 用例. 它通过交换信息与用例发 生交互,而参与者的内部实现与 用例是不相关的,可以用一组定 义其状态的属性充分描述参与者.
② ③ ④
例如:某大学图书馆信息系统的语境,它 强调系统外部的参与者.其中借书人 (Borrower)可以泛化成两类:学生 (Student)和老师(Teacher).
2.2.2 对需求建模
需求是根据用户对产品功能的期望,提出产品外部功能 的描述.需求分析师的工作是获取系统的需求,归纳系 统所要实现的功能,使最终的软件产品最大限度的贴近 用户的要求.需求分析师的一般只考虑系统做什么 (what),而尽可能的不去考虑怎么做(how). 识别系统的外部参与者来建立系统的语境. 考虑每一个参与者期望的行为或需要系统提供的行为. 把这些公共的行为命名为用例. 确定提供者用例和扩展用例. 对这些用例,参与者和它们之间的关系建模. 用注释修饰用例.
① ② ③ ④ ⑤ ⑥
2.3 实例——图书馆管理系统的用例图
确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 图书馆管理系统的用例图
2.3.1 2.3.2 2.3.3 2.3.4
2.3.1 确定系统涉及的总体信息
读者: ① 借书 ② 还书 ③ 书籍预定
2.3.1 确定系统涉及的总体信息
1. 2. 3. 4. 5. 6.
确定参与者
1. 2. 3. 4. 5. 6. 7. 对参与者建模的过程中需要注意的问题 参与者对于系统而言总是外部的,因此它们可以处于人 的控制之外. 参与者可以直接或间接地同系统交互,或使用系统提供 的服务以完成某件事务. 参与者表示人和事物与系统发生交互时所扮演的角色, 而不是特定的人或者特定的事物. 一个人或事物在与系统发生交互时,可以同时或不同时 扮演多个角色. 每一个参与者需要一个具有业务一样的名字,在建模中 不推荐使用类似于"新参与者"的名字. 每一个参与者必须有简短的描述,从业务角度描述参与 者是什么. 和类一样,参与者可以具有表示参与者的属性和可接受 的事件,但使用得不频繁.
关联关系
关联关系描述参与者与用例之间的关系.在UML 中,关联关系使用箭头来表示. 表示参与者用例之间进行通信. 不同的参与者可以访问相同的用例,一般而言它 们和该用例的交互是不一样的.
包含关系
一个用例可以简单地包含其它用例具有的行为,并把它所 包含的用例行为作为自身行为的一部分.这被称作包含关 系.在UML中,包含关系表示为虚线箭头加 《include》, 箭头指向被包含的用例. 包含关系把几个用例的公共步骤分离成一个单独的被包含 用例.被包含用例称作提供者用例,包含用例称作客户用 例,提供者用例提供功能给客户使用.
�
第2章 用例图
2.1 用例图的概念 2.2 用例图建模技术 2.3 实例——-图书馆管理系统中的 用例图
2.1.1 概述
用例图是由软件需求分析到最终实现的第一步,它描述人 们希望如何使用一个系统.显示谁将是相关的用户,用户 希望系统提供什么服务以及用户需要为系统提供的服务, 以便使系统的用户更容易地理解这些元素的用途,也便于 软件开发人员最终实现这些元素. 用例图最常用来描述系统以及子系统.
图书馆管理员: ① 书籍借出处理 ② 书籍归还处理 ③ 预定信息处理
2.3.1 确定系统涉及的总体信息
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ 系统管理员: 增加书目 删除或更新书目 增加书籍 减少书籍 增加读者帐户信息 删除或更新读者帐户信息 书籍信息查询 读者信息查询
2.3.2 确定系统的参与者
首先分析系统所涉及的问题领域和系统运 行的主要任务: ① 分析使用该系统主要功能部分的是哪些人. ② 谁将需要该系统的支持以完成其工作. ③ 系统的管理者与维护者.
2. 图书馆管理员处理借书,还书的用例
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ 查询借阅者信息 查询书籍信息 增加书目 删除或更新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户
2.3.4 图书馆管理系统的用例图
扩展关系
扩展用例被定义为基础用例的增量扩展.在UML 中,扩展关系表示为虚线箭头加《extend》,箭 头指向被扩展的用例(即基础用例) 基础用例提供扩展点以添加新的行为. 扩展用例提供插入片段以插入到基础用例的扩展 点上.
扩展关系
例如:图书馆信息系统用例图的部分内容. 基础用例有ReturnBook(还书), BorrowBook(借书),FindBook(找书) 等.如果读者所借图书超期 (OverdueBook),此时用基础用例就不能 解决这类问题,这时就可以在基础用例 "还书"的基础上增加扩展用例 "IssueFine(交纳罚金)".
2.1.2 参与者
参与者的种类: ① 系统用户 命名这类参与者时,应当按照 业务而不是按位置命名,因为一个人可能 有很多业务. ② 与所建造的系统交互的其他系统 ③ 一些可以运行的进程 ,如时间等.
确定参与者
如何寻找系统的参与者? 谁将使用该系统的主要功能. 谁将需要该系统的支持以完成工作. 谁将需要维护,管理该系统,以及保持该系统 处于工作状态. 系统需要处理哪些硬件设备. 与该系统交互的是什么系统. 谁或什么系统对本系统产生的结果感兴趣.
2.3.2 确定系统的参与者
图书馆管理系统的参与者: ① 读者(借阅者) ② 图书馆管理员 ③ 图书馆管理系统维护者
2.3.3 确定系统的用例
1. 借阅者请求服务的用例 2. 图书馆管理员处理借书,还书等的用例 3. 系统管理员进行系统维护的用例
1. 借阅者请求服务的用例
① ② ③ ④ ⑤ ⑥ 登录系统 查询自己的借阅信息 查询书籍信息 预定书籍 借阅书籍 归还书籍
识别用例
识别用例最好的方法就是从分析系统的参与者开始,考 虑每个参与者是如何使用系统的. 用例建模过程就是 一个迭代和逐步精华的过程.系统分析者首先从用例的 名称开始,然后添加用例的细节信息. 如何识别用例. 特定参与者希望系统提供什么功能. 系统是否存储和检索信息,如果是,由哪个参与者触发. 当系统改变状态时,是否通知参与者. 是否存在影响系统的外部事件. 哪个参与者通知系统这些事件.
1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书,还书的用例图 3. 系统管理员进行系统维护的用例图
1. 借阅者请求服务的用例图
2. 图书馆管理员处理借书,还书的 用例图
3. 系统管理员进行系统维护的用例图
讨论题
假设有一个基于网络的学生成绩管理系统, 该系统主要完成以下功能:教师使用该系 统完成学生成绩的录入,修改,显示和打 印,学生使用该系统来查询所学课程的成 绩,管理员使用该系统输入学生信息,教 师信息,班级信息和课程信息. 对上面给出的系统进行分析,找出系统中 的参与者,用例,并对每个参与者,用例 进行详细的描述.
2.1.3 用例
用例的名称: ① 简单名 ② 路径名 是在用例名前加上所属包的名字
2.1.3 用例
用例的动态执行过程可以用UML的交互来 说明,可以用状态图,时序图,协作图或 非正式的文字描述来表示.用例功能的执 行通过系统中类之间的协作来实现.一个 类可以参与多个协作,因此可以参与多个 用例. 在系统层,用例表示整个系统对外部用户 可见的行为.
参与者间的关系
在用例图中,使用泛化 关系来描述多个参与者 之间的公共行为. 参与者间的泛化关系 示例:
2.1.3 用例
用例是一个叙述型的文档,用来描述参与者使用 系统完成某个事件时的事情发生顺序. 外部可见的系统功能单元,这些功能由系统单元 所提供,并通过一系列系统单元与一个或多个参 与者之间交换的消息所表达. 用例的用途是:在不揭示系统内部构造的前提下 定义连贯的行为. 不是需求或功能的规格说明,也是展示和体现其 所描述的过程中的需求情况.
2.2 用例图建模技术