用例图及用例分析
客户
电影信息查询
今日电影查询
主题电影查询
售票工作人员
系统管理人员
售票
维护会员信息
<
系统维护
日志维护
权限维护
增删用户
后台数据维护
<
<
<
个人信息查询
会员信息添加
会员信息修改
会员信息删除
管理电影信息
<
订购电影
电影校验
维护电影数据
<
电影信息添加
电影信息删除
电影信息修改
购票
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
重点用例分析
用例名称：售票
描述：售票工作人员使用系统销售用例完成售票的任务
标识符:uc1
优先级：A(高)
角色: 售票工作人员
前置条件：售票工作人员已成功登录系统并具有查询电影信息、售票的权限主事件流:
1. 售票工作人员选择售票选项，用例开始
2. 售票工作人员输入账号，系统根据规则检查账号的有效性
A1：售票工作人员账号无效
3. 售票工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．售票工作人员查询输入顾客所购买电影名称
6.系统根据输入的电影名，进入数据库调出电影单价，查询余票
7．售票工作人员扫描会员卡
A3：有会员卡
8. 显示电影总价格
9. 接受顾客付款，售票工作人员点击确认
10. 打印电影票
11. 用例结束
其他事件流：
A1:售票工作人员无效
(1).系统售票工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3：有会员卡
（1）.系统显示会员的具体信息，进行折扣计价。
（2）.跳至主事件流第8步
后置条件：系统成功将已售出的电影信息更新至数据库中
特殊需求：
用例名称：添加会员
描述：工作人员使用系统添加会员用例完成添加会员的任务
标识符:uc2
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限主事件流:
1. 工作人员选择添加会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击添加会员
6.系统进入数据库查询现有会员，生成新的会员号
7．工作人员录入会员信息
8. 显示最新会员信息
9. 接受顾客付款，工作人员点击确认
10. 制成会员卡
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
后置条件：系统成功将已添加的会员信息更新至数据库中
特殊需求：无
用例名称：删除会员
描述：工作人员使用系统删除会员用例完成删除会员的任务
标识符:uc3
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限
主事件流:
1. 工作人员选择删除会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击删除会员
6.输入会员账号
7. 系统进入数据库查询现有会员
A3：无此会员
8．工作人员点击删除
9. 显示确认删除提示
10. 工作人员点击确认
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此会员
(1). 系统显示无此会员的提示信息
(2). 返回主事件流第4步
后置条件：系统成功将已删除的会员信息移出至数据库中
特殊需求：无
用例名称：查询会员
描述：工作人员使用系统查询会员用例完成查询会员的任务
标识符:uc4
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限主事件流:
1. 工作人员选择查询会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击查询会员
6.输入会员账号
7. 系统进入数据库查询现有会员
A3：无此会员
8．工作人员点击查询
9. 显示查询会员的信息
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此会员
(1). 系统显示无此会员的提示信息
(2). 返回主事件流第4步
后置条件：无
特殊需求：无
用例名称：添加电影
描述：工作人员使用系统添加电影用例完成添加电影的任务
标识符:uc4
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限主事件流:
1. 工作人员选择添加电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击添加电影
6.系统进入数据库查询现有电影，生成新的电影号
7．工作人员录入电影信息
8. 显示最新电影信息
9. 点击确认
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
后置条件：系统成功将已添加的电影信息更新至数据库中
特殊需求：无
用例名称：删除电影
描述：工作人员使用系统删除电影用例完成删除电影的任务
标识符:uc5
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限主事件流:
1. 工作人员选择删除电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击删除电影
6.输入电影名
7. 系统进入数据库查询现有电影
A3：无此会员
8．工作人员点击删除
9. 显示确认删除提示
10. 工作人员点击确认
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此电影
(1). 系统显示无此电影的提示信息
(2). 返回主事件流第4步
后置条件：系统成功将已删除的会员信息移出至数据库中
特殊需求：无
用例名称：查询电影
描述：工作人员使用系统查询电影用例完成查询电影的任务
标识符:uc6
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限主事件流:
1. 工作人员选择查询电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击查询电影
6.输入电影名
7. 系统进入数据库查询现有电影名
A3：无此电影
8．工作人员点击查询
9. 显示查询会员的信息
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此电影
(1). 系统显示无此电影的提示信息
后置条件：无
特殊需求：无
用例名称：今日电影查询描述：顾客使用系统今日电影查询用例完成查询电影
标识符:uc7
优先级：A(高)
角色: 顾客
前置条件：无
主事件流:
1. 顾客选择今日电影查询选项，用例开始
2. 显示今日电影信息
3. 用例结束
其他事件流：无
后置条件：无
特殊需求：无
用例名称：个人信息查询描述：顾客使用系统个人信息查询用例完成个人信息查询标识符:uc8
优先级：A(高)
角色: 顾客
前置条件：顾客已成功登录系统
主事件流:
1. 顾客选择查询个人信息查询选项，用例开始
2. 顾客输入账号，系统根据规则检查账号的有效性
A1：顾客账号无效
3. 顾客输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5 显示顾客个人信息
6. 用例结束
其他事件流：
A1:顾客无效
(1).顾客无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
后置条件：无
特殊需求：无
用例名称：检索
描述：当功能界面中“请选择”输入3的时候进入检索功能
角色: 用户
前置条件：已经进行排序
主事件流:
1.用户选择检索功能，用例开始
A1：未完成前置条件
2. 用户选择检索条件，输入检索关键字
3. 系统根据输入信息查询文件
A2：检索失败
4.检索成功
5．将检索到的信息显示在屏幕上或存储在其他文件中
6. 用例结束
其他事件流：
A1：未完成前置条件
返回主菜单
A2：检索失败
返回搜索菜单
后置条件：系统成功将已检索的信息显示在屏幕或存储在文件中特殊需求：无
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。 当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。 用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。 用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor） 1．参与者的概念 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在 下面的人形图标表示。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。 参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。 第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。 第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
Requirement Analysis Specification 需求分析规格书 1版本更新記錄
目录 1版本更新記錄 (1) 2用例圖 (4) 3用例:GR _UC001創建收貨單 (4) 3.1用例活動圖 (4) 3.2參與者 (4) 3.3用例觸發事件 (5) 3.4用例概要 (5) 3.5用例流程詳述 (5) 4用例：GR_UC002召回收貨單 (8) 4.1用例活動圖 (8) 4.2參與者 (8) 4.3用例觸發事件 (8) 4.4用例概要 (8) 4.5用例流程詳述 (9) 5用例：GR_UC003沖銷收貨單 (9) 5.1用例活動圖 (9) 5.2參與者 (9) 5.3用例發生條件 (10) 5.4用例觸發事件 (10) 5.5用例概要 (10)
5.6用例流程詳述 (10) 6類圖Class Diagram (11) 6.1類圖 (11) 6.2系統主類 (11) 6.3其他公用類 (13) 7系統接口簡介 (13)
2 用例圖 3 用例:GR_UC001創建收貨單 3.1 用例活動圖 收貨單創建者：[Creater] 屬於變動角色，由具有[角色管控權限]的人指定。 2. 收貨單申請者：[Applicant] 發出收貨申請的人，其他人可以代替該角色起草[收貨單]。 3. [GA 總務] 4. 例外控制成員:[Exception Controller] Creater Applicant
屬於變動角色群體，由人為指定。如果[收貨單]被提交給[SAP系統]進行處理，出現失敗情況，則該角色會參與到[收貨單]創建過程，否則不參與。 3.3 用例觸發事件 1.在用例流程中，如果按鈕[Submit]被點選，則系統發送[通知郵件]給[Applicant]和 下一個關卡的[User]。 2.在用例流程中，如果按鈕[Approve]被點選，則系統發送[通知郵件]給下一個關卡的 [User]，如果點選該[Approve]按鈕的當前使用者是最後一個關卡，則系統發送[通知郵件]給[Submitter]和[Applicant]。(Submitter即點選[Submitt]按鈕者。) 3.在用例流程中，如果[Reject]按鈕被點選，則系統發送[通知郵件]給[Submitter]和 [Applicant]。(Submitter即點選[Submitt]按鈕者。) 3.4 用例概要 [Creater]根據實際需求起草[收貨單]，提交給[Applicant]進行審核。[Applicant]審核完畢以後，如果不同意該[收貨單]，則駁回[收貨單]，否則批准[收貨單]，[收貨單]被提交給[GA總務]進行審核，若審核未通過，則[採購單]被駁回，否則自動傳送至[SAP系統]，如果[SAP系統]處理失敗，則[收貨單]被提交給[Exception Controller]審核，若審核未通過則[採購單]被駁回，否則重新傳送至[SAP系統]。如果[SAP系統]對[收貨單]處理成功，則[創建收貨單]流程結束。 3.5 用例流程詳述 4.[Creater]進入系統登陸認證模塊，成功登入[E-Procurement]系統。(請參閱 SB::UI003) 5.[Creater]在[主菜單]的[Apply Forms]下拉菜單中點選[Goods receipts]選項，進入 [Goods receipts Application]畫面。用例流程開始。(請參閱SB::UI004~UI::005) 6.在[GR No.]欄位將自動生成一個[流水號]。該序列號是一個以[0000000001]開始的十 位連續[序列號]。 7.在[Issued Date]欄位將默認顯示當前日期和時間。 8.在[Submitter]欄位將顯示登錄人的姓名和工號。 9.在[Status]欄位默認顯示狀態為[Draft]。 10.[Creater]點選欄位[Applicant]，在彈出的對話框中選擇[申請人]，默認顯示為 [Submitter]的信息。 11.[Creater]點選欄位[Posting Date]，在彈出的日期選擇框中選擇過帳日期。 12.[Creater]在[Declaration No.]欄位填入[報關單號]。 13.[Creater]點選欄位[Posting to]，在彈出的對話框中選擇[Company Code]。 14.[Creater]填入[Subject]。 15.[Creater]點選按鈕[Add]，新建[採購單]，將開啟[Goods Receipts Line]畫面。該 畫面以Layer方式呈現，并覆蓋整個視窗。(請參閱SB::UI006)
我们应当怎样做需求分析：功能角色分析与用例图(转) 在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。 但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。 需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。 对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。 一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。
什么是用例 用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。 1. 什么是用例？ 在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式： 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。 功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS 文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。 1.1 参与者和用例 从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：
用例图及用例分析 客户 电影信息查询 今日电影查询 主题电影查询 售票工作人员 系统管理人员 售票 维护会员信息 <
重点用例分析 用例名称：售票 描述：售票工作人员使用系统销售用例完成售票的任务 标识符:uc1 优先级：A(高) 角色: 售票工作人员 前置条件：售票工作人员已成功登录系统并具有查询电影信息、售票的权限主事件流: 1. 售票工作人员选择售票选项，用例开始 2. 售票工作人员输入账号，系统根据规则检查账号的有效性 A1：售票工作人员账号无效 3. 售票工作人员输入密码，检查密码是否正确 A2：密码错误 4．显示登录成功提示信息 5．售票工作人员查询输入顾客所购买电影名称 6.系统根据输入的电影名，进入数据库调出电影单价，查询余票 7．售票工作人员扫描会员卡 A3：有会员卡 8. 显示电影总价格 9. 接受顾客付款，售票工作人员点击确认 10. 打印电影票 11. 用例结束 其他事件流： A1:售票工作人员无效 (1).系统售票工作人员无效的提示信息 (2).返回主事件流第2步 A2:密码错误 (1). 系统显示密码错误的提示信息 (2). 返回主事件流第3步 A3：有会员卡 （1）.系统显示会员的具体信息，进行折扣计价。 （2）.跳至主事件流第8步 后置条件：系统成功将已售出的电影信息更新至数据库中 特殊需求：
基于UML用例图的系统需求分析 一、UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。 二、用例建模简介 用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为，图示化系统的主事件流程。 用例图主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。 ●用例图 包含了用例Use Case）和参与者（Actor）。用例之间用关联来连接，以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。 ●用例描述 用来详细描述用例图中每个用例，用文本文档来完成。 三、用例图说明 ●参与者 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 ●用例