积累面向构件的企业知识体系


 2005-11-14 00:00:00       753

我们常常把面向构件和汽车制造作比较。然而,并不存在一个大众化的汽车构件库,每个厂家从里面挑选构件来组装各自的汽车。各个汽车厂商有自己的构件库,估计通用汽车的汽化器就有几十上百种。而大家使用的、生产了几千年的椅子,更是千姿百态……

那么面向构件的积累在哪里呢?首先,我们要克服两个误区:一个误区认为有普遍通用的构件;一个误区认为随意写的一段软件就是可以积累的构件。实际上,汽车和家具的构件是针对某一个或几个相对接近的型号而言的,同时这些构件是经过精心设计的。软件构件在这方面也是共通的,是针对某个领域而言的。对于一些大中型企业来讲,因为本身的个性化需求,就需要设计一套自有的业务构件体系,是构件积累的个体单位。


面向构件的架构

"力量是一种关系",我相当喜欢温伯格的这句富有哲理的话。构件的力量在于它和其他构件的关系--不能和其他构件协作的构件是没有用的。

架构就是一种最大的积累。从本质上说,这是因为架构规定了相对独立的构件之间的关系。所谓软件架构,就是要用一种简洁的结构来支撑整个可以发展的软件系统。其中,架构机制(Architectural Mechanism)是不可或缺的。架构机制为通用问题提供通用解决方案,它即可以是具体的一组类,也可以是抽象的模式。通常而言,架构机制存在于分层架构的中下层,就好比一座大厦的供暖、供电、排水等系统,解决了整座大厦的不少通用问题。面向构件的架构为构件应用提供信息总线、工作流程管理、系统管理与监控等通用机制(参见图1)。

图1 基于EOS的应用系统架构图

我们在以前的专栏中提到过,面向构件方法综合了面向对象等方法的优点。在架构的支持之下,面向构件方法支持"programming by difference"式的开发--替换了一个构件的同时,就等于重用了其他的九千九百九十九个构件。而且这些被重用的构件,藏在明确定义的抽象职责层之后,不会跳出来使复杂性爆炸式上升。 因此,架构是积累和发展的基础,一个致力于企业知识积累和长足发展的组织,应当牢牢把握架构这一核心。下一节,我们将从数据定义、构件接口、构件分解等方面,具体谈一谈如何以架构为中心,进行面向构件的精确控制。


面向构件的精确控制力

致力于企业知识积累和长足发展的组织,必须理顺控制和被控制的问题。做个类比,面向对象方法中,由于依赖倒置原则适应了人类认识过程的规律,被奉为"面向对象设计的标志所在"。而对于企业知识积累而已,同样,如果企业不能成为"控制方",知识的一致性、完整性、长远性就不能得以保证。 企业应从以下几方面,以一种"以架构为中心"的方式,增强面向构件的精确控制力:

数据定义。从Business角度讲,数据怎么可能"冬眠"呢!对于一些大型应用系统而言,其不断增长的数据积累就是最重要的资产,比如电信BSS系统、银行OLTP系统、象Wal-Mart之类的零售商的数据仓库系统等。 在这些企业中,数据比应用更具长效性,是独立于任何应用来进行收集、规划、管理、发展的财富。因此,在企业知识积累过程中,企业应牢牢控制住数据定义这一环,并在数据定义工作中掌握主动。面向构件应用架构的数据分离原则,对上述活动给予很好的支持。 构件接口。切记,构件接口的定义是组织的重要长期资产!如果设计正确的话,组织所经营的业务会清晰地体现在"构件接口集"之上。构件接口和构件实现不同,构件实现是technology-focused的 ,而构件接口应当是business-focused的,这是面向构件应用之所以稳定的要求。企业知识的积累中,应当由企业掌握这"事关长远稳定"的构件接口定义的控制权。

构件分解。如果两个或更多事物中的一个发生变化,不会影响其他事物,这些事物就是正交的。正交性是面向构件分解的关键,如此一来,复杂性得以更好地控制;完成不同需求的一组组构件,都是相对隔离的;需求的改变,总能明确定位到少数构件,并避免变化的影响波及开去。值得说明的是,我们建议构件分解工作企业应当参与,而不建议完全"撂"给应用开发商--毕竟企业知识的积累将体现在构件上,企业必须保证构件分解的质量比较高--而构件分解的良莠更多属于"应用系统的质量属性"这样的"非功能需求"范畴,将非功能需求的控制大权旁落,天晓得在当前这种产业情形之下,会是什么结果。


企业和开发商的分工与合作

如果我们企业把软件系统的开发实施完全交给开发商或产品供应商,即使我们能够保障一个项目的适用性,我们也很难考虑软件的发展性和不同应用之间的协作。有的企业开始尝试自控项目管理的模式,把开发商当成开发资源融入团队由自己亲自从细管理,但是因为分工不明确或分工错位,企业团队承担了很大的责任和压力,项目实施效果失去了评判者。应当有所为有所不为。构件体系的精确控制能力和长期发展性,正是企业长期规划和项目控制的焦点。

好的,来总结一下企业和开发商的分工与合作(参见图2)。

图2 企业和开发商的分工与合作


构件库的组织

那么,企业构件库当如何组织呢?图3显示了如何组织多维检索的构件库,是不要需要的用户,可能从不同视角检索构件库,获得想要的构件。

图3 构件库的组织


积累面向构件的企业知识体系

一个基本完备的企业构件库,应当由基础构件库、业务构件库、行业构件库组成(参见图4)。基础构件库是大部分应用软件所常用的构件,相当多的部分用于诸如数据存取、安全、事务以及事件处理等服务的管理。有了这些通用服务,用户可以将注意力集中于业务级构件的开发上。业务构件库是一些跨行业的积累,而行业构件库专注于特定行业。

图4 企业构件库

企业构件库汇集了经过多次验证的软件成果,它们为大量应用系统所使用。构件库的建立和稳定化的过程,经历了规约、设计、实现、测试、部署等迭代化的步骤,其稳定可靠程度比传统应用的一般模块高一个数量级。另一方面,通过重用构件以"开发即组装"方式进行软件生产时,仅需经历规约、重用、部署等步骤,大大缩短了软件产品的上市时间。

随着知识经济的凸显,要想在复杂多变的经济环境中立足,企业需要在知识积累、传递、共享的过程中形成企业的核心能力。企业知识的显性化、构件化是企业知识管理的有效途径。面向构件的企业应用解决方案由若干个构件有机组成,用户可以通过既有构件的重新装配来实现新的业务需求,这样的应用模式有利于企业的长期积累,随着企业的发展,其构件化的业务知识也不断地积累,成为企业构件库,其核心竞争力也会不断提高。

相关阅读: