软件系统通用技术方案及实施方案（技术方案）

软件系统通用技术方案软件系统通用技术方案及实施方案1 10 2.数据库设计 2.1数据库设计原则 2.2数据库逻辑架构设计 2.3数据库逻辑模型设计 2.4主题域模型设计 4.逻辑模型设计 5.数据应用流程 26 1.1设计目标 261.2设计思路 261.3设计原则 271.4平台整体架构 30 2.2需求分析 322.3研发策划 332.4设计与编码实现 34 352.5系统测试 352.6总结验收 38 2 39 3.3业务组件与表示层 423.4我司通用企业运维应用平台 3.5通用企业应用平台的结构 443.6通用企业运维应用平台的特点 503.7基于通用企业平台的运维服务 3.8核心经办业务技术架构概述 583.9核心经办业务技术架构设计 603.10技术架构中各层对象在创建过程中的依赖关系 64 664.2研究管理流程 67 4.2.2需求分析 68 三、系统测试方案 71 712.压力测试报告 72 722.2压力测试流程 90 3.2服务器系统环境变量配置 1393.3服务器安装过程说明 1403.4客户端访问方式 147四、项目管理方案 148 3 5.2组织基本制度 5.3组织架构 5.5激励系统 6.1有效的管理原则 6.4加强项目开发的管理 6.5实行时效工作制 6.7加强员工培训 7.1管理机构职责 7.2人员岗位职责 8.内部培训 8.1员工培训计划 8.2服务质量的监控考核 8.3员工的奖惩条例 8.4人员配置原则 1.2阶段工作及成果 1.3.4沟通承诺 1.3.7管理项目的风险 200 200 200 20041.3.11记录估算并且使用估算工具 2011.3.12遵守学习曲线 2011.3.13考虑意外缓冲 2011.3.14录实际情况与估算情况 1.3.15只有当任务100%完成时，才认为该任务完成 2021.3.16公开、公正地跟踪项目状态 1.4质量控制、质量保证方案 2031.4.1项目质量管理的关键 2031.4.2本项目质量保证措施 1.4.3IT项目质量管理的目标和质量控制 2061.5项目验收方案 2081.5.1验收目的 2081.5.2验收对象 2081.5.3项目验收的前提条件 2081.5.4验收方法 2091.5.5验收步骤 2101.5.6验收程序 2111.5.7验收依据 1.5.8验收内容和标准 213 1.5.10项目交接 2152.测试方案 2.1测试内容设计 2162.1.1系统功能测试 2.1.2系统性能测试 2.1.3系统安全性测试 2.1.4易用性测试 2.1.5接口测试 2212.1.6可扩展性测试 2.1.7兼容性测试 2.1.8用户文档检查 2222.2测试阶段规划 2.2.1单元测试 2.2.2软硬件联调测试 2.2.3集成测试 2.2.4系统测试 2.2.5验收测试 22652.3测试工作流程 2.3.1各过程测试整体流程 2272.3.2测试方案 2.3.3测试计划 2302.3.4测试准备 2322.3.5测试执行 2332.3.6测试报告 2.4测试结果评价与测试工具 2352.4.1测试用例设计 2.4.2测试结果评估准则 2362.4.3测试输出成果 2.4.4测试人员名单 3.项目风险管理 3.1风险管理过程 3.1.1风险管理计划 3.1.2项目风险的跟踪 3.2项目风脸管理计划 3.3本项目风险和对策 4.项目沟通管理 2484.1项目实施各方职贵 4.2需要用户和原承建商配合的建议 4.2.1项目管理方面 2524.2.2软件研发阶段 2524.2.3培训组织工作 4.2.4项目验收阶段 2534.3客户交互的安排 5.质量保证方案 2545.1项目质量方针 2545.2项目质量目标 5.3质量保证承诺 2555.4项目质量范围和标准 5.4.1质量范围 2565.4.2质量标准 2575.4.3质量管理 5.4.4质量保证的基本思想 5.4.5软件研发过程中主要的工作活动 2615.4.6质量过程管理 2626 265 270 2701.1培训部门 1.2培训要点说明 271 274 275 276 278 282 2851.2.8平台工程师培训计划 2.软件操作手册 2903.系统运维手册 2923.1运行详细手册 351 3514.2项目试运行计划 5.系统变更记录 361 3615.2系统变更制度 6.验收报告 3666.1验收报告格式 368 3757.1参与人 375 7.3会议主题 7.4沟通时间 7.5会议决策 7.6遗留问题信息记录 1.售后服务承诺 3762.人员培训方案 37972.1培训目标及理念 3812.2.1实施过程中的培训 3812.2.2阶段性统一培训 3812.2.3其它培训方式 3812.2.4培训考核 3812.2.5培训讲师介绍 382 3822.3.1系统管理维护人员 3832.3.2卡务中心操作人员 3832.3.3终端操作人员 2.3.4各个子系统的管理人员 3842.3.5各个子系统的操作人员 3842.3.6第三方接入研究人员 3.软件平台故障支撑计划 385 3873.2.1咨询服务 3873.2.2应用系统的故障响应 3.2.3应用系统辅助操作 3.2.4应用系统的维护服务 3883.2.6应用系统业务调整 3.2.7应用系统软件升级 3.2.8支持机构 3883.2.9咨询服务组 3883.2.10咨询服务专家组 3893.2.12远程登录诊断维护 4.软件维护方案 3904.1远程支持服务流程 3904.2现场服务流程 392 3954.4客户服务质量文件 3965.应急维护方案 5.1应急预案目标 3995.2应急预案具体措施 85.3应急处理流程 6.集成服务方案 4016.1集成服务目标 6.2岗位分工和职责 4056.3维护作业制度 4066.4系统安全制度 4076.5故障处理制度 4086.6技术档案和原始记录的管理制度 4097.现场服务方案 4127.1现场组织管理策略 4127.2项目管理组织体系 4147.3项目组织各角色的职责 4157.3.1项目领导小组 7.3.2项目指导小组 7.3.3运维总负责人 7.3.4总协调人 7.3.5项目管理组 7.3.6现场负责人 4187.3.7项目软件经理 7.4现场维护管理 7.5项目管理监控 7.5.1阶段评估 7.5.2迭代评估 4277.6资源监控 4277.6.1人员策划 7.6.2人员变更 429 4311.疫情期间应急预案 2.疫情防控教育、宣传方案 4323.疫情时期车辆管理方案 4354.物资储备、使用计划及落实措施 4365.疫情防控检查方案 4386.防护用品发放标准 4417.正确使用口罩防护的方法 4428.正确的洗手方法 4459一、数据库管理方案1.1、总体规划，建立科学、完整的信息资源管理体系整体规划，将以往分散的数据资源进行整合，建立科学、完整的信息资源体系结构，确保业务人员、技术开发人员等使用和维护信息资源的用户从整体上把握数据资源的情况，方便、准确的利用信息资源和有效的维护、管理信息资源。科学、完整的信息资源管控体系不但包括信息资源自身的完整性，科学性，也应包括信息采集、管理、共享、利用方式的规划，以及数据模型、数据指标等规范化、标准化的考虑。1.2、统一规划、集中管理各类信息资源统一规划数据资源，不只是要对各类信息资源进行物理集中存储管统一制定业务数据指标体系，以管理服务对象为核心，组织相关联的业务数据，实现对内业务使用、对外服务应用的统一视图。设计集中、统一的数据库服务系统，实现信息资源的集中存储、集中处理、集中管理、集中服务，并保障数据的一致性，降低数据交换、系统内共享使用复杂性。1.3、按照业务需要规划主题数据以面向管理服务对象的业务主题设计为核心，依据管理的业务管理范围和业务管理要点，建立面向管理服务对象、面向业务管理、面向公共服务、面向决策支持等的多个主题数据库，并以面向管理服务对象的主题数据库为核心来建设。1.4、通过数据集成和数据交换实现数据共享利用数据资源的共享是数据资源体系设计的主要目标之一。对内，通过数据集成实现数据共享；对外，通过数据交换实现数据共享。分析系统内、外的数据共享、交换需求，规划统一数据共享、交换数据区域，提供标设计数据管理服务中心应用系统，统一规划数据的获取、操作、展现、管理、服务等处理。同时解决数据综合利用问题，以及数据深加工利用。支持业务宏观、微观决策分析。1.6、数据模型设计具有较高的可扩展性随着业务不断发展和数据应用的不断深入，必然要产生新的业务指标和新的系统数据。数据模型(包括概念模型、系统数据模型)的设计要保证能适应这种变化，在指标体系变化时或业务内容增加时，尽可能不用修改各类数据表的结构。数据标准化是数据共享、数据利用和保障数据质量的前提或基础。数据指标设计遵循国家、总局相关标准，确保数据的规范化、标准化。数据标准化问题包括方方面面的工作，除了指标、数据元、数据库结构等数据本身的标准化外，还有交换数据的标准、元数据标准等内容。为了支持各类工作的开展，适应未来的业务变革，应建立全面的、多层次的数据标准2.1数据库设计原则由于数据库是对项目所有业务条线和所有数据的集合，投标方对采购方现有业务系统、所有数据将进行深入的了解和分析。结合现有数据库建设的优点和长处，深入了解，加强分析，结合现有系统的数据结构，设计符合采购方现状，并有足够扩展性，可满足采购方业务扩展要求和其他委办局交换数据要求，高数据质量的、优异的数据库。数据库设计和建设将整体性按照管理业务一体化的建设要求，数据模型设计应兼顾各业务条线之间的数据结构的整体性，投标方将按照EDM(企业级数据模型)的方法，建设业务企业级概念模型和逻辑模型。数据库的存储数据内容包括结果数据、过程数据和整理后的主题数数据库设计以业务为核心，建立涵盖行业业务为主，包括项目所有数据，和项目基本信息的数据库。数据库的数据内容覆盖项目所有的数据及与其他委办局、总局交换所得的数据。数据库的设计和建设，并面向项目各业务条线数据的关联、各种查询和交换等应用；独立性与可扩展性数据库中的结果数据库结构的设计基于业务工作内容的基本属性设计，独立于具体业务办理流程，以适应将来的业务变动；数据库中的办理过程数据库结构的设计将兼容相应办理流程的架构，同时具备足够的可扩展性，能涵盖目前及未来的业务办理模式；数据库中的主题数据库结构要根据数据分析、挖掘的需要，符合采购方现有业务条线，且独立于具体业务的办理流程。数据库的设计和建设要满足扩展需求。数据库设计应具备较强的可扩展性和预见能力，以适应管理业务变化。当业务发生变化时，数据库数据应不做变化或少变化。标准化、规范化数据库的设计和建设要遵循数据标准和国家相关数据标准，以及市采购方已建的各项业务规范。数据库的设计和建设，将充分考虑数据字段的业务来源、数据类型、取值范围、遵循标准等，并将相关字段建立数据关联关系。对于数据库的设计和建设，需考虑对业务系统库表设计的指导需求，数据库的数据库表设计应为业务系统的建设提供参考和借鉴作用。根据采购方建设规划要求，基于统一的数据标准，建设以业务数据为基础，以数据共享为主线，以提高数据资源价值为目标，涵盖数据采集、数据治理、数据利用等各方面的，全市大集中的市数据库，并使其成为采购方数据的存储中心、管理中心、交换中心和服务中心。2.3数据库逻辑模型设计第视频2、决策支持数据决策支持数据是按照面向分析主题，对业务数据进行二次加工形成的面向管理和决策服务的数据。决策支持数据可以分为两大类，一类是按照管理服务对象为核心重新组织的业务主体数据，例如业务主体数据、广告数据、合同数据等；另一类是汇总统计、分析挖掘后形成的数据，主要是对报表汇总、数据综合利用、信息挖掘后形成的结果信息的记录。共享交换数据主要是实现内各系统之间，以及与外系统之间的数据交换与共享。共享交换数据主要包括广东省工商局、质监局、知识产权局交换数据、内部交换数据、业务机构交换数据(各级智慧系统与同级部门的交换数据)、公共服务数据等。4、基础规范数据基础规范数据用于对整个系统基础的信息资源进行约束。基础规范数据主要包括资源目录体系、标准代码数据、数据字典等。系统管理类数据是一种公共的、基础的环境数据，一数据，如系统环境参数信息、系统运行状态信息等描述系统运行环境的数据，以及机构、用户、权限、日志等描述业务运行基础和环境的数据。元数据是描述数据及其环境的数据，主要包括各类系统使用的共享元数据和各类系统自主元数据。主题数据库是经科学规划，面向业务主题的数据组织存储形式。主题库的结构设计与应用处理过程相分离，能有效实现数据的关联和共享，降低大型信息系统的开发和维护成本。系统设计中一般有三类主题组织形式：面向业务管理的数据主题按照业务领域建立业务主题。面向管理服务对象的数据主题按照管理服务对象来组织相关数。决策分析主题按照决策分析需求组织数据，例如：辖区经济秩序评价主题、企业信用分类主题、人员绩效考核主题。信息系统设计基本采用面向对象的信息工程方法，数据分析与规划也与此相适应，以面向管理服务对象的业务主题设计为核心，开展主题库模主题数据库模型分为概念模型和逻辑模型。主题数据库模型设计将管理业务数据主题分为三类，共23个业务主题管理服务对象主题是以管理的主要管理服务对象为核心，把该对象的状态和管理信息集中起来，能方便直观的掌握管理服务对象的信息全貌，有利于信息共享应用。公共业务实体主题是将业务处理过程中的公共信息实体进行整合，有效的促进业务的整体规范化和业务联动。其它业务管理主题是指现阶段没有完全抽象成管理服务对象和公共业务实体主题的其它业务管理主题。保留部分业务管理主题，一方面是由于存在部分业务是以管理过程为核心或者还不太稳定，不便于也没有必要完全以对象为核心来组织数据主题，另一方面也是为了突出重点，更好的完成管理核心业务对象的设计。被保留的业务管理主题在主题细分和应用设计时仍然可采用面向对象的设计方法。概念数据模型反映用户综合性信息需求，一般采用主题库名称及其内容(简单数据项或复合数据项)的列表来表达。主题库逻辑模型设计是从系统分析人员的视角，对概念数据模型的进一步分解和细化，一个逻辑主题库由一组规范化的基本表构成。基本表是按规范化的理论和方法建立起来的数据结构，一般要考虑达到第三范式的在信息化总规阶段，本设计报告只对主题库逻辑模型进行初步设计，不具体设计描述数据项，采用“简化E-R图”的方式，用长方框代表“基本表”,用向后缩进排列代表“下一级”基本表。基本表和下级基本表的对应关系一般为“一对多”,省略关系联线。对不同主题中基本表之间的关系和联系，本设计采用虚线长方框加关联说明的描述方式。主要有两种表现形式。表现形式一：基本表加向后缩进一级的虚框关联表。例如：地址网格信息(关联到网格主题)说明企业基本信息表与网格主题中地理网格信息表是存在关联关系的(即企业基本信息表中存在地理网格ID这一外键字段),通过关联来说明企业所在地的地址网格信息。表现形式二：基本表注明“XX基本信息”随后紧跟同级的虚框关联表“XX信息”。说明本主题需要记录部分业务信息，但更多详细信息可以到相关主题中去查询。例如：信息件基本信息涉及主体基本信息涉及主体信息(关联到航船主体相关信说明信息件主题中存在“涉及主体基本信息”表，涉及主体的详细信息可以关联到业务主体主题中去继续查询。出现这种情况表明两个主题存在一定的数据冗余，但这也是正常业务的特性造成的，即信息件涉及的主体可能不是本地注册的业务主体，甚至可能是未注册的主体，实际信息处理时只能先到主体信息表中查询，如果找到则自动关联引用，如果找不到数据应用的总体流程如下所示：0-根据应用需要，以及数据库的规划，将数据应用分为操作型数据处理、分析型数据处理。操作型数据处理主要是针对OLTP类型的应用提供数据服务，主要是向业务信息综合应用系统中的核心业务类应用。分析型数据处理主要是针对OLAP类型的应用提供数据服务，主要是向数据中心系统、管理决策支持系统，如数据ETL过程、数据加工、数据统计分析、数据挖掘等提供数据处理服务。1、一体化业务数据库从整体上看，操作型数据处理是数据资源的基本生产单元，综合信息化管理系统生成并使用各类业务数据。操作型数据一方面来自于各业务应用系统业务办理过程的产出，另一方面来源于经数据共享交换自相关系统传递过来的外部数据。以主体登记为例，业务办理过程产出的申请案数据，属于操作型数据。Store)是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。仍以主体登记为例，一家企业申请后，数据根据企业变更、迁移等各类业务不断变化，随时间迁移会增加出相关的监管、年检、处罚各类数据。对于主体登记，此时基于业务申请数据，产生实体数据(ODS数据)概念。一家企业的实体数据指通过历次申请沉淀，集成各类附加信息，反映企业当前情况的数据。此例反映出ODS数据由操作型数据不断更新，面向主题，当前或接近当前并且不断变化的特征。通过此例，也反映出对于业务管理数据仓库建设，ODS是不可或缺的一部分。在业务系统和数据仓库之间形成一个隔离层智慧业务数据仓库应用具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。例如，对统计概念“本期设立”,其主要来源于操作数据，而统计概念“期末实有”则可根据企业状态，自ODS数据产出。完成数据仓库中不能完成的一些功能带有ODS的数据仓库体系结构中，数据仓库层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS,但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数由于操作型数据不直接产生，而需要经过筛选才能产生ODS数据。例如，企业的ODS数据中不需要业务申请的办理人、办理过程，因为其不直接反映企业现状，这个筛选过程被称为ETL过程(采集、转换、传输、装载)。通过分析型数据处理的数据ETL过程(采集、转换、传输、装载)将各类业务数据资源归集到数据中心的ODS数据中。ODS本身可以提供主题数据，通过ODS数据的加工处理(统计定制和模型建立),可形成各类统计分析数据。在ODS基础上进行数据的分析挖掘、综合利用，产生的分析型数据处理是数据资源的综合利用的核心。在数据仓库领域中，元数据被定义为：描述数据及其环境的数据。元数据有两方面的用途。首先，元数据能辅助应用，如记录数据项的业务描述信息的元数据能帮助用户使用数据；其次，元数据能支持系统对数据的管理和维护，如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。具体来说，在数据仓库系统中，元五类系统管理功能：(1)描述哪些数据在数据仓库中；(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据；(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排；(4)记录并检测系统数据一致性的要求和执行情况；(5)衡量数据质量。对元数据进行管理，可形成数据资源目录管理应用。通过数据中心的共享交换服务，对外提供数据交换和信息服务，对内进行跨业务领域、跨系统的数据共享使用。、系统设计方案在现有信息化系统进行有效整合基础上，借鉴新一代的应用技术体系，实现对管理要素的全面感知、有效传输和按需定制服务，为行政管理人员和相关单位及人员提供高效的管理辅助，并为公众提供便捷、实时的信息根据项目的建设目标和系统的总体框架、设计思路、建设内容及保障措施，围绕业务协同、信息共享，充分考虑各业务内部管理的需求，平台采用“全面整合、重点补充、突出共享、逐步完善”策略，加强重点区域或运输通道交通基础设施、运载装备、运行环境的监测监控，完善运行协调、应急处置通信手段，促进跨区域、跨部门信息共享和业务协同。以“统筹协调、综合监管”为目标，以提供综合、动态、实时、准确、实用的安全畅通和应急数据共享为核心，围绕“保畅通、抓安全、促应急”等实际需求来建设信息化平台。系统充分整合和利用业务管理部门现有相关信息资源，以信息技术、网络视频技术、互联网技术、移动通信技术、云计算技术为支撑，结合业务管理与数据交换平台，构建业务与各部门之间智慧、畅通、安全、高效的信息化平台。系统充分考虑业务安全及安全职责今后的变化与发展趋势，应用目前主流的、成熟的应用技术，内联外引，优势互补，使系统建设具备良好的开放性、扩展性、可维护性。结合本系统建设要求，需要保证各系统的完整性和功能的实用性，在保证平台运行稳定运行和数据提供准确迅速的同时，界面简单实用，系统可扩展性，可维护性强。在平台的开发、部署与实施中，严格遵循如下指导原则：在本次系统的建设过程中，系统实施和业务模型的建立严格贴合业务管理实际，且充分考虑业务管理部门内部管理的需求特点，本系统将有力的辅助完成公文流转、管用互动和事务管理，有效实现与其相关联系统的数据共享与数据交互，增强系统可实施性。同时系统操作简单、快捷，具有良好的人机交互界面，易于使用推广，且维护方便；此外系统良好的人机接口与灵活多样的展现方式，还能提高用户的查询效率，并做到快速响在系统功能划分模块化设计，预留了发展余地，系统结构设计、系统配置、系统管理方式等方面采用国际上先进同时又是成熟、实用的技术；系统设计所采用的技术和设备符合国际标准、国家标准和业界标准，在系统架构设计上充分考虑到各接口的开放性和可扩展性，满足用户根据信息技术的发展对应用系统进行扩展、维护及系统升级。系统采用先进的系统结构和技术措施，采用成熟的开发手段，具有良好的可靠性，能有效的避免单点失败，关键设备和部件采用冗余配置，能建立各种故障的快速恢复机制，确保系统7×24小时地正常运转，在技术服务和维护响应上同用户积极配合，确保系统的可靠，保证数据指标完整系统在系统级、应用级、网络级提供各自的安全手段和措施，为系统提供全方位、立体化的安全实施方案，以便合法用户能够随时得到所需要的数据支持，系统提供高安全度防护手段，防止内部用户的非法入侵以及操作人员的越级操作，非法用户则无法接触有权限的数据，保护信息的机密，所有应用项目和软硬件都遵守国家保密条例，符合国家有关电子政务系统安全要求，具备较强的自我保护机制，以便能有效抵御各种恶意攻击，确保内部信息的安全。2.迁移数据管理业务及其管理模式将随着社会的发展而不断的变化，与此相对应的是，安全畅通与应急处置的需求也将不断拓展，管理部门将不断产生新的需求。在此情况下，本次系统建设不可能一步到位，这就需要在发展过程中不断完善。因此系统软件体系结构设计上支持大数据量的扩展，以能够适应业务的不断发展和用户规模的扩大，具体设计方式如下：(1)定时清理数据，可以通过使用触发器或者带存储过程的作业来实现定时清理数据业务；(2)利用数据的转换与提取，定期用程序或用事务复制导入原始/汇总数据，把数据复制到一台专门做统计的服务器上，专门做查询所用；查询的时候做相应的优化，例如索引，视图等这样查询的时候压力就会小很多；同时考虑负载平衡，在空隙时利用其CPU和内存；(3)各业务系统和外部数据源传送的数据为维系挽留系统输入，这些数据分别经过数据格式检查；源数据清洗抽取转换、装载数据到收集层；对收集层中数据抽取、转换、装载到数据仓库；数据仓库中数据进行抽取、转换并结合模型算法库中的算法生成维系结果集以供输出；同时通过数据仓库接口，可将数据提供给应用系统的本地化查询使用；(4)划分存储硬盘把数据、日志、索引分盘存放，这样可以提高IO吞吐率用优化器，优化查询。系统的各种接口满足开放和标准化原则。所有系统设备不但满足当前需要，并在扩充模块后满足可预见将来需求，保证建设完成后的系统在向新的技术升级时，能保护现有的投资。1.4平台整体架构系统总体架构严格遵循安全性、共享性、扩充性、可维护性、可兼容性的开发原则；平台建成后，将会有大量的工作人员及船舶公司、商户等同时在线使用。因此在整个平台建设时，将进行良好的规划及架构设计；同时，为了适应未来项目的新增和变更，平台将具有足够的柔性，可通过简单配置和二次开发适应新的需求。在本次中也包括部分软件研发工作，按招标文件要求我公司将组织后台研发人力资源，现场技术人员与后端支持按照研发和维护服务要求配置资源，主要研发人员要培养后备力量，防止人员变动影响服务质量，确保软件研发和维护工作按计划顺利完成。我公司经过多年的研发实践，根据自己的业务特点，形成自己的项目研发实施过程，可分为八个阶段，即项目启动、需求分析、原型研发与策划、设计与编码实现、测试、安装实施、总结验收和运行维护。每个阶段对应着不同的活动内容和工作任务。在中我公司将按照研发实施过程，根据软件升级的需求和升级软件的规模适当的裁剪和简化研发过程，达到系统升级稳定快速上线运行要求。项目升级内容工作量少于30个工作人日，通过软件《变更请求单》,对需求变更进行描述，并由相关主管人员对变更内容进行确认后，安排研发人员进行研发，详细流程见系统维护流程；工作量高于30个工作人日，建议进行正式需求调研，调研与需求分析的任务主要是获取用户需求，分析用户需求特点和要求，形成系统需求，作为项目研发工作的基准。我公司的软件研发方案简单介绍如下：2.1项目启动过程软件研发启动过程意味着项目组正式成立，本公司领导在内部项目启动会上任命软件研发负责人，激励项目组成员，并介绍项目和客户背景，以便项目组顺利开展工作。如果软件研发内容较多，影响范围较大，根据情况最好召开现场启动会，现场启动会议建议由客户方领导组织项目成员和相关人员参加，是一个项目正式开始的动员会，宣告项目启动，明确各方责任，说明注意事项，并要求所有相关人员和部门配合项目开展。我公司项目负责人简要介绍研发实施的过程和方法。2.2需求分析对于业务部门提出的应用软件研发需求，由现场工程师与业务部门进行沟通，了解业务部门对应用软件的研发需求，形成需求文档，经相关部门确认后，按双方商定的研发进度进行研发和实施。首先需要经双方协调，制定《需求调研计划》及《需求调研大纲》,确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，用户也须做好准备工作，经双方同意后按此计划开始调研。调研正式开始前，项目研发组应检查所有必要的准备工作已经圆满完成。按调研计划的进度进行现场调研，主要任务是用业务语言描述客户需求。尽可能及早落实主要算法，确定关键参数，掌握客户政策文件，收集需要打印的报表等。每天应将当天调研的内容整理成文档，并及时与用户确认，提高工作效率。及时将访谈记录、用户政策材料整理成规范格式的需求分析报告，向客户项目组长汇报调研结果，共同对需求分析报告内容进行确认。同时明确今后需求变更控制的规程需求变更控制流程。对于调研期间未落实的问题，以待明确问题的形式体现在需求报告中，并确定落项目研发组根据调研编写《系统需求分析报告》,并由项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否。评审通过后的需求报告将成为系统的设计、研发、测试、实施、试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。研发组与客户一起制定总体项目计划，共同确定本项目的各项工作进度安排，明确每一阶段的工作内容，以及需要用户配合完成的具体工作。2.3研发策划需求调研结束后，根据当前掌握的项目信息进行项目研发过程的策划，软件研发组对用户需求进行深入分析，并和我公司项目原型库各原型进行对比分析，选出和本项目模式接近的复用源作为原型，以便能快速架构和研发出符合本项目特点的稳定适用的原型系统。必要时给项目组成员培训将系统需求各部分功能进行分解，估算分解后各子功能的根据各成员的特长和业务发展方向分配任务。将研发过程分为几个阶段，把某些重要任务的完成作为检查点。根据任务划分结果制定研发计划进度表，并标记出各阶段检查点，作为项目跟踪监控的依据。研发计划要符合公司的模板模范，并与前面提到的总体项目计划保持一致，不可预知事务建议采用日程表记录，不再制定计划。《项目研发计划》制定出来后，要提交给部门进行评审和风险分析，评审通过后纳入配置管理。研发计划一般作为研发过程进度安排，在执行中根据实际情况变化应及时调整修改计划，并将实际执行结果与最初的计划相比较，作为考评研发负责人的一项内容。研发计划进度表参见《软件执行中参照的规程或标准：本公司质量体系文件《软件需求管理规范》、《软件需求规格说明书模板》、计算机软件产品研发文档编制指南、计算机软件需求说明编制指南。项目经理召集项目组全体成员一起讨论和明确系统设计、数据结构、每个人的工作内容、各部分之间的接口关联等。做到每个项目组成员对项目的总体情况、整体工作目标和个人工作目标、工作时间、与其他人的关系、工作的方式方法等都有个清晰的概念，为项目的顺利开展及项目组成员间的良好沟通做好铺垫。应全面考虑调研时用户提出的每个功能模块，研发出的程序应贴近用户需求，研发人员应从用户的角度来考虑问题。做到定期检查和总结，来保证整体程序的完整性、一致性和协调性，保证项目按计划进行。如果发现有重大问题可能影响项目进展，PSM要及时向PM和部门负责人员提出。在研发过程中有不明确的需求，应该尽量以书面的形式与用户交流。项目研发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，形成《系统设计报告》(其中包括数据库设计),提交项目组评审。对其中评审不合格的部分进一步完善和重新策划，评审通过后，作为后续软件研发和测试的基础。根据系统设计输出结果和公司编码规范的要求进行代码编写，实现软件功能。制定二级研发计划，作为软件编码阶段的项目管理和监控依据，项目研发小组要严格据此计划控制项目进度，按时向工程领导小组汇报工作进展。为保证质量软件研发组应每周进行代码审查，提前发现问题，减为了使用户能够及时获知项目的进展情况，研发小组向客户项目组长或相关领导提交项目周报。在编码实现过程中，也欢迎客户业务和技术负责人对阶段结果进行检查，以便及早发现问题，纠正偏差。测试是检验软件研发结果质量的重要手段之一，根据阶段不同，可将测试划分为三个阶段：单元测试、集成测试和系统测试。首先是单元测试，侧重于核实软件的最小可测试元素。单元可以是一个窗口(窗体),也可以是一个函数、菜单、报表或一个存储过程。单元测试应对单元内所有重要的控制路径设计测试用例，以便发现单元内部的错误，保证模块自身的准确性和流畅性。集成测试是把通过单元测试的各个模块组装在一起之后，按设计要求进行的测试，以便发现与接口有关的各种错误，保证系统的初步正确和稳系统测试在单元测试和集成测试后，基于系统的整体需求说明书而对系统进行的准确性和完整性的测。根据测试的内容和侧重点不同又可将测试分为：功能测试、性能测试功能测试是对软件系统的功能需求进行的测试。主要暴露由于系统说明写的不明确或研发人员对系统说明的误解或理解不足造成的功能错误。性能测试是为描述测试对象与性能相关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。包括负载测试、强度测试、并发测试、恢1)负载测试：核实在保持配置不变的情况下，测试对象在不同操作条件(如不同用户数、事务数等)下性能行为的可接受性；2)压力测试：核实测试对象性能行为在异常或极端条件(如资源减少或用户数过多)之下的可接受性；3)并发操作测试：核实测试对象在处理多个并发请求时的可接受4)恢复测试：恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或通过加强性能测试提高软件可靠性，使系统每年中断工作次数不超过3次，累计时间不超过1小时。安全性测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时的表现。测试人员在软件研发过程中开始编写测试用例和测试大纲，根据制定的《测试计划》,在软件功能模块完成后，根据需求和设计结果的要求对软件进行测试，填写《测试问题卡》,并进行测试总结编制《测试总结报告》,对测试所发现的问题进行追踪修改和确认测试，直到彻底修改完成并对其它模块没有任何影响。测试过程尽量能够模拟用户环境测试几个周期。测试组测试时，研发人员应密切配合，及时改正测试出的问题，对问题应做备忘录，以便将来查询。测试资料作为项目验收的重要内容之一。为加快项目进度，建议用户方测试组及早介入测试，最晚也应在我方的系统测试完成之前介入，并按事先双方约定的规范方式进行测试。2.6总结验收验收分两个阶段：安装运行前的用户测试；系统正式运行后的实际业务操作的检验。系统运行满足约定时间后，进行软件的验收工作。验收前和用户沟通好验收的时间和方式，制定验收计划，列出模块清单，并且安排好每个模块验收的时间段，按照这个时间列表与用户逐个模块验收。双方事先商定验收过程要求及参加人员，必要时邀请行业专家和相关领导参软件验收以符合需求分析、业务要求作为验收标准。验收结果说明软件满足下列要求：符合通过审核的需求和设计文档中表述的功能要求，以及符合性能和安全性等非功能要求。问题处理：将验收过程中发现的所有错误都必须记录下来；对错误进行分类和确定级别；报告的错误得到修改/处理，或修改错误的计划得到验收工作建议由用户相关部门组织的专家组对软件系统进行全面的验收和鉴定，并出具项目验收小组领导签字的项目验收报告，并签署验收意见，本公司在此过程中将全程参与，在现场进行验收前的维护工作。对运行中的系统进行维护时，要严格按流程操作，以防带来意想不到的后果。系统维护一个很重要的事情就是我们要与用户沟通好工作的方式●软件研发和升级完善遇到不能按时完成等重大问题时，须提前提出，双方协商解决。系统基本稳定后，如果有问题，由用户定期书面提交问题报告，我们根据问题情况，制定问题解决方案及提交时间，并书面反馈。有秩序、心平气和而又很理智去思考和解决问题。系统我司计划采用当下流行的微服务架构，各业务应用分别注册在云平台及现场服务中，模型服务对应模型数据及围绕模型的业务逻辑，各业务应用的服务对应应用模型数据及围绕应用模型的业务逻辑。流程引擎、表单引擎、公文交换平台是系统的三大核心组件。系统采用了符合BPMN规范并且高度可扩展的流程引擎服务，通过流程引擎配置功能，实现个性化流程节点的灵活配置，流程引擎架构图如下所示：表单引擎有丰富的资源库，便捷的画布设计、自由拖拽组合，支持快速流程模板配置，真正意义实现千人千面页面展示效果。表单引擎架构图表、表格操作(增、删、插入等操作)。系统数据库具有灵活的系统兼容性和伸缩性，可灵活接入其他系统，是一个实用、高效、安全的平台。其采用安全的数据交换技术实现平行文、下行文、上行文的公文交换。网络及硬件平台包括网络设备、服务器主机、操作系统、存储设备等资源，是应用软件开发、运行的基础平台。网络平台层的构成具有个性化的特征，不同的应用环境具有不同的主机设备、不同的网络设备、不同的存储介质、不同的操作系统。因此这要求建立在网络平台层之上的应用支撑平台层必须具备跨平台的特性，只有这样才可延伸原有资源的生命周期，避免硬件设施的重复投资。我司的统一电子解决方案框架平台是基于J2EE技术建设的，因此系统具备跨操作系统的特性，从而可最大程度地保护用户的使用。其中应用服务器中间件采用BEAWeblogic中间件，数据库采用3.2基础服务应用平台应用支撑平台层起到保证事务完整性、响应大规模并发处理、支持异构系统的互联，并对应用数据的安全性进行保障，是三层结构不可或缺的重要组成部分。本系统采用BEAWeblogicPlatform、BEATUXEDO为J2EE应用服务器和消息/中间件。业务支撑平台层是多层架构业务系统的核心支撑部分。我司的业务支撑平台以J2EE应用服务器和消息中间件为核心依托，包括我司自主版权的通用中间件产品。三层框架开发平台，为实现业务应用的快速开发提供了动力和保障；工作流平台，用于管理业务系统易变的流程；数据交换平台，用于数据传输和数据转换以及应用系统集成；消息平台，主要用于公共服务系统中将手机、语音等多种渠道的消息统一成一种消息。业务支撑平台将各系统中的共性功能抽象、封装并统一解决，提供丰富的功能组件，使用开发人员可以将主要精力集成在业务逻辑，而不是复杂的技术实现。业务支撑平台是我司的核心企业应用平台，在今后的运维服务系统开发中，我公司也将充分利用该开发平台的优势，利用平台中的一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。3.3业务组件与表示层业务逻辑层实现了应用系统所有的业务组件，业务组件基于应用支撑层进行构建开发，并且业务组件设计开发遵循“高内聚、低偶合”的思想，使业务组件之间可以保持相对独立，并且通过表示层个性化定制业务组件。用户通过系统表示层实现对业务系统的操作与交互，系统表示层设计遵循操作方式简便、灵活、友好；操作界面设计风格统一，符合业务办理流程规范，便于操作员学习掌握等标准进行设计，并可以根据每个用户使用特点和角色的不同，形成个性化的应用界面。表示层提供业务展现、内容管理、个性化定制、访问控制、搜索服务等功能。3.4我司通用企业运维应用平台本次开发基于我司自主研发的通用企业应用平台进行运维。下面对通用企业应用平台的结构、功能和特点进行简要介绍。如果从更广义的角度来讲，又称为“组件框架”,即ComponentFrameWork。企业应用平台是我司构建于多层架构的，以J2EE规范为核心技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架，它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。它是一个基于组件技术的快速开发和运行平台，它的部分组件最终同业务应用组件一起部署到ApplicationServer上。Fj…me(achtFj…me(acht商业逻辑层BFW对象持久化层0p通用应用平台在整体框架上采用典型的MVC模式，集中了大量功能强大、灵活易用的功能组件。既支持C/S/S结构也支持B/S/S结构，其中两种体系结构共用同一套业务逻辑处理服务，只是表现和控制层不同。统一的业务逻辑层星星昌国8商业逻辑层以EJB/JavaBean技术为实现手段，提供了对象持久化等商业逻辑组件。设计要点如下：2.通过统一的服务组件基类调用安全、日志、工作流、规则等引擎3.在管理管理信息系统中对象持久化是一个关键性服务，单一的数据库接口解决全部问题并不现实，因此采用由OP层统一包装，统一管理，但暴露多种操作接口的方式来解决。对象持久化接口提供面向对象和面向过程两大类，具体支持四种方式：2)简单的sqlexecute封装3)可持久化的数据总线DataSet,通过其xml接口可发送到页面)4)DAO(单表抽成的可持久化的实体类对象)平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。C/S/S结构的视图层和控制层"工厂”模式来获取服务组件对象的。这样做的好处是可以以透明的方式业务逻辑层采用我公司统一的通用企业应用平台，所以在控制层最后一道套经过验证是健壮稳定的架构。与系统核心平台二版略有不同的是：由于C/S/S结构的框架设计基本上采用系统核心平台二版的结构，这是一"工厂”模式来获取服务组件对象的。这样做的好处是可以以透明的方式业务逻辑层采用我公司统一的通用企业应用平台，所以在控制层最后一道套经过验证是健壮稳定的架构。与系统核心平台二版略有不同的是：由于C/S/S结构的框架设计基本上采用系统核心平台二版的结构，这是一古客户端ⅡDAO(数据访问对象)DCM(数据控制管理层)通过配置文件实现了将Event分发给相应的EJBAction去处perform方法处理Event处理EJB和JavaBean的服务对象。C/S/S结构中客户端的设计要点是：1.GUI采用传统的Window界面，以Delphi为开发工具；2.客户端通过统一的动态库函数与服务端的门户MainServlet通讯，通讯的内容以XML为数据格式，整个通讯协议完全模拟SOAP协议；3.客户端的设计在分层基础上对类进行了适当的归类。做到类之间的调用关系明确。类的责任单一。类之间的依赖关系简单。编程实现较为方便。下面简略的介绍一下编程常用的调用关系。为了说明上的方便，图中把框架完成的调用关系去掉了。调用关系简图如下：C/S/S结构中控制层的设计要点是：1.整个控制层的设计思路参考B/S/S结构中的Struts框架。MainServlet可以映射到Struts的ActionServlet,而RequstProcesser+Event可映射到Struts的Action;2.但与Struts不同的是它与客户端之间传递的均是XML,没有表B/S/S结构的视图层和控制层设计界面层以JSP/XML界面层以JSP/XML/XSL/JS技术为主要实现手段，为系统开发提供了系列功能强大的组件，主要有以下几大类：请求入口轻型控性请求校验及格式化客户端请求接口1.轻型控件：封装所有的HTMLForm元素和按钮，提供显示、标准2.重型控件：包括DataWindow,目录树，Tab页等具有复杂功能属3.局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功能，并封装通用的页面对话框；4.Object:Applet和COM,用于复杂界面操作和客户端本地化操作。请求控制层以Servlet技术为实现手段，综合运用struts框架和WorkFlow引擎，以单点入口的方式统一控制请求。设计要点如下：ActionServlet和DispatchAction作为企业应用平台的流程控制基类；2.组织机构和权限管理模块进行身份和权限认证，从视图、操作、数据三个层次控制权限行为；3.日志和异常处理负责系统信息的记录；UniWorkflow定制和控制业务流程。5.Action本身并不处理业务逻辑，而是通过统一的BSFactory从EJBContainer获取BusinessServiceComponets处理业务逻辑。3.6通用企业运维应用平台的特点1)采用了三层结构的技术框架，为应用系统提供了一个非常良好的结构，应用系统将来的升级、扩充、修改和定制都非常方便。当用户需要发生变化或需要对某个功能进行修改的时候，可能只需要对某一个层次的组件进行修改，而不会对整个系统的结构发生影响。和维护的难度，降低安装和维护的成本，由于界面操作风格一致、操作简单，也降低了对用户培训的要求。另外，由于支持WWW技术，为将来支持其他的客户端和移动用户也提供了技术上的可能。3)提供了最基本的系统组件，如用户管理、权限管理、组织机构管理、工作流管理、菜单管理、数据库管理等功能，简化了应用系统开发的过程，提高了工作效率。而且在将来应用系统开发的过程中，也可以提取和积累各种通用组件，增强系统功能。4)实现了界面层和数据层的统一管理，在应用系统的开发过程中，不需要对界面层和数据层进行编码，只需要通过系统工具对界面层和数据层对象进行定义即可。这样不仅简化了开发过程、提高了开发效率，而且在界面层和数据层需求发生变化和需要重新定制的时候，可以通过简单地修改界面层和数据层的进行来完成。5)基于应用框架，应用系统开发员可以集中精力开发业务层组件，不需要过多地考虑各种技术问题和其他方面的实现细节，也提高了业务层组件的独立性，减少与其他模块的关联，便于将来扩充、升级和修改。6)提供了一个统一的界面层，该界面层包括菜单管理、视图管理、界面权限管理、界面操作逻辑管理、界面元素自动生成等功能。应用系统开发员只需要定义好自己的界面层对象，不需要把精力花费在界面逻辑和界面操作的实现上，简化应用系统开发的过程，而且所有基于UniEAP的应用系统界面风格一致、统一管理、操作方便，方便了用户学习和使用，也降低了培训和维护的费用。7)提供了一个通用的数据层，业务系统不需要重新开发，只需要定义自己的数据层对象，因次简化了应用系统的开发过程。8)从界面层到数据层，都充分体现了业务对象之间的各种关系(一对一、一对多、多对多等),并且提供了充分的实现手段，使得应用系统实现业务对象之间的复杂的逻辑关系成为可能，而且非常简单。方便了业9)在很多方面提供了通用的模式和技术规范，如组件设计、数据库设计、界面设计等，可以为应用系统的开发提供有效的指导和参考。由于本此项目系统的的设计和开发我司未进行参加、因此本次运维我司自主研发的通用企业应用平台进行运维，所有我司有信心做好采购方软件运维服务。提供了统一的模式和共享组件，降低了系统间的耦合度、减少了应用系统开发的模块，因而能够准确地控制应用系统开发的过程，有效地提高应用系统开发和维护的质量。按招标文件要求对于采购单位提出的应用软件升级需求，由现场工程师与采购单位业务部门进行沟通，了解业务部门对应用软件的升级需求，按双方商定的开发进度进行开发和实施。采用组件技术，系统具有非常好的可扩充性，对新技术的发展也具有很好的适应性。这是因为采用了组件技术后，可以开发出各种共享组件和通用组件，也可以集成第三方开发的组件，组件的升级也非常方便，而且随着组件技术的标准化，不同的组件标准之间也可以实现通讯，因而无论采用哪种组件标准都具有可扩充性和因此，应用升级中，对系统平台充分了解的情况下，能够较准确的规避升级过程中的技术难点，提出多种适合劳动保障系统的升级方案，能够较准确的根据企业平台的特点估计工作量，对升级时间进度准确把握，让客户方对升级的进度和时间安排做到心中有数。另外，由于由于采用了组件技术，提供了很强的可定制能力，因而应用系统能够在此基础上能够建立面向具体行业的业务模型，在每一次为具体用户定制业务系统的时候，都可以积累经验，提高业务模型的通用性，以便适应更加广泛的用户需求。软件系统将涉及系统等多个分公司及与其他相关公司和内部系统的接口，软硬件基础设施复杂，因此在系统的实现上必须采用标准的技术，以求跨操作系统平台、跨数据库平台、跨中间件平台。基于此本公司在整体技术实现路线上采用基于J2EE和webservice组件的技术构建应用逻辑。应用逻辑层和公用服务层的每个功能模块均是一个相对独立的组件，这些组件的开发和部署保持相对的独立性，而且在未来很可能是由不同的团队开发和部署的，也是可以相对独立的进化的。每个组件通过定义良好的接口，向外部提供服务。这些服务的获取者可能来自客户端、可能来自其他组件。这种基于组件的设计可以达到比较好的重用性。在J2EE的架构下，各组件通过J2EE标准定义的RMI协议，向各客户组件提供服务。业务操作员及公众信息查询人员通过标准的HTTP协议或安全的HTTPS协议访问系统管理信息系统及公共服务系统。公用服务层同样以组件的方式实现，可以与业务逻辑的组件的部署在同一应用服务器上，也可以部署在不同的服务器上。如果业务逻辑层的组件和公用服务层的组件驻留在同一进程空间中，则通过对象间的消息机制通讯，如果驻留在不同的进程空间中，则通过标准的RMI-IIOP的协议通在管理信息系统中，最重要，难度最大的是数据操作的实现策略，因为在任何一个管理信息系统中“信息”都是系统的核心，几乎每一个业务逻辑都与数据操作相关，因此本方案将对数据操作的实现策略进行详细阐在J2EE的架构中，对数据库的操作有两种方式，一种是组件管理的持久性(Beanmanagedpersistence),也即组件自行管理数据库操作的完整性和一致性；另一种EJB容器管理的持久性(ContainerManagedPersistence),也即通过J2EE的应用服务器提供的对数据库操作的服务。考虑到性能和负载方面的因素，我们建议采用结合事务处理服务器和组件管理的持久性的方式，管理对数据源的操作。介于业务逻辑层和数据服务器之间的是事务处理服务器，处理服务器负责处理实际的对数据源的操作，保证多个数据读写请求对多数据源的操作的原子性、一致性、隔离性和持久性。同时通过处理服务器，进一步降低业务逻辑层和数据源之间的耦合度。逻辑架构中的服务和查询处理服务均驻留在事务处理服务器上，操作数据库，保证的完整性和查询的性能。J2EE组件与事务处理服务器通讯的机制，与事务处理服务器的平台和应用服务器的平台有关。事务处理服务器一般需要在数据库服务器上安装相应的组件，通过紧密集成的数据库访问机制，访问数据库。介于处理服务器和业务逻辑层之间的是公用的数据存取服务，这一层封装业务逻辑和公用服务层其他组件对各种数据源的读写操作，直接管理与数据库、目录服务器、应用集成服务器之间的数据交换请求，进一步降低业务逻辑与服务器、目录服务器等数据源之间的耦合度。在基于J2EE应用架构下，将数据存取服务独立出来的原因如下：采用诸如bean管理的实体bean、会话bean和诸如遗留系统、B2B、LDAP等等其他数据源中检索数据，以及进行数据根据产品供应商不同，持久存储API差别很大。一些数据源拥有非标准化或私有的API。这些API和其能力同样根据存储的类型不同也有差别.纯文本文件等。这样存在如下缺点，即访问这些系统的API很不统一。组件通常使用私有的API来访问外部或遗产系统，以便于检索和存储数据。当组件中包含特殊的访问机制和API时，组件的可移植性直接就受到影响。组件需要透明于实际的持久性存储或者数据源实现，以便于提供到不同供应商产品、不同存储类型和不同数据源类型的更容易的移植性。解决以上的问题，需要采用数据访问对象(DataAccessObject,DAO)来抽象和封装对数据源的访问。DA0管理着与数据源的连接以便于检索和下图说明采用数据访问对象提供数据存取服务的实现。数据库数据库封装封装封装使用图-1实现示意图其中业务对象代表数据客户端，该对象需要访问数据源以获取和存储数据。数据存储对象是数据存取服务的主要对象，数据存储对象封装业务对象对数据源的访问，以保证对数据源的透明访问，业务对象也把数据加载和存储操作委托给数据存取对象。事务处理服务负责完成对数据对象的实际存储和加载的工作，应用集成服务实际完成将数据发布到外部系统以及从外部系统读取数据的职能。值对象代表用作数据携带的值对象。数据存取对象可能使用值对象来把数据返回给客户端。数据存取对象也可能使用值对象接受来自于客户端的数据，并更新数据源中的数据。下面的时序图表示使用数据存取对象读取数据库数据、更新数据库数图-2过程示意图业务对象负责完成应用逻辑的处理，通过数据存取对象向事务处理服务器发出读取数据的请求，事务处理服务器将数据库中的数据读取出来，数据存取对象创建值对象，将值对象返回给业务对象。为了运维本套系统，我司在本项目应用软件系统中综合利用核心平台的架构特点，基于核心平台进行运维，设计实现基础服务应用平台，在此平台基础上构建可拆可合、可配置的业务组件。下面对其结构、功能和特点进行简要介绍。基础服务应用平台，如果从更广义的角度来讲，又称为“组件框架”,是构建于多层架构的，以J2EE规范为核心技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架，它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。基础服务应用平台不是ApplicationServer,它与BEAWeblogicApplicationServer、Tomcat、JBOSS均不属于同等性质产品。它是一个基于组件技术的快速开发和运行平台，它的部分组件最终同业务应用组件一起部署到ApplicationServer上。yReposi0基础服务应用平台的结构简图如上图所示，各组成部分的功能及职责GUI:用户界面层呈现用户交互界面提供表现控件界面控件布局控制界面的表现，包括具体的设备和与设备相应的UI的控制。功能限于界面的具体在设备上的展现(如：Browser对html的解析)、界面表现的控制、界面组件的布局。InteractionControl:交定义业务逻辑的逻辑表单开启和关闭事务响应用户界面层的业务请求提供事务管理机制将基础服务纳入统一的事务管理范畴ApplicationLogic:应用逻辑组件处理事务规则及功能提供原子业务功能ApplicationService:基础服务组件统一资源访问服务身份认证服务权限管理服务报表服务其它服务基础服务应用平台的技术架构如下图所示，它是对上节中架构简图的图-3架构简图Client层以JSP/XML/XSL/JS/PB技术为主要实现手段，为系统开发提供了一系列功能强大的组件，主要有以下几大类：轻型控件：封装所有的HTMLForm元素和按钮，提供显示、标准行为局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功能，并封装通用的页面对话框；Object:Applet和COM,用于复杂界面操作和客户端本地化操作。UIM层以Servlet技术为实现手段，以struts框架为依托，采用单点入口的方式统一控制请求。设计要点如下：采用Structs控制请求和业务流程，拓展Struts的ActionServlet和DispatchAction作为基础服务应用平台的流程控制基类；Action本身并不处理业务逻辑，而是通过统一的IneractionObjectFactory从EJBContainer获取IneractionObject处理业务逻辑。商业逻辑层以EJB/JavaBean技术为实现手段，提供了对象持久化及打印、邮件等商业逻辑组件。设计要点如下：通过统一的服务组件基类调用安全、日志、工作流、规则等引擎式服在管理管理信息系统中对象持久化是一个关键性服务，单一的数据库接口解决全部问题并不现实，因此采用由OP层统一包装，统一管理，但暴露多种操作接口的方式来解决。对象持久化接口提供面向对象和面向过程两大类，具体支持四种方式：1)得到connection2)简单的sqlexecute封装3)可持久化的数据总线DataSet,通过其xml接口可发送到页面)4)DAO(单表抽成的可持久化的实体类对象)平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。基础服务应用平台在逻辑服务组件上借鉴Spring的实现机制，采用类似WebService的UDDI所定义的、由基本的三个角色构造的“ServiceRequestor—ServiceRegistry—ServiceProvider”三角型访问模式，所有发布的InteractionObject都在InteractionObjectFactory中注册，且可以同时存在多个Provider(如在J2EE体系中就存在JavaRequestor,它调用InteractionalObject时先通过InteractinalObjectFactory根据注册信息找到InteractionalObject的Provider,然后得到由Provider提供一个InteractionalObject的stub,最后再调用InteractionalObject的servicemethod对请求进行处理。这所以这样做的一个根本目的是：将逻辑组件开发和部署分开，由工具插件统一负责组件部署，业务开发人员只需要用最简单的语言完成业务逻辑即可。基础服务应用平台专门为InteractionalObject的访问定义了一个“InteractionalObjectFactory”层，这一层主要考虑的是屏蔽在Action中对InteractionalObject的不同调用方式，使得在不同的环境下的移植變得很方便(不管是何种组件的调用方式，返回给Action的服务接口都是相同的，從而保证Action中代码的可复用性)。架构中的几层在“创作”过程的依赖关系是什么,即凭什么知道要创下图阐述了几层对象在创作过程中的依赖关系，它们之间的连线是本节说明的重点，所以颜色调成了红色，对这些线的说明调成了蓝色，以显突出。注释文字可能有点不清楚，拷在下面：用户界面需求会决定最终的界面窗口是什么样子的。我们提倡在需求调研时就把大部分界面都确定下来。界面会决定有什么样的Interaction,以及Interaction都完成什么样的功能。但并非一个窗口就完全对应一个Interaction,一个窗口可能会用到多个Interaction,而一个Interaction也可能被多个窗口调用。但界面中的一次请求肯定对应一个Interaction对象中的一个方法，要不然怎么管Interaction叫“交互对象呢”?一次交互就是一个完整的事务。界面间接决定了Action的命运。逻辑需求和行业经验会决定设计出多少AppLogic,落实到具体的模型就是有什么实体类，有什么控制类。其中实体类会在编码阶段被拆分为Interaction是GUI层和BL层的“和事佬”,它主要是要满足GUI的请求，但也要照顾AppLogic的脸色，必要时要对GUI和BL做个折中处理。用广界面肃求会决定最终的界的前口是什血时应一个Aetion.Aelian是势Interactian都完成什么样的功能，但并作一个窗一个lateraetlam叶单中的一个方法。安不热亮普Inleractloa-“变五时象呢”?一次变五就Imternotion是GML层和肌属的“和事储”,它立要是要满足CE1的请必要时要对1未配假个析中处理，西间接凑定了Aetion的命速’图-5示意图前后台交互文档中对说明哪个Action的哪个方法来响应界面请求，入参、出参是什么,看了交互文档