详细解读敏捷和架构的关系

显然，当敏捷方法应用于可伸缩系统时，任何这样的误解都会引起系统性能的不一致（实用程序或性能缺陷）和系统间接口的不一致（设计缺陷）。反过来，本来可以避免的一些重构或重做工作就成为必须要做的事情了。因此，在可伸缩系统中必须保证有一些建模。

根据我们的经验，当团队采用更多的敏捷开发实践时，许多团队都很少依赖需求和架构约定（和更具扩展性的建模），这些需求和架构约定可能是他们以前方法中的“生命周期”早期阶段获取的。然而，同时，这些团队会依赖于简单却高效的域模型的可视化展示，将其作为项目的原始架构。我们也看到，许多敏捷团队不论在开始还是在开发过程中都相当依赖这个关键制品。

4, RUP：以架构为中心

我们在第1部分中提到过，RUP的根源在于开发一套支持面向对象开发方法的软件过程。此外，RUP的大部分内容融入了Rational公司技术领导在做咨询时从应用程序到大规模系统中所获取的经验教训，这些技术领导有Grady Booch、Philippe Kruchten、Walker Royce和 Ivar Jacobson等人。综合起来，形成RUP的实践主要来自于针对面向对象开发方法的大规模系统的开发。的确，RUP已经被一些公司（如Ericsson等公司）应用于大规模系统的项目，在这样的项目中同时有几千名开发人员参与开发。

RUP的主要特点是“以架构为中心和用例驱动”。Booch对“以架构为中心”进行了如下描述：

（1）架构是可以命名和管理的东西；

（2）人们使用架构容纳用例，有意识地管理风险，并且通过迭代和增量的方式完善架构。

所以，作为高效大规模系统软件开发的基础实践，RUP考虑架构已经很长时间了。Kruchten［2004］提出了可伸缩系统架构的重要性的演变。

由于很多软件系统并不复杂，架构可以让开发者保持相互理解。然而，为了适应新的需求，随着系统的演变和发展，情况就完全不同了，系统无法同步增长。集成新技术需要完全重建系统。此外，设计者也缺少判断系统组成部分合理性的智能工具。所以，糟糕的架构总是被列为软件失败的原因就不奇怪了。没有架构，或者使用糟糕的架构是软件项目的主要技术风险。

那么，RUP拥有应用于迭代和增量软件过程条件下的架构开发指南就不足为奇了。目前，RUP指南包括一组用于定义系统的架构视图，每个视图都从架构上反映了一个或多个重要利益相关者的视角。其中，有如下两个强制的视图。

用例视图。每个系统只有一个用例视图，用例视图图示了所有用例和场景，从架构上包含了重要的系统行为、类或者技术风险。

逻辑视图。每个系统只有一个逻辑视图，逻辑视图图示了关键的用例实现、子系统、包和类，从架构上包含了重要的系统行为。

此外，RUP额外规定了4种可选的视图，这4种视图可以根据所配置系统类型等方面的重要性酌情使用。

进程视图。当系统拥有多个控制线程，并且线程之间有交互或依赖时推荐使用该视图。该视图通过把类和子系统映射为进程和线程说明了系统的进程分解。

配置视图。当系统分布在多个结点之间并且结构上存在牵连时，推荐使用该视图。配置视图图示了处理系统中一组结点的分布，包含进程和线程的物理分布。

实现视图。当实现不是严格由设计驱动时，即设计和实现模型中的相应包之间的责任分布是不同的时，推荐使用该视图。实现视图在给个人或团队分配实现任务时非常有用。恰当的实现结构会支持高效的持续集成。

数据视图。当持续数据是系统的关键部分时，推荐使用该视图，例如，包含数据模式、数据定义和算法等内容的系统。

5,炫目的敏捷架构师

在敏捷项目中，传统架构师的象牙塔已经逐渐成为最薄弱的一环，而他们的许多工作职责也已经被整个敏捷