UML(ATM系统)需求建模.doc

UML(ATM系统)需求建模 作者： 日期：19 个人收集整理 勿做商业用途金陵科技学院学生实验报告（理工类）课程名称：_面向对象分析和设计（UML）实验名称：_需求建模：用例关系图_ 专业班级：_M10计算机科学与技术_学生学号：_1021413036_学生姓名：_张_伟_实验学时: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. 确定需求.2. 创建 SRS。SRS 必须提供以下信息：软件系统定义、SRS 文档的用途、软件系统的范围、功能性需求、非功能性需求、目标软件系统的运行条件。3. 确定用例。用例应包含以下信息：名称、概要、事件的基本过程、可选路径、异常路径、触发器、假设、前置条件、后置条件、业务规则、非功能性需求、作者、日期.4. 确定角色。5. 描述用例和角色之间的关系。6. 保存模型。1 引言1。1目的为了明确用户的需求并较好的与开发人员进行沟通，使用户与开发人员双方对软件需求取得共同理解基础上达成的协议，特编写此文档，并作为整个软件开发的基础。1.2背景这个项目的开发是应InfoSuper银行要求，为其开发的一套ATM系统。InfoSuper 银行 45% 的收入来自个人银行业务。因此，银行希望进一步提升个人业务的服务质量并争取留住客户并提高他们的忠诚度。该银行进行了一次市场调查以了解客户在个人银行业务处理时间、满意度和资源需求方面的要求。 InfoSuper银行希望开发一个软件系统以通过改进的设施来减少客户访问银行的次数并提高客户服务。1.3定义：账号:在银行中，事物应用的单个账号。账号可以为多种类型，但是至少包括支票和存款。每个顾客可以拥有多个账号。ATM： 一个工作站终端，使得顾客能够使用现金卡在ATM上进行自己的事物处理.ATM同顾客进行交互，收集事物信息，并发送事物信息到中心计算机，由中心计算机确认和处理信息之后，将现金通过ATM提供给客户。银行：一个金融机构，负责保存顾客的账号信息。可以经授权访问账号。银行计算机： 银行拥有的计算机，同ATM网和银行自己的现金工作站进行交互。银行可以拥有自己的内部计算机网处理账号，但是我们只关心同网络进行交互的计算机。现金卡：每张卡提供给一个银行客户，授权客户可以使用ATM机访问自己的账号。每张卡包含一个银行代码和一个卡号，银行代码根据信用卡的国际标准进行编码，卡号确定卡能够访问的账户。一张卡不能访问客户的所有账户。每张卡只能有一个持卡人，但是多个复本可能存在,所有必须考虑从不同的ATM机同事使用相同卡的行为。客户： 拥有银行的一个或者多个账号的人。客户可以包括一个人或者多个人，或者是公司。相同的人，拥有不同银行的账号被认为是不同的客户。事物： 对单个客户账号的单个完整的操作请求。2 项目概述2。1对开发软件的一般描述这个项目的开发是为银行提供一套高效稳定的终端服务平台，使得银行与客户间的业务办理更方便、便捷和安全。2。2对开发软件的功能描述该软件可以划分为两个子系统，一个是服务银行储户的，即是持卡人的交易系统;另一个是服务银行工作人员的。银行工作人员分为两类:一类是业务人员,可以使用本系统进行配款，统计，打印报表，一类是技术人员，对本系统进行管理维护。本系统其基本框架为：数据库控制程序客户端应用程序ATM系统图1 ATM系统框架图2.3用户特点本软件的用户主要是银行的广大持卡人，大多都具有使用ATM经验。另外，我们的系统要实现的一个重要目标就是有足够的界面友好性和易操作性。即使是一个对ATM系统完全陌生的客户，也可以在交易界面的提示下顺利完成交易。另外一部分的用户是银行工作人员，大致分为两类：一类是业务人员。其依赖本系统管理ATM交易参数，统计交易信息，打印各类汇总报表，根据ATM提示及时配款.另一类是银行技术人员。其对本系统进行升级，维护工作。3系统用例模型3.1确定角色自动取款机（ATM）中央计算机银行工作人员储户账户事务现金卡3.2确定角色关联1储户拥有账户2工作人员输入-针对账户的事务3中央计算机-处理-针对账户的业务 4ATM与中央计算机交换关于事务的信息5中央计算机确定事务与分析的对应关系6ATM-读现金卡7ATM-交互用户8中央计算机-处理并发的访问3.3创建用例1 储户取钱2 储户存钱3 储户转账4 储户更改密码5 储户查询余额6 储户查询交易概要7 银行工作人员统计报表8 银行工作人员打印报表9 银行工作人员维护ATM 10银行工作人员对ATM机配款4需求说明4。1 基本描述ATM终端可以接受一张可识别的银行储蓄卡，通过储户身份验证后，同储户进行各种交互,处理储户要求，执行各类操作，为储户服务。系统要求保持一定时间内的交易记录，可以处理多个ATM终端并发访问。同时,系统应每天自动汇总各种交易数据，生成报表。系统24小时工作，无操作时播放待机动画广告。系统具有设备自检提示报错功能，可以提示凭条打印机已坏，ATM终端钱柜缺钱。如图2 ATM工作示意图：ATM终端交易ATM终端交易ATM终端交易ATM机打印报表统计信息配 款系统维护银行工作人员操作储户操作图2 ATM系统工作示意图4.2 功能需求针对InfoSuper银行对该软件的需求,做如下功能设计，在给出基本框架之后,我们将逐一介绍各部分。根据用户的不同身份分为两个模块，每个模块包含了不同的功能：管理模块：管理维护功能，配款功能，统计和打印报表功能储户模块：存款功能，取款功能,修改密码功能，转账功能,查询余额功能，查询交易概要功能如图3 ATM系统功能模块图所示:ATM系统存款管理模块取款转账修改密码查询余额储户模块配款统计报表管理维护交易概要打印报表图3 ATM系统功能模块图本系统按上述功能,设计其需求用例图如图4ATM系统用例设计图所示： 图4 ATM系统需求用例图图5第二迭代用例模型图6第三迭代用例模型4.2。1 储户模块1。 功能需求简介功能需求1: 描述：ATM终端无人操作时，显示待机动画输入:无处理：ATM显示待机界面输出:显示待机界面功能需求2：描述：ATM接受卡,检验卡是否可进行交易输入:ATM接收储户插卡处理：检验卡是否可识别处理输出：不可识别退卡；否则继续。功能需求3：描述：校验密码是否格式正确输入：储户输入密码处理：校验密码是否符合格式输出：不正确则提示储户重新输入功能需求4:描述：校验密码是否正确输入：储户输入正确格式密码处理：校验当前密码与存储的账户密码是否一致输出：不一致则提示密码错误，请重新输入或者退卡功能需求5:描述：卡密码连续三次输入错误,没收磁卡输入：储户连续第三次输入密码处理：校验密码输出：错误则吞食磁卡，提示“您的卡连续三次密码错误,已被吞没。请联系客服955*”功能需求6：描述：磁卡认证完成，进入主交易界面输入：储户输入正确密码处理：校验密码输出：显示主交易界面功能需求7：描述：ATM现金不足,系统应对取款储户进行提示，可退出交易输入：无处理：检查ATM现金数输出:返回至ATM主交易界面功能需求8：描述：ATM凭条打印机故障，系统应对存款和转账储户进行提示,可退出交易输入：无处理：检查ATM凭条打印机输出：故障则提示储户是否继续,可返回至主交易界面功能需求9：描述：ATM认定的存款金额储户不认可输入：认证成功完成，输入需要存储的金额,将钞币放入ATM机处理：硬件检验钞币数量，提示储户确认，储户输入“否输出：退出钞币,返回主界面功能需求10：描述:ATM存款输入:ATM认定存款金额,储户“确认”处理:在账号上记录存入金额输出：打印存款凭条，显示“交易成功”，返回主交易界面功能需求11:描述：取款金额大于账户余额输入：输入取款金额处理：判断输入金额和账户余额输出:取款余额大,则提示储户“余额不足”，返回主界面功能需求12:描述：取款数额超过当日取款最大额度输入：储户输入取款金额处理：判断输入金额和当日该账户ATM取款额之和是否大于当日取款最大额度输出:如超出则提示储户“超过当日取款最大额度，重新输入或返回功能需求13:描述：取款输入:取款合法金额处理：从账户记录取走的金额输出：吐钱功能需求14:描述：取款交易成功，打印取款凭条输入：储户输入“打印”或者“不打印”处理:若是“打印”则打印机打印凭条，否则什么也不做输出：无功能需求15:描述:修改密码输入：储户输入新密码处理:两次新密码判断是否一致输出：一致则重置密码，显示“修改成功；否则退出修改密码功能需求16:描述：转账输入:转账账号，转账金额处理：判断金额是否超过本账户现有金额，是则本账号下账，他账号上账输出：显示“转账成功”,或者退出转账2。 use case在以下所有用例中，假设储户已进入主交易界面.用例编号UC01用例名称取款创建人 张伟最后修改人 张伟创建日期 2010/10/26最后修改日期2010/11/02角色取款人描述取款人输入取款金额，币种，面值等。系统判断账户正常且金额允许后提供款给他。前置条件 取款身份验证合法后置条件 无主干过程1.0从ATM取款取款人指定所需金额，币种，面值 系统接受请求，从账户扣钱 取款人输入其他信息，结束此次取款 系统保存交易信息分支过程 1。1账户余额不足 系统提示“您输入的取款金额超过您的账户余额” 系统返回主交易界面，结束此次取款 1。2单笔超限或当日取款总额超限 系统提示“输入金额不对，单笔不能超过5000”系统返回主交易界面,结束此次取款 1.3 ATM余额不足 系统提示“很抱歉，ATM余额不足,暂时不能为您服务 系统返回主交易界面,结束此次取款异常 1.0。E。1账户状态非法（被冻结或强制冻结) 系统提示“账户异常，您的卡被强制收回,如有疑问请拨955” 吞卡系统返回主交易界面，结束此次取款 1。0.E。2 账户状态异常（挂失中） 系统提示“您的账户处于挂失中” 系统返回主交易界面，结束此次取款 系统返回主交易界面，结束此次取款 1.0。E。2 账户状态异常（卡已注销） 系统提示“本卡已被注销，卡将被收回，请确认 系统返回主交易界面，结束此次取款包括用例优先级 高使用频率 很高，峰值每小时20次业务规则特殊需求假设 备注与问题用例编号 UC02用例名称 存款创建人 张伟最后修改人张伟创建日期2010/10/26最后修改日期2010/11/02角色存款储户描述存款人选择存款交易。储户塞入钞票，ATM输出金额，储户确认后，系统上账,打印凭条，退卡前置条件 存款人是合法储户，通过验证 账户状态正常 储户信息数据库在线 所需ATM硬件就绪后置条件 无主干过程2。0从ATM存款存款人塞入钞票系统硬件点钞，输出显示金额储户确认数额系统处理数据，给账户加钱打印存款凭条返回主界面，此次存款交易结束异常过程 2。0.E。塞入钞票机器不认识 系统提示“您的钞币不能识别，请检查 ATM吐钱 系统返回主交易界面，结束此次取款包括用例 优先级 高使用频率高,峰值10次每小时业务规则特殊需求假设备注与问题用例编号UC03用例名称修改密码创建人 张伟最后修改人张伟创建日期2010/10/26最后修改日期2010/11/02角色卡储户描述存款人选择修改密码交易。系统要求储户连续两次输入新密码，一致则修改密码。前置条件存款人是合法储户，通过验证 账户状态正常 储户信息数据库在线后置条件 交易信息被保存在账户资料中主干过程3.0修改账户密码储户输入两次新密码两次新密码一致，系统修改账户密码屏幕显示输出“修改成功”，储户确认返回主界面,此次修改密码交易结束交易信息存入账户流水分支过程 3。1两次新密码不一致 系统提示“输入的新密码不一致，请重输或者退出修改密码 储户选择重新输入，返回主干过程 系统返回主交易界面,结束此次取款包括用例 优先级中使用频率中，峰值5次每小时业务规则 修改密码的储户无需再输入原密码，储户身份已经被认证特殊需求 假设 备注与问题 细节问题,例如密码输入3位后直接按确认的处理,不讨论用例编号UC04用例名称系统内本卡账户转账至他账户创建人 张伟最后修改人张伟创建日期2010/10/26最后修改日期2010/11/02角色储户描述储户提供他账户，转账金额，（系统不保证转账账户正确）,确认.系统从本账户下账，转账账户上账。前置条件 存款人是合法储户，通过验证 账户状态正常 储户信息数据库在线后置条件 无主干过程 4。0系统内部转账储户选择转账功能 储户输入账户，金额系统要求确认，储户确认系统执行处理：本地账户下账,他账户上账打印转账凭条返回主界面，此次转账交易结束包括用例 优先级中使用频率中，峰值5次每小时业务规则实现功能钱从本卡转至他账户特殊需求 假设 备注与问题 用例编号 UC05用例名称 查询余额创建人 张伟最后修改人张伟创建日期2010/10/26最后修改日期2010/11/02角色卡储户描述存款人选择查询余额交易。系统显示输出账户余额前置条件存款人是合法储户，通过验证 账户状态正常 储户信息数据库在线后置条件 无主干过程5.0查询余额储户选择查询余额功能 系统屏幕输出账户余额返回主界面,此次修改密码交易结束包括用例 优先级 较高使用频率 较高，峰值10次每小时业务规则 特殊需求 假设 备注与问题 4.2。2 管理模块功能需求17：描述:打印报表输入：业务人员启动打印程序处理:系统自动生成日，月，年各种报表输出:无功能需求18：描述：自动升级或维护输入：工作人员启动升级程序处理：自动获取升级文件，终止系统，升级,重启ATM系统输出：显示“升级成功，版本号*。*”4.3 性能需求在查询过程中，要求系统显示该账户卡上所有的余额。在取款过程中，该系统只支持交易金额为100的倍数。在存款过程中，该系统只支持交易金额为50的倍数。在转帐过程中,该系统支持任何储户输入的数据，但是仅仅限于本行之间的账户转帐。如果交易中响应时间超过30秒，系统提示“操作已过时”，自动退出本系统。交易结束时,系统知道更新账户上的数据，保持账户余额的一致性。交易完成后,储户可以点击“取卡”退出本系统.本系统可以进行各个银行的金额交易.系统可以并行使用的储户在100个以上。注意：当交易金额超过当前账户余额时,系统自己提示“余额不足”，自动退出本系统,当系统遇到任何不对输入时都自动退出本系统.4.4对输入输出的规定密码：由储户设置的一个6位整数。取款数目：只支持交易金额为100的倍数.取款金额:不能输入5000以上的数字存款数目：只支持交易金额为50的倍数。转账数目：支持储户输入的任何数据，但是仅限于内间账户转账。响应时间:30秒以内.注意：如果输入、输出违反以上规定，则系统退出，返回到登陆页面. 5 实验体会随着学习UML的深入，越来越发现UML的强大之处。通过两周对ATM系统的用例关系的设计，使我有了这种感觉它决不是简单的画图而已.在实验的开始阶段通过查阅大量的书籍，掌握了UML案例的基本设计方法，再加上实践,从而慢慢理解了用UML语言设计建模的特点：1.分步有序，每一阶段由每一阶段的目标，成果。一步一步走,水到渠成。不要跨越阶段，否则欲速则不达。2。不是每个逻辑、流程都需要精确分析，那样做耗时耗力，一般项目都有日程表，不允许无限制的细化。分析的目的是搞清核心逻辑、流程.3.不要总想在一张图中表现出所有类型的关系，每种图有它的特点,适合分析描述那些关系.即使把所有都画在一张图里也会很乱,搞不清楚。 在掌握新知识的同时，在建模过程中,也遇到一些问题，诸如角色与用例的关系的确定，一些修改影响了其他模图的建立,通过询问指导老师和上网查找资料，得到了比较满意的解决。在这次实验中，关于UML的概念以前比较模糊的地方，我在实际操作中，变得更加清楚了,对UML用例运用的更加系统，更加熟练；但是更让我明白,UML的知识是十分丰富的,我现在的认识还不够，我将会在以后的学习中，不断提高自己的UML知识。