软件项目实训及课程设计指导——学习开展课程设计的预备知识和相关技术

软件项目实训及课程设计指导——学习开展课程设计的预备知识和相关技术

1、课程设计必须要“因材实施”和适应本校目前学生的知识和技术水平

目前有些高校计算机类及软件工程类本科在大二年级中就增加有课程设计的教学环节，而大二学生的编程开发方面的知识水平一般都停留在对某种语言（如C/C++、Java等）的应用级别，开发工具和测试平台基本上都还没有实际应用和真正掌握。这与真正的企业级应用系统的开发所要求的技术水平还有一定的差距。下图为企业级应用中所可能涉及到的相关技术。

因此，指导教师在设计课程设计中的相关项目的开发技术的深度和广度也应该要“因材实施”和适应本校目前学生的知识和技术水平。不同年级和不同层次的学校也都应该要结合本专业的培养目标和学生的知识层次开展不同层次的课程设计及相关的教学活动，不要拔苗助长，更不应该存在有全国统一的课程设计的教学标准。

作者在本文中主要是按照J2EE技术平台企业级应用系统开发中，开发人员所必须要具备的知识、技术水平和目前软件开发企业对用人的基本技术要求，罗列出下面的知识提纲，让计算机应用开发类和软件工程类的在校学生能够有所对照，并了解自身目前存在哪些方面的知识缺陷而及时有针对性地学习和提高。

当然，计算机应用开发类和软件工程类的在校学生也应该要加重对软件开发中的各种基础知识和理论性知识的学习和灵活应用。因为，没有深厚的“思想和原理”的武装，学生毕业后在企业中成长的“后劲”就会比较差或者“后劲”不足。下图为J2EE技术平台中主要的技术及应用架构示图。

2、明确企业级软件应用系统开发中的各种关注点

作者在下文中所罗列出的这些关注点与计算机应用开发类和软件工程类的在校学生在学校课堂中的知识学习时重点关注某个课程所涉及的技术的先进性是不同的，课堂学习时当然要学习最先进的技术、并熟悉对这些技术的具体应用、掌握相关的开发工具和测试平台等。而在企业级应用系统开发中首要的关注点并不是技术本身是否先进，而是软件应用系统本身所应该具备的稳定性、可扩展性和安全性等方面的要求是否能够满足和得以实现，其次才是对先进性技术的具体应用——适合项目的需要。

（1）应用系统的稳定性

企业应用系统首先是要保证软件系统本身在运行过程中的稳定性，因为软件应用系统是为企业的业务经营和数据处理提供各种服务和支撑的，随时的停机或者系统崩溃将会影响到企业业务活动的正常开展和给企业造成一定的经济损失。

（2）应用系统的可扩展性

企业的业务活动随着企业本身的发展和竞争的加剧，业务功能及软件应用系统的运行环境等方面的因素都有可能会发生变化和提出更高的应用要求。当然，企业的应用系统不应该是一次性的软件系统，必须能够适应和满足企业业务的各种变化的要求——这也就要求企业应用系统本身还必须要具有良好的可扩展性。

（3）应用系统的安全性

许多企业应用系统都涉及到企业本身经营过程中的各种机密的业务和生产数据，一旦这些数据丢失或者信息泄露，将会影响到企业本身的竞争力。因此，对企业应用系统提出安全性方面的要求是不言而逾的，保证软件系统本身安全可靠地运行和防范应用系统本身所可能遭遇到的各种形式的破坏也是必要的。

（4）应用系统的技术性

企业应用系统开发中并不一定要追求时髦的、先进的技术应用，而稳定和成熟的技术是企业应用系统开发中的首选技术——因为稳定和成熟的技术是开发人员所熟悉和了解、并能够把控的技术，这样能够降低应用新技术所可能带来的风险。

当然，企业应用系统的开发中也不能采用太落后的“老古董”式的技术——这将缩短应用系统的生命期。因此，在应用新技术之前，开发人员必须要预测出该新技术所可能带来的风险、并权衡利弊，合理地应用它们。

3、掌握模型视图控制器体系架构模式及具体应用

（1）什么是模型视图控制器（MVC）体系架构模式

MVC模式是软件系统设计的经典体系架构模式——它将一个复杂的应用系统分解为模型（Model）、视图（View）和控制器（Control）三部分，它们分别对应于应用系统中的业务逻辑和业务数据、用户操作界面、用户请求处理和数据显示的同步等系统功能模块。如下示图说明了MVC模式中的模型（Model）、视图（View）和控制器（Control）三部分之间的关系及交互。

（2）为什么要应用模型视图控制器体系架构模式

MVC体系架构模式是用来帮助软件系统的开发人员控制软件系统中的各种可能的“变化”（应用系统的功能、环境、性能等方面经常会发生改变）的一种体系架构设计模式。

基于MVC体系架构的应用系统能够具有良好的可扩展性和灵活性，因为应用系统中的业务处理功能和用户操作界面是分离的，两者之一发生变化时都不会导致对方也会产生被动地变化和修改，从而也就提高了企业应用系统的可扩展性。

（3）如何应用模型视图控制器体系架构模式

由于MVC体系架构模式倡导将应用系统中的业务逻辑处理、用户操作界面和请求处理等方面的功能实现代码各自要相互分离。为此，应该要将应用系统中完成业务逻辑实现的功能代码和反映用户操作界面的代码尽可能地独立和分离，并由控制器组件来担当两者交互的“门面（Façade）”或者“中介（Mediator）”——当然，在J2EE技术平台中可以通过应用各种支持MVC体系架构模式的开源框架如Struts和Struts2、JSF框架来保证。

4、了解Java技术平台中的各种编码规范和要求

（1）Java程序中包的命名规范

Java语言中的包是解决应用系统中同名符号冲突的一种机制，但在代码实现中如何合理地分离包中的内容？如何正确地进行包的命名？Java平台倡导采用反域名规则——如“com.px1987.项目名.模块名”的包名定义，而其中的域名可以采用学生所在学校的域名。

（2）类和接口的命名规范

面向对象的Java程序中的基本的组成单元是类和接口，为了提高项目实现中的各个模块代码的可读性，开发过程中也必须要遵守项目组中规定的类和接口的命名规范。Java程序中的类名一般应该采用大写字母开头，并达到“见名知意”的命名要求，如UserInfoServiceBean（完成用户信息处理的服务组件）、UserInfoDAOBean（完成用户信息数据访问的组件）等形式。

（3）类和接口中的成员方法的命名规范

类和接口中的成员方法代表该类或者接口对外的功能服务，大型的企业应用系统中的各个模块是分组或者分人协同开发的，成员方法的命名不应该出现“歧义”。一般采用“动词+名词”所形成的短语、并首字母小写。如doUserLogin（完成用户登陆处理）、doQueryUserInfo（完成查询用户信息处理）等形式。

（4）成员属性变量（对象）的命名

尽管面向对象类设计中倡导将属性封装以避免直接对它们的访问，而且根据JavaBean组件的规范，每个成员属性的get/set方法是依据对应的成员属性名称产生的——它们代表这些成员属性数据对外的访问接口，开发过程中也必须要注意正确地对成员属性变量（对象）的命名规范。下图所示为在MyEclipse IDE工具中自动产生出成员属性对应的get/set方法的局部截图。

在成员属性名称中的第一个单词的首字母要小写，从第二个单词之后的每个单词的首字母要大写。如firstName、userAge等形式，Java平台下的各种开发工具如MyEclipse IDE等将能够自动地为每个成员属性提供对应的get/set方法。

5、熟悉面向对象编程技术中有关类设计的五个基本原则

软件应用系统中的程序代码类的设计质量将直接影响到整个软件应用系统本身的整体质量，如何正确和合理地进行类的设计（包括类的结构、关系和职责分配等问题）？在面向对象编程技术中提供了各种设计思想和编程原则、乃至设计模式，而其中有关程序类设计的五个基本原则主要是指“依赖倒置原则”、“接口隔离原则”、“开放—闭合原则”和“单一职责原则”、“Liskov替换原则”。

但如何将这些设计原则在实际的企业级软件应用系统开发中加以体现和遵守、乃至灵活地应用？这些原则体现了哪些设计思想？希望读者一定要学习和掌握它们，并在软件应用系统的项目开发中灵活地加以应用。

（1）开放—闭合原则

软件应用系统中的各个功能模块应该要对软件应用系统的结构和功能方面的扩展开放（允许），但要对直接修改软件应用系统本身的程序代码行为加以禁止或者关闭（不允许）。

（2）单一责职原则

软件应用系统中的一个具体的设计元素（一般为程序功能类）只应该完成某一类型的功能（职责），而不应该设计和开发出“复合”功能的程序类。

（3）接口隔离原则

使用多个专门的接口比使用单一的复合总接口要优越，各个接口的可扩展性都比较高，而每个接口所对应的功能实现类也都内聚性高和各个功能实现类相互隔离。

（4）Liskov替换原则

派生类要与其对应的基类自相容，也就是要求基类中的各个抽象方法都要在派生类中加以具体的实现，并且一个具体的派生实现的子类应当只实现其接口和所继承的抽象类中所声明过的方法而不要出现其他附加的方法。下图中的示例代码为遵守Liskov替换原则的代码示例。

（5）依赖倒置原则

软件系统中的高层模块不应依赖于系统中的底层模块，两者都应该要依赖于某个抽象的元素（如接口或者抽象类等）；抽象元素不应该依赖于细节的具体实现元素，具体实现的细节元素应该要依赖于抽象元素。下面的左图代表以前传统的过程设计中是从上到下的一条依赖，应该修改为右图的依赖接口。