自适应博客系统设计与实现
该题目是并非取自于多媒体图书系统，而是来自于自己做过的的一个博客项目，对其进行了详细的分析与设计过程。具体两个过程如下：
一、系统分析
1.1、可行性分析
可行性研究报告的目的是确定该系统能否实现，会遇到那些问题，能否解决以及后续发展等问题。发现明确设计项目所要面临的问题和方法以及如何解决是可行性分析的目标所在。
本课题设计主要是参考网上主流的博客样式和功能，来模拟实现一个可以在Web端和移动端进行的轻博客的相关功能操作，两个模块访问同一个服务器。Web端的主要功能包括用户Login，Register，Blog查看，Blog发表，Blog搜索，Blog类别管理，Blog留言，留言管理，个人信息设置等；移动端部分的功能与之大致相同，没有留言管理。同一个服务器向两个平台端提供数据请求接口。该系统的相关功能符合市场上的Web端和移动端的博客系统的基本要求，服务端使用Springboot内嵌的Tomcat进行本地实现，保证服务端的高效稳定，Bootstrap被使用于Web前端，保证用户体验以及编码质量，移动端使用用户广泛Android平台，版本要求Android6.0，保证一定市场。所使用的相关技术和框架都是比较流行而且稳定，从而保证系统的可行性和稳定性。
1.2、系统需求分析
在软件开发和维护周期中，需求分析是会一直影响整个课题开发过程的一个阶段。在整个软件开发生命周期中需求分析的重要性可由数据体现，这些失败的项目高达七成，大约六成的失败的原因是需求阶段问题。事实上，需求阶段问题使得一半以上的Developer遇到麻烦，这种重要却基础的问题越来越受Developer重视。需求分析阶段的主要任务获取并且明确用户提出的Demand，以通俗化的交流方式来实现明确模糊的需求，开发者最终形成对需求的完整，明确和的描述，产生需求规格说明书等。
在确定要执行的操作和要实现的功能，然后从上到下分解功能，逐步细化它们，将它们抽象为更小的功能，然后逐步实现它们。在此阶段，作为过程和结果还需要创建用例图和需求规格说明书。
确定课题目标后，以自己熟悉的Web开发和Android开发为基础，分别在Web端和Android移动端实现轻博客系统，两端的功能相似，但Web端界面更加美观，功能更加丰富，Web端博客的相关功能模块如下说明。
（1）博客浏览以及留言：该功能部分主要是给没有登陆的游客进行博客的浏览以及评论，除此之外，用户查看自己的博客也会调转到其中的相关博客页面。
（2）用户登陆以及注册：用户根据自己注册过的账户以及密码进行Login，经过Server查询后，返回Success数据跳转进入博客管理用户界面。
（3）博客管理：该部分主要以表格的形式展示出当前用户的所有的博客的标题，类别，日期，点击数，状态等信息，可以对所有博客进行删改。
（4）博客发表：需要填写的部分包括博客标题，博客类以及博客正文，其中博客正文是Markdown中编辑，博客编辑结束后选择保存为草稿状态或者直接发表。
（5）留言管理：将游客的留言以表格的形式展示出来，包括留言内容，留言人，浏览时间，删除操作等。
（6）类别管理：展示出当前所有的类别，并且可以添加新的类别以便发表博文时选择，同时也支持删除。
（7）用户设置：该部分主要可以查看设置用户的Email和手机号，并且也可以进行密码的修改。
根据功能的相关需求分析，我们可以画出Web端的用例图，实现相关用户以及用例的关系的可视化，作为以后的系统分析和两个平台端代码实现的前提基础，如图1.1所示。
图1.1 Web端博客部分用例图
Andriod端的功能与Web相似，区别在于Android端缺少留言管理，添加分享功能。相关用例图如图1.2所示。
图1.2 Android端博客部分用例图
1.3、系统性能分析
性能测试的目的是预计当前系统的性能要求，从而分析解决性能问题，避免不必要的风险。本系统移动端系统采用Android 6.0，开发采用API 23版本SDK，Java使用Jdk1.8，Tomcat的版本为8.0。服务器端支持高并发，但在访问量达到一定程度时，响应速度会变慢。在一定的并发数量系统正常运行并响应用户的请求操作，Android客户端和Web端可以正常获取服务器的信息并且进行相应的显示。
操作系统：Windows 7操作系统。
应用服务器：Tomcat8.0以上。系统数据库服务器是MYSQL，数据库操作可视化工具采用Navicat Premium 12。
浏览器：谷歌浏览器（Web端访问操作）
智能手机：Android6.0操作系统，SDK 23。物理内存为2G以上，手机内存4G以上，能正常开启数据流量和连接到移动互联网。
二、系统设计
2.1 系统概要设计
考虑相关功能的具体实现设计和每个模块之间的交互等具体问题的解决，这是在系统分析阶段的主要任务。系统分析结束后就要开始进行系统设计而这一步又是建立在系统分析的结果上，需求分析的目标是解决What的问题，相应的，系统设计的目的则是解决How的问题。
在概要（结构）设计阶段，按照一定的原则把把软件分解为多个模块层次，每个模块都会被指定一定的任务，并且模块间调用关系和接口也进行确定。
在这个阶段，主要考虑划分模块层次、分配功能、确定调用关系等，也需要支持模块的内部实现。在这个阶段，模块间的接口与传参过程要清楚，为了以防后续设计产生不必要的问题，需要标注准确的数据字典。功能重复的模块需要被合并，然后分解出可以复用的模块常常是典型的调整。在该阶段，可以重用的代码或者逻辑模块应被尽可能标记精练出，同时设计实现符合面向对象原则的系统结构，来提高系统性能，减少系统实现的代码量，数据流图、详细的数据字典以及每个部分的文本介绍等是概要设计文档的关键部分。
数据流图主要是以数据流向作为驱动来描述整个系统运行流程。该图是基于用例图，在用例图的基础上对其中相关功能部分关系的仅需一步细化。当用户在浏览器之上打开本地服务器地址后会进入所有的博客浏览界面，无论是用户还是游客，进入该网址后都可以进行博客浏览和相应博客的留言。当需要进一步发表博客或者进行博客、留言分类等的管理时，需要用户进行Login或者非用户Register。Login时提交账号和密码后，请求服务器进行页面跳转，服务器收到登陆请求和数据后，搜索数据库，Select查询成功后返回成功消息，并且跳转到用户的博客主界面。首页是对数据库相关数据的统计，包括博客，留言，日志等相关数据的统计，可以选择进行博客管理，留言管理，分类管理，个人设置等。进入博客管理后，请求服务器以列表的形式展示出所有博客的相关信息，可以进行修改和删除，同时也可以进入发表博客界面，需要填写博客标题，类别，博客正文是以Markdown编辑器进行编写。博客写完后，可以选择保存为草稿或者直接发表，点击按钮后，请求服务器进行数据库的添加，服务器操作数据库成功后返回成功信息，再次进入博客管理界面时，新的博客信息也会被显示出。进入留言界面时，向服务器请求留言数据，服务器进行数据库的Select并返回数据，当然也可以对每一条留言进行删除操作。
对于每一个Blog，都有相应的类别，还可以进行Classification management，请求Server进行类别的增删改查，最后就是个人设置，包括密码，邮箱，手机等信息的修改，Web端的数据流具体如图。
图2.1 Web端的数据流图
Android端的数据流动与Web端的最大区别在于数据的交互方式和通道。移动端的登陆、注册涉及MySQL数据库操作，所以需要通过HTTP协议向Server发送请求来实现数据验证，服务器接收请求并处理成功后，返回Json数据给客户端，客户端收到返回结果后，进行格式转化并判断后再进行相应的操作，类别管理等模块的相关请求过程与之相似。但是由于博客正文是在Markdown中撰写，难以进行格式，文字，图片的处理，所有在Android系统中使用加载网页的方式来展示和发表博客。具体的数据流图如图2.2所示。
图2.2 Android端的数据流图
2.2 系统详细设计
在具体设计阶段，需要详细准备进行各个模块的实现。在这个阶段，关注与每个模块，以概要设计的数据流和功能任务为依据，将模块的算法实现、关系转换、内部流程等内容用UML和文字说明表示出。根据概要设计文档，再进一步进行各个模块的详细设计。其中，如果需要进行结构修改的时候，需要从上一个阶段再开始，调整概要设计文档的部分内容，而不能直接解决，系统模块的流程图、类图，时序图等是具体设计文档重要的UML部分。
类图是一种显示系统中Entity的属性行为以及Entity之间关系的一种的Static model。在项目中主要体现为Java bean实体类，作为控制层和数据处理类的基础类。具体如图2.3所示。
图2.3 系统后台类图
项目主要包括用户类，博客类，类别类，评论类，操作日志类和图片文件类。用户类主要用于用户基本信息的操作，包括用户登陆，注册，信息修改时会调用该类，并且博客类还有一个图片类与之一一对应来表示用户头像。博客类是其中最主要的一个类，博客的增删改查都会调用该类，并且博客类中还有用户Id的属性用于连接博客温和用户。博客类中还有类别属性，该属性也会独立出成一个类别类，涉及类别的增删改查。除此之外，还有一个留言类，该类连接了用户类和博客类，并且用户和评论之间是N对M，博客和评论之间是1对N。
类图只能静态显示基本实体模型以及它们之间的关系，无法显示每个功能的请求时序，所以我们需要对相关功能进行顺序图的描述。
序列图是一种展示功能模块之间传递Message的过程的交互图，用户登陆功能的顺序图如图2.4所示。
图2.4 用户登陆顺序图
用户登陆成功后进行博文发表时的顺序图如图4.5所示。当然博文的其他操作以及其他设计服务器的操作也都与之过程相似。
图2.5 发表文章顺序图
2.3 数据库设计
数据库的设计对系统完成和可维护性非常重要，数据库设计决定了未来是否能够很好地维护数据，以后的需求是否得到很好的开发，还能确定系统性能。不恰当的数据库的关键功能更改可能导致对多个表的修改甚至重建，错误可能导致数据库数据不一致。解决这些问题。在数据库设计开始时，您需要考虑这些问题，减少冗余，提高Reuseablity，并减少未来的系统维护量。
数据库设计通常分为多个阶段，包括分析，设计（包括概要，逻辑和物理），数据库建立、测试和维护，数据库概念设计和逻辑设计是其中的主要部分。
概念设计主要是分析出相关的实体中的属性以及实体之间的关系，并画出E-R图来进行表示，E-R图可以体现出映射项目中相应类的数据库实体、每个的属性和他们之间联系。在基本满足数据库的三大范式表设计后，还要向更高层次的范式扩展，从而降低后台操作数据库产生的冗余，避免非主属性对码的部分和传递Rely等。博客后台数据库的E-R图具体如图2.6所示。
图2.6 数据库E-R图
在数据库中每一个实体就是一个表，与项目中的Java bean相对应，根据上面的实体联系图，我们可以将其转化为关系模型，其中涉及每个表中属性确立，主键确立，外键确立以及高层次范式确立，从而提高高数据库的操作效率，减少冗余。关系模型的转换后开始进行数据库物理设计方面，即在可视化的数据库管理系统Navicat中建表。一共有7个表，包括用户表来存储用户信息，博文表来存储所有博文的相关数据，头像文件表来存储与用户一一对应的用户头像，类型表用于存储系统中的博文可以有的所有类型，留言表由于存储所有的博客的所有留言，操作日志表则是用来存储最近的用户操作（包括登陆，博客处理，类型处理和个人设置）。
以上是一个大致的博客系统的分析与设计过程，考虑到了系统的基本需求功能、工作过程，数据库等，但还有设计过程不够全面，功能较少等缺点需要继续改进。
