如何用UML和构件的描述生产线(组图)

 引言

随着中国正式加入世界贸易组织(WTO)，中国企业迫切需要尽快地实现信息化以适应即将到来的市场竞争，但是目前中国不过有1000多家大中型企业开始实施ERP(EnterpriseResourcePlan，企业资源计划)，这个数字占中国企业总数的比例还不到2.9%。由于ERP软件功能复杂、耗资巨大、维护成本相对较高，因此，研究如何借助于软件工程的软件重用思想和方法，提高ERP软件的开发效率，具有重大的意义。

软件重用是指，使用专为重用而设计的、预先定义的软件资产来构造组装软件系统的过程。软件生产线和CBSE是当前软件工程领域比较流行的软件重用实践活动，它们对工业化软件开发和维护都具有潜在的促进作用。它们解决软件重用问题的思路有所不同：软件生产线强调"自顶向下的重用"，即从体系结构或领域模型出发考虑系统的重用;而CBSE强调"自底向上的重用"即从系统最基本构件块搭建的方，式考虑系统的重用。两者的结合是目前最理想的重用手段。

UML是当今在面向对象领域占主导地位的标准建模语言，它融合了Booch、OMT和OOSE方法中的主要概念。它不仅可以支持面向对象的分析与设计，更重要的是能够有力的支持从需求分析开始的软件开发全过程。UML目前已经称为软件开发行业的既定标准，在当前和未来开发软件的过程中，使用UML建模已经称为软件成败的关键所在。但是，UML作为一种通用的建模语言，不可避免地丧失了某些重要特征我们归纳为以下几点：

UML没有明确地提供可变点的描述方法。

一个软件生产线是一组软件系统，它们共享通用的、受管理的设计和标准(或资产)，这些特征满足一个特定市场范围或任务的明确需求，而且它们按照规定的方式由公共的核心资产库开发而成。软件生产线通过抽取某一类应用系统的共性，建立可重用的核心资产;再通过对核心资产的定制生成多个类似应用系统的实例。因此，可变点对于软件生产线的体系结构(模型)描述十分重要。UML作为一种通用的建模语言，并未对软件生产线中可变点的定义提供明确的支持。

UML 语言对构件设计和描述没有明确的支持。

采用UML中的面向对象标记只能描述方法调用的交互类型，无法描述构件之间多样的连接类型;而且它们还不支持构件的层次结构的描述、系统族的定义等。

本文的后几节打算按以下几部分进行描述。第2节分析软件生产线的可变点问题，然后提供一种可变点描述方法。第3节描述基于可重用构件的软件生产线描述方法。第4节对本文工作进行了总结和展望。

软件生产线的可变点

软件生产线的体系结构

稳定而不失灵活性的体系结构是一个成功的软件生产线的基础。体系结构描述了软件产品线应用领域的业务体系结构共性和个性、支持该业务体系结构的信息体系结构、应用体系结构和技术体系结构。软件生产线为获得体系结构的重用，必须依据"低耦合、高内聚"的原则，设计能够适应变更的体系结构，这就要求在捕获需求时使用域分析的方法，对历史和前景进行分析(历史分析用于总结该类系统需求的不变点和可变点，前景分析用来预测系统需求今后可能发生的变化)，得到不变和可变的功能需求和质量场景。从体系结构的各个侧面来看，变更对体系结构影响的程度从大到小依次为业务、位置、技术、组织、信息和应用。要特别注意对族体系结构可变点的实现。详细设计的方案应使含有可变点的构件尽可能灵活地适应可变点的变化，提高构件的可重用性。

　　软件生产线的可变点分析

　　关于软件生产线的可变点描述，我们将以ERP软件的"库存子系统"为实例详细阐述。

　　对于单个应用系统而言，其可变点可以通过UML建模来实现。可变点可以作为类的属性来实现，例如：仓库中的某项器材的库存数量经常处于变动之中，这样我们可以为器材类添加一个"库存数量"的属性。可变点还可以通过继承的方式来实现，由同一父类派生出多个子类，每个子类完成特定的功能。这些都是标准UML语言可以支持的。

　　对于软件生产线，它的可变点存在于从需求分析直到设计、实现的各个阶段。例如：两个制造企业都要完成器材的出入库的功能，但是，某个企业在器材入合格库之间需要首先进入待验库，而另一个企业则无需经过器材检验的步骤。这种系统层的可变点通过标准UML语言无法实现。软件生产线的可变点描述既要实现同一产品族系统的集成，又要清晰地表现同一产品族内单个系统之间的可变性。

软件生产线的可变点描述

　　为了满足上述的可变点要求，我们提出了一种基于"选择模型"的软件生产线描述方法。该方法充分利用了UML语言的扩展机制，使用"Stereotype(范型)"描述软件生产线的体系结构中的可变点，其优点在于保证了与标准UML语言的兼容性，适合于广大熟悉UML语言的开发人员使用。此外，为了有效地管理整个软件生产线的可变点，我们采用基于"选择模型"的方式支持软件可变点的查找和控制。

　　图1是我们定义的一个库存系统软件生产线的用例图。该用例图中的可变点定义引入了"可选用例"和"可选角色"两个范型。图2和图3分别是依据该库存软件生产线生成的两个实例应用系统：A企业的库存系统用例图和B企业的库存系统用例图。

　　类似的扩展还同样可以应用于其他所需的UML图中，包括：类图、活动图、协作图等。从原则角度考虑，图中的每个元素，如：类、关联、继承，实际上都是可选的或者可以使用一套元素的其他进行替换。因此，扩展机制必须保证每种元素的可变性都可以进行定义。目前，我们采用的扩展机制还不是十分完善，有待于今后进行进一步研究。

　　"选择模型"的定义

为有效地控制上述UML模型的可变点将它们有效地连接在一起，定义了一个"选择模型"，它可描述为一个四元组{定制要求，解答，UML图，动作｝。定制要求：依据该软件生产线进行定制的开发人员会产生的问题，解答：开发人员做出的选择，UML图：列出对应该选择应该选择的相应的UML图;动作：列出这种选择相应产生的动作。具体样例如图4所示。

　　软件生产线的构件描述

　　虽然当前大多数方法都表明支持基于构件的软件工程(CBSE)，但是它们的重点通常集中在实现和发布阶段，而且趋向于将构件看作软件开发的"结果"，而不是软件开发的一个重要组成部分。

　　本文参考文献中提到的KbroA方法，针对ERP软件的特点，进行了扩充，提出以下的软件生产线的构件描述方法(CDES)。这种方法使得在分析和设计阶段就是完全面向构件的，而且将构件的实现描述与具体的构件标准COM+/EJB/CORBA)分离。该方法中的所有构件采用一组UML图形进行描述。

　　CDES方法将构件的描述分为三部分：管理层、规范层和实现层。管理层通过描述ERP软件的管理特征，提供构件的语义描述，主要通过用例图和活动图描述。规范层定义了构件对外的接口特征，即对应它所能满足的管理层功能需求，主要通过类图和顺序图描述。实现层定义如何通过底层的实现构件和实现类完成规范层定义的功能需求，主要通过类图、顺序图、配置图、构件图描述。

　　为了满足软件生产线的体系结构描述所需的的集成性和可变点特性，构件的描述应该始终与选择模型息息相关。选择模型指明了对于不同的应用系统应该如何进行构件的选择。规范层的类图描述通常十分简单，它只描述该系统对外所暴露的属性和特征。构件的实现层类图通常是规范层类图的子类，为了满足功能需求，通常还需要加入比规范层类图更多的新类。

　　结束语

　　本文的研究成果源自于作者在海尔工装设备公司和沈阳飞机工业集团公司两个企业的物资供应系统的开发经验，本文的研究成果已经应用于某制造企业的"物资采购供应系统"，我们在另一企业的库存子系统中应用上述的软件生产线体系结构描述，快速、有效地生成了新的实例应用系统。同时，我们完善了最初创建的软件生产线体系结构，使其可以面向更多领域的库存系统。

　　目前，我们的研究成果还不是特别完善。下一步还需要改进软件生产线中可变点的描述方法。"选择模型"还需要进行准确的形式化描述，以期能够实现一定程度的ERP软件自动生成功能。我们还希望在软件生产线的体系结构描述中借鉴Rational等公司正在极力推动的可重用软件资产规范(Reusable Asset Specification)，使其可以描述更加丰富的可重用软件资产。