康拓普舆情监控系统概要设计说明书文档格式.docx
- 文档编号:17632468
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:31
- 大小:580.82KB
康拓普舆情监控系统概要设计说明书文档格式.docx
《康拓普舆情监控系统概要设计说明书文档格式.docx》由会员分享,可在线阅读,更多相关《康拓普舆情监控系统概要设计说明书文档格式.docx(31页珍藏版)》请在冰豆网上搜索。
MVC模式
MVC是Model-View-Controller的简写。
"
Model"
代表应用的业务逻辑(通过JavaBean,ActionForm实现)。
View"
是应用的表示面(由JSP页面产生)。
Controller"
是提供应用的处理过程控制(一般是一个Servlet),通过这种设计模型把应用逻辑,处理过程和显示逻辑分成不同的组件实现。
Struts
Struts是采用JavaServlet/JavaServerPages技术,开发Web应用程序的开放源码的FrameWork。
J2EE
全称是Java2PlatformEnterpriseEdition,它是由sun公司领导、各厂商共同制定并得到广泛认可的工业标准。
1.2系统的上下文联系
本系统暂无与其他系统的数据交换功能。
1.3系统的体系结构
该系统采用Browser/Server结构,客户端使用浏览器访问系统,服务器端使用中间件(Weblogic)管理企业组件(EJB),同时作为WebApplication服务器。
康拓普舆情监控系统系统的核心功能管理子系统结构如下图:
pomonitor目录下的系统结构
系统根据PDCA循环的思想规划功能模块,对应于五个大的模块:
basicData、engine、poManagement、stat、logger。
系统通过统一的接口框架与其他信息系统进行数据交互。
1.4子系统概述
根据需求规格说明书将系统划分为以下5个主要功能模块,包括:
基础数据管理、自动采集、舆情管理、统计分析、采集日志五个模块。
1.5关键的设计概念
1.5.1系统采用技术简介
1.5.1.1MVC模式简介
MVC英文即Model-View-Controller,即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离,这样一个应用被分成三个层——模型层、视图层、控制层。
它们分别担任不同的任务,下图显示了这几个模块各自的功能以及它们之间的相互关系。
视图
视图(View)代表用户交互界面,对于Web应用来说,可以概括为HTML界面,但有可能为XHTML、XML和Applet。
随着应用的复杂性和规模性,界面的处理也变得具有挑战性。
一个应用可能有很多不同的视图,MVC设计模式对于视图的处理仅限于视图上数据的采集和处理,以及用户的请求,而不包括在视图上的业务流程的处理。
业务流程的处理交予模型(Model)处理。
比如一个订单的视图只接受来自模型的数据并显示给用户,以及将用户界面的输入数据和请求传递给控制和模型。
模型
模型(Model)就是业务流程/状态的处理以及业务规则的制定。
业务流程的处理过程对其它层来说是黑箱操作,模型接受视图请求的数据,并返回最终的处理结果。
业务模型的设计可以说是MVC最主要的核心。
MVC设计模式告诉我们,把应用的模型按一定的规则抽取出来,抽取的层次很重要,这也是判断开发人员是否优秀的设计依据。
抽象与具体不能隔得太远,也不能太近。
MVC并没有提供模型的设计方法,而只告诉你应该组织管理这些模型,以便于模型的重构和提高重用性。
我们可以用对象编程来做比喻,MVC定义了一个顶级类,告诉它的子类你只能做这些,但没法限制你能做这些。
业务模型还有一个很重要的模型那就是数据模型。
数据模型主要指实体对象的数据保存(持续化)。
比如将一张订单保存到数据库,从数据库获取订单。
我们可以将这个模型单独列出,所有有关数据库的操作只限制在该模型中。
控制器
控制(Controller)可以理解为从用户接收请求,将模型与视图匹配在一起,共同完成用户的请求。
划分控制层的作用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,可以完成什么样的用户请求。
控制层并不做任何的数据处理。
例如,用户点击一个连接,控制层接受请求后,并不处理业务信息,它只把用户的信息传递给模型,告诉模型做什么,选择符合要求的视图返回给用户。
因此,一个模型可能对应多个视图,一个视图可能对应多个模型。
MVC处理过程
首先控制器接受用户的请求,并决定应该调用哪个模型来进行处理;
然后模型根据用户请求进行相应的业务逻辑处理,并返回数据;
最后控制器调用相应的视图来格式化模型返回的数据,并通过视图呈现给用户。
MVC的优点
首先,模型、视图与控制器的分离,使得一个模型可以具有多个显示视图。
如果用户通过某个视图的控制器改变了模型的数据,所有其它依赖于这些数据的视图都应反映到这些变化。
因此,无论何时发生了何种数据变化,控制器都会将变化通知所有的视图,导致显示的更新。
这实际上是一种模型的变化-传播机制。
其次,模型是自包含的,与控制器和视图保持相对独立,所以可以方便地改变应用程序的数据层和业务规则。
此外,控制器提高了应用程序的灵活性和可配置性。
MVC的应用范围
适用MVC需要精心的计划,由于它的内部原理比较复杂,所有需要花费一些时间去理解它。
将MVC运用导应用系统中,会带来额外的工作量,增加应用的复杂性,所以MVC不适合小型应用程序。
但对于开发存在大量用户界面,并且业务逻辑复杂的大型应用程序,MVC将会使软件在健壮性、代码重用和结构方面上一个新的台阶。
尽管在最初构建MVC框架时会花费一定的工作量,但从长远的角度来看,它会大大提高后期软件开发的效率。
MVC与J2EE架构的关系
MVC与J2EE架构的对应关系是:
View处于WebTier或者说是ClientTier,通常是JSP/Servlet,即页面显示部分。
Controller也处于WebTier,通常用Servlet来实现,即页面显示的逻辑部分实现。
Model处于MiddleTier,通常用服务端的javaBean或者EJB实现,即业务逻辑部分的实现。
MVC与Struts的关系
MVC模式是一种架构模式,其实需要其他模式协作完成。
在J2EE模式目录中,通常采用servicetoworker模式实现,而servicetoworker模式可由集中控制器模式,派遣器模式和PageHelper模式组成。
而Struts只实现了MVC的View和Controller两个部分,Model部分需要开发者自己来实现,Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。
1.5.1.2Struts2简介
对于开发Web应用,要从头设计并开发出一个可靠、稳定的框架并不是一件容易的事。
幸运的是,随着web开发技术的日趋成熟,在web开发领域出现了一些现成的优秀的框架,开发者可以直接使用他们,Struts就是一种不错的选择,它是基于MVC的Web应用框架。
Struts2以WebWork优秀的设计思想为核心,吸收了Struts1的部分有点,建立了一个兼容WebWork和Struts1的MVC框架,Struts2的目标是希望可以让原来使用Struts1、WebWork的开发人员,都可以平稳过度到使用Struts2框架。
Struts2的体系与Struts1体系的差别非常大,因为Struts2使用了WebWork的设计核心。
Struts2大量使用拦截器来处理用户请求,从而允许用户的业务逻辑控制器与ServletAPI分离。
下图是Struts2的体系结构。
Struts2体系结构图
一个请求在Struts2框架中的处理大概分为以下几个步骤:
1.客户端初始化一个指向Servlet容器(例如Tomcat)的请求;
2.这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助,例如:
SiteMeshPlugin);
3.接着FilterDispatcher被调用,FilterDispatcher询问ActionMapper来决定这个请求是否需要调用某个Action;
4.如果ActionMapper决定需要调用某个Action,FilterDispatcher把请求的处理交给ActionProxy;
5.ActionProxy通过ConfigurationManager询问框架的配置文件,找到需要调用的Action类;
6.ActionProxy创建一个ActionInvocation的实例。
7.ActionInvocation实例使用命名模式来调用,在调用Action的过程前后,涉及到相关拦截器(Intercepter)的调用。
8.一旦Action执行完毕,ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。
返回结果通常是一个需要被表示的JSP或者FreeMarker的模版,也可能是另外的一个Action链。
1.5.1.3Spring简介
Spring是一个开源框架,是为了解决企业应用程序开发复杂性而创建的。
它是一个分层架构,由7个定义良好的模块组成。
下图是Spring框架的7个模块示意图
Spring7个模块示意图
组成Spring框架的每个模块(或组件)都可以单独存在,或者与其他一个或多个模块联合实现。
每个模块的功能如下:
●核心容器:
核心容器提供Spring框架的基本功能。
核心容器的主要组件是BeanFactory,它是工厂模式的实现。
BeanFactory使用控制反转(IOC)模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
●Spring上下文:
Spring上下文是一个配置文件,向Spring框架提供上下文信息。
Spring上下文包括企业服务,例如JNDI、EJB、电子邮件、国际化、校验和调度功能。
●SpringAOP:
通过配置管理特性,SpringAOP模块直接将面向方面的编程功能集成到了Spring框架中。
所以,可以很容易地使Spring框架管理的任何对象支持AOP。
SpringAOP模块为基于Spring的应用程序中的对象提供了事务管理服务。
通过使用SpringAOP,不用依赖EJB组件,就可以将声明性事务管理集成到应用程序中。
●SpringDAO:
JDBCDAO抽象层提供了有意义的异常层次结构,可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。
异常层次结构简化了错误处理,并且极大地降低了需要编写的异常代码数量(例如打开和关闭连接)。
SpringDAO的面向JDBC的异常遵从通用的DAO异常层次结构。
●SpringORM:
Spring框架插入了若干个ORM框架,从而提供了ORM的对象关系工具,其中包括JDO、Hibernate和iBatisSQLMap。
所有这些都遵从Spring的通用事务和DAO异常层次结构。
●SpringWeb模块:
Web上下文模块建立在应用程序上下文模块之上,为基于Web的应用程序提供了上下文。
所以,Spring框架支持与JakartaStruts的集成。
Web模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。
●SpringMVC框架:
MVC框架是一个全功能的构建Web应用程序的MVC实现。
通过策略接口,MVC框架变成为高度可配置的,MVC容纳了大量视图技术,其中包括JSP、Velocity、Tiles、iText和POI。
1.5.1.4元搜索引擎简介
元搜索引擎就是通过一个统一的用户界面帮助用户在多个搜索引擎中选择和利用合适的(甚至是同时利用若干个)搜索引擎来实现检索操作,是对分布于网络的多种检索工具的全局控制机制。
一个真正的元搜索引擎由三部分组成,即:
检索请求提交机制、检索接口代理机制、检索结果显示机制。
“请求提交”负责实现用户“个性化”的检索设置要求,包括调用哪些搜索引擎、检索时间限制、结果数量限制等。
“接口代理”负责将用户的检索请求“翻译”成满足不同搜索引擎“本地化”要求的格式。
“结果显示”负责所有元搜索引擎检索结果的去重、合并、输出处理等。
元搜索引擎的出现,对于那些需要连续地使用不同的搜索引擎重复相同的检索的人来说,是一个福音。
使用元搜索引擎同时对几个搜索引擎进行检索,获得分级编排的检索结果。
元搜索引擎的原理
我们可将元搜索引擎看成具有双层客户机/服务器结构的系统。
用户向元搜索引擎发出检索请求,元搜索引擎再根据该请求向多个搜索引擎发出实际检索请求,搜索引擎执行元搜索引擎检索请求后将检索结果以应答形式传送给元搜索引擎,元搜索引擎将从多个搜索引擎获得的检索结果经过整理再以应答形式传送给实际用户。
当然,某些元搜索引擎具有略微不同的机制。
发展方向及前景
元搜索引擎是为弥补传统搜索引擎的不足而出现的一种辅助检索工具,有着传统搜索引擎所不具备的许多优势。
但是,元搜索引擎依赖于数据库选择技术、文本选择技术、查询分派技术和结果综合技术等。
用户界面的改进、调用策略的完善、返回信息的整合以及最终检索结果的排序,仍然是未来元搜索引擎研究的重点。
1.5.1.5结构化采集技术(爬虫+结构化内容识别)
网络爬虫
网络爬虫,是一种自动获取网页内容的程序,是搜索引擎的重要组成部分。
通俗的讲,也就是通过源码解析来获得想要的内容。
结构化内容识别技术
结构化内容识别技术能够从文本型网页中识别出不同字段的内容,例如作者、发布时间、联系电话等,并进行数据存储,以满足多维度的信息挖掘和统计需要。
1.5.2系统应用的字符编码
无论是对Web应用的本地化还是国际化,都会涉及到字符编码转换问题,Web应用的各种可能的输入和输出,当数据流的源与目的地使用不同的字符编码时,就需要对字符编码进行正确的转换。
(Web应用的输入流和输出流)
1、处理Http请求数据编码
默认情况下,IE浏览器发送请求时采用”ISO-8859-1”字符编码,如果Web应用程序要正确的读取用户发送的中文数据,则需要进行编码转换。
系统通过公用的字符编码转换函数来进行处理
2、处理XML配置文件编码
在XML文件中包含有中文,将XML文件字符编码设为“GB2312”,这样在Java程序加载和解析XML文件时无需再进行编码转换。
3、处理资源文件编码
定义资源文件
创建资源文件
按照配置文件,创建对应的资源文件ApplicationResources-impproject.properties
对资源文件进行编码转换
编码转化采用JKD中提供的native2ascii命令,,在DOS下执行如下命令,将生成按照GB2312编码的中文资源文件ApplicationResources-impproject_zh_CN.properties
当Web客户的Locale为中文时,系统框架将自动选择来自
ApplicationResources-impproject_zh_CN.properties文件的消息文本。
1.5.3系统主要设计模式
1.5.3.1装饰模式(Decorator)
模式说明
装饰模式以对客户端透明的方式来扩展对象功能,是继承关系的一个替换方案。
它能够动态的给某个对象添加一些额外职责。
在下面的情况下使用:
需要扩展一个类的功能,或者给一个类增加额外责任;
需要动态地给对象增加新的功能;
在使用继承的方式增加功能时,由于增加的功能太多,这些功能经过排列组合会产生大量的类,以至于不现实;
在本系统中装饰模式主要应用于为表现层服务,对请求显示的数据作预处理,例如系统中有一个工程合同列表页面,用来显示合同信息,对于某些特殊字段的显示需要做特殊处理,如项目总额,需以特定格式(保留两位小数,千分位加逗号分隔),我们采用在Form和VO之间增加一个装饰层来进行预处理。
如下图所示,表现层Form读取的VO对象属性,都是经过Decorator类加工过的。
代码实现
ContractVO如下图
在Decorator类中,getAmount格式化了项目的总金额,getSubmitDate对日期进行处理,代码如下:
在EngineeringContractDetailForm类中引入装饰类对象:
1.5.3.2门面模式(Facade)
模式说明:
门面为子系统中的一组接口提供一个一致的界面,它定义了一个高级接口,这个接口使得子系统更加容易使用,在系统设计过程中,通常将一个系统划分为若干个子系统以降低系统的复杂性,同时还要使子系统之间的通信和相互依赖关系达到最小,子系统之间通过统一的接口进行访问,使用门面模式,可以增加子系统的独立性,在多层应用系统设计时,可以给每以层定义一个接口,层与层之间的通信通过门面模式进行。
在系统中,通过SessionBean来封装业务逻辑,在多个EntityBean或DAO方法中对数据层的操作,都放在一个SessionBean方法内进行处理,在实现事物一致性的同时,让服务调用更加方便。
例如,一个新增合同的业务,需要执行一系统操作,如通过ProjectBean检查项目是否存在,通过BudgetBean检查合同是否在项目预算范围内,通过ContractBean新增合同数据表。
我们在业务层中添加一个门面类ContractFacadeBean,通过方法insertContract()将这些新增合同的这些操作全都封装进来,外部用户只要调用门面类的insertContract()就可以实现所有的功能,系统实现如下图所示:
1.5.3.3适配器模式(Adapter)
适配器模式又称包装器模式(Wrapper),它将接口转换成用户希望的另外一个接口,使得原来那些由于接口不兼容而不能工作在一起的那些类可以在一起工作。
适配器模式需要有Adaptee(被适配者)和Adaptor(适配器)以及Target(目标)三个身份。
在本系统中的工作流中对流程的上报和审核控制采用了适配器模式,以适应多个不同类型的流程。
适配器模式的基本结构如下:
1.5.3.4工厂模式(Factory)
工厂模式是类的创建模式,由一个工厂类根据传入的参量决定创建出哪一种产品类的实例.
工厂模式涉及到工厂角色,抽象产品角色以及具体产品角色等三个角色
(1)工厂类角色(Creator):
担任这个角色的是工厂方法模式的核心,含有与应用紧密相
关的商业逻辑.工厂类在客户端的直接调用下创建产品对象,它往往由一个具体类实现
(2)抽象产品角色(Product):
担任这个角色的类是由工程方法模式所创建的对象的父类,或它们共同拥有的接口.抽象产品角色可以用一个接口或抽象类实现.
(3)具体产品角色(ConcreteProduct)角色:
工程方法模式所创建的任何对象都是这个角色的实例,具体产品角色是由一个具体类实现.
优点:
工厂模式的核心是工厂类.这个类含有必要的判断逻辑,可以决定在什么时候创建,哪一个产品类的实例.而客户端则可以免除直接创建产品对象的责任,而仅仅负责"
消费"
产品.工厂模式通过这种做法实现了对责任的分割.
缺点:
(1)当产品类有复杂的多层次等级结构时,工厂类只有它自己.以不变应万变,就是模式的缺点.
(2)这个工厂类集中了所有的产品创建逻辑,形成一个无所不知的全能类,有人把这种类叫做上帝类(GodClass).如果这个全能类不能正常工作了,整个程序都会受到影响.
(3)将这么多的逻辑集中放在一个类里面的另外一个缺点是,当产品类有不同的接口种类时,工厂类需要判断在什么时候创建某种产品.这种对时机的判断和对哪一种具体产品的判断逻辑混合在一起,使得系统在将来进行功能扩展时较为困难.
系统根据传入的适配器名字,创建新的适配器产品,AdapterFactoryPM是工厂类角色,ImpAdviceEntryAdapter是具体产品角色,EntryAdapter是抽象产品角色,角色关系如下图所示:
代码实现:
1.5.3.5反转模式(IOC)
IoC(InversionofControl)即控制反转。
IoC是一种用来解决组件(实际上也可以是简单的Java类)之间依赖关系、配置及生命周期的设计模式,其中对组件依赖关系的处理是IoC的精华部分。
IoC的实际意义就是把组件之间的依赖关系提取(反转)出来,由容器来具体配置。
这样,各个组件之间就不存在hard-code的关联,任何组件都可以最大程度的得到重用。
运用了IoC模式后我们不再需要自己管理组件之间的依赖关系,只需要声明由容器去实现这种依赖关系。
就好像把对组件之间依赖关系的控制进行了倒置,不再由组件自己来建立这种依赖关系而交给容器去管理。
1.5.3.6责任链模式(ChainofResponsibility)
责任链模式(CoR)建议发出请求的对象与可能处理这个请求的对象集合之间是低耦合的(set
of
potential
request
handler
objects)。
在有不止一个对象可以处理或实现(fulfill)客户请求的时候,责任链模式(CoR)认为顺序地给每一个对象一次处理请求的机会。
在这种情况下应用责任链模式(CoR),把每一个可能处理请求的对象以链表的形式组织起来,在链表中,每一个对象有一个指向下一个对象的指针(Pointer)。
在链表中的第一个对象接受请求并且决定是否处理它,或者把它传递给下一个对象。
请求一个接一个地遍历(flow
through)链表中的所有对象,直到请求被其中的一个对象处理或者因到达链表尾而没有被处理。
下面是责任链模式(CoR)一些重要的特征:
(1)
可能处理请求的对象集合(set
objects)以及它们在链表中的顺序是由客户端根据现应用的状态在运行时动态决定的。
(2)
客户端根据现在的状态,对于不同的请求类型,可以拥有不同的可能处理请求的对象集合(set
一个处理请求的对象也可以根据客户应用的状态和请求类型,把请求传递给不同的处理对象。
为了使这些交互简单,所有的可能处理请求的对象应提供一致的接口。
在JAVA中,不同处理对象可以实现一个共同的接口或者继承同一个抽象的父类来实现。
(3)
客户对象初始化请求,或者在不知道这些对象是否能处理这个请求的情况下初始化任何可能处理请求的对象。
也就是说,客户对象和在处理链表中的处理对象都不需要知道到底哪个对象去处理这个请求。
(4)
请求不能保证被处理。
也就是,在没有处理的情况
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 康拓普 舆情 监控 系统 概要 设计 说明书
![提示](https://static.bdocx.com/images/bang_tan.gif)