用例规约+活动图例子
ROSE用例图与活动图示例
2.3.4 使用Rational Rose 绘制用例模型
• 通信关系定义对话框
2.3.4 使用Rational Rose 绘制用例模型
• 依赖关系定义对话框
2.3.4 使用Rational Rose 绘制用例模型
• “车辆管理系统用例图”最终结果
2.3.4 使用Rational Rose 绘制用例模型
它的作用域不仅限于支持面向对象的分析与设计还支持从需求分析开始的软件开发的全过21uml22uml用例图描述的是参与者actor所理解的系统功能用于需求分析阶段列出系统中的用例和参与者并显示哪个参与者参与了哪个用例的执行下面通过uml来分析并构造车辆管理系统模型主要找出系统中所有的用例以及对用例进行说明还需要和车辆管理信息系统的潜在用户进行讨论图形使用visio及rationalrose工具软件绘制用例建模可分为用例图和用例描述
2.2.1 用例图
• 下面通过UML来分析并构造车辆管理系 统模型，主要找出系统中所有的用例， 以及对用例进行说明，还需要和车辆管 理信息系统的潜在用户进行讨论，图形 使用Visio及Rational Rose 工具软件绘制
2.3.1 用例图
• 用例建模可分为用例图和用例描述。用 例图由参与者（角色）、用例（Use Case）、系统边界、箭头组成，用画图 的方法来完成。
2.1 基于UML的用例模型实验
• UML特点：
– – – – 面向对象 可视化 独立与开发过程 程序设计语言以及易于掌握使用
2.2 基于UML的用例模型实验
• 2.2.1 用例图
用例图描述的是参与者（Actor）所理解的系 统功能，用于需求分析阶段，列出系统中的用 例和参与者，并显示哪个参与者参与了哪个用 例的执行
江苏联通物资管理系统2(1)
3.4.2 入库管理分析入库管理主要就是指企业的仓库管理人员对公司采购的原材料以及生产资料进行管理，需要进行信息的输入，信息输入之后还需要进行审核，最终保存的必须是有效的信息，这样可以提高工作的效率以及工作的正确率。
在物资进行入库的时候一定要进行信息的准确填写，其次要经过相关部门的审核，只有经过上述的步骤之后才可以将物资进行入库。
入库时信息参数要保证一定的完整性，这样可以提高工作的效率以及仓库的利用率和减少企业运营的成本。
如表3.1所示为入库管理用例分析。
表3.1 入库管理用例规约江苏联通公司物资管理系统的日常物资入库工作由入库管理员来完成，其他用户不具备权限，入库流程主要包括以下几个主要步骤：1、入库管理员登录系统；2、录入采购的物资；3、对物资检查无误后提交数据库保存。
除了新采购的物资需要入库以外，外借的物资在归还时也要进行审核入库。
江苏联通公司物资入库活动如图3.2所示。
图3.2 物资入库活动图3.4.3 出库管理分析物资在以下两种情况下需要进行出库，一是对生产原材料的领取，二是物资借出的时候，在出库的时候对物资的信息要进行详细的输入，同时还要进行信息审核以保证输入的信息是有效的，在出库的时候要保证有着足够的凭据来进行出库管理。
出库管理的操作人员是出库管理员，用例规约如表3.2所示。
表3.2 出库管理用例规约江苏联通公司物资出库活动图如图 3.3所示。
出库情况一般为两种，一种是物资领用，一种是物资借出，物资借出需进行审核，审核通过进行物资的发放。
图3.3 物资出库活动图3.4.4 统计管理分析统计管理模块主要的功能就是对货物流转的过程进行统计。
对于公司物资的管理情况的统计可以极大的缩短工作的时间，进而可以提高工作的效率，统计管理模块可以有效的解决这一问题。
使用这一模块可以很好的为物资的管理带来方便，同时会使得公司的管理层对于公司的物资有一个清晰准确的掌握，这对辅助决策是有很大意义的。
统计的过程中会有各种不同环节统计。
用例规约(实例)
课程注册系统用例规约版本<1.0>查看成绩报告卡用例1.简要说明本用例允许学生查看他（她）刚结束学期的成绩报告卡。
本用例的Actor 是学生。
2.事件流当学生从主表格中选择“查看成绩报告卡”活动时，用例开始。
1.基本流—查看成绩报告卡1.系统检索出学生上个学期所修完的每门课程的成绩信息。
2.系统准备、排版并显示成绩信息。
3.当学生完成查看成绩信息后，选择“关闭”。
2.备选流1.没有可以查看的成绩信息如果在基本流中，系统不能找到这个学生上个学期的任何成绩信息，将会显示一个消息。
学生确认这条消息后，用例终止。
3.特殊需求没有和本用例有关的特殊需求。
4.前置条件1. 登录在本用例开始之前，学生要登录到系统。
5.后置条件没有和本用例有关的后置条件。
6.扩展点没有和本用例有关的扩展点。
课程注册用例1. 简要说明此用例允许学生登记当前学期的课程。
如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。
课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。
课程目录系统是用例中包含的一个主角。
2. 事件流当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。
1. 基本流—创建课程表1.学生选择“创建课程表”。
2.系统会显示一张空白课程表。
3.系统从课程目录系统中检索可选课程的列表。
4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。
在完成选择后，学生选择“提交”。
5.在此步骤中为每一门所选课程执行“添加课程”子流程。
6.系统保存该课程表。
2. 备选流1. 修改课程表1.学生选择“修改课程表”。
2.系统检索并显示学生现在的课程表（例如，本学期的课程表）。
3.系统从课程目录系统中检索本学期所有可选课程的列表。
系统向学生显示该列表。
4.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
用例文档及活动图
活动图
定义活动图
活动图的符号
一个活动图必然有一个开始状态
至少有一个结束状态
转移用来表示活动或状态间的控 制流
有分支时要在分支路径中注明分 支条件
分岔用来开始并行处理 联结用于把并行处理转换为
单个处理
活动图
定义活动图
ATM机“登录”用例的活动图
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
“增加预约”示例
➢ 示例一：“掌上校园” ➢ 示例二：“网络教学平台”
重构用例
如果你对以下问题都回答“是”的话，那么这个用 例就是集中的。否则，这个用例需要拆分为几个小 的
这个用例是否能够带来一个独立的好处？ 你是否可以利用２０个字来描述这个好处，且不用“和”，“与” 参与者是否能够仅通过在一次会话就完成这个用例 你能否想象在一个连贯的测试计划中，这个用例将是一个测试用例
前置条件 参与者启动这个用例之前必须完成的所有用例。
后置条件 包括这个用例对系统所做的所有改变。
部署约束 描述访问这个用例的所有约束
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
一个事件流仅描述用例中的一条路径，不包括其他的分支。
在用例中有三种事件流：
正常事件流：通过描述一切都按部就班时的情况来捕捉用 例的目标。
绩 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) 什么叫事件流,作用是什么？
第05讲用例规约
用例规约：记录时间(续)
前置条件： 后置条件：
用户必须已经登录到这个系统 系统将雇员的工时正确的记录到数 据库中
用例规约：记录时间(续)
正常事件流：
1.雇员查看当前时间之前输入的数据； 2.雇员从已有的支付号码中选择一个， 这些收费代码是按客户和项目组织 的； 3.雇员从当前的时间段选择一个日期； 4.雇员输入以正整数表示的工时； 5.系统在视图中显示这个数据，并在 以后的视图中看到这个数据。
3. 受益人及其利益：
3. 公司：需要精确地记录交易并满 足客户的利益。需要支付授权服 务记录可接受的支付。需要一些 容错功能。需要账目和存货清单 得到自动的快速更新
正式型（详细型）-处理销售3
3. 受益人及其利益：
5. 政府税务机构：需要从每一次销售 中收税。 6. 支付授权服务：需要用正确的格式 和协议传来的数字授权请求。需要 精确计算它们可支付给商店的款额
把它们看做是看门人， 它阻止参与者触发该用 例直到满足所有条件 说明在用例触发之前 什么必须为真
后置条件
后置条件约束用 例执行后系统的状 态
用例执行后什么 必须为真 对于有多个事件 流的用例，则应该 有多个后置条件
前置、后置条件注意
某些用例依赖于其他用例
一个用例在离开系统时，可能是另一个 用例的前置条件（例如：“登录”和“管理 系统”）
正式型（详细型）-扩展1
1. 在系统失败时，要恢复和校正账 目，确保所有的交易敏感状态以 及事件能够从场景的任何步骤中 恢复
1. 出纳员重启系统和登录，并请求恢 复先前的状态
正式型（详细型）-扩展2
2. 系统重建先前的状态
系统检测阻止恢复的异常状态 1. 系统给出纳员发出一个出错信号，记 录该错误并进入一个干净的状态 2. 出纳员开始一次新的销售
UML中的活动图实践案例
UML中的活动图实践案例在软件开发过程中，使用统一建模语言（UML）可以帮助开发人员更好地理解和设计软件系统。
其中，活动图是一种非常有用的工具，可以描述系统中的业务流程和操作流程。
本文将通过一个实践案例，详细介绍如何使用活动图来建模和分析系统的业务流程。
案例背景假设我们正在开发一个在线购物系统。
该系统允许用户浏览商品、选择商品、下订单并支付。
为了更好地理解和设计该系统，我们将使用活动图来描述用户购物的整个流程。
活动图的基本元素在开始建模之前，让我们先来了解一下活动图的基本元素。
活动图由以下几个主要元素组成：1. 动作（Action）：表示系统执行的基本操作，例如发送电子邮件、生成报告等。
2. 控制流（Control Flow）：表示活动图中的控制流程，即动作之间的顺序关系。
3. 决策节点（Decision Node）：表示在不同条件下的流程分支，类似于编程语言中的if语句。
4. 合并节点（Merge Node）：表示流程分支的合并点，类似于编程语言中的else语句。
5. 初始节点（Initial Node）：表示活动图的起点。
6. 终止节点（Final Node）：表示活动图的终点。
建模过程现在让我们开始建模购物系统的活动图。
1. 首先，我们需要定义系统的起点和终点。
在活动图中，起点用一个带有黑色实心圆圈的初始节点表示，终点用一个带有黑色实心圆圈的终止节点表示。
2. 接下来，我们需要定义用户浏览商品的流程。
用户打开购物系统后，系统将显示所有可用的商品。
用户可以通过滚动或搜索来浏览商品。
在活动图中，我们可以使用动作来表示这些操作，并使用控制流来表示它们之间的顺序关系。
3. 用户选择商品后，系统将显示商品的详细信息。
用户可以查看商品的图片、描述、价格等信息。
在活动图中，我们可以使用动作来表示这些操作，并使用控制流来表示它们之间的顺序关系。
4. 用户选择完商品后，系统将允许用户下订单。
用户需要提供收货地址、联系方式等信息。
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
《软件工程》实验指导书
《软件工程》实验指导书计算机学院2017年2月软件工程实验指导前言软件工程实验是为计算机相关专业本科《软件工程》课程配套设置的，是《软件工程》课程讲授中一个重要的、不可或缺的实践环节。
其目的是使学生能够针对具体软件工程项目，全面掌握软件工程管理、软件需求分析、软件初步设计、软件详细设计、软件测试等阶段的方法和技术，通过该课程设计使学生进一步理解和掌握软件开发模型、软件生命周期、软件过程等理论在软件项目开发过程中的意义和作用，培养学生按照软件工程的原理、方法、技术、标准和规范，进行软件开发的能力，培养学生的合作意识和团队精神，培养学生对技术文档的编写能力，从而使学生提高软件工程的综合能力，提高软件项目的管理能力。
按该课程的特点，实验内容包括软件开发的两大方法学的专题训练，即结构化（生命周期学）的方法学和面向对象的方法学，通过对一个简单项目，要求学生利用结构化软件开发技术或面向对象的软件开发技术完成对该项目的开发。
因此设置五个实验项目，从项目发的准备工作，系统分析过程，系统设计过程，软件测试到系统实施，覆盖软件开发的整个过程，此外又引入我国国家《计算机开发规范》，以规范技术文档的书写标准，提高实验教学质量。
通过实验训练，达到如下目的：使学生进一步了解和掌握软件工程原理，提高对实际项目的分析和设计能力，通过实验课程，熟悉和基本掌握软件工程方法学、软件开发的过程，文档资料的编写格式及规范，全面领会和贯通所学习的理论知识，从而培养学生综合运用所学课程知识，分析解决问题的能力，培养学生理论联系实际作风，实事求是，严肃认真的科学态度和良好的工作作风，为今后从事科学研究工作打下基础。
实验要求软件工程实验具体要求如下：每个项目小组必须按照《软件工程实验指导书》附录中给定的文档规范标准提供项目文档；题目自定或采用附录二中的题目；软件开发的方法自定（结构化或面向对象的方法学）。
实验一用Visio进行功能分析和建模1. 实验目的掌握结构化分析的方法。
电子科技大学-UML实验报告讲解
软件工程专业类课程实验报告课程名称：系统分析与设计（含UML）学院：信息与软件工程学院专业：嵌入式系统学生姓名：XXXXXX学号：201222XXXXX指导教师：周XXXX评分：日期：2014年11 月12 日目录目录 (2)实验1 (3)1.1实验名称 (3)1.2实验时间和地点 (3)1.3实验内容和目的 (3)1.4实验环境 (4)1.5实验步骤及实验结果 (4)1.6实验结论、心得体会和改进建议 (7)实验2 (8)2.1实验名称 (8)2.2实验时间和地点 (8)2.3实验内容和目的 (8)2.4实验环境 (9)2.5实验步骤及实验结果 (9)2.6实验结论、心得体会和改进建议 (13)实验3 (14)3.1实验名称 (14)3.2实验时间和地点 (14)3.3实验内容和目的 (14)3.4实验环境 (15)3.5实验步骤及实验结果 (15)3.6实验结论、心得体会和改进建议 (20)实验4 (21)4.1实验名称 (21)4.2实验时间和地点 (21)4.3实验内容和目的 (21)4.4实验环境 (22)4.5实验步骤及实验结果 (22)4.6实验结论、心得体会和改进建议 (27)实验5 (28)5.1实验名称 (28)5.2实验时间和地点 (28)5.3实验内容和目的 (28)5.4实验环境 (28)5.5实验步骤及实验结果 (29)5.6实验结论、心得体会和改进建议 (46)电子科技大学实验报告实验11.1实验名称用例图、活动图的创建1.2实验时间和地点实验时间：2014-10-12实验地点：信息与软件工程学院实验中心1.3实验内容和目的实验内容：1.3.1开发一个网上书店系统。
顾客注册后可以登录系统，搜索图书信息，管理自己的购物车，填写和管理自己的订单，管理自己的个人信息。
管理员需要处理订单和管理图书。
（1）请创建该系统的用例图，并完成“搜索图书”的用例规约。
（2）请创建“搜索图书”的活动图1.3.2开发一个在线考试系统。
面向对象需求分析——用例图和活动图
面向对象需求分析——用例图和活动图面向对象软件开发的方法有：a，面向对象分析（OOA）b,面向对象设计(OOD）c,面向对象实现（00I）d，面向对象测试（OOT）,e，面向对象维护（OOM）这几个主要大步骤。
下边我们就从面向对象的角度来学习UML的相关图。
这里介绍面向对象分析阶段的用例图和活动图。
面向对象分析阶段，我们要明确系统的职责，范围和边界；确定软件的功能和性能；构建需求模型（用例模型）。
首先在这里说一下，为什么将这两个图放在一起，主要原因就是活动图的一个目的是更细致的描述用例图，和文档的配合使用，使用例图更加清楚明了。
先介绍一下：用例图1，概念：用例是系统的一个功能单元，是对用户需求的描述。
2，组成：参与者，用例及其之间的关系（包括关联关系，泛化关系，包含关系，扩展关系）：3，用例建模的步骤：a,确定系统的范围和边界；b,确定系统的用例和参与者；c,描述用例；d，对用例分类，并确定用例之间的关系；e,建立用例图，并定义用例图的层次结构；f,评审用例模型。
下边我们看个例子：这是一个教务管理系统的总用例图和一个子一级用例图，当然还可以再分：在上述6个步骤中，我简单总结一下：a,系统边界，就是一个系统内部所有元素与系统外部事物的分界线。
b,用例和参与者，需要我们根基实际情况去抽象。
c,描述用例，这个我重点写一下（举例，选课注册）：用例编号：0101用例名称：选课注册执行者：学生功能：实现学生选课注册的过程类型：主要用例，基本用例级别：一级过程描述：1，学生输入系统账号和密码，系统进行验证；2，查询课程信息3，查询个人选课信息4，若可以选课，则进行选课注册，并将选课信息写入数据库中5，返回选课注册是否成功异常事件流处理：1，学生的账号和密码错误，允许重新输入（3次）2，学生未按时交纳学费，不可选课3，学生人数已达到上限，不可选课。
（当然在这里在把下边的活动图，添加进来即可）d,用例分类和确定之间的关系，有端点用例，基本用例，主要用例，辅助用例等，关系弄准确就可以。
信息系统分析与设计-餐饮管理系统(面向对象)
课程设计报告课程名称:信息系统分析与设计课程设计题目：餐饮管理系统分析与设计姓名：系：专业：年级：学号：指导教师：职称：年月日课程设计结果评定目录1. 系统规划 (1)1.1 目的 (1)1.2 意义 (1)1。
3 目标 (1)1。
4 规划 (2)2. 系统分析与设计 (2)2.1 用例图 (2)2。
2 用例规约 (2)2.3 顺序图 (3)2.4 活动图 (3)2.5 状态图 (4)2.6 类图 (4)2。
7 架构设计 (4)2。
7.1 系统组成 (4)2。
7。
2 系统功能 (4)2.8 数据库设计 (7)3。
总结 (8)参考文献 (8)餐饮管理系统分析与设计1. 系统规划1.1 目的构建一个集高效性、灵性、实用性、功能划分详细以及方便的可扩充性等特于一体的通用餐饮娱乐业管理系统，使餐饮管理者对餐饮业管理进行宏观的和微观的细致管理，在满足广大顾客的需求的同时，也大大增加酒店餐厅的工作效率，促成一个双方满意的局面。
1.2 意义当今世界已进入了在计算机信息管理领域中激烈竞争的时代，应用计算机已经变得十分普遍了，如同我们离不开的自行车、汽车一样。
我们应该承认,谁掌握的知识多，信息量大，信息处理速度快，批量大，谁的效率就高，谁就能够在各种竞争中立于不败之地。
随着科学技术的不断提高,计算机科学日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域并发挥着越来越重要的作用。
越来越多的管理人员意识到信息管理的重要性.由于当前酒店的管理还处于人工管理阶段，仅在财务部门使用了计算机，所以酒店的管理效率不高。
由于缺乏科学的管理和现代化的管理工具，该饭店在管理上和业务的安排上都存在着不足。
(1）房间的管理不够科学方便，房间使用情况不直观.（2）库管员不能随时掌握库存情况，不能及时发现商品缺货的情况,另外统计商品数量即费时又费力。
（3）由于该酒店的商品种类多，菜样多变，靠人工方式管理商品和菜品信息有很多不便。
模板-用例规约
密级：内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称
×××项目
主 题
用例规约
说 明
该项目用于网上购物
适用对象
该项目适用于代替以往的购物方式，改为网上购买食品的用户。
修订历史
版本
章节
类型
日期
作者
说明
1.0
C
说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
评审记录
角色
er点击‘确认’按钮，删除商品信息
4.系统删除选中的商品信息，并更新商品信息列表
其它事件流：
第3步，user选择“取消”，系统将取消删除操作，并返回商品列表页面
异常事件流：
第4步，系统删除商品信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user删除失败
后置条件：
6．系统保存结账信息，并返回到商城主页面。
其它事件流：
第1步，user若没有登录系统，则提示用户先登录系统，同时若是用户没有注册账号，提示用户先注册账号
第2步．user选择‘修改’按钮，对已选购的商品信息进行修改
第2步．若用户是首次结账，需要填写送货地址，送货地址包括：姓名、本地/外地、通讯地址、邮政编码、电话号码。非首次结帐，显示上次购物时的送货地址，并默认为本次的送货地址。
其它事件流：
无
异常事件流：
第6步，系统保存商品数量时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user更改商品数量失败
后置条件：
系统更新商品数量信息。
2.1.4结账
用例描述：
用例名称：
用例规约+活动图例子
⽤例规约+活动图例⼦⼀、⽤例规约作业请根据中国⼯商银⾏⽹络银⾏的转账汇款的相关说明，试编写该⽤例的规格说明。
要求从中体会业务规则的作⽤和分析，并在⾃⼰的课题中分析充分详尽的业务规则。
注：新发布的⽤例⼀章的课件中，有个取款相关的⽤例规格说明，可参考。
1.安全提⽰：为了您的资⾦安全，请勿轻信陌⽣⼈通过⽹络聊天群、直播、电话、短信等⽅式进⾏的诱导性“投资理财”、代办⼤额信⽤卡或⾼额贷款、⽹购客服或快递进⾏退货等⾮正规渠道要求进⾏转账汇款，谨防被骗。
短信通知⼿续费将根据我⾏政策进⾏减免，请以实际扣款情况为准。
2.汇款类型：根据⼈民银⾏关于防范电信诈骗有关要求，我⾏为您提供“实时汇款、普通汇款、次⽇汇款”三种汇款⽅式选择。
对于“普通汇款”和“次⽇汇款”，您可在限定时间内通过⼿机银⾏或⽹银“转账汇款-查询汇款明细”进⾏撤销。
3.到账时间：⾏内汇款⼀般实时到账，7*24⼩时受理。
⾃2019年11⽉29⽇起100万元（含）以内跨⾏汇款，我⾏将优先通过⽹银互联系统汇出⾄收款⾏，⼀般实时到账，7*24⼩时受理。
100万元以上跨⾏⼤额汇款，⼯作⽇交易时间（前⼀⽇20:30-当⽇17:15）⼀般实时到达收款⾏；⼯作⽇（周⼀⾄周四）⾮交易时间（17:15-20:30）提交，系统预约⾄当⽇20:30后汇出；⾮⼯作⽇，系统将做预约处理，待下⼀⼯作⽇交易时间（⼀般为节假⽇最后⼀天20:30后）汇出。
准确时间以⼈民银⾏系统为准。
4.收款⼈信息：当您向其他银⾏汇款时，系统⽆法判断收款⼈信息是否准确，仅对信息格式进⾏校验，请您务必准确填写收款⼈户名、卡（账）号、收款⾏等信息，若因上述信息填写错误导致汇款失败，⼿续费不退回。
汇款成功后收款⼈信息将⾃动添加⾄“我的收款⼈”，⽅便您再次汇款操作。
您还可直接输⼊收款⼈户名、⼿机号向其汇款，若其⼿机号已绑定银⾏账户（含他⾏），则将实时汇⼊绑定账户；若其⼿机号未绑定银⾏账户，则系统将向收款⼈发送短信，根据收款⼈短信回复卡/账号汇⼊资⾦。
课堂练习用例图与用例规约 PPT
2、 无效的参与者泛化
✓ 参与者泛化:特别参与者会继承泛化参与者所有的要素！ ✓ 参与者的重要性在一识别用例,假如泛化没有带来任何用例,则如此
的方法没有任何意义 ✓ 在系统中假如两个参与者涉及相同的用例,则合并
8
3、 错误的用例关系
✓ 依赖关系:include, extend都是依赖关 系(dependency)的 构造型(stereotype), 带箭头的虚线表示
课堂练习用例图与用例规约
用户需求简要描述
某公司要开发一个旅店预定系统,该旅店可对外开放 豪华双人间、双人间、三人间和单人间,房间费用视情况 按季节调整,但周一到周五半价(周末全价)折扣不变。关 于外界请求,该系统应能依照请求入住时间预定指定档次 的房间,记录旅客姓名、地址、联系电话、有效证件号、 房间类型和预定天数,并计算出总费用。预定的同时旅客 按规定须提交10%定金。六个小时之内旅店允许旅客取 消预定,并退回所有定金,超过六个小时定金不退还。每周 一系统自动打印一周预定情况清单。采纳哪种费用支付 方式和何种类型操作界面尚不确定。
12
5、参与者和用例间的关系
✓ “打印报表”和 “酒店管理员” 之间的关联是 有意义的交互 不？
13
6、 用例粒度太小
14
较为合理的用例图
酒店前台
<<include>>
查找房间 <<include>> 预订房间
计算总费用
<<extend>>
取消预订
退还定金
管理人员
调整价格
时间
打印预订清单
15
感谢您的聆听！
✓ 扩展关系:“extend” 关系的方向,子用例对 主用例的扩展
OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描述
一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。
这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。
有时候，这类规则也被写到软件架构文档中。
关于用例补充规约以后再讨论。
第二种是交互规则。
这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。
当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP 定单进入特殊流程等。
这类规则一般要写到用例规约中。
交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。
稍后参看示例。
第三种是内禀规则。
所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。
例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。
同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。
这类规则是业务实体的内在规则，因此应该写到领域模型文档中，稍后参看示例。
读者或许对把规则这么分类有不同的习惯和理解，可能会觉得麻烦。
但是笔者这么做有充分的理由。
首先，全局规则与具体用例无关，它实际是系统应该具备的特性，这些规则把它分出来目的就是为了让系统去负责这些特性的实现。
读者可以结合实际考虑一下，通常授权，事务，备份等特性都是由系统框架去实现的，具体的功能中并不去实现它们。
如果读者有过基于某个框架开发应用的经历的话一定会认同笔者的话。
其次，交互规则是在用例场景当中产生的，它们规定了满足什么条件后业务将如何反应。
通常，这部分规则是最复杂，也最不稳定，最容易变化的。
大家所说的需求经常变更相信绝大部分就来自于此。
UML活动图实例
1. UML活动图实例一、活动图的组成元素 Activity Diagram Element1、活动状态图（Activity）2、动作状态（Actions)3、动作状态约束（Action Constraints）4、动作流（Control Flow）5、开始节点（Initial Node）6、终止节点（Final Node）7、对象（Objects）8、数据存储对象（DataStore）9、对象流（Object Flows）10、分支与合并（Decision and Merge Nodes）11、分叉与汇合（Fork and Join Nodes）12、异常处理（Exception Handler）13、活动中断区域（Interruptible Activity Region）14、泳道（Partition）二、活动图案例分析三、总结活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。
活动图在本质上是一种流程图。
活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。
一、活动图的组成元素 Activity Diagram Element1、活动状态图（Activity）活动状态用于表达状态机中的非原子的运行，其特点如下：(1)、活动状态可以分解成其他子活动或者动作状态。
(2)、活动状态的内部活动可以用另一个活动图来表示。
(3)、和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。
(4)、动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。
UML中活动状态和动作状态的图标相同，但是活动状态可以在图标中给出入口动作和出口动作等信息。
2、动作状态（Actions）动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。
动作状态有如下特点：(1)、动作状态是原子的，它是构造活动图的最小单位。
软件工程各阶段的UML图应用
软件⼯程各阶段的UML图应⽤UML是统⼀建模语⾔，主要⽤于软件的分析与设计阶段。
但是UML有这么多图，具体怎么⽤呢?⼀：需求分析阶段的业务⽤例图⽤例图，是⽤来表⽰系统⾓⾊与系统什么功能发⽣交互的图。
通过⽤例图，可以很清晰地表⽰系统放主要功能。
⽤例图在我们进⾏软件分析阶段和设计阶段都有使⽤：由⽤户需求得到业务⽤例（描述最主要的业务功能，客户最感兴趣的、期望的功能）在与客户第⼀次交流沟通，采集需求后。
我们可以得到《开发⽂档1.0》（见上⼀篇博⽂）。
同时，也可以由客户描述的系统功能、⽤户⾓⾊画出业务⽤例图。
注意：这只是初步的⽤例，⽤来说明系统业务功能的。
例如：⼀个新闻⽹站的业务⽤例图如下：⼆：概要设计阶段的功能活动图、系统⽤例图1：在把《开发⽂档1.0》和业务⽤例图交予客户审核确认后，我们开始编写《开发⽂档2.0》，然后根据《开发⽂档2.0》中新增的功能描述，我们可以画出每⼀个功能的活动图：例如：管理员原理新闻的功能活动图2：由每⼀个功能活动图，完善业务⽤例图得到系统⽤例图（此时才是真正全⾯描述系统各个⾓⾊可以执⾏什么功能的⽤例图）三：详细设计阶段的⽤例规约图由《开发⽂档3.0》中的“功能详细设计”部分，画出每⼀个功能⽤例的约束图，主要包括：⽤例名、⽤例流程、异常处理等操作四：详细设计阶段的业务模块图根据《开发⽂档4.0》中的“模块划分”，我们就知道了这个系统主要会有哪些业务类，画出业务模块图，每个业务类下罗列该模块下的功能⽤例：五：详细设计阶段的类图根据《开发⽂档5.0》中对每个⽤例的架构、以及功能模块的划分，可以初步确定系统需要多少个实现类组成，画出类图：六：详细设计阶段的时序图根据每个⽤例的活动图以及第五步的系统类图，我们可以为每个⽤例画出时序图，更加清晰明确地模拟出⽤户是怎么⼀步步调⽤哪个类的哪个⽅法来实现进⾏功能交互的，如：七：根据上⾯的类图、⽤例的时序图等等，进⾏编码开发。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、用例规约作业
请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。
要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。
注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。
1.安全提示：为了您的资金安全，请勿轻信陌生人通过网络聊天群、直播、电话、短信等方式进行的诱导性“投资理财”、代办大额信用卡或高额贷款、网购客服或快递进行退货等非正规渠道要求进行转账汇款，谨防被骗。
短信通知手续费将根据我行政策进行减免，请以实际扣款情况为准。
2.汇款类型：根据人民银行关于防范电信诈骗有关要求，我行为您提供“实时汇款、普通汇款、次日汇款”三种汇款方式选择。
对于“普通汇款”和“次日汇款”，您可在限定时间内通过手机银行或网银“转账汇款-查询汇款明细”进行撤销。
3.到账时间：行内汇款一般实时到账，7*24小时受理。
自2019年11月29日起100万元（含）以内跨行汇款，我行将优先通过网银互联系统汇出至收款行，一般实时到账，7*24小时受理。
100万元以上跨行大额汇款，工作日交易时间（前一日20:30-当日17:15）一般实时到达收款行；工作日（周一至周四）非交易时间（17:15-20:30）提交，系统预约至当日20:30后汇出；非工作日，系统将做预约处理，待下一工作日交易时间（一般为节假日最后一天20:30后）汇出。
准确时间以人民银行系统为准。
4.收款人信息：当您向其他银行汇款时，系统无法判断收款人信息是否准确，仅对信息格式进行校验，请您务必准确填写收款人户名、卡（账）号、收款行等信息，若因上述信息填写错误导致汇款失败，手续费不退回。
汇款成功后收款人信息将自动添加至“我的收款人”，方便您再次汇款操作。
您还可直接输入收款人户名、手机号向其汇款，若其手机号已绑定银行账户（含他行），则将实时汇入绑定账户；若其手机号未绑定银行账户，则系统将向收款人发送短信，根据收款人短信回复卡/账号汇入资金。
5.交易限额：各类转账认证方式（U盾、电子密码器、短信）交易限额，您可在“工银e支付-安全管理-认证管理”或“安全-认证管理”下查看、调整。
向绑定工行账户手机号汇款交易限额受支付认证方式控制；向绑定他行账户手机号汇款，单笔最高100万元；向未绑定银行账户手机号汇款单笔最高5万元。
（注：手机银行渠道可通过工银e支付办理最高单笔20万元、日累计100万元的转账）
6.汇款手续费：个人网银：本行（含同城和异地）汇款免收手续费；跨行汇款，每笔5000元（含）以下的免收手续费；5000元以上按柜面收费标准的五折收取。
如您已购买结算套餐，将抵扣结算套餐并免收手续费。
具体请参考我行门户网站“服务价目表”公布的收费标准及相关优惠活动。
（注：手机银行境内人民币汇款目前暂不收费）
7.付款账户：自助注册卡无法使用U盾、密码器认证，若您已申领U盾或电子密码器，您可登录手机银行在“我的账户”下点击“功能升级”按钮，按照提示通过刷脸认证后将该卡升级为柜面注册卡。
8.其它说明：境内汇款不支持向16位财智账户卡汇款。
国际借记卡、贷记卡外币账户作为收款账户可接收本人其他同币种外币账户转入的钞/汇；如作为付款账户，只可从外币现钞账户转出。
二、活动图作业
1. 本校自今年起启用网上订购教材流程，简述如下：
（1）教务处发布《编制教材选用计划》的通知
（2）任课教师经课程组教师集体研究讨论后，根据教学计划、课程教学大纲要求和有关教材信息，任课教师在教务系统里填写《教材使用计划审批表》（3）教务处整理教材使用计划
（4）学院组织院级教学工作委员会审议本学院的教材使用计划，若有不当，则由任课教师重新提交教材使用计划；若无问题，则报送教务处备案
（5）教务处制定《学生教材订购发行单》，电子版将在教务管理系统公布
（6）根据教务处发布的《学生教材订购发行单》，教材供应商提前备书供货
（7）教师领取教师用书，同时学生在自愿订购的基础自行向供应商订购图书
请按照UML活动图的规范画出该流程的活动图。
2. 本校的考试管理流程如下图所示，请按照UML活动图的规范画出该流程的活动图。