数字城市执法信息系统介绍

1、数字城市执法信息系统介绍第一章概述1.1项目背景市市政园林局（以下简称市政园林局）是市政府主管全市市政、供水、燃气 和城市园林管理工作的工作部门， 主要负责城市道路桥梁、 城市排水、 城市污水 集中处理、城市绿化、城市自来水、城市燃气的建设和管理等职能。目前，市政园林局已建立了 “数字市政” 核心系统基础地理信息平台 （ GIS） 和核心系统业务管理系统（ MIS ），并且局属单位建立了供水专业子系统、燃气 专业子系统、排水专业子系统，各系统之间遵循“数字市政”统一的数据标准和 技术规范实现数据共享和互联互通。随着市政园林局 “数字市政” 二期的实施， 数字市政已经逐步进入了全面启 动和维护应

2、用的阶段， 在强化内部管理系统应用的同时， 市政园林局需要进一步 拓展应用领域，一方面，加强巡查工作，及时发现和处理问题，另一方面加强与 市民互动，提高服务水平。但是，现阶段某些市政设施的案件信息主要通过群众举报、 社区上报等方式 而被动获取， 部分设立巡检人员的部门， 也主要依靠巡检人员现场检查并联系相 关处理单位进行案件处理， 如果有巡检结果，一般使用纸记录方式， 不便于查找， 而且保存也是一个大问题， 容易出现丢失的情况。 由于市政的设施特别多， 项目 复杂，工作量很大，巡检人员必须深刻了解所在区域的情况， 否则就会出现漏检， 甚至是不检的情况。当前的管理模式已不能满足市政业务监督要求。

3、1.2系统建设目标系统建设的主要目标是在已经建成的数字市政核心系统一期（GIS）、二期（MIS）的基础上，围绕责任明确、巡查到位、发现与处理问题及时、增强与市 政互动、加强监督考核等要求， 进一步拓展数字市政系统功能， 促进数字市政的 全面推广应用。根据招标文件，我们认为“数字市政” PDA巡查系统不同于一般的数字城管 系统，它是一个专业城市管理和泛城市管理相结合的一个市政网格化管理的应用 模式。其专业的管线，如自来水、燃气、污水等专业设施专业性很强，非一般人 员所能发现和处理，因此这是一个宏观和微观相结合的城市管理专业系统。根据上述目标，“数字市政” PDA巡查系统的主要任务是：（一）满足市

4、政管理需求1. 快速、全面发现和了解问题。 把市各个区按街道以及路网划分为一定的市 政信息收集基础网格， 并以此为基准形成物理网格， 同时由于市政的专业性， 人 力资源配置不同， 巡检人员的专业背景不同， 因此各专业公司有必要在物理网格 的基础之上，通过重新组合， 形成本公司的巡检网格， 所有的巡检人员多头管理。城市市政设施巡查人员按责任根据各专业公司的逻辑巡查网格进行动态巡 查，对发现的问题运用PDA采集子系统实时上报业务受理平台， 使发现的问题迅 速纳入系统流程并快速流转。2. 有效的指挥处置。建立市政管理责任分工体系，明确各级各部门职责。 业务受理平台根据问题的性质、 类别等情况立案，

5、并将立案后的问题转发给调度 督办中心； 调度督办中心接到业务受理平台的案件后， 利用数字化系统流程， 迅 速向责任部门派发任务； 责任部门按限时处理制度要求， 及时办结， 结果反馈调 度督办中心和业务受理平台。3. 科学分析，绩效考核。运用分析评价子系统，对管理部门、市政巡检员的 相关数据进行科学的统计分析， 建立一套绩效考核机制， 严格而科学的对市政建 设、市政管理进行分析和评价。4. 资源共享。利用市政局现有资源，包括“数字市政”各种软硬件环境以 及煤气公司、自来水公司等专业公司的呼叫中心，集成成一个统一的应用平台。 充分利用“数字市政”的各种空间数据，对市政相关部件进行精细化管理。（二）

6、面向对象的管理思路借鉴面向对象的思路， 把市政管理对象简要分为部件、 事件， 把部件按市政 管理的职能和专业分工进行分类管理， 其对应的事件也归属其专业公司， 通过将 不同的对象进行有效的组合， 形成责任网络、 管理部门、巡检人员、 部件、事件、 处置等一体化的基于对象的管理思路。（三）科学分析评价。 通过分析评价子系统， 建立一套科学完善的绩效考核 体系，对管理的各责任主体的工作效率的综合考评， 对责任网络或更粗粒度的市 政设施状况的进行综合分析，比如利用GPS技术和手机定位技术，对巡检人员上 岗履职情况进行监督评价，对各专业公司处置问题的效能进行监督评价。1.3系统建设依据的标准GB/T1

7、5539-1995 软件工程标准分类法GB/T8566-2001 信息技术软件生存周期过程GB/T8567-1988 计算机软件产品开发文件编制指南 城市市政综合监管信息系统技术规范 城市市政综合监管信息系统管理部件和事件分类与编码 城市市政综合监管信息系统 _地理编码GB/T9385-1988计算机软件需求说明编制指南GB/T9386-1988计算机软件测试文件编制规范GB/T12505-1990GB/T14079-1993GB/T15532-1995GB/T16680-1996GB/Z18493-2001GB/T12504-1990GB/T17544-1998计算机软件配置管理计划规范 软

8、件维护指南 计算机软件单元测试 软件文档管理指南 信息技术软件生存周期过程指南 计算机软件质量保证计划规范 信息技术软件包质量要求和测试GB/T18491.1-2001 信息技术软件测量功能规模测量GB/T18492-2001 信息技术系统及软件完整性级别地球空间数据交换格式 计算机信息系统安全保护等级划分准则 全国组织机构代码编制规则地名标牌 _城乡中华人民共和国行政区划代码地名分类与类别代码编制规则城市市政综合监管信息系统单元网格划分与编码规则技术文件第二章需求分析2.1业务需求分析2.1.1PDA 采集子系统PDA采集子系统以PDA为原型，为城市市政设施巡查人员对现场信息进行快 速采集与

9、传送而研发的专用工具。 该手机装有网格化地图， 具备接打电话、 短信 群呼、录音拍照、GPS定位、表单填写、用户管理、地图浏览、数据查询、数据 同步、辅助功能等主要功能。接打电话 可以接听由监督中心下达的任务或者拨打电话到监督中心上报信息、 反馈信 息。同时可以在监督员之间进行通讯和联络。短信群呼 将检查到的信息或对工作有帮助的重要以短信群呼的方式发送到监督中心 及其他监管员的设备中。亦可在监督员之间通过群发方式请求援助。录音拍照 通过录音和拍照功能可以拍摄城市部件中发生的问题，录制群众的言论信 息，最终以图片或音频数据的形式作为市政管理问题的附件上报到监督中心。GPS定位利用手持的移动终端设

10、备具有的 GPS定位功能，可以在一定精度范围内将 事件发生位置精确定位到地图上， 并且可以显示或查询自己所在位置、 巡逻路线 情况及周边人员位置信息等情况。 可以进行个人巡查线路轨迹回放， 计算轨迹长 度及计算轨迹包含面积，同时可通过移动 GPR测络定期或不定期向调度中心发 布自己所在位置，使业务受理子系统能掌握巡检员的在岗情况， 记录其巡查路线， 为综合评价提供基础数据。地图操作 包括地图放大、缩小，地图漫游，全图显示，地图测距，测量面积等地图浏 览基本操作，同时需要提供地物编辑功能，能对地图中地物进行位置、形状、属 性的增加、删除、修改等操作。 并可通过一定的流程把修改后的数据更新到中心

11、地理信息数据库。数据同步本功能主要用于更新数据，通过 GPRS5线数据传输实现“市政通”的数据 始终与服务器数据交互， 使两者数据保持一致。 包括接收调度中心下发的巡查指 令，日常信息。表单填写 系统具有提供标准表单模板的功能，并且可以提供各功能选项用以自由组 合。监督员将采集到的信息在相应表单中填写，通过 GPRSc线网络发回到业务 受理子系统。要求表单可根据需要定制。用户管理由于负责各区域的监督员采用轮流上班的方式进行工作， 因此在员工进行交 接班时提供用户登陆 / 退出的方式对监督员进行管理：输入员工卡号、密码，登 入系统（监督员的基本信息在设备中预先存储） 。并且该操作会将信息自动传输

12、 到监督指挥子系统中，便于对监督员的管理。数据查询客户端设备应具备简单的查询功能： 根据属性查询（在屏幕上输入要查询的 属性条件，根据该条件进行查询，找到满足要求的对象） 、根据位置查询（根据 相对位置进行查找符合要求的对象） 、在图中选择部件对象查询其属性信息，并 且可以对查找到的对象进行目标定位。辅助功能用户可以根据个人的使用习惯对系统进行定制。2.1.2业务受理子系统业务受理包括两种方式的受理， 一种是由公众和媒体反映的问题； 第二种是 由城市监督员发现的问题，业务流程也有两种形式。业务受理子系统是呼叫中心使用的， 接收巡检员上报和公众举报的市政管理 问题，建立市政管理问题案卷并利用工作

13、流方式向下一个环节转发； 该子系统同 时与“市政通”通讯，发送问题核实、处理结果核查等工作任务。并利用工作流 引擎 按照工作流程实现整个巡查指挥调度案件信息的流转。 要求案件工作流程可 修改、定制。上报问题登记问题上报是整个市政管理业务流程的开始， 公众投诉通过呼叫中心系统， 由 工作人员新建问题案卷，进行登记和录入。巡检员通过PDA采集子系统收集问题 信息，转发到业务受理子系统直接生成案卷记录， 并可由工作人员补充录入不完 整的信息。 实现与局总服务调度、 供水热线、 煤气客户服务热线三大呼叫系统的 衔接，包括呼叫信息的传入和受理立案信息的发布。地图浏览 包括地图放大、缩小，地图漫游，全图显

14、示，地图测距，测量面积等地图浏 览基本操作。 可以在地图上看到巡检员所在位置， 回放巡检员某时间段内的巡查 轨迹。可以进行问题定位，并发送问题位置到巡检员移动终端。举报问题核实对于公众举报的市政问题， 在新建问题案卷后将相关信息发送到 “市政通”， 由巡检员对问题进行核实， 通过核实的案卷转入审批环节。 核实为虚报的案卷则 作结案归档处理，并向公众进行反馈。地图更新可以将指定区域指定图层的地理信息数据导出到 PDA手持终端，并且可以把 PDA手持终端上的部件等相关信息经审核后导入到“数字市政”基础地理信息平 台。通过一定的流程可将PDA上待更新数据更新到中心地理信息数据库， 进行数 据更新。立

15、案处理经过确认的案卷给予立案，生成案卷编号等信息，并转到下一环节处理。 处理结果审核收到调度中心任务完成消息时， 将相关的任务信息和案卷信息发送到 “市政 通”，由巡检员进行处理结果的审核。并根据巡检员的反馈，对案卷进行结案和 归档处理。案卷结案归档问题处理完毕并核实处理反馈后， 进行结案处理并归档， 并实现与 “数字市 政”二期系统业务数据相关联。案卷查询统计及部件定位 可用多种方式查询统计案件信息，并定位问题部件。用户办案信息箱 系统提供了用户的个性化服务， 将用户处理的案卷相关信息保存在 “办案箱” 中，用户可以随时追踪所关心的案卷。 当有通知信息达到时， 自动弹出提示框通 知用户。2.

16、1.3调度督办子系统 调度督办子系统接收业务受理子系统传送的案件信息， 根据案件具体情况利 用工作流进行案件的分工，指派，下发工单。指派任务，派送工单到局属单位。指派任务到相关局属处室。 接收各单位，各部门案件处理反馈信息。 调度管理通过协调将案件转交给局外单位处理，或重新分派给局属其他单位处理。 督办、催办对已立案的各案件的办理情况进行监管， 对接近办结期限的案件可发出督办 或催办信息，或直接对重点案件发出督办通知。案件反馈 将案件处理信息反馈给业务受理子系统。2.1.4构建及维护子系统构建及维护子系统负责构建系统各种表单及流程，管理维护各种基本信息， 使系统正常运作。构建工作流程 要求能根

17、据业务需要， 用户可定制、 构建业务工作流程， 设置人员角色等各 种流程参数。构建各种表单、工单要求能根据业务需要， 用户可定制、 构建业务工作表单及下发的工单， 并在 工作流程中应用。部门管理系统应提供部门管理功能， 统一管理局属各单位， 各巡检部门， 设施维护部 门的基础信息。巡检人员管理系统可以统一管理巡检人员基本信息， 对相应人员制定巡检计划及各种巡检 表格。PDA终端管理管理维护PDA终端信息，并与相应巡检人员关联。历史信息维护将所有的巡检信息及已经完成的案件信息建立历史信息库， 可以调出相应的 历史信息进行查看， 并实现历史信息地图定位， 以方便快捷的方式进行查询， 并 可以通过至

18、少一种统计图表来汇报各类统计信息，如历史问题多发设施等。2.1.5巡检网格划分及管理根据属地管理、地理布局、现状管理、方便管理以及兼顾现有各专业责任区 等原则，在建成区（少量供水设施延伸到非建成区）范围内划分物理单元网格。要求各市政专业在已划分的巡检物理网格基础上进行组合， 形成各专业巡检 区域，并与巡检人员相关联。提供网格数据管理及维护功能。2.1.6分析评价子系统分析评价子系统可以利用各环节产生的数据资料进行统计分析， 得出综合统 计报表及评价信息。本子系统为绩效量化考核和综合评价服务，建立分析模型， 根据设定的评价指标对部门、 人员进行综合分析评估。 生成图形、 表格等方式的 评价结果。

19、根据需要建立评价模型设定评价指标由评价人员根据需要调整评价指标，并直接反映到评价结果中 分析评价根据评价模型根据评价指标的设定，利用案件处理过程中的各种数据对部门 或个人进行分析评价，得出评价结果。统计分析利用案件处理过程中的各种数据进行统计分析得出用户需要的统计分析报 表。要求可自定义报表及自定义报表统计方式、方法。2.2用户分析图2-1 用户分析2.3技术需求分析2.3.1总体需求必须严格遵守软件工程开发规范，遵循相关编程开发规范；采用多层的构架，基于组件开发设计，具有相当的灵活性、可操作性和 可扩展性；采用先进的分析与设计技术；要求使用图形开发工具基于数据库进行开发 。2.3.2系统架构

20、以 B/S 、 C/S 相结合的体系架构，实现市政部件的数字化管理。按业务需求，实现 PDA 数据采集、业务受理、调度督办、分析评价、构建 维护等功能，并满足数据交换方案、安全平台认证、资源共享等要求，实现资源 的跨部门共享。2.3.3采用成熟平台利用“数字市政”和各专业公司现有资源，同时针对已有的各类数据，保证 数据类型、数据格式、存储方式、存储位置的多样性。2.3.4市政部件的全生命周期管理系统应该以市政部件的资源管理为核心，实现市政资源的全生命周期管理。 伴随系统运行， 市政部件的任何细微变化都清晰的记录在系统库中， 通过回溯可 以查看任一时间点的市政部件的详细信息、历史原貌。2.3.5

21、PDA+GPS+GIS 技术利用 GPS 定位和手机定位技术，结合公众服务，通过 PDA 实现实时动态的 市政部件监控，利用 GIS 做指挥沙盘，实现巡检、监督、调度指挥的一体化管 理。2.3.6系统构建和维护利用成熟的软件平台， 能够根据特定信息管理需求， 实现快速客户化定制开 发的 PDA 巡检系统构建平台。包括表单设计、业务设计和工作流设计。2.3.7系统集成和数据共享PDA 巡检系统涉及很多相关的硬件产品和软件产品，需要把他们有机的结合起来，实现系统的集成。空间数据、部件数据、部件事件等等都需要在 “数字市政” 范围内实时共享， 不系统对数据的共享要求极高。2.3.8系统日志审计系统要

22、提供用户登录日志写入、 应用程序运行日志写入、 数据库读写日志写 入等功能， 同时可以对系统日志进行查询和管理。 日志写入规则可以通过系统提 供的配置工具由用户自由定义。 要重点保证对数据库重要信息资源读写的日志记 录，通过分析该日志，能够知道何人、何时访问或者修改了何数据。通过系统日志写入，加强系统安全审计，清除系统安全隐患。2.3.9业务安全和信息安全系统需要保证业务安全和信息安全，对进入系统的用户能够实时监控。 业务安全主要指用户身份安全和业务操作安全。 系统要对用户登录进行身份 验证，拒绝非法用户访问本系统； 系统要结合身份验证对登录用户进行业务功能 授权验证， 确保用户的业务操作依据

23、事先拟定的用户访问权限进行， 防止用户越 权访问系统。同时系统具有对进入系统的用户进行集中监控的手段和能力。信息安全主要指信息资源访问安全和自身数据安全。 系统要对用户登录和应 用程序访问进行身份验证和信息资源授权验证， 确保信息资源访问安全； 系统要 提供对数据库自身内容的安全备份和恢复功能，确保数据安全。系统将同时保证数据交换过程中的数据安全。2.4 系统主要性能要求数据录入 2 秒内响应；关键查询响应时间不超过 2 秒；非统计性查询平 均时间为不超过 5 秒，统计查询不超过 20 秒； 工作流程设计应将人工操作减到最少，具备较高的自动化和超时提示， 如：用户报漏等在即将超时和超时时提前给

24、系统用户，并将其事务的优 先级调高，可以优先处理； 采用友好的图形化窗口用户操作界面，支持键盘、鼠标操作，且操作界 面应简洁、直观，有利于简化操作，在文本输入框可支持按回车键跳到 下一个输入框，尽量较少滚动屏幕，提高操作效率； 具备相应容错手段，在一定范围内能拒绝操作人员的误操作，对于不符 合业务规则的操作将不能进行。同时对于大多数的操作都提供取消的功 能；具备较高的容错能力，在出错时具备自动恢复功能； 具备完整的权限管理办法和完善的系统安全机制、用户认证、授权和访 问控制，如日志管理功能等，对每次非法操作产生告警； 必须实现完全模块化设计，支持参数化配置，支持组件及组件的动态加 载；支持多数

25、据源间的访问连接，能方便地与相关的其它应用系统集成在一 起；能为系统管理员提供多种发现系统故障和非法访问的手段，系统维护与 管理可以通过操作界面完成；提供在线帮助功能。2.5系统可扩展性要求系统应考虑系统结构， 功能设计，管理对象， 软硬件平台的可扩展性及软硬 件的负载平衡机制。 要求系统必须具有平滑的扩展能力和灵活易行的二次开发能 力。2.6安全需求分析系统自身应具备统一且完善的安全机制， 保证网络设备的正常运转和系统软 件的安全运行，防止非法用户的闯入，保证系统的数据安全。 系统安全和可靠性设计保障支持 CA 认证。 系统应对所接入的用户进行严格鉴权，包括对用户名称、用户密码和 IP 地址

26、进行验证，用户只能在授权范围内进行相关操作； 系统应具备系统访问日志记录和操作日志记录的功能。第三章总体设计3.1指导思想系统要服务于统一的战略目标 提高房地产的管理和决策水平、 质量与效 率，实现业务管理的科学化、 规范化、信息化。总体设计要做到面向 “数字市政”、 面向行业管理部门的整合需求，用系统工程的思想方法把握 ”数字市政 ”的融合。 系统总体设计以需求为牵引， 注重科学性、 实用性、先进性、可扩展性和安全性， 做到系统的一体化设计和信息资源的集成化管理， 在遵循 “总体规划， 分步实施， 分阶段建设 ”的过程中，不仅能支持现阶段的建设目标，还必须能在此基础上不 断扩充完善， 使之与

27、后阶段的建设共同形成一个统一的整体， 实现系统的总体战 略目标。现阶段的系统设计是以“数字市政”的延伸为出发点， “以业务为导向，以 数据为核心，以集成为重点，以应用为目的 ”作为总的指导思想，统筹规划，严 格管理。并采用面向对象、面向服务、 UML 、 EAI 、组件化和构件化等先进技术 和方法，做到技术先进，系统完整，架构统一，结构开放，可扩展性强、跨平台 应用和网络安全。3.2设计原则为了实现本系统的总体目标， 使招标文件工程建设能够更加合理、 科学，系 统必须安全、可靠、稳定，具备支撑业务办公的能力。为此，在建设招标文件工 程时，必须遵循如下原则：标准化原则系统必须建立在有关国家或行业

28、标准的基础上， 尤其是“城市市政综合监管 信息系统技术规范”，内容包括系统建设的整个过程和相关的要素，如业务数据 的分类编码、属性数据编码、文件系统命名规则、源文件格式、数据字典与接口 规范等等。统一规划原则对系统的整体框架、 软硬件平台必须统一规划； 从系统的角度出发， 综合分 析本系统各子系统之间以及与已有系统的关系，考虑系统的整体性。实用性和易用性原则保证系统实用性， 满足用户的业务需求是系统的基本目标。 系统开发的整体功能应该与“数字市政”的相关业务紧密结合，切实满足相关业务工作的需要。 此外，系统的设计应围绕和针对各类用户进行，以满足各类用户不同需求，并考虑和满足部分业务的实时性要求

29、，要求有较高稳定性。系统结构力求简洁、清晰、 实用。系统设计应坚持 应用与设计无关”、人性化等理念。系统用户只需专心于业 务的处理，而不必顾及技术的设计；充分考虑系统用户的计算机水平和操作习惯， 使界面友好，保证用户的操作简单易行。经济性原则系统的建设要在实用的基础上做到最经济， 充分利用现有各种资源，通盘考 虑整个系统建设过程中人力物力的最优化配置， 要求具有较高的性价比，节约资 金，避免浪费。先进性和前瞻性原则系统所有组成要素均应充分地考虑其技术的先进性。只有将当今最先进的技 术和实际应用相结合，采用目前先进而成熟的技术及设备， 同时，开发或配置先 进、高效实用的系统软件和应用软件， 使整

30、个系统能协调一致地运行，才能获得 最大的系统性能和效益。信息技术发展非常之快，软硬件更新换代迅速，在系统 的设计中要有超前性，必须充分考虑技术的发展趋势。同时在硬件配置和系统设 计中还充分考虑系统的发展和升级，使系统具有较强的扩展能力，处于应用系统 技术领先地位。安全性原则安全可靠性是衡量一个系统的重要标准之一。在确保系统中网络设备稳定、 可靠运行的前提下，还需要考虑软硬件系统整体的容错能力、安全性及稳定性， 使系统出现问题和故障时能迅速地修复。因此需要对系统关键应用和主干设备考 虑有适当的冗余；对数据库中的重要数据提供可靠的备份能力和有效的恢复手 段。系统涉及的信息从对社会完全公开到机密各种

31、密级的数据，系统运行的网络 环境复杂，涉及到多个不同性质的网络间的互联互通， 因此，必须采用严格的安 全保密措施，实行严格的权限管理和操作规程，绝对保证系统的数据安全和系统 安全。循序渐进原则系统的建设要根据现有的条件，有计划有步骤地进行。系统建设初期，应以 满足基本功能、实现常用的迫切的基础功能为主， 以后再逐步进行功能扩展，使 系统功能逐步完善。以数据为核心原则数据是系统生存的基础，是系统具有生命力的保证。因此，在系统建设与实 施过程中必须充分重视和考虑业务数据的标准和规范性，建立起业务数据生产、 更新和维护的规范机制，保证数据的开放性和交互共享性。3.3设计思路根据招标文件的目标，在系统

32、总的指导思想和建设原则的基础上， 我们认为 招标文件的系统建设可以从以下几个方面入手：3.3.1以框架为基石、以业务为主线系统建设应该采取 制定规范一一搭建框架一一业务开发一一系统集成”的 建设模式，在这其中 制定规范、搭建框架”最为重要。具体的建设模式如图 3-1 所示。辭03图3-1开发模式采用这种模式是出于以下几点考虑：系统建设涉及的众多数据、业务、部门。要实现一个统一的系统必须制定完 善的规范，以此作为项目开发的准绳，才能规范整个系统的开发和实施。 系统建设是一个不断发展完善的过程。系统建设要求总体规划、分步实施， 分阶段建设， 需要建立招标文件工程与后续工程良好的衔接关系， 使系统成

33、为一 个统一体。 这就要求在招标文件必须搭建一个好的整体框架， 能够满足业务和功 能不断的调整和扩展，并使后续工程的实施能够而且必须在整体框架中进行。3.3.2框架与平台无关，应用与设计无关，表现与业务分离根据系统的特点， 系统将采用以 B/S 为主的方式为客户提供服务， 而只在少 数特殊需要时采用 C/S 方式，例如：当系统需要提供稳定、 可靠的数据访问和编 辑支持时，尤其是空间数据方面。为此，系统核心框架采用J2ee/.Net 的体系架构（视实际情况而定），分层、模块化设计。J2ee/.Net框架确定了系统的骨架， 是业务运行支撑框架， 使得各种不同的组件能够有序地组织， 并以此为纽带，

34、按 照 EAI 框架提供的系统集成的基本规范，将不同的产品进行整合，并通过业务 总线和数据总线，实现系统数据和业务的集成。J2ee/.Net本身具有良好的跨平台 性， EAI 又具有很强的产品整合能力， 这样的框架是系统长期地稳定和优良的可 扩展性的保证。系统框架与平台的无关， 还表现在框架与产品的绑定是松散的， 不受具体产 品的限制。 系统必须考虑到集成环境的复杂性， 框架应该建立在众多可选产品所 必须具有的基本功能的基础上， 是多个产品的共性， 尽量避免采用某个产品特有 的功能，这样可能导致系统对某个产品产生依赖，从而影响系统的集成与扩展。 因此，系统框架能够支持多种 J2ee/.Net应

35、用服务器、数据库和 GIS等产品。系统设计过程中始终贯穿定制和可配置的思想。 从数据库设计上， 将系统所 用到的管理数据与业务数据分离出来， 业务数据通过管理数据定制出来， 这不仅 表现在业务表单、 业务报表上， 而且表现在业务处理流程、 数据交换流程等方方 面面。这样定制出来的业务具有很强的灵活性， 不需要修改程序就可以实现对业 务表单、业务流程的修改，不仅提高了系统的适应能力，降低系统的维护成本， 而且可以使业务人员更专心于业务的处理， 不必顾及技术的设计。 另外，在系统 中广泛采用可配置的参数进行管理， 实现逻辑和数据的分离， 也有助于提高系统 的灵活性和系统的应变能力。 例如：通过对系

36、统运行参数的进行配置来改善系统 的性能，适应不同的负载需求。 业务流转条件采用参数化的配置可以适应业务规 则发生的变化等等。可配置的管理方式，为系统的随需应变奠定了基础。3.3.3“微内核 ”“插件 ”的结构，促进多种技术集成系统建设需要将多种技术融为一体， 共同完成系统的建设目标。 系统设计不 仅要考虑不同业务不同功能间的集成之外， 还应该考虑不同技术间的集成。 系统 框架采用 “微内核 ”“插件”的结构，将绝对必要的功能封装为系统的内核，其他 功能则依据扩展接口核规则， 通过插件的方式提供， 降低组件间的耦合度， 在更 高的层次上实现软件复用，有助于提高系统的兼容性、扩展性、灵活性、可靠性

37、 和网络支持，实现软件的无缝集成。兼容性：微内核中只包含绝对必要的功能， 这些是通用的和最基本的， 具体 功能的实现必然要利用已有的产品和研发成果， 一个好的产品必然是建立在这些 通用和最基本的东西之上的，这种结构能够兼容更多的产品。扩展性：内核只提供机制，而把实现策略留给插件。可以根据接口，通过开 发插件的方式来解决操作上的不便或增加一些功能。 实现真正意义的 “即插即用 ” 的软件开发。灵活性：系统更容易通过插件组装进行功能定制，根据需要选够功能插件， 定制软件的界面、操作流程，使系统具有伸缩性，满足用户的个性化需求。可靠性：体积较小的内核可以得到更多的测试， 使系统骨架更加稳定、 健壮。

38、 大部分功能都是采用插件实现的， 插件与内核之间有隔离， 所以一旦发生故障不 至于导致系统的崩溃，避免出现 “牵一发而动全身 ”。网络支持： 微内核设计基于消息传送机制， 所以能更容易支持网络通信， 适 应分布式的应用环境。另外，采用这种 “微内核 ”“插件”的结构，也有助于实现系统的分阶段实施， 在招标文件开发出来框架和接口机制， 后续阶段需要对功能进行完善或增加新的 功能，只需要通过对插件的省厅、 国土局部修改和开发新的插件就可以实现， 而 且，插件提供的标准化接口，也能帮助用户进行二次开发。3.3.4借鉴成功的案例，采用工业标准和成熟的主流产品系统建设应该以成熟的应用和技术为基础， 紧跟

39、主流的信息技术， 这样才能 保证系统的稳定性、先进性。系统采用的许多技术，如：J2ee/.Net、 XML 、WebService等都是基于工业标准，在业内得到广泛的应用，技术上已经非常成熟， 资料齐全， 队伍庞大， 有较多的成功案例可供参考， 保证了技术的先进性和稳定 性的有机结合。在业务建模方面， 也需要充分已有相关案例的成功经验， 尤其是国土房产管理方面的，我们在市政、PDA、国土、房产、信息共享、系统集成等方面有许多 的实践（具体可参见商务投标文件），总结和深化了许多业务模型及关键技术， 通过多方案的比较和中和分析，在充分认证的基础上来进行系统设计。 总之，充 分借鉴现有的成功案例，采

40、用工业标准和成熟的主流产品，系统建设将不存在关 键技术上的风险，为系统实现建设目标提供有力的保障。3.4系统总体结构通过对招标文件的理解和系统初步的需求分析，根据我们的建设思路，提出 系统的总体结构，我们从逻辑结构、网络结构和功能体系三个方面进行描述：3.4.1总体逻辑结构系统的总体逻辑结构如图3-2所示，将系统划分为四个层次（数据设施层、 基础平台层、系统支撑平台和功能表现层） 以及标准和规范体系、安全体系和运 行保障机制。具体描述如下：功能表PDA采 集子系统业务受理 子系统调度督办 子系统1现层构建及维护 子系统巡检网格 划分及管理分析评价 子系统系统支撑平台怎食基础平台层OS RDBM

41、S GIS SDE Web Service XML GPRS数据层业务数据库空间数据库-系统运行支撑数据 1图3-2总体逻辑结构数据层数据资源层主要用来存储和管理系统涉及到的所有数据，它不仅包括各类数 据在数据库中的存储内容、组织方式和存储机制，还指明了数据的管理模式和入 库更新机制。业务属性数据是指主要业务需要的基本数据。 这些数据有着良好的结构， 数 据间的关系较为清晰。业务相关数据是指同主要业务有关联的， 或是业务办理过程所需要、 相关的 数据，如：各类附件、批文，单位基础数据，政策法规数据等等。系统管理数据是指系统运行、 业务建模、业务流转， 以及系统管理所必须的 数据，

42、包括系统用户数据、权限数据、运行参数、资源目录、业务规则、系统日 志等等。这些数据是系统最基础的数据， 与业务数据是相互隔离的， 对业务的修 改不会影响到这些数据。元数据是关于数据的数据， 包含数据集的说明或描述。 系统需要建立有效的 元数据组织结构、层次关系和储存体系。 基础平台层基础平台是系统的骨干， 是支撑着整个系统的企业级基础框架。 它采用中间 件技术，为业务应用层提供基础服务， 根据服务的侧重点不同划分为不同的子平 台。 系统支撑平台系统支撑平台是系统的骨干， 是支撑着整个系统的企业级基础框架。 它采用 中间件技术， 为业务应用层提供基础服务， 根据服务的

43、侧重点不同划分为不同的 子平台，主要包括：协同工作引擎、工作流引擎、 地理编码引擎和数据交换引擎。协同工作引擎： 主要通过消息驱动将巡检员、 呼叫中心、 指挥中心等环节关 联起来，达到整个“数字市政”的布式消息协同及功能操作协同。其中，移动终 端与呼叫中心之间采用 GPRS 实现消息收发、数据更新。主要包括消息封装、消息加密、消息发送、消息接收、数据传输、消息解析 等功能模块。工作流引擎：通过对工作流管理工具定制的流程进行解析，自动判断在流程 进行阶段，需要使用什么表单、绑定什么数据、具有什么数据和功能权限、需要 关联什么图层等，同时在业务处理过程中，需要能察看和监控流程的运行情况， 并智能判

44、断流程走向，同时要提供痕迹管理工具， 保留每次业务处理过程的痕迹。地理编码引擎：地理编码引擎为 PDA 采集子系统、业务受理子系统、调度 督办子系统等提供地理编码服务， 也就是将规范化分段描述的地名匹配到一个确 定的点状空间位置，从而快速实现事件定位、地址查找。 该引擎主要包括地址描述、地址解析、地址匹配、部件定位等功能模块。 数据交换引擎：数据交换引擎主要实现子系统之间的数据共享以及外部数据 交换。对于“市政通” 移动终端，本引擎提供接口根据请求的巡检区域对各类数据 进行切割以实现数据（包括部件、基础地形、业务数据）同步（数据传输由协同 工作引擎完成）。对于基础地形数据以及外部业务数据，本引

45、擎提供导入、导出等程序接口。 业务应用层业务应用层说明了系统功能模块的划分， 实现具体的业务应用。 系统在第一 阶段要实现的主要业务有： PDA 采集子系统、业务受理子系统、调度督办子系 统、构建及维护子系统、巡检网格划分及管理和分析评价子系统等。业务应用层采用组件技术进行构建， 将业务逻辑封装为不同的专业组件并与 表现分离。 这些专业组件并不包含业务流转、 空间数据处理等基础功能， 它们需 要与基础平台提供的基础业务组件一起实现业务的功能。 业务对数据的访问和与 外界的数据交换则通过数据交换引擎提供的统一接口完成， 接口实现的细节在这 里被屏蔽，简化了开发工作。 部分专业组件还

46、需要接受基础平台的统一管理和监 控，以确保系统的稳定运行。 标准和规范体系标准和规范体系是指数据标准、 技术规范和管理规范。 需要建立和完善基础 数据分类与编码标准、数据格式、信息发布规范、数据交换协议等统一标准，为 系统数据共享和应用整合奠定基础。 技术开发过程中遵循相关的技术规范， 如代 码编写规范、命名规范、接口规范、二次开发标准等，可以提高软件开发质量， 降低开发周期，增强代码的可重用性和易读性，使软件便于维护，便于扩展。此 外，按照国家有关条例和系统需求， 制订和完善保障系统建设的管理规范和法规 制度，如信息采集、 登记、维护、交换、公开制度及其工作流程； 项目管理制度

47、； 信息交换和共享管理制度等。系统的标准和规范需要具有良好的扩展性， 随着实际应用进行升级更新。 标 准规范体系也必须符合、兼容国家标准、行业标准和地方相关标准。 安全体系和运行保障机制系统采用的主要技术是公钥基础设施（PKI）技术，结合传统的信息安全防 御手段，为系统提供各种安全服务和访问控制， 建立一个通用的、 高性能的安全 平台。系统安全体系包括证书认证服务、 密钥管理及密码服务系统、 授权服务系 统以及基本安全防护系统等， 提供贯穿整个系统的安全服务， 包括身份验证、 不 可否认、数据保密性、时间戳等安全服务功能。安全体系的核心是以统一的 CA 身份认证，实现单点登录，按

48、照授权分级分类进行系统访问。运行保障机制包含支持系统运行的的相关机制、 制度，对系统的管理依靠的 是合理的运行管理机制。 运行管理机制的实施需要配备相关人员和相应的监控管 理功能， 包括面向安全性的用户管理、 权限管理和密码管理； 面向可用性的节点 管理和状态监控； 面向可靠性的数据备份和恢复； 面向性能优化的性能监控； 面 向运行管理机制的信息管理等。3.4.2系统运行框架根据招标文件的需求描述， 我们在总体逻辑结构的基础上， 初步确立的系统 主要运行机制，如图 3-3 所示。系统通过不同系统、不同软硬件环境以及组件间 的业务流、数据流（消息）来实现系统的运转，业务处理、数据交换是推动系统

49、业务流、数据流的引擎，安全机制将确保数据访问的安全。3.5关键技术3.5.1面向对象技术/UML建模技术面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。 与传统的结构化软件开发技术不同， 面向对象技术提出了对象的封装、 继承、多 态性、对象的覆盖等方法，而传统的程序表示方法（如：框图、 NS图等），无法 对面向对象这些新的特性加以描述表达。 因此，面向对象技术的表达、 面向对象 技术的方法论也是面形对象技术必不可少的研究内容之一。UML 是用来描述模型的，它用模型来描述系统的结构或静态特征以及行为 或动态特征。它从不同的视角为系统的架构建模，形成系统的不同视图（view）每一

50、种UML的视图都是由一个或多个图（diagram）组成的。一个图就是系统架 构在某个侧面的表示， 它与其它图是一致的， 所有的图一起组成了系统的完整视 图。 UML 提供了九种不同的图可以分成两大类：一类是静态图，包括用例图、 类图、对象图、组件图、配置图。另一类是动态图，包括序列图、协作图、状态 图、和活动图。在本系统开发中，我们将基于 UML 技术，以面向对象的分析、 设计、开发的方法学指导我们的整个开发活动。 典型的， 我们将以用例图体现我 们对需求的理解，描述系统的功能集合；以类图、对象图、活动图、序列图的形 式体现我们系统的体系结构； 以组件图展示系统各个有机组成部分， 以展开图表

51、达出我们对系统的部署想法。在本标书的写作上，我们也大量使用 UML 来描述 用例和业务流程。3.5.2B/S 为主， C/S 相辅相成的多层分布式技术随着中间件与 Web 技术的发展，三层或多层分布式应用体系越来越流行。 在这种体系结构中，客户机只存放表示层软件，应用逻辑包括事务处理、监控、 信息排队、Web服务等采用专门的中间件服务器，后台是数据库。在多层分布式 体系中，系统资源被统一管理和使用， 用户可以通过门户透明地使用整个系统的 资源。采用多层分布式技术具有安全性、稳定性、易维护、快速响应和扩展灵活 等特点。但是， C/S 结构也有自己的特点，例如可以提供数据的高效访问、实现 复杂的空

52、间数据编辑等。 所以，系统采用 B/S 结构为主， 以满足大量用户对系统 的信息访问的要求，而对于复杂的操作功能采用 C/S结构实现，以满足少量特殊 用户的要求。3.5.3 中间件技术中间件这一概念是在应用架构（Application Architecture）的发展历程中，伴 随着三层（3-Tiers）或多层（n-Tiers）结构应运而生的。它是为了解决交易问题、 应用逻辑共用问题和松偶合问题，而在客户 /表示层和服务器 /数据层之间引进了 中间层，这就是中间件。中间件处于操作系统软件与用户的应用软件的中间， 能够使应用软件相对独 立于计算机硬件和操作系统平台， 为当今的大型分布式应用搭起了

53、一个标准的平 台，把大中型分布式系统和技术组合在一起，实现大中型应用软件系统的集成。 中间件也保证了系统的异构性、 扩展性和分布运行的可行性。 在系统建设过程中， 大量采用了中间件技术， 最主要的是：具有动态表单技术和复杂业务流程建模的 工作流中间件、以队列（Queue）和发布定阅（PUB/SUB）作为消息传输机制的消息服务引擎。3.5.4 组件化、构件化开发技术软件开发的重用手段从最初的源代码、目标代码、类库（面向对象技术） ， 发展到今天的组件式开发技术。 组件是具有某种特定功能的软件模块， 它几乎可 以完成任何任务。 组件以其较高的可重用性产生了一种崭新的软件设计思路， 它 把硬件以芯片

54、为中心的工艺思想恰如其分地融合于软件的分析、设计和施工之 中，组件的构件化就将多个组件组织在一起形成不同的构件，随着构件的积累， 利用这些构件开发软件就像搭积木一样容易。 构件技术是迄今为止最优秀也是发 展最快的一种软件重用技术， 它比较彻底地解决了软件开发中存在的重用性、 适 应性差和周期长等问题。在系统的开发中， 我们将坚持组件化、 构件化的开发技术， 通过开发不同的 组件、接口和构件，实现软件的重用和快速开发。3.5.5XML 和 Web Service 技术XML（eXtensible Markup Language，可扩展标识语言）是ISO （国际标准化组 织）所制订的 SGML （

55、Standard Generalized Markup Language 通用语言标识标 准）的一个精简集。 它是用于定义其它标识语言的一种元语言， 它用于描述信息 的各种标识都可以由设计者自行建立， 以强化特定专业数据的结构和关联。 由于 XML 具有数据来源的多样性和多种应用的灵活性、柔韧性和适应性，内容与形 式的分离，它具有开放的标准，有助于实现数据的标准化、结构化。因此在数据 交换和协议描述上有着先天的优势，我们在系统中将大量采用 XML 语言来描述 信息，并作为数据交换的基本格式。Web 服务是使应用程序可以用与平台无关和与编程语言无关的方式进行相 互通信的一项技术。 Web 服务是

56、一个软件接口，它描述了一组操作，可以在网 络上通过标准化的 XML 消息传递来访问这组操作。它使用基于 XML 语言的 协议来描述要执行的操作或者要与另一个 Web 服务交换的数据。 一组用这种方 式相互作用的 Web 服务在面向服务的体系结构（ Service-Oriented Architecture， SOA ）中定义了特殊的Web服务应用程序。在系统对外提供服务，系统数据的 发布与共享可采用Web Service技术，实现数据的共享和异构系统的整合。3.6系统接口设计系统接口是系统不同应用之间业务和数据发生联系的纽带，也是不同组件间相互访问的入口。系统总体结构将子系统之间的互操作封装到

57、统一的电子政务基 础平台中，从而简化了接口设计，但电子政务基础平台的接口设计却成为系统成 败的关键，所以我们设计时必须着重考虑，考虑的方面包括通讯模式、数据格式 和交互协议。具体如下：通讯模式接口的基本形态是由它所支持的通信模式决定的。目前主要有两种基本模式：同步消息传送同步消息传送接口定义了发送者等待响应时被调用的方法的信号。消息可能包含事务上下文，并提供安全授权信息。异步消息传送同步消息传送接口将消息被传送到一个消息队列中，发送者和接受者独立决定处理消息的事务和安全环境。接收者可能收到由发送者详细指定地址的消息，图3-4异步通讯系统采用这两种通讯模式，支持多种消息的传送模式，以满足不同的应用的 要求。点对点传输发送方将消息放入消息队列，接收方从队列中接受消息。路由转发消息发往不相邻的节点，而是经过路由节点转发。发布/订阅订阅者可以根据自己的需要订阅某些主题， 然后在适当的时间从