4..4.7 使用一般场景进行沟通的概念

 

 

—般场景的用途之一就是能够使涉众进行沟通-我们已经指出，每个属性团体都有其 描述基本概念的词汇，不同的术语可能代表相同的事件。这可能会给沟通带来麻烦。例如. 在有关性能的讨论中，代表用户的涉众可能并没有意识到对事件响应的等待时间与用户有 关。

促进这种了解将有助于对构架决策的讨论，尤其是对于权衡的讨论。 表4.7给出了对每个质量属性可能的刺激，并说明了大量不同的概念。一些刺激在运 时出现，一些刺激在运行时之前发生。对设计师来说，问题就是理解在这些刺激中，哪些刺激代表相同的事件，哪些刺激是其他刺激的聚合以及哪些刺激是独立的。关系明晰后， 设计师就可以使用每个涉众都能够理解的语言把这种关系传达给所有涉众。我们并不能以 -种概括的方式给出刺激之间的关系，因为它们部分地依赖于环境。性能事件可以是原子 的.也可以是其他较低层事件的聚合：故障可以是单个的性能事件或聚合。例如.在客户 机和服务器之间每交换几条消息就有可能出现故障（出现了未曾预料到的消息）.从性能 的角度来说，每个消息都是原了事件。

 

4.5其他系统质量属性

我们己经对质量属性进行了综合讨论。在研究文献和权威性的软件工程教科书的厲性 分类中，还可以发现大量的其他属性，在我们的场景中，已经捕获了其中的-些属性。例 如：可扩充性通常是-个重要的属性，但在此处的讨论中，可扩充性是通过修改系统容量来袖获的一例如.所支持的用户的数量。可移植性是作为平台可修改性来捕获的。

 

如果一些质量属性（如操作性）对您的组织非常重要。为该质量属性创建一般场景

是合理的。这只需要填写-般场景的6个部分即可：源、刺激、环境、制品、响应和响应度量。对互操作性来说，刺激可能是与另外一个系统进行互操作的请求，响应可能是支持 互操作的一个新接口或一组接口，响应度量可以是时间方面的困难性，要修改的接口的数量，等等。

 

4.6商业质量属性

 

除了上述与系统直接相关的质量属性外，还有很多商业质量目标往往也会对系统的构 架产生较大的影响。这些商业目标与成本、进度、市场和营销策略有关。系统的质量属性 具有模糊性，此处的每个商业目标也是如此，需要通过场景使这些目标变得具体•以使它 们适合影响设计过程，并且变得可以测试。然而，在这里我们仅对其进行概要论述.并把 场景生成留作讨论题。

 

(1)上市时间 如果存在较大的竞争压力，或产品推向市场的时间很关键.则幵发时 间的长短就成为一个重要因素。这会迫使在开发中购买或重用现有的元素。通常可以通过 使用预先构建好的元素（如商业产品）或柬用以前某个项目中的元素来缩短上市时间。在 系统中插入或部署系统子集的能力依赖于从系统到各元素的分解。

 

(2)成本和收益。系统开发自然不能超出预算。不同构架的幵发成本不同。例如，采 用开发组织并不具有的技术（或相关专业知识)实现构架的成本要远高于利用组织内的已 有资产实现构架的成本。实现一个灵活性很高的构架的成本通常耍高于构建一个不太灵活 的构架的成本（尽管其维护和修改成本较低）。

 

(3)所希望的系统生命期的长短.，如果希盥系统生命期很长，则可修改性、可扩充性 和和可移植性就变得非常重耍。但为支持这些特性而构建基础结构中的额外部分（例如支 持可可移植性的层）通常会导致上市时间的推迟。另一方面，可修改、可扩展的产品更可 能在市场上存在较长的时间，从而延长了其生命期。

 

(4)目标市场。对于通用（大众市场）软件，系统所运行的平台及其特性集将决定潜 在市场的大小。所以，可移植性和功能性就成为能占有市场多大份额的关键。其他-些质 饊属性，如性能、可靠性和舄用性等也起着一定的作用。而对于较大的专门市场，应该考 虚产品线策略，即各个系统的核心（往往也包括保证可移植性的部分）是相同的.在此基 础上构建具有各种特性的软件。第14章将讨论软件产品线方法。

 

(5)推出计划。如果产品是作为一个基本功能集推出的.以后将会发布很多特性.则 构架的灵活性和可定制性就非常重要。尤其是耍保证所构建的系统必须易于收缩和扩展。

 

(6)与老系统的集成。如果新开发的系统必须与现有系统集成，则-定耍认真考虑， 定义合适的集成方法。这显然具有重要的营销价值，但也涉及到构架上的很多问题。例如.

 

将某个老系统与HTTP服务器集成，以便能够从万维网上进行访问是在过去十年中很多公 司的营销目标。为此，必须分析这种集成对构架的要求。

 

4.7构架的质量属性

除了与系统相关的质量属性和与开发系统的商业环境相关的质景属性外，与构架直接 相关的一些质量厲性也是非常审:要的。下面我们考察3个这样的属性，具体场景的生成同 样留作讨论题。

 

概念完整性是在各个层次上统一系统设计的根本指导思想。构架应该以类似的方式去 完成类似的任务。Fred Brooks在其著作中特别强调了系统的概念完整性的极端重要性，并 指出没有概念究整性的系统是注定要失败的[Brooks75]：

 

我认为概念完整性在系统设计中是最重要的考虑事项.一个省却了不常见的特性或改 进，但反映了 一组设计思想的系统要比一个包括了很多好的但相互独立且不协调的思想的 系统好得多.[Brooks 75]

 

在这著作中，Brooks主要论述了系统在用户眼中将会是什么样子.但这一观点同样 适用于构架的布局。Brooks强调了概念完整性对用户的作用，以及构架完整性对其他涉众 (特别是开发人员和维护人员）的作用。

 

在第III部分，我们建议在对所评审的项目的构架进行评估时必须有设计师。如果找不 到这样的设计师，就说明构架缺乏概念完整性。

 

正确性和完整性是构架能够满足系统的各种需求及运行时的资源要求的必耍条件。第 III部分所讲述的正式评估再次说明了设计师希望得到一个正确完整的构架。

 

可构建性是保证能够由指定的幵发小组在规定的时间里及时开发系统.并允许在开发 过程中做某些更改的构架属性。可构建性指的是构建某个所期毕的系统的难易程度：它是 通过在构架层次上仔细关注系统到模块的分解，将这些模块合理地分配给开发小组并限制 模块之间（因此也就是小组之间）的依赖来实现的。其目的是最大程度地实现并行开发。

 

因为可构建性通常是用成本和时间来衡量的.所以可构建性和各种成本模型之间存在 着联系。但可构建性所涉及的内容一般要比成本模型更为复杂。系统是用某些部件构成的， 而这些部件又是借助各种工具生成的。例如，用户界面可能是用用户界面工具箱中的各种 工具（称为窗口小部件）实现的，而这呰窗口小部件可能又受用户界面生成器的控制.这 时，窗口小部件就是我们所说的构成系统的部件:，而用户界面生成器则是构建系统所用的 工具.所以，可构建性的一个元素就是在系统中使用的部件和操纵这些部件的工具之间的 匹配。此外，对所要解决的问题的认知程度也是可构建性的一个方面。做出这一决策的指异思想就足耍缩短上市时间，并且步要求潜在的供应商为理解和设计某个新概念而付出代 价。所以.-个运用大盤熟知概念的设计方案要比引入若干新概念的设计方案具有更好的可构建性。

 

4.8小 结

 

本章讲述的质最属性是软件设计师最常追求的目标。由于这些质量诚性的定义是蜇疊 的，因此我们选择用•般场规对苒进行刻画。读者已经看到，可以把这些质量诚性分为适 用于系统的、适用于商业环境的和适用于构架本身的。

 

下-帘将延续从质最W性到构架的思路.讨论•些具体的构架方法。

 

 

4.10讨论题

(1)对于您当前正在幵发的系统来说，遛茁要的质坫属性是什么？捕获这些质量属性 的面向特定系统的场景是什么，对应的一般场景趙什么？

 

(2)    Brooks认为概念完整性是系统成功的关键。你同意他的这观点吗？你能想出不 具有此域性的成功系统吗？如果确实有这样的系统，是什么因素导致了该系统的成功？为 了检査是否符合Brooks的观点，你将如何去考察一个系统？

 

(3)为4.4节和4.5节中列举的商业质狱属性和构架质iitW性生成场景。场谩中是否 捕获了所有的质馈厲性？哪呰质最厲性很难在场景中捕获？