ATM(自动取款机)的用例图
实验一 用例图uml实验ATM机用例图
学号
验时间
实验名称
用例图
实验内容
本次实验完成如下内容：
1.确定系统功能需求
2.完成系统用例图的绘制
3.确定每个用例的事件流
一、实验目的
能够根据系统的功能分析系统的用例组成
正确确定用例图中的参与者
根据系统确定每一个用例的事件流
二、实验环境
UML建模工具Rational Rose 2003
三、主要设计思想
本实验主要有以下两个特点：
（1）活动者、用例的划分。创建一个用例框图是可视化建模中具有关键的一环。每个用例所涵盖的内容（功能）既不能太大也不能太小，否则会影响以后工作的进展。
（2）使用Rational Rose工具规范性建模。从浏览器窗口容易看出，除了一个总的用例框图（全局视图）外，每个活动图均包含在各自的包中，显得直观明了。每个用例都附带有重要的――该用例事件流的详细描述，保持和需求的一致性，这点在以后的工作开展中也是十分重要的。
四、实验结果
五、实验总结
学会了寻找用例，参与者，用例与参与者。学会了，怎么描述用例，建模。
UML建模_ATM取款机
软件建模（UML）作业班级：计算机0806班学号：20083007姓名：姜俊方UML 个人作业一、ATM 机需求分析图二、用例图用于描述一组用例、参与者及它们之间的连接关系。
用例图仅仅从角色使用系统的角度描述系统中的信息，也是站在系统外部查看系统功能，而并不描述该功能在系统内部是如何实现的。
用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例可应用于整个系统，也可应用于系统的一部分，包括子系统、单个的类甚至接口。
通常，用例不仅代表这些元素所期望的行为，而且还可把这些元素用作开发过程中测试用例的基础。
椭圆：用例，是用户与计算机之间的一次典型交互作用。
人形：参与者(外部执行者)是指用户在系统中所扮演的角色。
ATM 系统的用例图读卡机模块键盘输入模块IC认证模块显示模块吐钱机模块打印报表报表监视器模块ATM 自动取款存钱取钱转账查询余额付款银行工作人员客户修改密码添加信息银行工作人员维护硬件设备ATM 提款系统用例图存款查余额用户更改密码取款验证用户付款信用三、类图用于描述一组类、接口、协作及它们间的静态关系。
在面向对象系统的建模中，类图最为常用，它用来阐明系统的静态结构。
类是对一组具有相同属性、操作、关系和语义的对象的描述，其中对类的属性和操作进行描述时的一个最重要的细节是它的可见性。
一个典型的系统模型中通常有若干个类图。
一个类图不一定要包含系统中所有的类，一个类可加到几个类图中。
在类图中类用矩形框来表示，它的属性和操作分别列在分格中。
类之间可以多种方式链接(如关联、泛化、依赖和实现等)。
关系用类框之间的连线来表示，不同的关系用连线上和连线端头处的修饰符来区别。
类图数据库ATM键盘ATM 屏幕吐钱机ATM 读卡器账户ATM 系统类图四、顺序图(序列图)顺序图表示对象之间传送消息的时间顺序。
顺序图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。
ATM系统UML 7种图
UML建模语言7种图(以银行ATM系统为例)分类：JAVA2010-04-21 20:40 2911人阅读评论(0) 收藏举报uml语言活动作业优化1 用例图：描述了系统提供的一个功能单元。
以一种可视化的方式理解系统的功能需求，"角色"与系统内用例之间的关系。
本例中，参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
2 类图：显示系统的静态结构。
逻辑类、实现类，实现类就是程序员处理的实体。
类在类图上使用包含三个部分的矩形来描述，如图2所示。
最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说"方法"）。
本例中许多单个的帐户组成了帐户库，帐户具有帐户类型、帐户号、余额三个属性。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮助自己整理思路，充实及优化自己的设计。
3 序列图：显示具体用例（或者是用例的一部分）的详细流程。
它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。
本例以时间为顺序描述了顾客在ATM机上取款时信息的流动情况，顺序图着重于对象间消息传递的时间顺序。
4 状态图：表示某个类所处的不同状态和该类的状态转换信息。
包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。
本例描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。
ATM机取款完整用例
示例：ATM机取款扩展事件流描述 机取款扩展事件流描述
2a.卡被验证为无效：ATM吐出银行卡，并给出提示信息（用例失败） ； 4a.输入密码错误：ATM给出提示，如没超过3次重试机会则回到步骤3，否则ATM 吞卡（用例失败）； 4b.账号不存在：ATM给出提示并回到步骤9； 5a.ATM中现金空缺：ATM的服务选项中没有取款； 6a.ATM中现金少于取款额：ATM给出提示并回到步骤6； 7a.顾客余额少于取款额：ATM给出提示并回到步骤6； 7b.取款额超过24小时限额：ATM给出提示并回到步骤6； 10a.ATM日志无法更新：ATM进入安全模式，所有功能被挂起，并向银行主机告 警（用例失败） ；
*a.顾客可以在任何时候决定退出：ATM停止事务，吐出银行卡，并做记录（用例失败）； *b.传感器在监测到反常情况时报警：ATM被挂起；Βιβλιοθήκη 为如下活动开发一个完整的用例
前置/后置条件 后置条件
• ATM机取款前置条件：
– ATM机开机并正常运作；顾客拥有一张可以插入ATM机读卡器的银 行卡；
• ATM机取款后置条件：
– 最小保证：顾客的操作被记录（录像）；所有的账户和交易记录 必须保持平衡；ATM机与银行主机系统的通讯重新初始化； – 成功保证：顾客取得正确数量的现金；顾客取回银行卡、凭条； 顾客账户数据被正确修改；银行系统记录了取款信息。
示例：ATM机取款基本事件流描述 机取款基本事件流描述
1.发起取款：顾客将银行卡插入读卡器； 2.验证银行卡：ATM读取卡上的银行标识和账号数据，验证卡的有效性； 3.输入密码：在ATM提示下，顾客输入密码； 4.验证账号和密码：ATM验证账号有效并且密码正确； 5.选择服务（取款）：在ATM提示的可选服务中，顾客选择取款； 6.输入取款额：在ATM提示下，顾客输入50元倍数的金额； 7.服务授权：ATM向银行主机提供卡号+密码+账号+取款额，发起取款事务，银行 主机返回取款授权，并更新余额； 8.派发现金：ATM清点并吐出现金； 9.返还银行卡：ATM吐出银行卡； 10.提供凭据：ATM打印并吐出凭条，并更新内部日志（记录取款成功信息）。
ATM自动取款机用例图
自动取款机用例图一、顾客与ATM机交互功能用例ATM机用例约束：1、插卡：用户和ATM自动取款机交互时，系统提示请插入磁卡，插入磁卡后，如果验证成功，进入登陆界面；否则退卡。
2、输密码：系统在登录界面提示输入密码，如果输入的密码正确，按确认键进入主界面，否则按更正键，重新输入密码。
3、存款：进入主界面后，选择存款进入存款界面，系统提示请放入整百元的人民币。
存款成功后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
4、取款：进入界面后，选择取款，若所取的金额在界面上有，按相应的金额进行取款操作；若无，在键盘上手动输入所取的金额后按确认键。
取款成功后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
5、查询余额：进入主界面后，选择查询余额，进入查询余额界面，屏幕显示“您的余额是 *** ”。
完成该操作后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
6、修改密码：进入主界面后，进入修改密码界面，系统提示输入旧密码，新密码，确认新密码，如果两次输入的新密码一致，按确认键，则修改密码成功。
完成该操作后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
7、缴费：进入主界面后，选择缴费，系统提示按键选择缴费项目，按确认键后，进入缴费提示界面，则按确认键，则缴费成功。
缴费成功后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
8、转账：进入主界面后，选择转账，系统提示输入转账账户和转账金额，按确认键后，进入转账提示界面，如果该界面上显示的是你所要转账的用户名，则按确认键，则转账成功。
如果和你所要转帐的用户不一致，则返回主界面，重复上述的转账操作。
转账成功后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
9、打印凭条：进行完相应的操作后，如果要核实一下操作，选择打印凭条，ATM 自动取款机会把凭条打印出来。
完成该操作后，如果还要进行其他操作，按返回主界面键返回主界面，否则退卡。
ATM(自动取款机)的用例图
ATM（自动取款机）的用例图、类图、顺序图、状态图、活动图及协作图1 用例图参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
2 类图图2所示的银行系统类图和图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 机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。
同样对于一个真正的银行系统，这个类图过于简单。
比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。
场景法设计用例-ATM机
1．案例描述：下图所示是ATM例子的流程示意图。
2.场景设计：下表所示是生成的场景。
表3-8 场景设计
3.用例设计
对于这7个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
表3-9 测试用例表
4.数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。
表3-10 测试用例表
5.要求：将转帐、存款、系统启动这3个流程细化成场景，并设计出相关的测试用例！。
ATM2
ATM系统分析和设计说明：报告中所使用的A TM机隶属工商银行，位于工大工商银行外面。
一、ATM机完整用例图二、取款、查询的用例说明三、取款、查询用例的活动图《取款》储户银联系统说明：该活动图是按用户正常登陆后进入取款功能而设计的活动图。
在主界面出点击取款功能按钮，进入取款主界面，用户输入取款金额，且此时可更改，系统将清空之前的输入。
若用户选择确认取款，可能会发生以下状况：①操作超时了，系统时钟到时后将自动吞卡(该状况可能发生在任一时刻)，然后终止此次活动。
②ATM机此时余额不足，则ATM机锁住,显示ATM机暂停服务,终止此次活动。
③账户余额不粗，则ATM机提示余额不足信息并返回取款界面。
④储户输入取款金额超过一次上限（该工行ATM机上限为2500元），则ATM机提示一次取款不能超过2500元上限并返回取款界面。
⑤储户输入金额为0(或非整百)元，则A TM机提示输入非法并返回取款界面。
⑥储户输入合法金额，则银联系统修改账户余额、交易等信息，打钱并转入等待界面。
储户取钱后，ATM机显示此次交易成功。
储户可选择继续取款(回到初始取款界面)、查询（进入查询界面，结束此次流程）、返回（回到主界面，结束此次流程）、打印凭条（进入打印，结束此次流程）或退卡（结束此次活动）。
《查询》储户银联系统说明：该活动图是按用户正常登陆后进入查询功能而设计的活动图。
主界面出点击查询功能按钮，进入查询主界面，并选择所要查询的账户类别。
此时，银联系统需作出判断，即该用户是否有此项账户下的相关信息，若没有，则提示所查用户无此账户信息；若有，则进入查询系统内部数据库，显示该用户此项账户下的余额信息。
用户确认此项显示信息，并开始继续选择，如继续查询（回到查询主界面，开始一次新的活动）、选择转账功能（进入转账界面，结束此次流程）、选择取款功能（进入取款界面，结束此次流程）、选择返回（返回主界面，结束此次流程）、退卡（结束此次活动）。
ATM用例图_用例规约_时序图[]
![ATM用例图_用例规约_时序图[]](https://img.taocdn.com/s3/m/e841b606e45c3b3567ec8b7f.png)
ATM用例图_用例规约_时序图[]————————————————————————————————作者：————————————————————————————————日期：ATM 系统用例图存款取款查询转账客户银行主机改密码用例包括：1） 存款：客户持银行卡（本行或其他行）从ATM 存放现金 2） 取款：客户持银行卡（本行或其他行）从ATM 提取现金3） 查询：客户持银行卡（本行或其他行）在ATM 上查询卡的帐户信息 4） 转账：客户持银行卡（本行）在ATM 上进行同行转账5） 改密码：客户持银行卡（本行或其他行）在ATM 修改卡的密码系统用例规约：ATM取款用例名称：ATM取款描述：客户持银行卡（本行或其他行）从ATM提取现金actors: 客户和银行主机前置条件：无基本流： 1.客户插入银行卡。
2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。
3.客户输入密码。
4.ATM验证帐号和密码。
5.ATM显示包括取款在内的服务功能，客户选择“取款”。
6.输入取款额：客户输入数量为50元的倍数的取款额。
7.ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。
8.ATM打印并吐出凭条。
9.ATM清点并吐出现金，记录取款成功。
10.ATM询问客户是否继续服务。
11.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。
[用例结束]备选流：3-7，10a. 客户取消服务：ATM记录服务取消，打印凭条，吐出凭条和银行卡，[用例失败] 3,6,11a. 客户未及时输入超过30秒：ATM吞卡，[用例失败]2a. 卡无效：ATM吞卡，[用例失败]2b. 读卡器或卡被损坏：ATM吞卡，[用例失败]4a. 密码错：4a1. 客户重新输入密码a.累计3次密码错误：ATM吞卡，[用例失败]4b. 无此帐号：ATM吞卡，[用例失败]5a. ATM无现金：ATM不显示“取款”功能，客户可选择其他服务，[用例失败] 6a. 取款额超过ATM现金余额：ATM要求客户重新输入取款额。
ATM用例图
用例图一、ATM 系统分为三个大的模块二、任务概述1、系统功能实现用户在ATM 上提取现金、查询账户余额、修改密码及转账功能. 系统用例图根据系统的需求分析可知 ，系统中的角色有顾客、 管理员和系统 ,其中顾客使用 A TM 系统进行交易;工作人员可以更改 A TM 的设置、 放置现金、 机器维护等;系统则作为外部角色参与整个活动。
ATM 系统登录模块 事务模块退出模块输入密码存款查询余额 修改密码转账打印凭据退卡插卡ATM机银行工作人员三、需求规定3. 1系统功能概述ATM自动取款机系统相关的主要对象有：用户：使用ATM自动取款机进行现金交易。
进行取款、查询余额、设置密码、转账等操作。
系统：对用户的需求进行接收,通过与数据库的交互，根据对用户应用服务的响应，更新数据库中用户的信息。
数据库：对用户的所有信息进行存储更新.登陆功能：在整个的系统中，首先用户要选择应用的提示语言的种类，“ENGLISH”或“汉语”,之后输入正确用户登录密码以后才可以进入主界面进行相关的操作.验证用户：当用户输入账号和密码时，系统要进行验证，用户和密码输入正确了才可以登陆进去。
修改密码：系统要求首先输入旧密码，再输入写密码，并对新密码进行第二次确认，全部输入正确,修改功能完成。
查询功能：在主界面中点击余额查询功能选项,就会弹出余额的窗口。
存款功能：当用户存款的时候，系统要提示进行添加.转账功能:用户可以通过该功能将自己账户上的金额转到其他账户。
取款功能：当用户在菜单栏点击取款功能选项，可以进入取款界面：●首先你可以输入取款的金额，输入的必须为50倍数的数字，否则系统会提示输入的金额错误，请重新输入。
如果屏幕上有便捷提示，比如：1000元、800元、500元等。
如果上边有你想要取款的金额，你可以按相对应的按键就可以了，如果没有，你再找一个“其他金额"按下之后,就可以自由输入自己想取的金额了,输入金额之后，按“确认”,即完成取款功能。
UML(ATM系统)需求建模
金陵科技学院学生实验报告（理工类）课程名称：_面向对象分析和设计（UML）实验名称：_需求建模：用例关系图_____专业班级：___M10计算机科学与技术___学生学号：_____1021413036__________学生XX：_______X____伟__________实验学时：4 实验序号：1一、实验目的熟悉Visio工具，能运用该工具，实现需求建模。
掌握用例的UML图形设计，理解和设计实验内容中要求的用例和角色之间关系。
二、实验设备和环境PC(一台)，Windows 2000或以上版本，安装。
Microsoft Visio 2003三、实验要求：实验具体题目：InfoSuper 银行是一家著名的金融机构，其客户遍布全球。
该银行向客户提供以下服务：企业银行业务、个人银行业务、共同基金、理财服务、住房贷款InfoSuper 银行 45% 的收入来自个人银行业务。
因此，银行希望进一步提升个人业务的服务质量并争取留住客户并提高他们的忠诚度。
该银行进行了一次市场调查以了解客户在个人银行业务处理时间、满意度和资源需求方面的要求。
调查结果显示为了来办理银行事务（如，提取现金、支票存款、和获取交易概要等），一个客户平均每月要跑 10 到 15 趟银行。
银行希望开发一个软件系统以通过改进的设施来减少客户访问银行的次数并提高客户服务。
为此 InfoSuper 银行的代表找到了软件开发商 Janes Technologies 公司。
在分析了银行的需求文档后Janes Technologies 公司项目经理 Jennifer 建议银行开发自动取款机（ATM）系统提供以下功能：现金提款、现金存款、交易概要、更改 PIN、同行转帐、有关银行提供的其他服务的信息、还需要在部署 ATM 系统的地方提供箱子以供客户丢弃支票与请求支票簿。
要求设计 ATM 系统，使其突出系统优势和成分。
（一）要设计 ATM 系统，需要执行以下任务：1.确定需求。
使用UML对ATM系统【用例图-活动图-时序图-类图】
使用UML对ATM系统建模评分：一．实验目的针对指定软件系统的需求进行分析和设计；使用Microsoft Visio软件，绘制UML图。
二．实验设备计算机、Microsoft Visio软件。
三．实验内容及步骤下图所示是一个自动（ATM）系统，它的需求陈述如下：本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：（1）取款服务。
顾客可以用A TM卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。
（2）存款服务。
顾客可以把现金存入与ATM卡对应的账户中。
（3）转帐服务。
顾客可以把一个ATM卡对应的账户中的款项转帐到另一个ATM账户中。
（4）查询服务。
顾客能够查询一个ATM卡对应的账户中的余额。
该ATM系统包括以下组成部分：（1）能够读取ATM卡信息的读卡器。
（2）与客户进行交互的顾客控制台（包括键盘和显示器）。
（3）送出顾客所取现金的装置（下文中称为取款器）。
（4）用于放入存款的插槽（下文中称为存款器）。
（5）打印客户回执的打印机。
（6）启动和关闭A TM系统的开关键盘。
图ATM系统（7）ATM系统与ATM服务器通过特定的网络连接进行通信。
ATM系统在提供以上服务的过程中，必须满足以下要求：（1）一个顾客可以在最终确认前放弃一项交易。
（2）ATM在执行交易过程中将与ATM系统进行通信，对是否允许交易进行验证。
（3）ATM为每次成功的交易提供一个打印回执。
（4）ATM需要维护一个内部日志，对每次交易进行记录。
要求对ATM机软件系统进行建模，按照下列要求完成实验内容：（a）画出系统顶层和细化的用例图；（b）画出系统的分析类图；（c）选取用例图中的一个用例，画出它的序列图；（d）画出系统的体系结构图、构件图和部署图。
四、实验结果(一)顶层用例图(二)用户用例图(三)ATM用例图(四)分析类图(五)用户取款序列图(六)体系结构图<<实体>>银行卡<<边界>>读卡器<<边界>>银行网络<<实体>>日志<<控制>>ATM<<边界>>操作面板<<边界>>客户控制台<<边界>>打印机<<实体>>回执<<控制>>通信<<控制>>交易<<控制>>取款<<控制>>存款<<控制>>转账<<控制>>查询<<边界>>取款器<<边界>>存款器银行系统(七)组件图(八)部署图五、实验小结通过这次实验，基本掌握了UML绘图工具的使用，对于ATM系统的工作流程有了较完整的认识。
ATM用例描述及用例分析
问题描述：•银行有很多ATM机分布在城市的各个地方，并通过广域网与中心服务器相连；•每台ATM机都有读卡器、出钞机、键盘、显示器和收据打印机；•顾客可以通过ATM机从自已的银行帐户中取现金、查询余额、转帐；•顾客把ATM卡扦入读卡器就启动一个事务.在卡背面磁条中保存有ATM卡号、启用日期和截止日期，读卡器识别出卡后，系统将确认ATM卡是否过期;然后用户输入个人密码并和系统保存的个人密码匹配比较以检验是否正确或因挂失而禁用。
输入密码时最多可以尝试三次,连续三次输入关败， ATM卡将被没收，若ATM卡已挂失,也会被没收；•如果用户输入个人密码通过确认，ATM将提示客户可做取款、查询余额、转帐选择。
在开始取款前，系统要检查客户帐户是否有足够的钱，是否超过每天最高取款限额、出钞机是否有足够的现金；如果此事务可行,出钞机将按客户的要求的数额出钞、打印收据并退还ATM卡;任何时侯客户都可能取消事务，事务一旦终止，卡就被退出；客户记录、帐户记录都将保存在服务器中。
•为了给ATM机的出钞机装入现金以及进行日常维护，操作员可以启动或关闭ATM机。
UML ATM机结构类图UML表达的问题域的概念静态模型—实体类UML表达的 ATM机用例图《软件需求规格说明书》用例描述验证客户路经活动图UML表达的验证客户用例交互顺序图验证客户用例交互矩阵—类封装顺序图作用:1．作为交互分析的工具和方法；2．识别出用例中的类；3．分析交互的时间顺序;4．分析交互消息；5．进行类操作（消息）封装,与类的职责进行验证；《软件需求规格说明书》用例描述UML表达的取款用例交互顺序图ATM状态图实体类封装验证矩阵用例描述检查点检查标准：1．用例粒度是否符合用户的价值观点?2．是否按4W+DO模式书写用例描述?什么人(Who)在什么时间（When)和地点（Where)因为何种原因(Why）依据什么信息实体做(Do）什么事情以及做事情的条件、约束、规则、算法和结果；3．备选动作序列是否符合业务需求?4．用例描述其余属性是否一致和完整？11/ 11。
实验报告模板-用例描述完
基本流程
1.插卡2.选择转账选项3.用户输入转账账号4.系统验证转账账号5.用户输入转账金额6.系统验证转账金额输入是否符合要求7.系统验证用户账户余额8.系统显示转账账户及转账金额9.用户确认10.系统更新并保存账户信息
泛化用例
扩展用例
1.输入账户账号不正确
b.选择继续放入钞票或者结Fra bibliotek放钞包含用例
修改记录
用例名称
余额查询用例
标示符
用例描述
本用例主要描述客户从ATM机查询银行卡余额
参与者
用户与ATM
优先级
一级
状态
前置条件
ATM机无故障、插入银行卡、输入密码、余额查询操作
后置条件
无
基本流程
1.插卡2.输入密码3.选择余额查询功能4.系统显示账户余额及最大取款限额
软件建模与分析
实验报告
班级：
学号：
姓名：
完成日期：
实验一ATM取款机系统设计与分析
一、系统功能描述
该系统实现的功能有存款、取款、修改密码、余额查询和转账。
二、系统需求建模
1、分析
（1）参与者：ATM和客户
（2）用例：存款用例、取款用例、修改密码用例、查询余额用例、转账用例。
（3）用例图：
（4）用例描述
优先级
一级
状态
前置条件
ATM机无故障、插入银行卡、输入密码、存钱操作
后置条件
用户放入钞票、存入现金、系统更新账户存款金额
基本流程
1.插卡2.输入密码3.放入钞票4.系统显示存款金额5.用户选择继放钞或者结束放钞6.用户确认信息7.系统更新并保存账目信息
ATM银行系统用例图
UML建模语言7种图(以银行ATM系统为例)分类：JAVA 2010-04-21 20:40 705人阅读评论(0) 收藏举报1 用例图：描述了系统提供的一个功能单元。
以一种可视化的方式理解系统的功能需求，"角色"与系统内用例之间的关系。
本例中，参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
2 类图：显示系统的静态结构。
逻辑类、实现类，实现类就是程序员处理的实体。
类在类图上使用包含三个部分的矩形来描述，如图2所示。
最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说"方法"）。
本例中许多单个的帐户组成了帐户库，帐户具有帐户类型、帐户号、余额三个属性。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮助自己整理思路，充实及优化自己的设计。
3 序列图：显示具体用例（或者是用例的一部分）的详细流程。
它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。
本例以时间为顺序描述了顾客在ATM机上取款时信息的流动情况，顺序图着重于对象间消息传递的时间顺序。
4 状态图：表示某个类所处的不同状态和该类的状态转换信息。
包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。
本例描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。
UML-ATM提款系统设计
《基于UML的ATM系统设计》ATM自动取款机系统业务用例图.该系统主要有两个执行者：银行管理员和客户。
银行管理员会启动或参与的业务主要有添加现金、维护ATM硬件设备和协助客户改密码。
客户启动或参与的业务主要有修改密码、取钱、转账和查询余额。
ATM自动提款系统用例图1.名称：取款描述：用户插入卡片，并输入正确的密码后，系统连接上银行的数据库。
用户输入所需金额，系统在检查帐户余额后决定是否允许提供该服务。
预期结果：用户拿到需要的金额。
用户目标：用户想要取到所需的金额。
参加者：用户，押款人员，银行数据库。
依赖性：见图1-2前置条件：1. 用户帐号必须是有效帐号。
2. 用户必须正确登录。
3. 用户的帐户中的余额必须大于取款额。
方案：方案1：用户正常登录（插卡，输入正确密码）后，输入需要取的金额，所取金额小于帐户中的余额，取到需要的钱数。
方案2：用户正常登录后，输入需要取的金额，所取金额大于帐户中的余额，提示错误信息，要求重新输入，直到输入正确为止，拿到所输入的钱数。
方案3：与方案（2）相同，但提示错误信息后，决定停止该服务。
工作流：1. 用户正常登录。
2. 用户提出取款申请。
3. 后台数据库验证取款申请的合法性。
4. 更新数据该帐户的内容（减少帐户上的余额）。
5. 用户得到所需的钱。
6. 用户决定是否打印交易记录。
后置条件：帐户金额下降了，新的余额就是老的余额扣除提款金额。
商业规则：1. 顾客可以用银行卡从对应的帐户中支取现金，现金必须是100元的整数倍。
2. 用户一次提款最多为2,000元人民币。
3. 用户一天提款不得超过3次。
需求：1. 一个ATM系统必须支持每天500次的交易量。
2. 系统在无法完成该服务时，提出错误信息。
3. 系统在无法接待用户时，进入关闭状态。
实现注意事项：1. 用户可随时返回上一级菜单。
2. 用户可随时停止该服务。
3. 机器中没有所需钱数，提示错误信息。
2. 名称：用户转帐描述：用户需要利用A TM系统进行转帐业务期望结果：让用户得到成功转帐业务用户目标：后台数据库为用户转帐提供相应服务参与者/角色：后台数据库、用户依赖性：用户的转帐操作使用数据库响应转帐前置条件：用户登录A TM机,进入转帐子系统方案：1．用户登录A TM系统2．用户请求转帐服务3．用户得到相应服务工作流：1．用户登录ATM系统2．用户发送转帐请求3．系统响应用户的发送请求4．系统进行相应处理更新5．用户选择打印相关记录后置条件：用户得到转帐服务商业规则：1．用户每次输入的帐号应为合法帐号（帐号位数正确、不含非法字符等）2．用户每次欲转款额应小于规定的每次允许转出的款额,并且欲转款额应小于信用卡上的总余额3．用户每天的转帐次数不应超过规定值需求：多个用户可以在不同地点同时进行转帐业务注意事项：用户输入的帐号非法时或欲转的款额非法时，系统作何处理3. 名称：查询余额描述：期望结果：余额数量信息用户目标：用户得知余额数量参加者/角色：依赖性：前置条件：用户拥有一个账号，登录后台数据库方案/工作流：1.登录ATM2. 发出查询余额请求3.响应请求4.得到余额信息（扩展：打印回执单）后置条件：商业规则：需求：实现注意事项4、名称：存款客户将ATM卡插入读卡机，读卡机将信息传给客户管理系统，客户规律提出查询密码，ATM显示屏幕显示输入密码的请求，客户输入密码进入输入设备，输入设备将密码传递到客户管理系统，客户管理系统再将确认密码的请求传给ATM系统，ATM系统确认密码的合法性传到客户管理系统，客户管理系统将服务类别的询问通过显示屏幕显示出来，供客户选择服务类型。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ATM（自动取款机）的用例图、类图、顺序图、状态图、
活动图及协作图
1 用例图
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
银行储户在ATM机上完成取款、存款及其他业务。
2 类图
图2所示的银行系统类图和图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 机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。
同样对于一个真正的银行系统，这个类图过于简单。
比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。
而有些操作先定义为abstract，如余额的计算。
然后再继承这个abstract class，我们可以有saving account 和checking account等等。
不同的帐户有不同的余额计算方法，我们可以加上具体的算法。
对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。
通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
图2 银行系统类图
3 顺序图
图3描述了顾客在ATM机上取款时信息的流动情况。
以时间为顺序。
因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。
通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。
流程图对我们的设计起到了很好的帮助作用。
注意在本图没有一个生命线终端有一个"X"，这是因为这个流程中还未遇到有对象生命结束。
当有对象生命结束时需在对应的生命线终端画"X"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。
图3 ATM取款顺序图
4 状态图
图4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。
因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。
图4 ATM状态图
插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。
进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。
存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。
通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。
状态图可以帮助我们发现问题，并及时改正。
5 活动图
图5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，3图中的客户管理和事物管理对应于5图中的Bank，图3中的读卡机、显示、输入设备及点钞机对应于5图中的ATM Machina，银行储户就是Customer。
初看活动图和顺序图表达的意义很接近。
但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。
例如5图中fork和join处，我们可以很清楚的看到一些并行活动的存
在。
这个活动图以顾客插入卡为开始，以顾客取卡结束。
我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。
图5 ATM银行系统活动图
6 协作图
在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。
顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。
图6将3图转换为协作图。
1．插入ATM卡
2．接受ATM卡
3．查询密码
4．显示输入密码请求
5．输入密码
6．密码传递
7．请求确认密码合法性
8．确认密码合法性
9．询问服务类别
10．显示输入服务服务类别请求11．输入取款请求
12．取款请求
13．询问取款数额
14．显示输入数额请求
15．输入取款数额
16．传递取款数额
17．询问取款数额确认
18．显示确认数额请求
19．输入确认
20．传递确认信息
21．数额合法性确认请求22．确认数额和法性
23．出钞请求
24．计算帐户余额
25．出钞
26．取钞
27．传递余额并询问是否还需要其他服务
28．显示帐户余额并提示选择下面的服务
图6 ATM系统协作图
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。