个人博客系统的设计与实现Word文档格式.docx
- 文档编号:20699649
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:27
- 大小:493.13KB
个人博客系统的设计与实现Word文档格式.docx
《个人博客系统的设计与实现Word文档格式.docx》由会员分享,可在线阅读,更多相关《个人博客系统的设计与实现Word文档格式.docx(27页珍藏版)》请在冰豆网上搜索。
关键词:
个人博客,Blog,Web应用,JSP,MySQL
Abstract:
Withthepopularityofthemobilephone,tabletandhandheldterminalaccessdevice,moreandmoreuserswantedtointeractthroughthenetworkplatformtoshowtheirindividualityandspreadtheirideology.Itwasfrequentlyusedtoreleaseinformationthroughapersonalblog.Theprojectestablishedasimpleblogsystem,whichfacilitatedthestudentstoexchangetheirinformation,suchaspersonallifeexperienceorstudynotes.Anditgreatlypromotedtheexchangeofideasandinteractionofthestudents,expandedthecircleofcommunication,andincreasedstudents’interestinlearningandlife.ThesystemimplementedbyJava,JSP,TomcatandMySQLtechnologies.
Keywords:
Blog,Webapplication,JSP,MySQL
1绪论
1.1课题背景
随着手机、平板等手持终端访问设备的普及,普适计算越来越渗入人们的生活。
跟随发展的就是个性化服务,如网络发布、签名、预约等都被极大地赋予了个人特色,越来越多的用户希望通过网络平台进行互动交流,同时展现自己的个性,传播自己的思想。
著名的网站包括Facebook和人人网等。
很多人对发生在自己身边的事以及对生活的一些感悟愿意用文字或图片的方式记录下来发到网络上与他人分享交流,其中通过个人博客发布是一个使用频率较高的方式。
本课题拟建立一个交互简捷的博客系统,方便在校学生发布信息进行交流,可以将个人生活经验或学习笔记心得等发布到系统中,方便其他同学的查看讨论交流。
1.2目的和意义
根据维基百科的定义[1],博客或网络日志(英语:
Blog,为WebLog的合成词),台湾译作网志、部落格,港澳译作网志,马新译作部落格、博客、网志,是一种由个人管理、不定期张贴新的文章、图片或影片的网页或联机日记,用来抒发情感或分享信息。
博客上的文章通常根据张贴时间,以倒序方式由新到旧排列。
许多博客作者专注评论特定的课题或新闻,其他则作为个人日记。
能够让读者以互动的方式留下意见,是许多博客的重要要素。
从定义可以看出,Blog一般包含了最新的个人私人信息或专题方向信息,因此开设blog给在校学生使用,让同学不定期的更新记录自己的学习生活状态,不仅可以用来及时相互交流,还可作为学习的笔记本使用,长时间的积累将成为一笔精神财富。
建立系统的根本目的就是要促进学生的思想交流和互动,扩大学生的交际圈,提升学生的综合能力。
它不仅能扩大同学获取信息的渠道,还能提高学习兴趣,增加生活情趣。
1.3系统设计指导思想
由于系统需要具有普适的特性,因此建立以Web服务为中心的系统是最优的架构。
使用传统的B/S架构能接纳多种终端设备的访问,如使用笔记本电脑、台式计算机、手机、平板电脑等设备。
其中以学生使用的实际情况看,PC终端和手机终端将是访问的主要设备,因此在系统架构上必须容纳传统的浏览器访问和手机终端访问方式。
结合实际的需要,技术实现上将以普通Web结合Wap的方式实现系统功能的访问,并且这两种技术架构相近,可以统一到Web服务器中一起管理[2,3]。
另外,从用户操作的角度出发,使用系统应该感受到较好的便捷性,即通常所说的系统设计以人为本的思想。
综合考虑,对系统设计提出如下几点要求:
1.便捷性:
系统以便捷的信息访问为首要目标,以方便用户使用为核心原则,需要充分考虑实际操作的各项细节,支持多种终端接入。
这种追求近乎完美的操作体验正是著名的苹果公司创始人乔布斯先生所推崇的,当然本系统以这种指导思想为目标,努力做到尽善尽美,最终通过用户的不断反馈将及时调整,力争做到方便用户操作。
在不需要查看操作帮助的情况下也能轻松直观的操作,并对操作流程有清晰的理解。
2.实用性:
包括系统功能和系统信息呈现以实用为目标,不添加华而不实的部件与功能,既不丢失必要的信息,又能简单直观,以传达信息为核心,对文字记录和图片发布能提供较好的功能封装。
另外通过系统能及时了解多方面多渠道的信息,体现系统的核心价值。
3.可靠性:
由于多用户的同时访问,因此系统要具备可靠的性能处理要求,能支持多用户并发访问和并发操作。
同时所有的用户数据都存放在服务器上,要求数据存取可靠安全,尽量避免丢失用户创建的资料或数据状态不一致现象。
4.可维护性:
针对系统后期的功能调整或增删,应尽量减少维护的工作量。
对用户来说,对系统中自己的资料的操作也应该方便查阅和维护。
2系统需求论述
根据前面的分析与定位,本博客系统主要用于校内同学的使用,因此需求的重点也反映在同学平时生活中的明显的和一些潜在的期望。
就主要功能来说,核心在于创建自己的博客空间,在博客空间中方便的发表博文,支持他人在线评论互动,同时能方便地查阅他人的博文并添加评论。
同时由于潜在的需求期望增加获取信息的渠道,单纯的博文浏览显得过于单薄,因此系统中增加创建兴趣小组的功能,将小组的最新消息自动发布到组员,并提供小组讨论的页面空间。
另外系统提供站内信功能,帮助简化互发消息的管理,这样系统能自主控制所有消息,并能保留消息的历史信息,方便消息维护。
这里为了方便叙述,特预先约定几个使用的名词术语的确切含义:
博客空间:
指网上由一到多个页面组成的、由用户自己管理发布的、他人能访问浏览的虚拟空间。
所有者可以设置其基本信息和呈现方式,可以在空间中发布自己的文字或图片信息供他人访问并回复。
博文:
发布在博客空间的一条信息,可能是文字描述,可能是图片,也可能是混合形式。
一般由博客空间的所有者发布,他人只能回复已有的博文,不能发起一条新的博文。
空间显示的时候一般按照时间由近到远的顺序进行显示。
博客:
指登录进入系统的一般用户,可能是普通的注册用户,并没有开通自己的博客空间,可能只对小组感兴趣,因此只加入了小组,也可能是具有博客空间的博主。
这里泛指系统中的正常用户。
博主:
指拥有博客空间的系统用户,可以登入自己的博客空间进行管理,也可以浏览查看其它博主的空间,并具有普通博客具有的一切操作功能。
综合上述,得到系统的功能性需求如下图。
图1系统普通用户的用例图
其中各功能性需求简要说明如下:
简单的系统登入登出及注册功能在这里不再详述。
其他重要的功能主要集中在博客访问和博主访问这两个角色上,其中博主角色具有博客角色具备的所有的系统功能。
博客可以进入系统浏览查看某博主的博文并回复,或根据关键字搜索得到相关的博文信息,另外可以进入小组空间查看小组的最新信息,同样可以利用搜索功能查询小组中的相关信息。
如果没有找到相关主题的小组信息,则可以创建新的小组并接纳成员访问。
在小组中可以浏览发帖信息并回帖参与交流。
博主角色能操作的功能主要集中于自己的博客空间方面,主要包括:
发布博文管理,空间信息管理,回复管理,空间模块管理,外观方案管理,设置头条或置顶管理,分类管理,关键字管理,好友管理,常用链接管理,背景音乐管理。
这几个模块的访问一般是博客主人身份才能操作。
对于系统管理员角色的操作,主要侧重于系统的运营与维护方面的功能。
主要包括系统级别的用户管理、系统级别的博客与小组信息维护、系统属性设置、系统状态检查与监测、系统数据的导出与导入、系统的启动与关闭,具体如下面的用例图所示。
图2系统管理员用例图
对系统的非功能性需求方面的要求,主要体现在性能需求和可靠性需求两个主要方面,下面从这两个核心的角度加以说明。
性能需求:
由于属于Web服务型项目,这必然要求系统能承受大量的同时在线用户访问的问题。
目前来看,只要系统结构设计得当,只需要保障硬件平台的性能需求就能将并发访问需求控制在合理的承受范围。
另外由于用户很少集中登录集中处理,实时状况下多用户处理需求没有想象的高,但遇到一些特殊情况时,可能会表现出来,比如学校举办运动会或大型活动如歌手比赛等,此时系统内会有较大量的发布、评论等活动,但这些活动相互间关联性不大,没有严格串行化操作的要求。
因此虽然访问量和发布量大,但相对独立,运用软件架构可以很好的处理,同时使用应用服务器自身提供的集群特性可以很好地解决压力承受的性能要求。
[4,5,6]
可靠性需求:
由于不是重要的支撑平台,即使系统停机较长时间,也不会带来太大的损失,但可能会给用户造成很大的困扰,因此可以将可靠性需求映射到底层的支撑软件平台上,如使用Java应用服务器和Oracle数据库服务器,其本身较高的可靠性要求可以大体上实现本系统对整体可靠性的要求,同时结合软件架构内合理的辅助型框架应该能较好的满足可靠性要求。
[4,6]
3系统分析与设计
基于系统的需求,这个章节主要陈述分析得出系统的分析模型和设计模型,从逻辑上理解系统的实现方式和操作方式。
下面叙述中没有严格按分析和设计划分小节,而是大体按照几个主题进行了陈述,将分析结果与设计结果大体连贯起来,后续的章节将介绍具体的实现。
3.1系统的总体分析
针对B/S结构来说,整个系统服务都集中于服务器端,对服务器的架构设计一般使用3层架构或多层架构,这在Java体系结构设计中非常普遍。
本系统使用常见的三层架构,即界面表示层、业务逻辑层、数据持久层。
图3整个系统的总体结构
系统总体布局如上图,客户端如需求所述,可能是PC机上的浏览器,也可能是基于手机的客户端,通过使用Web和Wap访问协议来协调这两者。
如果将Web接口包装成WebService接口,则可以接入更多类型的访问设备。
下图显示了整个系统的架构图。
图4系统体系架构
其中表示层的职责主要集中于处理Web页面的数据显示、接收用户输入和各类操作,属于整个系统的最前端,但其中没有系统的操作逻辑,仅仅包含简单的页面交互方面的处理逻辑,一般使用JavaScript脚本来生成浏览器端的交互逻辑,并使用脚本将输入数据或操作结果反馈到后台业务逻辑层。
这部分内容借鉴了课程《Web程序设计》和《Java高级编程》中的知识,使用了其中的介绍的脚本交互组件CKEditor。
这个组件功能强大,只要简单配置就可以很好的完成文字和图片的发布工作,这极大地减轻了表示层开发的工作量。
在毕业设计的过程中,深深体会到了封装以及基于组件开发带来的好处,具体地体会到了《软件工程》课程中的原来较为抽象的思想。
3.2分析类的获取
确定了主要的系统用例,接下来需要得出分析类模型,用于评估整个系统,也起到了承接分析与启下设计的作用。
归纳一下系统的功能,并综合操作特性,得到如下几个综合的操作界面类型(这里统一以UI为后缀,表示用户界面):
主页面(MainUI):
是系统的首页面,主要呈现登录模块、搜索模块、所有博客空间最新更新情况统计、所有小组更新情况统计、推荐的博客与小组的内容展示、讨论热烈的话题汇总、博客和小组排行榜、广告模块等信息。
个人主页面(UserMainUI):
用于用于个人有关的信息设置与管理,包括个人博客汇总信息(一个用户可以有多个博客空间)、创建小组管理、参与小组的最新情况、书签管理(用于记录一些常用链接)、个人信息管理模块、搜索模块、登录模块。
博客主页面(BlogUI):
即个人博客空间,包括个人信息模块、搜索模块、登录模块、标题模块、书签模块、访客模块、发帖信息模块、近况模块、推荐小组模块、推荐博客模块、通告模块、广告模块(系统内用户发布、非商业广告)。
博客管理主页面(BlogMgmtUI):
用于对当前博客空间进行设置,包括标题设置、界面设置、模块设置、访问性设置、发帖设置、回复设置、访客信息管理模块。
小组主页面(GroupUI):
主要呈现某小组的信息,包括标题、简介、空间发帖、成员、搜索模块、登录模块、提示栏个人信息显示模块、近况模块、推荐小组模块、推荐博客模块、通告模块、广告模块(系统内用户发布、非商业广告)。
小组管理主页面(GroupMgmtUI):
用于小组内的信息管理。
包括标题设置、界面设置、成员及访问性设置、发帖设置、回复设置。
搜索页面(SearchUI):
主要用于站内的信息搜索,包括用户、博客空间、小组、主题、关键字、一般包含信息的搜索及其结果。
系统管理页面(AdminUI):
汇总了系统的管理功能,包括系统开关机模块、系统属性设置模块、系统数据管理模块、系统用户管理模块、状态显示模块、统计信息模块。
控制类的作用集中体现了系统的业务逻辑,因此最终的控制类大部分都映射到了业务逻辑层,根据用例模型中的系统功能性描述,经过统筹安排,得出系统中的控制类如下:
登录控制类(LoginWorkflow):
专门负责登录的控制逻辑。
登出控制类(LogoutWorkflow):
针对登出系统专门进行处理。
虽然网页型访问一般设有30分钟会话有效期,但这里还是单独进行处理,保证数据的一致性。
注册控制类(RegisterWorkflow):
专门处理新用户注册的问题。
查找功能在各个对象上都有体现,最终界面将分类显示,因此查找功能这样组织:
综合查找控制类(FindWorkflow):
用于统一各类查询及汇总各查询结果。
小组查询(FindGroupWorkflow):
针对小组进行筛选查询的控制类。
用户查询(FindUserWorkflow):
用于对用户进行各类信息进行筛选查询。
博客空间查询(FindBlogWorkflow):
基于输入值查询满足条件的博客空间。
发帖查询(FindItemWorkflow):
针对发帖回帖进行筛查,可以对博客空间和小组内的发帖同时筛选。
针对发帖管理的控制类组织为发帖、显示、回复三个控制类。
创建新帖控制类(CreateItemWorkflow):
博客空间和小组空间里面使用相同的控制逻辑,因此统一为CreateItemWorkflow控制类,不同的就是发往的空间不同而已。
显示发帖控制类(ListItemWorkflow):
针对显示自定义的要求较多,因此单独设计显示控制逻辑,在博客空间和小组空间中使用相同的控制类,最终显示在界面类中加工生成不同的页面风格。
回帖控制类(ReplyItemWorkflow):
用于管理回帖的过程控制,与创建新帖很相近,但地位不同。
另外几个控制类集中于管理功能,包括:
发帖条目的管理控制类(ItemMgmtWorkflow):
对空间中所有的发帖进行管理的控制类,体现在对条目的增删改查,对回复的管理,附加信息以及状态的管理。
博客管理控制类(BlogMgmtWorkflow):
对博客空间的信息进行配置,对各模块进行配置与显示,以及置顶发帖、管理链接关键字、背景音乐处理等。
小组管理控制类(GroupMgmtWorkflow):
针对小组的各管理功能,包括设置小组状态、批复加入请求、任命管理者、发帖管理等。
用户管理控制类(UserMgmtWorkflow):
针对用户自身进行管理,包括更改信息,管理好友等操作。
系统管理控制类(SysMgmtWorkflow):
所有针对系统的管理和操作都纳入这个控制类中,当然设计阶段可以对设计类进行调整,划分出分角色的管理类实现。
3.3系统关键抽象概念的获取与分析
下面分析系统的领域模型。
在这个系统中领域模型的重要作用是显而易见的,所有用户都围绕着这个模型在工作。
匿名用户可以浏览系统中的各种信息,包括浏览博客空间和小组空间的信息;
普通博客可以查看其它博客空间的信息,并能够进入小组进行讨论;
而博主则可以在自己的博客空间发布博文并进入小组讨论,所有人都在围绕领域模型浏览信息或操作信息。
因此根据前面的假设和扩展,初步得出下面的领域模型结构。
图7系统的关键抽象
根据前述需求,一个用户可以创建多个博客空间,并可以发布多条博文,每条博文具有一个特定的主题,并且可以具有多个分类关系,可以包含多条回复的评论,并且具有一个特定的状态。
用户可以创建一个小组,并且小组可以加入多个用户,小组中可以发帖、回帖。
由于博客空间和小组内的消息发布在操作和结构的性质上是一致的,不同之处在于小组内任何人都可以发帖,而博客空间内只允许博主发帖,这在设计实现中只要检查当前是博客还是小组,操作者是否拥有当前博客空间即可解决权限问题,因此在系统设计中将两者统一处理,将消息发布对象统称为发帖条目(PostItem),回复统一为回帖条目(ReplyItem)。
每个发帖条目关联一个主题(Subject),并具有零到多个关键字(分类)(Keyword)。
当然发帖条目有不同的状态(Status),如草稿、扣留发布、正常发布、置顶发布、隐藏、删除、允许回复、禁止回复。
另外博客博主仅仅在检查操作时有区分权限的关系,因此将两者统一为用户(User)。
重新整理系统模型如下图。
图8博客空间与小组内的发文及回复的模型
对于发帖条目的状态变迁可以建立下面的模型进行建模。
图9发帖条目的状态变迁图
用户新建发帖后,键入的内容自动保存,此时发帖属于草稿状态;
编辑完成点击发布后,发帖进入待发布状态;
进入待发布状态的帖子由系统自动判断是否有违规定的地方,进入审批状态,结果若通过则进入发布状态,若未通过则进入待发布状态,此时用户可以继续编辑或丢弃帖子,因此在待发布状态下的帖子都是没有审核通过的帖子;
处于发布状态的帖子是可以显示在空间里面的,当然如果用户选择隐藏则不显示在空间内;
超过时限的帖子则进入存档状态,存档状态下的帖子都将被移到到备份库中压缩存储。
3.4分析类交互
下面选取一个简单的登录过程和发布帖子这两个用例来说明分析类的交互过程分析。
登录过程在所有系统中都有体现,功能也简单直观。
一般在操作的设计中,首次登录的时候只需要输入用户标识和密码即可登录,当用户名或密码不正确时,在后续的界面上加入验证码来防止破解攻击,多次无效后(一般控制在10次)账户便被锁定。
本系统中由于没有太大的安全性需求,因此即使多次登录失败账户也不需要锁定,只需加入验证码即可。
图10登录的交互流程
其中的协作关系如下,其中用户类不属于系统内部,只是用来交互做输入的,因此可以看出用户需要打开主界面,在登录模块中输入用户名、密码,点击登录即可,成功后在会话中记录用户信息,在系统主页面中记录安全信息,这样在各个页面间跳转的时候就可以共享安全状态和安全凭据了。
下面分析发布帖子的交互过程。
界面中使用CKEditor控件可以完成文字修饰、上传图片及编排版式的功能,最终在浏览器上生成一个HTML的描述文本,提交后服务器端接收这个HTML描述文本,设计中将这个描述文本直接存入数据库中即可。
浏览帖子的时候只要取出此描述文本放入页面中即可显示原先编辑好的效果。
提交此数据后,首先确认并检查用户权限,是否可以发帖,通过后将发帖内容交给系统检查,这里由ItemChecker接口来完成检查工作,最终设计中只要实现这个接口就可以完成多种检查方法。
检查通过后,发帖内容存入数据库,同时用户可以浏览最终的效果。
图12发帖交互流程图
对应的协作图如下所示,其中为了保险起见,将用户验证做了两次,防止恶意信息被用重播的方式插入到系统中,即创建帖子时验证身份和发布帖子时也验证身份,因此中间可能隔了较长的时间,如果用户被禁用,则这时可以重新检查权限状态。
4系统设计
系统设计中需要综合考虑功能性需求和非功能性需求,而且非功能性需求更重要。
一些部分需要软件设计模式的加入,但本人对设计模式了解还不很透彻,因此设计中只是完成了功能操作,没有再细致地考虑调整其结构,让它满足设计模式的要求,当然过多运用设计模式也会带来一些负面的影响,比如其结构复杂,不太容易立即理解,因此后面的设计暂时以满足功能要求为第一目标,然后重点考虑实现非功能需求的便捷操作的要求。
4.1系统运行平台的设计选择
整个系统使用Java语言作为开发的基础语言,Web界面部分搭配使用HTML、CSS、Javascript以及JSP技术来实现。
最终发布的系统对平台没有特别大的强制要求,因为基于Java开发的Web型服务项目,可以选用流行的Tomcat服务器或者JBoss服务器或者GlassFish服务器来搭建,这些都是开源免费的平台。
数据库可以使用MySQL数据库,它也是免费使用的数据库,很多大型网站都选用了MySQL作为自己的数据库支持平台。
开发过程中,选择平台搭建于WindowsXP系统下,当然发布时可以选择Windows平台或Linux平台,两者的环境下都有上述的开源软件。
对于硬件平台,基本上没有强制性要求,只要是可用的服务器硬件平台都能完成正常部署和使用,当然性能高的服务器对多用户支持的效果会更好。
4.2系统数据库的结构设计
根据前面的需求描述及领域模型的系统关键数据抽象,分析得出系统的数据库表结构如下面的关系图所示,其中基本表(Table)用于记录底层的核心的信息。
另外,必须基于基本表在其上层创建一些视图(View)以方便某些角度的数据的操作。
整体的逻辑结构如图所示:
图14数据库表的总体关系图
单独表的建模信息不再详细列举,可以参阅上述的总图中的描述信息。
4.3数据库操作的设计
为了简化数据库操作的代码,防止过度的重复数据库常规执行的初始代码,将数据库操作进行封装是很必要的,这也为后期数据库升级和系统功能升级提供便利。
数据库操作的封装还能有效隔离软件对具体数据库的依赖。
现在实际项目开发中可以用的框架较多,比如JPA框架、Hibernate框架、JDO访问、TopLink框架等,这些框架支持强大,但使用起来需要配置和编程传递接口等,因此在大中型项目中使用是较为合理的,本系统针对数据查询和更新操作较为简单,没有过多的附加操作,因此使用Apache的开源项目CommonDbUtils可以很好的实现数据库的访问和操作。
在项目中定义DbHelper访问数据源封装信息。
importjavax.naming.Context;
importjavax.naming.InitialContext;
importjavax.sql.DataSource;
importmons.d
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 个人 博客 系统 设计 实现