第一篇：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建模--银行管理系统（范文）
银行管理系统的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建模
本科生课程设计—网上购物系统的分析及设计
广西科技大学
Guangxi University of Scienceand Technology
课 程 作 业
专
业： 计算机科学与技术
班级学号：
学生姓名：
班级学号：
学生姓名：
指导教师：
二〇一三年十二月摘要.....................................................................................................................................................III 1 引言.......................................................................................................................................................3
1.1 选题背景....................................................................................................................................3 1.2 选题意义和目的.........................................................................................................................3 1.3 研究方法....................................................................................................................................3 2 可行性分析...........................................................................................................................................4
2.1 技术可行性分析.........................................................................................................................4
2.1.1与现有系统比较的优越性...............................................................................................4 2.1.2 技术可行性评价..............................................................................................................4 2.2 经济可行性分析.........................................................................................................................4
2.2.1 支出.................................................................................................................................4 2.2.2 投资回收周期..................................................................................................................4 网上购物系统的分析............................................................................................................................5
3.1 网上购物系统的需求分析：.....................................................................................................5 3.2 用例分析....................................................................................................................................5
3.2.1确定用例:.........................................................................................................................5 3.2.2 创建用例..........................................................................................................................5 3.2 用例分析....................................................................................................................................6
3.2.3创建用例图.......................................................................................................................6 3.3 类图分析....................................................................................................................................7
3.3.1 当前系统的类..................................................................................................................7 3.4 时序图分析................................................................................................................................8
3.4.1 时序图描述......................................................................................................................8 3.4.2 顾客的时序图..................................................................................................................8 3.4.3客户删除订单的时序图...................................................................................................9 3.4.4 管理员处理订单的时序图............................................................................................10 3.4.4 管理员处理订单的时序图............................................................................................10 3.5 系统的协作图分析...................................................................................................................11
3.5.1 顾客订购协作图............................................................................................................11 3.5.2 顾客删除订单的协作图................................................................................................11 3.5.3 管理员处理订单协作图................................................................................................12 3.6 系统的状态图分析...................................................................................................................13
3.6.1 管理员状态图................................................................................................................13 3.6.2 用户状态图....................................................................................................................13 3.7 系统的构件图分析...................................................................................................................14
3.7.1 网上购物系统构件图....................................................................................................14 3.8 系统的部署图分析...................................................................................................................15
3.8.1 网上购物系统部署图....................................................................................................15 参考书籍.............................................................................................................................................17 结
论.....................................................................................................................................................17
本科生课程设计—网上购物系统的分析及设计
摘要
本论文共分三部分，分别介绍了统一建模语言（UML）、面向对象程序分析与设计以及通过一个简易电子商务系统的例子介绍如何应用UML进行项目需求分析、结构规划和生成框架代码，以及如何从现有系统逆向转出代码，生成Uml模型。
该设计的主要目的是对统一建模语言的学习过程，并在学习中，通过一个简单的例子来理解UML语言的建模思想。本设计是通过一个购物车的例子来理解UML语言的。通过面向对象程序设计方法与UML思想的结合，对系统进行建模。即设计UML中的类图、对象图、用例图、协作图、顺序图、状态图、构件图和部署图。通过这些UML框图生成代码。然后，根据生成的代码框架及UML模型来完善整个程序。
这个网上购物系统，主要是实现向购物车中添加和删除商品及对商品进行结帐的功能。系统是用JSP语言实现的，它的主要功能都是通过Servlet控制的。该程序的设计思想都是通过UML语言体现的，论文详细描述了整个设计及学习的全过程。
关键词：
统一建模语言 面向对象分析
ABSTRACT
This paper is divided into three parts and introduces separately Unified Modeling Language, OOA and OOD.By a piece of easy E-business system , It shows how to apply UML to carry on Requirement Analysis and Structure plan and to turn into project code, and how to transfer to project code reversely and produce UML model from a existing system.The main purpose of this design is to study course of Unified Modeling Language.During studying, the modeling thought of UML can be understood through a simple example.In order to understand the thought of UML, an example of shopping cart is citinged.Through the combination of the method of OOD and the thought of UML, the model of the system is realized.Namely, it is to design Class Diagram、Use Case Diagram、Sequence Diagram、State Diagram、Component Diagram and Deployment Diagram.The code is produced by using these UML block diagrams.Then, the whole program is perfected according to code frame that are produced and UML model.The online shopping system mainly realizes functions of adding goods to shopping cart and deleting goods from shopping cart and checking out.The system is developed by JSP language, and the main functions of it are controlled through Servlet.The design philosophy of this procedure was all embodied through UML language.The paper has described in detail the design and whole studying processes.Key Word:
Unified Modeling Language
II
1.1 选题背景 引言
它主要是通过在网页上进行简单的对商品进行选购。
1.2 选题意义和目的
该案例的目的主要是：一，学习UML在面向对象技术中的应用。二，演示在一个完整的应用中如何使用UML：从分析到设计模型到真正的代码和可运行的应用。三，学习使用UML建模工具Visio。本案例遵循的是一种顺序过程。
1.3 研究方法
一个成功的系统开发项目的成功之处在于它能够在想象者和实现这些想象的系统开发人员之间建立起沟通的桥梁。统一建模语言(Unified Modeling Language,UML)就是一种建立桥梁的工具。它能帮你捕捉住对系统所发挥的想象力，并是你能够用这些想象出来的东西来和项目的风险承担人(在这里可以理解为用户)进行交流。UML借助与一套符号和图形来帮助我们完成这些工作。每种图形在开发过程中都发挥其各自不同的作用。可行性分析
2.1 技术可行性分析
2.1.1与现有系统比较的优越性
简单性：在实现平台的功能的同时，尽量让平台操作简单易懂，这对于一个网站来说是非常重要的。
针对性：该平台设计是网上购物系统及后台管理的定向开发设计，所以具有专业突出和很强的针对性。
实用性：该平台能完成商品展示和管理员管理的基本信息，具有良好的实用性。2.1.2 技术可行性评价
技术可行性：目前，公司的管理工作和服务工作存在盲目性、随意性、和无效消耗，不能保证营销部门的工作质量，影响商品的销售，给公司带来实际的和潜在的经济损失。虽然系统开发初期投资较大，但是，若开发成功本系统，将有助于公司更好地预测市场，更好的开发客户及时调整经营销售策略，在激烈的市场竞争中把握主动。因此，从长远利益考虑，本项目若能开发成功，它所带来的效益将远高于系统投入。
2.2 经济可行性分析
2.2.1 支出
经济可行性：由于实体店铺对电子购物商城系统开发项目达成了共识，并拨出专项资金，用以购置建立网络中心所需的网络设备和软件，具备了开发Web平台系统的基本条件。
为了今后的系统维护，开发团队准备联合具有丰富经验的软件开发人员共同研究，这为今后系统的顺利开发提供了有力的技术条件。2.2.2 投资回收周期
资本周转速度快，回收期短，风险小，盈利多。不足的是，投资回收期没有全面地考虑投资方案整个计算期内的现金流量，即：忽略在以后发生投资回收期的所有好4
处,对总收入不做考虑。只考虑回收之前的效果，不能反映投资回收之后的情况，即无法准确衡量方案在整个计算期内的经济效果。网上购物系统的分析
3.1 网上购物系统的需求分析：
1：普通用户可以登陆系统，成为登陆后用户。
2：普通用户只具有搜索产品、查看产品分类、查看产品项目、查看产品等几个基本权限。
3：除提供一般权限外，本系统还可为登陆后用户提供编辑帐号、购物车、定单、结算的功能和服务。
4：登陆后用户可修改购物数量。
3.2 用例分析
3.2.1确定用例: 1系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？ 2执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？ 3.2.2 创建用例 订单处理 2 订单维护 3 订单状态查询 4 个人信息维护 5 订购 6 接收发货 7 库存查询 8 缺货拒绝 商品查询 10商品信息维护 11销售查询 12员工信息维护 13报表维护 14订单增加 15订单删除
3.2 用例分析
3.2.3创建用例图
系统管理的用例图如图3-1所示：
系统用户的用例图如图3-2所示：
3.3 类图分析
3.3.1 当前系统的类
当前系统的类： 产品类（Product）的主要操作：设置和获取每个属性值的方法。产品类别类（Category）的主要操作：设置和获取每个属性值的方法。3 产品项目类（Item）的主要操作：设置和获取每个属性值的方法。订单类（Order）的主要操作：设置和获取每个属性值的方法、初始化订单（initOrder）、增加产品项目（addLineItem）等。购物车类（Cart）的主要操作：设置和获取每个属性值的方法、增加产品项目（addItem）、删除产品项目（removeItemById）等。购物车项目类(CartItem)的主要操作：设置和获取每个属性值的方法、统计金额（calculateTotal）等。
网上购物系统的类图如图3-3所示：
图3-3 网上购物系统的类图
3.4 时序图分析
3.4.1 时序图描述
顺序图可描述几个对象间的动态协作关系，它非常直观的展示了对象之间传递消息的时间顺序。反映了系统执行过程中某个特定时刻所发生的事情。在系统分析时，可对主要对象类绘制顺序图，以便分析系统的行为，验证和修改系统的静态结构，满足用户的需求，达到系统的目标。3.4.2 顾客的时序图
顾客首先使用自己的帐号和密码进行登陆系统，登陆模块会将客户的ID保存在系统缓存中，并提交给商品查询模块。商品查询模块提示客户输入查询条件，客户输8
入适当的查询条件后，查询模块将显示商品列表。客户得到商品列表后，提交自己想要购买的商品ID，订购模块得到商品ID。生成订单并提交给数据库模块进行保存，保存成功后，提示用户订购商品成功。顾客订购的时序图如图3-4所示：
图3-4 顾客订购的时序图
3.4.3客户删除订单的时序图
客户在提交订单后可以对订单进行维护（添加，删除，修改）。客户首先输入自己的帐号和密码登陆系统，登陆模块会将客户的ID保存在系统缓存中，并提交给订单查询模块。订单查询模块会显示当前所有的订单，顾客得到该列表后，选择要删除商品的ID，订单处理模块把删除信息提交给数据模块，数据模块保存信息。订单处理提示用户删除成功。客户删除订单的时序图如图3-5所示：
图3-5 客户删除订单的时序图
3.4.4 管理员处理订单的时序图
管理员使用其帐号和密码登陆后，登陆模块会将管理员的ID保存在系统缓存中并提交给订单处理模块。订单处理模块提交给管理员未处理的列表，管理员提交某商品的ID得到该商品的库存情况，如果库存充足则接收订单，并把接收信息提交给数据模块，数据模块更新该客户的订单信息并返回成功信息给订单处理模块，订单处理模块提示改操作成功。管理员处理订单的时序图如图3-6所示：
3.4.4 管理员处理订单的时序图
图3-6 管理员处理订单的时序图
3.5 系统的协作图分析
3.5.1 顾客订购协作图
顾客订购协作图如图3-7所示：
图3-7 顾客订购协作图
3.5.2 顾客删除订单的协作图
顾客删除订单的协作图如图3-8所示：
图3-8 顾客删除订单的协作图
3.5.3 管理员处理订单协作图
管理员处理订单协作图如图3-9所示：
图3-9 管理员处理订单协作图
3.6 系统的状态图分析
3.6.1 管理员状态图
管理员状态图如图3-10所示：
图3-10 管理员状态图
3.6.2 用户状态图
用户状态图如图3-11所示：
图3-11 用户状态图
3.7 系统的构件图分析
3.7.1 网上购物系统构件图
构件之间存在的唯一关系是构件的依赖性。构件依赖性指一个构件依赖于另一个构件。构件依赖性画成构件之间的虚线箭头。如下图箭头指的构件表示被依赖，也就是说,Cart、Eshop、Checkout都依赖于ShoppingServlet。下图描述的是在网上购物系统中几个构件之间的依赖关系。网上购物系统构件图如图3-12所示：
图3-12 构件图
3.8 系统的部署图分析
3.8.1 网上购物系统部署图
部署图可以显示节点以及它们之间的必要连接，也可以显示这些连接的类型，还可以显示组件和组件之间的依赖关系，但是每个组件必须存在于某些节点上。部署图用于对系统的实现视图建模。绘制这些视图主要是为了描述系统中各个物理组成部分的分布、提交和安装过程。在实际应用中，并不是每一个软件开发项目都必须绘制部署图的。如果项目开发组所开发的软件系统只需要运行于一台计算机并且只需使用此计算机上已经由操作系统管理的标准设备，这种情况下就没有必要绘制部署图了。另一方面，如果项目开发组所开发的软件系统需要使用操作系统管理以外的设备（例如数码相机、路由器等）、或者系统中的设备分布在多个处理器上，这时就有必要绘制 部署图，用其来帮助开发人员理解系统中软件和硬件的映射关系。下面是本系统的部署图，如图3-13所示：
Desktop...16
Desktop...RegistrationS LANerverWebBrowserbuyingSystemsaleSystemMaintainSystemLANDesktop PC(saler)
图3-13 网络购物系统的配置图Internet 参考书籍
[1] 面向对象程序设计高级教程，陈奇，高等教育出版社，2022 [2] 标准建模语言UML极其支持环境，周伯生，张莉等，北京：计算机世界，1998 [3] UML和模式应用——面向对象分析和设计导论，Craig Larman等，姚淑珍，李虎译，机械工业出版社，2022 [4] UML ASL Reference Guide ASL Language Level 2.5；Ian Wilkie, Adrian King, Mike Clarke, Chas Weaver and Chris Rastrick；
[5] Stephen J.Mellor, Marc J.Balcer,Executable UML :A Foundation for Model-Driven Architecture, ,2022,科学出版社
结
论
本次课程设计将UML建模应用到构建系统设计上，并通过八种框图，从各种角度观察系统来进行需求分析、系统设计。通过一个完整的简单例子来说明UML在整个系统设计所发挥的作用。
通过这次的课程设计，使我对UML全新的理解,使我对UML产生了更加浓厚的兴趣,在程序的设计过程中，我发现自己的软件知识尤其是对软件的整体设计不是完全理解，对于一些细节不够了解，对知识的了解不全面，有待学习和提高。
通过这次的设计，知道自己的不足，我相信自己会在一定时间内通过不断的学习和实践提高自己的能力，设计给我带来很大的帮助，同时开阔了我的眼界，使我明白只有自己亲自实践，才能了解自己所做的东西，如果没有实践，恐怕就不会有电流的产生，地球为什么是圆的，以及现在的一切。勤于实践不仅能锻炼自己，还能够提高17
自己的能力，增强自己的自信心。在面对困难时要勇敢的面对才有能力、有把握去克服它，征服它。虽然我现在还有所欠缺，但我相信在以后的工作和生活中，我会不断提高自己，完善自己。
第四篇：UML(ATM系统)动态建模
实验3 动态建模
一、实验目的与要求 掌握分析ATM系统用例中用例的流程，分析对象之间的交互关系 掌握用UML设计参与对象之间的交互，用状态图、时序图、协作图和活动图来描述系统的行为。
二、实验设备、环境
PC(一台)，Windows 2000或以上版本，安装Microsoft Visio 2022
三、实验内容及步骤 交互图：实现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 客户程序数据库服务器
