eGov电子政务系统
概要设计说明书
1引言
1.1编写目的
此文档对eGov电子政务系统概要设计进行说明。
预期的读者有 (甲方)的需求提供者、项目负责人、相关技术人员等，北京亚思晟商务科技有限公司(乙方)的项目组成员，包括项目经理、客户经理、分析设计开发测试等人员。
1.2背景
eGov电子政务系统是基于互联网的应用软件.在研究中心的网上能了解到已公开发布的不同栏目(如新闻, 通知等)的内容. 各部门可以发表栏目内容(如新闻, 通知等)，有关负责人对需要发布的内容进行审批。其中：有的栏目(如新闻)必须经过审批才能发布，有的栏目(如通知)则不需要审批就能发布。系统管理人员对用户及其权限进行管理。
1.3定义
无
1.4参考资料
eGov电子政务系统需求规格说明书
eGov电子政务系统详细设计说明书
2总体设计
2.1需求规定
eGov电子政务系统按模块可以分成三部分，一是一般用户浏览的内容管理模块, 二是系统管理，三是内容和审核管理，而它们各自又有具体的小模块组成。具体需求见eGov电子政务系统需求规格说明书。
2.2运行环境
操作系统：Win2003/XP, Linux
WEB服务器:Tomcat 5.5以上
数据库服务器:MySQL5.0以上,能够处理数据并发访问，访问回馈时间短。
2.3基本设计概念
1．系统整体方案
（1）eGov电子政务系统主要特性
我们从以下五个方面确定目标系统特性如下：
● 用户界面的复杂度：数据的静态显示/可定制视图（customizable view）
● 用户界面的部署约束：基于独立的桌面电脑或专用工作站的浏览器
● 用户的数量和类型：组织内的日常使用者，总共几百人
● 系统接口类型：通过HTTP协议提供服务，未来可以使用SOAP的SOA技术
● 性能：主要是独立的数据更新，有少量并发处理
从上述特性我们可以判断eGov电子政务系统属于中大型项目，因此我们使用基于Struts-Spring-Hibernate框架的分层架构设计方案。
（2）架构分层
在eGov电子政务项目架构设计中，我们使用分层模式。具体地说，我们将eGov电子政务系统应用在职责上分成3层：表示层（Presentation Layer）、持久层（Persistence Layer）和业务层（Business Layser）。每个层在功能上都应该是十分明确的，而不应该与其他层混合。每个层要相互独立，通过一个通信接口而相互联系。
（3）模式和框架使用：
在分层设计基础上，我们将使用设计模式和框架，这些是可以重用的资产。
1）MVC模式
MVC模式就是一种很常见的设计模式。所谓的MVC模式，即模型—视图—控制器（model—
view--controller）模式。其结构图如下：
图4-1  MVC架构图
1、Model端
在MVC中，模型是执行某些任务的代码，而这部分代码并没有任何逻辑决定用户端的表示方法。Model只有纯粹的功能性接口，也就是一系列的公共方法，通过这些公共方法，便可以取得模型端的所有功能。
2、View端
在MVC模式里，一个Model可以有几个View端，而实际上多个View端是使用MVC的原始动机。使用MVC模式可以允许多于一个的View端存在，并可以在需要的时候动态注册所需要的View.
3、Controller端
MVC模式的视图端是与MVC的控制器结合使用的。当用户端与相应的视图发生交互时，用户可以通过视窗更新模型的状态，而这种更新是通过控制器端进行的。控制器端通过调用模型端的方法更改其状态值。与此同时，控制器端会通知所有注册了的视图刷新用户界面。
那么，使用MVC模式有哪些优点呢？MVC通过以下三种方式消除与用户接口和面向对象的设计有关的绝大部分困难：
1、控制器通过一个状态机跟踪和处理面向操作的用户事件。这允许控制器在必要时创建和破坏来自模型的对象，并且将面向操作的拓扑结构与面向对象的设计隔离开来。这个隔离有助于防止面向对象的设计走向歧途。
2、MVC将用户接口与面向对象的模型分开。这允许同样的模型不用修改就可使用许多不同的界面显示方式。除此之外，如果模型更新由控制器完成，那么界面就可以跨应用再使用。
3、MVC允许应用的用户接口进行大的变化而不影响模型。每个用户接口的变化将只需要对控制器进行修改，但是控制器包含很少的实际行为，它是很容易修改的。
面向对象的设计人员在将一个可视化接口添加到一个面向对象的设计中时必须非常小心，因为可视化接口的面向操作的拓扑结构可以大大增加设计的复杂性。
MVC设计允许一个开发者将一个好的面向对象的设计与用户接口隔离开来，允许在同样的模型中容易地使用多个接口，并且允许在实现阶段对接口做大的修改而不需要对相应的模型进行修改页面设计说明
2）框架
根据项目特点，我们使用三种开源框架：表示层用Struts；业务层我们用Spring；而持久层则用Hibernate。如图1-1所示。
图1-1  Struts-Spring-Hibernate架构
1  表示层
一般来讲，一个典型的Web应用的前端应该是表示层。这里可以使用Struts框架。
下面是Struts所负责的：
管理用户的请求，做出相应的响应
提供一个流程控制器，委派调用业务逻辑和其他上层处理
处理异常
为显示提供一个数据模型
用户界面的验证
以下内容，不该在Struts表示层的编码中经常出现，与表示层无关的。
与数据库直接通信
与应用程序相关联的业务逻辑及校验
事务处理
在表示层引入这些代码，则会带来高耦合和难以维护的后果。
2  持久层
典型的Web应用的后端是持久层。开发者总是低估构建他们自己的持久层框架的挑战性。系统内部的持久层不但需要大量调试时间，而且还经常因为缺少功能使之变得难以控制。这是持久层的通病。幸运的是，有几个对象/关系映射（Object/Relation Mapping，ORM）开源框架很好地解决了这类问题，尤其是Hibernate。Hibernate为Java提供了持久化机制和查询服务，它还给已经熟悉SQL和JDBC API的Java开发者创造了一个学习桥梁，使他们学习起来很方便。Hibernate的持久对象是基于POJO（Plain Old Java Object）和Java集合（collections）的。此外，使用Hibernate并不妨碍你正在使用的IDE（Integrated Development Enviroment）。
下面是Hibernate所负责的：
如何查询对象的相关信息。
Hibernate是通过一个面向对象的查询语言（HQL）或者正则表达的API来完成查询的。HQL非常类似于SQL，只是把SQL里的table和columns用Object和它的fields代替。HQL语言容易理解且文档也做得很好。HQL是一种面向对象查询的自然语言，很容易就能学会它。
如何存储、更新、删除数据库记录。
如Hibernate这类的高级ORM框架支持大部分主流数据库，并且支持父表/子表（Parent/child）关系、事务处理、继承和多态。
3  业务层
一个典型Web应用的中间部分是业务层或者服务层。从编码的视角来看，这层是最容易被忽视的一层。我们往往在用户界面层或持久层周围看到这些业务处理的代码，这其实是不正确的。因为它会造成程序代码的高耦合，这样一来，随着时间推移，这些代码将很难维护。幸好，针对这一问题有好几种框架（Framework）存在。最受欢迎的两个框架是Spring和PicoContainer。这些也被称为轻量级容器（micro container），它们能让你很好地把对象搭
配起来。这两个框架都着手于“依赖注入”（dependency injection）（还有我们知道的‘控制反转’Inversion of Control=IoC）这样的简单概念。这里我们将关注于Spring的依赖注入和面向方面编程。另外，Spring把程序中所涉及到的包含业务逻辑和数据存取对象（DataAccess Object）的Objects——例如transaction management handler（事务管理控制）、Object Factoris（对象工厂）、service objects（服务组件）——都通过XML来配置联系起来。
下面是业务层所负责的：
处理应用程序的业务逻辑和业务校验
管理事务
提供与其他层相互作用的接口

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。