模式与软件架构——软件架构的非功能特征

软件的非功能特征对软件系统的开发和维护工作、总体可操作性以及消耗的计算机资源有重大的影响。除开影响应用程序的质量和架构外，非功能性特征还会影响系统的功能特性。软件系统的规模越大，复杂度越高、生命周期越长、非功能特征就越重要。

软件架构的非功能特征

软件架构非功能特征

• 可修改性
• 互操作性
• 效率
• 可靠性
• 可测试性
• 可重用性

1.可修改性

大型的工业和商业软件系统的寿命周期通常都是很长的，有时候会长达20年甚至更长。很多这类应用程序在开发结束后都不是固定不变的，而在其整个生命周期内不断演化。原来的需求又会变化，还会出现新的需求。为了降低维护成本和修改工作量，应用程序的软件必须为修改和演化做好准备。

软件老化的原因

• 一成不变 (lack of mevement):软件不更新，必然老化
• 盲动(ignorant surgery):修改软件的人对最初的设计不了解，软件架构逐渐被破坏
• 软件一开始就缺乏灵活性
• 文档不充分，随着时间的推移，对系统的认识越来越不清晰

软件老化的后果

• 越来越难以通过引入新功能来跟上市场的步伐
• 性能越来越低
• 可靠性越来越差

解决方法

• 提供准确的文档
• 修改时保留原来的结构
• 认真审核
• 软件最初设计就应该为修改做好准备

可修改性包含内容

可维护性

主要是指修复问题，即出现错误后对软件系统的 “修理” 。如果软件架构为维护做好了充分的准备，那么这通常只需要做局部的修改，并且可以最大限度降低修改给其他组件带来的副作用。

可扩展性

主要指给软件系统添加新功能，将组件替换为改进后的版本以及删除多余或不必要的功能和组件。为提高可扩展性，软件系统的组件必须松耦合。从而打造出让你更换组件是不会影响其客户端的架构，并支持在既有架构中添加新组件

重组

重新组织软件系统的组件以及他们之间的关系，比如调整组件的位置，将其移动到另一个子系统中，为支持软件系统重组，必须仔细设计组件之间的关系。理想情况下，应该能灵活配置组件，而不影响其他实现的主要部分

可移植性

指对软件系统进行修改，使其支持各种硬件平台、用户界面、操作系统、编程语言或编译器、为提供可移植性，需要这样组织软件系统：找出依赖于硬件、其他软件系统和环境的部分，将其放在系统库和永恒界面库等特殊的组件中。

2.互操作性

系统中的软件并非独立，经常需要与其他系统或环境交互。为了提高互操作性，设计软件架构时，对那些外部可见的功能和数据结构，必须提供明确的访问途径。
互操作性的另一方面是程序与使用其他编程语言编写的软件系统的交互。

3.效率

效率与执行软件是使用的资源及其对响应速度、吞吐量和存储空间消耗的影响相关。
要提高应用程序的效率，不能光靠使用精巧的算法，在组件之间合理的分配职责以及组件之间的耦合度也是很重要的。
在分布式软件系统中，效率也扮演者重要的角色，分布式应用程序底层的IPC（进程间通信）必须足够快，能够以足够高的速度传输消息和数据，诸如Forwarder-Reciever 等模式致力于解决效率问题，然而，很多模式都为解决问题增加了间接程度，这可能降低而不是提高效率

4.可靠性

可靠性是指，无论应用程序或系统发生错误还是用户以意外或错误的方式使用，软件系统都能继续运行。一般可以将可靠性分为两个方面。

• 容错： 其目标是在发生错误时确保行为正确并自行修复，如分布式软件系统在到远程组件的连接断开时重新建立连接，修复这种错误后，软件系统可继续或重新执行错误发生时正在执行的操作。
• 健壮性：指的是对应用程序进行保护，以抵御错误的使用方式和无效输入，确保他在发生意外错误时处于指定的状态。请注意，不同于容错，健壮性并不一定意味着软件能够自发成错误时继续运行，也可能只保证软件以指定的方式终止即可。

软件架构对软件系统的可靠性影响重大，为提高可靠性，软件架构可采取的方式包括

• 有意在应用程序中添加冗余
• 集成监视组件或错误处理

5.可测试性

软件系统的规模日益增大并且越来越复杂，工业软件尤为如此，这导致测试更困难，更昂贵。
要简化软件系统正确性的评估工作，有赖于架构的支持，支持可测试性的软件架构有助于发现并修复错误，临时集成调试代码和调试组件也更容易。

6.可重用性

可重用性是当前软件工程讨论最多的主题之一，它有望缩减软件系统的开发时间和成本，还可以改善软件质量，可重用性主要包括两个方面： 通过重用开发软件以及开发时考虑重用。

• 通过重用开发软件： 这意味着重用既有项目或商业库的组件和成果、设计分析、设计规范或代码组件。
• 开发软件时考虑重用： 开发软件时专注于生成在未来的项目中可重用的组件，这要求当前开发的应用程序采用的软件架构允许哥哥部分彼此独立，这样无需做重大的修改就能在其他系统使用它们

结束语

非功能特征可能既相互矛盾有互为补充。例如，提供重复的应用程序功能以支持容错时，与未提供这种冗余的结构相比，最终的结构既低效又昂贵。确定软件架构的非功能需求显然需要考虑不同非功能需求之间的相互依赖关系，并作出必要的取舍，同时还需要确定不同非功能需求的优先顺序，在发生冲突时优先考虑一种需求，而舍弃另一种需求。
虽然对于软件架构来说，非功能特征至关重要，但是在多大程度上具备这些特征却难以度量，在软件架构必须满足的详细指标中，只包含为数不多的几个非功能特征，因此，估算软件架构在多大程度上具备给定的非功能特征主要依赖于软件工程师的经验。