第一篇：UML建模--银行管理系统（范文）
银行管理系统的UML
建模
课程设计报告
专业：
学号：
姓名：
任课教师：
一、系统概述
银行是与人们生活密切相关的一个机构，银行可以提供存款、取款、转账等业务。在银行设立账户的人或机构被称为银行的客户（customer）。一个客户可以在银行开设多个账户（account），客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。另外，客户可以随时查询自己的账户情况，以及查询以前所进行的存款、取款等交易记录。客户还有权利要求关闭自己的账户。
实际生活中的银行功能其实还要复杂得多，但为了简化系统，本次设计只考虑银行的基本功能。简化版的银行信息系统至少应具有如下功能：
1.一个银行可以有多个账户； 2.一个银行可以有多个客户； 3.一个客户可以持有多个账户； 4.一个账户可以有多个持有者； 5.银行可以为客户开设账户； 6.银行可以为客户注销账户； 7.客户可以从自己账户中取钱； 8.客户可以向自己账户中存钱；
9.客户可以在同一银行的不同账户之间转账； 10.客户可以在不同银行的不同账户之间转账； 请完成登录、存款、取款、转账和查询几个模块的设计。
二、需求分析
银行系统是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行设立账户的人或机构通常被称为银行的储户。一个储户可以在银行开多个账户，储户可以存钱到账户中，也可以从自己的账户中取现，还可以将存款从一个账户转到另一个账户。储户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。后台管理员可以对客户的账户进行注销、删除、查询等管理，还有就是银行利息、汇率、手续费之类参数的设置，以及财务管理以及财务分析。
软件分别有开户，查询存取款，转账等功能。各个模块各有不同的功能，但都能完成查询和存取功能。各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成。
此软件所要完成的主要功能有三方面：如果是存款，用户填写存款单，然后交给收银员键入系统，同时系统还要记录存款人姓名，住址，身份证号码，存款类型，存款日期，利率及密码（可选）等信息，完成后由系统反馈成功存款信息给用户。如果是取款，用户填写取款的相关信息（取款金额、取款币种）进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息单给用户。如果是转账，用户填写转账的相关信息进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并反馈信息给用户。系统及时更新数据库。
外部功能：实现化窗口，开户/销户、存款/取款、查询/转账。
内部功能：同步，过滤，定位，识别，更新，连接。
三、系统的UML基本模型
（1）、用例图
通过分析对银行管理系统的需求分析，确定参与者有银行客户、收银员。收银员具有维护系统信息、维护客户信息、查询客户情况和处理处理客户需求的作用。用例包括：
1）开户、2）存款、3）取款、4）转账、5）查询、6）销户等
（2）、用例描述：
用例名称：银行信息系统
描述：银行客户对需要办理业务的需求以及收银员对事件的处理。
（3）、银行信息系统的事件流
1.用例存款的事件流
1.1 前置条件
在存款之前，客户已经办理银行账号并且带来现金若干，并到达银行网点。1.2 后置条件
如果这个用例成功，这个存款事件是成功的，否则，系统没有变化。1.3 扩充点
无 1.4 事件流
1.4.1 基流（1）客户将银行卡交给收银员。
（2）收银员要求客户输入卡密码。
（3）客户输入卡密码，并确认密码。
（4）收银员提示，请客户选择服务类型。
（5）客户选择存款服务。
（6）收银员提示：存款数目。
（7）客户说出数目，并把钱交给收银员。
（8）收银员完成服务。
（9）收银员退还卡。1.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
2.用例转账的事件流
2.1 前置条件
在转账之前，客户已经办理银行账号，被转账人的账号已经存在并且已经知道了对方的账号。
2.2 后置条件
如果这个用例成功，这个转账事件是成功的，否则，系统没有变化。2.3 扩充点
无 2.4 事件流
2.4.1 基流
（1）客户填写转账单。
（2）客户把转账单和银行卡交给收银员。
（3）收银员要求客户输入卡密码。
（4）客户输入卡密码，并确认密码。
（5）收银员转账成功。
（6）收银员退还卡。2.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
3.用例查询的事件流
3.1 前置条件
在查询之前，客户已经办理银行账号并且携带银行卡，并到达银行网点。3.2 后置条件
如果这个用例成功，这个查询事件是成功的，否则，系统没有变化。3.3 扩充点
无 3.4 事件流
3.4.1 基流
（1）客户将银行卡交给收银员。
（2）收银员要求客户输入卡密码。
（3）客户输入卡密码，并确认密码。
（4）收银员提示，请客户选择服务类型。（5）客户选择查询服务。
（6）客户说出查询内容，收银员将内容反馈给客户。
（7）收银员完成服务。
（8）收银员退还卡。3.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
（4）、活动图
活动图是基于对象的状态变迁所绘制的视图。
收银员首先凭着自己的系统用户名和密码登录系统，收银员可以通过银行客户提供的有效证件号开户，提供客户账号开户、存款、取款、转账、查询、销户等功能，最后退出系统。
1．存款活动图
2．转账活动图
3．查询活动图
（5）、时序图
时序图（Sequence Diagram）主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。收银员通过用户账号和密码登录系统，在系统的操作窗口对需要存款、取款、转账、查询、销户的用户进行操作，最后退出操作窗口。
我们所开发的银行管理系统时序图如图所示：
（6）、类图
类图是对象结构建模的一部分，类图描述系统中类的静态结构。类图是代码生成（将模型转化为代码）的来源，也是逆向工程（将代码转化为模型）的目标设生成物。
类图设计如下图：
系统中主要的类（1）用户类： 它的属性有用户名（Name）、密码（Password）、银行卡号（Cardnumber）、用户身份证号码（ID）。
操作包括修改密码（Changpassword）、存款（deposit）、取款（cash）、转账（transfer）、查询（Chaxun）、、用户开户（Registered）。
（2）系统类：
它的属性有电脑号（Computernumber）、机器地址（Mac）。本身的操作没有，但有被管理员使用的操作。（3）收银员类：
它的属性有用户名（name）、密码（password）。
操作包括用户开户（Registeredusers）、注销用户（Deleteusers）、查询用户信息（Chaxun）、系统维护（Weihu）。
（7）状态图
状态图用来表示建模对象是如何改变其状态的，状态定义为对象行为在某一时刻的快照或转折点。
四、结论
系统主要的实现目标是实现客户开户、存款、取款、转账、查询、销户和后台服务器端系统的设计，提供完善的功能设计。
五、总结及心得体会
UML工具很好的帮助我们实现了对银行信息系统的设计，通过UML建模，把事物从抽象到实例化的过程，对每个对象进行细化分析，从而得到简单而方便，容易理解的模型结构。通过此次试验收获很大，使我们认识到了通过UML模型可以高效完成软件设计，收获颇丰。
一、开发背景与目标
1.1开发背景
本系统选题为银行存储系统，是模拟银行存储开发的。随着计算机的飞速发展及应用领域的扩大，特别是计算机网络和电子商务的发展，极大的改变了商业银行传统的经营模式。能够为客户提供方便、快捷、安全的服务，也能够有效的降低银行的营运成本，这是银行存储系统追求的目标。目前，对于现代化银行运营的要求是客户可以实现方便安全的业务交易，银行职员可以进行高效合理的工作管理，实现银行业务电子化
在银行管理系统中，系统包括4个节点，分别是：银行管理员业务处理节点、ATM自动取款机节点、系统维护节点、数据库节点。
银行管理员业务处理节点，银行管理员通过该节点办理相应业务； ATM自动取款节点，用户通过该节点进行自动取款服务；
系统维护节点，系统管理员通过该节点进行后台维护，执行银行管理员允许的所有操作；数据库节点，负责数据的存储与处理。
谁使用系统的主要功能?谁改变系统的数据? 谁从系统获取信息? 谁需要系统的支持才能完成日常的工作任务?谁负责维护,管理并保持系统的正常运行?系统需要应付,处理那些硬件设备?系统需要和那些外部系统交互?谁(或是什么)对系统运行产生的结果感兴趣?
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求
第二篇：UML建模--银行管理系统
银行管理系统的UML
建模
课程设计报告
专业：
学号：
姓名：
任课教师：
一、系统概述
银行是与人们生活密切相关的一个机构，银行可以提供存款、取款、转账等业务。在银行设立账户的人或机构被称为银行的客户（customer）。一个客户可以在银行开设多个账户（account），客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。另外，客户可以随时查询自己的账户情况，以及查询以前所进行的存款、取款等交易记录。客户还有权利要求关闭自己的账户。
实际生活中的银行功能其实还要复杂得多，但为了简化系统，本次设计只考虑银行的基本功能。简化版的银行信息系统至少应具有如下功能：
1.一个银行可以有多个账户； 2.一个银行可以有多个客户； 3.一个客户可以持有多个账户； 4.一个账户可以有多个持有者； 5.银行可以为客户开设账户； 6.银行可以为客户注销账户； 7.客户可以从自己账户中取钱； 8.客户可以向自己账户中存钱；
9.客户可以在同一银行的不同账户之间转账； 10.客户可以在不同银行的不同账户之间转账； 请完成登录、存款、取款、转账和查询几个模块的设计。
二、需求分析
银行系统是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行设立账户的人或机构通常被称为银行的储户。一个储户可以在银行开多个账户，储户可以存钱到账户中，也可以从自己的账户中取现，还可以将存款从一个账户转到另一个账户。储户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。后台管理员可以对客户的账户进行注销、删除、查询等管理，还有就是银行利息、汇率、手续费之类参数的设置，以及财务管理以及财务分析。
软件分别有开户，查询存取款，转账等功能。各个模块各有不同的功能，但都能完成查询和存取功能。各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成。
此软件所要完成的主要功能有三方面：如果是存款，用户填写存款单，然后交给收银员键入系统，同时系统还要记录存款人姓名，住址，身份证号码，存款类型，存款日期，利率及密码（可选）等信息，完成后由系统反馈成功存款信息给用户。如果是取款，用户填写取款的相关信息（取款金额、取款币种）进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息单给用户。如果是转账，用户填写转账的相关信息进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并反馈信息给用户。系统及时更新数据库。
外部功能：实现化窗口，开户/销户、存款/取款、查询/转账。
内部功能：同步，过滤，定位，识别，更新，连接。
三、系统的UML基本模型
（1）、用例图
通过分析对银行管理系统的需求分析，确定参与者有银行客户、收银员。收银员具有维护系统信息、维护客户信息、查询客户情况和处理处理客户需求的作用。用例包括：
1）开户、2）存款、3）取款、4）转账、5）查询、6）销户等
（2）、用例描述：
用例名称：银行信息系统
描述：银行客户对需要办理业务的需求以及收银员对事件的处理。
（3）、银行信息系统的事件流
1.用例存款的事件流
1.1 前置条件
在存款之前，客户已经办理银行账号并且带来现金若干，并到达银行网点。1.2 后置条件
如果这个用例成功，这个存款事件是成功的，否则，系统没有变化。1.3 扩充点
无 1.4 事件流
1.4.1 基流（1）客户将银行卡交给收银员。
（2）收银员要求客户输入卡密码。
（3）客户输入卡密码，并确认密码。
（4）收银员提示，请客户选择服务类型。
（5）客户选择存款服务。
（6）收银员提示：存款数目。
（7）客户说出数目，并把钱交给收银员。
（8）收银员完成服务。
（9）收银员退还卡。1.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
2.用例转账的事件流
2.1 前置条件
在转账之前，客户已经办理银行账号，被转账人的账号已经存在并且已经知道了对方的账号。
2.2 后置条件
如果这个用例成功，这个转账事件是成功的，否则，系统没有变化。2.3 扩充点
无 2.4 事件流
2.4.1 基流
（1）客户填写转账单。
（2）客户把转账单和银行卡交给收银员。
（3）收银员要求客户输入卡密码。
（4）客户输入卡密码，并确认密码。
（5）收银员转账成功。
（6）收银员退还卡。2.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
3.用例查询的事件流
3.1 前置条件
在查询之前，客户已经办理银行账号并且携带银行卡，并到达银行网点。3.2 后置条件
如果这个用例成功，这个查询事件是成功的，否则，系统没有变化。3.3 扩充点
无 3.4 事件流
3.4.1 基流
（1）客户将银行卡交给收银员。
（2）收银员要求客户输入卡密码。
（3）客户输入卡密码，并确认密码。
（4）收银员提示，请客户选择服务类型。（5）客户选择查询服务。
（6）客户说出查询内容，收银员将内容反馈给客户。
（7）收银员完成服务。
（8）收银员退还卡。3.4.2 替代流
如果输入的密码无效，用户可以重新输入密码或者终止用例。
（4）、活动图
活动图是基于对象的状态变迁所绘制的视图。
收银员首先凭着自己的系统用户名和密码登录系统，收银员可以通过银行客户提供的有效证件号开户，提供客户账号开户、存款、取款、转账、查询、销户等功能，最后退出系统。
1．存款活动图
2．转账活动图
3．查询活动图
（5）、时序图
时序图（Sequence Diagram）主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。收银员通过用户账号和密码登录系统，在系统的操作窗口对需要存款、取款、转账、查询、销户的用户进行操作，最后退出操作窗口。
我们所开发的银行管理系统时序图如图所示：
（6）、类图
类图是对象结构建模的一部分，类图描述系统中类的静态结构。类图是代码生成（将模型转化为代码）的来源，也是逆向工程（将代码转化为模型）的目标设生成物。
类图设计如下图：
系统中主要的类（1）用户类： 它的属性有用户名（Name）、密码（Password）、银行卡号（Cardnumber）、用户身份证号码（ID）。
操作包括修改密码（Changpassword）、存款（deposit）、取款（cash）、转账（transfer）、查询（Chaxun）、、用户开户（Registered）。
（2）系统类：
它的属性有电脑号（Computernumber）、机器地址（Mac）。本身的操作没有，但有被管理员使用的操作。（3）收银员类：
它的属性有用户名（name）、密码（password）。操作包括用户开户（Registeredusers）、注销用户（Deleteusers）、查询用户信息（Chaxun）、系统维护（Weihu）。
（7）状态图
状态图用来表示建模对象是如何改变其状态的，状态定义为对象行为在某一时刻的快照或转折点。
四、结论
系统主要的实现目标是实现客户开户、存款、取款、转账、查询、销户和后台服务器端系统的设计，提供完善的功能设计。
五、总结及心得体会
UML工具很好的帮助我们实现了对银行信息系统的设计，通过UML建模，把事物从抽象到实例化的过程，对每个对象进行细化分析，从而得到简单而方便，容易理解的模型结构。通过此次试验收获很大，使我们认识到了通过UML模型可以高效完成软件设计，收获颇丰。
第三篇：UML(ATM系统)动态建模
实验3 动态建模
一、实验目的与要求 掌握分析ATM系统用例中用例的流程，分析对象之间的交互关系 掌握用UML设计参与对象之间的交互，用状态图、时序图、协作图和活动图来描述系统的行为。
二、实验设备、环境
PC(一台)，Windows 2000或以上版本，安装Microsoft Visio 2003
三、实验内容及步骤 交互图：实现ATM系统的序列关系图和通信（协作）关系图； 2 分析设计软件系统的状态图。（（1）和（2）选做一个状态图）；
（1）ATM系统
（2）具体题目如下：某销售POS机，它的工作流程是：当客户到收银台后，收银员逐一输入用户购买的商品，输入完之后，计算出总金额，然后等待用户付款，确定支付成功之后，完成收银，等待下一个客户。请为其绘制出相应的状态机图。
3分析设计ATM系统的活动图（选做1个活动图）。
建立动态模型：
建立序列关系图、状态图、活动图
步骤：
编写脚本
确定各个对象之间的事件
构造事件追踪图（交互图）
构造状态图
添加活动和动作
一、时序关系图
1）ATM系统的正常情况脚本
ATM请储户插卡；储户插入一张现金兑换卡。 ATM接受该卡并读它上面的卡号。
ATM要求储户输入密码；储户输入自己的密码“1234”等数字。
ATM请求系统验证卡号和密码；核对储户密码，然后通知显示器显示说这张卡有效。
ATM要求储户选择事务类型（取款、转账、查询等）；储户选择“取款”。 ATM要求储户输入取款额；储户输入“880”。
ATM确认取款额在预先规定的限额内，然后要求处理这个事务；成功处理完这项事务并返回该账户的新余额。
ATM吐出现金并请储户拿走这些现金；储户拿走现金。 ATM问储户是否继续这项事务；储户回答“不”。
ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。 ATM请储户插卡。
2）ATM系统的异常情况脚本
ATM请储户插卡；储户插入一张现金兑换卡。 ATM接受该卡并顺序读它上面的数字。
ATM要求密码；储户误输入“8888”等数字。
ATM请求总行验证卡号和密码；经验证发现密码错误，拒绝这张卡。 ATM显示“密码错”，并请储户输入密码；储户输入“1234”等数字；ATM请求总行验证后知道输入密码正确。
ATM要求储户选择事务类型；储户选择“取款”。
ATM询问取款额；储户改变主意不想取款了，按“取消”。 ATM退出现金兑换卡，请储户拿走它们；储户取走卡。 ATM请储户插卡。
ATM 脚本的事件时序图如下图所示：（正常情况）
用户读卡器显示器ATM卡用户账户事务提款机插卡读卡初始化提示输入密码输入密码验证密码获取密码获取账户初始化提示选择业务选择业务执行事务初始化提示输入金额输入金额获取余额验证取款金额计算余额计算利息更新账户配给现金打印收据退卡
二、状态图
主屏]do：显示主屏幕插卡[可读]Do：要求密码输入密码Do:验证账户继续密码错拿走卡退卡do：退卡请拿走卡插卡[不可读]不可读的卡do：显示信息取消取消do:显示取消信息无效账户账户有效Do:要求类型取消输入类型Do:要求金额取消结束do：打印账单Do:显示无效账户信息输入金额等待5秒Do:处理事务中止取消Do:请求继续拿走现金do：吐出现金请拿走现金事务成功取消事务失败Do:失败信息网络响应等待网络响应中断do：显示取消信息ATM类的状态图
处理事务验证账户请求处理事务请求验卡事务成功事务失败无效账户账户有效密码错
事务处理状态图
账户验证状态图
三、活动图
插卡<没有接收动作>输入密码<没有接收动作>输入账户类型输入金额取卡取钱<没有发送动作>
四、实验体会
顺序图的重点是完成某个行为的对象类之间所传递的消息的时间顺序。一个顺序图事务对象角色，生命线，激活期和消息构成。协作图用于描述系统的行为是如何有系统的成分合作实现的。协作时一种静态结构，是一个系统对实现某些服务所涉及的对象及其交互的投影。一个协同定义了一组对某些服务有意义的参加者和它们的联系，这些参加者定义了交互中的对象所扮演的角色。
第四篇：基于UML的图书馆管理系统建模设计
基于UML的图书馆管理系统建模设计
一、图书馆管理系统可行性分析
随着政府机关与广大企事业单位内部网络的广泛建立，在通用信息平台上构筑高效实用的协同工作和自动化办公应用系统，满足信息高度共享和即时发布的需求，有效实现内部知识管理，已成为众多用户的共同需求。
该图书管理系统，为图书馆管理提供了一个较好的解决方案。在开发过程中，按照软件工程的步骤，从设计到开发采用了面向对象的思想和技术，采用了SQL SERVER 2000数据库，使得本系统可以方便的和其他子系统进行数据交换。同时，注意从软件的图形应用界面上优化软件质量，使得本系统具有很强的可操作性。
二、需求分析
需求分析的目的是深入描述软件功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。2．
1、客户需求分析
①能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。
②能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。
③提供方便的查询方法。如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。
④提供旧书注销功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。
⑤能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。⑥对所借图书情况进行登记，包括借阅时间、借阅人等 ⑦对超出借阅时间、损坏或丢失图书的读者进行相应处理 ⑧读者可以查询自己的信息 ⑨借书、还书、续借书
2．2 定义系统的边界和范围 该系统的边界为学校的图书馆
该系统的范围可包括“读者管理子系统”、“书籍管理子系统”、“借阅管理子系统”、“系统管理子系统” 2.3确定执行者
根据前面介绍的客户需求分析可以看出。“图书馆管理系统”有三个执行者，即“读者”、“图书管理员”、“系统管理员”
1）2）读者：查询个人信息、查询图书信息、借阅图书、返还图书、续借图书、接受相应处理
图书管理员：借书处理、还书处理、新旧书登记处理、办理相应处理手续
3）系统管理员：系统维护工作——学生信息管理、图书信息管理、系统状态维护 2.4确定用例
（1）“图书馆管理系统”中的用例
在第一层，根据客户对“图书馆管理系统”的整体业务功能要求，可选的用例有：
·基本业务功能管理
·基本数据修改 ·信息查询
·数据库管理
（2）“基本业务功能子系统”中的用例
在第二层，客户对“基本业务功能子系统”的整体业务功能要求，可选的用例有： ·借阅管理 ·借书
·续借书 ·还书
（3）“基本数据修改功能子系统”中的用例
在第二层，客户对“基本数据修改功能子系统”的整体业务功能要求，可选的用例有： ·读者信息管理 ·读者信息录入 ·读者信息修改 ·读者信息注销 ·书籍信息管理 ·书籍信息录入 ·书籍信息修改
·书籍信息注销（4）“信息查询子系统”中的用例
在第二层，客户对“信息查询子系统”的整体业务功能要求，可选的用例有： ·图书信息查询 ·读者信息查询
（5）“数据库管理子系统”中的用例
在第二层，客户对“数据库管理子系统”的整体业务功能要求，可选的用例有： ·借阅管理 2.5分层绘制用例图
根据系统需求分析中客户对系统的功能要求，我们一确定了系统和子系统的边界、执行者和用例，现在就可以绘制用例图了。
1． 最高层用例图
根据客户对“图书馆管理系统”的整体业务功能要求，可以绘制如图1-1所示的最高层用例图 2． 第2层用例图
在第2层用例图中包括四个用例图：基本业务功能子系统、基本数据修改功能子系统、信息查询子系统、数据库管理子系统。如下图所示：
System<
System读者信息销毁<
System借阅管理系统管理员图1-5 数据库管理子系统
2.6 描述用例
1．“借书”用例
用例编号：0102（共有两层用例图，每层用2位数字表示，采用4位编号）用例名：借书
执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：借阅图书
过程描述：
（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“借阅”（2）输入图书证编号
若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书；（3）输入图书编号
若读者已借满，提示“您已借满，请先归还部分图书再来借，谢谢！”；若读者可以正常 4 借阅，提示“您确定要借阅这本书吗？”
（4）确定借阅图书，则借阅证号增加一条借阅信息记录；读者选择 “放弃”，回到步骤（3）重新选择图书；
（5）读者成功借阅图书，系统管理员保存借阅记录并修改库存图书数量、读者借出数量。
（6）借阅完成，点击“退出”，退出系统。2．“还书”用例 用例编号：0103 用例名：还书
执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：归还图书 过程描述：
（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“还书”；（2）输入图书证编号；
若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书，有超期未还的图书，调用“超期罚款”；若读者说自己丢失图书，调用“丢失罚款”
（3）输入要还的图书编号； 若输入错误，提示“您未借阅该图书！” 若输入正确，提示“您确定要归还这本书吗？”（4）读者选择“确定”，读者借阅的图书信息记录消失；读者选择 “放弃”，返回到步骤（3）
（5）完成还书，点击“退出”，退出系统；
（6）读者成功归还图书，系统管理员删除借阅记录，并修改数据库管理子系统的图书数量和读者借出数量。
3．“读者信息录入”用例
用例编号：0302 用例名：读者信息录入
执行者：直接执行者：系统管理员，间接执行者：读者 目的：录入新读者相关信息，包括姓名、身份、学院 过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息录入”（2）写入读者相应信息，将读者信息保存至数据库
（3）发放图书证
（4）创建完成，读者信息录入成功，在数据库管理子系统增加图书信息，退出系统
4．“读者信息注销”用例 用例编号：0303 用例名：读者信息销毁
执行者：直接执行者：系统管理员，间接执行者：读者
目的：当读者由于工作地点变化或其他原因，无需再使用图书馆的图书资料时，应当为其办理注销
过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息注销”（2）查询读者的借阅记录
若有未归还图书，给出提示：暂时不能注销
否则注销读者，提示：注销后，不能借阅图书 若不确定，返回上一层界面
（3）注销图书证，删除基本数据修改功能子系统中的读者信息（4）注销完成，在数据库管理子系统删除读者信息，退出系统 5．“书籍信息录入”用例 用例编号：0305 用例名：书籍信息录入
执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统 目的：图书馆里的图书根据馆藏需求进行更新 过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息录入”
（2）写入图书相应信息
（3）图书管理员给图书进行分类编号，记录条形码信息（4）图书管理员为图书张贴条形码
（5）图书管理员检查图书编号是否入库
（6）在数据库管理子系统增加图书信息，书籍信息录入成功，退出系统 相应活动图如下：
系统管理员界面图书管理员数据库管理子系统登陆基本数据修改功能子系统点击书籍信息录入图书进行分类编号，记录条形码信息图书张贴条形码检查图书编号是否入库增加图书信息[否]退出系统[是]
6．“书籍信息注销”用例
用例编号：0306 用例名：书籍信息注销
执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统
目的：当图书馆里藏书，由于受到毁损或其他意外的破坏而无法再使用的情况下，需要对馆藏图书进行注销。过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息注销”
（2）输入图书编号，若该书借阅出库，则暂时不能注销，提示“该书借阅中，不能注销”；若该书未被借阅，提示“确定要注销此书吗？”若不确定，返回上一层界面（3）成功注销图书后，在数据库管理子系统删除图书信息，退出系统
三、系统分析
3.1建立对象类（1）reader 类名：reader 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 功能：负责读者信息并对这些信息进行处理，便于对读者借阅信息进行统一管理。属性：读者的编号ID（reader_id）、姓名（reader_Name）、身份（identification）、学院（academy）、所借书籍的编号（borrowed）等 操作：借书和还书、接受相应处理
(2)system admin 类名：system admin 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等
操作：读者信息管理、书籍信息管理、借阅管理、（3）books admin 类名：books admin
类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等
操作：借阅管理、书籍信息录入、书籍信息修改、书籍信息注销（3）Books 类名：Books 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，可以共享 属性：书名、作者、书籍编码、类别、价钱、入库时间 操作：分类编号、记录条形码信息、（4）borrow 类名：borrow 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：借阅书籍的编号、借阅时间、操作：借书、还书、续借书、交欠款、交罚款（5）data 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：书籍信息、读者信息、借阅信息
操作：读者信息录入、读者信息修改、读者信息注销、书籍信息录入、书籍信息修改、书籍信息注销、增加借阅信息、删除借阅信息 3.2 建立对象类图
reader+编号+姓名+身份+学院+所借书籍的编号+借书()+还书()+接受相应处理()data+书籍信息+读者信息+Attribute1+读者信息录入()+读者信息修改()+读者信息注销()+书籍信息录入()+书籍信息修改()+书籍信息注销()+增加借阅信息()+删除借阅信息()system admin+编号+姓名+读者信息管理()+书籍信息管理()+借阅管理()Books+书名+作者+书籍编码+类别+价钱+入库时间+分类编号()+记录条形码信息()borrow+借阅书籍的编号+借阅时间+借书()+还书()+续借书()+交欠款()+交罚款()books admin+编号+姓名+借阅管理()+书籍信息录入()+书籍信息修改()+书籍信息注销()图2-1 图书馆管理系统类图
四、系统设计
4.1顺序图建模
◆在“借书”用例中涉及的对象间的交互分析如下：
1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的借书要求进行处理。涉及的对象：
·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象 传递的消息：
·消息：口令密码（）
·消息的类型：同步消息
·返回消息：口令密码正确或出错信息 2）输入图书证编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象
传递的消息：
·消息：核对图书证编号（）·消息的类型：自调用消息
·返回消息：图书证编号正确或出错信息 3）输入图书编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“reader”对象
传递的消息：
·消息：[最大借书额为0]:核对借书额（）·消息的类型：同步消息
·返回消息：可以借书 4）确定借阅图书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象 传递的消息：
·消息：[确定借书]: 借阅证号增加借阅信息记录（）·消息的类型：自调用消息 ·返回消息：借书成功 5）修改数据库。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象
传递的消息：
·消息：[借书成功]: 保存借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息
·返回消息：退出系统
根据以上确立的“借书”用例图中涉及的对象，建立“借书”用例的顺序图如图3-1：
基本数据修改功能子系统借阅窗口reader数据库管理系统借阅管理窗口 : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [最大借书额为0] : :核对借书额()4 [确定借书] : 借阅证号增加借阅信息记录()5 [借书成功] : 保存借阅记录并修改库存图书数量、读者借出数量()图3-1 “借书”用例顺序图
◆在“还书”用例中涉及的对象间的交互分析如下：
1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的还书要求进行处理。涉及的对象：
·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象 传递的消息：
·消息：口令密码（）
·消息的类型：同步消息
·返回消息：口令密码正确或出错信息
2）输入图书证编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象
传递的消息：
·消息：核对图书证编号（）
·消息的类型：自调用消息
·返回消息：图书证编号正确或出错信息
3）超期罚款处理。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统超期罚款窗口”对象 传递的消息：
·消息：[超期]：超期罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息
3）丢失罚款处理。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统丢失罚款窗口”对象
传递的消息：
·消息：[丢失]：丢失罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息
4）输入图书编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“reader”对象 传递的消息：
·消息：[借阅]：核对是否借阅此书（）·消息的类型：同步消息 ·返回消息：是否借阅此书 5）确定还书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象
传递的消息：
·消息：[确定还书]: 借阅证号删除借阅信息记录（）·消息的类型：自调用消息 ·返回消息：还书成功
6）修改数据库。涉及的对象：
·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象
传递的消息：
·消息：[还书成功]: 删除借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息 ·返回消息：退出系统
根据以上确立的“还书”用例图中涉及的对象，建立“还书”用例的顺序图如图：
基本数据修改功能子系统还书窗口基本数据修改功能子系统超期罚款窗口基本数据修改功能子系统丢失罚款窗口reader : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [超期] : ：超期罚款()4 [丢失] : ：丢失罚款()5 [借阅] : ：核对是否借阅此书()6 [确定还书] : : 借阅证号删除借阅信息记录()
图3-2 “还书”用例顺序图一
reader数据库管理系统借阅管理5 [确定还书] : : 借阅证号删除借阅信息记录()6 [还书成功] : :删除借阅记录并修改库存图书数量、读者借出数量()
图3-3 “还书”用例顺序图二
4.2 构件图建模
构件图主要用于建立系统的静态实现视图模型，通过构件之间的依赖关系描述系统软件的组织结构，展示了系统中的不同物理构件机器之间的联系。
图3-4所示的是图书馆管理系统部分构件图，图书管理员登陆“基本数据修改功能子系统”并成功通过验证后，进入基本数据修改功能子系统主界面
图书管理员登陆验证基本数据修改功能子系统主界面续借书借书还书丢失罚款超期罚款图3-4 基本数据修改功能子系统构件图
4.3 配置图建模
实用配置图定义的软硬件结构及通讯机制，表示软硬件系统之间的合作关系；使用构件图描述系统由哪些构件组成。
图书馆管理系统是一个客户/服务器和服务器/浏览器相结合的系统，可以同配置图显示系统的物理结构，如图3-5所示：
TCP/IP应用服务器ODBC图3-5 图书馆管理系统配置图SQL SERVER13 客户程序数据库服务器
第五篇：uml建模报告ATM自动柜员机系统
UML建模报告
（2010 / 2011 学年 第 2学期）
题 目：
基于UML的ATM自动
柜员机系统
专
业：
成员：
指
导
教
师：
基于UML的ATM自动柜员机系统建模报告
一、需求分析
（1）功能需求：
1.登陆：客户通过输入正确的登陆密码即可登陆ATM。
2.取款：允许客户取出自己账户中的现金。3.客户存款：允许客户把现金存入自己账户。4客户查询余额：允许客户查询自己的账户余额。
5客户转账：允许客户将自己账户中的金额转移至另一账户。6客户更改密码：允许客户修改自己的登录密码。
（2）系统操作要求：
1．要求用户每次取款数额为50的整数倍；
2．要求用户一次取款数额不得大于1000元； 3．要求用户一天取款数额不得超过5000元； 4．要求用户每次取款数额不得大于账户余额； 5．要求用户设置的登录密码为6位。
（3）系统性能要求：
1．要求反应时间不得大于10秒钟； 2． 系统设计目标：
ATM自动取款机可以提供24小时不间断服务，操作简单，可以很方便为用户提供取款、转账/汇款、查询账户余额等服务。
（4）实现手段：
使用ASP.NET进行界面设计，建立一个数据库保存客户的账户信息，使用C#语言功能函数并对数据库中的账户信息进行操作。
二、总体设计
本系统总共分为登陆、查询、存款、取款、转账、修改密码等6个功能模块。
1.登录模块：登陆模块使用字符匹配算法，要求用户在输入账号之后输入登陆密码，只有输入正确的密码才能登陆自己的账户。否则提示密码错误。
2.查询模块：用户输入正确的密码后就可登陆自己的账户并接受服务。查询功能允许用户查得自己账户上的余额信息。
3.存款模块：允许客户向自己的账户中存入现金。
4.取款模块：允许客户从账户中取走现金，要求取出的金额不能大于所剩余款，否则提示余额不足。
5.转账模块：允许客户将自己账户中的金额转移至另一账户。要求所转的金额不能多于所剩余款，否则提示余额不足。
6.修改密码模块：允许用户修改自己的登陆密码，密码仍然是6位数的，修改之后，下次登陆就应该用新密码。
三、详细设计 用例图：
类图：
客户取钱的协作图：
其他功能的协作图与此类似。
账目类的状态图：
ATM系统的部署图：
四、测试报告 我们在客户数据库中建立四个账户，如下：
其中四个属性分别是客户名、账号、密码、账户余额。打开网页，进入初始页面：
若选择取回磁卡，显示如下：
1.登录功能测试
我们选择继续以进行测试，单击测试进入如下页面：
若输入不存在的账号，则出现提示：
现在我们输入正确的账号，这里以08060112为例：
单击确认，系统将提示客户输入密码，正确的密码是“123456”，我们输入“333333”以进行测试，系统提示密码错误：
我们输入正确的密码“123456”，单击确认，则进入交易界面：
2.查询功能测试
单击查询，显示如下
与数据库表中的number值比较可得，结果正确。3.取款功能测试
选择返回，回到主菜单，单击取款，系统提示客户输入取款金额：
我们输入300单击确认，显示如下
单击确定回到主菜单，单击查询，显示如下：
余额为700，说明取款成功，取款功能顺利实现。4.转账功能测试
单击返回，回到主菜单，单击转账，系统提示用户输入转入账号，我们以转入08060119为例：
单击确认，系统提示转账金额，我们输入300：
单击确认，提示转账成功：
单击确定回到主菜单，这时我们单击查询08060112的余额：
结果正确，我们再通过数据库查询08060119的余额，打开表格，右击，执行，显示如下：
结果也正确，说明转账功能也已顺利实现。5.存款功能测试
单击返回回到主菜单，单击“存款”，我们通过输入数值来模拟放入现金：
单击确认，系统提示操作成功：
单击“确定”回到主菜单，单击查询，显示如下：
结果正确。
6.修改密码功能测试
单击返回回到主菜单，单击“修改密码”，系统提示如下：
我们将密码修改为“555555”，输入“555555”后，提示操作成功：
单击确定就回到主菜单。这时我们取回磁卡重新登录以测试密码是否已经修改。依旧输入卡号08060112，单击确认，输入旧密码“123456”，提示密码错误：
单击确定，重新输入新密码“555555”，单击确认，则可顺利登录到主菜单
可见，密码已经修改成功，另一方面，我们查看数据库中的数据，右击，执行，显示如下：
可以看到账户08060112的password属性已经变为“555555”，因此，修改密码功能也能顺利实现。至此，ATM系统的六大功能都已通过测试并正确无误。
五、总结
通过这次UML建模的学习，我们学会了很多知识。之前我对UML建模一无所知，但现在我已学会了一些UML建模的基本知识，并学会了建立一些简单的模型。
虽然只有短短的几个礼拜，但收获却是很大的。首先是分析问题的能力，刚拿到这个题，总觉得无从下手，不知道题目到底要我们做什么，心里只是干着急，不知道该干嘛。经过一周的迷茫，我们开始静下心来，分析题目，找参考书，尝试性地进行编程。到第三周，我们终于做出了一个成果并且编译没有错误。之后就是尝试运行，运行的过程中出现很多问题。比如转账，修改密码等，但经过我们细心的测试、排查，还是找到了错误的原因并进行了纠正。因此，我们的查错改错的能力也得到了提高。最重要的是，我们通过这次实习学会了互相合作，俗话说“三个臭皮匠顶个诸葛亮”，也许我们单独做很难完成这个程序。但是只要我们团结一致就没有克服不了的困难。这次实习在我们的大学生活乃至整个人生中都有着非常重要的意义，是一笔不小的财富，难忘的经历。我们会以此为基础走好人生的每一步。
以上是我们对UML建模的学习的一点总结，同时也是为自己的未来整理好思路，为以后的学习做好准备。UML建模，教会了我很多，而我要做的，就是在以后的学习与生活中更加努力的学习来迎接它带来的知识与挑战。
点击咨询 