《用质量属性进行体系结构设计》由会员分享，可在线阅读，更多相关《用质量属性进行体系结构设计（5页珍藏版）》请在金锄头文库上搜索。
1、8.4 用质量属性进行体系结构设计本节介绍在质量模型中确定的、可由应用体系结构处理的质量属性的描述：n 功能性n 性能（有效性）n 可改用性n 可用性和可靠性n 适用性n 可移植性8.4.1 功能性功能性为系统或应用满足其设计目的的能力。功能性与合法性、正确性、互操作性、安全性等有关，这些质量属性中有的受体系结构的影响比其他的大。功能性驱动系统体系结构的初步分解，将其分解为一组共同完成系统功能的组件。我们不能很容易地利用功能来评价体系结构。功能性是规定所有其他质量属性的基础，因为系统的分解部分地受到功能性的影响。性能必须相对于某些功能来度量。性能的设计需要理解功能性，母滴是合理地分配功能或使它
2、模块化。可维护性必须针对在某个特定的功能组件或组件集合中修改或添加功能来进行度量。功能规格说明是一个用来描述功能性需求的常见文档，他常常是系统或应用产生的唯一规格说明。只基于功能规格说明的体系结构一般会在其他质量属性方面受到损害。例如，可维护性常常被遗漏，结果是，大多数系统的维护更困难，成本更高，但如果其体系结构考虑了这个质量属性，则该系统的维护就容易的多，成本也更低。1互操作性互操作性是系统的一种质量，它使系统能与其他应用、系统、技术一起工作，甚至包括那些在原始开发中没有预见到的应用、系统、技术一起工作。在现代信息处理中，业务系统互操作性正成为一种重要的必须品。在内部开发中，一个系统或应用最
3、终需要与同一组织机构中的其他系统，甚至是与企业外部的系统（业务到业务(B2B)集成）进行互操作。系统可以互操作，目的是完成默写高层次高价值的功能，如组成制造供给链，以改进响应性，同时降低维护过多库存所带来的成本。系统也可以为实现其他质量属性而进行互操作。例如，为了系统的安全性，在信息技术（IT）体系结构的现有安全模型和组件中安装新系统和新应用也极为重要。一种常见的系统集成需求是具有处理用户信息和安全证书目录的能力。互操作性还影响到商业软件的开发人员。如果某些企业软件供应商具有开放式系统，或具有预置的现有技术和系统的转接器，那么，比起只有封闭独立的体系结构的企业供应商，其销售产品的机会更好。2安
4、全性安全性（Security）指具有强制授权、验证的能力，在某些情况下，指具有周密的抵制服务攻击的能力。验证是建立用户或系统标识的行为；授权时允许或阻止用户或系统标识的行为；授权时允许或阻止用户或系统对某些资源进行访问的行为。通常在体系结构中利用诸如验证和授权服务器（安全网关）、网络日志监控器、防火墙和其他提供安全服务的组件等技术来解决安全问题。ISO/IEC9126模型不将安全作为一个软件质量属性，因为他与整个系统有关，而不仅仅是与软件有关。安全需求会影响系统的功能分解。有的操作和资源可能需要不同与其他操作和资源的保护，因此需要与其他成分分开。8.4.2性能（有效性）性能标识系统的响应性，可
5、利用对事件（刺激）的响应时间或一段时间内处理的事件数目来度量。一般，性能质量属性表示为每单位时间的事物处理数目，或表示为完成单个事务处理所需的时间长度。其外部特征通常以并发用户数目和应用在用户负载下的相应对应性来度量。性能的某些方面是体系结构化的。代码中的算法或数据结构的具体选择不是体系结构决策，但诸如计算在组件上怎么分配以及组件（内部进程和交互近程）间的通信模式等决策是体系结构的决策。交互组件通信通常比内部计算更费时间（交互进程通讯通常是系统性能的颈瓶）。在某种意义上说，性能是系统组件间通信和交互的数量的函数。性能可在体系结构层次上用诸如服务请求的到达率和分布、处理时间、队列大小、等待时间（
6、请求得到服务的速度）等来模型化。DeGrace和Stahl称这个质量为有效性。代码执行有效性（code execution efficiency）是用户要求的一些技术指标，如运行时间、响应时间、内存利用率等。他们隐含地确定了一个体系结构决策，即：最小化模块、模块到操作系统的通信。DeGrace和Stahl的描述集中于某些实现（非体系结构的）准则，诸如利用各种编译程序的优化、使循环结构免于不必要的计算、为有效处理而对数据分组和索引、使用有效的工具（关系数据库）优化数据存储有效性等。性能一般是系统体系结构中的一个驱动因素，并且常常损害其他质量属性。不过，由于硬件成本下降、软件开发成本上升，价格/性
7、能比耶发生了变化，其他质量正成为性能的重要竞争因素。资源有效性性能的一个方面是资源的有效利用。有的作者称性能的这个属性为资源有效性（resource efficiency）。计算资源的功能越来越强，价格越来越便宜（摩尔定理）。处理器越来越快，系统内存量不断增加。过去为了节省计算时间和降低内存用量而实行的设计习惯，随着系统性能的提高已经变得较不重要了。性能（处理器有效性）影响系统的分解和组件之间的连接协议的设计。系统可以分解为一组层次，以增加系统的模块性（从而增加可维护性和可重用性），但是，这种分解可能会妨碍系统满足性能需求的能力。体系结构设计师必须在这种分解与质量属性冲突时进行质量属性和设计的
8、折衷。性能质量和软件体系结构在第14章介绍。8.4.3可修改性可修改的体系结构是一种可随时间增加或增长的体系结构，折衷增加或增长可能是由其他开发者或客户以直接的方式完成的。换句话说，在现有应用中增加新功能，比建造新系统在成本上更合算。可修改性有时称为可维护性。一个可修改的应用可以增加新的功能而不需要对体系结构做重复工作，如更改功能在组件上的分配等。可修改性的度量为对应用进行更改所需的成本和工作量。与可修改性相关的刺激类型为功能、平台、质量属性或操作环境的更改请求。功能更改请求大概是最常见的事件。对于修改请求的体系结构响应可能是增加、修改或删除组件、连接器或界面，它们也用成本和工作量来度量。8.
9、4.4可用性和可靠性可用性是系统的一个属性，他度量系统正常运行的时间比例，通常是度量故障平均时间和故障之后修理故障的平均时间。可靠性是一个度量系统持续运行能力的属性。这两个属性都可由体系结构部分地满足。与可用性相关的刺激是硬件和软件故障，可用诸如故障平均时间等响应来度量它。影响可用性的体系结构决策包括硬、软件冗余和故障检测技术，如重试和看门狗等。可恢复性可恢复性（也称可维修性）与可用性有关。如果系统的处理时间要多长时间运行，且在停机或崩溃后系统必须从中断的地方开始，则需要考虑这个特性。这个特性并不只是基于事物处理的信息系统特有的，它也适用于桌面应用。考虑一个字处理器，它在你撰写某个重要文档的中
10、途崩溃了。任梦通过经常保存来应对这种情况，但这样做有时也不成功。现代字处理器能自动将中间草稿或文档草稿之间的变化保存到硬盘驱动器上。然后，如果什么东西崩溃（应用或操作系统），则在启动应用时，文档会恢复到最后的状态，这使用户能保存修改后的文档并继续工作。简单的应用可以自己纠正错误，但更复杂的系统可能需要人工纠正，以便重置系统的状态，使它可以正确启动。这可能需要在实际系统或应用启动前，启动一个诊断程序来检查系统的完整性。有时，应用在每次重启前，不管是否正确关闭，都要自动启动这样的一个诊断程序。本人过去使用过的一个系统具有基于队列的请求处理体系结构。请求不会丢失，因为它们保存在消息队列和临时工作空间
11、。该系统利用软件和硬件冗余来构造，但队列是全局性的。为防止多个处理器处理相同的请求，请求状态元数据被标记为“处理中”。在正常关机中，不能完成一个请求的所有进程都要把其状态改回“需要处理”，这样再重新启动时它可以继续进行处理。但是，如果系统在处理中崩溃，请求就成了孤儿。为解决这个问题，在重新启动时要将诊断服务作为第一个服务运行。此诊断服务重置所有孤儿请求，使他们能正确处理。提示：可用性的一个常见公式为MTTG/(MTTF+MTTR),其中MTTF为故障平均时间，MTTR为修理平均时间。可靠性通常定义为故障平均时间，不过，有的文章把他定义为故障之间的平均时间（MTBF），它是MTTF+MTTR之和
12、。8.4.5适用性适用性一般指适用于最终用户使用。不过，适用性也适用于其他系统用户，如系统维护人员、操作员及移植工程师。9126模型称实用性的这些方面为与用户类型有关的使用质量（quality in use）。最终用户（模型化为参与者）关心的是功能性、可靠性、适用性和有效性；维护人员（常常不模型化）关心的是可维护性。使用质量是系统的整体主观质量，受多个质量属性的影响。使用质量用场景来度量。8.4.6可移植性可移植性是在不同的应用或操作环境（如硬件、操作系统、数据库和应用服务器）中重用一个组件的能力。可移植性可视为可修改性的一种特殊类型。一个系统的可移植性的度量基于怎样使改动局部化，理想的情况是
13、局限于单个组件中。与可修改性一样，可移植性是系统移植在时间和金钱方面的成本度量。可移植性的基准是具体配置的规格说明，系统必须运行于这些具体配置之上。ISO9126模型确定了4个与可移植性有关的属性，他们分别是：适应性、安装性、一致性、替换性。可移植性的另一个词为可扩展性（extensibility）。在本人经验中，这个质量属性通常被忽略，本人认为他是被误解了。可移植性常常与将一个应用的源代码从一个操作系统（如Windows）一直到另一个操作系统（如Linux）有关。修改一个系统或应用以便用户可以从某个Web界面访问它便是可扩展性的例子。这种更改可能不在系统中引入新功能，而是改变了它的操作环境。
14、最好是说，可扩展性是“重要的，因为应用设计人员可能没有预见到发生在组织机构操作环境中的变动”。维护和扩展一个应用的成本将占应用生命周期成本的大部分。本人经历的其中一个例子是有一个产品大量返工，因为它不能再标准Java 2 Enterprise Edition（J2EE）应用服务器环境中运行。他是用一个专用应用服务器平台编写的，此应用不具有可扩展性质量。如果原设计者预见到他们的专用服务器平台会在一两年内过时，大概就不会在客户要求此应用工作在标准J2EE应用服务器上时，为进行移植而头疼了。此应用直接地处理数据库连接，应用的最终用户（他们是使用此专用应用程序接口（API）的开发人员）必须从此应用中使
15、用相应的数据库连接对象来执行与应用有关的数据库功能。如果此应用独立于管理数据库连接的组件，则最终用户就能很容易地把此应用集成到J2EE环境，该软件供应商也能很容易地进行转变。不可扩展的方法存在两个问题：l 最终用户的应用和供应商提供的平台必须用数据库连接信息来配置。这使配置复杂化，违背了使用简单化这个质量特征，通常会使故障排除更困难。l 不能利用事务处理（在最终用户的Enterprise Java Beans（EJB）和应用的数据对象上执行更新操作），这给最终用户的应用带来功能性问题。因此，数据完整性不能得到保证。正如第六章所见，部分满足可扩展性需求的一种方法是得出一组独立于平台的体系结构模型
16、。这是对象管理组（OMG）的MDA研究的前提。独立于平台的模型给出特定中间件技术的体系结构，并且在建造类似系统时可以重新使用。这并不保证应用本身是可扩展的，但它作为一种现实的人工制品，留下了一组可进一步推动开发工作的设计文档，因为产生抽象体系结构描述的困难工作已经完成。生成独立于实现的体系结构模型会迫使设计人员从独立于平台的观点考虑体系结构。8.5 体系结构和质量模型在DeGrace和Stahl的模型中，质量属性称为软件工程准则（software engineering practice）。SEI模型称它们为技术体系结构决策。当然，前者的模型强调通过实现级准则（如程序设计习惯表达方式）来处理质量属性。在后者的模型中，质量属性可视为前者的一个规格说明，具体软件工程准则为体系结构决策。体系结构准则的类型包括使用处理质量属性的模式和启发方法。在Evaluating Software Arch
