应用程序架构本质，第 3 部分: 软件开发方法学入门

在关于应用程序体系结构的原理的本系列的此部分中，您将了解与应用程序开发方法相关的技能、工具、技术和里程碑。技能全面的应用程序架构师必须能够将许多方法应用于应用程序的开发。所选择的方法可能由项目的组织或本质决定。在专门命令和控制严格且灵活的技术之间求得平衡是成功完成应用程序开发项目的一个关键组成部分。

架构师所担任的角色是将自动化的需要（需求）转换为符合资源限制（时间、资金投入、技能）要求的恰当结构（设计）和构造方法（方法）。在本系列前面的文章中，我们了解了与需求及设计模式相关的基本概念。在本文中，您将了解如何应用恰当的技术来定义应用程序开发方法。

有很多软件开发方法发布在各种书籍里、打包为产品或由标准组织进行维护。如果为大型组织设计软件，则可能会有确定的以经过实践的非正式方式或强制的正式方式采用的标准方法。

技能和能力

有用且有效的开发方法应该包括从松散托管到完全指定的各种技术。所使用的技术类型和所应用的流程精确量由应用程序设计、技能集合、技术成熟度、规模、复杂性和重要性中涉及的风险决定。这些技术的一端是开发团队，将与涉众紧密合作，创建满足一组已经标识并进行了优先排序功能的应用程序解决方案。大部分精度要求都可以从流程的部署方面派生出来，可通过对应用程序组件的持续测试和集成来进行此工作，如图 1 中所示。

图 1. 敏捷方法示意图

这些技术中接下来涉及统一过程方法，其将开发工作划分为具体的规程（设计、编码、测试等），如图 2 中的简化形式所示。涉众提供的信息以及对涉众的反馈更为程序化和正式化，其直接性和连续性更低一些。当需求得到了很好地理解，而且很少或没有可重用设计与实现资产可用时，就可以使用这种类型的方法。

图 2. 正式方法示意图

流程精确度要求的另一端是产品线体系结构，其中的应用程序设计、构造流程、配置和部署均为预先开发的，可使用一组变化点进行自定义。这与生产线工程有些类似（正如名称中所暗示的这种关系）。材料、部件和组装流程都已标准化。这种方法的简化视图如图 3 中所示。

图 3. 产品线方法示意图

在任意规模的项目中，会很明显地发现，无论如何在多方面进行精心的定制，都不会有同时适合应用程序的所有方面的单个方法。体系结构的有些组件具有模糊或未知的需求，如下面这种情况：“我们需要能帮助组织和确定怠帐的东西”。其他组件是已知且得到很好理解的功能元素的实例：“我们需要应用程序数据库维护接口。”即使在最初级的开发团队中，后者的实现也是从复制最新构建的实例或某个现有体系结构类型开始的。

组织或开发团队会随着时间不断发展其可重用组件和设计。在进行此工作的过程中，有些应用程序类型的开发方法会从试验性的创造流程过渡到正式的重用和变体。

了解各种技术的细节非常有价值，但还要确保了解其优缺点。另外，请应用适合应用程序及在其中进行开发工作的上下文的技术。体系结构本身充当将应用程序划分为反映关注分离的结构的主要机制。这个分离允许架构师以独立于其他组件的方式分析每个组件的特征。要应用的方法只是其中的一个特征，应该由体系结构分析进行标识和提供支持。

方法模型

因此，如果希望成功构建具有合适规模的应用程序，则需要某种类型应用程序开发方法。方法中具体涉及什么？如何对可用的各种方法进行比较和对比？要讨论这些问题，可以创建方法模型，以定义可以在方法、其属性及可能的关系中指定的事项的类型。存在很多这种模型的示例，包括属于 Eclipse Process Framework (EPF) 的一部分的统一方法体系结构 (Unified Method Architecture)。还可以对方法本身的属性进行讨论，如其概要或根据指定的角色、应用程序生命周期和活动说明方法处理的范围。

敏捷开发

敏捷开发方法是轻量级流程，追求尽可能减少标识需求与工作代码交付之间的时间延迟。抽象需求捕获为所需功能的通用声明或用户案例（以叙述的方式描述如何使用系统实现目标）。需求正式化为实现的测试用例，开发的目标就是通过测试用例，从而以尽可能少的流程开销交付所需功能。

敏捷开发流程通常每次处理少量的用户案例或需求。计划调度基本上就是一个时间框方法，定义应该完成的交互和需求的时间范围。每次迭代应该足够大，以至少交付应用程序的一个重要功能方面的内容，但不要太大而分散团队的注意力。

项目管理

根据组织的不同，作为架构师的您可能不会对应用程序开发项目的日常管理负有最终责任。不过，您应该清楚地了解与项目预算和计划管理相关的问题和需求。架构师的职责包括在可用时间及财务限制范围内交付所需的功能。

您应该能够通过分析组件固有的复杂性和风险影响因素来在体系结构的帮助下支持进行准确的计划和调度。您还可以为特定的组件指定特定的技能或技能级别，从而帮助准确地进行资源调度。

对于更为灵活的方法，项目管理涉及进行需求优先级排列和促进团队开发周期工作。在这种情况下，架构师可通过分析需求的影响和复杂性增加价值。

迭代开发

迭代开发中的迭代 指的是，这些方法将涉及到重复执行内核流程。根据具体方法，内核可能或多或少采用结构化的方式，如每个 IBM® Rational® Unified Process® (RUP®) 迭代中的工作流或 Scrum 中的 Sprint。每次迭代都会在项目交付内容中得到切实的进展。每次迭代之后，都会对结果进行分析，并调整计划，以进行下一次迭代。

统一过程 (Unified Process) 之类的方法以及 RUP 之类的相关产品基于阶段和迭代定义流程框架。开发生命周期应该定义为阶段的序列。每个阶段会得到系统的一个关键里程碑版本，并会对此阶段进行评估，并针对下一阶段进行规划。在每个阶段内，会使用一组并行工作流定义执行的活动及每个活动使用、创建或修改的构件。阶段的类型决定哪些工作流是强制性的，哪些是可选的，并使用权重来指示该工作流相对于其他工作流所需的工作量。随着阶段的过渡，工作的分布从需求分析逐渐转移到实现的设计、测试和部署。不过，所有工作流都会进行一定程度的执行（虽然可能是仅仅基于其他流的反馈对构件进行调整）。

在阶段内，一组工作流可能在迭代过程中执行多次。每次迭代应该具有基于时间范围或实现的里程碑的明确持续时间。迭代可能进一步修改工作的分布，以将重点放在特定的区域，如原型等方面。

风险评估

开发方法以及应用于特定应用程序组件的资源类型的选择应该部分依赖于组件带给项目的风险量。风险涉及到很多方面，包括位置需求、新技术、复杂算法、性能和响应时间需求或关键正确性和可靠性。

通过标识应用程序设计的高风险组件，可以尽早处理这些风险。您可能会决定针对特定的风险元素评估现成软件。不过，对于提供竞争优势组件或使用专用算法的组件，可能无法进行此工作。可以接受多大的风险，这取决于您的环境以及应用程序对业务的竞争价值。一般情况下，如果一个项目风险很高，而回报又较低，比如不能提供独特的具有竞争力的功能，则不会启动这个项目。可以通过确定项目的各个要素和重构高风险区域，可减少风险。最终，您将获得所公开内容的清楚映射，并能够了解在何处应用特殊技能或进行相关工作。

流程定义和定制

没有任何流程甚至方法能够在任何时候适合所有人。在某些时候，您可以显式或隐式地对流程进行定制，以适合您的需求。您应该熟悉基本方法元模型，并能够定义和自定义方法元素。通过定义考虑应用程序组件的不同特征的流程，可为项目定义恰当的开发流程。

工具

有很多工具可用，我在此不可能一一提到。我已经确定了一些能帮助您入门的示例。

Eclipse Process Framework

EPF 是一个方法定义框架。此框架定义用于形成特定方法的文档的流程和内容元模型。其组合器工具是一个 Eclipse 插件，允许浏览、创作和发布内容。通过使用 EPF，可以从方法内容中的现有元素创建流程定义；方法内容中包括角色、工作产品及任务定义和相关指南（检查清单、模板等）。还可以通过使用描述符来添加信息，从而进一步对元素进行定制，而不限于方法库中定义的内容。

可以使用此框架来创作新方法内容或扩展现有配置。然后可以使用这个新内容来定义项目进度，并将其作为 Web 内容发布。企业架构师可以使用此工具来创建新配置。通过对支持特定项目上下文的方法内容进行省略、添加或专门化，配置可以约束或扩展现有库。

IBM Rational Method Composer 是带扩展功能的此框架的产品版本，内置了针对 RUP 的内容，并与 IBM Rational 工具集进行了集成。

IBM Rational ClearQuest

Rational ClearQuest® 是工作流、流程自动化及问题跟踪系统。该产品提供了大量预置工作流，可以使用设计工具进行自定义。ClearQuest 与 IBM Rational 工具集中的其他产品进行集成，也提供基于 Web 的接口。通过与 IBM Rational ClearCase 集成，可提供流程构件的版本和配置自动化。

IBM Rational ClearCase

Rational ClearCase® 是版本与配置管理系统，可为大型企业资产存储库和版本控制提供支持。ClearCase 产品可与 IBM Rational 工具、Microsoft® Visual Studio® 集成，甚至能向本机文件系统插入版本控制功能。可以在资产存储库中创建复杂的规则、控制和报告功能，以支持配置提升流程及与其他系统集成。

IBM Rational Software Architect

可以使用 IBM 的 Rational Software Architect 相对于应用程序的开发来设计构件和流程的结构。可以创建包含解决方案通用结构的项目模板，并使用关于如何使用所包含内容的指导方针进行标注。IBM 发布了设计这些模板的结构的建模指导方针，使用库软件包保持可以复制到模型中并进行自定义的通用构件组件。

技术

和工具一样，相关技术也非常多，无法在本文中全面涉及。以下是其中的一些技术。

极限编程

极限编程（Extreme Programming，XP）是一种轻量级敏捷方法，强调尽可能快地交付可正常工作且经过测试的代码。此技术最适合小型团队，但能够通过恰当地将应用程序划分为较小的组件来进行扩展。此方法的主要动机是为了尽可能减少占用团队有效进行功能交付方面的工作的流程开销量（有时候在敏捷性相关文献中将其称为礼节 (Ceremony)）。XP 专业人员使用测试驱动的开发（Test-Driven Development，TDD）和持续的集成来保持开发目标（即使用工作代码满足需求）。

TDD 将测试放在编码工作前。应用程序需求表示为测试用例，反映抽象需求和业务规则（可能是从用户案例中提取的）。将首先编写测试用例，然后将通过编写满足各个测试用例的代码来进行实现。只要将代码提交给项目构建版本，就将运行测试。这与持续集成技术进行了集成。

持续集成意味着会频繁地定期（或在提交或集成代码时）重新构建整个项目（或某个合适的子项目）。如果项目成功构建，将对所得到的系统运行所有测试，并将生成相应的报告供整个团队进行复查。任何造成构建版本中断的内容将在接下来的工作中具有高优先级。

Scrum

Scrum 是用于管理开发项目的轻量级敏捷方法。业务需求表述为通用术语，并作为具有优先顺序的列表进行维护。开发团队在短时间内不间断地进行工作（通常为两到四周）。每个这样的时间段都称为 Sprint。Sprint 开始时，团队将从风险和范围的角度对最高优先级需求进行评估，并确定在 Sprint 结束时要实现、测试并可能部署的一组需求。日常会议（称为 Scrum）将对进度以及阻碍进度的问题进行非正式的讨论。

在 Sprint 期间，团队将全权负责自行组织和完成所需的任务。在日常会议中提出的任何问题都将由项目经理进行处理。会对每天要进行的工作进行计划。每个 Sprint 之后，将评估进度，并制定下一个 Sprint 的计划。将基于提出的新功能以及 Sprint 期间所得的经验教训预先确定需求的优先级。

当需要定期提交发布版本，需要将大型项目划分为较小的项目或需求不稳定时，则请使用 Scrum 方法。

Crystal

Crystal 是一组与由重要性因素（财务、法律或失败后的声誉影响）、项目团队规模和项目优先级定义的一系列项目上下文关联的方法。这些方法按颜色区分，涵盖所有项目规模和精度要求。这些范围通过对实际项目使用此方法的实际实践确定。可以随后对适用性范围进行调整，以反映在扩展了此方法的范围的项目中的成功应用。当现有方法不适用时，将添加新构造，以形成具有自己颜色标识和范围的新方法。

您可以在自己的工作中使用 Crystal 来实现一些非常有用的效果：

• 将 Crystal 方法直接作为现成方法使用。
• 使用 Crystal 机制来根据自己组织的优先级、经验和技能确定方法配置的特征。
• 维护自己的现有方法分类，随着时间的推移，可以通过为新项目选择最高效的方法来优化开发工作效率。
• 使用 Crystal 方法分类技术来评估现有方法或建议的方法。

开放统一过程

开放统一过程（Open Unified Process，OpenUP）是一种迭代方法，其中包含的内容非常少，但是可以进行扩展。OpenUP 强调开发过程中的体系结构和建模，正在逐渐被纳入模型驱动的开发中。

IBM Rational Unified Process

RUP 是打包为产品的统一过程 (Unified Process) 方法的变体。RUP 包括各种内容、可交付模板、流程模板、角色、流程和构件指南等等，几乎可以针对任意项目上下文进行定制。RUP 作为可浏览、可重用的内容交付。各个组织可以构建描述自己特定流程的内容，并在任意规模的团队部署。

团队软件流程和个人软件流程

美国软件工程协会（Software Engineering Institute，SEI）支持在软件开发工程方法中使用团队软件流程（Team Software Process，TSP）和个人软件流程（Personal Software Process，PSP）。TSP/PSP 的目标是提高软件开发工作的易管理性、可测定性、可靠性和可预测性。SEI 提供了大量的背景材料、案例研究、书籍、培训、指导和咨询服务，以支持这些流程。

里程碑

我怎么能在里程碑作为流程的一部分出现时在流程或方法的上下文中讨论里程碑呢？实际上，我所讨论的是应用程序开发流程嵌套在其中的高级流程。这通常为某个产品或项目从其中派生的投资组合管理流程。从可行性及此流程的计划阶段的某方面而言，应该开发系统的大致体系结构并使用其分析设计与实现所涉及的工作、风险和资源。在此处制定和定制开发流程将带来很大的帮助。

分析体系结构的组件，以分配驱动资源和方法选择的特征。将最佳资源应用于难于理解或对其理解不透彻的组件。如果要应用新技术，请考虑进行相关的调查和原型设计工作。标识属于通用实现模式的实例且能进行更严格管理的组件。

总结

了解众多可用方法及其特征对了解如何最好地构造设计非常关键。您应该熟悉主要方法，并了解各个方法的优缺点。应该学习如何根据需求定制方法。选择适合项目类型和开发环境的正确方法。了解如何在体系结构中的正确点以正确的方式应用正确的方法，这样将极大地提高您的项目成果。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
• Agile Alliance 维护与敏捷软件开发技术相关的各种资源。
  
  
• Scott Ambler 是多本描述敏捷方法在各个开发领域（如数据库建模、文档编制、对象建模和项目管理）的应用的书籍的作者。
  
  
• 美国软件工程协会 (Software Engineering Institute) 提供了大量关于团队软件流程、个人软件流程和软件产品系列的相关信息。
  
  
• Alistair Cockburn 是 Crystal 系列方法的创建者，并负责维护一个 wiki，其中提供了阅读清单和指向其他关于 Crystal 方法的资源的链接。
  
  
• 目前提供了有各种关于统一过程的资源，包括各种开发环境下的变体：
  • 敏捷统一过程（Agile Unified Process，AUP）
  • 企业统一过程（Enterprise Unified Process，EUP）
  • 基本统一过程（Basic Unified Process，BUP）
  • 开放统一过程
  • Rational 统一过程
  
  
• developerWorks 中国网站架构专区：获取提升您在体系结构方面的技能所需的参考资料。
  
  
• 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。