用例和用例图

UML用例和用例图

h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说，详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足

用例及用例图案例

第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、客房入住、退房结帐、旅客信息查询几个方面的功能。
第3章用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？

用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互的动作序列的说明, 包括可选的动作序列和会出现异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约, 软件开发过程是用例驱动的.
实例1：图书馆管理系统中的用例图
1.确定系统涉及的总体信息图书馆管理系统是对书籍的借阅及读者信息进行统一管理的系统，具体包括读者的借书、还书，书籍预订；图书馆管理员的书籍借出处理、书籍归还处理、预订信息处理；还有系统管理员的系统维护，包括增加书目、删除或更新书目、增加书籍、减少书籍、增加读者账户信息、删除或更新读者账户信息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票购买者将可以自主选择是通过人工座席还是自动语音登录网站预订机票，那么谁是参与者？

用例和用例图

第一页，编辑于星期二：十三点五十六分。
第二页，编辑于星期二：十三点五十六分。
第三页，编辑于星期二：十三点五十六分。
第四页，编辑于星期二：十三点五十六分。
第五页，编辑于星期二：十三点五十六分。
第六页，编辑于星期二：十三点五十六分。
第七页，编辑于星期二：十三点五十六分。
第八页，编辑于星期二：十三点五十六分。
第二十三页，编辑于星期二：十三点五十六分。
第二十四页，编辑于星期二：十三点五十六分。
第二十五页，编辑于星期二：十三点五十六分。
第二十六页，编辑于星期二：十三点五十六分。
第二十七页，编辑于星期二：十三点五十六分。
第二十八页，编辑于星期二：十三点五十六分。
第二十九页，编辑于星期二：十三点五十六分。
第十六页，编辑于星期二：十三点五十六分。
第十七页，编辑于星期二：十三点五十六分。
第十八页，编辑于星期二：十三点五十六分。
第十九页，编辑于星期二：十三点五十六分。
第二十页，编辑于星期二：十三点五十六分。
第二十一页，编辑于星期二：十三点五十六分。
第二十二页，编辑于星期二：十三点五十六分。
第三十页，编辑于星期二：十三点五十六分。
第三十一页，编辑于星期二：十三点五十六分。
第三十二页，编辑于星期二：十三点五十六分。
第三十三页，编辑点五十六分。
第九页，编辑于星期二：十三点五十六分。
第十页，编辑于星期二：十三点五十六分。
第十一页，编辑于星期二：十三点五十六分。
第十二页，编辑于星期二：十三点五十六分。
第十三页，编辑于星期二：十三点五十六分。
第十四页，编辑于星期二：十三点五十六分。

第05讲用例分析与用例图

基于用例的需求分析过程
获取原始需求
开发一个可以理解的需求
识别参与者
识别用例
确定关系
55/ 55
思考
软件
工基于用例的需求分析过程可大致分几步？程什么是系统边界
用例的概念用例的关系参与者的定义与关系
56/ 55
软实验06
件工
画出系统用例图
程注意用例的粒度与关系
软用例粒度-3
件 “四轮马车”
工程
C(Create)
R(Read)
U(Update)
D(Delete)
所有业务最终会成为CRUD？
CRUD能为Actor提供价值？
CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查”
关心数据的存储和维护，反而忽略了用户的目的
36
用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图、活动图或非正式的文字描述来表示
25/55
用例的命名
软
件执行者视角：
工
程（状语）动词+（定语+ ）宾语
顾客
购买商品 <<extend>> 信用卡支付
26/55
识别用例
软
件工
识别用例
程关键词：价值
12/ 55
用例与用例关系
软
件工
用例图
程
参与者
用例
用例关系
13/ 55
软用例图
件工程
获取需求、指导测试、对过程中的其他工作流起指导作用
14/ 55
参与者
软件
工参与者，Actor

实验报告1--用例和用例图

中北大学软件学院实验报告
专业：软件工程
方向：软件开发与测试
课程名称： UML
班级：
学号：
姓名：
辅导教师：井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验，我掌握了在课堂上学习的用例图等。

加深了对书本知识的认识和记忆。

在实验中我学会了去如何操作ro se工具图。

通过ro se工具图，可以去清晰的去展示一个关系等。

使用非常方便。

用例和用例图统一建模语言

UML用例图的建模(续)
Record grades Update grades Generate cards
Distribute report cards
View grades
UML用例图的建模(续)
2、区分用例优先次序
这项任务通常是由系统分析人员完成，他们对哪一项任务最关键，哪一项任务最艰巨有最好的全局认识。他们还可以确定出哪个用例可以为其他用例所重用。在上例中，可以提出以下优先次序列表：
UML的用例图标
UML用例图组成(续)
3、用例图的关联 1)角色与用例的关联角色与用例的关联表示角色与用例相关性。在UML中是使
用一条实线连接角色与用例，如下图所示。
UML用例图组成(续)
成绩管理
UML用例图组成(续)
2）角色与角色的关联
角色与角色的关联用来表示一般角色与特殊角色的泛化关系。在UML图中，使用带空心三角箭头的实线表示。如下图所示：
用例图在各种开发活动中被广泛使用,但它最经常用做描述系统以及子系统.
UML用例图的作用(续)
• 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步.
第二章用例和用例图
(4) 统计
①经理能够使用系统的统计功能，了解商品销售情况、库存情况、供应商情况，以便进行合理的营销策略。 ②经理按市场情况适时变动商品价格。
案例----超市进销存系统用例图建模
2.建立超市进销存系统的用例图模型
在系统需求分析中需考虑：系统用例图模型需要哪些视图，每个视图包含什么内容？视图中成员是否需构成包？

用例和用例图

访客用例图
会员用例图
书店管理员用例图
3、用例描述（1）细化用例描述----搭框架

用例名称：搜索图书概述：用户根据关键字搜索图书前置条件：无事件流：基本事件流扩展事件流后置条件: 无
3、用例描述（2）细化用例描述----填＂血肉＂

事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息，并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返回基本事件流2。

编写用例描述应遵循以下几点：

使用简单的语法，主语明确，语义易于理解；在事件流描述中让读者直观地了解是参与者在控制还是系统在控制；从第三者观察的角度指出参与者的动作，以及系统的响应；显示参与者的意图而非动作显示过程向前推移，每一步都有前进感；

构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为命名。将多个用例的公共的行为抽取出来放到一个被包含用例中。对于变化部分，将其抽取出来，放到扩展用例中。清晰的描述事件流。

扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例（扩展用例）的行为。基本用例不知道扩展用例的任何细节，没有扩展用例，基本用例是完整的。只有在特定条件下，它的行为可以被扩展用例的行为扩展，因此扩展关系处理事件流的异常或者可选事件。