| 银行业务管理系统系统设计与实现报告 | 您所在的位置：网站首页 › 银行系统分析与设计 › 银行业务管理系统系统设计与实现报告 |
银行业务管理系统系统设计与实现报告
|
1 概述
本项目使用 Ruby on Rails 实现了一个简易的银行业务管理系统，已于 GitHub 开源，地址为 https://github.com/iBug/Junk-Bank-System。另外本项目还发布在了 Docker Hub 上（镜像为 ibugone/junk-bank-system），并据此实现了使用 Docker Compose 的简易部署，其配置文件位于 https://github.com/iBug/Junk-Bank-System/blob/master/docker-compose.yml。 1.1 系统目标某银行准备开发一个银行业务管理系统，要求实现客户管理、账户管理、贷款管理与业务统计四大类功能。详细需求在 1.2.2 节介绍。 1.2 需求说明 1.2.1 数据需求银行有多个支行。各个支行位于某个城市，每个支行有唯一的名字。银行要监控每个支行的资产。 银行的客户通过其身份证号来标识。银行存储每个客户的姓名、联系电话以及家庭住址。为了安全起见，银行还要求客户提供一位联系人的信息，包括联系人姓名、手机号、Email 以及与客户的关系。客户可以有帐户，并且可以贷款。客户可能和某个银行员工发生联系，该员工是此客户的贷款负责人或银行帐户负责人。银行员工也通过身份证号来标识。员工分为部门经理和普通员工，每个部门经理都负责领导其所在部门的员工，并且每个员工只允许在一个部门内工作。每个支行的管理机构存储每个员工的姓名、电话号码、家庭地址、所在的部门号、部门名称、部门类型及部门经理的身份证号。银行还需知道每个员工开始工作的日期，由此日期可以推知员工的雇佣期。银行提供两类帐户：储蓄帐户和支票帐户。帐户可以由多个客户所共有，一个客户也可开设多个账户，但在一个支行内最多只能开设一个储蓄账户和一个支票账户。每个帐户被赋以唯一的帐户号。银行记录每个帐户的余额、开户日期、开户的支行名以及每个帐户所有者访问该帐户的最近日期。另外，每个储蓄帐户有利率和货币类型，且每个支票帐户有透支额。每笔贷款由某个分支机构发放，能被一个或多个客户所共有。每笔贷款用唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次支付的情况（银行将贷款分几次付给客户）。虽然贷款号不能唯一标识银行所有为贷款所付的款项，但可以唯一标识为某贷款所付的款项。对每次的付款需要记录日期和金额。 1.2.2 功能需求 客户管理：提供客户所有信息的增、删、改、查功能；如果客户存在着关联账户或者贷款记录，则不允许删除； 账户管理：提供账户开户、销户、修改、查询功能，包括储蓄账户和支票账户；账户号不允许修改； 贷款管理：提供贷款信息的增、删、查功能，提供贷款发放功能；贷款信息一旦添加成功后不允许修改；要求能查询每笔贷款的当前状态（未开始发放、发放中、已全部发放）；处于发放中状态的贷款记录不允许删除； 业务统计：按业务分类（储蓄、贷款）和时间（月、季、年）统计各个支行的业务总金额和用户数，要求对统计结果同时提供表格和曲线图两种可视化展示方式。 1.2.3 需求说明 支行、部门和员工的信息需要预先插入到数据库中，本项目假设这三类数据已经在数据库中了，并且本实验不要求实现这三类数据的维护。 后台 DBMS 使用 MySQL； 前端开发工具不限，可以是 C/S 架构也可以是 B/S 架构； 查询功能允许自行设计，但要求尽可能灵活设计，考虑用户多样化的查询需求； 各类数据的类型可自行根据实际情况设计； 测试数据自行设计； 系统实现时要保证数据之间的一致性； 程序须有一定的出错处理，要求自己先做好测试，能够处理可以预见的一些错误，例如输入的客户姓名带单引号（类似 O'Neil）、输入数据不合法等等； 其余功能可以自行添加，例如登录管理、权限管理等等，但不做强制要求。如果做了添加，请在实验报告中加以描述； 本实验要求单独完成。 1.3 本报告的主要贡献众所周知，好的实验报告是成功实验的一半。因此 本报告的主要贡献在于完整、详实、丰富地填满了这份繁杂冗长的实验报告模板，尽自己所能充实了各位助教阅读实验报告的体验。 其次，本报告介绍了一个采用良好开发技术达到 1.1 节所述目标、完成 1.2 节所述需求的 B/S 架构的银行业务管理系统，并对其代码及实现技巧进行了详细的剖析 另外，本报告通过详细的分析，介绍了 Ruby on Rails 框架的强大与便捷 最后，本报告在第 5 章为实验及实验报告的设计提出了一些改进意见。 2 总体设计系统采用 Ruby on Rails 框架，使用 Model-View-Controller 架构进行前后端一体的全栈开发，前端采用 Bootstrap 4 进行界面设计与优化，并使用 JavaScript 与 jQuery 实现页面上的动态功能。 2.1 系统模块结构本系统采用标准的 Ruby on Rails 全找开发结构，其结构如下图所示：
各模块功能： Puma Server 负责处理客户端（浏览器）发来的 HTTP 请求，解析内容，并根据路由规则选择合适的控制器和动作，以及向客户端返回 HTTP 响应 Controller (Action Controller) 负责执行实际的业务逻辑，包括调用模型与数值计算等 Model (Active Record) 为 ORM，负责与数据库通信，从数据库内容构建 Ruby 模型供其他模块使用 View (Action View) 负责从模板渲染 HTML 页面，交由 Server 返回 MySQL 或 MariaDB 为后端 DBMS，负责数据的存储与维护等模块之间的接口： 五个模块组成应用程序整体，通过 HTTP 协议与外部通信 Server 通过直接调用 Action Controller 中相关方法的方式执行动作，通过外部变量 params 传输 HTTP 请求参数（包括 URL 参数与 POST 方式的主体） MySQL 与 Active Record 通过 SQL 查询的方式通信。AR 维护一个 SQL 客户端，通过其发送 SQL 语句及接收结果 Active Record，Action Controller 与 Action View 之间均通过传递 Ruby 对象的方式传输数据具体的 Active Record 模型、Action Controller 控制器与 Action View 视图在第 3 节介绍。 2.2 系统工作流程系统工作流程如 2.1 节的图中所示，客户端（浏览器）访问网站时实际发生的工作流程按 2.1 节的图中逆时针进行，文字过程如下： 浏览器向服务器发送 web 请求； 服务器（此处忽略前端 Nginx / Apache 等反向代理服务器）根据定义好的路由（Routes）决定该请求要交给哪个控制器处理； 控制器接收到请求，处理请求参数，根据请求内容存取所需的数据（对象模型）； 应用程序模型（Active Record）根据接收到的查询请求构造 SQL 语句，向 DBMS 服务器进行查询，将查询结果转换为 Ruby 模型，返回给调用者； 控制器完成规定的操作，获取了需要的数据，将它们发送给视图（View）控制器，视图控制器将 HTML 模板渲染成完整的 HTML 页面，传回给前端服务器； 前端服务器将 HTML 页面作为 web 响应发送给浏览器。 2.3 数据库设计数据库一共 12 个表，存储了各种实体（如账户）与实体之间的关系（如客户与账户的联系）。由于部分实验要求，如使用「名称」、「身份证号」之类的属性作为主键等对数据库设计以及 Active Record 的默认行为不够友好，因此本系统实现时全部使用自增整数 ID 作为主键，实验要求中的主键全部加上 UNIQUE NOT NULL 约束保持候选性质，按照普通属性处理。另外 Active Record 会主动记录每个项（数据表行）的创建与更改时间，因此每个表都有两个额外的时间列（由 t.timestamps 创建），与本实验无关，可以放心忽略。 下面为本实验所构建数据库模型的 ER 图：
下面为创建每个表及相关约束所使用的 Active Record 迁移脚本。 2.3.1 支行 class CreateBranches 名称 城市 资产 员工 账户 贷款标题的实现方式与列表页面相同，除了内容增加了识别信息（对于支行、部门、员工和客户，使用名称作为识别信息，对于账户和贷款则使用编号）。 主体部分为一个 元素，列出所展示对象的全部适用的属性及关联对象。list_items 为一个自定义帮助函数，其内容如下： module ApplicationHelper def list_items(items, options = {}) render partial: 'inline_listing', locals: options.merge(items: items) end end对应的列表模板 application/_inline_listing.html.erb 如下： 无 3 %> … 共 个，该列表列出了默认前 3 个对象，并在总数超过该默认值时显示总数及一个「查看全部」的链接。 卡片脚部为【编辑】（当前对象）、【返回】和【删除】三个按钮，其中在不适用的场合下【编辑】和【删除】按钮可能不存在，例如贷款的详细信息页面，当贷款状态为「发放中」时。这些按钮的功能都使用 Rails 自带的库实现。 3.3.6 创建 / 编辑表格模型表格使用 Rails 自带的 Action View Forms 实现，在新建对象时能够自动填充为默认值，在编辑对象时能够自动填充为当前值。下面以支行的编辑表格 branches/_form.html.erb 为例展示： 其中账户的新建页面有个别选项会随「账户类型」的选择而变化，且「账户类型」选项在编辑时是不可修改的。该功能使用 Vue.js 实现，相关部分代码如下： var app = new Vue({ el: '#account-form', data: {accountType: document.querySelector('[v-model="accountType"]').value} }); 3.3.7 关联信息列表页面该页面用于 支行的关联员工、账户、贷款 部门的关联员工 员工的关联客户使用一个 标签列出全部项目，每个项目自己占据一行，代码如下： 3.3.8 账户的关联客户页面账户的关联客户页面与 3.3.7 节所述的关联信息列表页面不同，使用一个完整的 table 以列出额外信息，如客户访问账户的时间等。另外主卡片下方还有一个额外卡片，作为「添加新关联客户」的表格。代码 accounts/owners.html.erb 如下： 客户 最近访问时间 操作无客户可添加 新增客户其中选择新关联客户的下拉选单仅显示可正常添加的客户（不存在冲突账户的客户），其产生逻辑见 3.2.7 节。 3.3.9 「业务统计」页面业务统计页面包含两个大卡片，分别列出储蓄业务概览数据及贷款业务概览数据，内容参见 3.2.11 节，代码 stats/index.html.erb 如下： 储蓄业务 贷款业务其中 svg_header 为一个小部件，用于在标题前面添加图标，以便美观，其代码如下： 3.3.10 业务统计的搜索页面该搜索页面由「储蓄业务」和「贷款业务」两页面共用，因此提取为 stats/_common.html.erb： 搜索结果 时间 客户数 业务额其中搜索结果使用 列出表格，使用 Chartkick 插件（后端采用 Chart.js）绘制图表。由于 Chart.js 对曲线图表有额外的技术限制难以绕过，因此此处待用了柱状图表。此处绘制两个图表，分别展示总金额和总客户数。 搜索表格代码如下： 搜索 搜索该表格使用 GET 方法发送，以确保所有搜索结果链接可复用。另外该模块包含了一个自己写的帮助脚本，其内容如下： function onSubmit(e) { $('#branch').val($('#branch_ids').val().join(" ")); $('#branch_ids').removeAttr('name'); $.each(["start_date", "end_date"], function(index, id) { var a = [], elem; for (var i = 1; i |
【本文地址】