526互联

软件架构实践 V2：第二章

发布时间 2024-01-12 22:15:05作者: LHX2018

第二章 什么是软件架构

如果一个项目的系统构架 (包括理论基础) 尚未确定，就不应该进行此系统的全面开发。只有对构架做出明确清楚的表述，才能使之在整个开发和维护过程中加以充分利用。

——Barry Boehm

本章我们将严格地从软件工程的角度对构架进行讨论，即除了第1章中所讲到的企业所获得的价值外，我们还将研究软件构架对项目开发的重要意义。

2.1 软件架构概念的澄清

：某个软件或计算机系统的软件架构是该系统的一个或多个结构，它们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。

这里所说的某个元素的 "外部可见属性" 是指其他元素对该元素所做的假设，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。下面我们深入阐述一下该构架的含义。

  • 首先，构架定义了软件元素。构架中包含了关于各元素应如何彼此相关的信息。也就是说，构架必须省略各元素中与其交互无关的某些信息。因此，构架首先是对系统的抽象，该抽象去除了不影响它们如何使用、其他元素如何使用以及如何与其他元素关联或交互的细节。在几乎所有的现代系统中，各元素是通过接口实现交互的，而这些接口又将各元素的细节划分为公有和私有两大类。根据这种划分，构架属于公有部分，而私有部分一一即仅与内部具实现有关的细节一是不属于构架的。

  • 第二，该定义明确指出系统可能而且确实由多个结构组成，而且，其中任何一个结构并不能与构架等同。

  • 第三，该定义意味着具有软件的每个计算系统都有一个软件架构

  • 第四，只要某个元素的行为可以从其他元素的角度观察到或区别开，这个元素的行为就是构架的内容。正是这种行为的存在，才使各元素的交互成为可能，而这种交互显然是构架的一部分。这是被当做构架的框线图其实根本就不是构架的另一个原因。它们只是框线图，提供了所展示的元素做什么的更多信息。当看到这些框线图中某个框(数据库、图形用户接口、可执行代码等)的名字时，读者很可能会设想相应元素的功能和行为。与框线图相比，这种想象更接近于构架，但这种想象来自于读者的思维，依赖于某些在框线图中并未表示出来的信息。这并不是说在各种情况下都要对各元素的行为和性能给出精确的描述，但如果某个元素的行为对与之交互的另一个元素的代码编写有特定的要求，或者影响到整个系统的可接受性，则该行为就是软件构架的一部分

  • 最后，我们所给的这个定义并不涉及对架构优劣的评价，这意味着架构将支持或组织系统满足其行为、性能和生命期需求

2.2 其他观点

软件构架在不断发展，但它仍然是一个尚不成熟的学科；因此，它没有一个统一的、公认的定义。另一方面，目前有很多关于软件构架的定义。大多数常见的定义的要点都是一致的一一结构、元素以及元素之间的关系一一但它们在细节上有很大不同，不能互换。

通过研究设计人员所遵循的设计规范以及他们在开发实际系统时所采取的行动，对软件构架的研究得以不断发展。对系统设计中内在的共性进行抽象是一种尝试，由此它必须说明各种活动、概念、方法、途径和结果。鉴于此，软件工程团体中存在其他构架定义；因为您很可能会遇到其中的一些定义，因此应该理解这些定义的含义并能够对其进行讨论。下面是几个最常见的定义：

  • 架构是一种高层设计
  • 架构是系统的总体结构。这个常见说法（不正确地）暗含的意思是系统只有一个结构。我们知道这种说法是错误的，如果有人持这种观点，不妨问问他所说的结构到底指什么。
  • 架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构
  • 架构是组件和连接器。连接器是指系统运行时为传送控制和数据信息而采用的机制。因此，该定义主要强调了系统运行时的架构。

2.3 架构模式、参考模型和参考架构

  1. 架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。可以把架构模式看作是对架构的一组制约条件——即对各元素类型及其交互模式的限制条件，而这些制约条件就确定了一组或一系列能满足它们的架构。（B/S C/S）
  2. 参考模型是一种考虑数据流的功能划分。参考模型是对已知问题的标准分解，分解所得的各个部分相互协作，构成问题的解决方案
  3. 参考架构是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。参考模型实现了功能划分（参考结构则将这种功能划分与系统分解对应起来）。这种对应可能（但不一定必须）是一一映射。

参考模型、架构模式和参考架构都不是架构，但他们都是捕获架构元素的有用的概念。

2.4 为什么说软件架构非常重要

  1. 构架是涉众之间的交流
    1. 构架提供了一种共同语言，有关各方可借助它表达和协商各自的需求，并理性地找到解决方案，即使对大型、复杂系统的开发也是如此(参见下面的引文“按下这个按钮将会怎样”)。如果没有这样一种语言，要想充分理解大型系统并理智地做出对系统质量和易用性都具有重要影响的早期决策将十分困难。构架分析不仅依赖于而且促进了这个层次上的交流，第II部分将对此进行讨论
  2. 构架是早期设计决策
    1. 架构明确了对系统实现的约束条件
    2. 架构决定了开发组织的组织结构
    3. 架构阻止或支持系统的质量属性的实现
    4. 通过研究架构来预测系统质量
    5. 架构使推理判断和控制更改更简单
    6. 架构有助于循序渐进的原型设计
    7. 可以通过架构进行更准确的成本和进度估计
  3. 构架是可传递的、可重用的模型
    1. 产品线共享一个公共的架构
    2. 系统开发可以使用大型的、由其他组织开发的元素
    3. 少就是多：限制选择范围是值得的
    4. 架构使基于模板的开发成为可能
    5. 架构可以作为培训的基础

系统架构与软件架构：几乎没有差别

2.5 软件架构和视图

为了有意义地传达架构的信息，必须说明此刻正在讨论哪个或哪些结构——即采用的是架构的哪个视图

大体上将架构结构分为3组：

  • 模块结构
    • 分解
    • 使用
    • 分层
    • 类或泛化
  • 组件-连接器结构
    • 进程或通信进程
    • 并发
    • 共享数据或存储库
    • 客户机/服务器
  • 分配结构
    • 部署
    • 实现
    • 工作分配
      image