【note】《软件体系结构》知识整理（1-5章）

第 1 章 软件体系结构概论

1.1 从软件危机谈起

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题

1.1.1 软件危机的表现

  • 软件成本日益增长
  • 开发进度难以控制
  • 软件质量差
  • 软件维护困难

1.1.2 软件危机的成因

  • 用户需求不明确
  • 缺乏正确的理论指导
  • 软件规模越来越大
  • 软件复杂度越来越高

1.1.3 如何克服软件危机

采用工程的方法进行软件生产可以克服软件危机，于是诞生了软件工程

软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法

软件工程包括三个要素：方法、工具和过程

1.2 构件与软件重用

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。

软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。这些可重用的元素称做软构件，简称构件

由于构件大都经过严格的质量认证，并在实际运行环境中得到检验，因此，重用构件有助于改善软件质量

1.2.1 构件模型及实现

构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和实现代码的复合体。简单地说，构件是具有一定的功能，能够独立工作或能同其它构件装配起来协调工作的程序体。

构件模型是对构件本质特征的抽象描述

1.2.2 构件获取

在建立基于构件的软件开发（component-based software development, CBSD）中，构件获取可以有多种不同的途径：

  • 从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件
  • 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件
  • 从市场上购买现成的商业软件，即CTOS（commerical off-the-shell）构件
  • 开发新的符合要求的构件

一个组织在进行以上决策时，必须考虑到不同方式获得构件的一次性成本和以后的维护成本，然后做出最优的选择

1.2.3 构建管理

对大量的构件进行有效的管理，以方便构件的存储、检索和提取，是成功重用构件的必要保证。构件管理的内容包括构建描述、构建分类、构件库组织、人员及权限管理和用户意见反馈等

1.3 软件体系结构的兴起和发展

1.3.1 软件体系结构的定义

软件体系结构为软件系统提供了一个结构，行为和属性的高级抽象，由构成系统的元素的描述，这些元素的相互作用，知道元素集成的模式以及这些模式的约束组成

1.3.2 软件体系结构的意义

  • 体系结构是风险承担者进行交流的手段
  • 体系结构是早期设计决策的体现
  • 软件体系结构是可传递和可重用的模型

1.4 软件体系结构的应用现状

  • 软件体系结构描述语言
  • 体系结构描述构造与表示
  • 体系结构分析、设计与验证
  • 体系结构发现、演化和重用
  • 基于体系结构的软件开发方法
  • 特定领域的体系结构框架
  • 软件体系结构支持工具
  • 软件产品线体系结构
  • 建立评价软件体系结构的方法

第 2 章 软件体系结构建模

2.1 软件体系结构建模概述

可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型

2.2 “4+1”视图模型

“4+1”视图模型从5个不同的视角，包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容

2.2.1 逻辑视图

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。逻辑视图中使用的符号集合如下

2.2.2 开发视图

开发视图也称模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。下图是用来表示开发视图的符号

2.2.3 进程视图

进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。如下是进程视图使用的标记符号

2.2.4 物理视图

物理视图主要考虑如何把软件映射到硬件上，它通常要考虑系统性能、规模、可靠性等。下图是物理视图的标记元素集合

2.3 软件体系结构的核心模型

体系结构的核心模型由5种元素组成：构件、连接件、配置、端口和角色。其中构件、连接件和配置是最基本的元素

构件是具有某种功能的可重用的软件模块单元，表示系统中主要的计算元素和数据存储。构件有两种：复合构件和原子构件

连接件表示构件之间的交互，简单的连接件如：管道、过程调用、事件广播等，更为复杂的交互如：客户-服务器通信协议，数据库和应用之间的SQL链接等

配置表示构件和连接件的拓扑逻辑和约束

2.4 软件体系结构的生命周期模型

  • 需求分析阶段
  • 建立软件体系结构阶段
  • 设计阶段
  • 实现阶段

第 3 章 软件体系结构风格

3.1 软件体系结构风格概述

软件体系结构风格是描述某一特定应用领域中系统组织方式的管用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束

3.2 经典软件体系结构风格

3.2.1 管道和过滤

在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

管道/过滤器风格的软件体系结构具有许多很好的特点：

  • 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点
  • 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。
  • 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来
  • 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉
  • 允许对一些如吞吐量、死锁等属性的分析
  • 支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行

这样的系统也存在着若干不利因素：

  • 通常导致进程称为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换
  • 不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重
  • 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性

3.2.2 数据抽象和面向对象组织

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和他们的相应操作封装在一个抽象数据类型或对象中

面向对象的系统有许多的优点：

  • 面向对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象
  • 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合

但是，面向对象的系统也存在着某些问题

  • 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象
  • 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么C对B的使用所造成的对A的影响可能是料想不到的

3.2.3 基于事件的隐式调用

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中的过程的调用

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响

隐式调用系统的主要优点如下：

  • 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中，只需将它注册到系统的事件中
  • 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口

隐式调用系统的主要缺点如下：

  • 构件放弃了对系统计算的控制。一个构件出发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了那些构件的构成，它也不能保证这些过程被调用的顺序
  • 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题
  • 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题

3.2.4 分层系统

层次系统组成成一个层次结构，每一层为上层服务，并作为下层客户。

层次系统的许多可取属性如下：

  • 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解
  • 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层
  • 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法

但是，层次系统也有不足之处，如下：

  • 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来
  • 很难找到一个合适的、正确的层次抽象方法

3.2.5 仓库系统及知识库

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化

黑板系统主要由一下三部分组成：

  • 知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成
  • 黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题
  • 控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

3.2.6 C2风格

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

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

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

C2风格具有以下特点：

  • 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起
  • 所有构件之间的通信是通过以连接件为中介的异步消息交换机制来实现的
  • 构件相对独立，构件之间依赖性较少，系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设

3.3 客户/服务器风格

C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络

服务器的主要任务是：

  • 数据库安全性的要求
  • 数据库访问并发性的控制
  • 数据库前端的客户应用程序的全局数据完整性规则
  • 数据库的备份与恢复

客户应用程序的主要任务是：

  • 提供用户与数据库交互的界面
  • 向数据库服务器提交用户请求并接受来自数据库服务器的信息
  • 利用客户应用程序对存在客户端的数据执行应用逻辑要求

网络通信软件的主要作用是完成数据库服务器和客户应用程序之间的数据传输

C/S体系结构的优点主要在于系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小

C/S体系结构的缺点如下：

  • 开发成本较高。C/S体系结构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本，且客户端变得越来越臃肿
  • 客户端程序设计复杂。采用C/S体系结构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大
  • 信息内容和形式单一，因为传统应用一般为事务处理，界面基本遵循数据库的字段解释，开发之初就已确定，而且不能随时截取办公信息和档案等外部信息，用户获得的只是单纯的字符和数字，既枯燥又死板
  • 用户界面风格不一，使用繁杂，不利于推广使用
  • 软件移植困难。采用不同开发工具或平台开发的软件，一般互不兼容，不能或很难移植到其他平台上运行
  • 软件维护和升级困难。采用C/S体系结构的软件升级，开发人员必须到现场为客户机升级，每个客户机上的软件都需维护。对软件的一个小小改动，每个客户端都必须更新
  • 新技术不能轻易应用。因为一个软件平台及开发工具一旦选定，不可能轻易更改

3.4 三层C/S结构风格

3.4.1 三层C/S结构的概念

传统的二层C/S结构存在以下几个局限：

  • 二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet
  • 软、硬件的组合及集成能力有限
  • 客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏
  • 数据安全性不好。因为客户端程序可以直接方法数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁

三层C/S结构如图

三层C/S体系结构是讲应用功能分成表示层、功能层和数据层三个部分

  • 表示层

    表示层是应用的用户接口部分，担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据

  • 功能层

    功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。通常，在功能层中包含确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能

  • 数据层

    数据层就是数据库管理系统，负责管理对数据库数据的读写

3.4.3 三层C/S结构的优点

  • 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性
  • 允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
  • 三层C/S结构中，应用的各层可以并行开发，各层也可以选择格子最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些
  • 允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制

3.5 浏览器/服务器风格

浏览器/服务器风格就是三层C/S结构的一种实现方式，具体结构为浏览器/Web服务器/数据库服务器

B/S体系结构的不足之处：

  • B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能
  • B/S体系结构的系统扩展能力差，安全性难以控制
  • 采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构
  • B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理应用

3.6 公共对象请求代理体系结构

公共对象请求代理(common object request broker architecture, CORBA)是由对象管理组织OMG制定的一个工业标准，其主要目标是提供一种机制，使得对象可以透明地发出请求和获得应答，从而建立起一个异质的分布式应用环境

3.7 正交软件体系结构

3.7.1 正交软件体系结构的概念

正交软件体系结构由组织层和线索的构件构成。组织层是一组有相同抽象级别的构件构成。线索是子系统的特定，它是由完成不同层次功能的构件组成，每一条线索完成整个系统中相对独立的一部分功能。简单来讲，就是不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的

正交软件体系结构的主要特征如下：

  • 正交软件体系结构由不同功能的n(n > 1)个线索（子系统）组成
  • 系统具有m(m > 1)个不同抽象级别的层
  • 线索之间是相互独立的（正交的）
  • 系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）

3.7.3 正交软件体系结构的优点

正交软件体系结构的优点如下：

  • 结构清晰，易于理解。正交软件体系结构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能
  • 易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的构件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需响应的增删线索构件族，而不影响整个正交体系结构，因此能方便地实现结构调整
  • 可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用

3.8 基于层次消息总线的体系结构风格

层次消息总线（hierarchy message bus, HMB）的风格的各个组成要素：构件模型、构件接口

3.8.1 构件模型

HMB风格的构件模型包括接口、静态接口和动态行为三个部分，如图

3.8.2 构件接口

在体系结构设计层次上，构件通过接口定义了同外界的信息传递和承担的系统责任，构建接口代表了构件同环境的全部交互内容，也是唯一的交互途径

3.8.3 消息总线

HMB风格的消息总线是系统的连接件，构件向消息总线等级感兴趣的消息，形成构件消息响应登记表

3.8.4 构件静态结构

3.8.5 构件动态行为

3.8.6 运行时刻的系统演化

HMB风格方便地支持运行时刻的系统演化，主要体现在以下三个方面：

  • 动态增加或删除构件
  • 动态改变构件响应的消息类型
  • 消息过滤

3.9 异构结构风格

3.10 互联系统构成的系统及其体系结构

3.10.1 互联系统构成的系统

互联系统构成的系统(system of interconnected system, SIS)是指系统可以分成若干个不同的部分，每个部分作为单独的系统独立开发。整个系统通过一组互联系统实现，而互联系统之间相互通信，履行系统的职责

3.10.2 基于SASIS的软件过程

软件过程：系统分解，用例建模，分析和设计，实现，测试，演化和维护

  • 系统分解

    将上级系统分解成几个从属系统

  • 用例建模

    为每个系统在SIS系统中建立一个用例

  • 分析和设计

    分析和设计的目的是为了获得一个健壮的系统体系结构

  • 实现

    实现过程主要完成构件的开发和测试工作

  • 测试

    组装不同从属系统时的集成测试，并测试每个上机用例是否根据其规约通过互联系统协作获得执行

  • 演化和维护

    当某从属系统的需求发生变化时，不必开发新版本的上级系统，只需对该从属系统内部结构进行变更，不会影响其他从属系统

3.11 特定领域软件体系结构

3.11.3 DSSA的定义

特定领域软件体系结构(domain specific software architecture, DSSA)的必备特征：

  • 一个严格定义的问题域和/或解决域
  • 具有普遍性，使其可以用于领域中某个特定应用的开发
  • 对整个领域的合适程度的抽象
  • 具备该领域固定的、典型的在开发过程中可重用元素

从功能覆盖的范围角度有两种理解DSSA中领域的含义的方式：

  • 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
  • 水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用体系结构

3.11.2 DSSA的基本活动

  • 领域分析

    这个阶段的主要目标是获得领域模型。领域模型描述系统之间的共同的需求

  • 领域设计

    这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计

  • 领域实现

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

3.11.4 DSSA的建立过程

DSSA的建立过程分为五个阶段：

  • 定义领域范围：本阶段的重点是确定什么在感兴趣的领域中及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求
  • 定义领域特定的元素：本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块图将被增加更多的细节，特别是识别领域中应用间的共同性和差异性
  • 定义领域特定的设计和实现需求约束：本阶段的目标是描述解决空间中有差别的特定。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论
  • 定义领域模型和体系结构：本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义
  • 产生、搜集可重用的产品单元：本阶段的目标是为DSSA增加构件，使它可以被用来产生问题域中的新应用

DSSA的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA

第 4 章 软件体系结构描述

4.1 软件体系结构描述方法

  • 图形表达工具
  • 模块内连接语言
  • 基于软构件的系统描述语言
  • 软件体系结构描述语言

4.2 软件体系结构描述框架标准

4.3 体系结构描述语言

ADL是这样的一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架

4.3.1 ADL与其他语言的比较

4.4 典型的软件体系结构描述语言

4.4.1 UniCon

UniCon及其支持工具的主要目的有：

  • 提供对大量构件和连接件的统一的访问
  • 区分不同类型的构件和连接件以便对结构配置进行检查
  • 支持不同的表示方式和不同开发人员的分析工具
  • 支持对现有构件的使用

4.4.2 Wright

Wright支持对构件之间交互的形式化和分析。

Wright的主要特点为：对体系结构和抽象行为的精确描述、定义体系结构风格的能力和一组对体系结构描述进行一致性和完整性的插件

4.4.3 C2

4.4.4 Rapide

Rapide是一种可执行的ADL，其目的在于通过定义并模拟基于事件的行为对分布式并发系统建模

Rapide由五种子语言构成：

  • 类型语言：定义接口类型和函数类型，支持通过继承已有的接口来构造新的接口类型
  • 模式语言：定义具有因果、独立、时序等关系的事件所构成的事件模式
  • 可执行语言：包含描述构件行为的控制结构
  • 体系结构语言：通过定义同步和通信连接来描述构件之间的事件流
  • 约束语言：定义构件行为和体系结构所满足的形式化约束，其中约束为需要的或禁止的偏序集模式

Rapide的优点在于能够提供多种分析工具

4.4.5 SADL

4.4.6 Aesop

Aesop的目的是建立一个工具包，为领域特定的体系结构快速构件软件体系结构设计环境，每个这样的环境都支持一下五个方面：

  • 与风格词汇表相应的一系列设计元素类型，即特定风格的构件和连接件
  • 检查设计元素的成分，满足风格的配置约束
  • 优化设计元素的语义描述
  • 一个允许外部工具进行分析和操作体系结构描述的接口
  • 多个风格特定的体系结构的可视化，以及操作它们的图形编辑工具

4.4.7 ACME

ACME最初目的是为了创建一门简单的、具有一般性的ADL，该ADL能用来为体系结构设计工具转换形式，和/或为开发新的设计和分析工具提供基础

ACME支持从四个不同的方面对软件体系结构进行描述，分别是结构、属性、约束、类型和风格

  • 结构

    在ACME中定义了七种体系结构实体，分别是构件、连接件、系统、端口、角色、表述和表述映射

  • 属性
  • 设计约束

    设计约束是体系结构描述的关键成分，它们决定体系结构设计使如何演化的。设计约束可以当做一种特殊的属性，但因为在体系结构中，设计约束起着核心作用，所以，ACME提供了特定的语法来描述设计约束

  • 类型和风格

4.5 软件体系结构与UML

4.5.1 UML简介

统一建模语言(UML)是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制

4.5.2 UML的主要内容

  • 用例图：用来显示若干角色乙级这些角色与系统提供的用例之间的连接关系
  • 类图：用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述
  • 对象图：类图的实例，几乎使用与类图完全相同的标识
  • 顺序图：用来反映若干个对象之间的动态协作关系，也就是随着时间的推移，对象之间是如何交互的
  • 协作图：描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系
  • 状态图：描述类的对象所有可能的状态以及事件发生时状态的转移条件
  • 活动图：描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动
  • 构件图：描述代码构件的物理结构及各构件之间的依赖关系
  • 部署图：定义系统中的物理体系结构

第 5 章 动态软件体系结构

5.1 动态软件体系结构概述

体系结构的动态性主要分为三类：

  • 交互式动态性
  • 结构化动态性
  • 体系结构动态性

允许在系统运行时发生更新的软件体系结构称为动态软件体系结构，动态体系结构在系统被创建后可以被动态地更新

5.2 软件体系结构动态模型

5.2.1 基于构件的动态系统结构模型

  • 模型简介：基于构件的动态系统结构模型支持运行系统的动态更新，该模型分为三层，分别是应用层、中间层和体系结构层
  • 更新请求描述

    一般来说更新描述包括以下几个部分：

    • 更新类型：包括添加、删除和修改一个新的构件
    • 更新对象列表：需要更新对象类的ID号
    • 对象的新版本说明：对象的新版本执行情况
    • 对象更新方法：更替、动态和静态
    • 更新函数：用来更新一个执行对象进程的状态转换函数
    • 更新限制：描述更新和它们之间的关系的序列
  • 更新执行步骤
    • 检测更新的范围：在执行更新之前，首先要判断是局部更新还是全局更新，局部更新作用域需要新构件的内部而不影响系统的其他部分。全局更新影响系统的其他部分，全局更新需要发送请求到更高的抽象层
    • 更新准备工作：如果更新发生在应用层，构件配置器等待参与的进程发出信号，以表明他们已处于可安全执行更新的状态；如果更新发生在配置层，就需要等待连接件中断通信，其他构件配置器已完成它们的更新
    • 执行更新：执行更新，并告知更新发起者更新的结果
    • 存储更新：将构件或体系结构所作的更新存储到构件或体系结构描述中

5.3 动态体系结构的描述

5.3.1 动态体系结构描述语言

5.3.2 动态软件体系结构的形式化描述

5.4 动态体系结构特征

  • 可构造性动态特征
  • 适应性动态特征
  • 智能性动态特征

5.3 化学抽象机

  • 化学抽象机是一种对动态软件体系结构的分析、测试非常有用的形式化描述技术

❤ 点击这里 -> 订阅《PAT | 蓝桥 | LeetCode学习路径 & 刷题经验》by 柳婼

❤ 点击这里 -> 订阅《从放弃C语言到使用C++刷算法的简明教程》by 柳婼

❤ 点击这里 -> 订阅PAT甲级乙级、蓝桥杯、GPLT天梯赛、LeetCode题解离线版