软件架构.docVIP

软件架构 我们毫不怀疑世界正变得越来越依靠软件。软件是诸如无处不在的手机，和复杂的空中控制系统的核心元素。事实上，如果没有软件，例如eBay 和 Amazon等我们理所当然认为是创新的企业将不可能存在。甚至那些金融业，零售业和公共部门等传统行业也相当的依赖于软件。在当今的时代，某种程度上，我们很难发现一个企业完全与软件不相关。我们对于“架构”的定义没有缺陷。甚至存在支持定义集的网站。架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。这些标准还定义了以下相关概念：系统是为实现某个（些）特殊作用的组件的集合。专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。环境决定了开发，操作，策略和其他影响系统的设置和条件任务是指系统为了实现对对象设置的使用或操作涉众是对于系统有利益关系或关注的个人，团队或组织。正如我们所见，“组件”贯穿于这些定义。正如有意留下一个模糊的概念来解释，大部分架构定义没有提到“组件”，组件也许是逻辑上的或物理存在的，技术上独立的或特定的，规模大的或规模小的。由于文章的原因，我使用了UML 2.0规范的组件定义；并且我相当宽松的使用这个概念来包含各种所遇到的架构成分，包括了对象，技术组件（例如Enterprise JavaBean），服务，程序模块，遗留系统，包应用程序等。 架构是对软件系统组织，结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。系统或计算系统的软件架构是包含软件部分，外部可见特性部分，和他们之间的关系的系统的结构。架构是系统的组织结构和相关行为。架构可被重复分解为通过接口，互联部分的关系和结合部相互作用的部分。通过接口相互作用的部分包括类，组件和子系统。 软件架构或系统由组成系统的结构的相互作用和软件结构的重要设计决定组成。设计决定应成功实现所期望支持的质量。设计决定为系统开发，支持和维护提供概念上的基础。虽然在某些方面定义有些区别，但我们可以看到大部分是相同的。 一个架构定义结构 如果你要求人们为你描述“架构”，十分之九的人都会参照结构来解释。这在关于构建或其他土木工程结构（例如桥梁）中非常常见。虽然这些条目中的其他属性（例如行为，目的适当性和美学观念）也存在，但是结构的属性是最熟悉的和最经常被提到的。 我们对你会让某人来描述一下他所工作的软件系统架构一点也不会感到奇怪，他们将会给你展示一份系统结构方面的图表——无论这些内容是否是架构层，组件，或是分布结点。事实上，结构是架构的基础属性。架构会以各种形式展示他们自己，且大部分架构的定义是非常模糊的。一个结构组件可能是一个子系统，进程，库，数据库，计算结点，馈赠系统，按需产品等等。 许多架构的定义不但承认了他们自己的结构元素，而且还有结构元素的组成，关系（任何连接部分都需支持这样的关系），接口。这些部件都以不同方式被提供。 一个架构定义行为 与定义结构元素一样，架构定义了这些结构元素的相互作用。这些作用可以实现所期望的系统行为。一个架构关注于重要元素 当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关心这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。 由于架构仅关注于重要元素，它给我们提供了在考虑中的系统的一个特殊透视图——与架构最相关的透视图。8在这种含义下，一个架构是一个系统的抽象，可以帮助架构师管理复杂性。 我们仅仅应注意重要元素的设置不是静态的。作为一个需要被提炼，确定风险，可执行的软件构建和经验总结的结果，重要元素的设置可能会改变。但是，面对改变的架构的稳定性是好的架构，好的可执行架构进程，好的架构师的标志。如果架构需要根据变化不断作出调整，那么这不是一个好的标志。但是，如果架构相对稳定，那么相反的也对。 一个架构可以平衡涉众需求 架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。 仅仅提供一个任务的例子，考虑如下涉众群各自的所需： 最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。 系统管理员关注直觉行为，管理和辅助监测