结合面向对象和构件化技术的领域需求分析方法

软件的可复用性是人们评价一个软件系统的重要指标。软件复用是提高软件生产效率与质量的一种有效途径，它可以通过软件中的可复用构件(reusable component)来实现，即通过集成已有的构件来创建新系统。以领域分析为基础的特定领域复用(Domain-Specific Reuse)是提高软件复用水平的重要途经之一。将目标集中在一个特定应用领域中实现软件复用，从构件的开发到构件的存储与管理都比较容易。本文对结合面向对象、FODA方法和构件化思想的领域分析方法进行了初步探索，提出了构件化的领域分析方法，从而为在软件开发的前期阶段实现构件化开发，更加有效地实现软件复用提供了指导。

1 相关理论

1.1 软件复用

软件复用是指重复使用“为了复用目的而设计的软件”的过程。软件复用是在软件开发中避免重复劳动的解决方案，其出发点是应用系统的开发不再采用一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积累的知识和经验，如：需求分析结果、设计方案、源代码、测试计划及测试案例等，从而将开发的重点集中于应用的特有构成成分。

与软件复用相关的两个基本开发活动是面向复用的开发和基于复用的开发，前者是生产可复用构件的过程，后者是利用现有的可复用构件生产新系统的过程。它们分别对应领域工程和应用工程，处理好它们之间的关系，才能实现真正成功的软件复用。

1.2 领域工程

领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程，它覆盖了建立可复用的软件构件的所有活动。其中“领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。

领域工程是创建可复用构件的过程，其核心思想是：应用模式领域化，问题抽象通用化，软件元素重用化，开发过程工程化。实施领域工程的过程可以分为以下三个主要的阶段：
(1)领域分析：目标是获得领域模型。
(2)领域设计：目标是获得DSSA(特定领域软件体系结构)。
(3)领域实现：主要任务是依据领域模型和DSSA开发、组织可重用构件。

需要特别指出的是，领域工程的三个基本阶段所描述的过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前得到的结果进行修改和完善，再回到当前步骤，在新的基础上实施本阶段的过程。

1.3 面向特定领域的软件开发

与领域工程相对的是开发单个应用系统的软件工程的过程，称为应用工程。

在应用工程中，软件开发人员的任务是针对一组特定的需求产生一组特定的设计和实现。与此相对，在领域工程中，领域工程人员的基本任务是对一个领域中的所有系统进行抽象。领域工程的各个阶段主要是对应用工程中相应阶段产品的抽象，领域工程又对本领域中新系统的开发提供支持。在CBSE思想的指导下，基于构件的应用工程实际上是构件的组装过程。构件(Component)是指应用系统中可以明确辨识的构成成分。而可复用构件是指具有相对独立的功能和可复用价值的构件。随着对软件复用理解的深入，构件的概念已不再局限于源代码构件，而是延伸到需求、系统和软件的需求规约、系统和软件的构架、文档、测试案例和数据以及其他对开发活动有用的信息。这些可复用软件构件通过领域工程获得，作为应用工程开发的基本元素。

在开发实际的应用系统时，将领域工程与应用工程相结合，可以快速、有效地开发出用户满意的系统。两者相结合的软件开发模型如图1所示。

通过以上讨论可以看到，在面向领域的软件开发过程中，领域模型的建立是软件开发的基础。当开发同一领域的新系统时，可根据领域分析确定新应用的需求规约，以此来指导贯穿于整个开发的设计与组装。因此领域分析的成功与否，对今后的开发具有举足轻重的作用。领域分析的成功复用，可以从更抽象的层次实现软件复用。

1.4 领域分析

所谓领域分析(DA)就是在系统分析之前，分析、研究有关应用领域特性的活动。它是发现和记录某个领域各系统的共性和差异的过程，是系统化、形式化、有效复用的关键。通过领域分析，相似系统的公共特性将被提取，适用于该领域所有公共的、基本的对象、操作也将被标志出来，并且可通过定义模型描述它们之间的关系。领域分析的目标就是获得领域模型。领域模型(Domain Model)是领域中各系统的共同需求的描述。它描述了领域内系统需求上的共性。

1.4.1 FODA方法与特征模型

FODA对领域分析过程进行了完整的描述，特征概念是FODA方法的核心。所谓特征是指系统中的属性和特点，按特征在领域中的可选性及特征间的相互关系可分为三类：

(1)强制性特征：必须被选择的特征。
(2)可选特征：从0到n个可供选择的特征。
(3)可替换特征：至少有一个被选择的特征。

按特征的内容也可分为三类：
(1)功能相关：系统所作的事情。
(2)环境相关：系统是如何被使用的，变化点的原因。
(3)表示相关：系统信息是如何被用户所观察的或者是如何被相关应用所获得的。

特征模型通过使用抽象和细化的机制对领域中不同应用的所有特征进行了分类，从而提供了关于领域体系结构和可复用构件的高层视图。特征模型可作为应用开发者的地图，当应用开发者面对庞杂的Use Case模型或者其他模型时，特征模型提供了关于哪些是可选的、哪些是可合并的信息。

1.4.2 领域Use Case模型和动态模型

领域Use Case模型是RSEB(Reuse-Driven Soft-ware Engineering Business)方法为了表示领域中用户需求的不同之处对其进行扩展而形成的。但是领域Use Case模型无法详细地表示出系统工作流程。为了更详细地描述整个系统对象间的活动，考虑在领域Use Case模型中附加动态模型对工作流进行建模。领域Use Case模型和动态模型采用构件化的思想进行组装。动态模型可以采用uml的活动图描述，领域Use Case或单个的活动与活动图之间通过接口进行连接，并且有明确的标识，从而完整、独立、详尽地描述特征模型。在此还特别注意了可变性机制，可变性机制中主要是变化点和变体的表示。变化点是指在Use Case中不同应用之间的不同处理方式或处理对象的一种抽象，而变体是指变化点的一种具体实现方法。

为了领域Use Case模型和动态模型的构件化组装，在实际应用中定义了这些描述需求的构件接口，接口定义如下：

接口=(Provides，Requires)
其中，Provides为对外提供的功能/服务，Requires为对外要求的功能服务。
Provides=({provideFunction})
Requires=({requiredIncludedFunction}，{requiredExtendedFunction})
需要说明的是，在对外要求的功能/服务中，requiredIncludeFunction是必须满足的条件，requiredExtendFunction是可能满足的条件，从而增加了构件的灵活性和可变性。

2 构件化的领域分析方法

领域分析是提取构件和建立体系结构的关键。依据面向对象、FODA中特征的概念以及CBSE方法的一些思想，进行领域分析有以下几个步骤：

(1)建立领域边界模型：目的是定义领域的范围。
方法是，从待分析领域中确定包含哪些应用，表示出本领域系统的边界；从这些应用中找出所有与本领域进行交互的人或领域，并表示出它们的通用职责。为了确定领域的范围，可以根据领域知识用类似于高层抽象用例图的形式来表示。

(2)建立特征模型：目的是识别领域中应用的共同特征和可变特征。
方法是，在实际建模中利用开发的原型或现存系统寻找本领域中的通用功能和可选功能，抽象表示成强制性特征和可选的特征；然后找到相同功能的不同实现方法, 用可替换特征表示；最后考察模型中的特征是否可以被进一步分解为子特征，从而形成特征模型。

(3)建立领域Use Case模型和动态模型：目的是将领域内的特征描述完整化、独立化，并且具有可适应性和可标识性。通过此步可以描述整个领域的业务处理。

方法是，选择特征模型中强制性特征、可替换特征以及一些出现频率比较高的可选特征作为通用功能；将具有相似功能或者操作同一对象的功能组成一个Use Case，在组成一个Use Case时也要考虑复用力度的问题，根据复用的力度选择Use Case的规模；强制性特征、可选特征和可替换特征分别利用uml中的包含(include)、延伸(extend)和实现(realize)关系予以表示，从而映射到Use Case模型中，并且定义其接口；对于相对具体的Use Case，利用动态模型描述随时间发生的活动和参与的对象，并且定义接口与其描述的Use Case模型连接，对于某些活动可以继续定义动态模型并通过接口进行组装。

(4)建立对象模型：目的是抽象出主要的对象和类，描述领域中对象和类的静态关系，为下一步体系结构的建立打下基础。

方法是，将动态模型中的对象与领域Use Case模型中的名词相结合建立对象模型；把相同或相似的对象进行合并；最后再用使用、继承、参数化等机制实现变体。

综上所述，整个分析过程分为以上四步进行，但这四步不是线性的，是并行和迭代的。它是对以上模型不断精化的过程，可以分成几个周期不断循环进行，直至得到满意的领域模型。在此过程中，还有一个将所得模型构件化提交构件库的阶段，在此不作讨论。

3 应用分析

　　随着科学技术的不断发展，各高校、科研院所等单位的项目负责人在进行项目开展时，往往需要各部委等的基金资助，以保证项目的正常进行。如此多的项目基金的管理就相对地形成了一个基金管理领域。在这个领域中，利用基金管理系统可以大大提高基金机构管理的效率，实现办公自动化，以节省人力、物力和财力。通过领域工程，建立起基金管理领域模型和统一的构架以及对实现有用的构件，可指导领域内所有应用系统的开发。根据上述领域分析方法，我们在领域分析阶段将其应用于基金管理的模型开发中。

依据笔者对基金管理领域知识的了解并结合相关的基金管理系统，对基金管理系统进行领域边界分析，确定基金管理领域的领域边界模型。基金管理机构内一般包括基金管理者和维护系统运行的管理人员，基金管理机构外则涉及到基金申请者和评审专家。系统内外的参与者和领域的交互，就构成了基金管理系统的领域范围，领域边界模型如图2所示。

然后将基金管理系统所具有的功能特征(如专家评审、申请管理、专家管理和拨款等)、环境特征(如不同的基金管理机构提供不同的基金资助)和表示特征用特征模型表示出来。在这个模型中包括所有基金管理系统都具有的强制性特征(如专家管理、申请管理、拨款等)， 也包括可选特征(如并不是所有的基金管理机构都提供项目总结管理)，还包括可替换特征(如评审方式可以是在线评审也可以通过邮件发送文档的方式评审)。特征模型(部分)如图3所示。

再根据以上特征模型中的功能特征抽取出通用功能，包括用户登录、添加活动、修改活动、浏览信息、查询信息、统计打印信息、分配专家、专家评审等，将其用Use Case描述，如图4所示，并且还可以插入活动图。下面给出评审管理的部分描述，此处选用了专家评审这一用例，其中评审是变化点，它有2个变体(在线评审和邮件发送文件)。

其接口定义为：
Provides：
function setopinion( )
Requires：
Include：
Extend：function onlinegetinfor( )
将在线评审用例继续用活动图描述，在这个活动图中，对象object就是评审对象。
其接口定义为：
Provides：
function onlinegetinfor( )
Requires：
由上可知，通过接口的定义可以建立动态模型和Use Case模型之间的描述关系，如图5所示，从而更加具体地将特征模型映射到领域Use Case模型中。

接下来由面向对象方法及领域Use Case模型和动态模型得到对象模型，它描述了本领域中重要的对象和它们之间的关系。对象模型是领域应用系统的灵魂，通过对象之间的交互形成具体的应用系统的体系结构。从以上工作中可得到基金、申请者、专家、申请、资助项目、评审和单位七个类，变化点和变体可通过泛化在类图中表示。对象模型如图6所示。

至此建立了整个领域的领域模型，同时利用uml半形式化地描述了领域需求。根据领域模型，可以进一步建立DSSA，进行软件的下一步开发，将所得的可复用的构件加入构件库。在进行具体应用系统的开发时，通过提取可复用构件和开发新的专用构件，可完成整个应用系统的组装。

本文结合在基金管理领域中进行领域分析的实践，对构件化的领域分析过程进行了说明，该方法在建立特征模型的基础上，利用领域Use Case模型和动态模型构件化地分析了领域需求，并且表示了领域中对不同应用的不同处理方式。这样将可在软件开发的前期阶段实现构件化开发，有助于重用者更加方便有效地进行设计、实现阶段的构件化开发，实现软件开发的有效复用。