银行管理系统3460894911.doc

课 程 设 计 报 告学生姓名:学 号：学 院:班 级:题 目:银行管理系统银行储蓄业务系统王欣指导教师： 职称: 教授 2011年 7 月 12日目 录1.选题背景12.银行储蓄业务子系统的需求分析22.1需求陈述22.2 需求分析22.2.1 功能需求22.2.2 性能需求32.3 系统需求建模32.3.1 确定参与者32.3.2.确定用例42.3.3.系统用例建模52.3.4用例描述53.系统分析93.1系统用例建模93.2静态结构模型103.2.1类的识别103.2.2类的关联分析103.2.3类的属性描述113.3系统动态模型123.3.1系统执行顺序分析123.3.2系统的协作分析203.3.3系统状态分析233.3.4系统活动分析25系统设计与实现304.1 UML体系结构设计304.1.1硬件体系结构设计304.1.2软件体系结构设计304.2对象模型设计314.2.1定义系统对象类314.3 系统实现334.3.1组件分析334.3.2配置分析345.课程设计体会心得356.参考文献361.选题背景随着科技发展和社会进步，尤其是计算机大范围的普及，计算机应用逐渐由大规模科学计算的海量数据处理转向大规模的事务处理和对工作流的管理，这就产生了以台式计算机为核心，以数据库管理系统为开发环境的管理信息系统在大规模的事务处理和对工作流的管理等方面的应用，特别是在银行账目管理之中的应用日益受到人们的关注。今明年来我国信息产业发展迅速，手工管理方式在银行储蓄管理等需要大量事务处理的应用中已显得不相适应，采用IT技术提高服务质量和管理水平势在必行。目前，对外开放的趋势使银行业直接面对国外银行巨头的挑战，因此，银行必须提高其工作效率，改善其工作环境。这样，银行的储蓄业务管理信息化势在必行。在传统的银行储蓄管理中，其过程往往是很复杂的，繁琐的，储蓄管理的过程中需要经过多道手续，倘若这些过程为手工操作，效率十分低下，且由于它们之间关联复杂，通过集合查询的方式各不相同；且会出现信息的重复传递问题，因此该过程必须实现信息化。该系统开发的整体任务是实现银行储蓄管理的系统化、规范化、自动化和智能化，从而达到提高银行企业管理效率的目的。2.银行储蓄业务子系统的需求分析2.1需求陈述银行是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。银行系统是一个较大的系统，它可以分为六个部分：贷款业务，储蓄业务，外汇交易，网上银行，信用卡业务和系统管理。我们将重点描述的是银行储蓄业务子系统，它的主要功能是为银行储户提供开户，销户，补办，挂失，解挂等基本操作以及存款，取款，转账等操作。用户需要从系统管理子系统登录后才能进入储蓄模块。在银行设立账户的人或机构通常被称为银行的客户。一个客户可以在银行开多个账户，客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转入到另一个账户。客户还可以随时查询自己账户的情况，可以销户，可以补办或者挂失账户，并查询以前所进行的存款、取款等交易记录。客户也有权利关闭账户。上面大概地描述了银行储蓄业务子系统的功能，这种表达将有利于测试需求的定义，因为每一个描述的功能都是单独可测的。在分析系统需求时，保证每个功能可测是一个很好的习惯。例如，像“必须易于使用”就是主观的，所以可能是不可测的。要避免像这样的不清楚的需求，更有用的需求集应该列出用户认为“易于使用”的特定的用户界面的特性。 由于分析设计过程是个迭代的软件开发过程，所以需求也会是在分析设计的过程中不断补充、细化。上述的需求只是初步的基本需求，还有待不断地细化和完善。2.2 需求分析2.2.1 功能需求银行储蓄业务子系统的开发目标是充分利用计算机和网络技术，使储户的各类操作方便快捷，如为银行储户提供开户，销户，补办，挂失，解挂，存款，取款，转账等操作，同时也提高了银行的工作效率。在对上面描述的银行储蓄业务子系统的基本需求分析后，可知这个简化的银行储蓄业务子系统至少应该具有如下功能：（1）一个银行可以有多个账户（2）一个银行可以有多个客户（3）一个客户可以支持有多个客户（4）一个客户可以有多个支持者（5）可以开户、销户（6）可以注销账户（7）可以补办（8）可以挂失和解挂（9）可以存款、取款和转账等2.2.2 性能需求性能需求是从各个角度描述对系统的约束和限制，反映了应用系统对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性等。下面是关于该银行储蓄业务子系统的性能需求分析：(1) 时间特性需求：理想状态下该系统应为用户提供7×24小时服务(2) 客户端：采用浏览器和传统客户端相结合的方式进行业务处理，在30-60秒内完成页面下载，网络带宽应至少为56Kbps以上。(3) 系统开放性要求：基于主流WINDOWS平台建设的“银行储蓄业务子系统”，使其具有良好的可扩充性和可移植性。系统可运行在主流的WINDOWS操作系统平台上，便于以后系统的升级。遵循主流的标准和协议，不仅可以为系统与上级平台系统交换信息提供便利，而且也有利于系统内部各部分之间交换信息，这将有助于提高系统扩充性。(4) 系统可扩充性要求：基于可扩充的平台进行建设的“银行储蓄业务子系统”，提高了系统的可扩展性，例如，可保证所整合的业务系统的可扩充性、对不同级别的用户要求的层次和模块，可灵活地进行定制。系统提供与现正在应用的平台统一的接口，使得将来易于与当前系统实现互连互通，为用户提供全方位、高质量和高效率服务。(5) 界面友好性要求：系统提供统一的操作界面和方式。要求操作界面美观大方，布局合理，功能完善，对于初级用户容易上手。(6) 系统可用性要求：系统操作快捷、内容完整是保证对用户进行使用的基础。因此，应准确而详细地理解各用户群特征、任务和使用环境，在“有效性”、“效率”以及“满意度”等方面满足各类用户对系统的要求。(7) 系统可管理性要求：该系统涉及面较广，系统应提供对管理内容的分级分类管理和维护、审批服务事项维护、工作流定制与监控、用户信息维护、系统配置和管理、远程监测和故障诊断等功能。2.3 系统需求建模2.3.1 确定参与者通过分析银行储蓄业务子系统的功能需求，可以识别确定出3个参与者：银行职员、客户、银行系统。参与者的描述如下：（1）银行职员描述：银行职员可以创建、删除或者注销账户，并可以修改账户信息。示例：银行的工作人员。（2）客户描述：客户可以存钱、取钱，并在不同的账户之间转账，而且可以进行挂失、补办等业务。示例：任何在银行中开有账户的个人或者组织。（3）银行系统描述：客户可以在银行系统中设立或者关闭账户。示例：任意一个提供存款、取款、转账等业务的银行。2.3.2.确定用例前面已经识别确定出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在：（1）登录本用例提供了验证用户身份的功能。（2）存款本用例提供了存钱到账户的功能。（3）取款本用例提供了从账户中取钱的功能。（4）管理账户本用例提供了创建、删除或者注销账户，以及修改账户信息的功能。由于“转账”既可以在属于同一银行的账户之间发生，也可以在属于不同银行的账户之间发生，而发生于不同银行的账户之间的转账需要与参与者“银行系统”交互，因此需要用两个不同的用例来描述银行内的转账和银行之间的转账：在银行内转账，本用例提供了在属于同一银行的账户之间转账的功能；在不同的银行之间转账，本用例提供了在属于不同银行的账户之间转账的功能。由于、具有公共行为，因此可以抽象出一个父用例“转帐”。（5）转账本用例描述了转账的通用行为，是、的父用例。参与者“银行职员”与用例“登录、管理账户”交互，参与者“银行职员”作为参与者“银行系统”的代理与用例“存款、取款、转账”交互，也即参与者“客户”依赖参与者“银行职员”完成存钱、取钱、转账等动作。用例“转账”拥有两个子用例，分别是“银行内转账”和“不同银行之间的转账”，因此他们之间存在类属关系。另外，用例“不同银行之间的转账”要与代表另一个银行的参与者“银行系统”进行交互。2.3.3.系统用例建模图2.1 系统用例图2.3.4用例描述用例描述是对完成用例行为所需的事件进行的描述。用例描述叙述了系统应该做什么，而不是系统应该怎么做。下面是对前面识别出的用例逐一进行描述。2.3.4.1登录1）简单描述，本用例描述了用户如何登录到系统中。2）当用户想登录到银行系统中时，用例启动： （1）系统提示用户输入用户名和密码。（2）用户输入自己的用户名和密码，提交。（3）系统验证输入的用户名和密码，用户登录系统成功；如果输入用户名和/或密码无效，用户可以重新输入或终止该用例，允许重复操作3次。2.3.4.2存款 1）简单描述，本用例允许客户借助“银行职员”存款到账户中。 2）前置条件，在本用例开始前，银行职员必须登录到系统中。 3）后置条件，如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。 4）当客户想存钱到自己的账户中时，要向银行职员提交存款单和金额，用例启动：（1）系统提示银行职员输入用户姓名、用户的ID号、账号和所存款项的金额等信息。（2）银行职员输入相关信息后提交，系统确认账户是否存在并有效（当用户名、用户的ID号与账户的户主信息一致且用户处于非冻结状态时，账户有效）。（3）系统建立存款事件记录，并更新账户的相关信息。5） 账户不存在或者无效时，显示提示信息，用户可以重新输入或者该用例。2.3.4.3取款 1）简单描述，本用例允许银行职员按照客户的要求从客户的账户中取款。 2）前置条件，在本用例开始前，用户必须登录到系统中。 3）后置条件，如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。 4）当客户想从自己的账户中取钱时，要向银行职员提交取款单，用例启动：（1）系统提示银行职员输入用户姓名、用户的ID号、账号和取款金额。（2）银行输入相关信息后提交，系统确认用户是否存在并有效（当用户名、用户的ID号与账户的户主信息一致且用户处于非冻结状态时，账户有效），用户中的存款金额是否足够支付所取款项。（3）系统建立取款记录，并更新账户的相关信息。5）账户不存在或者无效时，显示提示信息，用户可以重新输入或者该用例；账户中的存款金额不足，显示提示信息，用户可以重新输入金额或者终止该用例，允许重复操作不超过3次。2.3.4.4转账 1）简单描述，本用例允许银行职员按照客户的要求将资金从一个账户转入到另一个账户。 2）前置条件，在本用例开始前，用户必须登录到系统中。 3）后置条件，如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变 4）当客户要求转账时，用例启动： （1）系统提示银行职员输入用户姓名、用户的ID号、账户号码和转账金额。 （2）银行职员输入相关信息后提交。（3）系统确认资金转出账户是否存在并有效（当用户名、用户的ID号与账户的户主信息一致且用户处于非冻结状态时，账户有效），资金转出账户中的资金是否足够支付所转款项。 （4）更新资金转出账户的相关信息。（5）为资金转出账户建立转账记录。 （6）存储转账记录。 （7）判断资金转入账户是否属于同一银行，如果资金转入账户与资金转出账户属于同一银行，则执行分支流S-1：在同一银行的账户间转账；如果资金转入账户与资金转出账户属于不同银行，则执行分支流S-2：在不同银行的账户间转账。 5）分支流 S-1：在同一银行的账户间转账： （1）系统确认资金转入账户是否存在并有效（当账户处于非冻结状态时， 账户有效） （2）更新资金转入账户的相关信息。 （3）为资金转入账户建立转账记录。 （4）存储转账记录。 S-2：在不同银行的账户间转账： （1）发送转账通知给另一银行。6）账户不存在或者无效，显示提示信息，用户可以重新出入或者终止该用例，允许重复操作3次；账户中的存款金额不足，显示提示信息，用户可以修改所转款项的金额或终止该用例。2.3.4.5管理账户1）前置条件，在这个用例开始前，银行职员必须登录到系统中。2）后置条件，如果这个用例成功，账户信息会被添加到系统中、或被更新（修改）、或从系统中删除。否则，系统的状态没有变化。 3）当银行职员想添加、修改或者删除账户信息时，用例启动： （1）系统要求银行职员选择所要执行的活动（添加账户、修改账户信息、或删除账户）。 （2）如果所选的活动是“添加账户”，则执行分支流S-1：添加账户。 （3）如果所选的活动是“删除账户”，则执行分支流S-2：删除账户。 （4）如果所选的活动是“修改账户”，则执行分支流S-3：修改账户信息。 4）分支流 S-1：添加账户 （1）系统要求银行职员输入客户信息：姓名、ID号、地址、存储金额。 （2）银行职员输入多要求的信息后提交。（3）系统为客户建立账户。（4）将账户信息存储到数据库中。 S-2：删除账户（1）系统提示银行职员输入账号。（2）银行职员输入账号后提交。（3）系统检索账户信息。（4）显示账户信息。（5）银行确认删除。（6）关闭账户。（7）从系统中删除账户。 S-3：修改账户信息（1）系统提示银行职员输入账号。（2）银行职员输入账号后提交。（3）系统检索账户信息。（4）显示账户信息。（5）银行职员修改账户信息。（6）银行职员修改完毕后提交。（7）系统更新账户信息。5）输入无效的账号，银行职员可以重新输入或终止该用例；账户不存在，系统显示错误信息，银行职员重新输入账号或者取消操作，允许重复操作3次（用例终止）；取消删除，删除账户操作被取消，用例终止。3.系统分析3.1系统用例建模系统的用例图如图3.1所示，参与者“银行职员”与用例“登录”、“管理账户”交互，参与者“银行职员”作为参与者“客户”的代理与用例“开户”、“销户”、“存款”、“取款”、“转账”交互，也即参与者“客户”依赖参与者“银行职员”完成开户、销户、存款、取款、转账的动作。用例“转账”具有两个子用例“在银行内转账”和“在不同的银行之间转账”，因此他们之间存在类属关系。另外，用例“在不同的银行之间转账”要代表另一个银行的参与者“其他银行职员”交互。图3.1 系统用例图3.2静态结构模型3.2.1类的识别进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对象分析的基本任务。系统的静态结构模型主要用类图和对象图描述系统中主要的类。在系统分析过程中，要严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选类时主要依据冗余、无关性、笼统、属性、操作和实现等标准，删除不正确或不必要的类与对象1. 根据给出的需求陈述，从陈述中找出下列名词，可以把它们作为类与对象的初步的候选者：银行，账户，客户，资金，计算机，储蓄管理系统，存储卡，工作人员，存/取款单。通常，在需求陈述中不会一个不漏地写出问题域中的所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。2. 筛选出正确的类与对象通过一个简单、机械的过程不可能正确地完成分析工作。非正式分析仅仅帮助人们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉那些不必要的，仅仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选时主要依据下列标准，删除不正确或不必要的类与对象。经过分析，选出需要的类：（1）.银行在这个系统中，银行没有相关的行为，但有身份，所以成为一个类，类名为“银行”。（2）.账户账户也有身份，可以根据账户的账号来区别账户，具有不同账号的账户是不同的。账户具有相关的行为，资金可以存入到账户、或从账户中取出、或在账户之间转移，所以账户是系统中的一个类，类名为“账户”。（3）.客户客户也具有身份，具有相同名字和不同身份证号码的两个人也是不同的。在这个系统中，客户没有相关的行为，但有身份，所以客户是系统中的一个对象，类名为“客户”。（4）.资金资金没有身份，资金可以存入、取出或在账户间转移，但这是账户的行为，而不是资金自身的行为，所以用一个简单的浮点数值来表示资金。3.2.2类的关联分析多数人习惯于在初步分析确定了问题域中的类与对象之后，接下来就分析确定类与对象之间存在的关联关系。当然这样的工作顺序并不是绝对必要的。由于在整个开发过程中面向对象概念和表示符号的一致性，分析员在选取自己习惯的工作方式时拥有相当大的灵活性。在需求陈述中使用的描述性动词或者动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些隐含的关联。根据系统中识别出的类，识别出类之间的关系，。类“银行主界面”与类“登录窗口”之间存在“一对多”的关联关系，而“账户窗口”、“查找账户窗口”、“转账窗口”、“存款或取款窗口”是“银行主界面”的一部分，它们与“银行主界面”具有一致的生命周期，因此它们与类“银行主界面”之间是组合的关联关系。类“账户窗口”、“查找账户窗口”、“转账窗口”、“存款或取款窗口”与类“账户”之间是依赖关联关系。类“账户”与“客户”之间是多对多的关联关系，1个客户对象至少持有1个账户对象，1个账户对象至少由1个客户持有（联合账户可以由多个客户共同持有）。类“账户”和类“银行”之间是“多对多”的关联关系，类“账户”是类“银行”的一部分，1个银行对象至少有一个账户对象，1个账户对象只属于1个银行。类“账户”与类“交易”存在“一对多”的关联关系，1个账户对象可以没有或有多个交易记录（交易对象），1个交易对象只属于一个账户。类“存款”、“取款”、“转账”继承类“交易”，因此它们和类“交易”之间是隶属的关联关系。3.2.3类的属性描述3.2.31类：银行银行代表物理存在的银行，应该具有下列私有属性：银行代码:字符型银行名:字符型银行地址:字符型电话:字符型3.2.3.2类：账户账户应具有如下私有属性：账号:数字型账户穿创建日期:时间性余额:实数型3.2.3.3类：客户客户具有如下私有属性：姓名:字符型客户号码:字符型客户地址:字符型3.2.3.4类：转账转账具有如下私有属性：账目:账目型日期:时间型资金:实数型3.2.4 类图的构建 经过以上各个过程的分析可以得出系统的类图如图3.2 所示图3.2 系统类图3.3系统动态模型3.3.1系统执行顺序分析3.3.1.1开户：开户的顺序图如图2.3所示，客户要求创建新账户，银行职员发送消息“新账户（）”给类“银行系统界面”，类“银行系统界面”发送消息“新窗口（）”给类“账户窗口”，创建用于填写账户信息的窗口。银行职员填写必要的信息后，提交，类“账户窗口”的方法“新账户（）”被调用，发送消息“新账户（）”给类“账户”，创建账户对象。在方法“新账户（）”被执行过程中，要调用方法“查询（）”查询是否已在数据库中存在。若该账户已在数据库中存在，类“账户”发送消息“更新（）”给类“客户”，更新数据库中该客户的信息；反之，若数据库中不存在该客户信息，则类“账户”发送消息“新账户（）”给类“客户”，创建客户对象，然后调用方法“存储（）”将客户信息存储到数据库中。图3.3 开户顺序图3.3.1.2销户销户的顺序图如图3.4所示，客户要求删除账户，银行职员发送消息“删除账户（）”给类“银行系统界面”，类“银行系统界面”发送消息“新查询窗口（）”给类“查询窗口”，创建用于填写账号的窗口。银行职员账号后，提交，类“查询窗口”的方法“查询（）”被调用，发送消息“获取账户（）”给类“账户”，返回匹配指定账户的账户信息，调用方法“新窗口（）”创建窗口并将账户信息显示在窗口中。银行职员确认删除，类“账户窗口（）”的方法“删除账户（）”被调用，在方法“注销账户（）”被执行过程中，要调用方法“关闭账户（）”结清账户的利息和余额，关闭账户，然后调用“删除（）”从数据库中删除账户，发送“更新（）”给“客户”，更新信息，删除数据库中的账户信息。图3.4 销户顺序图3.3.1.3修改账户修改账户信息的顺序图如图3.5所示，银行职员发送消息“修改账户（）”给类“银行系统界面”，类“银行系统界面”又发送消息“新查询窗口（）”给类“查询窗口”，创建用于填写账号的窗口。银行职员账号后，提交，类“查询窗口”的方法“查询（）”被调用，发送消息“获取账户（）”给类“账户”，返回匹配指定账号的账户信息，调用方法“新窗口（）”创建窗口并将账户信息显示在窗口中。银行职员修改账户信息后，提交，类“账户窗口”的方法“修改账户（）”被调用，发送消息“更新（）”给类“客户”，更新数据库中的账户信息。图3.5 修改账户顺序图3.3.1.4存款存款的顺序图如图3.6所示，客户要求存款，银行职员发送消息“存款（）”给类“银行系统界面”，类“银行系统界面”又发送消息“创建窗口（）”给类“存取款窗口”，也即类“存取款窗口”的方法“创建窗口（）”被调用，创建用于填写存款信息的窗口。银行职员填写必要的信息后，提交，类“存取款窗口”的方法“存款（）”被调用，发送消息“存款（）”给类“账户”。在类“账户”的方法“存款（）”的执行过程中，首先，调用类“账户”的方法“查询（）”，确认数据库中是否存在该账户，若存在，则发送消息“创建窗口（）”给类“存款”，创建一个存款交易记录，然后调用方法“存储（）”将该记录存储到数据库中。调用类“账户”的方法“新的账户余额（）”计算新的账户余额，最后调用方法“更新（）”更新数据库中该账户的信息。图3.6 存款顺序图3.3.1.5取款取款的顺序图如图3.7所示，客户要求取款，银行职员发送消息“取款（）”给类“银行系统界面”，类“银行系统界面”又发送消息“创建窗口（）”给类“存取款窗口”，也即类“存取款窗口”的方法“创建窗口（）”被调用，创建用于填写取款信息的窗口。银行职员填写必要的信息后，提交，类“存取款窗口”的方法“取款（）”被调用，发送消息“取款（）”给类“账户”。在类“账户”的方法“取款（）”的执行过程中，首先，调用类“账户”的方法“查询（）”，确认数据库中是否存在该账户，若存在，则发送消息“创建窗口（）”给类“存款”，创建一个取款交易记录，然后调用方法“存储（）”将该记录存储到数据库中。调用类“账户”的方法“新的账户余额（）”计算新的账户余额，最后调用方法“更新（）”更新数据库中该账户的信息。图3.7 取款顺序图3.3.1.6在银行内转帐在银行内转账的顺序图如图3.8所示，银行职员发送消息“转账（）”给类“银行系统界面”，类“银行系统界面”又发送消息“创建窗口（）”给类“转账窗口”，创建用于填写转账信息的窗口。银行职员填写必要的信息后，提交，类“转账窗口”的方法“转账（）”被调用，发送消息“转出账款（）”给类“账户t1”，并查询此账户是否存在且资金是否足够然后计算新的账户余额并更新信息。然后发送消息“新的转账（）”给类“转账”，创建一个转账交易记录，然后调用方法“存储（）”将该记录存储到数据库中。类“转账窗口”还发送消息“转入账款（）”给类“账户t2”，并查询此账户是否存在，然后计算新的账户余额并更新信息。然后发送消息“新的转账（）”给类“转账”，创建一个转账交易记录，然后调用方法“存储（）”将该记录存储到数据库中。图3.8 银行内转账顺序图3.3.1.7在银行之间转账在银行之间转账的顺序图如图3.9所示，银行职员发送消息“转账（）”给类“银行系统界面”，类“银行系统界面”又发送消息“创建窗口（）”给类“转账窗口”，创建用于填写转账信息的窗口。银行职员填写必要的信息后，提交，类“转账窗口”的方法“转账（）”被调用，发送消息“转出账款（）”或“转入账款（）”给“账户”，并查询此账户是否存在，如果是资金转出，还要检查资金是否足够，然后计算新的账户余额并更新信息。然后发送消息“新的转账（）”给类“转账”，创建一个转账交易记录，然后调用方法“存储（）”将该记录存储到数据库中。最后发送转账通知给另一个银行。图3.9 跨行转账顺序图3.3.1.8登录登录的顺序图如图3.10所示，银行职员启动系统，类“登录窗口”的方法“新建窗口（）”被调用，创建用来填写登录信息的窗口。银行职员填写登录信息后，提交执行方法“确认（）”，验证用户名和密码是否正确，若正确，发送消息“新的银行系统界面（）”，启动系统，创建系统主界面。图3.10 登录顺序图3.3.2系统的协作分析合作图也称为协作图，用于描述相互合作的对象间的交互关系和链接关系。与顺序图一样，合作图也展示了对象间的动态协作关系。它除了说明信息的交换外，还显示对象间的连接关系，描述信息在连接的对象之间的传递。根据以上对仓库设备管理系统各模块的分析得出的顺序图，可以得出：1.开户的协作图如图3.11所示图3.11 开户协作图2、销户的协作图如图3.12所示图3.12 销户协作图3、存款协作图如图3.13所示图3.13 存款协作图4、在银行内转帐协作图如图3.14所示图3.14银行内转账协作图5、在银行之间转帐协作图如图3.15所示图3.15银行间转账协作图6、登录协作图如图3.16所示图3.16 登录协作图3.3.3系统状态分析状态图描述了事件和对象状态的关系。顺序图和协作图都属于交互图，主要用来描述系统对象之间的动态协作关系，以及写作过程中的行为次序。交互图常用来描述一个用例中的几个对象协作工作的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况，但是并不对这些对象的行为，就应该使用状态图。根据对各模块的用例分析得出各模块的状态图如下：1、存取款状态图如图3.17所示图3.17 存取款状态图2、转账状态图如图3.18所示图3.18 转账状态图3、开户/销户状态图如图3.19所示图3.19 开户/销户状态图3.3.4系统活动分析3.3.4.1存款活动图如图3.20所示，该活动是对“存款”用例的进一步描述，它允许客户借助“银行职员”存款到账户中。在本用例开始前，银行职员必须登录到系统中。通过验证用户输入和提交的信息，银行职员判断该客户账户是否存在并有效，若存在有效，则进行取款活动，这时客户账户中存款的金额发生变化。系统把相应数据存入数据库并更新账户。否则，系统状态不变。图3.20 存款活动图3.3.4.2取款活动图如图3.21所示，该活动图是对“取款”用例的进一步描述，主要是允许银行职员按照客户的要求从客户的账户中取款，并交给用户。首先用户需要输入和提交相关信息，然后输入密码，系统通过检验输入信息和密码等确认该用户是否有效，如果有效则查看用户账户的资金是否充裕，如果充裕，则取钱交给该用户。 完毕以后系统建立交易记录，并更新然后存入数据库中。图3.21 取款活动图3.3.4.3开户活动图如图3.22所示，该活动图描述的是“管理账户”用例中的创建用户部分。主要是账户通过信息窗口通过输入信息和提交信息以后建立新账户，最终该该账户被保存到数据库中。图3.22 开户活动图3.3.4.3转账活动图如图3.23所示的活动图模拟了转账的工作流，银行职员按照客户的要求将资金从一个账户转入到另一个账户。这期间主要分为在同一银行内部转账和在不同银行之间转账。在同一银行内部转账主要需要检查用户账户存在并是否有效，然后查看用户金额是否充裕，充裕则转账，并显示余额后更新账户，建立账户记录并更新，最后把更新数据存入数据库。比较而言，在不同银行之间转账，除上述一些基本操作外需要通知另外一家银行，在转账之前需检查另外这家银行是否存在并有效，如有效，则进行转账操作。最后建立交易记录并更新该账户，把相应数据存入数据库。图3.2转账活动图3.3.4.4销户活动图如图3.24所示该活动图是对用例“管理账户”中删除账户部分做的进一步描述，主要是账户通过输入信息并提交相关信息，银行职员根据系统显示的账户信息确定是否删除该账户，最后退出账户，系统从数据库中删除该账户。图3.24 销户活动图系统设计与实现4.1 UML体系结构设计4.1.1硬件体系结构设计4.1.1.1 主机客户端：CUP：Inter(R) Pentium(R) E2180 主频：2.00HZ 内存：2G 服务器：服务器的中央处理部件（CPU）使用Intel的至强(Xeon)系列处理器。服务器内存必须使用服务器专用ECC内存4.1.1.2 外存储器客户端硬盘：160G 服务器的外存200G磁盘4.1.1.3 终端与外部设备显示器及显示卡：三星显示器，显卡可以选择集成显卡。分辨率不低于1024x768，64位PCI接口，缓存1MB以上；通讯口：至少一个RS232串行通讯口和一个并行接口；网络接口板：16或32位接口, CD-ROM光盘驱动器: 24倍速以上。4.1.1.4其他辅助设备备份设备：CD-ROM光盘刻录机一台。佳能打印机一台。金山防火墙组件。计算机系统的硬件配置如图3.1所示。Inter Pentium内存2G其他设备硬盘160G数据库服务器数据库网络服务器防火墙图4.1 硬件配置图4.1.2软件体系结构设计因为硬件的配置比较的先进，所以在选择软件方面提供了很大的空间，考虑到服务器运行的图书要求，所以排除桌面操作系统的运用，由于图书馆计算机专业人员较少，所以主机的操作系统选择桌面操作系统。杀毒软件及防火墙均按照系统的需求以及硬件设备的情况选择。4.1.2.1操作系统服务器操作系统：windows NT客户端操作系统：windows XP4.1.2.2 数据库管理系统DBMS：SQL Server 20054.1.2.3 使用的编程语言.NET 2008 SQL Server 语言。4.1.2.4 软件工具金山防火墙、windows自带的防火墙、金山杀毒软件4.2对象模型设计4.2.1定义系统对象类（1）类银行银行代表物理存在的银行，应该具有下列私有属性：银行代码:String银行名称:String地址:String电话:String（2）类账户在确定类账户的属性和方法时，应考虑如下需求：·一个银行可以有多个账户根据这个需求，银行应该可以提供账户列表，但这个账户列表不必被银行外的对象访问。可以用数据库实现这个需求。·一个账户可以有多个持有者持有者():Customer·可以开户新账户(holder:Customer,balance:float):void·可以注销账户注销账户(accountNo:String):void·可以取钱取款(holderName:String,holderID:String,accountNo:String,money:float):float·可以存钱存款(holderName:String,holderID:String,accountNo:String,money:float):float·可以在银行内的账户之间转账银行内转账(accountNo:String,bankCode:String,money:float):float银行间转账(accountNo:String,bankCode:String,money:float):float账户应具有如下私有属性：银行:bank拥有者:customers号码:string开户日期:date密码:float(3)类客户·一个银行可以有多个客户根据这个需求，银行应该可以提供客户列表，但这个客户列表不必被银行外的对象访问。可以用数据库实现这个需求。·一个客户可以有多个账户开户():Account拥有账户()：Boolean删除（）：void客户具有如下私有属性：姓名:string客户号码:string地址:string账户:account在银行中，对账户进行存钱、取钱、转账操作，要保留业务记录，因此在系统中还应有代表这些业务记录的对象存在，可以为这些对象建立如下3个类： 存款业务记录、取款业务记录、转账业务记录，这三个类都是一种业务记录因此可以抽象出父类：转账业务记录（4）类转账业务记录·私有属性账户：Account创建日期：Date资金：float（5）类存款继承类转账业务记录·私有属性：无 (6)类取款继承类转账业务记录·私有属性：无·公共方法：无(7)类转账继承类转账业务记录·私有属性：转账账户:String转账银行:Bank根据上述分析，本系统的对象图如图4.2所示 图4.2 系统对象图4.3系统实现4.3.1组件分析组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，它实际上是一个文件，可以有源代码构件、二进制构件、可执行构件。构件对外提供的可见操作和属性称为构件的界面。在UML中，组件图描述了组件及组件之间的关系，表示了组件之间的组织和依赖关系。组件图是用来为面向对象系统的物理方面建模的图形之一。经过分析，银行储蓄管理系统的组件图如图4.2所示图4.3 系统组件图4.3.2配置分析配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。可以显示计算机结点的拓扑结构和通信路径，结点上执行的软构件，软构件包含的逻辑单元等，特别对于分布式系统，配置图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种软构件和对象的配置。配置图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，银行储蓄管理系统的配置图如图4.3所示。图4.4 系统配置图5.课程设计体会心得在本项目的软件开发的过程中，我全面实践一个面向对象应用系统的开发过程，学习很多有关的知识。这样的项目对我们学过的数据结构、程序设计、数据库、软件工程等课程是一