面向构件的软件开发方法学分析研究

面向构件的软件开发方法学研究
陈良山 200305018009
从软件建模方法论的角度看, 信息系统的开发方法已历经两代技术跨越: 面向过程, 包括面向功能和面向数据流。

面向对象, 体现功能与数据抽象方法的统一.20 世纪90 年代中期以来, 由于分布对象技术与软件重构工程的有机结合, 促使面向构件的软件开发方法应运而生.面向构件方法(COM >与面向对象方法(OOM > 的本质差异在于: 对象化建模过程一般针对单一应用系统, 对象抽象一般针对问题域, 对象模型的生成过程是静态的, 软件重用粒度是原子级的。

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

因此,COM 法与OOM 法在研究范畴、研究对象及其研究方法上都是有区别的. 不言而喻, 面向构件方法是21 世纪软件方法学的主流研究方向. 下面用过程与方法的组合理念来展开研究内容.
面向构件软件开发的一般过程
构件化软件开发的过程模型
所谓构件化, 是指软件体系结构可重组以及软件成份可重用的系统开发方法. 这种方法的基本内涵是: 应用需求领域化, 软件结构框架化, 软件元素构件化, 应用原型实例化. 这一思想可以概括为四个阶段、三个层次和两大过程, 如图 1 所示
从工程化与过程管理的角度讲, 整个软件系统的开发过程可定义为四个阶段: 分析, 设计,
实现, 评价. 但这并不是单纯的串行式瀑布模型, 而是过程并行与增量迭代等多种方法相结合的工作流模型. 多年来, 人们往往把系统阶段控制方法与软件建模抽象方法混为一谈。

最典型的是把生命周期法和原型法与面向过程和面向对象的方法混为一谈.
信息系统是一种具有生命周期的开放系统, 这是毋庸置疑的. 因此, 从工程管理及大的阶段控制过程看, 构件化方法与结构化方法和对象化方法一样, 仍然应该遵循软件生命周期规律。

差别在于, 前者的阶段论观点是弱化的历递归和过程重构特征. 换句话说, 在构件化方法中, 可以引入并行工程思想和能力成熟度模型(CMM > 来进行局部过程改造, 以提高系统开发效率和持续优化效果。

可以引入领域工程思想和面向对象方法来改善建模机制, 以提高系统实施过程
的可操作性. 这就是面向构件方法论的主要过程特征. 从模型化与内容抽象的角度讲, 构件化软件开发过程可按三个层次展开: 概念层, 逻辑层, 物理层. 这与UML 描述、数据库设计模式和元建模技术等多种方法是一致的, 差别只在术语不同. 例如, 在基于UML 形式描述的面向对象建模中, 上述三个层次称概念层、说明层和实现层。

而在元建模中, 则称元知识层、结构知识层和算法知识层.整个建模层次展开过程是: 首先从特定应用需求出发,
通过领域分析进行共性需求识别、领域对象抽象和领域知识获取, 以建立概念级的领域模型. 进而通过领域设计为领域需求寻求软件解决方案, 包括构架级和构件级的设计模型。

这种模型体现了初步设计和详细设计成果, 体现了框架结构和部件结构的组成原理可行性, 因而是一种逻辑模型. 由问题域的领域模型转化为解域的构架模型和构件模型, 是一个知识提取(正向> 和分析精化(逆向> 的迭代式增量开发过程. 第三, 根据领域应用开发或直接重用需要, 进行领域实现。

包括领域构件的识别、设计、编码和测试等局部过程集成,
系统构件的分类、检索、引用和构件库维护,
领域构件与系统构件的演化、例化、组合和应用原型的动态生成等领域框架整体集成,
从而建立符合领域应用的各种物理模型. 第四, 通过运行模拟(正向>和设计优化(逆向>等措施,
对领域化软件原型进行可用性评价和可重构验证,
并对符合确认测试条件的应用系统进行全局封装和使用规范生成。

最终获得一个真正构件化的目标系统,
这是一个经过版本逐次寻优的实用软件系统.整个过程模型充分体现重构工程思想,
并把面向构件的软件开发分离为正向工程和逆向工程两大过程.
正向工程侧重体现自顶向下与过程并行特征, 解决软件构架和构件的可用性问题。

逆向工程侧重体现自底向上与增量迭代特征, 解决构架及构件的可重构性问题. 过程重构的基本内涵是, 概念重定义, 结构重说明, 算法重用, 系统重生成.
面向构件的建模支持机制
常用的构件化建模方法如, 面向对象方法及UML 描述,框架、实例及其规则描述, 巴科斯范式、谓词逻辑和体系结构描述语言(ADL >等形式化描述, Petri 网和导航图等可视化描述. 支持上述建模方法的典型机制如, 抽象类型, 元模式, 模板, 分布对象, 协作代理, 参数化框架, 导航图标, 软件总线, 以及设计词汇表. UML 描述提供了静态和动态两种建模机制. 在静态建模过程中, 可通过用例图来描述反映功能需求的领域模型,
通过类图、对象图和包图来描述面向对象的结构模型,
通过构件图和配置图来描述软件系统的实现模型. 在动态建模过程中, 可通过交互图、状态图和活动图来描述软件系统的行为模型。

包括对象间的交互与协作,
对象的生命周期及状态转换, 事务处理及过程同步控制等.框架—规则—实例(称FR I>描述是智能建模方法的推广应用. 框架(Framework>是描述结构性问题的基本骨架, 是一组实体、关联和约束的集合.
规则(Rule>可用于定义实体与实例之间的结构组装或集成方法,
是结构中各类元素交互与连接映射的集合. 实例(Instance>是描述问题解决方案的例化模板, 是一组特定的结构类型和元素类型即表示值的集合. FR I描述特别适用于软件构架设计及动态生成. 其它建模机制的作用如, 巴科斯范式可用于概念模型的规范化描述,
谓词逻辑可用于说明构架和构件的约束条件,ADL 语言可定义软件体系结构的风格, Petri 网可描述工作流和事务处理的动态特性, 导航图可用于构件库的组织与管理. 设计词汇表可用于定义构件和连接件的类型。

使得领域概念元素化, 功能分解原子化, 构件聚合结构化.
领域工程及分析方法
领域工程的基本思想
在信息系统中, 领域(Domain>是具有相似应用范畴与共性需求抽象的问题域, 或者是与共性目标关联的应用域. 对于一个信息化企业来说, 领域概念通常涉及该企业所具有的行业特征和经营活动特征。

如机械、电子、化工或商贸领域, 管理、设计或制造领域. 可见, 领域给定了一个信息系统的工程实施背景和研究对象. 领域工程则是面向构件的理念工程, 其核心思想是: 应用模式领域化, 问题抽象通用化, 软件元素重用化, 开发过程工程化.应用模式领域化是一种从特殊到一般的总体归类方法,它根据特定应用系统的概念特征作出相似目标定位和领域划分, 寻求规范的需求描述和一致的概念设计, 从而使单一应用系统按照概念趋同模式向领域概念框架演化.问题抽象通用化是一种具体的需求识别方法, 是实现领域归类的关键技术. 需求通用化是需求领域化的技术延伸, 并从概念层扩展到说明层. 通用化抽象需要严格区分需求的共性、相似性和变异性, 以形成类化的需求分割。

把基本不变的问题抽象为共性模型, 把部分变化的问题抽象为相似模型,把频繁多变的问题抽象为变异模型.
共性模型和相似模型可用分类结构、继承机制及演化规则来统一描述。

变异模型可用代理结构、重载机制及例化规则来描述, 并提供用户自定义的工具支持. 通用化需要有抽象思维与分析高度, 没有抽象高度就没有问题通用性。

这正是领域分析的特点和难点所在.软件元素重用化使通用化的问题域模型进一步向解域深化. 通用是重用的基础, 重用是通用的目的. 软件重用同样可体现在三个层次: 概念级重用, 如领域知识、开发经验、建模方法和文档资源的重用。

逻辑级重用, 关键是软件体系结构重组和规则重用。

物理级重用的实质是构件重用, 包括模板共享、类库共享、子程序和函数调用等. 重用方法的引用包括组合式和生成式, 前者针对已有构件库,
后者针对形式描述工具和元生成器.开发过程工程化是一种行为方法论,
它不仅考虑信息系统的技术行为, 而且考虑与技术实施相适应的组织行为. 工程化的典型模式是,
把并行工程、重构工程、协同方法和系统集成技术与现代软件工程相结合, 形成“工程—
工程—产品—产业”一体化发展的工程研究环境和开发环境.
领域分析方法及形式描述
领域分析的基本出发点是,
寻求研究对象领域内共性需求、共性特征和共性结构的一致性描述,
寻求具有可变特征或相似功能覆盖的事务处理和对象抽象, 以获得概念化的领域模型. 在领域建模过程中, 理顺领域知识的分类关系极为重要, 它是规范概念和实现概念级元素重用的基础. 分类是面向对象方法的结构抽象策略, 它使领域知识可按不同层次和不同关系来组织, 以利将概念结构转化为静态的逻辑结构. 下面以集成供应链管理(ISCM >软件的研究开发为例, 说明领域模型的建立问题. ISCM 系统是企业信息系统的一个子集, 它把电子商务与供应链管理功能集成在一起. 与这种应用模式相适应, 任何一个企业的领域需求首先可以抽象为 5 大类: 目标, 组织, 流程, 资源, 环境. 进一步的抽象处理是, 把目标及其任务分解到组织和流程中。

再把组织中的职责与角色归入流程, 人员归入资源, 并通过工作流模式进行事务与数据融合. 经过二次抽象, 单个信息系统的领域需求可以归结为三要素, 即流程、资源和环境。

它也是ISCM 软件的共性需求. 换句话说, 在IS2 CM 软件开发过程中, 可以用事务流模型及事务对象来描述流程结构, 用类树模型及数据来描述资源结构, 用角色模型及实体来描述环境关联. 按照领域知识获取与组织方法, 三要素模型均可用概念元和概念结构来表示, 两者共同组成领域模型. 概念元可用巴科斯范式(或设计词汇表>来定义, 概念结构可用UML 用例图(图 2>来定义.
现给出 ISCM 领域模型的一些关键描述. ISCM 系统∷= 领域需求目标模型
领域需求∷= (流程, 资源, 环境>
流程∷= {活动集, 关系集}
资源∷= {人员, 资金, 物料, 信息, 时间}
环境∷= {顾客, 供应商, 竞争者, 变因}
目标模型∷= (概念模型, 逻辑模型, 物理模型>
概念模型∷= {元知识集, 结构知识集}
逻辑模型∷= {软构架, 关联集, 规则集}
物理模型∷= {构件集, 实例集, 说明文档}
软件构架与构件设计方法
构架设计及形式化描述
在软件系统中, 构架(A rchitecture> 即软件体系结构。

它是可预制和可重构的软件骨架, 是问题域模型转化为解域模型的框架式系统. 这里区分构架与框架, 即构架一般指解决问题的软件结构本身, 而框架则是用于描述各种系统结构的一种方法. 构架的典型实例如: 基于层次抽象程序解释执行与状态模拟的虚拟机结构. 根据实际应用需要, 上述单一软件结构可进一步组成多体系结构风格的分布计算系统, 如B S 与C S 集成体系结构. 框架则是可用于描述构架等总体结构的方法论体系. 框架的典型实例如, 采用巴科斯范式描述的概念结构, 采用类图描述的对象系统逻辑结构, 采用ADL 形式化描述的文本结构, 采用树型和网状拓扑描述的图形结构. 所以, 框架是研究构架的建模机制,
而构架可以是软件结构的框架描述.按照分布计算体系结构的思想,
任何一个应用软件的构架均可划分为三种构造逻辑:
一、界面表示逻辑, 用于覆盖与用户直接关联的前端应用。

二、事务处理逻辑, 体现软件的核心处理功能。

三、数据管理逻辑, 用于解决用户事务的数据交换和后端服务问题.
依据领域应用的复杂程度和系统平台的多线程能力, 事务逻辑可进一步细分, 形成多层应用体系结构。

但它本质上仍是三层构架. 三层构架划分思想既有利于保证用户、应用程序和数据三者之间的相互独立性,
以提高软件的整体执行效率和构架重组性能。

又与领域需求的三要素模型保持一致, 即用界面逻辑来覆盖环境需求, 用事务逻辑覆盖流程需求, 用数据逻辑覆盖资源需求.按照软件构架的逻辑构造思想,
每一种逻辑部件都可用特定功能的物理构件来实现。

而构件之间的相互连接及其组合规则与约束条件则构成一个完整的构架设计内容. 所以, 一个规范的软构架应由三要素组成: 构件(component>, 连接(connection> , 约束(constraint>。

称3C 构架模型. 所对应的实现模式是, 基于对象的基本构件, 基于角色关联的连接及接口件, 基于规则和参数配置的约束集合, 基于实例与连接约束的构架集成. 这种构架设计模式可归纳为:软构架= 软芯片(构件>+ 软总线(连接> + 控制使能(约束>若采用网状结构来定义构架及其要素之间的事务关联,采用树型结构来定义构架生成过程中所引用的资源,
则一个通用的构架模型可用网状结构与树型结构的组合模式来描述, 并采用树网分层机制进行管理, 如图 3 所示.
图 3 中, 基本构件的定义可分为两类: 一是已存在的系统构件, 由系统平台及开发工具自身携带的构件库所提供, 主要完成较低层功能。

二是新开发的领域构件, 主要提供应用领域的共性事务或特定事务处理功能, 提供高层次和大粒度的重用支持. 系统构件与领域构件之间可以相互演化, 并用构件库进行分类管理.
连接是构件间角色关联、交互协议、接口类型以及智能特性的逻辑描述,
其功能构造体便是连接件(connector>. 连接件亦可定义为两类: 一是数据通信接插件, 实例如消息、管道和事件广播。

二是进程控制接插件, 实例如过程调用、事件触发和数据缓存.
约束用于定义构件或实例之间的组合方式、交互规则和集成方法,
是概念层、说明层和实现层所有语义转换与描述规范的集合.
规范、规则与约束条件的完备集称规约. 在进行构架生成时, 需要对构件和连接件进行实例化, 以便规约的引用. 实例化可分成直接例化和增量例化,前者按初始条件将相关构件直接例化为可通用的固定部件。

后者按层次渐近例化思想, 把上层构件逐步例化为新的重用部件, 直至满足领域需求. 框架集成则把已实例化的构件按规约组装成可用构架.按图 3 框架展开, 一个完整的软件构架可形式化描述为:
构架∷= 构架模式构架模型
构架模式∷= (构架名, 类型说明>
构架类型∷= {指定风格的构件类型集}
构架模型∷= (构件, 连接。

约束>
构件∷= (构件名, 对象集, 行为代理。

接口>
对象集∷= {对象名(属性集, 行为集, 消息接口>}
行为代理∷= {角色名(责任, 权限, 交互方式>}
连接∷= (角色名, 关联集。

映射方法>
关联集定义了连接类型
关联集∷= {泛化, 聚集, 依赖。

串行, 并行, 回环}
约束∷= (结构规则, 行为规则, 语义说明>
结构规则∷= {满足条件的静态结构规则集}
行为规则∷= {满足条件的动态行为规则集}
构件模型设计及模板划分
构件是可预制和可重用的软件部件, 是组成构架的基本计算单元或数据储存单元, 是实现领域应用的功能封装体. 依据对领域知识的抽象程度和构造逻辑的划分需要, 可生成不同粒度级的构件元素。

如对象, 二进制对象, 函数, 例程, 类库,数据包, 过滤器, 触发器等. 这些构件可以设计成模型和模板的形式, 并以源文件、二进制文件和可执行文件的形式存放.一个规范的构件设计也可引入三要素:
概念(Concept>,内容(Content>, 语境(Context>。

称 3C 构件模型. 概念刻画了构件的概貌特征, 包括功能需求和数据存取的语义描述和接口说明. 内容是概念实现的软件体, 包括程序代码、脚本、设计文档和技术标准等. 语境即上下文, 用于刻画领域应用环境历定义的交互构件, 二是用作I O 信息交换的接口构件. 界面构件可覆盖领域应用的环境需求. 事务构件是领域构件设计的关键, 主要用于实现事务流程及处理活动。

并可分解为通用事务和专用事务两个子类. 通用事务构件可解决泛化问题, 即完成基本不变或相似的事务处理任务。

其中, 关键策略是实体或过程的参数化. 专用事务构件可解决特化问题, 即实现多变事务的实例化和用户自定义功能, 包括特定实体或过程的例化与重载. 按照可泛化或可特化事务抽象的程度, 一个构件功能可以对应一个原子事务, 也可覆盖一个事务流. 数据构件的提取与领域资源共享及数据存取服务模式有关, 可分为数据文件DF (含HTML 等文档>、数据库DB 和知识库 KB (含黑板系统>三个子类级. 以上是从静态的对象抽象的角度来识别构件. 若引入协同建模方法与多代理机制, 则可为构件模型增加动态交互能力。

如设置热点和移动对象, 设置限次限时等条件触发响应, 嵌入隐式调用结构. 此外, 构件模型中必须引入接口定义机制, 主要包括IDL 和AP I两大接口描述支持.综上所述, 一个完整的领域应用构件集可以划分为三个大类七个子类。

每个大类或子类构件均可用一个模板来实现,构件模板是可规范化、可参数化和可实例化的模块语义结构或程序源代码. 体现上述构件设计思想的模板结构定义为:构件模板= (构件类型, 参数, 处理功能, 引用接口>这种基于功能类化和模板粒度划分的构件模型如图 4 所示.
图 4 的关键内涵在于:①通过设计与实现的分离, 把构件定义为模型和模板。

模型描述构件结构, 模板描述构件算法.②通过实体与规约的分离, 例如交互构件与通信代理机制的分离, 大大提高了构件化建模效果与实现效果.③通过粒度分解, 把构件定义为原子级和组合级两大类。

这样既降低了构件的设计难度和实现代价, 又提高了构件的重用性能和管理水准.
构架与构件的基本实现
领域构架生成方法
前已指出, 一个规范的软件构架可从模式(Pattern> 和模型 (M odel> 两个不同侧面展开, 并可用面向构件的关联网及资源树结构来实现. 按照这一设计原理, 与图 3 相吻合的领域构架动态生成过程可用图 5 表示.
在图 5 中, 领域构架的实现过程综合运用了六种软件系结构风格: 在静态结构表示方面, 采用类树来组织对象和中央资源, 包括类化的对象库、数据库和例程库, 这些分类库统一用构件库模式来管理。

在动态结构生成方面, 采用关联网来组织构件或对象之间的组合(隐式显式> 调用过程和虚拟解释执行过程, 这种关联网是基于规则引用和构架重组的. 整个领域构架生成过程可按三段式递增过程展开:
①为系统平台或外部系统的公共对象提供直接的对象调用渠道, 包括IDL 引用定义或AP I包装定义, 以生成系统构件。

这些系统构件是一组与具体领域无关的标准服务构件,可用于演化或组装领域构件.
这一过程可在一组给定的构架组合条件和构件选择条件下进行.
②根据给定的构件组合条件或领域需求说明, 调用相关的系统构件和领域对象, 并按照角色关联进行规则引用及方法映射, 以生成领域构件. 这一过程需要进行模型的一致性检验, 以消除语义冲突.
③根据领域框架的集成要求和具体应用的实例化要求, 调用相关的领域构件和应用例程, 或者对领域构件进行基于实例的演化。

并根据框架、实例及其规则的完整性检验〔2〕, 最
终生成可用的领域构架.这一过程是最关键的, 需要进行静态检测和动态验证, 以消除语义冲突和结构冲突. 其中, 实例是应用例程模板化的结果。

实例化则为构件演化和构架生成过程提供了相关支持机制, 如参数选择, 例程修改, 处理变换, 规则匹配, 约束检验, 以及实体或过程自定义等.
领域构件实现方法
如前所述, 一个规范的领域构件可从模型和模板(Tem2p late> 两个不同侧面展开。

模型是逻辑设计的关键, 模板则是物理实现的关键. 从功能实现的角度讲, 模板是结构稳定、语义规范和具有派生能力的算法单元. 下面采用ADL 形式描述来定义一个典型事务构件模板
Component general_ transac
TransacTypeID ∷= GT
ObjectModel < object_ model_ description >
BehaviorAgents < behavior_ agent_ description >
Interfaces < interface_ declaration >
Constraints < constraint_ declaration >
object_ model_ descrip tion {
ObjectName∷= object_ name_ list ( n , object_ name >
A ttributes∷= < object_ name ( data_ solt_ interface > >
Behaviors∷= object_ name ( method_ solt >
method_ solt∷= solt_ name ( inheritance_ name , method_
nam e , p rocessing >
maps∷= role_ name ( role_ type , computation_ list >
M essageO rdering∷= "{" m sg_ name ( parameter_ list > "}" }
behavior_ agent_ descrip tion {
RoleName∷= role_ name_ list ( n , role_ name, role_ type >
role_ type∷= "{" m sg_ sender, m sg_ receiver "}"
Resposibilities∷= respons_ name ( action_ states , secure_
conditions >
Authorities∷= authority_ list ( authority_ level , resource_
list >
Interactives ∷= interactive_ list ( interactive_ fashion, role_
type > }
interface_ declaration {
in_ port ∷ = 2 role_ type w ith ( require_ list " &"
notification_
list >
out_ port ∷= + role_ type w ith ( require_ list "&" notifica
tion_ list > }
constraint_ declaration {
StructureConstraints structure_ constraint_ declaration
SemanticConstraints emantic_ constraint_ declaration
} End component general_ transac
结束语
文章引用典型的软件体系结构类型来描述面向构件方法的研究模型本身,
以展示构架与构件的建模思想和设计风范.所提出的概念、原理和方法,
在集成化电子商务与供应链管理软件开发过程中得到了深入应用, 并收到良好效果. 进一步的研究是, 给出面向构件方法学的理论框架和常用构架与构件实现的关键技术, 以从不同层次逐步完善面向构件的软件方法学体系.。