构件化软件工程的一些基本概念

所谓构件化, 是指软件体系结构可重组以及软件成份可重用的系统开发方法。构件是可用来构成软件系统的即插即用的软件成分, 是可以独立地制造、分发、销售、装配的二进制软件单元。它由以下三大要素构成:一、接口：接口告诉构件的用户该构件能完成什么功能。二、实现：实现就是让该构件得以运作的代码。一个构件可以有多个实现, 如一个构件可以同时有处理XML文件的实现和处理关系型数据库文件的实现。三、部署：部署是构件的存在形式, 一般即为二进制代码或可执行文件。这种方法的基本内涵是: 应用需求领域化, 软件结构框架化, 软件元素构件化, 应用原型实例化。

构件模型是对构件本质特征的抽象描述。构件模型规定了构件接口的结构以及构件与软件构架、构件与构件之间的交互机制。构件模型通常还提供创建和实现构件的指导原则。一个被所有构件生产者和构件复用者所接受的构件模型实际上起到了构件标准化的作用。

所谓的软件构件化, 就是要让软件开发像机械制造工业一样, 可以用各种标准和非标准的零件来进行组装, 或者像建筑业一样, 用各种建筑材料搭建成各式各样的建筑。软件的构件化和集成技术的目标是: 软件可以由不同厂商提供的, 用不同语言开发的, 在不同硬件平台上实现的软件构件, 方便地、动态地集成。这些构件要求能互操作, 它们可以放在本地的计算机上, 也可以分布式地放置在网上异构环境下的不同结点上。

基于构件的软件工程开发的基本思想

构件技术是应用级别的集成技术。其基本思想是将应用软件分解成为一个个独立的单元, 将软件开发地过程转变成为类似于搭积木的搭建过程, 通过组装不同的软件构件单元来实现软件的集成, 按照构件技术的观点, 应用软件的开发就成为各种不同构件的集成过程.

构件化软件系统的开发方法

基于构件的软件系统的开发以构件为核心, 而且在需求分析阶段就可着手进行构件收集工作, 增加了开发的并行程度, 这从另一个方面提高了开发效率。它的开发大体可以包括两部分: 一是构件的开发, 二是应用程序的开发。而基于构件的软件系统的开发方法是面向重用的,面向接口和面向连接的。如下图所示：

构件化软件开发的过程模型

基于构建的软件开发过程与传统的软件开发有着很大的不同。其中最显著的一点就是它的开发过程不再是算法+数据结构，而是构件的开发+基于体系结构的构件的组装。

构件化建模过程一般针对领域应用系统, 构件抽象则针对解域, 构件化模型即构架的生成过程是动态的, 软件重用粒度是组合级的. 领域应用是多个单一应用通用化和重用化的应用集群, 解域是问题域的过程与层次深化, 构件则是对象的软件实现与集成。

构件化方法可以概括为四个阶段、三个层次和两个过程。如图一所示

四个阶段是指：分析、设计、实现、评价。是过程并行与增量迭代等多种方法相结合的工作流模型。构件化方法是遵循软件生命周期规律的，在构件化方法中, 可以引入并行工程思想和能力成熟度模型(CMM ) 来进行局部过程改造, 以提高系统开发效率和持续优化效果; 可以引入领域工程思想和面向对象方法来改善建模机制, 以提高系统实施过程的可操作性。这就是面向构件方法论的主要过程特征。

第一阶段：分析。基于构件的软件开发过程的需求分析与传统的软件开发方法大体相同都是对对象领域内的共性特征、共性需求、共性结构以及可变特征、特有需求进行归纳和一致性描述, 本阶段的工作不必也未必能面面俱到, 可以随着以后行为分析的进行而不断地调整、具体、优化。

第二阶段：设计。这一阶段的主要任务包括根据目标系统的需要修改构件, 根据开发平台的需要对构件进行必要的改变以及对构件进行适当的升级以便取得更好的应用效果等等。这一阶段工作的核心就是对构件进行修改以求它能同其它构件兼容以及在特定的系统进行应用。这一阶段开始时需要系统的需求, 构件的需求以及构件开发相关的文件。结束后能够得到复合系统要求的构件和与系统集成和系统维护相关的文件。

为了保证基于构件的软件系统能够正常有效的进行运转。系统的架构设计是十分重要的。架构的设计是评估。选择和构建基于构件的软件系统架构的过程。系统架构设计的目标是综合用户的需求,确定系统的规范, 选择合适的架构和确定系统的实施细节。例如实施平台, 程序语言等等。通过研究和企业的具体实践来看基于构件的软件系统的架构应当是分层模块结构。软件的架构包括两大部分。一是应用层。它是支持一个企业正常运营的应用系统。二是构件层, 包括软件中的各个构件。 也分为三个层次。第一层包括仅仅应用在特殊的企业或者应用领域的构件。第二层指横跨企业内部的中层构件, 包括普通的软件和与其它应用实体的连接部分。第三层是指连接操作系统和其它相关硬件的基础性构件。

第三阶段：实现。在所有的构件都就绪后, 最后就是把这些构件按系统构架组装应用系统。组装过程完成构件的连接和约束工作。一般只需要编写些基本代码。诸如构件间的互相调用等即可。其过程大体包括四个部分集成, 测试, 改变构件和重新集成。

第四阶段：评价。软件的可复用性是人们评价一个软件的重要指标。确定一个系统能否满足特定的需求以及发现并改正系统实施过程中漏洞需要对其进行评价。而系统测试的目标是根据系统需求选择的构件集成的最终系统。系统测试应当包括功能测试和稳定性测试。在这一阶段中需要选择合适的测试方法，包括单元测试(测试单个构件)，集成测试(测试由构件构成的子系统)，系统测试(测试由子系统构成的整个系统)等。需要的材料包括构件设计，开发，修改阶段以及系统集成阶段的文件。通过系统测试可以得到系统维护阶段需要的资料。

构件化软件开发过程按三个层次展开：概念层, 逻辑层, 物理层。这与UML 描述、数据库设计模式和元建模技术等多种方法是一致的, 差别只在术语不同。 例如, 在基于UML 形式描述的面向对象建模中, 上述三个层次称概念层、说明层和实现层; 而在元建模中, 则称元知识层、结构知识层和算法知识层。

其过程是：首先从特定应用需求出发, 通过领域需求分析进行共性需求识别、领域对象抽象和领域知识获取, 以建立概念级的领域模型. 进而通过领域设计为领域需求寻求软件解决方案, 进入到第二层逻辑层，还包括构架级和构件级的设计模型; 这种模型体现了初步设计和详细设计成果, 体现了框架结构和部件结构的组成原理可行性, 因而是一种逻辑模型。由问题域的领域模型转化为解域的构架模型和构件模型, 是一个知识提取(正向) 和分析精化(逆向) 的迭代式增量开发过程. 第三, 根据领域应用开发或直接重用需要, 进行领域实现; 包括领域构件的识别、设计、编码和测试等局部过程集成, 系统构件的分类、检索、引用和构件库维护, 领域构件与系统构件的演化、例化、组合和应用原型的动态生成等领域框架整体集成, 从而建立符合领域应用的各种物理模型。第四, 通过运行模拟(正向)和设计优化(逆向)等措施, 对领域化软件原型进行可用性评价和可重构验证, 并对符合确认测试条件的应用系统进行全局封装和使用规范生成; 最终获得一个真正构件化的目标系统, 这是一个经过版本逐次寻优的实用软件系统.整个过程模型充分体现重构工程思想, 并把面向构件的软件开发分离为正向工程和逆向工程两大过程. 正向工程侧重体现自顶向下与过程并行特征, 解决软件构架和构件的可用性问题; 逆向工程侧重体现自底向上与增量迭代特征, 解决构架及构件的可重构性问题. 过程重构的基本内涵是, 概念重定义, 结构重说明, 算法重用, 系统重生成。

面向构件的建模支持机制

常用的构件化建模方法如, 面向对象方法及UML 描述,框架、实例及其规则描述, 巴科斯范式、谓词逻辑和体系结构描述语言(ADL )等形式化描述, Petri 网和导航图等可视化描述. 支持上述建模方法的典型机制如, 抽象类型, 元模式, 模板, 分布对象, 协作代理, 参数化框架, 导航图标, 软件总线, 以及设计词汇表. UML 描述提供了静态和动态两种建模机制. 在静态建模过程中, 可通过用例图来描述反映功能需求的领域模型, 通过类图、对象图和包图来描述面向对象的结构模型, 通过构件图和配置图来描述软件系统的实现模型. 在动态建模过程中, 可通过交互图、状态图和活动图来描述软件系统的行为模型;包括对象间的交互与协作, 对象的生命周期及状态转换, 事务处理及过程同步控制等.框架—规则—实例(称 FRI)描述是智能建模方法的推广应用. 框架(Framework)是描述结构性问题的基本骨架, 是一组实体、关联和约束的集合. 规则(Rule)可用于定义实体与实例之间的结构组装或集成方法, 是结构中各类元素交互与连接映射的集合. 实例(Instance)是描述问题解决方案的例化模板, 是一组特定的结构类型和元素类型即表示值的集合. FRI描述特别适用于软件构架设计及动态生成. 其它建模机制的作用如, 巴科斯范式可用于概念模型的规范化描述, 谓词逻辑可用于说明构架和构件的约束条件,ADL 语言可定义软件体系结构的风格, Petri 网可描述工作流和事务处理的动态特性, 导航图可用于构件库的组织与管理. 设计词汇表可用于定义构件和连接件的类型; 使得领域概念元素化, 功能分解原子化, 构件聚合结构化.

构件化软件工程方法中工程化方法与形式化方法

近几年来，随着软件产品结构不断复杂化以及基于因特网的web应用不断增多，学术界和产业界对软件质量的认识发生了改变，除了要考虑软件产品功能和性能外，还要考虑产品的可靠和安全。因此，如何减少软件开发过程中的缺陷，成为软件工程和信息安全共同的研究课题。根据“缺陷放大模型-以及业界大量的统计数据表明；修正软件缺陷的成本随着发现该缺陷的时间推迟而增长，50%-75%的缺陷是设计阶段注入的。因此，在软件开发的整个生命周期中考虑软件的安全性，特别是在产品设计阶段，分析软件架构的安全性"改进产品架构安全设计，为保障软件产品安全性起到了决定性的作用。同时，由于大型复杂软件产品  一般都是基于组件的，因此单个组件的安全并不能完全保障整个软件产品的安全性，还需要从软件的架构角度来确保产品安全性&而软件架构的安全性分析满足了从更抽象的高层次保障软件安全可靠的需求&此外"对常用软件架构模式或风格的安全性分析，也可以大大提高软件架构复用的安全性。

软件架构的安全性分析过程一般包含三个步骤：第一步是架构师根据软件需求进行架构设计。第二步是安全分析师在架构师的帮助下对架构进行建模或描述，同时还要对软件的安全需求或安全模型（机制）进行建模或描述；最后是安全分析师检查架构设计是否满足安全需求或安全模型（机制），如果不满足，安全分析师要根据分析结果指导架构师对软件架构进行重新设计，并再次执行上述检查直到获得安全的架构设计为止。

根据软件架构安全性分析过程中不同的研究思路和方法，我们将现有的方法分为两大类：一类是形式化的理论方法；一类是工程化的应用方法。

所谓形式化，从广义上讲，形式化方法是指离散数学的方法用于解决软件工程领域问题，主要包括精确的数学模型以及对模型的分析活动。狭义上讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。就形式化建模而言，形式化表示必须包含一组定义其语法语义的形式化规则。这些规则可用于分析给定的表达式是否符合语法规定，或证明该表达式具有某种性质。根据形式化的程度，可以把软件工程方法划分成非形式化、半形式化和形式化三类。使用自然语言描述需求规格说明，是典型的非形式化方法。使用数据流图或实体—关系图等图形符号建立模型，是典型的半形式化方法。

    用于开发计算机系统的形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一个方法有坚实的数学基础，那么它就是形式化的。

基于数学的形式化规格说明技术，目前还没有在软件产业界广泛应用，它确实有实质性的优点：形式化的规格说明可以用数学方法研究、验证(例如，一个正确的程序可以被证明满足其规格说明，两个规格说明可以被证明是等价的，规格说明中存在的某些形式的不完整性和不一致性可以被自动地检测出来)。此外，形式化的规格说明消除了二义性，而且它鼓励软件开发者在软件工程过程的早期阶段使用更严格的方法，从而可以减少差错。当然，形式化方法也有缺点：大多数形式化的规格说明主要关注于系统的功能和数据，而问题的时序、控制和行为等方面的需求却更难于表示。

软件开发的工程化是指将软件的开发企图变成工业化流水线一样的加工，从而保证开发的进度与质量。也就是说开发过程不再依赖于个人的技艺，而是依赖于整个工程的合理组织和工艺的标准化、规范化及过程的可视性。利用软件工程化方法开发软件系统，可以获得事半功倍的效果，并且可使软件在整个生命周期中实现良性循环。但软件工程化工作的周期通常比较长，行业还没有强制性验收标准，软件开发组织往往只着眼短期利益，不能够持续不断投入资源。软件组织经常会感到软件工程化工作的繁重复杂，没有现成的模式，不知如何有效的开展工程化工作。

这两类方法在安全性的描述、分析方法、分析过程、分析结果等方面存在不同的特征，其对比如下表所示。

表1 理论和应用方法的比较

结束语

本文通过引入构件技术软件工程方法的概念、基本思想、模型、支持的机制以及工程化方法和形式化方法。基于构件的软件开发已经不是什么新名词，但是目前世界上还没有开发商用构件的公司出现，还没有形成规模化专业化、商品化的构件生产，可供使用的商品化业务构件还很少，同时基于构件的开发方法还有许多有待于进一步解决的问题，如系统构件、组织构件及构件库的规范和标准化问题，与人工智能、软件自动化技术的进一步的结合问题等等。但是我们可以相信, 随着技术的不断发展, 采用构件化和软件复用的方法进行软件开发必将受到人们越来越多的重视。