JAVA SMART系统-系统框架设计与开发

1 系统需求分析

SMART系统框架在实现上要求采用在J2EE领域中比较流行的SSH框架组合方式，并结合系统自身的一些特点来实现适合于本系统框架设计，该系统的一些非功能性的需求如下：

1.1 可扩展性要求

一般来说，软件的可扩展性决定着其适应变更能力的大小。事后我们总是可以很容易地评价某个程序是可扩展的还是不可扩展的，但是要想使这个系统在今后真正派上用场，我们必须事先就对它有个判断。一个系统一般都是要在不断升级的过程中去结合用户的需求来完善自身功能，因此该系统要求采用清晰的接口把对象的实现与它的交互分离开来，特定的实现就可以独立于应用的其他部分，各个实现也可以在将来很方便地修改、升级甚至彻底替换。这时的应用不再是一个单独的东西，而是一个系统中半独立的组件。多个开发者可以在相互不破坏彼此成果或者甚至在不了解全局场景的情况下协同开发。组件提供了特定的功能，允许独立地测试，也可以重用于多个应用中。如果组件之间工作分配及接口是很清晰的，这样的软件就很容易扩展。

1.2 可维护性要求

系统在开发完成以后，后期的维护也是一个项目中重要的一环，包括为了满足用户的使用体验对代码所作的修改；对上线后长时间运行过程中所出现的BUG所作的修改等等这些需求，都是要求一个系统是具有可维护性的特性的。

1.3 可伸缩性要求

可伸缩性和性能是紧密相关的，但是它们并不完全相同。可伸缩性可以广义地定义为应用在请求数目增长时维护性能的能力。在SMART系统中要求达到一个地市州级地区教育系统内的全体学生提供在线考试服务，并发数应在10000人以上。在本系统架构的中是采用分层的技术，这将可以很好的满足可扩展性与可维护性的要求，但是各层之间的通信又反过来制约了伸缩性。因此，就要求我们在架构设计的时候使用有成效的实践经验来连接这些层次。

1.4 可靠性要求

可靠的软件在所有时刻都会按照预期的那样执行。与可伸缩性类似，一个可靠的系统取决于对其底层组件的可预测性。从一个用户的角度来看，可靠性是对整个系统的判断，包括硬件、软件和网络元素。如果一个单独的组件发生故障了，并且用户无法访问应用或者应用工作不正确了，那么整个系统就是不可靠的。在SMART系统中的需求中，可靠性是首当其冲的，特别体现在考试的过程中。如果在考试的过程中系统出问题了，或者在考试后的阅卷中系统算错分了，这都将是灾难性的错误，从而导致严重的后果。因此，保证SMART系统的可靠性的至关重要的。

1 系统总体框架设计

1.1 总体结构说明

添加图片注释，不超过 140 字（可选）

1.1.1 表现层

如图1所示,在整个SMART系统的总体框架中表现层是结合J2EE领域的开源框架Struts来实现的，Struts能充分满足应用开发的需求，简单易用，该框架是基于MVC模式的来构建的，该模式将表达层分解为自包含的和可重用的几个部分，当用户通过浏览器发起HTTP请求时，该框架将利用其ActionForm将请求页面的非对象化的数据转化为对象，交由其对应Action来处理。基于MVC模式的整个交互的序列图如图7所示：

添加图片注释，不超过 140 字（可选）

开发人员利用该框架进行开发时，不用再自己实现全套MVC模式，节省了大量的开发时间。

1.1.1 业务层

如图1所示，在表现层与业务层之间利用一个公共代理类来完成交互，该代理类采用单例模式设计开发，在整个框架中起到了如下几点作用：

1. 减少耦合性

2. 避免生成大量的临时对象

在该代理类，实现一个对相应业务逻辑的处理方法，该方法的参数为一个封装好相应的页面数据对象、要调用的业务类的名称及该业务类中相应的处理方法名的类。

在该层中利用了Spring框架中的IoC模式(英文全名为Inversion of Control即反转模式)，该模式类似于著名的好莱坞原则：“Don't call us,we'll call you”，后被Martin Fowler改名为 Dependency Injection 依赖注射，也就是将类之间的关系通过第三方进行注射，不需要类自己去解决调用关系，实现了调用者和被调用者之间的解耦分离。IoC的引入并没有消除接口与实现类之间的联系，它的实质在于只是将这种联系转移了。在Spring的IoC实现中这关系被转移到相应的XML配置文件中，由Spring框架来提供对这种关系的依赖注入。其原理如图8所示：

添加图片注释，不超过 140 字（可选）

1.1.1 持久层

在SMART系统的整体框架中的持久层，是采用基于现有持久层框架的实现模式，在这种模式中，将最为繁琐的基于JDBC的OR映射工作，交由第三方组件（本框架中采用开源的Hibernate）来完成，这样就会在对数据访问对象进行编码时，大大的简化了一些繁琐而又复杂的编码工作，只需要利用Hibernate提供的API，对持久化对象进行操作。在该持久层框架提供了优秀的性能优化机制，如内置的数据库连接池支持，PreparedStatement缓存、数据缓存等。这些优化机制的综合使用大大提升了系统的性能。

在SMART系统的持久层中，对一些常用的添加、删除、更新数据库操作进行了抽象封装。并在Hibernate中配置相应的数据库连接池实现。

添加图片注释，不超过 140 字（可选）

1.1 总体结构设计与建模

1.1.1 公共代理机制的设计

在大部分采用B/S结构的web应用中，用户与系统的交互都是要涉及到相应的交互数据、业务逻辑，因此在本系统的框架设计中考虑到将这些交互中涉及到的因素全部封装到一个Carrier类中，再通过一个单例类来实现表现层与业务层的交互，这样用户操作时不用每次都去new一个临时的对象，也实现各功能模块中子程序之间的解耦。

1.1.2 系统接口设计

Java程序设计语言提供了两种机制，可以用来定义一个允许多个实现的类型：接口和抽象类。两种机制之间最明显的区别是，抽象类允许包含某些方法的实现，但是接口是不允许的。一个更为重要的不同之处在于，为了实现一个由抽象类定义的类型，它必须成为抽象类的一个子类。任何一个类，只要它定义了所有要求的方法，并且遵守通用约定，那么它就允许实现一个接口，不管这个类位于类层次的哪个地方。因为Java只允许单继承，所以，抽象类作为类型定义受到了极大的限制。接口使得我们可以构造出非层次结构的类型框架。例如：假设有一个接口代表一个singer(歌唱家)，另一个接口代表一个songwriter(作曲家)：

public interface Singer{

AudioClip Sing(Song s);

}

public interface SongWriter{

Song compose(boolean hit);

}

在现实生活中，有些歌唱家本身也是作曲家。因为是使用接口而不抽象类来定义这些类型，所以对于一个类而言，它同时实现Singer和Songwriter是完全允许的。实际上还可以定义第三个接口，它同时扩展了Singer和Songwriter，并且加入一些适合于这种组合的新方法:

public interface SingerSongwriter extends Singer,Songwriter{

AudioClip strum();

Void actSensitive();

}

如果要满足这样的一种灵活性，抽象类是不可能完成的。

虽然接口不允许包含方法的实现，但是，使用接口定义类型并不妨碍你为程序员提供实现上的帮助，在本系统的接口设计与实现中借鉴了Java API中的将接口类与抽象类的优点结合起来，将期望导出的每一个重要接口，都提供一个抽象类的骨架实现(skeletal implementation)类。按照惯有编码命名习惯，将该骨架实现类命名为AbstractInterface

在该系统中采用这种方式的来设计的接口有Business(业务)接口，DAO(数据访问对象)接口。

1.1.3 自定义标签的设计

在对系统的实现中，由于在表现层使用的是基于MVC的Struts框架，该框架中为了在表现层的JSP页面中不混合大量的Java代码，及保持JSP页面的程序的容易读性而提供了相应的Struts自己的一套标签，但是考虑到本系统的实际应用的功能实现。且这些功能实现又是Struts标签没法满足要求的，因此在该系统框架中实现了自己的一套标签，主要有<smart:submit></smart:submit>，<smart:select></smart:select>。

1. <smart:submit>标签：

设计意图：

在一般的基于B/S结构的web应用系统中，在页面上经常是会涉及到添加、编辑、删除几种常用的功能，在早期的一些开发编码中，相当一部分人是将这几种功能分为多个页面来实现，例如：添加用一个add.jsp页面，编辑用一个edit.jsp页面，删除用一个delete.jsp页面。而这些的页面的代码80%以上都基本上是一样的，只不过是上显示的按钮及在点击相应的提交给后台处理方法不一样。为了达到在一个页面上面实现添加、编辑、删除功能，并且要保持页面代码的清晰可读性，因此，在本系统框架中，封装了自定义的提交标签。

链接：https://pan.baidu.com/s/1gyHrdU1iwsTBiIKyk1lLmw?pwd=3333 
提取码：3333