计算机基础知识（第四篇）

优秀的颜
4 阅读1小时+

计算机基础知识（第四篇）

架构设计

概述

软件架构的定义：软件架构（Software Architecture）或称软件体系结构，是指系统的一个或者多个结构，这些结构包括的构件（可能是程序模块、类或者是中间件）、构件的外部可见属性及其之间的相互关系。体系结构的设计包括数据库设计和软件结构设计，后者主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述。

简单理解软件架构：软件架构指从需求分析到软件设计之间的过渡过程。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

软件架构的详细解释：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模以及这些模式的约束组成。

总结：在软件中，架构决策包括如何组织代码、模块和组件，如何处理数据流、用户界面和业务逻辑。好的软件架构能够确保软件具有良好的性能、可扩展性、可维护性和安全性，就像一个精心设计的大楼能够提供舒适和便捷的居住环境一样。所以，软件架构就是软件的总体设计方案，它决定了软件如何组织和工作，规定了软件系统的整体结构和各个部分之间的关系，以满足用户需求和业务目标。好的架构是构建可靠软件的基础。

软件体系结构设计：

  • 数据设计：数据设计为软件体系结构设计提供了数据基础。它涉及数据的存储、组织和管理，确保数据能够高效地被访问和处理。
  • 体系结构设计：体系结构设计为软件系统的整体结构提供了规划和设计。它涉及确定系统的主要组件及其交互方式，确保系统能够满足功能和非功能需求。

软件架构的定义：

  • 构件的描述
  • 构件的相互作用（连接件）
  • 指导构件集成的模式
  • 这些模式的约束

软件架构设计的生命周期

  1. 软件架构设计贯穿于软件开发生命周期的各个阶段。软件架构设计并非只在开发初期进行，而是贯穿于软件开发生命周期的各个阶段，包括需求分析、设计、实现、测试、部署和维护等。
  2. 需求分析阶段。需求分析和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。简单来说，该阶段关注的是如何将用户需求转换为软件架构模型，并确保模型的可追踪性。
  3. 设计阶段。是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次：SA的基本概念（构件和连接件）、体系结构描述语言ADL、SA模型的多视图表示。简单来说，该阶段关注的是软件架构模型的描述、设计与分析方法，以及设计经验的总结与复用。
  4. 实现阶段。最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在对开发过程的支持、开发语言和构件的选择以及相关测试技术。简单来说，该阶段关注的是如何将软件架构设计转换为代码，以及如何进行测试。
  5. 构件组装阶段。在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。简单来说，该阶段关注的是如何在架构设计模型的指导下，进行可复用构件的组装，提高系统实现效率，并解决组装过程中的相关问题。
  6. 部署阶段。提供高层的体系结构视图来描述部署阶段的软硬件模型，以及基于SA模型可以分析部署方案的质量属性， 从而选择合理的部署方案。简单来说，该阶段关注的是如何根据软件架构模型进行部署，并分析部署方案的质量属性。
  7. 后开发阶段。是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。简单来说，该阶段关注的是如何根据软件架构模型进行维护和演化。

软件架构设计贯穿于软件开发生命周期的各个阶段，每个阶段都有其特定的关注点和研究内容。通过这些阶段的研究和实践，可以确保软件架构设计在开发、实现、部署和维护过程中发挥其应有的作用，从而提高软件系统的质量和可维护性。

构件

在架构设计中，构件（Component）是指系统的重要部分，它们是功能上独立且可以被替代或扩展的模块或单元。外界通过接口访问其提供的服务，构件通常用来划分系统的不同功能或责任，以便更容易管理、维护和扩展整个系统。构件是系统架构的基本构建块，可以包括软件模块、类、库、服务等。

类 (Class)

类是面向对象编程中的基本概念，它描述了一种对象的属性和行为。类定义了对象的结构和行为模板，可以包括属性（数据成员）和方法（函数成员）。

模块 (Module)

模块是一组相关的函数、类、变量或代码块的集合，用于将代码组织成更小的可管理单元。模块可以是一个单独的文件或一组相关文件。

构件 (Component)

构件是指软件系统中的可复用组件。构件可以是代码、数据、文档或其他任何类型的软件资产。构件通常是松散耦合的，并且可以组合起来形成更大的软件系统。构件的典型示例包括类、模块、组件和框架。

服务 (Service)

服务是指提供特定功能的软件单元。服务通常是独立的、可复用的，并且可以通过网络进行访问。服务的典型示例包括 Web 服务、REST API 和微服务。

构件的组装方式：

  • 基于功能组装：通过子程序调用实现功能模块集成
  • 基于数据组装：围绕核心数据结构构建框架（如Jackson方法）
  • 面向对象组装：通过继承、多态实现复用

组装过程中的关键点：

  • 接口匹配：确保构件接口的输入／输出兼容性（如协议、数据格式）
  • 语境适配：调整构件对运行环境的依赖（如数据库连接配置）
  • 异常处理：解决组装失配问题（如通信协议不一致、数据模型冲突）

构件的作用：

构件技术是利用编程手段，将一些复杂的细节进行封装，并实现各种业务逻辑规则，用于处理用户的内部操作细节。构件技术使得复杂系统的开发和维护变得更加便捷和高效，避免了最终用户直接操作底层细节。目前，国际上常用的构件标准主要有三大流派：EJB、COM、DCOM、COM+和CORBA。

EJB

EJB 规范由 Sun 公司制定，主要用于 Java 平台的企业级应用开发。EJB 有三种类型：

  • 会话 Bean (Session Bean)：用于管理会话和业务逻辑，有不同的类型适应不同的需求。
  • 实体 Bean (Entity Bean)：用于与持久化数据交互，将对象映射到数据库表。
  • 消息驱动 Bean (Message-driven Bean)：用于异步消息处理，响应来自消息队列的消息。

COM、DCOM、COM+

这些技术由微软公司提出：

  • COM (Component Object Model)：微软公司的一种组件标准，用于创建可重用的软件组件。
  • DCOM (Distributed Component Object Model)：COM 的扩展，增加了位置独立性和语言无关性，支持分布式计算。
  • COM+：并不是 COM 的新版本，而是 COM 的进一步发展，提供了更高层次的应用功能。

CORBA

CORBA 标准由 OMG (Object Management Group) 制定，分为三个层次：

  • 对象请求代理 (ORB)：最底层，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”。
  • 公共对象服务：在 ORB 之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种服务。
  • 公共设施：最上层，定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

微服务架构标准

  • 核心规范：RESTful接口描述标准（替代CORBA IDL)
  • 技术栈：Spring Cloud Alibaba、Quarkus、Micronaut

云原生构件标准

  • 容器镜像标准（Docker/Containerd兼容）
  • 运行时规范（Kubernetes CRI标准）

跨平台互操作标准

  • GraphQL：替代传统SOAP/WSDL，实现前后端解耦
  • Apache Arrow：内存数据交换格式（跨语言／组件高效通

软件架构风格

软件架构风格的概念：是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。架构定义描述了系统的整体结构和组织方式。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。简单来说，软件体系结构风格就是一个模板，它规定了特定应用领域中软件系统应该如何构建。

软件架构风格的作用：反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

架构设计的一个核心问题是能否达到架构级的软件复用，强调对架构设计的重用。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

数据流风格

面向数据流，按照一定的顺序从前向后执行程序。

数据-批处理 批处理序列是一种架构风格，其构件是一系列按照固定顺序执行的计算单元。多个任务按照同步顺序执行，构件之间通过数据传递进行交互。每个处理步骤是一个独立的程序，必须在前一步结束后才能开始。数据以整体的方式传递，必须是完整的。典型的例子包括批量图像处理，如一次性处理大量图像，执行调整大小、添加水印或转换格式等操作。

管道-过滤器 管道-过滤器是一种架构风格，每个构件都有一组输入和输出。构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流相互关联。过滤器是构件，连接件是管道。典型的例子包括文本处理管道，在文本分析中，可以将文本处理划分为分词、词干提取、情感分析等多个阶段，每个阶段都是一个过滤器。早期编译器也采用这种架构，需要一步一步处理。

区别：

  • 批处理序列：通常一次性处理大量数据，离线执行，适用于批量处理任务。例如，批量图像处理。
  • 管道-过滤器：将任务分解为多个阶段，每个阶段逐个处理数据，通常是实时或近实时执行，适用于可组合和可扩展的任务。例如，文本处理管道。

调用/返回风格

构件之间存在互相调用的关系，一般是显式的调用。

主程序/子程序

在这种架构中，系统按照单线程控制的方式，将问题划分为若干个处理步骤。构件包括主程序和子程序，且子程序通常可以合成为模块。过程调用作为交互机制，充当连接件的角色。主要特点是通过调用来实现各处理步骤的顺序执行和数据传递。

面向对象

在面向对象的架构中，构件是对象。对象是抽象数据类型的实例，连接件即是对象间交互的方式。对象通过函数和过程的调用来进行交互。这种方法强调数据封装、继承和多态性，通过对象之间的消息传递实现系统功能。

层次结构

层次结构架构将系统构件分组成一个层次结构。连接件通过定义层间交互的协议来决定层间的互动。每层为上一层提供服务，并使用下一层的服务，只能看到与自己邻接的层。修改某一层最多影响相邻的两层（通常只能影响上层）。其优点是可以将一个复杂问题分解为一个增量步骤序列来实现，但缺点是并不是每个系统都可以轻易划分为分层模式，并且层次调用会影响效率。

客户端服务器 (C/S)

早期的两层C/S架构模式由三个部分组成：数据库服务器、客户端服务器和网络。服务器负责数据管理，客户端完成用户交互，称之为“胖客户端、瘦服务器”。后来，演变为三层C/S架构，增加了一个应用服务器，分别是表示层、功能层和数据层。表示层负责用户交互，功能层负责业务逻辑处理，数据层负责数据库处理。以上三层独立，互不干扰。

独立构件风格

构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行。

进程通信

定义：构件：独立的进程、连接件：消息传递

特性：

  • 构件通常是命名的过程。
  • 消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
  • 涉及不同进程或线程之间的通信和数据共享。
  • 这些进程可以运行在同一台计算机上，也可以分布在不同的计算机上。

事件驱动系统（隐式调用）

定义：

  • 构件不直接调用一个过程，而是触发或广播一个或多个事件。
  • 构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。

优点：

  • 为软件复用提供了强大的支持。
  • 为构件的维护和演化带来了方便。

缺点：

  • 构件放弃了对系统计算的控制，只能被动地控制。

虚拟机风格

自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配。 解释器、基于规则的系统

解释器

组成部分：

  1. 解释引擎：完成解释工作的核心组件。
  2. 代码存储区：包含将被解释的代码。
  3. 工作状态数据结构：记录解释引擎当前的工作状态。
  4. 进度数据结构：记录源代码的解释执行进度。

功能：

  • 解析和执行一系列指令或命令。
  • 将文本或代码解析成可执行的操作。

缺点：

  • 执行效率较低。

基于规则的系统

组成部分：

  • 规则集：预定义的一组规则或条件。
  • 规则解释器：解析和执行规则的组件。
  • 规则/数据选择器：选择适用的规则或数据。
  • 工作内存：存储当前工作的状态和数据。

应用领域：人工智能领域、决策支持系统（DSS）。

功能：

  • 根据一组事先定义的规则或条件来控制系统的行为。
  • 实现灵活的业务规则和决策逻辑。

数据为中心系统

以数据为中心风格 以数据为中心，所有的操作都是围绕建立的数据中心进行的。

仓库风格的架构

定义：

  • 将数据存储在一个中央仓库或数据库中。
  • 各个组件可以从仓库中读取和写入数据。
  • 组件之间通过共享数据仓库进行通信和协作。

黑板风格的架构

定义：

  • 类似于一个黑板或公告板，多个独立的组件称为“专家”共享一个公共存储区（黑板）。
  • 专家可以读取和写入数据。
  • 专家根据黑板上的信息进行推断和决策，适用于解决复杂的非结构化问题。

比较总结：

  • 仓库风格：强调数据的集中存储和共享，组件通过访问共享的仓库来交互。
  • 黑板风格：侧重于多个独立的组件共享一个中央知识存储区，根据共享的信息进行推断和决策。

闭环过程控制

闭环控制：当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。比如开空调，不会一调到某个温度就马上能到该温度，是逐渐接收室内的温度来变化输出空调的冷气。

C2风格

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

  • 系统中的构件和连接件都有一个顶部和一个底部；
  • 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不 允许的；
  • 一个连接件可以和任意数目的其它构件和连接件连接；
  • 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

软件架构复用

软件产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

软件架构复用

  • 机会复用：在开发过程中，只要发现有可复用的资产，就对其进行复用。
  • 系统复用：在开发之前进行规划，以决定哪些需要复用。

可复用的资产包括以下内容：

  • 需求：可重复使用的需求文档或需求规范。
  • 架构设计：可重复使用的系统架构或设计模式。
  • 元素：代码模块、库或组件。
  • 建模与分析：模型、分析工具和方法。
  • 测试：测试用例、测试脚本和测试环境。
  • 项目规划：项目计划、时间表和资源分配。
  • 过程方法和工具：开发过程、方法论和支持工具。
  • 人员：具备特定技能和经验的开发人员。
  • 样本系统：过去开发的原型或样本系统。
  • 缺陷消除：已识别和修复的缺陷及其对应的解决方案。

复用的基本过程

复用的基本过程主要包括以下三个阶段：

  • 构造/获取可复用的软件资产：创建或获取可复用的代码、设计文档、测试用例等。
  • 管理这些资产：将这些资产放入到构件库中进行管理，以便组织和检索。
  • 选择和复用：针对特定需求，从构件库中选择可复用的部分，以开发满足需求的应用系统。

层次架构风格

两层C/S架构：客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能复制易应用、安全性问题、服务器端压力大难以复用。

三层C/S架构：将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数库务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点：

  • 各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
  • 允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
  • 各层可以并行开发，各层也可以选择各自最适合的开发语言；
  • 功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。

三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。

三层B/S架构：是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点：

  • 使用浏览器作为客户端的话安全性难以控制；
  • 在数据查询等响应速度上，要远远低于C/S架构，因为C/S架构有部分数据储在本地；
  • 数据提交一般以页面为单位，数据的动态交互性不强。

混合架构风格：

  • 内外有别模型：企业内部使用C/S，外部人员访问使用B/S。
  • 查改有别模型：采用B/S查询，采用C/S修改。
  • 混合架构实现困难，且成本高。

富互联网应用RIA：弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下：

  • RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；
  • RIA简化并改进了B/S架构的用户交互；
  • 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
  • 本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序。

MVC架构

控制器（Controller)：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

模型（Model)：是应用程序用于处理应用程序数据逻辑部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。

视图（View)：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行在何实际的业务处理：

MVP架构

MVP（Model-View-Presenter）架构模式是MVC（Model-View-Controller）架构的一种变体，将MVC中的Controller替换为Presenter（呈现器）。其目的是为了完全切断View（视图）与Model（模型）之间的联系，由Presenter充当桥梁，实现View和Model之间通信的完全隔离。

MVP特点：

  • 双向通信：

    M（Model）、V（View）、P（Presenter）之间是双向通信。

  • Presenter作为桥梁：

    View与Model不直接通信，所有通信都通过Presenter进行。
Presenter完全把Model和View分离开，主要的程序逻辑在Presenter中实现。

  • 被动视图（Passive View）

    View非常薄，不包含任何业务逻辑，被称为“被动视图”，即没有主动性。
Presenter非常厚，所有的逻辑都在Presenter中实现。

  • 接口交互

    Presenter与具体的View没有直接关联，而是通过定义好的接口进行交互。
这种设计使得在变更View时，可以保持Presenter的不变，从而实现重用。

MVVM架构

MVVM:MVVM模式和MVC模式类似，主要目的是分离视图（View）和模型（Model)，实现双向绑定，有几大优点：

  • 低耦合，视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时 候Model可以不变，当Model变化的时候View也可以不变。
  • 可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
  • 独立开发，开发人员可以专注于业务逻辑和数据的开发（ViewModel)，设计人员可以专注于页面设计。
  • 可测试，界面向来是比较难于测试的，而现在测试可以针对ViewModel来写。

面向服务的架构风格

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线（ESB）提出服务请求，由应用管理来进行处理。

实施SOA的关键目标与特征：

  • 可从企业外部访问：服务可以被企业外部的系统或用户访问。
  • 随时可用：服务请求能被及时响应，保证服务的可用性。
  • 粗粒度接口:粗粒度服务提供特定的业务功能，而细粒度服务代表技术组件方法。
  • 服务分级：服务根据重要性和使用频率进行分级管理。
  • 松散耦合：服务提供者和服务使用者分离，减少依赖，提高灵活性。
  • 可重用的服务及服务接口设计管理：设计和管理可重用的服务及其接口。
  • 标准化的接口：使用WSDL、SOAP、XML作为核心标准。
  • 支持各种消息模式：支持不同类型的消息传递模式。
  • 精确定义的服务接口：服务接口定义明确，确保通信的准确性。

基于服务的构件与传统构件的区别：

粒度

  • 服务构件：粗粒度。
  • 传统构件：细粒度居多。

接口标准

  • 服务构件：标准化接口，主要是WSDL接口。
  • 传统构件：常以具体API形式出现。

实现与语言无关

  • 服务构件：实现与语言无关。
  • 传统构件：常绑定于某种特定的语言。

QoS服务

  • 服务构件：可以通过构件容器提供QoS（质量保证）的服务。
  • 传统构件：完全由程序代码直接控制。

关键技术

UDDI:

UDDI是一套基于WEB的、分布式的、为WebService提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的WebService注册，以便其他企业能够发现和访问的协议实现标准。它用于Web服务的统一描述、发现及集成。

WSDL

WSDL（服务描述语言）将Web服务描述定义为一组服务访问点。客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问，类似于远程调用。WSDL用于描述服务。

SOAP

SOAP（简单对象访问协议）是用于交换XML编码信息的轻量级协议，用于在分布式环境中传递信息。

XML

XML（可扩展标记语言）是WebService平台中表示数据的基本格式，用于数据交换。

主要的实现方式

在面同服务的架构（SOA）中，有多种实现技术和方法，其中包括Web Service、服务注册表、企业服务总线（ESB)

  • Web Service：利用标准化的Web协议实现服务的调用
  • 企业服务总线（ESB)：作为服务间通信的中间件，提供消息路由和转换功能
  • 服务注册表：用于服务的发现和查找；

WEB Service: WebService是一种网络服务，它使不同系统之间能够通过网络进行通信和数据交换。

WebService基于标准的网络协议（如HTTP和HTTPS)，并使用XML、JSON等数据格式，使系统能够跨平台、跨语言通信。WebService 可以被视为SOA实现的核心技术之一，它通过服务接口使不同系统之间的数据交换变得更加容易。

WebService主要由以下三个核心组件组成：

  • 服务提供者（Service Provider)：提供具体服务的实体，负责发布服务并处理服务请求。
  • 服务请求者（Service Consumer)：使用服务的实体，通过网络请求访问服务。
  • 服务注册中心（Service Registry)：管理服务的注册和查找信息，服务提供者在服务注册中心注册服务，服务请求者可以从注册中心获取服务的访问地址。

WebService的工作流程通常包含以下步骤：

  • 服务注册：服务提供者将服务的WSDL描述文档注册到服务注册中心。
  • 服务查找：服务请求者通过查询服务注册中心，获取所需服务的WSDL文档。
  • 服务调用：服务请求者根据WSDL文档描述的信息，构造请求消息，发送到服务提供者，进行了请求绑定。
  • 服务响应：服务提供者处理请求并返回响应消息给服务请求者。

WebService的实现主要有两种协议标准：基于SOAP的WebService和基于REST的WebService。

SOAP：是一种基于XML的消息传递协议，通常用于实现企业级WebService。SOAP消息通常在HTTP协议的请求和响应体中传输，也支持其他传输协议（如SMTP)。SOAP协议规范包括消息格式、服务描述（WSDL）和消息传输的安全性。

REST：使用 HTTP方法（GET、POST、PUT、DELETE）进行资源的操作。RESTful服务通过JSON或XML格式传输数据，更加简洁高效，广泛应用于互联网服务和轻量级应用。

在实际的WebService与SOA实现中，会遇到以下几个挑战：

性能问题：由于WebService需要序列化和反序列化数据，尤其是在SOAP协议下，数据量较大，传输效率低，导致性能下降。可以通过以下方式优化：

  • 使用RESTful API进行轻量级服务。
  • 使用缓存机制减轻负载。

安全问题：WebService数据传输在安全风险，尤其是在互联网环境下。解决方案包括：

  • 使用HTTPS加密数据传输。
  • 实现身份认证和访问控制（如OAuth、JWT等）。

复杂数据的处理：在需要处理复杂数据结构时，可以选择SOAP协议，结合WSDL和XML Schema来支持复杂数据类型。

服务注册表

  • 服务注册：应用开发者（服务提供者）在注册表中公布服务的功能。
  • 服务位置：服务使用者（服务应用开发者）查询注册服务，寻找符合自身要求的服务。
  • 服务绑定：服务使用者利用检索到的服务接口编写代码，将代码与注册的服务绑定，并调用注册的服务，实现互动。

企业服务总线（ESB）

企业服务总线（ESB）是用于连接各个服务节点的管道。它集成了基于不同协议的不同服务，通过消息的转化、解释和路由，使不同的服务互联互通。ESB的主要特点包括：

  • 总线作用：将各种服务进行连接与整合。
  • 描述服务的元数据和服务注册管理。
  • 数据传递和转换：在服务请求者和提供者之间传递数据，并对数据进行转换，支持同步模式和异步模式等。
  • 动态交互：具备发现、路由、匹配和选择的能力，支持服务之间的动态交互，解耦服务请求者和服务提供者。
  • 高级功能：包括对安全的支持、服务质量保证、可管理性和负载平衡等。

特定领域软件架构（DSSA）

特定领域软件架构（DSSA）是专用于解决某一特定类型任务（领域）的架构。它在该领域内提供了一套标准化的组合结构和软件构件，以满足独特需求和约束。DSSA通过结合特定问题领域的专业知识和最佳实践，优化软件系统的设计，从而提高性能、可维护性和可扩展性。

DSSA的主要特点：

  • 专用性：DSSA针对特定领域的需求和约束进行优化，提供定制化解决方案。
  • 标准化：通过定义标准的架构和组件，确保领域内的一致性和兼容性。
  • 高效性：结合领域内的最佳实践，提高开发效率和系统性能。
  • 可维护性：标准化的架构和组件使得系统更容易维护和升级。
  • 可扩展性：模块化设计使得系统可以灵活扩展，以应对不断变化的需求。

DSSA的组成部分：

  1. 领域模型：描述特定领域中的概念和关系。
  2. 参考需求：定义特定领域中的通用需求和约束。
  3. 参考架构：提供一个通用的架构模板，指导系统的设计和实现。

DSSA的应用：

  • 垂直域：在一个特定领域中的通用软件架构。例如，电子病历系统、医院信息系统或医学影像分析系统。
  • 水平域：在多个不同领域之间的通用部分。例如，购物和教育领域中的收费系统，或网络安全通用架构。

DSSA的三个基本活动：

特定领域软件架构（DSSA）的开发过程包括三个基本活动：领域分析、领域设计和领域实现。这三个阶段有助于确保系统能够满足特定领域的需求，并具备可维护和可重用的特性。

领域分析：这个阶段的主要目标是获得领域模型（领域需求）。识别信息源（需求），即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

领域设计：这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

领域分析用于确定需求，领域设计用于提供通用架构，而领域实现用于将该架构转化为具体的应用程序模块。这个过程有助于确保系统能够满足特定领域的需求，并具备可维护和可重用的特性。

DSSA的四种角色人员：

  • 领域专家：提供需求规约和实现知识，组织领域字典，选择样本系统，复审领域模型和DSSA。
  • 领域分析人员：控制领域分析过程，获取并组织知识，建立领域模型。
  • 领域设计人员：开发DSSA，验证其准确性和一致性。
  • 领域实现人员：根据领域模型和DSSA开发具体的系统构件。

每个角色在DSSA的开发过程中都扮演着至关重要的角色，确保系统能够高效、准确地满足特定领域的需求。

建立DSSA的过程：

  • 定义领域范围：确定领域应用的范围以满足用户需求。
  • 定义领域特定的元素：建立领域字典，归纳术语，识别相同和不同的元素。
  • 定义领域特定的设计和实现需求的约束：识别和分析设计和实现的约束及其影响。
  • 定义领域模型和架构：开发领域模型和一般架构，描述其构件。
  • 产生、搜集可复用的产品单元：生成和搜集复用构件，集成到DSSA中。

以上过程是并发的、递归的、反复的、螺旋型的，以确保DSSA能够有效满足领域需求，并具备高效性和可维护性。

领域开发环境：

  • 领域开发环境：由领域架构师负责，制定核心架构和参考结构，以创建通用框架满足多个系统需求。
  • 领域特定的应用开发环境：由应用工程师负责，根据具体需求将核心架构实例化为具体应用程序。
  • 应用执行环境：由操作员负责，实际部署和运行实例化的系统。

这三个层次的模型协同工作，确保系统能够高效开发和运行，满足特定领域的需求。

基于架构的软件开发（ABSD）

基于架构的软件开发（Architecturally Based Software Development,ABSD）是一种软件开发方法，强调在开发过程中首先定义系统的体系结构，然后根据这个体系结构来实现系统。它有助于确保系统的结构和设计与业务需求保持一致。

假设一家电子商务公司决定开发一个全新的在线购物网站，他们采用基于架构的软件开发方法：

  • 定义系统架构：首先，开发团队会定义系统的体系结构，包括用户界面层、业务逻辑层和数据存储层。这些层次将被明确定义，以确保开发过程中每个组件的职责清晰明确。
  • ABSD的关键决策：在系统架构阶段，团队会做出一些关键的架构决策，例如选择使用哪种技术堆栈、如何处理用户身份验证、如何处理库存管理、如何处理支付等。这些决策是ABSD的核心，它们会在整个开发过程中起到指导作用。
  • 系统实施：一旦系统架构被定义和核心决策被制定，开发团队会开始实施系统。他们会根据架构中的不同层次来编写代码，确保各个组件按照系统设计进行开发。
  • 持续维护和演化：随着时间的推移，业务需求可能会发生变化，但由于系统的基本架构已经定义，团队可以相对容易地进行扩展和修改，而不必重新设计整个系统。

基于架构的软件开发方法强调了在软件开发过程中先关注系统的结构和核心决策，以确保最终的系统能够满足业务需求并具有良好的扩展性和维护性。这个方法有助于降低项目失败的风险，因为它强调了在开发之前做出关键决策的重要性。

ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。

ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构进行复用。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。

开发过程

基于架构的软件开发过程可分为下列六步：

  1. 架构需求：重在掌握标识构件的三步，分为：需求获取、生产类图、对类图进行分组、把类打包成构件、需求评审。

  2. 架构设计：将需求阶段的标识构件映射成构件，进行分析，分为：提出架构模型、映射构件、分析构件互相作用、产出架构、设计评审。

  3. 架构(体系结构)文档化：主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

  4. 架构复审：由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。

  5. 架构实现：用实体来显示出架构。实现构件，构件组装成系统，分为：复审后的文档化架构、分析与设计、构件实现、构件组装、系统测试、架构演化。

  6. 架构演化：对架构进行改变，按需求增删构件，使架构可复用，分为：需求变化归类、架构演化计划、构件变动、更新构件的相互作用、构件组装与测试、技术评审、演化后的架构。

中间件技术

中间件作为应用软件与各种操作系统之间使用的标准化编程接口和协议，可以起承上启下的作用，使应用软件的开发相对独立于计算机硬件和操作系统，并能在不同的系统上运行，实现相同的应用功能。

中间件分类如下：

  • 通信处理（消息）中间件：在分布式系统中，人们要建网和制定出通信协议，以保证系统能在不同平实现分布式系统中可靠的、高效的、实时的跨平台数据传输。如RabbitMQ
  • 事务处理（交易）中间件：使大量事务在多台应用服务器上能实时并发运行，并进行负载平衡的调度，具有监视和调度整个系统的功能。如Seata（阿里开源的分布式事务解决方案）
  • 数据存取管理中间件：为在网络上虚拟缓冲存取、格式转换、解压等带来方便。如Hibernate
  • Web 服务器中间件：浏览器图形用户界面已成为公认规范，然而它的会话能力差，不擅长做数据的写入任务，受HTTP 协议的限制多等，就必须对其进行修改和扩充。如tomcat、NGINX
  • 安全中间件，如Shiro、Spring Security
  • 跨平台和架构的中间件：在分布式系统中，还需要集成各结点上的不同系统平台上的构件或新老版本的构件。如Dubbo
  • 网络中间件：包括网管、接入、网络测试、虚拟社区和虚拟缓冲等，如Nginx、HAProxy（高性能负载均衡器）

质量属性

软件系统属性

软件系统属性：软件系统属性可以分为功能属性和质量属性。

软件系统质量属性：

  • 性能 (Performance): 系统在资源利用效率、响应时间和吞吐量等方面的表现。
  • 可靠性 (Reliability): 系统在规定条件下和规定时间内运行的能力，包括可用性、容错性和恢复性。
  • 可维护性 (Maintainability): 系统的设计和实现容易理解、修改和测试的能力。
  • 可移植性 (Portability): 系统在不同环境中运行的适应性和安装难易程度。
  • 安全性 (Security): 系统保护数据和防止未授权访问的能力。
  • 用户体验 (Usability): 用户在学习、使用和满意度方面的体验。

软件架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。

确定软件系统架构并精确描述质量属性场景后，就需要对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于软件架构评审等工作。

质量属性的分类：

  • 开发期质量属性: 主要关注系统在开发过程中的表现，如可维护性、可测试性等。
  • 运行期质量属性: 主要关注系统在运行过程中的表现，如性能、可靠性、安全性等。

开发期质量属性主要指在软件开发阶段所关注的质量属性，这个阶段关注人群主要是开发者，包含6个方面：

  • 易理解性：指设计被开发人员理解的难易程度。
  • 可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
  • 可重用性：指重用软件系统或某一部分的难易程度。
  • 可测试性：对软件测试以证明其满足需求规范的难易程度。
  • 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
  • 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

运行期质量属性主要指在软件运行阶段所关注的质量属性，这个阶段关注人群主要是用户，包含7个方面：

  • 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
  • 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
  • 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
  • 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
  • 可靠性：软件系统在一定的时间内持续无故障运行的能力。
  • 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
  • 鲁棒性：是指软件系统在非正常情况（用户进行了非法操作、相关软硬件系统发生了故障）下仍能够正常运行的能力，也称健壮性或容错性

面向架构评估的质量属性

性能 (Performance)

指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。

设计策略:

  • 优先级队列: 优先处理重要任务以提高整体性能。
  • 增加计算资源: 增加服务器、CPU、内存等硬件资源以提升处理能力。
  • 减少计算开销: 优化算法和代码，提高效率。
  • 引入并发机制: 使用多线程或多进程技术，提高并发处理能力。
  • 采用资源调度: 动态分配和调度资源，避免资源浪费。

可靠性 (Reliability)

定义: 系统在一段时间内保持正常运行而不发生故障的能力。它强调了系统的稳定性和可靠性，通常通过衡量系统在一段时间内发生故障的概率来评估。可靠性指标包括MTTF（平均无故障时间）、MTBF（平均故障间隔时间）、MTTR（平均故障修复时间）。MTBF=MTTF+MTTR。

设计策略:

  • 心跳: 通过定期发送信号检测系统是否正常运行。
  • Ping/Echo: 使用Ping命令检测系统的连通性。
  • 冗余: 增加系统冗余设计，确保单点故障不会导致系统停机。
  • 选举: 在分布式系统中，选举主节点以确保系统的正常运行。

可用性 (Availability)

定义: 系统在需要的时候可供使用的能力，即系统处于可操作状态的时间比例。可用性通常通过计算系统在一定时间内可操作的百分比来评估。一个高可用性的系统意味着它在大部分时间内都是可用的，用户可以随时访问和使用它。

设计策略:

  • 心跳: 定期检测系统组件的健康状态。
  • Ping/Echo: 确保系统的网络连通性。
  • 冗余: 通过增加备份服务器和数据冗余，提高系统的可用性。
  • 选举: 使用主从切换机制确保系统在故障后迅速恢复。

可靠性和可用性的区别:

  • 可靠性: 强调系统不发生故障。例如，A公司过去一年中从未发生过故障，系统具有很高的可靠性。
  • 可用性: 强调系统在需要时可供使用。例如，B公司过去一年中总共停机了5小时，但它提供了冗余备份和快速恢复机制，系统具有很高的可用性。

安全性 (Security)

定义: 系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。

设计策略:

  • 入侵检测: 检测和防御系统受到的非法访问和攻击。
  • 用户认证: 确认用户身份，防止未授权用户访问系统。
  • 用户授权: 控制用户权限，确保用户只能访问其被授权的资源。
  • 追踪审计: 记录用户操作日志，以便追踪和审计用户活动。

可修改性 (Modifiability)

定义: 能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价来衡量。

设计策略:

  • 接口-实现分类: 将接口与实现分开，使得更改实现时不影响接口。
  • 抽象: 使用抽象层次来隔离变化。
  • 信息隐藏: 隐藏内部细节，减少变更对其他部分的影响。

功能性 (Functionality)

定义: 系统所能完成所期望的工作的能力。任务的完成需要系统中许多或大多数构件的相互协作。

设计策略:

  • 功能分解: 将系统功能分解成独立的模块或服务。
  • 明确接口: 定义清晰的接口，使各功能模块可以协同工作。
  • 一致性检查: 确保所有模块在功能实现上的一致性和完整性。

可变性(Variability/Scalability)

定义: 体系结构经扩充或变更而成为新体系结构的能力。新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构，（可扩展性） 。

设计策略:

  • 模块化设计: 通过模块化设计来支持扩展和变化。
  • 插件架构: 使用插件机制来增加或替换功能。
  • 配置管理: 使用配置文件来管理和应用不同的设置和扩展。

互操作性 (Interoperability)

定义: 作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。

设计策略:

  • 标准化接口: 使用标准协议和接口，如RESTful API、SOAP等。
  • 数据格式标准化: 使用标准的数据格式，如JSON、XML等。
  • 兼容性测试: 定期进行兼容性测试，确保系统与其他系统的互操作性。

易用性 (Usability)

定义: 关注软件系统的用户界面和交互设计，以确保用户能够轻松、高效地使用系统，并感到满意。易用性不仅关乎用户界面的外观，还包括用户体验、交互流程和用户学习曲线等方面。

设计策略:

  • 用户研究: 通过用户研究了解用户需求和使用习惯。
  • 界面设计: 设计直观、简洁的用户界面。
  • 用户测试: 通过用户测试不断改进用户体验。
  • 交互设计: 设计流畅、自然的交互流程，减少用户学习曲线。

质量属性场景描述

为了精确描述软件系统的质量属性，通常采用质量属性场景 (Quality Attribute Scenario) 作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

质量属性场景是一种用于描述系统如何满足特定质量属性需求的情境或情景。它由以下6部分组成：

刺激源 (谁):

  • 定义: 生成该刺激的实体，可能是人、计算机系统或者任何其他刺激器。
  • 示例: 用户、外部系统、定时器等。

刺激 (做什么):

  • 定义: 当刺激到达系统时需要考虑的条件。
  • 示例: 用户请求、系统调用、定时任务等。

环境 (在什么样的环境下):

  • 定义: 该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
  • 示例: 正常运行时、系统过载时、维护模式下等。

制品 (对哪个功能):

  • 定义: 某个制品被激励。这可能是整个系统，也可能是系统的一部分。
  • 示例: 数据库、用户界面、API接口等。

响应 (得到什么反馈):

  • 定义: 该响应是在激励到达后所采取的行动。
  • 示例: 返回结果、记录日志、发送通知等。

响应度量 (对反馈进行度量):

  • 定义: 当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
  • 示例: 响应时间、成功率、吞吐量等。

系统架构评估

敏感点：是指为了实现某一种特定的质量属性，一个或多个构件所具有的特性。

权衡点： 是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。

软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求，有时候还需要针对质量属性进行评估架构是否能满足。

评估方式

基于调查问卷（检查表）的方式

这种方式类似于需求获取中的问卷调查，但侧重于架构方面的问卷。评估人员需要对领域和架构有一定的了解，才能理解并回答与架构相关的问题。此方式通常用于获取主观反馈和意见，以改进架构。

基于度量的方式

此方式通过制定一些定量指标来度量架构，如代码行数、内存使用、响应时间等，以评估系统的各个方面。评估人员需要对架构的技术细节和度量标准有一定了解。

基于场景的方式

这是主要的评估方法，涉及定义一系列场景或情境，以测试系统在各种条件下的表现。每个场景描述了一种特定的使用情况，包括输入、预期输出和性能指标。评估人员会模拟这些场景，并评估系统是否满足质量属性需求。场景是从风险承担者的角度对与系统交互的简单描述。

实施过程：

  • 确定应用领域的功能和软件架构的结构之间的映射。
  • 设计用于体现待评估质量属性的场景（即4+1视图中的场景）。
  • 分析软件架构对场景的支持程度。要求评估人员既对领域熟悉，也对架构熟悉。

场景设计的三个方面：

  1. 刺激（事件）：触发架构响应的事件。
  2. 环境（事件发生的环境）：事件发生的背景条件。
  3. 响应（架构响应刺激的过程）：系统如何应对刺激。

基于场景的架构分析方法 (SAAM)

SAAM 是一种用于分析软件系统非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法之一。

特定目标

SAAM 的目标是对描述应用程序属性的文档进行分析，验证基本的架构假设和原则。

评估技术

SAAM 使用的评估技术是场景技术，通过定义一系列场景来具体化质量属性。

质量属性

SAAM 的基本特点是将任何形式的质量属性具体化为场景。尽管可修改性是 SAAM 分析的主要质量属性，但它也可以评估其他质量属性。

风险承担者

SAAM 协调不同参与者之间感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。

架构描述

SAAM 用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。架构描述包含功能、结构和分配三个主要方面。

方法活动

SAAM 的主要输入包括问题描述、需求声明、架构描述。评估过程包括以下五个步骤：

  • 场景开发：定义一系列用于评估的场景。
  • 架构描述：描述系统的架构，包括功能、结构和分配。
  • 单个场景评估：评估每个场景对架构的影响。
  • 场景交互：分析多个场景之间的交互和冲突。
  • 总体评估：对整个架构进行综合评估，形成最终报告。

ATAM（架构权衡分析法）

架构权衡分析法ATAM，是一种系统架构评估方法，主要在系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。

ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析以及架构评审与折中。整个评估过程强调以属性（质量属性）作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM主要活动领域：

  • 场景和需求收集：收集并定义系统的使用场景和需求，确保所有相关利益方的需求都被考虑。
  • 体系结构视图和场景实现：通过不同的架构视图展示系统的设计，并演示如何在这些视图中实现收集的场景。
  • 属性模型构造和分析：为每个质量属性构造模型，并进行分析以评估系统在这些属性上的表现。
  • 架构评审与折中：对架构进行评审，识别并讨论各质量属性之间的折中关系，以确定最优的架构设计方案。

效用树的结构包括：

  • 树根：质量属性
  • 属性分类：对质量属性进行详细分类
  • 质量属性场景：具体的应用场景（叶子节点）

质量属性的优先级排序：

ATAM主要关注的四类质量属性为性能、安全性、可修改性和可用性，因为这些是利益相关者最为关心的。得到初始的效用树后，需要对这棵树进行修剪，保留重要场景（通常不超过50个），再对这些场景按重要性和实现难度进行优先级排序。

优先级对的确定：

  • 重要性：用 H（高）、M（中）、L（低）的形式表示
  • 难易度：用 H（高）、M（中）、L（低）的形式表示

ATAM的阶段解释

1. 描述和介绍阶段

目标：

  • 收集相关架构材料。
  • 定义评估目标和评估的软件架构。
  • 明确要优化的质量属性。
  • 介绍ATAM方法的步骤和原则。

活动：

  • 评估团队与项目干系人一起定义评估的目标，确定评估的软件架构。
  • 收集架构文档和相关信息。
  • 介绍ATAM方法的步骤，以确保所有参与者了解评估的过程。

2. 调查和分析阶段

目标：

  • 确定架构方法。
  • 分析架构并评估这些方法对质量属性的影响。
  • 识别潜在的问题和权衡决策。

活动：

  • 定义架构方法，分析不同的架构设计。
  • 生成质量属性效应树，表示不同决策对质量属性的影响。
  • 识别潜在的问题和决策权衡。

产出：质量属性效应树

3. 测试阶段

目标：

  • 验证架构是否满足质量属性需求。

活动：

  • 创建测试用例模拟质量属性场景，包括性能测试、安全性测试等。
  • 运行这些测试用例，测量系统的性能和行为，并记录测试结果。
  • 讨论各种质量属性场景，分级它们的重要性。
  • 分析不同的架构方法，以确定哪种方法最有可能满足关键场景的需求。
  • 项目干系人对不同的架构方法和场景分级进行投票，以帮助确定最佳架构方案。

4. 报告阶段

目标：

  • 总结评估的结果。
  • 提供改进建议。
  • 为决策者提供决策依据。

活动：

  • 生成ATAM评估报告，包括评估发现、性能数据、改进建议及权衡决策。
  • 报告应清晰传达关键信息，帮助决策者做出明智的架构决策。

成本效益分析法 (CBAM)

成本效益分析法CBAM：用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。

有下列步骤：

  • 整理场景（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）
  • 对场景进行细化（对每个场景详细分析，确定最好、最坏的情况）
  • 确定场景的先级（项目干系人对场景投票，根据投票结果确定优先级）
  • 分配效用（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）
  • 形成"策略﹣场景﹣响应级别的对应关系"
  • 确定期望的质量属性响应级别的效用（根据效用表确定所对应的具体场景的效用表）
  • 计算各架构策略的总收益
  • 根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最的架构策略）

其他评估方法

SAEM方法

SAEM（Software Architecture Evaluation Model）方法将软件架构视为一个最终产品和设计过程中的一个中间产品，从外部质量属性和内部质量属性两个角度阐述评估模型，旨在为软件架构的质量评估创建基础框架。外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。

SAABNet方法

SAABNet方法用于表达和使用定性知识辅助架构的定性评估，来源于人工智能允许不确定、不完整知识的推理。使用BBN（Bayesian Belief Network）表示和使用开发过程中的知识，包含定性和定量描述。

SACMM方法

SACMM（Software Architecture Change Management Model）是一种软件架构修改的度量方法。

SASAM方法

SASAM（Software Architecture Static Analysis Method）通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的架构）进行映射和比较来静态地评估软件架构。

ALRRA方法

ALRRA（Architecture Level Reliability Risk Assessment）是一种软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。

AHP方法

AHP（Analytic Hierarchy Process）是一种对定性问题进行定量分析的多准则决策方法。

COSMIC+UML方法

基于度量模型来评估软件架构可维护性的方法。采用统一的COSMIC（Common Software Measurement International Consortium）度量方法来进行度量和评估，主要用于辅助分析软件架构的演化方案是否可行，并在开源软件DCMMS的软件架构UML组件图上进行验证。

软件可靠性

软件可靠性基本概念

软件靠性软件产品规定条件规间区间完成规定功能的能力。

软件可靠性和硬件可靠性区别：

  • 复杂性：软件复杂性比硬件高，大部分失效来自于软件失效。
  • 物理退化：硬件失效主要是物理退化所致，软件不存在物理退化。
  • 唯一性：软件是唯一的，软件复制不改变软件本身，而任何两个硬件不可能绝对相同。
  • 版本更新周期：硬件更新较慢，软件更新较快。

软件可靠性的定量描述：

  • 规定时间：自然时间、运行时间、执行时间（占用CPU)。
  • 失效概率：软件运行初始时为0，随着时间增加单调递增，不断趋向于1.
  • 可靠度：软件系统在规定的条件下、规定的时间内不发生失效的概率。等于1﹣失效概率。
  • 失效强度：单位时间软件系统出现失效的概率。
  • 平均失效前时间（MTTF)：平均无故障时间，发生故障前正常运行的时间。
  • 平均恢前时间（MTTR)：平均故障修复时间，发生故障后的修复时间。
  • 平均故障间隔时间（MTBF)：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间。
  • MTBF=MTTF+MTTR。

软件可靠性测试的定义：

广义的软件可靠性测试:

为了最终评价软件系统的可靠性，运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。

狭义的软件可靠性测试:

为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试。这种测试是面向缺陷的，以用户将要使用的方式来测试软件。

可靠性测试在确保软件的稳定性和安全性方面具有关键意义。通过广义和狭义的可靠性测试方法，可以更全面地评估和提升软件系统的可靠性，减少失效风险，控制成本，并适应不断增长的社会和生产需求。

可靠性测试的意义：

  • 软件失效可能造成灾难性的后果。
  • 软件的失效在整个计算机系统失效中的比例较高。
  • 软件可靠性技术很不成熟，加剧了软件可靠性问题的重要性。
  • 软件可靠性问题是造成费用增长的主要原因之一。
  • 软件对生产活动和社会生活的影响越来越大，从而增加了软件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。

软件可靠性建模与管理

软件可靠性模型是为预计或估算软件的可靠性而建立的可靠性框图和数学模型，用于分析和预测软件在实际运行中的可靠性表现。

影响软件可靠性的主要因素：

  • 运行环境
  • 软件规模
  • 软件内部结构
  • 软件的开发方法和开发环境
  • 软件的可靠性投入

软件可靠性模型的组成部分：

模型假设:

模型是对实际情况的简化或规范化，包含若干假设，例如测试选取代表实际运行剖面，不同软件失效独立发生等。

性能度量:

软件可靠性模型的输出量，如失效强度、残留缺陷数等。这些性能度量通常以数学表达式给出。

参数估计方法:

某些可靠性度量的实际值无法直接获得，例如残留缺陷数，需要通过一定的方法估计参数的值，从而间接确定可靠性度量的值。

数据要求:

一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。

软件可靠性设计

软件可靠性管理：为了进一步提高软件的可靠性，人们提出要把软件可靠性活动贯穿整个软件开发的全过程。

为什么需要可靠性设计：实践证明，保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。为了从根本上提高软件的可靠性，人们就提出了可靠性设计。

可靠性设计其实就是在常规的软件设计中，应用各种方法和技术，使程序设计在兼顾用户的功能和性能需求的同时，全面满足软件的可靠性要求。

软件可靠性设计原则：

  • 软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计原则相冲突。
  • 软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标。
  • 软件可靠性设计应确定软件的可靠性目标，不能无限扩大化，并且排在功能度、用户需求和开发费用之后考虑。

软件可靠性设计技术主要有容错设计、检错设计和降低复杂度设计等技术。

容错：指系统在运行过程中发生一定的硬件故障或软件错误时，仍能保持正常工作而不影响正确结果的一种性能或措施。

容错技术主要有：恢复块设计、N版本程序设计和冗余设计这三种。

  • 冗余是指在正常系统运行所需的基础上加上一定数量的资源，包括信息、时间、硬件和软件，在正常设备或元件出现问题或故障时，可以立即更换冗余的设备或元件，从而保证系统的正常运行。冗余是容错技术的基础，通过冗余资源的加入，可以使系统的可靠性得到较大的提高。
  • 恢复块设计（动态冗余）：动态冗余又称为主动冗余，是通过在软件中引入恢复块来实现容错。这些恢复块通常是代码块或子程序，用于检测和处理错误情况，以确保系统可以从错误中恢复并继续正常运行。
  • N版本程序设计：其设计思想是用N个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。是一种通过创建多个相互独立的软件版本来提高可靠性的方法。这些不同版本的软件在相同的输入下执行相同的任务，然后结果进行比对，如果其中一个版本的输出与其他版本不一致，则选择正确的输出。

除此之外，跟容错有关的技术还有：双机容错技术、集群技术，集群技术中又涉及到了负载均衡技术，对于这些技术是有必要做一些基本的了解的。

软件可靠性测试

软件可靠性测试是为了验证和提升软件系统的可靠性，确保其在预期的操作环境中能够稳定运行。该过程由以下主要活动组成：确定可靠性目标、开发运行剖面、设计测试用例、实施测试、以及分析测试结果。

软件可靠性评价

软件可靠性评价3个过程：选择可靠性模型、收集可靠性数据、可靠性评估和预测。

选择可靠性模型：需要选择适合您的软件项目的可靠性模型，这个模型将帮助您评估软件的可靠性。不同的项目可能需要不同的模型，以考虑其特定需求和特点。

示例：假设您正在开发一款医院管理系统，您希望评估该系统的可靠性。您可以选择使用"可靠性块图"模型，这是一种常用于评估系统可靠性的模型。然后，您根据系统的结构和功能，创建可靠性块图，标识关键组件和它们之间的依赖关系，以便量化系统的可靠性。

收集可靠性数据：一旦选择了适当的可靠性模型，接下来的步骤是收集相关的可靠性数据。这些数据可以包括组件的故障率、失效模式和效应分析（FMEA）等信息，以支持可靠性评估。

示例：对于医院管理系统，您可以开始收集以下数据：每个系统组件的故障率和平均失效时间（MTTF)、每个组件的失效模式，例如硬件故障、软件错误等。每个失效模式的严重性评估，以确定其对系统可靠性的影响。

可靠性评估和预测：使用所选的可靠性模型和收集的可靠性数据来评估软件的可靠性，并进行可靠性预测。这将帮助您了解软件在实际使用中的可靠性表现，以及是否需要采取进一步的改进措施。

示例：使用可靠性块图模型和收集的可靠性数据，您可以评估医院管理系统的整体可靠性。根据组件的故障率和失效模式，您可以预测系统在一定时间内的可用性和可靠性水平。如果评估结果显示某些组件存在潜在的可靠性问题，您可以采取措施来改进这些组件或提供备用方案，以提高系统的可靠性。

avatar
文章
阅读
粉丝