【IT168 技术文章】

    意图

    无论哪一种过程，其最终目的都是为了产生出可执行、并且可用的软件。因此软件过程中的各种活动应该围绕着快速、准确的实现这一目的而展开的。

    示例

    维力亚软件公司是一家合资公司，由于有外资背景，公司内部很早就引入了软件工程，并严格的对人员角色进行分工。包括领域建模人员、架构设计师、高级程序员、程序员、界面设计师等等多种角色。每个人各司其职，充分发挥出了分工的特点。但是随着公司开发项目的逐渐增多，这种方式也显露出其弊端来。每个人的主要目标都是为了通过评审，而有时候，就算是通过评审的工件，依然可能存在问题。但这时候扯皮就出现了。项目中存在的一些中空地带。以及交错地带，常常发生无人问津的情况。开发过程的效率开始下降，开发成本开始上升。问题虽然不是一下子出现的，但是已经逐渐变得严重起来了。

    上下文

    我们在进行过程设计，或引入一个过程理论的时候，有没有思考过该过程的每一个阶段、每一个活动的目的是什么，它们对生成最后的软件有什么样的帮助，这些帮助对于我们所在的组织有意义吗。很多情况下，我们并没有这么做，或者随着软件过程的定型，就不再思考这类的问题。一开始并没有什么了不起的，但是当软件过程演变成了一种政治体系的时候，那么问题就会慢慢严重起来。

    问题

    如何让过程围绕着产出软件的核心目标而不断演进？

    方法

    从上一篇介绍的内容中，我们知道软件过程的每一个阶段都是知识转换的过程，知识转换的终点就是软件。问题在于，我们如何保证这种转换的效率呢？
   
    现代软件的发展的趋势是重用。我们开发一个软件已经很少会从最底层开始编写了。我们使用各种各样的技术和平台。包括数据库、分布式体系、UI机制、业务元素等等。因此现在的软件编写往往都是站在巨人的肩膀上开始的。不同的软件组织，肩膀的高低也不一样。比如有的软件组织使用J2EE平台，有的软件组织则使用.NET平台。但是可以肯定的一点是，每个软件组织都或多或少的拥有自己的平台体系开发经验。这些经验的表现形式也不尽相同，可能是保存在某些高级技术人员的脑中，也可能是保存为文档、模型或代码的形式。

    对于单个的项目而言，其过程一定是从需求开始，以部署（以及后续维护）为终结的。但是对于长时间存在的软件组织而言，更重要的是项目经验、技术经验、管理经验的积累。这样说可能过于抽象，我们举一个具体的例子。在完成了一个库存管理项目之后，我们把库存管理的领域知识制作为商业组件的形式，而把项目中学习到的一些编码的技巧整理为模式的形式，并把项目过程中积累的过程方法添加到现有的软件过程中。这些经验的堆积就是在一开始我们提出的可重用框架。对一个软件团队的来说，它的所有软件项目都应该是围绕着这一个可重用框架而展开的。

    迄今为止，我们见过的大多数的可重用框架表现形式都可以总结为：以开发平台为基础，积累自己的商业组件，并以此为中心订立开发活动。这种形式是不是最好并没有定论，但我们是抱着学习的态度来研究它的。

    以开发平台为基础的意思是软件组织必须有自己所熟悉的开发平台，其大部分的项目都是在此基础上进行的。目前最流行的两种软件开发平台是J2EE和.NET，但是就算是同一个平台，不同的软件组织对平台内部的侧重也是不同的（同样对于J2EE技术，有的软件组织可能把JSP和Servlet作为核心选择，而另一些软件组织则把重点放在EJB上）。选择一种广泛应用的、具有生命力的平台技术是非常重要的。因为你的框架将会以此为基础进行，而框架的转移成本是非常之高的。虽然我们在一开始介绍的MDA思路为我们绘制了一副平台无关设计的美好愿景，但是在目前阶段，我们仍然要面对不同软件平台造成的严重隔阂。

    必须指出的是，我们上面提到的开发平台指的是在操作系统这个层次之上的平台，也就是俗称的中间件平台。但是从中间件到最终的产品之间有没有过渡的平台呢。其实可重用框架就扮演了这一角色。软件市场上已经出现了商业化的可重用框架了。IBM的SanFrancisco框架就是这种概念的代表。

    平台技术仅仅只是提供了一个技术，而软件组织要生存和发展，还需要积累和发展自己的商业组件。并将商业组件发展成为可重用框架。商业组件的好坏，直接和软件组织的能力、经验，以及平台技术相关。商业组件可能直接表现为代码的形式（Bean、类、COM组件等），也可能只是描述性的记录（文档）。商业组件是经验积累而成的。请注意，商业组件的设计并不完全等同于面向对象开发，因为面向对象只是一种技术手段，但是商业组件设计的优劣，更重要的是对业务的理解程度。举一个最浅显的例子，一个精通面向对象开发、面向组件开发的设计师，让他介入他完全不了解的行业组件设计，他的表现将会大打折扣。

    到目前为之，大家所认识的框架仍然是技术型的框架。但事实并非如此，框架还包括了外延的一系列软件活动。这才是一个完整的框架。结合之前我们讨论的软件交付为开发目标。我们把这种开发方式称为以可重用框架为核心，以交付为目标的软件开发。这其实并不是什么了不起的概念，大部分的软件组织都已经这么做了，只是没有意识到自己的方式而已。了解这一点，能够帮助软件组织有效的改进自身的构架。

    平台技术和组件开发并不是本文的重点，因此我们在肯定了两者的重要性之后，把精力转移到软件活动上。

    在拥有一个框架核心（平台和商业组件）之后，框架需要包含这样的活动（或活动集）：收集项目需求，并将需求映射到核心构架上来。这其实就是需求阶段到设计阶段要做的事情。但是由于我们的活动是以软件交付为目标的，因此我们需要明确的指出活动中的注意事项。

    为映射工作设计需求描述规格。需求并不是一件容易的事。最难的莫过于尺度的把握了，例如需求要多详细。使用现成的技术来定义需求描述规格，并根据核心框架的特点进行必要的扩展。例如，我们使用成熟的用例技术来描述需求，同时我们要求需求按照不同类的商业组件进行分类索引。用例技术的推荐读物是Alistair Cockburn的Writing Effective Use Cases一书，该书目前已有英文影印版。

    保证需求规格能够被项目成员所理解。这里的项目成员包括客户、领域专家、需求调研者、分析模型设计师。只有他们了解需求，才能够保证信息的正确的传递。（参见 知识接力模式）。

    为实现需求制定分析（设计）规则和指南 。这是把需求映射到核心构架上的重要步骤。制定规则是必要的，但要小心，不要让规则限制住开发人员的创造力（参见 活跃和混乱、严谨和死板模式）。规则的形式可能是设计规范、分析模式、类库、组件重用等等。在指南中提供示例，描述如何将需求转换为设计模型是一种不错的做法。同样好的做法还包括了模式指南。

    确保测试贯穿了需求模型和设计模型。我们终于提到了测试。测试在软件过程中扮演着重要的角色。但遗憾的是在本文中直接提到的机会并不多，从某个角度上看。 知识接力模式中提到的复审其实也算是一种测试。测试的信息都包含在需求模型和设计模型之中，例如前置条件和后置条件。在完成需求模型和设计模型时同步完成测试用例是一种非常好的做法（我们的团队正是采用这种做法），但是需要小心文档一致性（参见 一致性的思考模式）的所需要付出的额外成本。