网上报名系统的分析与设计

一个网上报名系统的分析与设计

实验考查内容：

以一个小型的简单软件系统为内容，考查学生的对于智能软件系统的分析与设计能力，包括：

（1）基于UML的面向对象分析与设计能力；

（2）关系数据库的使用与设计能力；

（3）面向对象的程序设计能力；

考查实验平台与工具：

（1）基于UML的分析与设计工具：Enterprise Architecture；

（2）关系数据库：MySql、SQL Server、Oracle；

（3）面向对象程序设计语言：C++ （Visual Studio 2007）；

1 设计模式概述

设计模式是设计面向对象软件过程中记录的知识和经验，用一系列类结构和对象来具体描述其含义。设计模式关注于可重复出现的结构设计方案的复用，提出了一个发生在特定设计环境中的可重复出现的设计问题，并提供了解决方案。设计模式使人们可以更加简单方便地复用成功的设计和体系结构，设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简单的说，设计模式可以帮助设计者更快更好地完成系统设计。

1.1 适配器模式（Adapter）

适配器模式可以将一个类的程序设计接口转换成另外一个接口，通过编写一个具有所需要的接口的类，然后让该类和拥有不同接口的类进行通信，使得原本由于接口不兼容而不能一起工作的那些类可以在一个程序里一起工作。有两种方法实现适配器：①类适配器②对象适配器。二者的差别在于一个通过继承而另一个通过对象组合的方式来实现。

1.2 工厂方法模式(Factory Method)

工厂方法模式对简单工厂模式进行了扩展，它不用一个专门的类来决定实例化哪一个子类，而是使用超类把这种决定延迟到每个子类，让子类决定创建哪一种对象。

1.3 桥接模式（Bridge）

桥接模式通过对象间的组合解除了抽象和实现间的固有的绑定的关系，使抽象部分与实现部分能够独立实现，将抽类的接口和它的实现分离，避免了使用继承机制所产生的客户代码与平台的相关性，使得无需修改客户端代码就可以改变或替换实现过程。在程序中，通常是使用面向对象中“子类化”的方法，即生成抽象类的不同子类来表示具体的变化。

2 设计模式的应用

2.1 系统简介

在该报名系统中，存储有报名数据的报名文件由专人负责上传，报名文件类型有多种，可以是access数据库、excel电子表格等等。报名系统负责从这些文件中读取相应信息，进行处理后，再存入到数据库中，而系统对所读取数据的处理方式也有多种，一种是团体报名处理方式，一种是个人报名处理方式，这两种报名处理方式截然不同。其中读取数据的文件类型以及处理数据所采取的方式，均由用户通过两个下拉列表框（界面控件）分别向系统提供。

2.2 具体设计及代码实现

2.2.1适配器模式实现

系统中，采用adapter模式，对下拉列表进行扩展。定义了DDListAdapter类中，增加了新的getFactory方法，其作用是根据用户对下拉列表的选择，而动态的生成相应的工厂类.从而扩展了原有的DropDownList类的功能。需要注意的是在创建DropDownList类的对象时，构造函数从配置文件中读取了所有需要创建的工厂类对象的类型名称，然后利用了微软.net平台提供的反射机制，动态的生成需要的工厂对象，既将生成工厂对象的决定权留给了用户，同时又将具体实现和客户代码完全分离，极大的提高了系统的灵活性。

部分代码如下：

public class DDListAdapter{

private ArrayList classes ;

private DropDownList dlist;

public DDListAdapter( DropDownList dl){

…//从配置文件中读取需要的类名，放到classes数组中

dlist = dl;

addToDropDownList();

}

public DBFactory getFactory() {

int i = dlist.SelectedIndex;

DBFactory dbfactory = (DBFactory)dlist.Items[i];

return dbfactory;

}

private void addToDropDownList() {

Assembly asb = Assembly.Load("factory.dll");

for(int i = 0; i < classes.count ; i++ ) {

Type t = asb.GetType(classes[i]);

DBFactory dbf = (DBFactory)Activiator.CreateInstance(t)；

dlist.Items.Add(dbf);

}

}

}

2.2.2 桥接模式实现

该系统最频繁的变化出现在两个方向上：数据存储方式和数据处理方式，这是系统中存在的两个明显的变化点。应用Bridge设计模式，将这两个方向上的变化分离开来，使它们在各自的维度上独立变化，而相互间不受影响。

用一个抽象类DBase来表示对不同数据文件读取操作的公共接口，然后分别派生出AxsDBase和ExlDBase两个类，实现对上传的access数据库和excel文件的具体操作。用另一个抽象类Signup来表示数据处理操作的公共接口，并且分别派生出IndividualSignup和GroupSignup 两个类。

部分代码如下：

public abstract class DBase {

protected DataTable dt;

public virtual void createDataTable(){};

...

}

public abstract class Signup {

protected DBase database ; //用于存放DBase的派生类

public virtual void importData(){}；

public Signup ( DDListAdapter dladapter ) {

DBFactory dbfactory = dladapter.getFactory();

database = dbfactory.getDBase();

}

}

其中DBase类中的createDataTable函数和Signup类中的importData函数都是虚函数，都需要这两个类的子类根据自己的功能来进行重载。在Signup类中为了决定使用DBase类的哪个子类对象，使用了前面创建的适配器对象来进行判断。

2.2.3 工厂方法模式实现

在系统的两个变化点中，存储数据的文件类型的变化尤为频繁，系统随时都有可能被要求对存储在新的文件类型中的数据进行读取，软件随时都有可能面临修改，因此如何降低软件维护的成本成为了本系统中的关键点。系统采用了工厂方法模式，并与前面适配器模式中引入的反射机制相结合，达到将这种必然的改动降到最低的目的。

构造了一个抽象类DBFactory，再由该类派生出AxsFactory和ExlFactory两个子类

部分代码如下：

public abstract class DBFactory{

public virtual string ToString(){}

public virtual DBase getDBase(){}

}

public class AxsFactory{

private ConnData data ;

public AxsFactory() { data = new ConnData()；}

public DBase getDBase(){ return new AxsDBase( data ); }

public override string ToString(){

return "Access数据库";

}

}

public class ExlFactory {

private ConnData data;

public ExlFactory() { data = new ConnData(); }

public DBase getDBase(){ return new ExlDBase( data ); }

public override string ToString(){

return "Excel文件";

}

}

DBFactory中的ToString方法必须在子类中实现，这样才能通过前面的适配器将工厂对象添加到相应的DropDownList控件中。

2.2.4 与.net反射机制的结合

引入了反射机制，主要是为了应对存储数据的文件类型的变化。在对系统进行编译时，需要将DBase抽象类和DBaseFactory抽象类及以及它们的所有子类，都放到一个文件factory.cs中，然后编译成factory.dll，同时将DBFactory类的所有子类的类型名称添加到一个配置文件中。

当系统需要对存储于新的文件类型中的数据进行读取时，只需要修改factory.cs文件，分别从DBase抽象类和DBFactory抽象类中派生出子类以完成相应功能。然后，重新编译该文件，更新相应的配置文件，再替换原工程中的同名文件即可，整个过程完全不涉及到对软件其他部分的修改。极大的提高了软件的扩展性。

3 系统优点

本系统紧密结合适配器模式、工厂方法模式和桥接模式，并引入微软.net平台提供的反射机制，既满足了系统的多样性和变化性，又保持了软件本身的通用性和扩展性。

1）通过桥接模式将系统中的两大变化点分离出来，并一一封装成类，使得这两个变化点可以独立的变动，杜绝了二者之间的相互影响。

2）通过适配器模式、工厂方法模式和桥接模式的结合，实现了面向接口的编程模式，将功能的具体实现从用户界面中分离出来，使得这两个层次间的变化相互独立，降低了软件的平台相关性，及高的提升了软件的维护性和扩展性。

3) 由于系统本身具有动态变化的特点，因此引入了微软.net平台提供的反射机制，使得在扩展系统时不用重新编译，而只需用新的类库和配置文件覆盖旧的类库和配置文件即可。

4总结

设计模式的应用可以简化系统的设计，使设计出来的系统的灵活性、复用性和移植性大大加强，并且极大的降低了软件后期维护的成本，它的提出，使软件开发具有了相当的规范性，方便了开发人员间的沟通。

本文就设计模式在报名系统中的应用进行了一定的研究和探讨，主要就报名系统中的几个关键问题，给出了相

应的设计模式解决方案。该报名系统的设计为解决分散式报名中的信息汇总分析，信息合并提供了合理的解决方案。根据处理方式的不同，它还可以引入到网上人事系统、业务协作信息系统中，完成数据收集的工作，并成为这两个系统的二次开发平台。

5基于UML的事业单位招考网上报名系统建模分析

事业单位招考的规模在扩大，使得招考报名工作十分繁琐，网上报名系统转变了传统的现场集中报名模式，方便了考生报名，减轻了报名管理工作的负荷，提升了工作效率，提高了考试管理机构的服务质量和服务水平，实现了报名工作的制度化、程序化、规范化和信息化。本文应用UML 建模技术对事业单位招考网上报名系统进行建模分析，使用UML 中的用例视图对网上报名系统的功能模块进行分析，用静态模型详细描述了系统模型的静态结构，用动态模型描述系统的行为和动作以及用例和对象的内部工作过程。

1 UML 建模概述

UML 是一种可视化的面向对象的模型分析语言。它的主要作用是帮助用户对系统进行面向对象的描述和建模。这种描述可以表示出这个软件开发过程从需求分析到实现和测试的全过程［1］。UML主要利用5 种图进行建模，5 种图分别如下。

( 1) 用例图: 从用户角度来描述系统功能，指出各个功能的操作者，并定义系统的边界。( 2) 静态图: 包括类图、对象图和包图。类图用于描述系统中类的结构和类之间的关系; 对象图相当于类图的实例; 包图是由包或类组成的，表示包与包之间的关系。

( 3) 行为图: 用于描述系统的动态模型和组成对象间的交互关系。

( 4) 交互图: 用于描述对象之间的交互关系，包括顺序图和协作图。

( 5) 实现图: 包括构件图和配置图。构件图用于显示系统中的软件组件及其相互关系; 配置图用于显示软硬件的物理体系结构。UML 的建模分为2 个部分: 静态建模和动态建模。建模过程分为以下3 个步骤:

( 1) 根据需求分析，得到系统UML 用例图，对网上报名系统进行描述;

( 2) 应用UML 类图建立系统各部分的静态模型;

( 3) 通过分析流程，得出系统的动态模型。

2 系统建模

2. 1 系统需求分析

开发系统的目标是满足用户的需求，给用户的工作带来方便。事业单位招考网上报名系统主要用户是考生和系统管理员，所以建模时必须包括他们需要的功能模块，这样开发出来的系统才有意义。

本文采用访谈调查的方法对部分考生和系统管理员进行了访问，记录下来他们对系统有哪些功能需求。主要有以下这些功能需求:

( 1) 考生主要功能需求: ①可以浏览考试相关信息; ②可以通过浏览器进行网上报名( 填报信息、上传照片、网上支付) ; ③可以在指定时间范围内修改报名信息或取消报名; ④可以在指定的时间内打印准考证; ⑤可以在成绩公布后查询考试成绩

2) 系统管理员功能需求: ①可以对网站进行维护( 信息的更新，界面的维护等) ; ②可以控制报名功能启动和停止; ③可以导出报名表并上报考试中心; ④依托银行和第三方系统———网上支付系统进行报名费的收取; ⑤可以对报名表进行统计报表、费用结算; ⑥考试

中心下发成绩后，可以将成绩单上传系统; ⑦可以对成绩进行浏览、查询、分析统计和打印报表。

2. 2 用例建模

建立用例模型的目的是描述系统的功能。建立用例模型首先要指出系统的边界和参入者( 用户) ，从用户需求中提取用例，其次描述操作者和系统的交互。由于在事业单位网上报名系统中，涉及到很多的用例和参入者，为此，按与系统交互对象的不同，将系统分为3 个包。如图1 所示。

图1 系统包图

考生与系统交互包主要描述考生使用系统的哪些功能( 用例) ，向系统输入哪些信息，从系统获取哪些信息。考生与系统交互的用例模型如图2 所示: 当考生登录系统以后，首先浏览考试信息，再填入报名信息、上传照片，报名成功后再支付报名费，打印准考证。如果报名信息有误或者放弃考试，考生重新登录修改信息或取消报名。

图2 考生与系统交互的用例模型

系统管理员与系统交互的用例模型如图3 所示: 系统管理员在报名开始时启动报名系

统，在报名截止时间停止报名系统。对系统的维护包括更新信息和系统界面的维护。对考生报名表进行编辑和维护。还可以对考生报名信息查询和打印报表。

图3 系统管理员和系统交互的用例模型

本系统和其他系统交互的用例模型如图4 所示: 考生支付报名费需要网上支付系统和银行的参入，考生试卷由考试中心批阅，成绩出来以后由考试中心成绩管理系统上传到各个网上报名系统。

图4 本系统和其他系统交互的用例模型

2. 3 静态结构建模

静态结构模型是网上报名系统静态结构的描述，主要是类图。类图是展现一系列类、接口、协作、包及其关系的视图［2］。它不仅定义系统中的类，表示类之间的联系如关联、依赖、泛化和实现等，也包括类的内部结构( 类的属性和操作) 。在建立静态模型之前，得先找出类。首先通过特定领域分析考察用例，抽象出类，并描述类之间的关系，再根据系统的具体情况和UML 设计的原则，采用高度抽象的方法，可将系统的基本模型元素和元素间的基本关系明确表示出来。在本网上报名系统中，抽象出来的实体类有系统用户、考生、系统管理员、成绩和考试等。用户类与系统管理员类和考生类之间是泛化关系，考试类与申论考试类和行测考试类也是泛化关系，考试中心( 接口)完成成绩的上传。限于篇幅，本文只对网上报名系统的实体类进行建模，来实现系统的总体的静态关系。事业单位网上报名系统的总体类图如图5 所示

图5 系统总体类图

2. 4 动态模型的建立

在面向对象的系统中，系统功能是由对象的相互作用来实现的。用动态模型来刻画用例的实现过程，以及对象间的动态行为［3］。在UML 的表现上，动态模型主要是建立系统的交互图和行为图。

( 1) 建立顺序图。交互图包括顺序图和协作图，但他们的侧重点不一样，顺序图着重体现交互的时间顺序，协作图着重体现交互对象的静态链接关系［4］。本建模系统主要强调时间和顺序，因此选择建立顺序图来分析系统。如图6 所示是网上报名用例的顺序图。图中涉及到5 个对象: 考生、报名界面、报考信息、报名和报名表。考生在网上报名时，首先登录报名系统的界面，阅读报考信息及政策再填写报名信息，若填写的信息有误可以修改，不想报考了，还可以取消报考。

图6 网上报名用例的顺序图

( 2) 建立活动图。行为图包括状态图和活动图。通常用状态图来表示单个对象在其生命周期中的行为，活动图描述满足用例要求所要进行的活动以及活动间的约束关系，且识别并行活动［5］。在本系统中的网上报名用例有多个参入对象，要进行多个活动，因此选择活动图来描述。

图7 网上报名模块的活动图

图7 是网上报名用例的活动图。其发生的第一个事件是阅读报考政策，如果考生不能满足此政策要求，就不能报考，整个活动结束。满足报考政策的考生填入个人信息和上传个人片，完成后提交信息。同时需数据库系统对个人信息和照片进行识别，符合要求网上报名，完成如果不符合要求，考生进行修改，再提交如此循环，直到符合要求

为止。

3 结论

本文首先建立了事业单位招考报名系统的用例模型，在用例模型的基础上，用类图把事业单位网上报名系统网上报名模块的静态结构进行了描述，用顺序图和活动图把该系统的上网报名模块的动态行为进行了描述。从建模过程可以看出UML 在系统建模和开发过程的优越性。它通过统一语义和符号使得大家愿意在建模上发挥自己的能力，把软件开发从原来的写程序发展到可以有很规范的结构和建模的方式。