内容发布更新时间 : 2024/5/8 1:04:33星期一 下面是文章的全部内容请认真阅读。

3 系统分析与设计 3.1 系统简介

本系统的主要功有，首先是对系统中用户、播放列表、歌曲、歌手等相关数据进行整合并存入数据库中，在需要时进行查询，并且还支持查看各类原型信息的查看、修改、删除等。通过本系统，用户可以很方便的了解到歌手的信息，以及专辑的信息，并且这些信息还可以保存在用的账户中，以便用户以后可以快速的查看。

3.2 系统框架设计

Struts 1.x原本是Apache中一个项目，但是现在已经成为java web开发中一个非常流行的网络框架，如果开发者想要基于Servlet和JSP创建一个可扩展的应用，Struts 1.x是一个不错的选择。而在后来的版本Struts 2.x中，是以WebWork为核心，从而使得那些与Servlet API相关的可避免的依赖关系不出现在核心业务控制层，不仅如此，Struts 2.x还提供了更方便的Validator、OGNL等工具，并且还抛弃了不繁琐的ActionForm。另外值得注意的一点是，一般软件的后续版本与之前本大同小异，没有什么根本的变化，但是在Struts框架中却不是这样，Struts 2.x和Struts 1.x具有完全不同核心，而它们具有相同的名字完全是因为Struts 1.x使用的广泛性。

本项目便是基于Struts 2.x搭建，并且在设计中使用了MVC模型，项目运行的逻辑如下：

（1）用户请求指定的Action；

（2）Action根据参数等条件进行导向；

（3）Action调用指定的业务逻辑完成后台操作并准备前台数据； （4）根据struts.xml配置文件将带有结果数据的前台页面反馈给浏览器。 数据持久化框架（Object-Relative Database-Mapping, ORM）一个在很多场景下对数据的访问都要求极其严格的框架，与Apache的iBatis提供的半自动化方式相比，Hibernate提供一种全自动化的数据持久化方案。在Hibernate中，

通过相应的文件配置，我们可以实现相同的程序在不同的数据库平台下后可以正常运行，并且不需要做任何修改，而因此Hibernate也成为了Java中最为流行的数据持久化框架。

使用通用JDBC编程，开发者需要编写大量的插入，更新，删除，选择等语句来操作数据库。但是，这些SQL语句往往因为数据库平台的不同而变化，这使得程序的维护变得非常麻烦。在Hibernate中我们可以使用HQL语句，根据HQL语法和配置好的数据库类型，将不变的HQL语句随环境的不同而转换成不同的SQL语句。

JDBC的缺点是，开发者必须关注数据库与POJO对象属性中的数据之间的映射关系，当多个POJO直接彼此带有关系映射时，该缺点更明显。因此可以通过合理的配置Hibernate使得自动的关联起表字段和类属性，自动维护单向或双向关系映射，那么开发者就可以很方便的对数据库进行操作。

在本项目当中我们除了使用Struts 2.x来创建Controller层外，还用到了文件上传的功能。在Structs 1.x中我们只能使用FormFile类来上传文件，但是在Structs 2.x中我们就可以直接使用java.io.File对文件进行操作，从而使得文件上传更加简单。

3.3 功能需求

本系统的需求方向主要分为“面向管理”、“面向体验”与“面向维护”共三个方面。 首先是面向管理，所谓管理就是指系统管理员在登录账户后可以对数据库中的各项数据进行增、删、查、改等操作；然后是面向体验，指普通用户或者没有账户的游客也可以在网站上搜索、播放、收藏自己喜欢的歌曲；而面向维护则指在后期的修改中开发者能最低程度的修改当前已有代码从而完成所需的功能。

项目中的功能与具体需求方向之间关系概括整理如图3-1所示。 图3-1 功能模块与需求方向

3.3.1面向管理的需求定义

面向管理的需求定理主要是针对系统管理员，涉及一般用户的内容比较少，并且不涉及未登录的用户。

在本项目当中我们对管理的定义为可以对数据进行添加、修改以及删除等操作，而一般的浏览、搜索或者播放歌曲并不归类在管理当中。当用户登录系统之后具有不同的身份，而根据不同的身份我们分配不同的权限，其中主要身份包括超级管理员、一般管理员、普通用户以及未登录用户几大类。

从表面上来看，超级管理员和普通管理员没有什么区别，但在权限上还是有些差别，比如超级管理员在用户管理上的权限要比普通管理员大。

“面向管理”的需求则是体现在系统的全局架构上，而并没有体现在任何一个单一的功能模块中。例如对系统架构解耦的要求，对页面代码复用率的要求等。

面向管理方向的功能需求归纳如图3-2所示。 图3-2 面向管理的需求定义

3.3.2面向体验的需求定义

“面向体验”则是指主要操作是浏览、搜索或者播放等，而不涉及数据的添加、修改、删除等。在本节定义的功能中，大多数以游客的身份就可以完成。

下面是需求定义图3-3所示。 图3-3 面向定义的需求定义

3.3.3面向维护的需求定义

一个好的系统不仅要求界面的美观以及功能的完善，而且需要后期维护的方便，所以在系统设计时就应该考虑这些问题，程序代码之间不应该只是简简单单的堆在一起，而是应该定义好每个模块的功能，从而能使得整个系统结构更加清晰，同样的，代码的复用率也是评判一个系统健壮性的重要标准。

本节所讨论的需求定义则是为了提高系统健壮性、可扩展性和代码质量而设定的。下面是需求定义如图3-4所示。

图3-4 面向维护的需求定义

这里列出的8条需求定义主要是为了整个系统的健壮性、逻辑安全性以及代码安全性，对于最终的功能上则没有什么影响，也就是说即使不使用SSH框架，不进行任何代码的复用，整个项目还是可以正常实现并运行，不过在各方面的效率相对较低。

（1）前台JSP页面的复用

在所有实现的代码当中JSP页面占了很大的比重，所以如果可以代码复用，那么后期维护将会极其便利，在本项目中所采取的复用策略是：

如果在布局和样式上有两个或者两个以上的页面相似，那么我们就考虑使用同一个页面完成相应的功能。

例如我们在设计页面的功能时发现，添加歌手信息界面和编辑歌手信息页面基本类似，不同就在于在添加歌手信息是表格里的内容都是没有值，而在修改歌手信息时，表格中相应的项都已经有值；另外一个不同就在于单击提交按钮后执行的操作不同；最后一个不同就是添加时歌手的ID值为空，为修改时歌手ID值不为空。

所以当我们遇到两个页面在布局和样式上基本一样时，而只有在内容上有细微的差异，我们就考虑使用一个页面来完成两部分功能，而不是使用不同的页面去显示。而我们采取这种方法不仅仅是为了精简代码，更是为了后期维护的便利。例如，如果页面要添加新的功能或者更换布局风格，那么我们在复用代码之后，就只需要修改一小部分代码就可以完成要求的功能，而不是像复用之前需要去修改所有页面相应的内容。

（2）后台代码的复用

后台也同样有复用的要求，这在软件工程理论中占有非常重要的地位。大致的策略为：

如果一个Java类文件中的某些方法或部分代码可以脱离其所在环境而独立完成指定的功能，而这部分功能还有另外至少1处被使用的场景，那么就将这些代码提取出来供多个Java类文件共同调用。

通常情况下，这种复用的代码都被放在*.util包中。 （3）码表：可扩展性

在我们的整个系统中，有很多部分都涉及到“静态列表信息”，比如在显示用户的所在地时，我们一般会选择select标签来实现选择的功能，但是在使用该标签是要注意，我们不能直接将所有所在地的信息直接写入在代码当中，而是应该先将这些信息存在数据库中，在需要时再从数据库中读取。

虽然在我们的项目当中这些信息基本不变，但是当项目应用到其他场景时，例如其他国家的人访问了我们的项目，那么我们就需要添加相应的地址，若果所有地址信息都是直接写到前端，那么我们就要修改所有有关地址的页面，而如果我们将这些信息写入到数据库中，则只需要一条SQL语句即可添加新地址。

码表是数据库中唯一的一张表，所有不同类型的静态列表信息都将存放在码表中，后台为前台加载信息时能够保证内容的动态性，通常我们使用JSP自定义标签来实现这个功能。

（4）系统安全性

本系统的安全性应当分为两个角度考虑：

第一，密码的安全性。首先不应该在任何地方保存用户密码的明文信息，正确的保存方式应该是通过MD5或者其他单项散列函数进行加密之后存储，另外由于自定义安全控件技术上难以实现，所以用户的明文密码也应该只能停留在浏览器的处理阶段。因为我们知道，一旦保存的数据库遭到黑客攻击，那么用户的密码信息将会泄露，而很多用户在不同的网站上基本使用相同的密码，如果密码以密文保存，那么黑客也无法破解出原密码，而如果以明文保存，那么将会给用户的隐私信息带来严重威胁。

第二，逻辑的安全性。在Structs框架中，后台的Action提供给前台所有的页面，而如果用户访问一个后台Action不存在的页面时，那么将会发生逻辑错误。而为了避免这类错误的发生，提高用户体验，并且防止非法用户通过暴力枚举的方式遍历网页目录，本系统将会处理这种情况，保证逻辑上的安全性。

3.4个性化音乐推荐系统设计

通过上面部分的需求分析的调差与研究将音乐推荐系统的功能设计如下图3-1所示。

音乐上传个性化音乐推荐系统单曲管理收集歌曲信息用户信息音乐检索音乐推荐

图3-1 个性化音乐推荐系统模块功能图

* 音乐上传：管理员对音乐进行分类包括音乐类型、音乐风格、音乐地区还有歌手类型并上传音乐。