“储蓄业务子系统”概要设计报告.doc

“储蓄业务子系统”概要设计报告 引言 1标识 文件状态: [ ]草稿 [ √ ]正式发布 [ ]正在修改 文件标识: 需求分析报告A2 单前版本: 1.0 作 者: XY 完成日期: Xxxx-xx-xx 2系统概述 (见《储蓄业务子系统需求分析报告》的1. 2系统概述) 3文档概述 文档根据《储蓄业务子系统需求分析报告》，对软件的功能实现、接口和界面等进行设计。文档采用了面向对象的设计方法，描述了系统中主要的类、各用例对应的顺序图等。 4基线 [1] 储蓄业务子系统需求分析报告1.0 2. 引用文件 计算机软件文档编制规范(GB/T 8567-2006 ) , 2006年3月14日发布，2006年7月1日实施。 3. 系统结构 系统采用s/s结构，用户界面通过www浏览器来实现，主要的业务逻辑在Web服务 器和应用服务器端实现，数据存储在数据库服务器，形成常见的Web应用三层结构。 系统开发采用MVC Model-View-Controller)框架，模型( Model)提供数据的内部表 示，视图(View)负责显示数据，控制器(Controller)负责对用户的输人或内部事件进行解 释，决定要做的处理步骤和处理内容，控制模型和视图做相应的改变。 3.1部署图 系统部署如图A2-1所示，前台采用Web浏览器显示页面，后台包括Web服务器、应用服务器和数据库服务器，主要处理业务逻辑。 提高数据的安全性，一台备份数据库服务器专用于数据的实时备份，当数据库服务器出 现故障时，通过人工切换可以保证银行业务基本上不受影响。 图A2-1系统部署图 图A2-2为系统的实体类图，系统中主要有七个实体类:客户类(Customer)、拥有类(Possess),账户类(Account)、存款信息类(Deposit)、子账户类(SubAccount)、取款信息类(Fetch)。下面给出每个类的描述。 类Account为一卡通账户类，accountNo属性表示账户的账号，password属性为密码，loss为是否挂失或销户，lossDate为挂失或销户的日期。具体属性数据类型与需求中的数据字典相似。对应的set * ( )方法的功能为给这些私有属性赋值，而get *()方法则得到这些属性值。 类Customer(略) 类Possess(略) 类Deposit(略) 类SubAccount(略) 图A2-2实体类图 图A2-3所示为边界和控制类图(只画出开户(OpenAccount )、存款(Deposit)、取款(Fetch)、转账( Transfer)和挂失(ReportLoss)相关的类)，其中，边界类负责用户与系统的交互，控制类负责业务处理，修改数据库并控制边界类。 OpenAccountForm为开户功能界面，其属性为开户时用户要输人的项。而OpenAccountController控制OpenAccountForm，并根据相应操作，对Account实体类进行修改，存储到数据库中。它有一个Account类的成员变量account。函数newAccount()生成Account类，insertAccount()把类写入数据库。 (其余类的描述略) 图A2-3边界类和控制类 (只给出具体的OpenAccountController和OpenAccountForm的描述) 4.执行概念 下面采用顺序图来表示各对象之间或对象与参与者之间如何通过交互来实现需求中的功能，每个顺序图分别与需求文档中的用例相对应。 4. 1开户 一卡通开户的顺序图如图A2-4所示，其中客户和柜台人员为用例中的参与者，OpenAccountForm为边界类，表示开户时的界面;()penAccountController为控制类，控制边界类和实体类间的交互;Customer和Account为实体类，与数据库中的客户表和账户信息表对应。横线上的文字描述了对象发出和接收的消息。 4. 2挂失 一卡通挂失的顺序图如图A2-5所示，其中客户和柜台人员为用例中的参与者，ReportLossForm为边界类，表示挂失界面;ReportLossController为控制类;Account为实体类。 4．3存欺 存款的顺序图如图A2-6所示，其中客户和柜台人员为用例中的参与者，DepositForm为边界类，表示存款界面;DepositController为控制类;Account和SubAccount为实体类。 (异常处理略) 图A2-4开户顺序 图A2-5挂失顺序 图A2-6存款顺序 4. 4取欺 取款的顺序图如图A2-7所