《银行贷款有效发放系统概要设计说明书》是在《银行贷款有效发放系统需求规格说明书》的基础上，通过我方与用户方反复沟通形成的应用系统结构设计文档。该文档必须充分反映《软件需求规格说明书》中的用户需求，如有改动必须征得用户的认可。它将作为项目验收时重要的的标准和依据。

        从另一方面讲，《银行贷款有效发放系统概要设计说明书》是开发人员在下一阶段进行系统详细设计的纲领性文件，也是考核系统总体质量的重要技术文档。

        .1.2 预期读者

        银行相关领导；

        银行相关业务人员；

        银行开发和维护人员；

        软件有限公司的开发和维护人员。

        .2 编写背景

        .2.1 系统名称及版本号

        银行贷款有效发放系统V1.0

        .2.2 任务提出者银行

        .2.3 任务承接者及实施者

        软件有限公司事业部贷款有效发放项目组

        .2.4 使用者

        预期读者，也供有关领导审阅。

        .2.5 与其他系统的关系

        贷款有效发放管理系统，需要将目前基础数据库、信贷管理信息系统、工作流系统、核心业务系统等部分数据进行整合，并提供部分人工数据采集功能实现贷款信息的完整性，实现各有关业务部门之间的信息共享，避免信息的重复录入。各系统间关系如下图所示：

        说明：

        1. 综合计划局信息补录

        该功能依附与工作流系统，其功能在工作流系统中实现。用于提供核心业务系统中不包含的客户，项目，贷款等信息用于统计。 

        2. 核心业务系统

        提供已发放贷款的部分客户信息和部分贷款信息。 

        3. 工作流系统

        提供用户管理，角色管理，部分项目信息，部分贷款信息和部分客户信息等。 

        4. 信贷管理系统

        与信贷系统直接交互，每日信贷系统会从有效发放系统抽取新增客户、项目和合同信息，完成贷款有效发放系统与信贷系统的数据同步。

        5. KM报表提供各种统计报表的查询和展现功能。 

        注：基础数据库已被整合到核心业务系统中，对于核心业务系统中不能提供的信息，通过综合计划局统计信息补录功能补充。另外，贷款有效发放系统也提供对简单报表的查询和展现功能。

        .3 文档结构

        因为采用需求分析、设计、开发迭代的方法，所以本设计主要阐述系统的结构和实现方法。

        .4 定义说明与符号规定

        外部系统指有效发放系统外的服务系统。

        .5 参考资料

        《银行贷款有效发放系统需求规格说明书》

        2.1 系统目标

        通过建设银行贷款有效发放管理系统，来建立统一的贷款有效发放的指标体系、通过实现数据集中、数据挖掘和信息共享建立最终贷款规模的预测判断机制、建立贷款有效发放的滚动预测，最终实现贷款全程有效发放管理。

        2.2 设计原则

        为了能够保证项目的实施，我们应该遵循的设计原则： 

        1. 模块设计需要服从体系架构设计。

        2. 对于可复用模块，一定要进行抽取，以避免重复开发。 

        3. 质量管理应贯穿于整个设计之全过程。

        4. 对质量保证的承诺应落实到全体人员。

        5. 实际执行的过程中，必须符合项目自身的特点，体现个性差异，切实做到有的放矢。

        2.3 运行环境 

        2.3.1 硬件平台

        服务器

        Fire 880: 4 * 1.2GHz CPU, 8GB Memory, 6 * 73GB Disk    

        客户端

        机: CPU PIII 800 | 128M 内存 | 网卡

        .3.2 软件环境

        服务器

        操作系统：Sun MicroSystem Corp. Solaris 9 数据库：Oracle 9i  J2EE1.3

        9i Application Server CCCCCCEFF   

        客户端

        Windows 98/2000/XP Microsoft Internet Explorer 5.0及以上

        为保证有较好的页面显示效果，建议使用1024*768象素的屏幕分辨率。

        2.4 开发环境 

        2.4.1 网络体系结构

        下图用于描述运行环境中网络的体系结构图，贷款有效发放系统中包括应用服务器和数据库服务器两部分。总行或者分行用户使用客户端通过浏览器访问系统。

        客户端

        下图用于描述开发环境和测试环境中网络体系结构图，开发和测试由版本服务器作为分割，两个过程相互独立，开发机不可越过版本库将应用系统发布到应用服务器。

        开发过程是开发人员使用开发机从版本服务器中取得最新版本进行修改，测试通过后将代码提交到版本服务器。

        数据库发布过程是发布人员使用版本发布机通过版本库的管理工具为发布代码制定发布版本，从版本库中取得该版本下所有数据库脚本，并将数据库脚本更新到测试环境的数据库。

        应用发布过程是发布人员使用版本发布机通过版本库的管理工具为发布代码制定发布版本，从版本库中取得该版本下所有源码，在本地编译、打包后发布到应用服务器。

        2.4.2 硬件环境

        服务器

        Fire 880: 4 * 1.2GHz CPU, 8GB Memory, 6 * 73GB Disk   

        客户端机: CPU P4 1G | 512M 内存 | 网卡

        2.4.3 软件环境

        服务器

        操作系统：Sun MicroSystem Corp. Solaris 9 

        数据库：Oracle 9i  

        J2EE1.39i Application Server   

        客户端

        Windows 2000/XP Microsoft Internet Explorer 5.0及以上

        .5 系统结构概述

        （1）可维护性。

        系统采用树形的管理方法对系统中的各种指标体系进行统一化的管理，按照指标的用途、性质分为不同大类和等级。每项业务中涉及到的指标通过分解算法，得到便于维护和扩展的较小单位，通过定义指标的范围、编码、文字内容、单位等项目对指标进行标准化管理。

        本项目中将采用BI-Soft报表工具，该工具提供了功能强大的可视化报表设计工具，可以通过简单的托拉方法创建列组合报表、分组汇总报表、多维度分析报表等，另外，BI-Soft提供Java接口，具有再编程能力，满足本项目中出现的各种样式要求。

        报表中经常会出现1万以下、1万到2万、100万以上等指标体系，报表工具根据上述的标准化指标体系，进行数据的分类和筛选，随指标体系的改变而改变，减少管理人员对报表定义的直接维护。

        （2）可扩展性。

        本系统采用基于表现层、应用层、数据层分离的三层体系架构，基于FsFrame框架和Eclipse开发平台，以服务的方式进行业务逻辑设计，从而充分保障系统在各个层次上的可扩展性。 

        （4）灵活性。

        框架中提供了业务数据的封装机制，简化后台服务的编写过程，并且方便业务数据在各个业务模块间的转换。系统中的参数分为系统配置参数、业务编码参数，为系统提供灵活性的设置。

        （3）模块化。

        贷款有效发放系统在开发时应考虑系统的模块化，将系统中所涉及到的业务功能进行抽象和划分，减少不同功能之间的耦合关系；在FsFrame中提供了Action和Service的调用机制，由Action负责页面的调度，Service负责业务数据的操作，通过Action和Service的组合实现功能的组织，降低系统功能内部的关联关系。

        （4）适应性。

        本系统将采取参数化的设计方法，将系统中涉及到的判断条件、标准分类等进行参数化，并抽取到数据库中以方便维护和管理，在设计中我们将充分考虑银行信贷管理的需求，在指标体系中建立所有资产的共性指标和不同资产的特色指标分类，满足业务发展的需要。各业务服务逻辑之间通过标准化的接口进行交互，所有的接口格式都进行足够充分的分析论证，能够保证较长时间的稳定，当平台功能扩充后，应用系统不需要进行很大调整就可以充分利用平台的新增功能和处理能力。

        另外，系统中都将提供用户菜单的维护功能。允许系统管理员对功能的组织方式、授权角色等内容进行维护。 

        .6 逻辑体系结构

        根据上述设计思想贷款有效发放系统分布在三个层次上，分别是表示层、业务逻辑层和数据层。表示层负责和各种使用人员的接口，并处理画面之间的流程控制以及和业务逻辑处理层之间的接口，业务逻辑处理层负责业务的处理、业务流程的转换、和其他系统的交互，以及报表的生成等，业务逻辑处理层中包含应用平台和报表平台，用于完成对业务逻辑和报表的运行支持，数据层分为应用数据库和数据仓库，应用数据库主要负责业务数据的存取，数据仓库主要负责报表的展现。该设计采用MVC（Model－View－Controller）设计框架的体系结构，其中View这一层对应系统的表示层，Controller对应系统的界面逻辑控制和部分业务处理，主要通过Struts框架来实现，Model对应业务处理层的各业务模块，它是对业务数据模型的抽象，在系统中通过EJB、JavaBean和一些相关的类来实现。贷款有效发放系统的软件体系体系结构如下图所示：

        .6.1 表示层

        表示层是贷款有效发放系统的使用界面，贷款有效发放系统的各种使用人员都是通过表示层和贷款有效发放系统进行交互处理。

        贷款有效发放系统采用B/S结构，其表示层的展现是通过标准的浏览器（如Internet Explorer）来实现的，贷款有效发放业务的使用人员可以在任何时候、任何地方通过浏览器连接到贷款有效发放系统中，进行业务操作。

        2.6.2 业务逻辑层

        在这一个层次，贷款有效发放系统提供一个WEB服务器和一个Servlet/JSP引擎作为底层支撑系统，以Struts作为开发框架的应用平台，系统可以用流程图的方式可视化组织业务的处理逻辑，以及页面展现和业务处理的关系。业务处理层是贷款有效发放业务系统的核心层，所有的业务处理都在这一层实现，所有的业务流程和业务处理都在这一层控制。当一个交易请求到达的时候，业务控制模块首先得到控制权，然后业务控制模块通知业务处理组件来执行业务处理模块。

        业务逻辑层在贷款有效发放业务系统中起着承上启下的作用，对表示层来说，业务逻辑层控制着表示层的显示画面的切换流程、交易的执行，对后面的业务处理层来说，它是访问业务处理层的一个唯一途径。

        应用服务器提供了基本的、底层的和应用无关的系统组件，包括JDBC、JTA、JDBC、RMI、Servlet、JSP、JMS、JTS、XML、JMX等。业务组件库中对应了MVC框架中业务模型（Model）部分的实现。

        .7 物理体系结构

        贷款有效发放系统是一种总行大集中方式的B/S结构系统。所有的服务器总行的中心机房以便统一管理和维护，亦有助于应用系统的部署和升级维护。贷款有效发放系统需分别搭建数据库服务器、应用服务器、报表服务器和短信平台。这些服务器可以使用同一个物理主机，也可分别部署到不同的物理主机之上。其中：数据库服务器用于数据的访问和存取控制，及数据的备份，另外数据库服务器配置了磁盘阵列用于海量数据的存储和备份；报表服务器用于部署报表的运行平台，完成报表访问的支持；应用服务器业务系统的部署，并提供对系统的访问，短信平台用于系统消息发送以及时通知用户。服务器可采用集群方式以提供系统的性能。

        总行及分行用户无需按照客户端，可通过计算机及IE软件在内部的任何地方访问贷款有效发放系统进行业务操作，总分行通过内部网络屏蔽区域差异。

        物理结构图

        说明：各用户机配置要求请参考“2.3 运行环境”小节。

        .8 关键技术

        .8.1 面向对象分析设计

        当今，计算机产业正朝着分布式处理、并行处理、网络化和软件生产工程化发展，而面向对象的方法是作为实施这些目标的关键技术之一。本项目中使用用例分析、序列分析、状态分析对系统的业务功能进行分析，进而得到系统中的对象实体。

        状态机由状态组成，各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件。转移是两个状态之间的关系，它由某个事件触发，然后执行特定的操作或评估并导致特定的结束状态。

        在序列图中可以有对象和主角实例，以及说明它们如何交互的消息。序列图描述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对象如何通过相互发送消息进行通信。您可以为用例事件流的各种不同形式制作序列图。

        状态机用于对模型元素的动态行为进行建模，更具体地说，就是对系统行为中受事件驱动的方面进行建模。状态机专门用于定义依赖于状态的行为（即根据模型元素所处的状态而有所变化的行为）。其行为不会随着其元素状态发生变化的模型元素不需要用状态机来描述其行为（这些元素通常是主要负载管理数据的被动类）。

        在工程的分析阶段用例图被用来鉴别和划分系统功能，把系统分成动作者(actor)和用例动作者(actor)，表示系统用户能扮演的角色(role) 。这些用户可能是人可能是其他的计算机一些硬件，或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。用例描述了当动作者之一给系统特定的刺激时，系统的活动。

        .8.2 MVC设计模式

        模型-视图-控制器（Model-View-Controller，MVC）模式是一种拆分方法，它将应用程序拆分成三个部分：模型、视图和控制器。其中模型表示企业数据管理对该数据的访问和更新的业务规则。视图处理模型的内容。它通过模型访问企业数据，并指定应该如何表示该数据。在模型发生改变时，视图将负责在它的表示中保持一致性。这可以通过使用推（Push）模型（视图向该模型注册，以获取它的改变通知）来实现，也可以用拉（Pull）模型（此时视图负责在需要检索最新数据时调用模型）来实现。控制器将和视图之间的交互转换为由模型执行的操作。在独立的 GUI 客户机中，用户交互可能是按钮单击或菜单选择，然而在 Web 应用程序中，它们则可能是GET和POST方法发送HTTP请求。由模型执行的操作包括激活业务流程或改变模型状态。控制器根据用户交互和模型操作的结果选择合适的视图，从而作出响应。采用MVC 体系结构有以下优势：

        在贷款有效发放系统设计中，表现逻辑（即客户端）、业务逻辑（即业务处理层）、数据库访问设计是相互分离和独立的。一方面，它符合组件化的设计思想；另一方面，它便于各部分的模型化。特别是表现逻辑在不同客户端各具特色，但它们使用的业务和数据却可以是相同的。在业务调度模块和各个渠道之间传送的XML信息就是这些业务和数据信息的统一载体。反过来说，相同的业务和数据可以有不同的表现形式，从一定程度体现了系统的灵活性。

        多个视图使用同一个模型。模型和视图的分开使多个视图可以使用相同的企业模型。因此，企业应用程序的模型组件就更容易实现、测试和维护，因为所有对模型的访问都要经过这些组件。

        对客户机新类型更容易支持。要支持客户机的新类型，您只需为其编写一个视图和控制器，然后在已有的企业模型中将它们进行连接即可。

        2.8.3 应用系统运行框架

        .8.3.1 系统运行框架

        在普通的应用开发中系统功能多以函数的形式提供给程序员使用，这种方法形式简单可以满足应用开发中对算法和功能封装方面的需求。但是在解决分布式应用、多系统共存和功能升级时将暴露出明显的不足。建立系统功能框架的目的是在应用中用到系统功能的地方进行接口抽象，根据功能的特点以最优的方式提供给开发者，如传统的API方式、在父类过程中预先定义、通过框架自动调用等。系统功能将采取组件化和工厂的开发方式，便于不同的应用在同一个平台上共存，和系统升级。

        2.8.3.2 Struts框架

        框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。Struts采用了MVC Model 2，这是对MVC在Web上应用的修订版。图示如下：

        应用有3个主要部件：一个Servlet Controller（由Struts提供，org.apache.action.ActionServlet，以下简称controller）及负责具体业务处理的Action类（org.apache.action.Action的基类）；Jsp页面（viewer）；应用的业务逻辑封装（model）。

        Struts 的中心控制器（ActionServlet）接受所有来自客户端的请求，并根据系统的配置（Struts-config.xml）路由HTTP请求到其他Action对象（开发者实现的org.apache.struts.action.Action的子类），在这些Action对象中会进行所有的业务操作，比如插入一条订单，修改一条记录。处理完毕，由Struts的ActionServlet转向到JSP页面，将处理结果返回给客户端。从这儿可以看出在Struts中ActionServlet担任了重要的角色，由它控制所有的程序流转，是MVC三个相对独立的部分协调工作，提供系统的完善功能。从下图可见Struts是MVC Model 2的一个典型应用。

        .8.3.3 工厂模式（Factory Method）

        定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

        适用于以下情况：

        当一个类不知道它所必须创建的对象的类的时候。  当一个类希望由它的子类来指定它所创建的对象的时候。当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。本系统中，通过工厂的模式对所有的服务处理模块提供统一管理，根据服务请求的内容由工厂类对处理模块进行统一调度。

        .8.3.4 DAO模式

        使用数据访问对象(DAO)模式来抽象和封装所有对数据源的访问。DAO管理着与数据源的连接以便检索和存储数据。

        在本系统中DAO模式屏蔽了数据库的底层差异，根据数据对象中的数据生成数据库访问语句；提供数据库函数翻译和参数检查功能。用户可以针对不同的数据库启用相应的生成器，以增强应用程序在不同数据库间的移植能力。

        实现了用来操作数据源的访问机制。数据源可以是RDBMS,LDAP,File等。依赖于DAO的业务组件为其客户端使用DAO提供更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当底层数据源实现变化时，DAO向客户端提供的接口不会变化，所有该模式允许DAO调整到不同的存储模式，而不会影响其客户端或者业务组件。重要的是,DAO充当组件和数据源之间的适配器。

        .9 关键算法设计

        菜单设计

        系统菜单功能为应用系统与操作员的提供了一个交互的平台，系统菜单在设计上应该考虑为操作员提供简捷方便的操作模式，菜单项可以通过简单的配置即可完成系统菜单的维护和菜单权限的设定。系统在原有的三级菜单增加为四级，将业务模块的功能处理提到菜单的级别上，使得操作员在进入系统之后在菜单就可以明了该模块下提供的功能。设计菜单在数据库中的存储结构； 在系统菜单树表中加入相应的操作层数据；设计四级菜单的页面展现方式，要求在实现时不能隐藏菜单项；业务模块的查询列表页面根据菜单传过的不同操作标志来确定当用户点击链接时应完成的相应操作。

        在满足需要要求的情况下，可以使用数据库和客户端COOKIE分别实现该记忆功能。使用数据库作为记忆的媒介虽然可以完成本功能的要求，但是实现过程较为复杂，开发内容较多，不符合快速开发的要求；COOKIE是保存在客户端的可以实时访问的数据容器，由于所有的操作均在客户端进行，解除了客户端于服务器端的交互，提高数据访问的速度。综上所述，在本次功能选择COOKIE实现，实施过程可以大体总结如下：确定关键字记忆功能实现的方法；

        贷款有效发放系统的模块分布和菜单定义是按照模块的划分进行的，用户在使用贷款有效发放系统开展业务时，由于业务进行过程中各模块功能之间存在着相关性，用户需要在不同的模块中切换以完成业务作业，而且在不同的模块中需要重复的输入关键字做查询等操作。为了方便用户对系统的操作和业务的开展，在系统现有功能的基础上为不同的模块中添加关键字的记忆功能，使用该功能可以记录用户访问过的关键字记录，以便用户在不同模块中可以知道最近访问的关键字记录的列表，并且使用最后一次访问的记录作为默认值显示在页面中，以便于简化用户的操作、提高各个模块之间的相关性。

        根据实现方法对记忆功能进行详细设计和开发； 在各个模块中应用记忆功能。

        数据库设计 

        3.1 数据组织形式

        由于银行现有的系统中存在多个与信贷管理相关的系统，如工作流系统，信贷系统等，信贷数据在多个系统中存在信息重叠的问题。依据总行的系统建设规划，遵循各系统间应尽量避免业务信息重复录入，加强各系统间业务数据共享的原则，在贷款有效发放系统中对相关的信贷业务数据进行重新组织和规划。

        .1.1 数据分布方式

        工作流系统是开发银行当前作为核心业务系统贷款业务信息收集和审批的前端系统，其主要对合同签订后客户开立、项目开立、贷款开立、贷款发放、贷款回收、资金支付等业务信息管理提供审批流程。

        贷款有效发放系统是贷款全程管理系统，主要提供对项目储备上报、审批，评审计划上报、审批，贷款各项滚动预测，综合计划局下达按季分月指导计划和下达人民币中长期项目贷款计划的业务操作和统计报表等技术支持。

        信贷管理系统是开发银行早期的信贷业务管理系统，其主要对合同签订后贷款相关信息的管理，有效发放系统将取代信贷管理系统在合同签订后贷款相关数据的管理功能。

        .1.2 数据特点分析

        工作流系统贷款信息在通常情况下与贷款有效发放系统中合同信息属于相同信息。因此为了减少操作人员在工作流系统贷款开立中工作量，当进行贷款开立时，工作流系统自动抽取有效发放系统对应合同信息。

        为减少操作人员的信息录入量，贷款有效发放系统与工作流系统中的客户信息之间进行共享，在工作流系统中的客户开立时，自动抽取有效发放系统已经录入的信息，然后补充核心系统特定信息，以避免客户信息的重复录入工作。

        为了保证统一的权限管理，工作流和有效发放使用统一的机构、用户、角色视图。这些数据目前保存在工作流的数据库中，操作员的用户申请，角色申请等由工作流系统统一管理。

        为信贷系统从有效发放系统读取新客户、新项目以及新签合同的信息提供接口，减少客户、项目和合同等信息在两系统间的数据冗余，避免信息重复录入。

        其他与本系统相关的管理表，如菜单定义、服务定义及角色设置因为与具体系统相关，因此保存在本系统。

        .1.3 数据传输与通讯

        在数据层中建立相关数据源的访问关系。

        .1.4 历史数据管理

        历史数据包括各分行填报的Excel文件，数据库中的历史状态数据。数据文件可采用按照不同项目所处阶段和不同时间的方式进行组织，分批次将分行填报数据导入到数据中，另外，对于相关的其他系统数据，需要分析数据源的数据质量和可移植性，组织历史数据移植工作，将历史数据导入到系统中。

        .2 命名规则

        数据库中的表根据系统所涉及的模块进行划分，采取前缀 表名的命名方法，前缀用于标识该表所属的模块。数据库表中字段名的命名方法，前缀小写，多个前缀根据需要可以组合，表名采用英文单词和缩写，当单词长度超过4个字母时缩写为4个字母，每个单词首字母大写。 

        3.3 数据库概念模型设计

        4.1 基本原则

        在概要设计阶段，根据需求阶段的调研结果，系统界面设计的基本原则进行整理。为保证系统界面在代码开发过程中保持统一样式和风格，因此必须遵循以下原则和规范： 一般适用原则简单明了原则：用户的操作要尽可能以最直接最形象最易于理解的方式呈现在用户面前。对操作接口，直接点击高于右键操作，文字表示高于图标示意，尽可能的符合用户对类似系统的识别习惯。

        提供高级自定义功能：为熟悉计算机及软件系统的高级用户设置自定义功能，可以对已经确定的常规操作以及系统的方方面面进行符合自身习惯的自定义设置。包括常规操作、界面排版、界面样式等种种自定义。

        用户导向原则：为了方便用户尽快熟悉系统，简化操作，应该尽可能的提供向导性质的操作流程。

        实时帮助原则：用户需要能随时响应问题的用户帮助。

        方便使用原则：符合用户习惯为方便使用的第一原则。其它还包括，实现目标功能的最少操作数原则，鼠标最短距离移动原则等。

        界面平面版式要求：系统样式排版整齐划一，尽可能划分不同的功能区域于固定位置，方便用户导航使用；排版不宜过于密集，避免产生疲劳感。 B/S构架适用原则

        用户自适应定义：提供较多的可订制功能，尤其对桌面面板提供强大的定制功能；使用户能够将最常用的功能定义到桌面面板，每次登录即可直接使用，简化用户操作。

        页面最小：由于Web的网络特性，尽可能减小单页面加载量，降低图片文件大小和数量，加快加载速度，方便用户体验。

        界面色彩要求：计算机屏幕的发光成像和普通视觉成像有很大的不同，应该注意这种差别作出恰当的色彩搭配。对于需用户长时间使用的系统，应当使用户在较长时间使用后不至于过于感到视觉疲劳为宜。例如轻松的淡彩为主配色，灰色系为主配色等等。切忌色彩过多，花哨艳丽，严重妨碍用户视觉交互。

        屏幕适应：Web界面需要适应不同用户屏幕大小。

        最少垂直滚动：尽可能减少垂直方向滚动，尽可能不超过两屏。

        瘦客户端要求：由于客户应用环境配置大多较低，除服务器可单独配置较灵活外，应该保证瘦客户端，使用户容易使用。例如尽量不要使用复杂的JS脚本和HTC组件，不要在客户端使用IE整合XML/XSLT等等。

        禁止水平滚动：由于将导致非常恶劣的客户体验，尽可能禁止浏览器水平滚动操作。

        避免隐藏（右键）操作：浏览器的右键操作不符合用户体验习惯，尽可能避免。  

        桌面面板导航简化操作：为了实现方便简捷的用户操作，应该保证用户绝大多数操作可通过首页桌面面板的导航来实现。

        浏览器兼容：需要适应不同浏览器浏览效果，虽然目前可不考虑不同浏览器差别，但仍需考虑IE浏览器版本差异带来的客户端不同效果。

        用户常用操作记录定义：对某些需定义操作的功能如查询、搜索等，提供系统自动记忆和客户定制功能，系统可自动记忆用户前1~3次操作，或者用户可自定义操作记录，方便以后使用。

        大数据量表格的水平扩展要求：本系统中存在大数据量的列表，需要较大的交互界面支持，为避免水平滚动，应尽可能获取大的屏幕水平空间。

        .2 页面区域化分

        工具栏区用于显示登录的操作员的信息，系统消息、草稿箱、退出等功能，方便操作员的使用；工作区用于显示具体功能的查询和维护页面；

        系统的展现部分共划分为导航区、菜单区、工具栏、和工作区四部分。其中：导航区用于显示系统的名称，系统中模块和功能的划分情况； 菜单区用于显示系统功能中的相关操作；

        页面采用表格的方式进行分割，以便于页面尺寸的自动调整和整体背景设置。正文是包括功能条的区域。

        .3 示例说明

        5 功能设计 

        5.1 基本原则

        在概要设计阶段，根据项目开发经验对开发的基本原则进行整理。为保证代码开发过程中保持良好的可阅读性和统一样式和风格，因此必须遵循以下原则和规范：

        5）尽可能细致地加上注释，并用javadoc注释文档语法生成自己的程序文档。 

        1）需要认真遵守《Java代码开发规范》所规定的所有内容； 

        2）在开发过程中需要注意不要破坏事务的完整性；

        4）开发中应用具有不同级别的日志，方便调试和查错；

        3）应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。 

        6）良好的设计能带来最大的回报。