(软件体系结构)第6章基于体系结构的软件开发过程.ppt

　　　　　　6.1 概 述　　在软件系统的开发中，体系结构的开发是一个关键环节。尽管如此，定义和维护体系结构的过程仍然是含糊不清的。例如，面向对象研究者曾经以用例集合分析为基础提出过一个体系结构开发过程。这一过程可用来确定系统及其交互中存在的对象。但是，它并没有为定义体系结构提供一个清晰的方法。 　　某些体系结构研究者也曾经提出以那些具有已知属性的体系结构风格为基础构造体系结构，但并没有讨论如何处理风格之外的信息。尽管这两种对体系结构开发过程的描述都不是错误的，但它们也并非完全正确。或者说，这两种描述都没能正确地反映实际的体系结构开发过程。 　　按照Bass等人的观点，基于体系结构的开发就是：将以软件体系结构为核心的方法应用于软件产品的开发中。研究领域包括：如何定义和表达体系结构；需求的收集、建模及其与体系结构的联系；构件的开发及其与体系结构的联系；体系结构与传统系统的联系；体系结构和产品规划的联系；所有以上和软件产品相关的工具和技术。在本章中，我们介绍Bass等人提出的这一导出体系结构的过程。　　基于体系结构的开发过程来自于对一些大型系统的总结，尤其是来自于这些系统的体系结构设计师。这些系统或者应用于大型企业，或者应用于军事。所有的系统规模都在100 KSLOC(Thousands Source Lines Of Code，千代码行)以上。 本过程由以下步骤组成：(1) 导出体系结构需求。(2) 设计体系结构。(3) 文档化体系结构。(4) 分析体系结构。(5) 实现体系结构。(6) 维护体系结构。其中的每个步骤都包括：● 输入，包括收集此信息的手段。● 验证活动。● 输出。该过程的各个步骤如图6-1所示。 图6-1 基于体系结构的开发过程的步骤 　　需要说明的是，设计、文档化和分析这3个步骤构成了一个迭代的过程。一旦达成了一个可接受的体系结构，它紧接着就被实现，并必须得到维护。 　　　　　6.2 导出体系结构需求　　图6-2提供了对导出需求的过程的概述。它显示，体系结构需求由开发组织创建，并受技术环境和体系结构设计师个人经验的影响。我们把该步骤的输入放在下面的部分中讨论。该步骤的输出有3个：列举功能需求(通过用例具体描述)；列举特定体系结构需求；列举质量场景集合，它为体系结构需求提供具体测试。 图6-2 导出体系结构需求 　　可以把需求细分为与系统功能相关的和与体系结构相关的。由于本章的重点在于设计的体系结构方面，我们将不讨论功能需求的组织。但需要注意的是功能需求往往为数众多，可以分成多个不同的抽象层次，并具体表示为用例。在后续步骤中，我们将假设有一个相对较小的功能类的列表可用。我们首先将明确地讨论体系结构需求，然后处理怎样把它们具体化的问题。 6.2.1 体系结构需求　　常常可以为将要设计的系统确定少量的“体系结构驱动器”。例如，在某一领域有经验的体系结构设计师可以这样考虑需求：体系结构必须适用于一个软件产品线，并确定4或5个对于所要设计的这类系统都很重要的体系结构变更点。一个体系结构设计师可能注意到一个系统重视在数据库方面的功能需求，从而意识到该系统会用到数据库，并可能因此采用标准的三层数据库体系结构风格。定义体系结构需求的第一步是确定体系结构驱动器。 　　下一步是列举体系结构需求。这些需求就是列举体系结构驱动器序列，并产生其他重要的体系结构需求。仍然用前面给出的两个例子说明：在体系结构驱动器是对产品线的要求的例子中，体系结构需求可能是对体系结构变更点的列举和对性能与可靠性需求的列举；在数据库的例子中，需求可能是对数据库管理系统的变更点(或不变点)的列举，可以是系统可能要进行的更改的类型的列举，还可以是一些性能需求。 　　体系结构需求从如下3个来源之一导出：系统的质量目标，系统的业务目标，或将在该系统上工作的人员的业务目标。后者的例子可以是这样的一个组织，他们希望建立一个由熟悉C++图形用户界面的人员组成的核心小组，这里的需求就可以是使用C++。　　体系结构需求的数量通常没有功能需求多，最多大约有20条。 6.2.2 质量场景　　设计过程的前提之一是，认为系统的体系结构需求和行为需求是同样重要的。两种需求都用场景或用例的形式具体表示。有多种不同类型的场景可用。普通的用例被用于单个产品的行为需求。抽象场景被用于产品线的行为需求。　　基于质量的体系结构需求通过特定质量场景来表示，在下面将详细描述它。特定质量场景在考虑可更改性时是修改场景，在考虑安全性时是威胁场景，在考虑性能时是响应时间场景，在考虑可靠性或可用性时是错误处理或性能降级(某些设备失效)场景。 　　但是，特定质量场景也会对多个质量产生影响。例如，考虑下列修改场景：“修改系统，为客户端增加一个缓冲区”，它是