建立架构基线的步骤

    必须尽可能早地建立一个良好的架构。即使在理论上，都很难通过采用重构等增量技术将一个糟糕的架构改良为一个好的架构，在实践中，那就更难了。这不是说重构是没有用的，而只是说明从一开始就建立一个良好的架构会更好。否则，重构的成本将很高昂，以致超出了功利的管理者所能接受的程度，那么他/她就会自然而然的选择简单修改而不是重构。所以，一个良好的架构需要在成本很小或者甚至零成本的时候就建立起来。优先构建架构会获得良好的投资回报的，它减少了项目执行过程中的重新设计和大量的返工。如果已经建立了一个良好的初始结构，就可以进行持续地重新评估架构，并做一些必要的完善和重构。

    架构基线。架构是最终系统的一个早期版本，也称为架构基线。架构基线是整个系统的子集，我们称之为骨架系统（skinny system）。这个骨架系统包含了项目结束时的“丰满（full-fledged）”系统所具有的模型的一个版本。它包含了相同的子系统、组件和节点的骨架（skeleton），但是并非所有的“肌肉（musculature）”都已齐全。

    不管怎么说，骨架系统确实具有行为，并且是可执行代码。骨架系统要进化到丰满系统（full-fledged system），可能只需要对结构和状态做出细微的改动。改动之所以是微小的，是因为在细化(elaboration)阶段或架构迭代结束时，我们已经得到了一个稳定的架构。否则，细化阶段必须继续，直到架构稳定为止，当然有一种系统化的方法来实现这一点。

    虽然骨架系统（架构基线）经常只包括了5~15%的最终代码，但是它已经足够可以验证所做的关键设计了。更为重要的是，你必须确认骨架系统能够成长为一个完整的系统。伴随着骨架系统，会有一个书面的架构描述文档。

    用例驱动架构基线。架构基线是由系统中的关键用例子集来驱动而建立的。我们称这个子集为架构重要用例(architecturally significant use case)。在识别出这些架构重要用例之前，你必须尽可能多地收集已有的信息来识别出系统的所有用例。注意，识别用例和描述用例并不是一回事。识别是指对系统需要做的事情进行界定、探索和发现。描述用例则是指对用例中的流程和步骤进行细化。描述用例贯穿了项目的整个生命周期，而识别用例则必须尽可能早地完成。

    从这些识别出来的用例中，确定出其中哪些是重要的——“重要”意味着把它们组合在一起可以覆盖所有需要做出的关键决策：

    · 演练了系统的关键功能和特性。

    · 涵盖了大部分的功能性、基础结构、平台特性等方面的风险。

    · 突出了系统中的一些具有高复杂度或高风险性的部分。

    · 是系统其他部分的基础。

    架构重要用例包含了不同类型的用例。毕竟，每个用例捕获了一组不同的涉众的关注点，并且需要做出不同的决策。因此，架构重要用例包含了应用用例和基础结构用例的组合。你可能会发现系统中的某些用例具有技术相似性和交互模式相似性。在这种情况下，只需要选择一个用例作为代表就可以了。这样，只要解决了其中的一个用例，就可以解决其他用例了。例如在酒店管理系统中，“登记入住”和“结帐离店”用例具有相似性，所以可以选择其中一个作为架构重要用例。

    当你挑出了架构重要用例，就可以分析它们中的关键场景了。分析用例场景时，就能更好地理解系统需要做什么和系统中的元素是如何交互的。通过对系统的理解，就可以定义和评估架构。这个过程将不断地迭代直到形成一个稳定的架构。稳定就意味着系统的关键风险已经得到解决，并且所作的决定可以基本满足着手开发系统剩余部分的需要。这个架构不仅受架构重要用例影响，还受使用的平台、必须集成的遗留系统、标准和方针、分布性需求、所使用的中间件和框架等等的影响。即便如此，用例对于评估架构还是非常有用的。在所选平台、中间件、分布式结构等环境中分析每个用例，可以评估所做的选择是否足够，并且发现哪些地方还需要完善。

    迭代地建立架构基线。对于一个复杂系统，在最终建立一个稳定的架构之前需要经过几个迭代。由于这些迭代聚焦于建立架构，因此也被称为架构迭代。在统一过程术语中，这些迭代叫做细化迭代（elaboration iterations）。

    每次架构迭代中必须处理所有的架构关注点。你可能无法在每次架构迭代中成功地解决所有的关注点，但是需要全面地考虑它们。每次架构迭代过程产生一个增量，解决了部分的架构关注点。

    迭代将持续进行直到所有架构关注点都已经得到解决。架构迭代结束时，将得到系统的一个早期可执行版本（骨架系统），并是通过测试和执行结果来证实的，因此，它是已验证和已确认的。

    此时的系统版本就成为了架构基线。因此，架构就是系统的一个早期版本，它展示了架构的关注点是如何解决的。由于系统包含了一系列的模型，架构基线也是由这些模型的一个版本来表述的。伴随着架构基线存在一个架构描述文档，它的内容就是从这些模型中摘录出来的。

    架构描述作为开发小组在系统的整个生命周期中的指南。架构描述是开发者在项目后续迭代中必须遵循的依据。

    架构描述还将经过涉众的评审，以确定架构是否确实合理。应在架构描述文档中附上一张修订历史表来说明系统的演变，它同时也说明了重要的决策。

    在架构迭代中，由于你需要做出决策，所以进展一般比较缓慢。一旦完成了架构迭代，生产率就会显著提高，因此投入到架构迭代中的时间是相当值得。