通用软件研发项目实施方案

1、目录 1软件系统架构设计软件系统架构设计.5 1.1概要说明 .5 1.2系统特点 .5 1.2.1根据优化流程开发.5 1.2.2充分利用现有资源.5 1.2.3先进的设计理念.5 1.2.4开放式的可扩展性.5 1.2.5与现有系统轻松衔接.5 1.2.6可信赖的高可靠性.6 1.3总体体系架构.6 1.3.1基于组件的soa系统应用架构.6 1.3.2系统技术框架.7 1.3.3其他重要问题.9 1.4主平台解决方案.10 1.4.1基于工作流的业务流程管理.10 监控管理.12 工作项服务.12 日志服务.12 1.4.2业务规则管理.13 1

2、.4.3主平台和各子系统的接口.13 1.4.4多级基于角色的权限管理.13 1.5数据模型 .14 1.5.1数据建模原则.14 1.5.2数据建模方法.15 1.5.3数据质量管理.16 1.5.4数据存储方式.16 1.5.5其他重要问题.17 1.6用户界面 .17 1.6.1用户界面设计原则.17 1.6.2用户界面层设计技术.17 2概要设计说明概要设计说明.19 2.1概述 .19 2.2设计原则 .19 2.2.1统一设计原则.19 2.2.2先进性原则.19 2.2.3高可靠/高安全性原则.20 2.2.4标准化原则.20 2.2.5成熟性原则.20 2.2.6适用性原则.2

3、0 2.2.7可扩展性原则.20 2.3系统功能综述.20 2.3.1主控平台.20 2.3.2房屋图元信息.20 2.3.3房屋基础信息.21 2.3.4楼盘表.21 2.3.5房屋权属信息.21 2.3.6房屋地址库信息.21 2.3.7统计分析.21 2.4重点子系统解决方案.22 2.4.1xxx子系统解决方案.22 xxx 子系统架构图.22 xxx 子系统预受理组件业务流程图.22 3接口、部署及迁移实施方案接口、部署及迁移实施方案 .23 3.1接口方案 .23 3.2系统部署方案.23 3.3系统硬件部署方案.24 3.3.1硬件部署图.24 3.3

4、.2网络拓扑结构.24 数据库层.24 存储层.26 应用层.28 发布层.29 3.3.3内外网交换系统.30 3.3.4网络安全.32 3.4系统迁移实施方案.32 3.4.1数据迁移.33 数据迁移需求分析.33 迁移规则制定.33 数据资源规划和清理.33 数据迁移工具的选择.33 数据迁移试迁及完善.34 正式迁移.34 3.4.2系统切换及过度时间计划.34 风险分析.34 切换方案.35 4平台技术标准与规范平台技

5、术标准与规范.36 5应用系统培训方案应用系统培训方案 .36 5.1万里红有限公司的培训优势.36 5.2基础条件 .36 5.3培训对象及目标.36 5.4管理层培训 .37 5.5系统管理人员培训.37 5.6普通用户培训.38 5.7外地代理商培训.38 5.8约束条件 .39 5.9培训结果的评估.39 5.10培训方式 .39 6平台的建设建议平台的建设建议.40 7所需的第三方产品所需的第三方产品 .41 8项目开发和管理工具项目开发和管理工具.42 9软件生命周期各阶段的工艺、方法软件生命周期各阶段的工艺、方法.43 9.1项目启动阶段.43 9.2需求分析阶段.44 9.3系

6、统设计阶段.45 9.4系统实现阶段.46 9.5集成测试阶段.48 9.6系统测试阶段.48 9.7系统交付阶段.50 9.8系统维护阶段.50 10项目实施方法项目实施方法.51 10.1迭代式软件开发模式.51 10.2为什么要以迭代方式开发.51 10.3迭代式方法的优点.52 11项目实施各个阶段的进度计划、成果及交付物说明项目实施各个阶段的进度计划、成果及交付物说明.55 7)7)系统交付阶段系统交付阶段.58 12项目管理方案项目管理方案.60 12.1项目组织机构.60 12.1.1组织结构及组织图.60 12.1.2投入人力的职能及责任限度.60 12.2范围控制 .61 1

7、2.3进度控制 .62 12.4质量保证 .63 12.4.1qa经理.63 12.4.2qa工程师.64 12.5沟通管理 .65 12.5.1项目主管.65 12.5.2项目组.66 12.5.3qa工程师.66 12.6配置管理 .68 12.7文档范本 .68 12.8风险控制 .69 12.8.1项目风险.69 在出现不可修复的危害之前准备修复计划；在出现不可修复的危害之前准备修复计划；.69 12.9保密措施 .69 12.9.1公司保密制度.69 12.9.2项目保密制度.69 13技术支持与售后服务方案技术支持与售后服务方案.71 13.1技术支持与售后服务体系.71 13.1

8、.1技术支持与服务原则.71 13.1.2iso9001的服务规范.71 13.1.3服务工作流程.71 13.2技术支持与服务体系组织保障.72 13.3服务体系 .72 13.4技术支持与售后服务质量保障.73 13.5技术支持与售后服务内容.73 13.5.1售前技术服务.73 13.5.2售中技术服务.74 工程实施 .74 项目管理 .74 试运行阶段 .74 系统推广阶段 .74 技术文档 .74 技术咨询 .74 质保期 .75 13.5.3售后技术服务.75 13.5

9、.3.1技术支持热线、传真及邮件服务.75 技术支持网站 .75 实时技术支持 .75 对运行维护的现场技术支持和服务.75 故障响应及排除 .76 例行巡检 .76 系统更新升级 .76 系统性能评估与优化.77 后期技术培训 .77 0周期性现场技术支持总结.77 1资料定期传送/专题讨论.78 2系统咨询服务 .78 13.6技术支持与售后服务流程.78 13.6.1故障类.78 服务流程 .78

10、流程目的 .78 流程描述 .79 现场响应时间 .79 13.6.2技术咨询类.79 服务流程 .80 13.6.3意见建议类.80 服务流程 .80 13.7紧急情况响应服务.80 13.7.1紧急情况定义.80 13.7.2紧急情况分类.80 13.7.3紧急情况处理流程.80 1 1 软件系统架构设计软件系统架构设计 1.11.1 概要说明概要说明 系统架构主要包括应用架构和技术架构。系统采用基于组件的标准 soa 应用架构，以及按 照 soa 方法构建的基于 j2ee 标准的技术架构。 系统的应用架构采用

11、了基于服务的体系架构的策略与方法，从组件、子系统以及门户三个 层次对系统进行构建，组件组装形成子系统，子系统集成形成门户。门户为人员等提供一 个优化的以人为中心的操作界面，用户可以方便地对 xxx 的整个生命周期进行管理；同时 系统管理维护人员也可以方便地通过 portal 对系统进行监控和管理。 系统的技术架构同样也是基于 soa 方法和策略进行构建的，它支持客户端和服务器端同步 和异步的两种不同的通信方式，web 层和服务层进行相对分离，支持分布式和集中式部署 两种方案，并且不局限于某一种应用服务器和数据库服务器产品。 1.21.2 系统特点系统特点 1.2.1 根据优化流程开发 根据流程

12、特点进行功能设计，采用先进的工作流引擎机制。保证了业务功能的实现。 同时达到了灵活配置。松散耦合的目的。保证系统能够能够与原系统灵活切换。符合以 “xx生命周期为主线“的高效处理流程。使统一设计，灵活接口。 1.2.2 充分利用现有资源 充分考虑现有硬件分散、系统相对独立、数据库数据分离的现状。采用分布式部署， 统一数据规范、统一接口规范的设计思路，在保证系统功能灵活配置，满足业务需求的前 提下，充分利用现有数据及硬件资源。 1.2.3 先进的设计理念 采用国际通用的java语言开发，海量数据库选型、高效稳定的中间件处理。先进的soa 架构设计，满足现有的性能需求，做到架构和系统的先进性和强大

13、的扩展能力。采用先进 的web2.0技术，做到界面简洁、易用。 1.2.4 开放式的可扩展性 系统分部署式部署，子系统统一规划，即满足了分布应用的要求，又实现了统一标准。 形成了统一、强大的xxx工作平台。 1.2.5 与现有系统轻松衔接 设计时充分考虑现有系统现状，开发过程和现有系统数据、应用分析同步进行，保证 新系统与现有系统顺利衔接。 1.2.6 可信赖的高可靠性 考虑到实时运行，提供业务流程对可靠性的较高要求，在系统设计中充分考虑了减少 和避免故障的可能和隐患，配合合理的系统部署方式和高效的维护服务，能够满足需求中 对系统故障时间、修复时间和单点故障隐患的可靠性要求。 1.31.3 总

14、体体系架构总体体系架构 1.3.1 基于组件的 soa 系统应用架构 系统的应用架构是系统进行构建的主要思路和方法，我们建议 xxx 系统采用基于 组件的 soa 的系统应用架构对系统进行构建。系统按照 soa 的方法把系统从总体上划 分为 3 个层次，分为：组件层、系统层、集成层。 a)组件层：组件层主要包括系统开发需要用到得各种组件，又可以分为横向通用组 件、纵向通用组件和纵向专用组件。横向组件是大部分系统都需要用到的通用的 组件，如：web 组件、日志管理、数据校验、邮件管理、打印组件、报表组件、 文档管理、参数管理、单点登陆等，横向组件的作用是更好的管理和复用系统的 通用组件；纵向通用

15、组件包括在领域应用中通用的组件，如：工作流、报表工具、 规则引擎、用户权限管理等在领域应用中使用较为广泛；纵向专用组件是针对每 一个领域专用的具有领域特色的组件，在 xxx 系统中纵向专用组件可以分为申请、 受理、收费组件、分类组件、保密组件等等有关于 xxx 的组件； b)系统层：系统层包括了有组件组装得到的各个应用系统，又可以分为核心层、综 合业务层和辅助管理层。核心层是整个系统的重点和难点，是整个系统最重要的 组成部分，如 xxx 子系统是将申请人的申请进行接受和汇总子系统； c)门户平台：基于以人为本的原则，基于 portal 技术，对系统层各个子系统进行集 成。使用门户平台，用户不需

16、要登陆每一个子系统进行相应的工作，而是在统一 的门户平台进行工作。结合工作流技术，对于每个登陆系统的人都提供简洁统一 的工作选项，对于申请人、审核人、系统管理员、维护人员、局领导等都能做到 方便的操作系统，快速进行业务处理和系统管理。下图为基于 soa 的 xxx 系统的 应用架构总体设计图。 通用以上的阐述，可以看出，系统整体都是基于 soa 架构进行设计的，主要体现在如 下四个方面： a)系统基于 soa 的以服务为中心的思想和方法，对 xxx 系统的整体体系架构进行设 计，建立了分层的松耦合、跨平台的系统架构； b)在组件层，我们采用了基于 soa 的组件模型，它将应用程序的不同功能单元

17、（称 为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的 方式进行定义的，它应独立于实现服务的硬件平台、操作系统和编程语言。这使 得构建在各种各样的系统中的服务可以以一种统一的通用方式进行交互； c)系统采用了基于 soa 的分类集成方法对系统的业务以及服务进行分类和集成，做 成统一的接口，面向业务和服务编写，以适应 soa 系统的统一交互； d)将每一种业务构成都分解成不同的组件或者子系统，将组件和子系统分开编写达 到每项组件和子系统都能做到相互无关，如果一项组件和系统改变将对系统中的 其余组件没有任何影响。实现组件相互之间低耦合的机制，最大程序上降低了系 统的升级、业务

18、变更对系统的影响。 同时，基于 soa 的系统应用架构具有强大的系统的扩展性： a)soa 的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应 对企业商业服务变化、发展的需要，本方案很好地体现了 soa 的这一中心思想； b)工作流和业务规则引擎的采用极大了提高了系统对于业务流程和规则变化的适应 性。工作流引擎可以使得在业务流程发生变化时使得系统调整最小，而不需要向 传统的需要完全重新开发；业务规则引擎的采用使得业务规则发生变化时只需对 业务规则进行重新描述即可完成系统的转换。 c)组件模型、组件集成技术的采用使得系统在进行业务功能的调整时，可以把变化 局限于某一个范围之内，在

19、需要时还能进行灵活的替换。由于系统应用架构是根 据每一项业务或者流程编写所以对于系统的扩展非常方便，只要对新加入的业务 对应加入新的组件就可以实现对 soa 系统的扩展； 总之，本节提出的基于组件的 xxx 系统完全体现了 soa 的核心思想，通过分层组件规 划、集成、工作流引擎、业务规则引擎等方法和技术充分体现 soa 的策略与方法，并且很 好地实现系统的可扩展性、可移植性等等。 1.3.2 系统技术框架 xxx 系统基于 j2ee 规范实现，整个架构建立在 struts 框架、spring 框架和 dao 模式 基础之上，并提供了对于 ejb、web service、jms 等组件技术的集

20、成机制。技术框架逻辑 上可分为：客户层、web 层、业务层、持久层、资源层、核心层。如下图所示为系统的技 术框架。 客户层：客户端计算机的浏览器，用于展现页面。 web 层：web 层基于 struts mvc，完成转发请求、http 请求合法性校验、http 请求参 数与数据传输对象 dto 之间的绑定、http 请求参数有效性校验、用户操作权限检查、记录 用户访问日志、显示系统运行异常等任务。 业务层：业务层基于 spring 框架，完成业务数据校验、业务逻辑处理、事务管理、记 录业务处理日志、抛出业务处理异常等任务，同时它也支持 web service、jms、ejb 等组 件服务模型。

21、 持久层：持久层基于 dao 进行构建，完成数据读取、数据存储、封装 sql 异常、抛出 sql 异常、记录数据读写日志等任务。 资源层：资源层包括数据库服务器、xml 存储文件等，是数据永久存储的介质。 核心层：核心层表现为系统提供的基础类库，为 web 层、业务层和持久层提供支持。 包括日志记录组件、异常处理组件、事务处理组件、ioc 容器封装组件、web 层数据绑定 组件、web 层数据校验组件、权限检查组件、持久层辅助组件、其他开源项目类库组件等。 本技术框架的特色或优势主要体现在如下几个方面： （1）系统技术框架提供了对 soa 的完整支持； （2）对于同一个应用系统，系统同时支持集

22、中式和分布式两种部署方案，系统采用分 离 ui 层和 bl 层的方式来实现分布式的实现； （3）业务层 service 的实现可以有很多种，webservice、jms、ejb、spring 等都可以 作为对业务层的一种实现； （4）在系统的 web 层，同时支持同步和异步两种通信交互方式，使用了 ajax 技术完成 改善用户体验的任务，主要完成页面表单数据的录入校验、生成联动的下拉列表等任 务。客户端访问 web 层时通过 ajax 技术可以实现异步交互，在提交页面时系统采用同 步方式处理提交页面的内容。如下图所示为系统对于这两种交互方式的支持图。 客户层 客户机浏览器 web层 strut

23、sactionservlet actionbean 业务层 数据层 oracle db 业务service接口 / 业务servicewebservimpl实现 http po dwrservlet dto httpservletrequestdto strutsaction 数据库表dao接口 / daohibernateimpl实现 db2 （5）在系统中，每个功能模块都是相对独立的存在，在可扩展性上只要将新加入的组 件添加到系统中就可以实现系统的扩展，在系统中由于采用如：struts、ajax 等当前 最新的技术，恰当的使用，在性能上会有显著的提高，而且由于 struts、ajax 等技

24、术 已经相当的完善所以在可靠性上也有可靠的保障。 1.3.3 其他重要问题 （1）业务规则是支持企业决策，影响或控制企业业务行为的指示，它是企业处理业务 过程中始终要遵循的规则，而工作流则是根据业务规则制定的实际应用当中需要流转 的程序。 在系统的编制过程中将严格遵守业务规则和根据业务规则制定的工作流程，在系 统的编程中业务规则是一条语句，它定义或约束业务的某些方面。其目的是对业务结 构做出断言，或者对业务行为施加控制和影响。在 xxx 系统中，系统通过对工作流和 业务规则的使用，对 xxx 的生命周期进行管理，从 xxx 到 xxx 都有明确的程序遵循。 （2）系统采用标准的 soa 架构进

25、行设计，通过组件的开发、组件的组装、系统的集成 形成了基于 soa 进行设计的完整的 xxx 系统体系架构；在应用系统开发上，应用了基 于 j2ee 的标准技术，如 struts、ajax、hibernate 等标准技术和标准架构，开发时通 过制定严格的开发规范，并通过严格的项目管理和实施方法来规范程序员的编码规范， 提高系统的可维护性；在数据建模时也会采用基于标准的扩展的数据模型构建方法， 在数据交换、系统接口等领域也基于国家数据交换标准进行设计与开发；在系统的整 体设计开发实施维护过程，都将基于国际国内的主流标准进行。 （3）由于系统是根据标准架构和分层编写而成，对于想增加工作流程或者业务

26、规则的 情况，系统也可以很容易的进行扩展，如在系统中加入的新的业务规则只要在层次上 分清属于系统的哪一层次，在系统的层次中新加入组件就可以很方便和容易的对系统 进行扩展。 （4）在系统中，复用是减少代码量和代码可读性一个必须要考虑的问题。需要用到的 重复代码需要编写可复用的方法，对接口的定义需要考虑到相同功能中所有的问题编 写可复用的接口，公用的类也可以做到复用，对于收费子系统来说，该子系统就可以 达到的复用的功能。 1.41.4主平台解决主平台解决方案方案 主平台担负着整个系统运转的枢纽工作，主平台的设计必须在安全、稳定、高效的规 则下进行设计。主平台保证 xxx 系统具有统一用户、统一认证

27、、统一接口、统一资源、统 一管理、统一接入等特点，建立完善的主平台基础设施。 系统以业务流程为中心，通过工作流平台提供流程的自动化，集成各子系统；在实际 业务中还存在着大量的业务规则，他们是系统中的核心的知识和价值的一个体现，对于业 务规则的管理也显得非常必要；主平台还涉及到与其他 19 个子系统的接口交互，系统的接 口也是系统要研究和讨论的一个主要方面；系统涉及到大量的用户，他们具有不同的角色， 如果对系统角色进行权限管理，也是系统的一个重要方面。 因此，下文将重点针对业务流程管理、业务规则管理、系统接口和权限管理这四个部 分分别进行阐述。 1.4.1 基于工作流的业务流程管理 xx 流程复

28、杂，环节众多，各子系统在业务环节上环环相扣。如何不仅能保证业务流程 的准确流转，还能使系统具有很好的业务流程的灵活性。工作流是解决这方面问题的最佳 方案。 经过对业务的分析以及抽象，工作流管理系统围绕业务交互逻辑、业务处理逻辑以及 参与者三个问题进行解决，业务交互逻辑对应的为业务的流转过程，在工作流管理系统中 对应的提出了工作流引擎、工作流设计器、流程操作来解决业务交互逻辑的问题，业务处 理逻辑对应业务流转过程中的表单、文档等的处理，在工作流管理系统中对应的提出了表 单设计器、与表单的集成来解决业务处理逻辑的问题，参与者对应到的为流转过程中环节 对应的人或程序，在工作流管理系统中通过与应用程序

29、的集成来解决参与者的问题。工作 流管理系统为方便业务交互逻辑、业务处理逻辑以及参与者的修改，多数通过提供可视化 的流程设计器以及表单设计器来实现，为实现工作流管理系统的扩展性，多数提供了一系 列的 api。 完整的工作流管理系统通常由工作流引擎、工作流设计器、流程操作、工作流客户端 程序、流程监控、表单设计器、与表单的集成以及与应用程序的集成八个部分组成。下图 为图形化的工作流管理系统示意图： 工作流引擎作为工作流管理系统的核心部分，主要提供了对于工作流定义的解析以及 流程流转的支持。工作流定义文件描述了业务的交互逻辑，工作流引擎通过解析此工作流 定义文件按照业务的交互逻辑进行业务的流转，工作

30、流引擎通常通过参考某种模型来进行 设计，通过调度算法来进行流程的流转(流程的启动、终止、挂起、恢复等)，通过各种环 节调度算法(split、and、or 等)来实现对于环节的流转(环节的合并、分叉、选择、条件 性的选择等)。wfmc 是国际工作流管理联盟，它于 1993 年成立，发布了一系列的工作流定 义、软件接口的草案文本，是目前世界上公认的最具权威性的工作流标准制定机构，得到 了广泛的支持和应用。xxx 电子 xxx 系统流程管理将基于 wfmc-tc-1009，wfmc-tc-1013 等 设计标准设计，基于 xml 的流程化定义语言。 工作流包括一组活动及它们的相互顺序关系，还包括过程

31、及活动的启动和终止条件， 以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实 现和管理工作流运行的一套软件系统，它与工作流执行者（人、应用）交互，推进工作流 实例的执行，并监控工作流的运行状态。 工作流管理主要通过五个接口与工作流执行服务一起共同组成了工作流系统： a)工作流定义交换，用于在建模和定义工具与执行服务之间交换工作流定义。主要 是数据交换格式和 api。数据交换通过 xpdl，api 通过 wapi。 b)工作流客户端应用接口，用于工作流客户端应用访问工作流引擎和工作列表，通 过 wapi 完成。 c)被调用的应用接口，用于调用不同的应用系统。 d)工作

32、流系统互操作接口，用于不同工作流系统之间的互操作。 e)系统管理和监控，用于系统管理应用访问工作流执行服务。 xxx 系统根据工作流管理系统的设计，采用先进的工作流管理设计思想，将申请、分 类、初审、实审、复议、法律手续等子系统定义标准工作流应用接口，在主平台中对 xxx 流程进行统一管理，用户可以对 xxx 过程中的状态随时进行监控。 监控管理监控管理 监控管理使用浏览器作为用户界面，提供完善的用户管理、角色管理、过程管理、系 统设置、系统安全管理、配置文件管理和日志管理，让管理者可以追踪和控管角色、活动、 节点、过程实例的状态和过程实例流经的路径；可以以图形的方

33、式再现已经完成的过程实 例的路径、可以显示正在进行中的过程实例，并且提供管理的机制，让管理者得以在必要 时终止或暂停某些过程实例。同时，系统亦提供有关工作过程的统计数据和报表，动态改 变过程的状态，协调各个部分的关系，并进而提升管理的效率。可以大幅降低纸张文件的 需求以及传递文件所需的额外人力负担，通过浏览器和数据库把各种信息方便地展现给用 户,让内部信息的流动及传递更加迅速准确。负载平衡提高工作流的工作效率。 工作项服务工作项服务 动态产生其对应的待办工作项、提醒工作项、历史工作项、暂存工作项，为用户提供 以人为本的优秀的系统使用体验。 1.4.1.

34、3日志服务日志服务 运行服务对工作流实例执行过程中的各种事件及由事件引起的相应数据的改变进行完 整的记录，形成日志数据写入日志文件，以便对工作流实例的执行过程进行跟踪分析。日 志数据大至包括以下几类：过程定义、过程实例、活动定义、活动实例、工作流相关数据、 工作项、统计数据、结构信息、归档信息等。日志库中实际记录的数据种类由相应的配置 文件设置不同的级别来确定。 1.4.2 业务规则管理 在 xxx 系统中，不仅仅流程复杂，而且中间存在着大量的业务规则，这些规则决定了 系统流程的流转方向，决定了 xxx 的结果等等。通过业务规则引擎和工作流的结合的使用， 可以降低系统流程管理的复杂性，也便于用

35、户对企业业务规则资产的积累。 业务规则目前尚无工业标准定义，一个比较公认的定义是由业务规则组织(business rule group)给出的，从企业业务的角度来看， “业务规则是支持企业决策，影响或控制企 业业务行为的指示” ；从计算机信息系统的角度来看， “业务规则是一条语句，它定义或约 束业务的某些方面。其目的是对业务结构做出断言，或者对业务行为施加控制和影响。 ” 业务规则可以用来代表企业活动和事件起因、状态信息、活动限制(包括质量限制、一 致性限制、完整性限制等)、管理企业的政策和法规、及通过数据挖掘方式可以获得相应的 专家知识和建议。 业务规则有静态规则与动态规则之分，静态规则描述

36、了一致性与完整性规则，通常可 用数据模型来描述。而动态规则描述企业的动态行为，如活动的执行时机与条件等。每条 业务规则语句都应该满足原子性、确定性、简洁性、一致性和相关性。 业务规则引擎用于处理复杂的业务逻辑，它从业务流程中以单独实体的形式提取业务 规则，从而达到对系统的更好的分离，提高系统的可维护性。 在业务规则实现过程中，系统将集成满足 jsr 94 标准的业务规则引擎，如 ilog、drools 等。 1.4.3 主平台和各子系统的接口 主平台与各子系统接口可以将在系统接口方案中进行体现。 1.4.4 多级基于角色的权限管理 权限管理机制包括了组织架构管理，根据 xxx 局的下属机构分布

37、情况。系统次采用树 形机构管理模式，满足 xxx 局的需求，支持多级组织架构、多级项目管理 系统能灵活适应 于各种组织架构模式,能实现的分级的的权限管理模型。 权限管理机制采用基于角色的权限管理模型，灵活严格的授权模型和操作配置进行权 限设计。对于主控平台可以设置多个角色如：系统管理员、审查员、申请人、复审人员等。 角色及岗位的定制灵活、易操作，可以保证 xxx 的要求，还能满足今后业务流程的发展。 因此，建议在 xxx 系统中中采用多级的基于角色的权限管理。它把整个访问权限控制 过程分成两步：访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限 的逻辑分离，并且角色之间、用户之间

38、也存在多级关系。 该设计中，角色不能被继承，角色把一些功能集合起来，用户可以拥有某一个角色， 同时也可以直接将某个功能赋予该用户。权限控制主要体现在界面菜单、工具栏、查询信 息结果上。不同权限的用户登录系统后将会看到不同的菜单和工具栏，进入某一个功能界 面后，可以控制界面上的各个组件状态，有权限则该组件可用；不同级别的人员能看到的 xxx 信息、xxx 统计、分析的信息也不一样。 该设计的一个好处是，开发人员在增加新功能时才增加功能定义，增加功能定义实际 上是增加一个窗体的类名到数据库中，程序调用该功能实际上是创建该窗体的一个实例。 而拥有权限管理的最终用户可以自由设置界面（菜单项和工具栏的文

39、字显示，顺序，布局 等） ，开发人员仅维护功能定义部分。 1.51.5 数据模型数据模型 1.5.1 数据建模原则 （1）既继承又创新； 数据模型将会对原有系统中使用较成熟部分进行继承，一方面有利于提高系统成功几 率，另一方面也方便与数据的移植；在继承的基础上，对于原有系统中不成熟部分将针对 原有数据模型存在的问题进行重新设计。既继承又创新的数据模型设计原则，是数据模型 设计成功的保障。 （2）数据的完整性与一致性； 数据的完整性和一致性是原有系统数据库存在的主要问题之一，一个个分离的数据库 相对独立，和其他数据库不存在直接的完整性和一致性规则，本次开发将对原有系统数据 模型进行整合，一方面从

40、数据模型层面保证数据的完整性和一致性，另一方面消除原有数 据库的一个个信息孤岛，为查询、统计、分析等业务管理服务。 在系统建设数据建模时，需要对系统数据模型进行整体规划，我们将基于主平台数据 模型对数据模型进行整合，主平台数据模型从根本上保证数据的一致性，它规定了数据的 标准，其他子系统将使用这些数据标准。各个子系统建设过程中，形成了每一个部分的相 对独立完整的数据模型，整体上的规划从通用性数据模型、专用性数据模型、数据等各个 层次保证了数据的完整型和一致性。 数据的完整性和一致性首先是从数据模型的层面从根本上保证数据的完整性和一致性； 再通过建立长效的数据质量监控管理机制，自动监控管理与手工

41、干预相结合的方法可以解 决在实际系统中出现的数据质量问题。 （3）主要变化的适应性； 在系统建设时，将对业务进行充分的分析，对于可能存在的主要变化进行研究，在数 据模型设计时将充分考虑这些变化性，数据模型将能对这种变化性进行适应。 数据模型在设计时将采用纵向和横向两种结构进行设计，对于变化的适应性，可以采 用纵向字段语义扩展和横向结构两种方法来对变化性进行适应。 （4）数据模型的标准化； 数据建模过程中，采用标准的数据建模工具，遵循数据模型的建设标准，使用国际、 国家等数据标准，对于数据接口也采用标准的数据接口标准。这些标准的实施，一方面可 以提高系统数据模型建设的整体水平，另一方面也有利于

42、xxx 系统和国际接轨。 （5）支持数据的移植； 数据的移植也是新系统数据模型建设需要考虑的一个重要问题。一方面，我们将对原 有系统的成熟数据模型进行继承，以便于进行数据移植，另一方面，对于新数据模型，会 建立新旧数据模型之间的映射关系，并消除中间产生的冲突。 在移植时，为了可以准确高效的进行数据的移植，可以借助于第三方的数据移植工具。 实施时，将根据系统实际情况，进行分步的数据移植和系统的切换。 1.5.2 数据建模方法 结合多年的行业应用的开发经验，我们总结出了一系列的行业数据模型构建方法，行 业数据参考模型是建立行业数据模型的关键。所谓行业数据参考模型，可以认为是概念的 集合，以及概念的

43、关系，加上一些管理交互的规则。参考模型的最高抽象形式就是标准。 它基于概念模型的形式，反映该领域内的业务概念的组成和相互关系。它以特定领域为范 围，是构建特定领域软件体系架构（dssa）的基础，为领域应用实施开发提供重要支持。 下图为行业数据参考模型和业务数据模型及数据仓库模型之间的关系。 行业数据参考模型是行业内主要特征的描述，它排除了行业中企业的个性化特征的描 述，在进行系统建模时最主要的是理顺业务，建立行业数据参考模型。通过生成转换工具， 可以将行业数据参考模型自动转换为业务数据模型和数据仓库模型，然后可以在业务数据 模型、数据仓库模型的基础上进行个性化调整。 下图为 xxx 领域的数据

44、模型的体系架构图。 特定领域的数据参考模型的体系架构如图 1 所示，最下面的通用横向数据模型和特定 领域的术语和数据字典是构建特定领域数据参考模型的基础。在其基础上建立的特定领域 的数据模型包含领域横向数据模型和领域纵向数据模型，领域纵向数据模型又可以根据主 题划分为几个相对独立的领域主题。关于通用横向、领域横向、领域纵向数据实体的详细 说明如下： 通用横向实体是跨领域适用的数据模型实体，由键和属性组成。如以“人员和组织” 为主题的数据模型，它不仅仅能在特定领域内复用，还可以跨领域进行复用。领域横向实 体是指在领域内相对通用的数据模型，经常被领域纵向模型引用。领域纵向实体是指只在 某个特定领域

45、适用，不被领域横向数据模型引用，和其他领域纵向数据模型的关系往往也 是确定的。 对特定领域的数据建模来说，重点是要分析清楚在特定领域内数据模型中，哪些属性 是复用的关键，即哪些属性是对领域特征的抽象。我们对 er 图概念模型描述方法进行了扩 展， 引入“维度” 、 “维度层次” 、 “事实”三个数据仓库的概念，扩充了 er 图中的属性定 义，并在此基础上，对构建特定领域数据参考模型提供了一个方法，对原有设计方法中忽 略的概念的抽象过程进行了详细说明。 1.5.3 数据质量管理 在进行系统使用过程中，数据质量是一个至关重要的问题，它直接关系到系统的正常 运行，因此，对于数据质量也有必要进行严格的

46、监控和管理。 数据质量管理的方法主要是基于流程，利用数据之间的勾稽关系进行数据质量的检查 和纠错的。 从 xxx 流程看，从申请到收费、分类、初审、实审、复审、授权、失效等每一个环节 之间已经环节内部都可能存在数据的一致性问题，在制定数据质量管理方案的时候，将基 于 xxxxxx 的流程，对 xxx 中的各个环节之间的数据以及环节内部的数据进行一致性的监控。 1.5.4 数据存储方式 数据存储将采用关系型和 xml 方式结合进行数据存储。 1.5.5 其他重要问题 （1）数据移植； 下文将针对数据移植进行单独的详细地阐述。 （2）数据的完整性和一致性； 数据的完整性和一致性的保证主要通过如下途

47、径来实现的，首先是从数据模型的层 次从根本上保证数据的完整性和一致性；再通过建立长效的数据质量监控管理机制， 自动监控管理与手工干预相结合，解决在实际系统中出现的数据质量问题。 1.61.6 用户界面用户界面 1.6.1 用户界面设计原则 （1）系统的界面风格统一采用编制好的 css 文件，对单元格、按钮、下拉列表、文本 框都进行统一的规格化，页面布局采用左边菜单项右边功能页的页面布局。在内容填 充中，对每一录入项都进行数据合法化校验，如果出现异常和错误将采用统一的报错 页面和易懂的提示语言对异常或错误进行描述。 （2）对于用户操作来说，越容易、越简便越好，在系统的编制过程中我们将体现以人 为

48、本的友好操作页面，根据登陆人的不同，根据权限的不同对每个人的操作页面都能 做到定制，方便操作人的操作和管理。 （3）由于系统采用同步和异步两种方式进行数据的交互，异步操作可以使用户更加方 便的在页面操作过程中和数据库中的数据进行交互，同步操作可以使用户提交页面时 实时的对提交的内容进行查看和修改。 （4）系统提供在操作过程中根据输入项和功能来提示的功能来帮助用户更好的使用和 操作系统。 （1）系统的使用参考手册除了系统使用参考手册外还建立了 xxx 相关的知识库。知识库 中支持用户进行组织资料，用户查询相关只是和参考。如：知识库中如果存储了计 算机相关的 xxx 知识，在 xxx 的申请和审核

49、过程中操作人员可以通过查询知识库得 到相关的资料进行参考。 1.6.2 用户界面层设计技术 （2）在 web 页面中通过页面文本框组件、下拉列表组件、单选按钮组件、多选按钮组 件、按钮组件等组件对页面进行设计和实现。 （3）web 页面采用 http 同步技术实时对系统进行访问，也支持在页面中使用 ajax 技 术对系统进行异步的访问，得到页面和系统交互后得到的相关内容。 （4）使用 web 框架技术 struts 对页面进行加工和整合，使用户更方便的操作和使页面 程序可读性更高。 （5）在页面的设计和实现过程中，离不开其它框架的支持，如：spring 提供业务层的 操作支持，hibernat

50、e 提供数据库的操作支持，还有诸如 tiles、web service、jms 等技术的支持。 2 2 概要设计概要设计说明说明 2.12.1 概述概述 系统建设的总体目标是完成 xxx 的整个生命周期的管理，替代原有的以纸张推动 的 xxx 系统，提高 xxx 审查的效率和质量。 系统的总体方案主要包括系统的体系架构、数据模型、用户界面，以及系统的部 署方案、系统接口、数据移植方案、查询统计方案等。它从体系架构、数据模型、用 户界面等各个层次对 xxx 局 xxx 系统的开发和实施方案进行总体描述。 系统将采用基于 j2ee 的 b/s 架构进行开发，采用基于组件的 soa 架构方法和策略

51、来进行系统的层次体系架构的设计，采用基于 java 的面向对象的方法对组件与服务进 行构建。系统具有统一的简洁一致的用户操作界面，有很强的扩展性、重用性和很好 的性能。 系统具有很强的灵活性，在开发时，将通过使用工作流、业务规则引擎等提高系 统对于业务流程和业务规则变动的适应性；在架构上，采用 soa 架构和组件化技术来 应对系统的各种变化；在数据层面上，通过良好的数据模型设计来应对各种主要变化； 在实现中，通过各个层次的复用提高系统的开发效率和系统的灵活性。 系统建立在各种标准之上，架构标准、数据标准等，并将在实际开发过程中建立 统一的系统开发标准规范体系，从整体上提高系统的水平，便于与外部

52、机构进行接轨。 2.22.2 设计原则设计原则 2.2.1 统一设计原则 统筹规划和统一设计系统结构。尤其是应用系统建设结构、数据模型结构、数据存 储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。数据库和接口 涉及需要考虑相互的统一性，保证系统的接口与数据存储的一致性，保证系统的高性能 应用。 2.2.2 先进性原则 系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品 和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和 综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时 还要保证技术的稳定、安全性。

53、采用先进的系统架构，能够为将来的系统规划提供便利， 为今后的发展奠定基础。 2.2.3 高可靠/高安全性原则 系统设计和数据架构设计中充分考虑系统的安全和可靠。对于高性能要求平台系统来 说，必须保证系统得安全可靠。才能获得持久稳定的发展。 2.2.4 标准化原则 建立共同遵守 xxx 系统统一标准的数据系统，支持业务开展、横向的信息扩展和宏观 管理的要求，使本系统成为 xxx 局中数据提供的权威系统。系统对操作的标准化，即系统 有检入检出的机制，确保数据维护的一致性和版本控制的可操作性。系统对数据导入导出 采用统一标准接口，如采用现在最流行的 xml 标准。 2.2.5 成熟性原则 在开发工具

54、的选型阶段，应该尽量选择成熟的产品和规范，如 java 、xml、odbc、jdbc 之类已经成为标准的、被大量实践所采用的技术。选用具有成熟性， 可持续发展性的开发工具。系统要采用国际主流、成熟的体系架构来构建，实现跨平台的 应用。 2.2.6 适用性原则 保护已有资源，急用先行，在满足应用需求的前提下，尽量降低建设成本。目前现有 系统独立建立，数据库分散，但是数据库资源丰富，有大量的服务器。所以缩减成本，充 分利用现有系统是保证节约成本的重要部分。 2.2.7 可扩展性原则 xxx 系统设计要考虑到业务未来发展的需要，尽可能设计得简明，降低各功能模块耦 合度，并充分考虑兼容性。系统能够支持

55、对多种格式数据的存储。对于海量数据的存储， 系统的设计必须考虑高效和分离的部署结构，不仅保证能够轻松建立接口，而且能够提高 数据库的扩展能力。 2.32.3 系统功能综述系统功能综述 2.3.1 主控平台 1、主控平台担负着整套系统运转的基础工作，基本任务为对所有子系统的整合，包括 对系统及角色的安全管理、身份认证管理、实现单点登陆和统一权限管理。 2、功能结构如图： 2.3.2 房屋图元信息 搭建地理信息系统环境，将基础地理信息图层导入，建立房屋现状图层，建立房屋历 史图层。 对测绘数据进行汇总、整理，与房屋管理数据库中数据进行比对，记入房屋管理数据 库，生成楼盘表。比对成功数据反馈相关信息

56、系统。 2.3.3 房屋基础信息 房屋普查数据中的图元清册表 ，以幢为单元集合的房屋坐落、类别(平房/楼房)、 用途、结构、面积、土地性质、管理方式、初始登记产权信息、建设工程规划许可证、建 设信息（包括建设单位、竣工日期）等数据信息。 在数据导入过程中，根据图元编号与地理信息中的图元进行关联，以图元的编号作为 主键，导入信息。 2.3.4 楼盘表 普查数据中的详细清单表，是以幢为单元集合、以分产权（分部位）为单位的房 屋数据，包括房屋分产权（分部位）的部位、自然层数、面积、户型、朝向、权利人信息、 使用用途、使用人信息、销售情况、管理方式等数据信息。 在数据导入过程中，通过以下选择流程来完成

57、数据导入 编号楼楼盘表户信息 2.3.5 房屋权属信息 从房屋权属和交易系统中读取数据，对房屋的现权利人权属数据进行汇总、整理，与 房屋管理数据库中的房屋普查数据进行比对，记入房屋管理数据库。 2.3.6 房屋地址库信息 通过对房屋普查数据的处理，建立房屋地址库。实现地址信息与房屋图元的紧密关联， 实现一址一物、一物多址的对应关系。在 gis 中实现对地址库的近似度查询，同时创建地 址库实用工具，实现对批量数据的近似度查询。同时还要实现地址与图元的相互关联，查 询方式有条件查询，模糊查询，空间查属性，属性查空间。在地址库的建设中，随着地址 的变化引进地址库的更新机制。地址变化主要由错误的地址信

58、息、地址变化信息、地址废 止信息组成。错误地址信息要进行更正；地址变化和地址废止信息要将地址存放到数据库 中，将新地址存储到地址库中。新地址要与旧地址存在联系。 2.3.7 统计分析 不仅要对新生成的房屋管理图层的各属性字段生成统计图表，还要对普查中的各种调 查表的数据生成统计图表，尤其是对xx 省市国有土地房屋调查详细清单和房屋类型的 统计。 统计图表包括柱状图、饼状图、折线图等。生成的图要美观、简明。同时还要生成文 字本资料，图文并茂。 统计范围不仅是对某一幢楼，还有可能是某一区域，某一小区，某街道、某个区县， 甚至是全市的统计。生成的统计结果要快。 2.42.4 重点子系统解决方案重点子

59、系统解决方案 2.4.1 xxx 子系统解决方案 xxxxxx子系统架构图子系统架构图 xxxxxx子系统预受理组件业务流程图子系统预受理组件业务流程图 3 3 接口、部署接口、部署及迁移实施方案及迁移实施方案 3.13.1 接口方案接口方案 由于 xxx 系统分为一个主平台和 19 个子系统，申请人、局领导、代办处、一般用户都 会使用到该系统。因此，xxx 系统需要对外的接口，以及各个系统之间的接口。 如下图所示，对外的接口，采用 web service 方式进行实现，对外应用通过授权连入 内网，调用内网的 web service 进行

60、业务处理；内部接口部分主要采用两种方法进行： （1）建立接口数据库，专门用于进行数据交换和共享；（2）建立接口组件，通用 esb 供 其它子系统进行调用。 建议接口方案示意图 服 务 总 线 主平台 接口数据库 电子申请子系统受理子系统 实审子系统 web service 公开公告子系统 对外发布子系统 内网 外网 在 xxx 系统中，主平台起到了部分的接口数据库的功能，在使用时用助于提高系统数 据的完整性和一致性。 3.23.2 系统部署方案系统部署方案 每个子系统之间都可以分离部署，每个子系统都同时支持集中式部署和分布式部署， 但单个子系统建议进行集中式部署。如下图为建议部署示意图。 3.