软考时间安排 >>

软考指定教材 >>

软考视频教程 >>

软考历年真题在线测试 >>

希赛网软考网上辅导招生 >>

希赛网软考串讲面授班招生 >>

希赛网软考冲刺辅导班招生 >>

  2.7.3 建立架构基线的步骤

  良好的架构必须尽早建立，技术在理论上，都没有办法通过重构等增量技术，把一个糟糕的架构改造成一个好的架构，在实践中就更难了。事实上如果重构的成本超过了管理者所能接受的程度，他就宁可简单的重写代码而不是重构。所以，一个良好的架构需要在建立成本很小的时候建立起来，事实表明，优先架构会获得良好的投资回报，它减少了项目执行过程中的重新设计和做无用功。如果已经建立了一个良好的架构，就需要持续的进行重新评估，并且做一些必要的完善和重构。

  1、架构基线

  架构是最终系统的一个早期版本，也称之为架构基线。架构基线是整个系统的子集，我们称之为骨架系统（skinny system）。这个骨架系统包含了项目结束时的“完整”系统所具有的模型的一个版本，它包含了相同的子系统、组件和节点的“骨架（skeleton）”，但并非所有的“肌肉（musculature）”都已齐全。不管怎么说，骨架系统确实具有行为，并且是可执行的代码，可能会需要对结构和状态作某些细微的改变，在精化阶段或者架构设计迭代结束的时候，我们就可以得到一个稳定的架构了。尽管骨架系统（架构基线）通常只包含 5%~15%的最终代码，但他已经足够验证你所做的关键设计了，更为重要的，你必须确认骨架系统能够成长为一个完整的系统，应该有一个书面的架构描述文档，但现在，这个文档必须通过架构基线来验证和确认。

  2、用例驱动的架构基线

  架构基线是由关键用例子集驱动建立起来的，我们称这个子集为架构重要用例，在你提取出这些架构重要用例之前，必须尽可能收集存在的信息，以识别出系统所有的用户描述。这种识别主要是对系统需要做的事情进行界定、探索和发现。当确认了与架构有关的用户描述以后，需要把若干描述集合成一个个的主题。通过讨论，确定架构的基本方案，由于架构对产品的重要性，大多数情况下，这个方案还需要经过评审，然后才能进入架构设计迭代。此时，需要把用户描述转换为描述用例，这是对用例中的流程和步骤进行细化，描述用例会贯穿项目的整个个生命周期，而识别用例则必须尽可能尽早的完成。在这些识别出的用例中，确认哪些是最重要的，所谓“重要”，意味着它们组合在一起，可以覆盖所有需要作出的关键决策：1演练系统的关键功能和特性。2涵盖大部分的功能性、基础结构、平台特性等方面的风险。3突出系统中一些高复杂性和高风险的部分。4是系统剩余部分的基础。架构重要用例列表应该包含应用用例和基础结构用例，要注意对其中一些具有技术相似性或者交互相似性的的用例，可以选择有一个用例作为代表，只要解决了其中的一个用例，就可以解决其它用例了。当挑出了架构重要用例以后，就可以分析它们当中的关键场景，通过分析用例场景，更好的理解系统需要做什么以及系统的元素是如何交互的，通过对系统的理解，就可以定义和评估架构，这个过程将不断迭代的形成一个稳定的架构。稳定就意味着系统关键风险已经被解决，并且所做的决定可以基本上满足着手开发系统剩余部分的需要，这个架构不仅受架构重要用例的影响，还受使用的平台、必须集成的遗留系统、标准和方针、分布性需求、所使用的中间建和框架等等的影响。通过用例，可以评估所做的选择是否足够，并且发现哪些方面还需要完善。

  3、迭代地建立架构基线

  前面已经提到过，在架构设计的雏形完成以后，我们可以从以下四个视角优化架构：1从质量属性及其应对策略的视角：根据非功能性需求和质量验收标准，提出整体上的体系结构策略。2从模块划分的视角：进一步进行模块划分，从开发成本与集成成本两方面综合考虑问题，合理划分模块。3 从解决缠绕和分层的视角：分离出共享和缠绕部分，建立合理的分层结构 4 从构件化和软件复用的视角：应用已经存在的基于复用的软件构造块，修改体系结构以适应这种构造块。考虑现有的结构能否有可以被将来复用的部分，按照构件的要求进行设计 对于一个复杂系统，最终建立一个稳定架构之前需要经过几个迭代，每次架构迭代中必须处理所有的架构关注点，虽然不可能在每次迭代中处理所有的关注点，但需要全面的考虑它们，每次迭代过程都产生一个增量，解决一部分架构关注点。 迭代一直需要持续到所有的架构关注点都已经解决，在迭代结束时所得到的早期版本（骨架系统）需要经过测试和运行来证实结果。伴随着架构基线的产生需要一个架构描述文档，这个文档将成为后期开发小组工作的指南，也是后续迭代中必须遵循的依据。架构描述还必须经过评审，已确定架构是否合理，这个描述文档还应该附上一张修定表已说明历史的演变，它同时也说明了重要的决策。在架构迭代中，由于需要作出决策，所以进展一般是比较缓慢的，一旦完成了架构迭代，后续的生产率就会明显提高，所以投入到架构迭代中的时间是非常值得的。

相关文章：软件架构设计的思想与模式[2]