基于MVC模式的新闻发布系统的设计研究.docx

更多企业学院：...../Shop/
《中小企业管理全能版》
183套讲座+89700份资料
...../Shop/40.shtml
《总经理、高层管理》
49套讲座+16388份资料
...../Shop/38.shtml
《中层管理学院》
46套讲座+6020份资料 
...../Shop/39.shtml
《国学智慧、易经》
46套讲座
...../Shop/41.shtml
《人力资源学院》
56套讲座+27123份资料
...../Shop/44.shtml
《各阶段员工培训学院》
77套讲座+ 324份资料
...../Shop/49.shtml
《员工管理企业学院》
67套讲座+ 8720份资料
...../Shop/42.shtml
《工厂生产管理学院》
52套讲座+ 13920份资料
...../Shop/43.shtml
《财务管理学院》
53套讲座+ 17945份资料 
...../Shop/45.shtml
《销售经理学院》
56套讲座+ 14350份资料
...../Shop/46.shtml
《销售人员培训学院》
72套讲座+ 4879份资料
...../Shop/47.shtml

基于MVC模式的新闻发布系统的
设计与实现

作者姓名：吴秋生 专业班级：2003070505

摘 要：新闻发布系统是公司内容管理系统的主要应用之一，是公司信息化建设和实现电子商务的重要途径。它的基本思想是分离新闻信息的内容和表现形式，以期提高新闻发布效率。本设计采用基于UML用例驱动对象建模的ICONIX项目管理方法，应用MVC三层设计模式，实现一个可以完成新闻栏目和新闻信息的添加、修改、删除以及新闻查看功能的新闻发布系统。

关键字：ICONIX；MVC；Servlet；JavaBean；新闻发布

Design and Implementation of the News Publishing System based on MVC model

Abstract: The news publishing system is the main application of Content Management System in a company, also it is an important approach of the companies’ information construction and the realization of E-Commerce. The separation of the contents and views of information in the news is it is the basic idea, so as to advance the efficiency of the news. Through applying the project management methods of ICONIX, which is based on use case driven object modeling with UML, and MVC design pattern, this paper implement a news publishing system with functions of adding, editing, deleting the category and news, and browsing news message.

Keywords：ICONIX; MVC; Servlet; JavaBean; News Publishing
目 录
第1章 前言 1
第2章 系统概述 2
2.1 项目管理方法 2
2.1.1 项目管理方法比较 2
2.1.2 项目管理方法选择 2
2.2 设计模式 3
2.2.2 MVC模式基本原理 4
2.2.3 MVC Model1 5
2.2.4 MVC Model2 5
2.3 小结 6
第3章 需求分析 7
3.1 需求描述 7
3.2 角色识别 8
3.3 用例识别 8
3.4 用例文档 8
3.5 用例驱动分析 10
3.6 小结 12
第4章 系统设计 13
4.1 系统总体设计 13
4.1.1 系统构架 13
4.1.2 发现系统类 14
4.2 视图层设计 15
4.2.1 前台设计 15
4.2.2 后台设计 16
4.3 模型层设计 18
4.3.1 前台显示和用户登录 18
4.3.2 新闻管理 19
4.3.3 栏目管理 20
4.4 控制层设计 21
4.4.1 用户登录 21
4.4.2 新闻管理 21
4.4.3 栏目管理 22
4.5 数据库设计 23
4.5.1 数据库需求分析 23
4.5.2 数据库概念设计 23
4.5.3 数据库逻辑设计 24
4.5.4 数据库表设计 24
4.6 数据库连接池设计 25
4.6.1 传统的数据库连接 25
4.6.2 数据库连接池的必要性 25
4.6.3 数据库连接池工作原理 26
4.6.4 具体设计 27
4.7 小结 27
第5章 系统实现 28
5.1 视图层实现 28
5.1.1 公共页面 28
5.1.2 前台实现 29
5.1.3 后台实现 30
5.2 模型层实现 32
5.2.1 新闻显示 32
5.2.2 新闻管理 32
5.2.3 栏目管理 32
5.3 控制层实现 32
5.3.1 用户登录 33
5.3.2 新闻管理 33
5.3.3 栏目管理 34
5.4 数据库实现 34
5.4.1 数据库表实现 34
5.4.2 数据库表关系 35
5.5 数据库连接池实现 36
5.6 小结 36
第6章 系统运行测试 37
6.1 系统测试环境 37
6.1.1 系统测试硬件环境 37
6.1.2 系统测试软件环境 37
6.1.3 Tomcat的配置 37
6.2 系统测试 37
第7章 系统评价与改进 39
7.1 系统评价 39
7.2 系统改进 39
结 论 40
致 谢 41
参考文献 42
附件 43

第1章 前言
伴随着网络的出现，网页逐渐融入人们的生活。快速及时的新闻浏览，五彩缤纷的网上信息，使网络与人们的生活息息相关，于是世界上出现了第三媒体——Internet。它打破了地域限制，真正使信息得以共享，改变了人们的工作和生活方式。人们对信息的需求有了更新，更高的要求，而网页由于本身所具有的信息量大，传递快速，没有时空限制等特点恰好满足这种要求。也正是由于网络实现网站的数据信息能够进行实时交互，保证网站数据的实时性。
随着Internet信息技术的高速发展，越来越多的企业想将自己企业的信息通过网络与全世界分享并最终实现电子商务，所以它们已经建立或计划建立自己的网站。但是，如果为了建立和维护自己的网站而聘请专职的网络技术人员，其成本对于一个中小型企业来说实在是太高了。对于上面这类企业来说，他们最需要的就是一个现成的可以自动发布信息的新闻发布系统，这样只要会打字，会上网就能利用新闻发布系统快速简洁地发布企业信息。
然而传统的信息发布方式已经不适应这个快速变化的信息时代，需要一个更高效，更简洁的方式进行信息发布。内容管理系统正是基于这样一个目的而诞生的，它是企业信息化建设和电子政务的新宠。它的基本思想是分离信息内容和表现形式，内容存储在数据库或独立的文件中，而表现形式存储在模版里。当用户请求页面时，各部分联合生成一个标准的HTML页面；当信息修改时，用户只需在一个可视化的界面对信息内容进行修改。大大缩短了信息的更新时间，提高了效率，并且简化了操作。
本设计便是基于内容管理思想的一个新闻发布系统，以下各章从系统概述、需求分析、系统设计、系统实现、系统运行测试和系统评价与改进依次展现系统开发过程。
第2章 系统概述
本章主要介绍在系统开发过程中所采用的软件项目管理方法和系统设计模式。
2.1 项目管理方法
2.1.1 项目管理方法比较
目前，面向对象软件开发的项目管理方法主要有RUP、XP和ICONIX。
RUP（Rational Unified Process）统一软件过程，是统一软件开发过程，强调文档、设计和代码的质量，采用动态适应变化的渐进式迭代周期，依靠需求和测试驱动，并积极鼓励客户参与的开发方法[1]。RUP是一个基于UML和构件式构架的迭代递增型开发过程，更适用于大、中型软件开发项目。
XP极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则,它将编码和设计活动融为一体，弱化了构架的概念[1]。要求先开发出系统中最重要的特性，迅速向客户提供所需功能，然后随着代码的演进通过重构来满足新的要求，从而使整个项目的风险降到最小。XP是一种渐进式的原型化开发方法，反映的是以编程为中心，节省资源的观念。它具有沟通高效，设计简单，反馈迅速等特点，是一种针对某些特定环境（需求变化快的小型开发团队）的具体过程实施模型和方法论。
ICONIX的规模大概在重量级的Rational Unified Process（RUP）和轻量级的极限编程（XP）之间[2]。和RUP一样，ICONIX过程也是用例驱动的，但不需要RUP使纪录延续到表中带来的大量开销；和XP一样，它相对较小，比较紧凑，但不像XP那样摒弃了分析和设计过程。因此，有助于使用统一建模语言（UML），同时对需求进行跟踪。该过程遵循了Ivar Jacobson的“用例驱动”的思想，能够获得有形、具体、易于理解的用例，可以使用这些用例来驱动开发工作。该过程的3个基本原则是：从用户需求向内进行；从问题域的关键抽象向外进行；从高级模型向下挖掘到详细设计[2]。
2.1.2 项目管理方法选择
本系统选择的项目管理方法是ICONIX，也许它并不是用于本系统开发最好的项目管理方法，当然它也有很多缺点。本系统选择它作为系统的软件项目管理方法，第一是因为系统本身较简单，采用ICONIX足以满足系统需求，并且由于时间限制，本人没有太多精力去学习更好的项目管理方法；第二是因为和别的软件方法不同的是，ICONIX更强调需求到设计之前的自然、有章可循的，同时也适合迭代的过渡，并且按照它自己的软件方法思想，它对UML符号集在可扩充的前提下作了一定的取舍。
本系统选择ICONIX项目管理方法，在系统设计和实现过程中，根据系统需要，对其进行了适当的取舍。图2-1是ICONIX项目管理方法过程的总图。

图 2-1 ICONIX总图[2]

2.2 设计模式
随着Web技术的发展，Web内容从一些静态页面发展到内容丰富的动态页面。目前，用于生成动态网页较为流行的技术有Microsoft的ASP、Tex的PHP和Sun的JSP。ASP只能工作在微软的IIS（Internet Information Server）和PWS（Personal Web Server）上及PHP模式，一些天生缺陷使得它们的使用受到了一定的制约。而JSP是一种完全与平台无关的开发新技术，它集极高的运行效率，较短的开发周期，超强的扩展能力，完全开放的技术标准，自由的开发方式等众多完美特性于一身。JSP+JavaBean+Servlet+JDBC+DBMS是一套能够实现动态网站的开发和维护的技术。DBMS数据库用于数据存储，JDBC用于连接数据库并对数据库进行存储，Servlet用于处理过程控制，JavaBean用于封装业务逻辑，JSP用于页面显示部分。而MVC正是这种设计模式代表。
2.2.2 MVC模式基本原理
MVC (Model-View-Controller)，即把一个应用的输入、处理、输出流程按照Model, View, Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层，其三层之间的关系和功能如图2-2“MVC组件类型关系和功能图”。

图2-2 MVC组件类型关系和功能图[3]

MVC设计模式的典型流程[4]为：首先Controller接收用户的请求，并决定应该调用哪个Model来进行处理，然后Model用业务逻辑来处理用户的请求并返回数据，最后Controller用相应的View格式化Model返回的数据，并通过表示层呈现给用户。
控制层(Controller)可以理解为从用户接收请求，将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉我们，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个链接，控制层接受请求后，并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
模型层(Model)就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心，必须能够满足大多数客户的需求，包括保证应用程序各组件的事务整合、维护并快速获取应用数据，支持事务工作流的协调以及在已有应用程序中集成新的应用组件等。MVC并没有提供模型的设计方法，而只告诉我们应该组织管理这些模型，以便于模型的重构和提高重用性。
视图层(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML，XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。
2.2.3 MVC Model1
在MVC模式的Model1体系中，JSP页面独立响应请求并将出理结果返回客户，所有的数据存取都是由JavaBean来完成。Model1体系十分适合简单应用需要，却不能满足复杂的大型应用程序的实现。MVC Model1的体系结构如图2-3所示。

图2-3 MVC Model1体系结构图[5]

2.2.4 MVC Model2
MVC模式的Model2体系结构是一种把JSP与Servlet联合起来实现动态内容服务的方法。它吸取了两种技术的优点，用JSP生成表达层的内容，让Servlet完成深层次的处理任务。这是一种有代表性的方法，它清晰地分离了表达和内容，明确了角色的定义及开发者与网页设计者的分工。本系统的设计模式选择的便是Model2。MVC Model2的体系结构如图2-4所示。

图2-4 MVC Model2体系结构图[5]

2.3 小结
本章首先介绍了目前面向对象的软件开发中所常用的几种项目管理方法，并最终根据系统需要选择了ICONIX作为系统项目管理方法。然后对MVC设计模式基本原理进行了详细阐述，并介绍了MVC的两种不同的模式Model1和Model2,并确定本系统的设计模式便是MVC Model2。
第3章 需求分析
需求分析在软件开发过程中，具有举足轻重的地位，它具有决策性，方向性，策略性的作用。需求分析的任务就是要解决“做什么”的问题，就是要全面地理解用户的各项需求，并准确地表达所接受的用户需求。
3.1 需求描述
新闻发布系统功能需求主要包括：前台显示功能和后台管理功能。
前台显示功能主要针对一般用户的，当一般用户在浏览新闻系统时，系统应该对新闻栏目和新闻条目的显示。另外，前台显示功能还应包括一个提供给系统管理员登录后台的登录入口。具体需求见表3-1系统前台显示需求表。
表3-1 系统前台显示需求表
用户
要求实现功能
一般用户
浏览新闻栏目
一般用户
浏览新闻
系统管理员
登录后台系统

后台管理功能是针对系统管理员的，当系统管理员登录系统后台时，系统后台提供给系统管理员的功能应该有：对新闻栏目的浏览、添加、修改和删除；对新闻条目的浏览、添加、修改和删除。具体需求见表3-2系统后台管理需求表。

表3-2 系统后台管理需求表
用户
要求实现功能
系统管理员
浏览新闻栏目
系统管理员
添加新闻栏目
系统管理员
修改新闻栏目
系统管理员
删除新闻栏目
系统管理员
浏览新闻
系统管理员
修改新闻
系统管理员
添加新闻
系统管理员
删除新闻
3.2 角色识别
角色识别的任务是找到所有可能与系统发生交互行为的外部实体、对象和系统。他们的行为不受系统控制，但是可以提供输入信息。
从系统描述可知，在前台显示模块中，系统主要对一般用户的浏览需求和管理员的登录需求做出响应；而在后台管理系统中，系统管理员可以对新闻栏目及新闻进行浏览、添加、修改和删除。所以本系统应包括两个角色：一般用户和系统管理员用户。而事实上这些人对于系统来说都是用户，只是当用户登录到后台便成了管理员而已。因此，系统角色可以统一为：用户。
3.3 用例识别
在UML文档中，用例（即Use Case）的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述[6]。
用例识别的目标是在需求描述和系统角色识别的基础上，识别出角色相映的用例，从而可以得出系统的用例模型，如图3-1是“系统用例模型图”。

图3-1 系统用例模型图

3.4 用例文档
用例文档主要为了描述出用例的详细业务流程，本系统主要包括以下用例文档：
(1) 前台显示用例文档：
基本流程：当用户在前台浏览新闻系统时，系统默认显示给用户的是所有栏目和所有新闻条目（每页显示8条新闻，一页显示不完可以分页显示）。当用户点击某个栏目时，系统显示相应的新闻条目。
分支流程：如果某个栏目下没有任何新闻，系统将显示一条信息，以指出该栏目没有新闻可以显示。
（2）登录入口用例文档：
基本流程：用户在前台显示页面提供的登录后台系统的登录入口中输入用户信息，系统根据用户的登录信息进行检验，然后进入系统后台管理系统。
分支流程：如果用户取消登录，则系统将信息重置，用户回到前台显示页面。
如果用户输入的信息不正确，系统将控制权交给“登录错误”页面，用户可以在此重新输入用户名和密码进行登录。
（3）系统后台管理用例文档：
基本流程：用户在登录系统后台后，可以对新闻和栏目进行操作，根据用户的操作选择，进入扩展用例。
（4）新闻管理用例文档：
基本流程：用户进入系统后便可浏览到新闻条目，在浏览过程中，用户可以修改和删除新闻。用户在进行相应的操作后，系统存储新的信息，系统将控制权交给后台管理用例。
分支流程：如果用户放弃对新闻的相应操作，则系统直接将控制权交给后台管理用例。
如果用户选择添加新闻，系统将控制权交给添加新闻用例。
（5）添加新闻用例文档：
基本流程：用户填写新闻相关信息，并确定添加新闻时，系统将存储此新闻，并将控制权交给新闻管理用例。
分支流程：如果用户放弃新闻添加，系统将直接将控制权交回给新闻管理用例。
（6）栏目管理用例文档：
基本流程：用户在后台管理中选择栏目管理时，用户将浏览到系统已有栏目，并可对其进行修改删除操作，用户在进行相应操作后，系统会存储新的信息，控制权将回到栏目管理用例。
分支流程：如果用户放弃相应操作，控制权将直接回到栏目管理用例。
如果用户选择添加栏目，控制权将交给添加栏目用例。
（7）添加栏目用例文档：
基本流程：用户填写栏目相关信息，并确定添加栏目，系统将存储此栏目，并将控制权交给栏目管理用例。
分支流程：如果用户放弃栏目添加，控制权将直接交回到栏目管理用例。
3.5 用例驱动分析
通过以上对系统需求的分析已经定义了系统的角色和系统用例。系统根据用例模型可以对用例进行细化，从而展现整个用例的活动顺序。序列图则反映了用例各个类之间的具体调用过程[7]，如图便是根据系统的角色分析和系统用例模型而得出的相应活动的顺序图如图3-2至图3-7。

图3-2 前台活动顺序图

图3-3用户登录活动顺序图

图3-4 后台新闻管理活动顺序图

图3-5 添加新闻活动顺序图

图3-6 栏目管理活动顺序图

图3-7 添加栏目活动顺序图
3.6 小结
本章从用户的角度，分析了系统的需求用例，画出了系统用例模型图，并得出了相应的用例文档；做出了用例驱动分析，并得出了相应的顺序图。本章的工作为系统的设计打下基础。
第4章 系统设计
根据上一章的需求用例分析，本章从先总体构架的角度对系统进行总体设计，然后根据MVC三层模式对系统进行详细设计，最后对系统数据库和数据库连接池进行了设计。
4.1 系统总体设计
4.1.1 系统构架
系统基于MVC Model2设计模式，设计出本系统自己的设计模式，在MVC Model2基础上加入数据库连接池模块层对数据库操作进行封装。具体模式图如图4-1。

图4-1 系统设计模式图

对于MVC设计模式，在本系统中具体实现方式是：Model由JavaBean完成，View由JSP完成，Controller由Servlet完成，再加上数据库连接池专门负责数据库连接和管理。本系统具体构架如图4-2。

图4-2 系统构架图

4.1.2 发现系统类
发现系统类是域建模的工作，其主要目的是根据系统需求用例及描述，找到代表与本新闻系统将要解决的问题有关的事务和概念的“对象”，即类[1]。
在本系统中，根据第3章中对系统需求用例的分析，可以总结出如下的需求集:
（1）系统应该分为前台和后台；
（2）系统前台应该可以显示新闻栏目和新闻以及用于管理员登录系统后台的登录界面；
（3）一般用户应该可以在前台自由浏览新闻，包括选择性地浏览新闻即先选择新闻栏目再浏览新闻栏目下的新闻条目；用户在浏览新闻时，系统应该可以将显示给用户一个包含新闻具体内容的HTML文件；
（4）系统管理员应该可以登录到系统后台；
（5）系统管理员应该可以对新闻栏目和新闻进行查看、修改、删除和添加操作。系统在添加新闻时，应该可以将添加的新闻保存为一个HTML文件。
由以上需求集进一步分析可知：
（1）词“系统”太模糊，不能成为一个对象的名称；同样，“前台”和“后台”为系统的两个不同的区域，亦不能成为对象名称；
（2）“新闻栏目”和“新闻”为系统的两个主要内容，所以应该分别作为一个类，而新闻栏目和新闻的显示需要管理类进行管理，系统管理员要对栏目和新闻进行查看、添加、修改和删除，也需要相应的管理类进行管理，所以，系统对于新闻栏目和新闻分别需要“栏目管理类”和 “新闻管理类”；
（3）要将添加的新闻保存为一个HTML文件，需要一个从表单中收集信息并将其转换为一个HTML文件的类；
（4）系统要保存信息，必须用到数据库，所以需要一个数据库连接的类；
（5）要将系统的各个功能执行成功，少不了相应的控制类。
因此，识别出系统主要的类：新闻类（News）和新闻管理类（NewsMgr），栏目类（Category）和栏目管理类（CategoryMgr），数据库连接池的连接对象类（ConnectionObject）和连接池管理类（ConnectionPool）以及各个Servlet类。
4.2 视图层设计
4.2.1 前台设计
当一个用户浏览新闻系统时，首先进入系统前台界面。如果把一个系统比作一个人，那么前台界面则是这个人的脸，因此系统的前台界面的设计是比较重要的，并且，前台界面应该被设计得比较简洁，方便。前台界面设计如图4-3所示。

图4-3 前台界面设计图

首先，在本系统的前台界面的顶部用户可以看到一个专为系统管理员用户提供的登录入口，为系统管理员提供了方便。而对于一般用户来说，他们也不会感觉这有何不妥，因为此登录界面比较简洁，并不会影响用户正常地阅读新闻。
其次，在登录界面的下方是新闻栏目的显示，显示系统新闻栏目数据库中已有的新闻栏目，一目了然，用户可以方便地找到自己喜欢和关心的新闻所在的栏目。
再次，在新闻栏目的下方则是新闻条目的显示，默认的新闻条目的显示方式是以表格的形式将系统新闻数据表中的新闻按发布时间进行列表（发布较早的新闻被放在列表的后面，而发布较迟的新闻被放在列表的前面，体现了新闻的“新”，即“时效性”）。新闻列表中仅显示新闻的标题，发布时间和新闻作者，如果想浏览整篇新闻，用户可以点击新闻标题（超链接），这时系统会将用户引导向一个包含新闻具体内容的HTML文件。
然后，用户可以对自己比较关心和感兴趣的新闻进行有选择性地浏览，这时新闻栏目便起作用了。当用户点击新闻所在的栏目时，系统在新闻列表中只显示本栏目的新闻条目。用户可以在此浏览自己关心和感兴趣的新闻。
4.2.2 后台设计
4.2.2.1 后台主页面设计
当用户登录到系统后台时，他便成为系统管理员，可以执行对新闻和栏目的查看、修改、删除和添加。此界面主要是面向管理员的，界面要设计得简洁方便，使得系统管理员在管理系统时容易操作。后台界面设计如图4-4所示。

图4-4 后台管理系统主界面设计图

当管理员用户登录到系统后台时，呈现到他眼前的是系统后台管理的主页面：
首先，系统后台主页面左上角是欢迎词（Welcome+管理员名），对于管理员，他可以感觉到系统的人性化；对于系统本身，系统可以识别此时登录的是哪个管理员，可以分配管理员的权限。
其次，欢迎词下方是系统管理的功能选择，一目了然，管理员可以在此选择要操作的模块进入，然后执行相应的操作。
再次，再往下就是系统新闻列表，与前台新闻显示类似，只是多了对新闻的操作（修改和删除）。管理员可以在此对系统已有的新闻进行修改和删除操作。
4.2.2.2 添加新闻设计
如果系统管理员在系统后台主页面中选择“添加新闻”，管理员会进入下图这样一个页面进行新闻的添加，添加完新闻标题和新闻正文内容后，还必须选择所添加新闻所属的新闻栏目。确认所有内容均已填好，点击“发表”按钮，新闻发布工作完成，如果点击“清除”按钮，则系统清除管理员刚才的所有输入，让管理员重新填写新闻的各项内容。管理员可以在系统后台主页面中看到刚刚发表的新闻，可以对其进行相关操作，如图4-5。

图4-5 发布新闻页面设计图

4.2.2.3 栏目管理设计
如果系统管理员在系统后台主页面中选择“栏目管理”，系统将链接到新闻栏目管理页面。栏目管理页面上有一些链接按钮，可以让管理员链接到其他页面。链接按钮下面是系统已有新闻栏目的列表，在此，管理员可以对新闻发布系统的栏目进行操作（编辑和删除栏目）。
如果管理员想要添加新闻栏目，只需点击“添加栏目”，就可以被链接到添加新闻栏目页面（因为此页面比较简单，所以并未给出具体设计图），添加栏目完成后，管理员可以在栏目管理主页面的栏目列表中找到新添加的栏目，并对其进行相关操作，如图4-6。

图4-6 栏目管理页面设计图

4.3 模型层设计
本系统模型层由JavaBean完成，模型层设计主要设计出完成各个功能模块中模型层的JavaBean类。模型层的类主要有新闻类News和新闻管理类NewsMgr以及栏目类Category和栏目管理类CategoryMgr。
4.3.1 前台显示和用户登录
在前台显示和用户登录模块中，充当模型层的是News和NewsMgr根据系统分析中的系统前台需求用例分析和上述的前台界面功能描述，对系统的前台的每一个流程、每一个模块进行详细功能设计。其相应的功能模型如下图4-7。

图4-7 系统前台显示和用户登录静态模型图
根据上面的系统前台模型，我们可以来说明各个类的责任和功能。

表4-1 前台类责任表
名称
类型
属性
责任（或操作）
Index page
边界
无
显示系统前台主页面，并提供管理员登录
News
实体
新闻条目的属性
新闻条目的抽象
NewsMgr
控制
无
根据新闻ID得到新闻对象，获得所有新闻和根据栏目ID得到该栏目的所有新闻
Login Form
边界
无
提供管理员登录，并负责客户端的登录完整性检验
main page
边界
无
系统后台管理主页面

4.3.2 新闻管理
管理员在系统后台主界面中可以对已有新闻进行管理（修改、删除和添加），新闻管理模块中充当模型层的仍然是News和NewsMgr。其静态模型如图4-8。

图4-8 新闻管理静态模型图

根据上面的新闻管理模型，我们可以对各个类的责任和功能进行说明。

表4-2 新闻管理类责任表
名称
类型
属性
责任（或操作）
Main page
边界
无
显示系统后台主页面，系统管理员可以在此对系统进行操作
表4-2 新闻管理类责任表（续）
NewsMgr
控制
无
对新闻条目进行操作，修改和删除
News
实体
新闻属性
对新闻实体的抽象
Addnews page
边界
无
添加新闻界面，以Form形式收集信息然后提交给控制器
AddNewsServlet
控制
无
在控制层设计
EditNewsServlet
控制
无
在控制层设计
DeleteNewsServlet
控制
无
在控制层设计

4.3.3 栏目管理
栏目管理中可以对已有栏目的编辑、删除以及添加新栏目，栏目管理静态模型如图4-9。

图4-9 栏目管理静态模型图

根据上面的栏目管理静态模型设计，我们可以对各个类的责任和功能进行说明。

表4-3 栏目管理类责任表
名称
类型
属性
责任（或操作）
ClassManage page
边界
无
显示系统既有栏目，管理员可以在此对栏目进行修改和删除操作
Addclass page
边界
无
添加栏目，提交给添加栏目控制器
Category
实体
ID和Name
新闻栏目的抽象
CategoryMgr
控制
无
实现对新闻栏目的操作
表4-3 栏目管理类责任表（续）
EditCategoryServlet
控制
无
在控制层中设计
DeleteCategoryServet
控制
无
在控制层中设计
AddCategoryServlet
控制
无
在控制层中设计

4.4 控制层设计
4.4.1 用户登录
当用户通过系统前台提供的登录入口登录后台系统时，系统将用户的登录信息提交给登录控制层处理。所以登录控制器必须对用户登录信息进行识别，判断其是否有权限登录到后台系统。用户登录控制器由LoginServlet完成，实现登录控制的静态类图如图4-10。

图4-10 登录控制静态模型图

根据图4-10登录控制静态模型设计，对各个类的责任和功能进行说明。

表4-4 用户等录控制类责任表
名称
类型
属性
责任（或操作）
LoginServlet
控制
无
控制用户登录

4.4.2 新闻管理
新闻管理中主要涉及到新闻信息的添加、删除和修改，所以其控制层由AddNewsServlet、DeleteServlet和EditServlet完成。新闻管理静态类图如图4-11。

图4-11 新闻管理静态模型图
根据图4-11新闻管理静态模型设计，对各个类的责任和功能进行说明。

表4-5 新闻管理控制层静态类责任表
名称
类型
属性
责任（或操作）
EditNewsServlet
控制
无
对已有新闻编辑的控制
DeleteNewsServlet
控制
无
对删除已有新闻的控制
AddNewsServlet
控制
无
对添加新闻的控制

4.4.3 栏目管理
栏目管理模块主要对新闻栏目进行修改、删除和添加，此功能模块控制层由EditCategoryServlet、DeleteCategoryServlet和AddCategoryServlet完成。栏目管理静态类图设计如图4-12。

图4-12 栏目管理静态模型图

根据图4-12栏目管理静态模型设计，对各个类的责任和功能进行说明。

表4-6 栏目管理控制层静态类责任表
名称
类型
属性
责任（或操作）
EditCategoryServlet
控制
无
对新闻栏目编辑的控制
DeleteCategoryServlet
控制
无
对删除新闻栏目的控制
AddCategoryServlet
控制
无
对添加新闻栏目的控制

4.5 数据库设计
4.5.1 数据库需求分析
由于本系统面向的对象有两个：一般用户和系统管理员。所以，数据库需求分析中就要考虑两方面因素。
对于一般用户来说，他们所关心的是新闻的浏览。通过系统功能分析，针对一般新闻用户的需求，总结出如下需求信息：
（1）每个新闻对应一个HTML文件；
（2）每个新闻只能对应一个新闻栏目；
（3）每个栏目下可以有多个新闻。
（4）每个新闻除了包含新闻的基本信息之外，还得包含新闻所对应的HTML路径信息。
对于系统管理员来说，他们所关心的是如何对新闻栏目和新闻的添加、修改和删除。通过分析，针对系统管理员，总结出如下需求信息：
（1）管理员可以对新闻栏目进行增、删、改；
（2）管理员可以对新闻条目进行增、删、改。
4.5.2 数据库概念设计
根据上面的数据库需求分析，就可以构造出各种实体，以及并根据它们的关系绘制出实体间的E-R图[8]，为以后的逻辑设计打下基础。如图4-13为本新闻发布系统实体间的E-R图。

图4-13 实体之间关系的E-R图[8]

4.5.3 数据库逻辑设计
根据数据库需求分析和数据库概念设计，设计如下所示的数据项和数据结构：
管理员表（用户名，密码），用户名为主码；
栏目表（栏目编号，栏目名称），栏目编号为主码；
新闻表（新闻编号，新闻标题，新闻内容，管理员名，所属栏目，发布时间），新闻编号为主码，管理员名和所属栏目为外码；
4.5.4 数据库表设计
数据库逻辑设计完毕后，现在可以将上面的数据库概念结构转化为某种数据库系统所支持的实际数据库模型。本系统使用SQL Server2000数据库。
新闻发布系统的数据库中各表的设计结果如下面几个表所示。

表4-7 管理员Master表
序号
字段名
字段含义
类型
宽度
是否非空
备注
1
UserName
管理员用户名
char
12
Y
Key
2
Password
管理员密码
char
12
Y
无

表4-8 新闻News表
序号
字段名
字段含义
类型
宽度
是否非空
备注
1
newsId
新闻编号
int
4
Y
Key
2
Title
新闻标题
char
50
N
无
3
Content
新闻内容
char
5000
N
无
4
UserName
新闻作者
char
12
Y
外码
5
Compose_date
新闻发布时间
datetime
8
Y
无
6
categoryId
新闻栏目编号
int
4
Y
外码

表4-9 栏目Category表
序号
字段名
字段