概要设计软件工程文档模板.docx
《概要设计软件工程文档模板.docx》由会员分享，可在线阅读，更多相关《概要设计软件工程文档模板.docx（19页珍藏版）》请在冰豆网上搜索。
概要设计软件工程文档模板
预算执行与经费审批网络管理系统
概要设计说明书
V1.0
人员
时间
备注
编写
于洋
审核
陈长清
1引言
1.1编写目的
本文档的编写目的是对预算执行与经费审批网络管理系统的架构进行说明，为后继的详细设计等工作提供参考和依据，本文档主要描述的内容有：
●系统逻辑结构设计；
●接口设计；
●运行结构设计；
●数据结构设计；
●出错处理设计。
本文档的预期读者为：
系统设计人员、测试人员、用户及其它有权限查阅本文档的相关人员。
1.2背景
系统名称：
预算执行与经费审批网络管理系统V1.0
任务提出者：
开发者（承接单位）：
华中科技大学软件学院
用户：
1.3定义
1SQLServer2005：
数据库管理系统（DBMS）。
2.NetFramework：
NetFramework是微软公司继WindowsDNA以来的新的开发平台。
.NetFramework是以一种类似于Java系统的虚拟机方式运行和管理的编程平台，通过CLR为基础，支持多种语言（C#、VB.NET、C++、Python等）的开发。
3C/S模式：
Client/Server（C/S）模式的关键在于功能的分布，一些功能放在前端机（即客户机）上执行，另一些功能放在后端机（即服务器）上执行。
功能的分布在于减少计算机系统的各种瓶颈问题，与B/S（Browser/Server，浏览器/服务器）模式相比，C/S模式一般应用在基于企业内部网络的系统。
4.NetRemoting：
是在不同应用程序域之间通信的技术，可以用于访问另一个应用程序域中的对象，不论两个对象是处于一个进程中，还是处于不同的进程中，甚至处于不同的系统中。
5DAO：
DataAccessObject即数据访问对象，是第一个面向对象的接口，它显露了MicrosoftJet数据库引擎（由MicrosoftAccess所使用），并允许VisualBasic开发者通过ODBC直接连接到其他数据库一样，直接连接到Access表。
DAO最适用于单系统应用程序或小范围本地分布使用。
6ODBC：
OpenDatabaseConnectivity即开放式数据库互连，是微软公司开放服务结构（WOSA，WindowsOpenServicesArchitecture）中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。
这些API利用SQL来完成其大部分任务。
ODBC本身也提供了对SQL语言的支持，用户可以直接将SQL语句送给ODBC。
7Delegate：
即委托，是一种引用方法的类型。
一旦为委托分配了方法，委托将与该方法具有完全相同的行为。
委托方法的使用可以像其他任何方法一样，具有参数和返回值。
1.4参考资料
[1]软件工程.（英）萨默维尔著，程成，陈霞译.机械工业出版社,2006
[2]预算执行与货币化操作管理系统需求说明书V1.0
2架构设计
2.1需求规定
2.1.1功能需求
参考《预算执行与经费审批网络管理系统需求说明书V1.0》
2.1.2质量需求
（1）时间特性要求：
一般操作响应时间<=2秒，特殊操作（统计、查询等）响应时间<=5秒。
（2）灵活性：
系统应能适应如下变化，并能及时重新部署投入运行
①服务器端、客户端操作系统更换；
②部分硬件的变化（如打印机）；
③网络环境的变化（如局域网升级、重新分配IP地址等）；
④系统数据库版本的变化；
⑤系统应允许计算机操作与原有的手工操作并行进行，在系统维护或故障停运期间产生的手工记录应能无缝录入系统。
（3）安全性：
对系统敏感数据（如用户密码、数据库连接信息等）需进行加密处理。
（4）易用性：
系统部分输入单元须提供智能化的操作方法。
如预算上报部门的操作人员在上报了一份新的预算上报后，在线的预算审核系统能够实时提示有新的预算上报到达，以便于预算审核人员能够高效的审核新的上报请求。
因为本系统的使用者对计算机的操作水平有限，因此要求界面友好，方便使用。
系统要具有一定的错误处理能力，能检测用户的错误输入并给出错误提示。
（5）可扩展性：
系统应能管理部队预算执行与货币化操作管理过程中出现的新的需求，满足前期该系统使用寿命5-7年的要求。
（6）可靠性：
系统应提供数据备份和恢复能力，当系统发生故障造成数据不一致时，通过恢复能使系统回到最近一次备份时状态。
由于用户在开始使用系统时操作不熟练，也容易使系统发生问题，因此系统备份和还原操作还可以提高系统数据使用的安全性。
2.1.3输入输出要求
在预算、直接报销、报销偿还和借款上报审核和出纳的过程中，应提供相应纸质的文件作为留档凭证，并且纸质文件的尺寸和样式应能够灵活调整。
2.2运行环境
2.2.1设备
系统运行所需的硬件设备如下：
1）数据库服务器
2）应用程序服务器
3）客户端
4）打印机
其中，数据库服务器配置应满足能流畅运行SQLServer2005企业版的硬件配置要求，应用程序服务器配置应能满足流畅运行Windows2003企业版的硬件配置要求。
系统运行的网络环境为100Mb以上局域网。
2.2.2支持软件
操作系统：
应用程序服务器Windows2003，数据库服务器Windows2003，客户端WindowsXP/2000/2003；
数据库：
MicrosoftSQLServer2005企业版；
运行环境：
.NETFramework2.0。
2.3基本处理流程
预算执行与经费审批网络管理系统的主要功能结构如图2-1所示：
图2-1系统功能结构图
2.3.1上报管理
由科室上报人员填写上报信息，包括该项预算所属年度，科目，明细科目，以及所要购买或消耗的项目明细，具体信息填写完毕之后由该科室的负责人授权，即填写授权密码，通过网络将该条预算申报信息上传到数据库。
当财务审核人员打开系统后，需要根据实际情况对上报的预算提请进行审核。
具体流程如图2-2所示：
图2-2上报流程
2.3.2审核/批管理
1）财务审核员决定报销请求的审批级别。
在对多个报销请求执行批准操作时，可以利用选择框，集体地批准；在对多个报销请求执行否决操作时，可以利用选择框，集体地否决。
审核报销请求的数据处理流程如图2-3所示：
图2-3审核流程
2）财务出纳人员没有财务审核的权限，出纳人员主要负责对已经审批通过的财务业务进行出纳，出纳成功后将打印该业务的相关凭证。
出纳报销的数据处理流程如下图所示：
图2-4出纳流程
2.3.3偿还报销管理
科室可向系统提交报销请求，其中必须正确填写报销请求的相关信息，如报销人，报销科室，报销金额，报销科目，报销物品单价，数量等信息，若这些信息都填写合法，则仍需要通过科室负责人的授权，再发送到系统的服务端中。
具体情况如图2-5所示：
图2-5偿还报销流程
2.4系统架构
2.4.1系统技术架构
系统的技术架构如图2-7所示。
为了满足前期所获得的需求，本系统采用C/S模式三层架构进行设计。
C/S架构全称为Client/Server，即客户端/服务器。
在这种模式中，服务器是网络的核心，而客户机是网络的基础，客户机依靠服务器获得所需要的网络资源，而服务器则则根据客户端的相关信息提供必要的网络服务。
C/S结构的优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器。
对应的优点就是客户端响应速度快。
图2-7系统技术架构
在本系统中，我们客户端主要有四个：
预算上报客户端、财务审核客户端、财务出纳客户端和领导审核客户端。
在本系统中是通过.NetRemoting技术实现了客户端和服务器之间的交互。
首先，服务器将要提供给的服务通过一个唯一的标志服注册在一个已知的端口中，客户端通过已知的端口号和其所需要服务器提供服务模块的唯一标识名，有服务指针获取服务器提供的操作。
本系统在采用C/S模式的基础上，选用了三层架构的方式来组织系统，即界面层、业务逻辑层和数据存储层，分别对应上图中的服务器和客户端的用户界面、业务逻辑和ODBC层。
同时，由于在需求中，客户提出需要实时的在客户之间传递数据。
因此，在四个客户端之间，我们通过代理的方式，实现客户端之间信息的实时传递。
2.4.2系统部署结构
系统的部署图如图2-8所示，有四个客户端：
科室上报、财务审核、领导审批车财务出纳客户端，财务出纳客户端可以与打印机进行交互。
服务器端分别为应用服务器和数据库服务器。
图2-8系统部署结构
2.4.3子系统结构
预算执行与经费审批网络管理系统的子系统的元素（各层模块、子程序、公用程序等）的划分入表2-1所示，表2-1简要地说明了每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制的关系。
表2-1系统模块划分
子模块
功能需求
程序（表单）
审批/核管理
1、判断某用户是否对某请求有审核/批权限；
2、财务审核预算；
3、领导审批请求；
4、财务审核请求；
5、财务审核报销请求；
6、财务审核借款请求
IBudgetApprove
借款管理
1、发出借款请求
IBudgetBorrow
信息查询
1、查询所有开支方式；
2、查询所有采购方式；
3、查询所有年度信息；
4、查询所有部门信息；
5、查询部门下的所有科室信息；
6、查询预算的相关信息；
7、查询借款的相关信息；
8、查询报销的相关信息；
9、查询审核/批相关信息
IBudgetCheck
偿还管理
1、发送直接报销或报销偿还请求；
2、执行借款请求；
3、执行直接报销请求；
4、执行偿还报销请求；
5、执行现金偿还请求；
6、添加新的报销金额相关信息；
7、判断信息的合法性
IBudgetPay
上报管理
1、上报预算相关信息；
2、向服务端发送报销提示信息
IBudgetReport
交互管理
1、上报操作完成提醒；
2、财务审核操作完成提醒；
3、审批通过操作提醒
ICommunication
数据库管理
1、备份数据库；
2、还原数据库；
3、清除所有一级预算相关信息；
4、获取备份文件列表
IDatabaseManage
基本信息管理
1、增删改科目相关信息；
2、增删改部门相关信息；
3、增删改部门下科室相关信息；
4、增删改年度相关信息；
5、增删改用户相关信息；
6、增删改开支方式的所有相关信息
IInformationManage
用户权限管理
1、验证科室负责人授权密码；
2、科室、领导和财务用户信息验证；
3、查询用户相关信息；
4、向服务器端发出登入/出信息；
5、判断用户类型
IUserAuthority
本系统根据实际情况的需要分成了三个之系统，各个子系统分别由上述子模块组成。
如表2-2所示：
表2-2子系统的模块组成
子系统
功能需求
组成子模块
科室上报子系统
1、提供预算上报请求；
2、用户借款请求；
3、直接报销请求；
4、偿还报销请求；
5、预算详细信息查询；
6、个人借款信息查询；
7、个人报销信息查询；
8、本科室借款报销信息查询；
9、当前用户口令的修改。
IUserAuthority
IBudgetReport
IBudgetCheck
IBudgetBorrow
IBudgetPay
ICommunication
财务审核子系统
1、财务预算审核；
2、财务借款审核；
3、财务直接报销审核；
4、财务偿还报销审核；
5、借款出纳；
6、直接报销出纳；
7、偿还报销出纳；
8、现金偿还报销；
9、部门科室信息、预算科目信息、年度管理和开支方式信息管理；
10、系统用户信息管理；
11、预算详细信息查询；
12、借款报销记录查询；
13、报销数据统计；
14、数据库文件的备份与还原；
15、当前用户口令信息的修改。
IUserAuthority
IBudgetCheck
IBudgetApprove
IBudgetPay
IBudgetReport
IBudgetBorrow
IDatabaseManage
IInformationManage
ICommunication
领导审核子系统
1、审批本部门借款；
2、审批本部门直接报销；
3、审批本部门偿还报销；
4、查询本部门预算信息；
5、预算详细信息查询；
6、借款报销记录查询；
7、当前用户口令信息的修改。
IUserAuthority
IBudgetCheck
IBudgetApprove
ICommunication
2.5人工处理过程
1）在出纳审核通过科室上报人员上报的报销和借款单之后，需要打印相应的报销和借款单作为纸质存档。
2）系统的使用者，如预算上报人员为了及时了解上报的预算请求处理的阶段，需要手工的记录上报预算的处理阶段；
3）财务审核人员要对数据库进行备份和还原等操作时，需要手动完成。
2.6尚未解决的问题
1）被否决预算、直接报销和借款未作相应的日志记录；
2）系统为提供可控的数据库自动备份操作，每次备份需要操作人员手工完成，不利于一些突发事件预防；
3）根据具体业务需要，系统中包含三个客户端：
科室上报客户端、财务审核客户端和部门领导审核财务端。
但在系统中并未使用工作流等方式来实时监控工作进行的流程。
3接口设计
3.1用户接口
在用户界面部分，根据需求分析的结果，用户需要一个用户友善界面。
在界面设计上，应做到简单明了，易于操作，并且要注意到界面的布局，应突出的显示重要以及出错信息。
外观上也要做到合理化，考虑到用户多对WINDOW风格较熟悉，应尽量向这一方向靠拢。
在设计语言上，已决定使用VISUALC#进行编程，在界面上可使用VISUALC#所提供的可视化组件，向WINDOWS风格靠近。
其中服务器程序界面要做到操作简单，易于管理。
在设计上采用下拉式菜单方式，在出错显示上可调用VISUALC#库中的错误提示函数。
系统中涉及到的主要用户接口如下：
1）运行预算执行和货币化操作管理系统的应用服务器需要根据实际情况，配置数据库服务器的IP地址和数据库连接字符串，才能连接上数据库管理系统SQLSERVER2005；
2）各个部门相关的预算执行和货币化操作系统的客户端需要根据应用服务器的IP地址和端口号，才能连接上应用服务器，从而获取所需的操作服务；
3）系统管理员可以通过操作SQLSERVER2005数据库管理引擎，来实现对数据库文件进行定时备份等数据文件的相关操作。
3.2外部接口
由于该软件是一款应用软件，并且在完成相应的工作时需要其他一些软件和硬件的支持，因此需要一些外部接口与系统的支持软硬件相结合。
本系统的外部接口主要有：
1）服务器端需安装WindowsXP/2003、SQLServer2005；客户端需安装WindowsXP/2000/2003、打印机驱动等软件；
2）必须留有20G以上的硬盘空间；
3）计算机在奔腾五以上的运行效果更佳。
3.3内部接口
内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。
具体参数的结构将在下面数据结构设计的内容中说明。
接口传递的信息将是以数据结构封装了的数据，以参数传递或返回值的形式在各模块间传输。
具体在系统中，主要内部接口有：
1）大部分采用COM技术，提高代码的重复利用率；
2）大量采用窗体的继承，保证风格的一致。
4运行设计
4.1运行模块组合
系统运行需要后台数据库、.NetRemoting、系统总控、完成特定数据管理功能程序模块和Winform显示控制几个部分协同工作。
4.2运行控制
系统需要先启动数据库服务器，启动无误后，各个客户端的用户通过实现获取服务器端的IP地址和端口号，就可以登录进入系统开始各种操作。
4.3运行时间
后台数据库服务器和应用服务器可以共同部署在一台服务器上，也可以各自占用一台机器，三个客户端可以在一台机器上，亦可以各自分开，通过局域网与服务器进行连接。
在运行是，应用服务器和数据库服务器必须同时开启，各个客户端则可以根据需要随时运行。
5系统出错处理设计
5.1出错信息
系统中的各种提示如表5-1所示：
表5-1系统出错提示
故障或提示
系统提示信息
含义
处理方法
不能提交
不允许为空，请输入
必选项未填
重新输入
不能提交
不合法，请重新输入
输入数据格式不合法
重新输入
不能提交
数据项已经存在，请重新输入
所选数据记录在数据库中已经存在
重新输入
删除确认
是否确认删除
确认是否删除
根据需要选择
作废确认
是否确认作废
确认是否作废
根据需要选择
登陆失败
用户不存在或口令不正确，请重新输入
用户名或密码
重新返回登陆界面
数据库文件备份成功
数据库文件备份成功
成功备份数据库问价
无
数据库文件恢复成功
数据库文件恢复成功
成功恢复数据库文件
无
客户端连接不成
连接不成功，请检查网络连接
客户端不能连接上服务器端
检查网络状况
连接不上数据库
数据库连接失败
服务器连接不上数据库引擎
检查数据库连接字符串
借款请求
X条借款请求
科室上报客户端提交了借款请求
根据实际情况操作
直接报销请求
X条直接报销请求
科室上报客户端提交了直接申报请求
根据实际情况操作
偿还报销请求
X条偿还报销请求
科室上报客户端提交了偿还报销请求
根据实际请款操作
申请完成提示
你提交的请求X已经被X审核通过
上报请求通过审核
无
5.2补救措施
1）采用磁盘做备份准备，使用SQLServer2005的BackupServer（备份服务）对数据库数据进行备份，如果系统遭到破坏，用备份的数据进行还原，数据的备份和还原可以通过应用程序实现，也可以通过系统管理员直接使用SQLServer2005的BackupServer进行备份。
建议用户每天对数据库中的数据进行备份；
2）当系统运行效率过低时，通过重新启动可以重新组织数据库索引，提高系统运行效率。
3）在系统运行的过程中，可能会突发一些不可预测的故障，如断电、死机等。
为了提高系统的安全性，我们采用了基于挂接操作系统接口的服务器自身监控安全模型。
在本系统的服务器操作系统中，通过远程DLL注入技术，修改操作系统中进程的导入地址表，挂接Windows操作系统的关机函数，截获Windows的关机消息，从而实现在服务器每次系统关机时，自动检测当前是否有正在运行的财务业务，保证所有业务都已顺利结束，并自动备份一次数据库，再转回Windows操作系统的关机执行。
从而保障了系统服务器的业务稳定性，和数据完整性，提高了系统的安全性和稳定性。
5.3系统维护设计
系统采用了分层的结构进行设计，使系统各个部分分割开来，提高了系统灵活性和可扩展性。
系统在三层架构的基础上，增加了一层公共层，将系统中通用的部分抽取出来，以便于系统的维护。
在设计逻辑层时，我们采用了Façade模式，Facade模式基本框图如下：
图5-1Façade结构
其中小圆代表业务逻辑层中的小的功能，系统子模块通过“门面Facade”来
自己获取所需的功能，实现了“高内聚，低耦合”的设计要求。
在系统维护的过程中，我们可以通过测试各个层次之间的接口即可达到系统维护的要求。
升级会员 