专栏-练就面向构件的生产管理


 2005-10-15 00:00:00       763

在CMM认证越来越普及化的同时,大家在问,软件生产的管理问题在多大程度上能够得到解决?一方面,经过 CMM的认证,软件生产更加有序,更加可控。另一方面,软件本身的复杂度 正好被衬托了出来:在CMM过程中需要管理的工件(Artifact)每个阶段都不一样(参见图1)。因为每个阶段的工具、手段相对脱节,于是当我们的开发过程更规范 ,比如增加“设计”这样一个环节时,反而增加了交流成本和“理解变形”的机会。再加上人力资源、时间等方面的压力制约,每个 环节增加了成本,不一定有益于结果。
图1
 
雕刻家在创作的时候,在同一块石料上不停地工作,由粗到细到精,一直 完成艺术品。软件的生产,能不能也找到每个阶段的共同语言,使得软件的生产成为一个有机的、连续的过程?
 
面向构件的软件生产
 
构件正是这样一种语言要素。因为构件,每个软件生产环节的描述语言得 到了统一(参见图2)。面向构件方法用构件为中心组织整个生产过程,从分析、设计、开发 、测试、发布、管理、到维护,每个阶段都统一以构件为基本单位进行。
 
图2
 
分析
 
面向构件方法分析活动的核心工作是发现待开发系统所处的问题域中稳定 的概念。捕捉到这些概念之后,通过给每个概念分配职责,使起成为业务构件(Business Component)(参见图3)。
 
图3
 
这样一来,问题空间被分割成相互独立的业务构件。一方面,面 向对象方法论的精华被我们吸收了。面向对象方法论的最精妙之处在于理顺了抽象和细节的关系,让细节依赖于抽象(结构化方法则 是抽象依赖于细节),让开发过程的下游活动依赖于上游活动(结构化方法则相反,所以到了后期推翻前期的成果)。而业务构件也 是这样的抽象单元、稳定单元,任由业务规则千变万化,订单、账户这些业务概念本身还是稳定如故。另一方面,复杂问题被 分离成了多个相对独立的子问题,每个业务构件的具体设计和实现可以有不同团队来完成。
 
设计
 
与分析相比,设计的客体是解决方案域,分析的客体是问题域。如果说, 分析强调在问题域之内“发现”,那么设计则有稍多一点 “发明”的味道。在《打造面向构件的大型企业级应用》一文中,我们提出了“横切竖割兼收并 蓄的大型软件的系统架构”的观点。上面所述的将问题空间分割成业务构件就对应了面向功能的分而治之,下面的设计活动将专注于 面向技术的分而治之。
 
面向构件设计的核心工作是将业务构件映射到多个技术构件。典型的,完 成一个业务构件的多个技术构件会位于当前流行的层次体系结构的不同层。另一方面,业务构件更多地会体现在技术构件的接口之上 ,而不是技术构件本身;也正是这一点,才使得面向构件的体系结构非常稳定(参见图4)。对业务建模以及业务驱动方法有研究的朋友应该可以看出,面向构件 方法论借鉴和整合了大量方法论的优秀方面,这更说明了面向构件方法“兼收并蓄”的优点。
 
图4
 
构件生产机构的一个重要长期资产,及开发面向构件系统中最大的问题之 一,就是构件接口的定义。接口的探索和确定,可以借助UML中的交互图(顺序图或协作图)进行(参见图5)。
 
图5
 
实现
 
关于构件的实现,前面已经多次说过,可以重复借助面向对象的实现方式 ,在此不再赘述。值得说明的是,面向构件方法论提倡的“为重用而生产,为使用而组装”改变了开发时的情形。本质上,开发人员 可以分为构件开发者和应用组装者(参见图6)。 构件开发者负责构件本身的开发,并由测试等相关人员验证构件的完整性和正确性。应用组装者是构件 的使用者,将现有构件按照用户所提需求进行个性化组装,以“按单定做”的方式快速生产应用系统。随着时间的推移,相信软件行 业也会步入传统制造行业现在的生产方式--大规模定制。
 
图6
 
测试
 
作为明确的可交付工件,构造的每个阶段制造出准确详尽的规约,这些规 约提供了该阶段应如何进行测试(参见图7)。另外,必须指出,面向构件方法论对传统测试的概念有所影响。业务 构件的测试,一方面是集成测试,因为它是由多个技术构件协作完成的;另一方面,从业务构件的使用者角度看,它又是单元测试。
 
 
图7
 
发布
 
 面向构件方法论对迭代和增量开发的 支持,有天然的优势。每次增量发布,将一部分完成并通过测试的业务构件提供给用户,或提供给功能测试团队。
 
成熟的面向构件开发会显著减少软件的上市时间。当使用构件框架和面向 构件的模板时,其影响尤为显著。
 
管理
 
统计表明,有大批项目不是因为技术、而是因为管理上的问题而导致失败 。下面仅以面向构件的进度管理说明面向构件方法论对管理的强大支持。
 
面向构件方法论为项目管理中的进度管理提供了良好支持。任务的分配以 构件为单位,每个构件都会分配到具体的开发者。传统项目管理中,进度的度量往往靠主观估计,很不科学。面向构件方法论主张通 过评审、走查、测试等确认活动来决定构件的完成进度,下一节进行详细阐述。构件包的进度,由其包含的所有构件的完成进度统计 而得。开发者的考核,可以通过其负责的所有构件的完成进度统计而来(参见图8)。
 
图8
 
维护
 
由软件人员还是用户维护,这是个问题。
 
图9
 
个人电脑基本上是由用户维护的(对硬件开发的专业人员来说,老鸟也是 用户呀),因为电脑的构件化做到了面向功能级。面向构件的软件也应当由这种大粒度的、面向功能的构件组成。如果能实现用户维 护,可以说对软件界的影响是革命性的。面向构件应用支持通过更换零件来维护,当零件出现故障时,更换整个零件比修理它来得更 省钱更轻松(参见图9)。
 
面向构件的软件生产,使得软件生产的每个环节得来了统一。随着生产过 程,软件的轮廓越来越清楚,接口被定义,关系被理顺,细节被实现,测试可以与开发同步进行,而发布、管理也有了更加业务化的 定义。而在CMM中大家关心的配置管理也成了构件管理和构件演化的完整记录。我们企 盼着这一天的早日到来,并为之不懈努力。

相关阅读: