基于特征可变性建模教学服务管理系统的研究与实现

郑晓娟,刘 洋,陈祥科

(东北师范大学信息科学与技术学院,吉林 长春 130117)

0 引 言

自软件危机之后，软件复用的概念开始流行起来，作为软件复用领域重要方法的软件产品线得到了很大发展，发展软件产品线的关键问题是如何进行可变性管理,并基于可变性[1]管理实现软件核心资产的复用。而软件产品线[2]可变性建模[3]是可变性管理的关键技术。

可变性建模分为2个阶段[4]：

1)需求阶段的可变性处理。本文从软件产品线的需求出发，采用改进的特征建模方法，加强模型间的可追溯性和一致性，指导生成系统的特征模型。

2)设计阶段的可变性处理。本文引入分层思想设计领域参考架构模型的办法和可变构件的概念，利用可选的构件和接口实现设计阶段的可变性建模。

在实际开发中，将前面的理论成功应用到教学服务管理系统项目中，开发可复用构件，提高效率，验证该理论作为软件复用分支理论是实际可行的。

1 传统特征建模方法

软件产品线面向特征的领域方法成为领域建模的主流，卡内基·梅隆大学的软件工程研究所[5]率先提出了面向特征的领域分析方法FODA,支持对领域中系统共性和可变性的发现、分析和文档记录。后来经过整合和分析建立了一个高效的复用模型FeatuRESB[6]，该方法引入了可变点和变体的概念,表达一组同一维度的变化特征。Kang等人[7]进一步将上述方法扩展到设计阶段,提出了一种面向特征的复用FORM方法。张伟等人[8]在现有领域分析方法所使用的特征模型的基础上,对特征模型的组织框架和剪裁机制进行了统一、抽象的描述，引入行为层特点，给出建模过程，提出FODM方法。表1给出了一些经典的特征建模方法的比较。

表1 特征建模方法的比较

通过研究发现特征建模方法存在以下几个问题：

1)在共性与可变性的识别、可变点的构建、依赖关系确定上，只是领域专家依据经验进行判断，缺少有效的识别依据，无法保证准确性。

2)特征建模可变点[14]的表示方法不够精炼和明确，需求过多时，呈现形式复杂。

3)缺少模型与核心资产的映射关系，无法保证一致性和可追溯性。

4)构建特征模型缺少详细可操作的指南,使得领域分析人员在实践中很难有效地进行领域建模活动。

5)只是提出方法，并没有应用到开发中，缺乏实践指导意义。

2 特征建模方法的改进

传统的需求阶段特征建模的流程是：

1)可变点的确定。明确可变性产生的位置。

2)可变体的确定。可变体利用变量实现对应可变点的不同选择。

3)可变体变化形式的确定。根据系统的需求属性来确定可变性，可变性可分为3类:可选性、或选性和多选性。

4)可变体之间的依赖关系确定。分为需要和排斥2种依赖关系，根据依赖关系，实现构件的绑定[15]。

传统的设计阶段的特征建模的流程：软件产品线体系结构的设计，它包含的元素不应当是单一功能结构，而是包含领域内所有构件以及构件关联的规则，从领域中所有应用系统的体系结构抽象出更高层次的体系结构，这个共有的体系结构是针对领域可变性模型中的领域需求给出的解决方案，常规的表示方式是用UML表示各个接口的关系，这造成软件产品线产品较多，过于复杂。

在传统建模流程的基础上，针对上述发现的问题，本文分析5家教学服务管理系统的功能需求后，划分形成领域的特征集，并进行如下的改进：

1)进行特征共性与可变性识别，设计表格分析，引入数值化的计算，根据在系统族中特征存在的概率，如果概率在20%～80%之间，可判断为可变特征，根据层次划分和可变点表示符号，进行树状构建。

2)在依赖关系判断上，设计表格进行分析，在表格的首行和首列填写所有特征，引入数值表示行列特征之间的依赖排斥关系，分析得到依赖关系对。

3)特征树中可变点和可变体的表示形式上进行精简，原有3类可变性，但是在或选和多选中是互通的，只有变体选择的个数不同，所以确定或选与可选2种表示形式，加强了特征模型的可读性，根据以上3步，通过可变点构建和依赖关系确认，可以得到教学服务管理系统的全特征模型。

4)在体系结构设计的过程中引入分层思想与领域特征集分层相对应，加强映射关系，保证模型的一致性，在构件设计中实现构件间的交互关系，通过上述改进，有效地改善了传统UML建模的复杂性。

5)将软件产品线中可变性的思想，延伸到构件的设计中，提出可变构件的概念，并给出详细构件的内部设计，将可变性模型延伸到代码层面，提高模型的可操作性和实用性。

6)在应用工程层面上将方法成功应用到教学服务管理系统二次开发当中，根据教学服务管理全特征模型，将现有系统的共性特征进行保留，针对可变性特征，结合学院的情况，有针对地实现可变构件的开发，将可变构件配置到共性系统中，高效地对系统进行了完善。

针对缺少详细的建模指南，本文给出如图1所示的详细操作步骤。

图1 改进后建模方法开发过程

3 改进后特征建模方法在系统中应用

教学服务管理系统是为高校提供服务的，包括作业管理、论坛中心、教务管理等，解决高校多系统混杂而带来的功能冗余、数据分散、不便管理等多种问题。总体功能结构如图2所示，根据总体的功能结构进行可变性建模。

图2 教学服务管理系统总体功能结构

3.1 教学服务管理系统的特征识别

本文将分层思想延伸到特征收集阶段，将教学服务管理系统的特征划分为业务特征集、功能特征集和行为特征集，与体系结构的通用构件层、基础构件层、原子构件层相对应[16]。在进行产品线研究时，存在大量系统，需要选择一个子集作为样本系统。对样本系统需求的考察将显示领域需求的一个变化范围,所以选取5个满足条件的教学服务管理系统的需求模型和SRS，进行特征识别，得到5个系统特征集的并集，并对其进行有效划分，得到表2。

3.2 教学服务管理系统特征的共性与可变性识别

在建立特征模型前，需要对教学服务管理系统中的特征进行共性和可变性分析，便于可变点的确定与构建，依次建立业务特征集(见表3)、功能特征集和行为特征集的特征识别表，以业务特征集为例。设计表格首列为样本的系统集，首行为特征集，如果在系统1中s1存在则记为1，依次分析各特征。

定义1特征存在系数FPR：FPR=特征在样本集中为1的个数/样本系统集的个数。

如果FPR大于0.8的特征放入到共性特征集中，将FPR在0.2～0.8的特征放到可变特征集中，存在系数低于0.2的特征视为系统中不存在的特征。功能特征和行为特征的分析同理,根据分析得到可变特征集，如表4所示。

表2 教学服务管理系统特征集

表3 业务特征集的特征识别表

表4 教学服务管理系统的可变特征集

3.3 教学服务管理系统特征的可变性依赖关系识别

表5 特征依赖识别表

表6 特征依赖对表

3.4 教学服务管理系统的可变点与可变体构建

在变化点的构建上，需要遵循的原则是：

1)变化点中变体的构造上应遵从系统层次结构。

2)需要考虑变化点之间、变体之间、变体与变化点之间的排斥和需要关系。

按照上述表示方式和原则，构成树状可变点，如图3所示。

图3 教学服务管理系统中的变化点

3.5 教学服务管理系统的特征模型构建

1)以教学服务管理系统为根特征，依据先共性特征再可变性特征的顺序，树的第一层为业务特征，第二层为功能特征，第三层为行为特征，依次加入特征树模型中。

图4 教学服务管理系统全特征模型

3.6 教学服务管理系统的参考架构设计

通过可变性需求阶段的建模，参考架构的设计主要考虑2方面：

1)充分结合特征模型。在参考架构的设计中纳入特征模型的思想，便于可变构件的设计。

2)分层设计的思想。有效降低参考架构设计的复杂性，提高各阶段的可追溯性。

图5 软件产品线参考架构元模型

分析架构设计的基础知识，并对软件产品线架构的研究，本文提出软件产品线领域工程参考架构的元模型(见图5)，根据元模型对教学服务管理系统的体系结构进行分层设计：

1)数据逻辑层。主要为系统提供相应的数据服务，在教学服务管理系统中，为其设计数据库及其相关的软件支撑环境[18]。

2)基础构件层。是系统业务功能实现的核心支撑，上层构件可调用本层的基础构件。在本文系统中，基于面向构件标准的软件总线及服务，为构件之间的数据交换和通信提供可靠保障，包含运算构件、显示构件等为系统提供基础支撑功能的构件。

3)业务构件层。是4层结构，包括原子业务构件层、基础业务构件层、通用业务构件层和行为业务构件层[19]。

①原子业务构件层。主要是将业务对象进行适当分解，并对基础构件层的构件进行组合。该层包含短信收发、上传下载、邮件收发、文件导入等界面展示构件和数据处理构件。

②基础业务构件层。基础业务层构件利用原子业务层的构件，通过整合原子构件。该层包含教务通知发布、成绩导入、考场安排、作业上交等能够直接处理业务的构件。

③通用业务构件层。该层包括作业管理、教务通知、成绩管理、系统管理等一些能进行通用型业务处理的构件。

④行为业务构件层。行为应用构件层处于最高层，该层构件通过将原子业务构件或者基础业务构件进行组装，形成符合特定领域需求的领域构件，形成领域应用构件，如图6所示。

图6 教学服务管理系统参考架构

在完成教学服务系统参考架构后，将架构层次与特征集层次进行对应比较，可以在一定程度上保证模型间的一致性。

3.7 教学服务管理系统的可变构件设计

在构件和接口的设计中，需遵循以下原则：

1)可变构件[20]的设计上要有普通构件具备的能力：对外请求的接口集合、对外提供的接口集合、功能说明和构件规约。

2)要适应可变性建模表示的需要，所以本文将共性部分设计为必选构件，可变部分设计为可变构件，必选构件对应的接口需要被设计为必选接口，保证系统的完整性和确定性。

3)在对应或选可变性时，接口一定是必选的，不能因接口而导致构件的可变性发生变化。

4)在可变构件的设计和构造时，需要考虑系统需求和设计复杂度选择合适的粒度，以免造成模型过于复杂或简单。

与可变特征相对应，可变构件也有3种形式，分别为必选、可选和或选构件[17]，如图7所示

图7 构件的设计

通过参照教学服务管理系统特征模型和参考架构，利用可变构件的设计原则和方法，为教学服务管理系统设计可变构件，其部分构件如表7所示。

表7 教学服务管理系统可变构件列表(部分)

以邮件群发构件为例进行构件内部的设计：在信息推送时要用到邮件发送的功能，实现一个邮件内容多人发送的功能，是一个可选构件。构件对外提供的接口集合有发送邮件的功能，对内提供参数有发送者的邮件地址、登录邮箱的用户名、密码、邮件的标题、内容和接收人邮件的地址等，设计如图8所示。

图8 邮件群发构件的设计

4 教学服务系统的实现

4.1 可变构件的开发

在以上领域分析、设计的基础上，针对某院教学服务管理系统应用要求，开展应用工程。针对其特定的应用环境和特定的需求，对以上特征模型进行裁减，选择相应的特征，得到设计的可变构件。在原有网站基础上进行再开发，开发可变构件，二次完善系统。下面以邮件群发构件开发为例，利用PHP和OOP开发[21]，伪码如下：

function sendMail(＄to,＄title,＄content){

require_once(′//引用路径′);

＄mail=new PHPMailer();

//是否需要身份验证

＄mail->SMTPAuth=TRUE;

function sendMail(＄to, ＄title, ＄content){

＄mail->From="liuyangwill661@163.com";

＄mail->FromName="liuyang";

//发送邮件的服务协议地址

＄mail->Host="smtp.163.com";

＄mail->Username="phpseven";

＄mail->Password="phpseven777";

＄mail->AddAddress(＄to);//收件人

//邮件标题内容

＄mail->Subject=＄title;

＄mail->Body=＄content;

return(＄mail->Send());

}}

上述代码是调用邮件群发构件的部分代码，其中调用send()方法，实现邮件多人发送的功能，借助163邮箱现有的服务器，作为实现邮件群发的基础，实现参数的设置，通过提供方法内部参数，可以实现群发邮件的功能，本构件并没有对前端页面和按钮进行封装，更有利于后期复用的兼容性。

4.2 教学服务管理系统实现

在教学服务管理系统应用工程阶段，针对特定的应用和需求，在具体的系统分析、设计后，一方面可以复用以上特征分析和特征建模的结果、系统框架和构件的设计，另一方面可以根据实际情况，二次开发适合具体应用特定业务构件和应用实例，然后进行系统集成配置。其运行界面如图9～图12所示。

图9 教学服务管理系统的学生主界面

图10 教学服务管理系统的学生作业管理界面

图11 教学服务管理系统的学生考试安排界面

图12 教学服务管理系统的学生论坛中心界面

4.3 实现效果评价

主要比较一次开发(见表8)和建模后开发(见表9)的相关参数，对效率进行度量。参数包括上线时间、资产库中增加的数量、需求设计阶段的工作量、学生与教务人员的满意度[22]。

表8 一次开发相关参数

表9 建模后开发相关参数

在开发效率上，收集开发过程中所消耗时间的反馈，前期可变性模型的创建有效地缩短了开发时间，提高了开发效率，同时构件的增加也为后序的复用提供支持。

在开发的质量上，虽然前期的需求和设计阶段消耗了一定的时间，但是可以帮助开发人员更加了解这个领域，开发出更加有针对性和满意度更高的功能需求和构件。

通过上述的比较发现，将改进后的特征模型应用于教学服务管理系统，可以有效地降低开发成本，提高用户的满意度。

5 结束语

本文旨在解决需求和设计阶段的可变性建模以及系统高效的实现,成功将此方法应用在教学服务管理系统产品线的开发过程中。通过提升可变性建模和管理层次，能更好地维护体系结构可变性的一致性配置，并给予可变性建模详细的操作指南，为实施的产品线提供良好的指导。根据可变模型的分析，得出可变构件，降低开发成本，未来可不断完善和丰富构件库以及软件产品线核心资产，形成产品体系，从根源上提高开发效率。