构件编织之道


 2006-07-01 00:00:00       758

黄柳青  温 昱
大多数构件技术都集中在技术构件,但是我们也应该看到,
业务构件也被越来越多地用来封装那些业务功能中特定的可复用的部分。
--Hans-Erik Eriksson,《UML业务建模》
 
大型软件系统架构的历史
对于软件开发而言,保持关注点分离很重要。关注点的分离,往往是软件工程的核心所在。
整个面向构件方法体系的重点在于,通过恰当地分离关注点,保留并改善自治性;通过将业务空间构件化,能得到清晰完整的、面向构件的解空间。例如,如图1所示,面向构件的报表系统不仅从页面、流程、业务、运算、数据这一维度进行了关注点分离,还从功能、配置、管理这一维度分别将构件打包。这样,一个个高聚合的构件,成就了整个报表系统的松耦合品质。例如,报表配置和报表功能可以方便地复用同一个报表数据构件,而工作流和报表系统都可以使用同一个权限和角色管理业务构件,等等。

图1  面向构件的报表系统
关注点分离原则不应只局限于详细设计一级,在架构级也应当运用关注点分离原则,并且其作用将会更为根本。让我们一起来回顾大型软件的系统架构的历史(参见图2)。

图2 大型软件的系统架构的历史
从原始的一锅粥架构到垂直分割的结构化架构,是第一次“否定”。现在看来,根据功能把软件的“解决方案空间”进行“竖割”虽然耦合度较高,但这个缺点不能掩盖产生“竖割”的深刻原因--这其实是从用户视角对软件的“问题领域空间”分割的最自然方式。
之后,大浪淘沙,大型软件的系统架构告别了功能分解的垂直分割时代,步入了水平分割时代。这个时代和工业史上的“泰勒时代”有点儿象--从业人员从事他们最专长的工作。本质而言,大型软件的系统架构从以“问题领域空间”的结构为中心,变成了以“解决方案空间”的结构为中心。
其实,从业界当前的实践来看,还是以这种水平分割架构为主。大部分现代项目将技术架构分割成一定数目的逻辑层,每一层为其他层提供完全不同的技术服务,这样做可以说是利弊兼有
因为划分层次有利于关注点分离,使每一层次尽量只与系统的一个技术方面有关,所以层次策略对实际的团队开发模式有很好的支持。开发人员从事他们最专长的工作,负责相应层的开发。其实,层的早期叫法为“领域”,从这一点就可以看出分层策略对分工的天然支持。将技术架构分解为不同的层,在软件行业中得到普遍接受和广泛认同。
层次策略要求独立地构建每一层,完成之后再将它们链接在一起,面向构件的软件过程认为,这种方式是昂贵的,因为影响整个子系统功能的基本缺陷只有到各层协作时才能被发现。
我们来深入分析单纯的水平分割架构:
*  最终用户和需求分析的本质,决定了其“面向功能”的特点;
*  最终产品和团队开发的本质,决定了其“面向技术”的特点;
*  从宏观上看软件开发,它是一个从“用户需求”到“软件系统”的转换过程,因此,怎样解决“面向功能”到“面向技术”这两个正交维的转换问题,就成了任何方法都不容忽视的问题(参见图3)。

图3. “面向功能”与“面向技术”
一言以蔽之,问题依然存在。那么下一步的进化呢?我们预言,“否定之否定”的哲学规律将发生作用--为什么要完全否定“横切”和“竖割”的任一种呢--让我们迎来横切竖割、兼收并蓄的大型软件系统架构!然则,横切竖割、兼收并蓄的大型软件系统架构又如何设计呢?我们认为,答案就是“面向构件的软件开发”。

构件的分类
按照构件的复用粒度的大小和关注点的区别,我们将构件分为业务构件和服务构件。服务构件又按照其服务的层次分为展现构件、逻辑构件、运算构件、扩展构件。如图4所示。

图4  构件类型及关系图
上述两种构件被视为软件构件的不同类型,每种构件定义了截然不同的粒度等级及构件系统的不同视角。
业务构件是对自治的业务概念或业务过程的软件实现。它是大型分布式信息系统中自治的、可复用的元素,包含对特定业务概念进行描述、实现、和部署时所必须的所有软件工件。业务构件由一系列不同类型的服务构件所组成,完成相对独立、粗粒度的业务功能。
如果业务构件系统被很好地封装,并提供清晰的接口,那么,该系统就可以被当作一个黑盒,从而成为一个合格的构件。如此这般形成了业务构件方法中颗粒最粗的构件,这种形式的构件被称为“系统层面构件”。系统层面构件在以下两种情况下非常有用:涉及多个系统时,或必须以黑盒方式与业务构件系统进行互操作的时候。
服务构件是对展现构件、逻辑构件、运算构件等服务于特定逻辑层次的构件类型的统称。多个相同服务类别的服务构件又可以组装成为同类别的服务构件,多个不同服务类别的服务构件又可以和业务流程、用户界面、数据模型一起封装成为更大粒度的业务构件。
服务构件具有以下特点:
*        它具有定义清晰的开发时和运行时接口。
*        它可独立插入某个运行时环境。
*        运行期的可跟踪和可管理性
*        分离关注点,即业务功能与数据通讯等底层技术分离
*        使开发人员获得更清晰的构件模型
我们假设,一个服务构件是使用面向对象技术构造的,它有特定的架构、设计和实现模式。如图5所示,一个服务构件通常由一系列具体的编程语言类组成,但也可以构建在其他任何编程语言之上。

图5   服务构件与语言无关(图片来源:《Business Component Factory》)

构件编织
有了对横切竖割兼收并蓄的大型软件系统架构的认识、以及业务构件服务构件分类的理解,我们就感到如下理念显得水到渠成了:业务构件即为横切竖割架构的“竖割单元”,而服务构件则是其“横切单元”。
当业务关注点和技术关注点被分离、并分别被业务构件和服务构件来承载的问题解决之后,遗留的“把业务构件和服务构件联系在一起”的问题如何解决?答案就藏在业务构件的实现方式中--业务构件是服务构件“编织”而成的。
看来,面向构件方法正是这样一种横切竖割的技术架构:
* 业务构件是完成特定业务功能的整体,它是一个很符合最终用户和需求分析的“面向功能”特点的概念;
* 业务构件在面向构件的软件过程中是一个“大粒度构件”;
* 当前流行的层次策略依然保留,用于服务构件的分层,即展现构件、逻辑构件、运算构件、数据构件等。
图6展示了两个“业务构件”的例子:Shipper和OderTaker。它们都是由不同的展现构件、逻辑构件、运算构件、数据构件等“服务构件”“编织”而成的。

图6   业务构件示例
总而言之,支撑其面向构件软件过程的核心理念在于两方面:
* 业务构件与服务构件分离,业务构件是面向业务的自治单元,服务构件是面向技术的封装单位。
* 业务构件提供的具有业务意义的服务,是通过编织服务构件实现的。

相关阅读: