迭代过程

    Witt 等人为设计和架构指出了 4 个阶段：勾画草图、组织、具体化和优化，分成了 12 个步骤7。他们还指出需要某种程度的反向工程。而我们认为对于大型的项目，该方法太"线性化"了。在 4 个阶段的末尾，可用于验证架构的内容太少。我们提倡一种更具有迭代性质的方法，即架构先被原形化、测试、估量、分析，然后在一系列的迭代过程中被细化。该方法除了减少与架构相关的风险之外，对于项目而言还有其他优点：团队合作、培训，加深对架构的理解，深入程序和工具等等（此处提及的是演进的原形，逐渐发展成为系统，而不是一次性的试验性的原形）。这种迭代方法还能够使需求被细化、成熟化并能够被更好地理解。

    场景驱动（scenario-driven）的方法

    系统大多数关键的功能以场景（或 use cases）的形式被捕获。关键意味着：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了必须减轻的一些重要的技术风险。

    开始阶段:

    基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。

    形成"稻草人式的架构"。然后对场景进行"描述"，以识别主要的抽象（类、机制、过程、子系统），如 Rubin 与 Goldberg6 所指出的 ―― 分解成为序列对（对象、操作）。

    所发现的架构元素被分布到 4 个蓝图中：逻辑蓝图、进程蓝图、开发蓝图和物理蓝图。

    然后实施、测试、度量该架构，这项分析可能检测到一些缺点或潜在的增强要求。

    捕获经验教训。

    循环阶段:

    下一个迭代过程开始进行：

    重新评估风险，

    扩展考虑的场景选择板。

    选择能减轻风险或提高结构覆盖的额外的少量场景， 然后:

    试着在原先的架构中描述这些场景。

    发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。

    更新4个主要视图：逻辑视图、进程视图、开发视图和物理视图。

    根据变更修订现有的场景。

    升级实现工具（架构原型）来支持新的、扩展了的场景集合。

    测试。如果可能的话，在实际的目标环境和负载下进行测试。

    然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。

    更新设计准则和基本原理。

    捕获经验教训。

    终止循环
    为了实际的系统，初始的架构原型需要进行演进 。较好的情况是在经过 2 次或 3 次迭代之后，结构变得稳定：主要的抽象都已被找到。子系统和过程都已经完成，以及所有的接口都已经实现。接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。

    这些迭代过程的持续时间参差不齐，原因在于：所实施项目的规模，参与项目人员的数量、他们对本领域和方法的熟悉程度，以及该系统和开发组织的熟悉程度等等。因而较小的项目迭代过程可能持续 2-3 周（例如，10 K SLOC），而大型的项目可能为 6-9 个月（例如，700 K SLOC）。

    架构的文档化

    架构设计中产生的文档可以归结为两种：

    软件架构文档，其结构遵循"4+1"视图（请对照图 13，一个典型的提纲）

    软件设计准则，捕获了最重要的设计决策。这些决策必须被遵守，以保持系统架构的完整性。

    图 13 － 软件架构文档提纲

    结束语

    无论是否经过一次本地定制的和技术上的调整，"4＋1"视图都能在许多大型项目中成功运用。事实上，它允许不同的"风险承担人"找出他们就软件架构所关心的问题。系统工程师首先接触物理视图，然后转向进程视图；最终用户、顾客、数据分析专家从逻辑视图入手；项目经理、软件配置人员则从开发视图来看待"4＋1"视图。在 Rational 和其他地方，提出并讨论了其他系列视图，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我们发现其他视图通常可以归入我们所描述的 4 个视图中的一个。例如 Cost&Schedule 视图可以归入开发视图，将一个数据视图归入一个逻辑视图，以及将一个执行视图归入进程视图和物理视图的组合。

    表 1 － "4＋1"视图模型一览表

    致谢

    "4+1" 视图的诞生要归功于在Rational、加拿大的 Hughes Aircraft、Alcatel 以及其他地方工作的同事。笔者特别感谢下面这些人的贡献：Ch.Thompson、A. Bell、M.Devlin、G. Booch、W. Royce、J. Marasco、R. Reitman、V. Ohnjec、E. Schonberg。