7. 系统架构设计基础知识

发表于 分类于

1 软件架构概念

1.1 软件架构的定义

  • 定义：软件架构(Software Architecture、简称 SA) 是系统的结构，包括软件的构件、构件的外部可见属性及其相互关系。
  • 作用
    1. 分析设计的有效性。
    2. 选择方案的可行性。
    3. 降低相关风险。

软件体系结构的设计通常考虑到设计金字塔中的两个层次——数据设计和体系结构设计。

1.2 软件架构设计与生命周期

1.2.1 需求分析阶段

  • 目标：分析和定义软件需求。
  • 任务
    1. 根据需求模型构建 SA 模型。
    2. 保证模型转换的可追踪性。

1.2.2 设计阶段

  • 目标：设计软件架构。
  • 任务
    1. 研究基于 SA 的测试技术。
    2. 寻求从 SA 到实现过渡的途径。
    3. 研究基于 SA 的验证方法。

1.2.3 实现阶段

  • 目标：实现软件架构。
  • 任务
    1. 研究基于 SA 的开发过程支持。
    2. 寻求从 SA 实现过渡的途径。
    3. 研究基于 SA 的测试技术。

1.2.4 构件组装阶段

研究内容包括如下两个方面。

  1. 如何支持可复用构件的互联，即对 SA 设计模型中规约的连接子的实现提供支持。
  2. 在组装过程中，如何检测并消除体系结构失配问题。

1.2.5 部署阶段

  • 目标：部署软件。
  • 任务
    1. 确定部署方案。
    2. 部署软件。

1.2.6 后开发阶段

  • 目标：主要围绕维护、演化、复用等方面来进行。
  • 任务
    1. 动态软件体系结构。
    2. 体系结构恢复与重建。

1.3 软件架构的重要性

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。

2 体系结构的软件开发方法

2.1 体系结构的设计方法概述

  • 基于体系结构的软件设计 (Architecture-Based Software Design, ABSD) 方法：自顶向下，递归细化的方法，通过概念子系统和构件逐步细化，直到产生软件构件。
  • 基础：功能分解、基于模块的内聚和耦合技术、软件模板的使用。

2.2 概念与术语

  1. 设计元素
    • 定义：软件系统的体系结构通过该方法得到细化。
    • 组成：概念子系统和概念构件。
  2. 视角与视图
    • 定义：从不同角度观察体系结构。
    • 视图：逻辑视图、进程视图、实现视图和配置视图。
  3. 用例和质量场景
    • 定义：推演系统行为的重要技术。
    • 作用：捕获质量需求。

2.3 基于体系结构的开发模型

  • 传统模型：存在开发效率不高，不能很好地支持软件重用等缺点。
  • ABSD 模型：整个软件开发过程划分为体系结构需求、设计、文档化、复审、实现和演化 6 个子过程。

2.4 体系结构需求

  1. 需求获取
    • 定义：获取用户需求。
    • 方法：从需求库中取出，加以利用和修改。体系结构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
  2. 标识构件
    • 定义：系统生成初始逻辑结构。
    • 过程：生成类图、对类进行分组、打包成构件。
  3. 架构需求评审
    • 定义：组织一个由不同代表(如分析人员、客户、设计人员和测试人员)组成的小组，对体系结构需求及相关构件进行仔细地审查。

2.5 体系结构设计

  1. 提出软件体系结构模型
    • 定义：选择合适的体系结构风格。
  2. 把已标识的构件映射到软件体系结构中
    • 定义：映射构件到体系结构。
  3. 分析构件之间的相互作用
    • 定义：分析构件间关系。
  4. 产生软件体系结构
    • 定义：细化中间结构。
  5. 设计评审
    • 定义：邀请评审体系结构。

2.6 体系结构文档化

主要输出两个文档：体系结构规格说明和测试体系结构需求的质量设计说明书。

2.7 体系结构复审

  • 定义：在一个主版本的软件体系结构分析之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。评估体系结构是否满足需求。
  • 过程：标识潜在风险，及早发现体系结构设计中的缺陷和错误。

2.8 体系结构实现

  • 实现：用实体来展示软件体系结构。
  • 过程：符合体系结构描述的结构性设计决策，分割成构件，按规定方式交互。
  • 步骤：
    1. 分析与设计
    2. 构件实现
    3. 构件组装
    4. 系统测试
    5. 体系结构演化

2.9 体系结构的演化

  • 演化：根据需求变化修改应用。
  • 步骤：
    1. 需求变化归类
    2. 制订体系结构演化计划
    3. 修改、增加或删除构件
    4. 更新构件的相互作用
    5. 构件组装与测试
    6. 技术评审

3 软件架构风格

3.1 软件架构风格概述

  • 软件体系结构风格：描述某一特定应用领域中系统组织方式的惯用模式。映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
  • 目标：研究和实践软件体系结构风格和类型问题。

3.2 数据流体系结构风格

数据流体系结构：与传统的冯·诺依曼体系结构或控制流体系结构不同，是一种计算机体系结构，指令执行的顺序是不可预测的，即行为是不确定的。

数据流体系结构风格包含以下 2 种

  1. 批处理体系结构风格
  • 在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必 须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。
    它的基本构件是独立的应用程序，连接件是某种类型的媒介。连接件定义了相应的数据流图，表达拓扑结构。
  1. 管道-过滤器体系结构风格
  • 当数据源源不断地产生，系统就需要对这些数据进行若干处理(分析、计算、转换等)。

3.3 调用/返回体系结构风格

调用/返回风格是指在系统中采用了调用与返回机制。利用调用-返回实际上是一种分而治之的策略。

  1. 主程序/子程序风格
  • 主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序 和子程序。子程序通常可合成为模块。
  1. 面向对象体系结构风格
  2. 层次型体系结构风格
  • 层次系统组成一个层次结构，每一层为上层提供服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。
  1. 客户端/服务器体系结构风格
  • C/S (客户端/服务器)软件体系结构是基于资源不对等，且为实现共享而提出的，在 90 年代逐渐成熟起来。

3.4 以数据为中心的体系结构风格

  1. 仓库体系结构风格
  • 定义：数据存储和维护的中心。
  • 特点：中央数据结构，独立构件。
  1. 黑板体系结构风格
  • 定义：解决复杂非结构化问题。
  • 特点：黑板系统作为信息处理器。
  • 应用领域：传统应用是信号处理领域，如语音识别和模式识别。另一应用是松耦合代理数据共享存取。

3.5 虚拟机体系结构风格

基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格。

  1. 解释器体系结构风格
  • 定义：程序执行的解释引擎。
  • 特点：执行效率低。
  1. 规则系统体系结构风格
  • 定义：基于规则的系统。包括规则集、规则解释器、规则/数据选择器及工作内存。
  • 特点：规则选择器和数据选择器。

3.6 独立构件体系结构风格

独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。

  1. 进程通信体系结构风格
  • 在进程通信结构体系结构风格中，构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。
  1. 事件系统体系结构风格
  • 事件系统风格基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
  • 应用：在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以及在编辑器中支持语法检查。

4 软件架构复用

4.1 软件架构复用的定义及分类

  • 定义：软件架构复用是指一组软件构件可以被多个系统所复用。
  • 分类：机会复用和系统复用。

4.2 软件架构复用的原因

  • 可以减少开发工作、减少开发时间以及降低开发成本，提高生产力
  • 提高产品质量使其具有更好的互操作性
  • 使产品维护变得更加简单

4.3 软件架构复用的对象及形式

基于产品线共性的“软件”产品线代表了软件工程中一个创新的、不断发展的概念。软件产品线的本质是在生产产品家族时，以一种规范的、策略性的方法复用资产。可复用的资产非常广。

在当前的趋势下，复用体由小粒度向大粒度的方向发展。

4.4 软件架构复用的基本过程

  1. 获取可复用资产
  • 定义：获取可复用资产。
  1. 管理可复用资产
  • 定义：构件库（Component Library）。
  1. 使用可复用资产
  • 定义：在开发中使用资产。

5 特定领域软件体系结构

5.1 DSSA 的定义

  • DSSA（Domain Specific Software Architecture）：特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。
  • 特点：
    1. 严格定义的问题域和问题解决方案。
    2. 具有普遍性，适用于领域中特定应用的开发。
    3. 对整个领域中使用的构件组织结构有恰当抽象。
    4. 具备该领域确定的、典型的在开发过程中可重用元素。

5.2 DSSA 的基本活动

  1. 领域分析
  • 目标：获得领域需求。
  1. 领域设计
  • 目标：描述领域需求的解决方案。
  1. 领域实现
  • 目标：实现解决方案。

5.3 参与 DSSA 的人员

  1. 领域专家
  • 定义：可能包括有经验的用户、领域专家、领域设计人员和领域实现人员。
  1. 领域分析人员
  • 定义：控制领域分析过程，进行知识获取，维护领域模型。
  1. 领域设计人员
  • 定义：控制软件设计过程，开发 DSSA。
  1. 领域实现人员
  • 定义：熟悉软件重用，实现领域软件构件。

5.4 DSSA 的建立过程

  1. 定义领域范围
  • 目标：确定感兴趣的领域。
  1. 定义领域特定的元素
  • 目标：编译领域字典和领域术语的同义词词典。
  1. 定义领域特定的设计和实现需求约束
  • 目标：描述解空间中有差别的特性。
  1. 定义领域模型和体系结构
  • 目标：产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。
  1. 产生、搜索可重用的产品单元
  • 目标：为 DSSA 增加构件，使它可以被用来产生问题域中的新应用。