用例图及用例分析
第3章用例及用例图-案例学习资料
● ① 找出系统外部参与者，确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
① 管理员选择进入管理界面，用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1：密码出错。
⑤ 进入管理界面，系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程，管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1：
– 有一个爱书之人，家里各类书籍已过千册，平时又 时常有朋友外借，因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号，以修改信息，但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录，可对外借情况列出打印。另外，还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
需求分析-用例图-用例规约
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
用例及用例图案例
用例及用例图-案例
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) 什么叫事件流,作用是什么？
第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
图书管理系统(用例图、类图、时序图)
软件系统分析与设计实验报告学院：计算机科学与技术学院专业：软件工程学号：*********姓名：***实验名称：图书管理系统用例建模时间：一、实验内容与要求本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。
在使用UML对系统建模时，学会使用UML建模工具，熟悉工具中的功能。
二、用例分析1、读者“借书还书系统”用例图(f还书(from Use Cases)1．1、行为者：主要行为者：读者。
1．2、前置条件：读者进入图书管理系统。
1．3、事件流：、主要事件流：：读者检索所需图书信息，并查看；：读者检索到所需图书，登录系统，开始借书；：系统查询图书信息，图书数目是否可借；：图书显示可借，借书成功；：图书显示不可借，借书失败；：进入续借图书界面，续借图书；：系统查看预约记录，：没有冲突，续借成功；：有冲突，续借失败；：：读者归还图书；：归还时间没有逾期，归还成功；：归还时间逾期，逾期处罚，归还成功；、备选事件流：：图书检索信息失败，未检索到图书，重新输入信息检索；：未曾检索到用户检索的图书，系统显示相关联的信息的图书；：用户名或密码输入错误，登录系统失败，重新输入用户名或密码登录；：系统显示图书不可借后，进入图书预约界面，输入信息预约图书；、异常事件流：：读者登录系统失败，未曾注册用户；：返回系统注册用户后，重新登录。
1．4、后置条件：退出系统。
1．5、1．6、扩展点：无。
2、“图书信息管理系统”用例图新书信息录入(f逾期通知(from Use Cases)(from Use Cases)2．1、行为者：主要行为者：管理员；2．2、前置条件：管理员打开图书信息管理系统；2．3、事件流：：主要事件流：：图书管理员输入管理员登录信息，登录系统；：进入图书信息管理界面，查看已有图书信息，是否有需要购入图书；：录入新购进图书信息，并确认；：进入读者信息管理界面，管理已有用户信息；：进入信息通知界面，查看已有用户图书借阅、预约情况；：查看读者所预约图书，自动查询图书信息，确认是否已有可借图书，有则通知读者；：查询读者已借图书信息，根据已借时间及归还时间分类；：所借图书即将逾期，启动系统提醒功能；：所借图书已经逾期，启动逾期及处罚通知功能；：备选事件流：：管理员用户名或登录名错误，重新登录；：需要购进新图书，存储信息，通知相关人员；：读者预约图书没有可借图书，不予通知；：预约通知提醒后，删除该预约记录；：读者所借图书距离归还时间仍很久，无需通知；：异常事件流：：登录失败超过一定次数后，系统冻结该用户名，一段时间后可以重用；2．4、后置条件：退出系统；2．5、扩展点：无。
UML中的业务用例图的绘制方法和实例分析
UML中的业务用例图的绘制方法和实例分析UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规则，用于描述系统的结构、行为和交互。
其中，业务用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。
本文将介绍业务用例图的绘制方法，并通过一个实例分析来说明其应用。
一、业务用例图的绘制方法业务用例图主要由参与者（Actor）和用例（Use Case）两个元素组成。
参与者是系统外部的角色，可以是人、其他系统或外部设备等，用例则是描述系统功能的场景。
下面是绘制业务用例图的步骤：1. 确定参与者：首先要明确系统与外部世界的交互角色，这些角色可以是系统的用户、其他系统或外部设备等。
2. 确定用例：根据系统的功能需求，确定系统需要提供的各个功能场景，每个场景都可以作为一个用例。
3. 绘制参与者和用例：使用UML中的图形符号，将参与者和用例绘制在图中。
参与者通常用人的图标表示，用例则用椭圆形表示。
4. 连接参与者和用例：使用关联线将参与者与用例连接起来，表示参与者与用例之间的交互关系。
一般来说，参与者可以触发用例的执行，也可以接收用例的输出。
5. 添加关系：根据实际情况，可以添加其他关系，如扩展关系、包含关系等，以更准确地描述系统的功能和交互。
二、实例分析为了更好地理解业务用例图的应用，下面以一个在线购物系统为例进行分析。
在这个系统中，主要涉及的参与者有顾客和管理员。
顾客可以进行商品浏览、商品搜索、添加商品到购物车、结算购物车等操作，管理员则可以进行商品管理、订单管理等操作。
根据上述分析，我们可以绘制如下的业务用例图：（图示：一个包含顾客、管理员和相关用例的业务用例图）从图中可以看出，顾客和管理员是系统的两个主要参与者，它们与系统之间存在着不同的交互。
顾客可以通过浏览商品和搜索商品来获取所需的商品信息，然后将商品添加到购物车，并最终结算购物车。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
权限管理用例图及用例分析
管理员提交表单数据格式错误,系统提示错误信息
系统将数据写入数据库时失败,提示错误信息后置条件:无源自注释:无用例图用例描述
用例编号:006
用例名称:权限管理
优先级别：HIGH
参与者:管理员 一般用户
用例描述:
权限管理
前置条件:
1．用户成功登陆系统
基本事件流:
在权限管理的页面上，输入新员工信息
点击提交按钮
员工信息被修改、删除或被导出 个人可以查看自己的信息 登录
系统给出提示
其他事件流:
管理员在执行基本事件流过程中点击”取消”按钮,系统关闭表单页
02-用例和用例图
使用用例时注意的问题:
1. 2. 3. 4. 不要将所有的需求都以用例的形式表示出来. 不要将所有的需求都以用例的形式表示出来 用例只描述系统功能性方面的需求, 它只是全部需求的一部分. 用例只描述系统功能性方面的需求 它只是全部需求的一部分 本质上用例分析是功能分解技术, 但目前是OO开发的第一步 开发的第一步. 本质上用例分析是功能分解技术 但目前是 开发的第一步 用例是与实现无关的关于系统功能的描述. 用例是与实现无关的关于系统功能的描述
(2) 储户按“取款”按钮 并输入 • 设置交易类型为“取款” 储户按“取款”按钮,并输入 设置交易类型为“取款” 取款数目 • ATM系统获得取款金额 系统获得取款金额 (3) 储户取走现金 储户取走现金/ATM卡/收据 卡 收据 • 输出现金、收据和 输出现金、收据和ATM卡 卡 (4) 储户离开 只描述了actor的行为 的行为 只描述了 • 系统复位 只描述了System的行为 的行为 只描述了
3.4.2 包含关系
包含关系是指一个用例(基本用例 的行为包含了另一 包含关系是指一个用例 基本用例)的行为包含了另一 基本用例 个用例(包含用例 的行为. 包含用例)的行为 个用例 包含用例 的行为 包含关系是依赖关系的版型, 但其含义更多. 包含关系是依赖关系的版型 但其含义更多
右图的例子演示了 包含关系
常见问题分析
(1) 用例的粒度问题 对于一个目标系统进行用例分析后得到的用 例数目有多少比较合适? 例数目有多少比较合适
常见问题分析
(2) 用例的分解 合并 用例的分解/合并 系统中相似的功能, 系统中相似的功能 是合并为一个用例还是 分解为几个用例? 分解为几个用例
用例的描述
用例的描述格式(续表 用例的描述格式 续表) 续表
软件工程课件之第4章用例和用例图
4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
第5讲2-用例及用例图
a 经过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者（actor）是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系：
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系，表达参加者与用
例之间具有使用，交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间，用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间，一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统，建立本学期 要开设旳多种课程，将课程信息保存到数据库中， 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统，选择课程：能够 查询课程，选择课程，支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者，拟定系统边界和范围。
第3章用例和用例图
3.1 用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译 名有: 用况、用案等. 它是站在用户的角度看待系统、 定义系统 ；使用用户能够看懂的语言来表述
定义1: 用例是对一个活动者(actor，角色，参与者)使用 系统的一项功能时所进行的交互过程的一个文字描述序 列. 定义2: 用例是系统、子系统或类和外部参与者交互的动 作序列的说明, 包括可选的动作序列和会出现异常的动 作序列. 用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约, 软件开发过程是用例驱动的.
18
面向对象分析与设计 & UML
3.4.1 泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子 用例也可以增加新的行为和含义或覆盖父用例中的行 为和含义.
右图的例子演示了 泛化关系
19
面向对象分析与设计 & UML
3.4.1 泛化关系
•
可以用来表示参与者与参与者之间，用例与用例之间的 特殊/一般化关系
33
面向对象分析与设计 & UML
3.6 用例的描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了主路径外, 其它路径是什么 用例结束后系统的状态 其它需要描述的内容
描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在 开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
用例分析文档模板
文档名称版本<1.0 >文档属性及版本目录1 用例：<用户登录> (4)1.1用例图 (4)1.2简要说明 (4)2 事件流 (4)2.1基本流 (4)2.2备选流 (4)3 用例场景 (5)3.1成功场景 (5)3.2失败场景 (5)4 特殊需求 (5)4.1总体要求 (5)4.2用例要求 (5)5 前置条件 (5)6 后置条件 (5)7 扩展点 (5)7.1新用户注册 (5)1用例：<用户登录>1.1用例图1.2简要说明此用例主要描述XXXXXX系统的用户登录。
由于XXXXXX系统是基于用户许可授权访问的系统，在用户访问该系统时，首先要通过合法的用户身份验证，其次要控制用户对系统资源的访问权限。
根据XXXXXX系统的实际应用需求，该系统的用户分为两种类型：一种是一般用户，另一种是特殊用户。
不同类型的用户具有不同的访问权限。
2事件流用户在浏览器地址栏输入系统的URL（网址），该用例启动。
2.1基本流1．进入登录页面如果用户没有通过身份验证，则在浏览器地址栏内访问任何一个页面的URL都自动进入登录页面。
2．输入用户名和密码系统提示用户名和密码必须输入。
用户名符合数据结构要求，密码符合密码长度以及复杂度等要求。
3．选择“登录”操作系统验证用户输入数据的合法性，进而验证是不是合法的系统用户以及用户的权限（一般用户、特殊用户）。
4．进入系统主页面。
2.2备选流A1.用户和密码输入在基本流的步骤3，提示用户输入合法的用户名和密码。
A2.用户或密码错误在基本流的步骤3中，用户输入的用户名或者密码错误，提示用户重新输入。
然后继续执行基本流的步骤3。
三次输入用户名和密码无效后，该用户被锁定，用例结束。
A3.退出系统无条件关闭浏览器。
用例结束。
3用例场景3.1成功场景登录成功：基本流取消操作：备选流，退出系统。
3.2失败场景没有输入用户和密码：备选流，用户和密码输入。
输入用户或密码错误：备选流，用户或密码错误。
权限管理用例图及用例分析
其他事件流:
管理员在执行基本事件流过程中点击”取消”按钮,系统关闭表单页
异常事件流:
管理员提交表单数据格式错误,系统提示错误信息
系统将数据写入数据库时失败,提示错误信息
后置条件:
无
注释:无
管理员提交表单数据格式错误系统提示错误信息系统将数据写入数据库时失败提示错误信息后置条件
用例图
用例描述
用例编号:006
用例名称:权限管理
优先级别：HIGH
参与者:管理员 一般用户
用例描述:
权限管理
前置条件:
1．用户成功登陆系统
基本事件流:
在权限管息被修改、删除或被导出 个人可以查看自己的信息 登录
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击添加会员
6.系统进入数据库查询现有会员，生成新的会员号
7．工作人员录入会员信息
8.显示最新会员信息
9.接受顾客付款，工作人员点击确认
10.制成会员卡
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
6.系统进入数据库查询现有电影，生成新的电影号
7．工பைடு நூலகம்人员录入电影信息
8.显示最新电影信息
9.点击确认
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
后置条件：系统成功将已添加的电影信息更新至数据库中
10.打印电影票
11. 用例结束
其他事件流：
A1:售票工作人员无效
(1).系统售票工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3：有会员卡
（1）.系统显示会员的具体信息，进行折扣计价。
（2）.跳至主事件流第8步
后置条件：系统成功将已售出的电影信息更新至数据库中
主事件流:
1. 工作人员选择删除会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击删除会员
6.输入会员账号
7.系统进入数据库查询现有会员
A3：无此会员
8．工作人员点击删除
后置条件：系统成功将已删除的会员信息移出至数据库中
特殊需求：无
用例名称：查询会员
描述：工作人员使用系统查询会员用例完成查询会员的任务
标识符:uc4
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限
主事件流:
1. 工作人员选择查询会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
特殊需求：
用例名称：添加会员
描述：工作人员使用系统添加会员用例完成添加会员的任务
标识符:uc2
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限
主事件流:
1. 工作人员选择添加会员选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此会员
(1). 系统显示无此会员的提示信息
(2). 返回主事件流第4步
后置条件：无
特殊需求：无
用例名称：添加电影
描述：工作人员使用系统添加电影用例完成添加电影的任务
标识符:uc4
优先级：A(高)
5．工作人员点击查询电影
6.输入电影名
7.系统进入数据库查询现有电影名
A3：无此电影
8．工作人员点击查询
9.显示查询会员的信息
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
3. 顾客输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5 显示顾客个人信息
6. 用例结束
其他事件流：
A1:顾客无效
(1).顾客无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
后置条件：无
特殊需求：无
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
后置条件：系统成功将已添加的会员信息更新至数据库中
特殊需求：无
用例名称：删除会员
描述：工作人员使用系统删除会员用例完成删除会员的任务
标识符:uc3
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加会员的权限
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击查询会员
6.输入会员账号
7.系统进入数据库查询现有会员
A3：无此会员
8．工作人员点击查询
9.显示查询会员的信息
10. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
标识符:uc6
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限
主事件流:
1. 工作人员选择查询电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
其他事件流：无
后置条件：无
特殊需求：无
用例名称：个人信息查询
描述：顾客使用系统个人信息查询用例完成个人信息查询
标识符:uc8
优先级：A(高)
角色: 顾客
前置条件：顾客已成功登录系统
主事件流:
1. 顾客选择查询个人信息查询选项，用例开始
2. 顾客输入账号，系统根据规则检查账号的有效性
A1：顾客账号无效
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限
主事件流:
1. 工作人员选择添加电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击添加电影
A3:无此电影
(1). 系统显示无此电影的提示信息
(2). 返回主事件流第4步
后置条件：无
特殊需求：无
用例名称：今日电影查询
描述：顾客使用系统今日电影查询用例完成查询电影
标识符:uc7
优先级：A(高)
角色: 顾客
前置条件：无
主事件流:
1. 顾客选择今日电影查询选项，用例开始
2. 显示今日电影信息
3. 用例结束
3. 工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．工作人员点击删除电影
6.输入电影名
7.系统进入数据库查询现有电影
A3：无此会员
8．工作人员点击删除
9.显示确认删除提示
10.工作人员点击确认
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
9.显示确认删除提示
10.工作人员点击确认
11. 用例结束
其他事件流：
A1:工作人员无效
(1).系统工作人员无效的提示信息
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此会员
(1). 系统显示无此会员的提示信息
(2). 返回主事件流第4步
用例图及用例分析
重点用例分析
用例名称：售票
描述：售票工作人员使用系统销售用例完成售票的任务
标识符:uc1
优先级：A(高)
角色: 售票工作人员
前置条件：售票工作人员已成功登录系统并具有查询电影信息、售票的权限
主事件流:
1. 售票工作人员选择售票选项，用例开始
2. 售票工作人员输入账号，系统根据规则检查账号的有效性
特殊需求：无
用例名称：删除电影
描述：工作人员使用系统删除电影用例完成删除电影的任务
标识符:uc5
优先级：A(高)
角色: 工作人员
前置条件：工作人员已成功登录系统并具有查询、修改和添加电影的权限
主事件流:
1. 工作人员选择删除电影选项，用例开始
2. 工作人员输入账号，系统根据规则检查账号的有效性
A1：工作人员账号无效
(2).返回主事件流第2步
A2:密码错误
(1). 系统显示密码错误的提示信息
(2). 返回主事件流第3步
A3:无此电影
(1). 系统显示无此电影的提示信息
(2). 返回主事件流第4步
后置条件：系统成功将已删除的会员信息移出至数据库中
特殊需求：无
用例名称：查询电影
描述：工作人员使用系统查询电影用例完成查询电影的任务
A1：售票工作人员账号无效
3. 售票工作人员输入密码，检查密码是否正确
A2：密码错误
4．显示登录成功提示信息
5．售票工作人员查询输入顾客所购买电影名称
6.系统根据输入的电影名，进入数据库调出电影单价，查询余票
7．售票工作人员扫描会员卡
A3：有会员卡
8.显示电影总价格
9.接受顾客付款，售票工作人员点击确认