高级系统架构师--第四章：软件架构设计

最好对着目录自己回想一下相关的知识点和概念

4.1 软件架构概念

架构概念

软件架构风格是惯用模式

在特定的应用领域中，软件架构风格是被反复使用、被广泛认可的一种通用结构或组织方式。就像在建筑领域中，不同风格（如欧式、中式等）有各自典型的结构和设计元素，在软件领域，比如在互联网应用开发中常见的MVC（模型 - 视图 - 控制器）架构风格，它规定了模型负责数据处理、视图负责展示、控制器负责交互逻辑，这种风格就是一种惯用模式，能帮助开发人员高效地构建软件系统 。

架构定义词汇表

架构会定义一套特定的术语集合。在软件架构的语境下，这些术语有着明确的含义。例如在微服务架构中，“服务”“网关”“负载均衡”等都是其词汇表中的术语，开发团队成员基于这套统一的词汇表进行沟通和协作，能够减少误解，提高开发效率。

架构定义一组约束

架构还包含了一系列的规则和限制。这些约束可能涉及到软件的性能、可扩展性、安全性等方面。比如在实时性要求高的应用架构中，会对数据传输延迟、响应时间等有严格的约束，以确保系统能满足特定的业务需求。 这些约束指导着软件系统的设计、开发和维护等各个环节。

架构所处位置

架构发展历程

架构的4+1视图

ADL

Architecture Description Language（体系结构描述语言）

什么是形式化语言？

形式化语言是一种具有精确语法和语义的语言，用于以严格、无歧义的方式表达概念、规则、系统结构或行为等。

语法层面

形式化语言有着明确且严格定义的符号集合和组合规则，就像自然语言中的语法规则规定了单词如何组成句子一样，形式化语言的语法规则规定了符号如何组合成合法的表达式、语句等。例如在数学中的谓词逻辑语言，它有特定的符号（如∀表示全称量词，∃表示存在量词等）以及严格的符号组合规则来形成公式，任何不符合这些规则的表达式都是不被允许的。

语义层面

每个形式化语言的表达式、语句等都有精确的含义定义，不存在模糊性或多义性。以布尔代数这种形式化语言为例，逻辑运算符“与”“或”“非”都有清晰明确的语义，“与”运算只有当两个操作数都为真时结果才为真，其他情况为假，这种语义定义是精确且无二义的。

应用场景

常用于数学、逻辑学、计算机科学等领域。在计算机科学中，形式化语言可用于描述算法、程序规范、软件架构（如ADL）等。比如ADL作为形式化语言，能精确描述软件系统的结构（包括构件、连接件及其关系）、行为（如构件间的交互方式）和属性（如性能、可靠性等特性），让架构师能够以一种严格、规范的方式表达系统架构，便于开发团队成员准确理解系统架构，也有利于进行后续的分析、验证等工作 。 总之，形式化语言为精确描述和分析复杂系统提供了有力的工具。

4.2 软件架构风格

架构风格总体介绍

数据流风格

批处理

管道过滤器

调用/返回风格

独立构件风格

虚拟机风格

虚拟机风格是一种软件架构风格，通过在软件和硬件之间提供抽象层来运行应用程序，让应用能在不同硬件和操作系统上无缝运作。
核心机制与关键组件：核心是虚拟机监控器（Hypervisor ），它负责管理虚拟机的创建、调度和销毁等，并提供虚拟硬件接口。利用虚拟化技术将物理硬件抽象，构建虚拟硬件环境供操作系统和应用感知。比如在常见的虚拟机软件中，虚拟机监控器可让多个虚拟机在单一物理主机上并行运作，每个虚拟机都有独立操作系统和应用程序，且认为自己独占硬件资源。

基于规则的架构风格

仓库风格

闭环控制架构（过程控制）

C2风格

C2风格是一种基于组件-连接件的软件架构风格，具有独特的分层和消息传递机制，以下是对它的详细介绍：

基本定义与原理

C2风格基于一种层次化的架构模型，其核心思想是将系统划分为多个层次，每个层次由一组组件构成，组件之间通过连接件进行通信和交互。组件之间的交互主要通过消息传递来实现，消息在层次之间进行上下传递，从而实现系统的各种功能。

架构特点

• 分层结构：C2风格的系统通常具有明显的层次结构，一般分为上下两层，上层组件可以向下层组件发送消息，下层组件也可以向上层组件反馈消息。这种分层结构使得系统的组织和管理更加清晰，不同层次可以承担不同的功能和职责。
• 松耦合：组件之间通过消息进行交互，并不直接依赖于其他组件的具体实现。这使得各个组件可以相对独立地进行开发、修改和替换，只要它们遵循相同的消息接口规范，就不会影响整个系统的运行，提高了系统的可维护性和可扩展性。
• 消息驱动：系统的运行主要由消息的传递和处理来驱动。组件接收到消息后，根据消息的内容和自身的功能进行相应的处理，并可能产生新的消息发送给其他组件。这种消息驱动的方式使得系统具有较好的灵活性和动态性，能够适应不同的业务需求和变化。
• 可动态配置：C2风格允许在系统运行时动态地添加、删除或替换组件，以及改变组件之间的连接关系。通过这种方式，可以根据实际情况对系统进行灵活的配置和调整，以满足不同的应用场景和用户需求。

适用场景

• 分布式系统：在分布式环境中，各个节点可能分布在不同的地理位置，C2风格的分层和消息传递机制可以很好地适应这种分布式的架构，实现节点之间的通信和协作。例如，在分布式的云计算平台中，不同的服务器节点可以采用C2风格进行架构设计，实现资源的管理和任务的分配。
• 大规模复杂系统：对于大规模的复杂系统，C2风格的分层和松耦合特点有助于将系统分解为多个相对简单的组件，便于开发和维护。例如，大型的企业级信息系统，涉及多个业务模块和功能领域，可以采用C2风格进行架构设计，使得各个模块之间的关系更加清晰，易于管理。
• 需要动态调整的系统：如果系统需要在运行时进行动态的调整和配置，C2风格的可动态配置特性可以很好地满足这一需求。例如，在一些实时监控和控制系统中，可能需要根据实时的环境变化和用户需求，动态地调整系统的功能和参数，C2风格可以方便地实现这一点。

示例

以一个简单的智能家居系统为例，它可以采用C2风格进行架构设计。系统的上层可以是用户界面组件，负责接收用户的操作指令，如打开灯光、调节温度等。下层可以是各种设备控制组件，负责与实际的智能家居设备进行通信，实现对设备的控制。上下层组件之间通过消息进行交互，用户界面组件将用户的操作指令封装成消息发送给设备控制组件，设备控制组件接收到消息后，执行相应的操作，并将操作结果以消息的形式反馈给用户界面组件。

4.3 基于架构的开发方法

开发过程1

开发过程2

开发过程3

4.4 特定领域软件架构

基本概念

DSSA 即 Domain Specific Software Architecture，中文为特定领域软件架构，

领域参考模型：高层次的抽象模型、描述该领域的关键概念及其关系，帮助
开发团队准确理解领域问题和需求。
比如：在医疗信息系统领域，参考模型可能会定义病人、医生、治疗、药
物、诊断等实体及其相互作用
参考需求：基于参考模型定义的，描述软件系统需要满足的功能性和非功能
性的条件。
比如：参考需求可能包括数据隐私包含、高可用性、用户界面易用性、数据
准确性等。
参考架构：基于参考模型和参考需求定义的软件架构蓝图，通常包括软件结
构组成、技术选型、设计模式。
比如: 采用微服务架构，使用加密技术，采用特定中间件和数据库技术等。

参与人员

建立过程

三层次模型

4.5 软件架构评估

为什么需要架构评估?

为什么要进行架构评估？

• 确保满足需求：提前验证架构能否满足功能、性能、可扩展性等需求，避免后期返工。比如高并发业务场景下，评估架构是否能承载流量。
• 降低风险：识别潜在风险，如技术选型不当、架构不合理等，及时调整。像采用新技术时，评估兼容性和稳定性风险。
• 提供决策依据：为后续开发、维护等决策提供参考，如资源分配、开发计划制定等。

架构评估到底评什么？

• 功能性：评估架构能否实现系统功能需求，功能模块是否完整、合理。例如电商系统的商品管理、订单处理等功能实现情况。
• 性能：考量响应时间、吞吐量、并发能力等性能指标。如在线支付系统的支付响应速度。
• 可扩展性：判断架构能否方便地添加新功能、模块或应对业务增长。像社交平台用户量增加时，架构对新功能和用户的支持能力。
• 可靠性：评估系统的容错能力、故障恢复能力等。如银行系统的容灾备份能力。
• 可维护性：看架构是否便于理解、修改和升级。例如代码结构是否清晰，模块耦合度高低。
• 安全性：检查架构在数据保护、权限控制等方面的措施。如金融系统对用户数据的加密和访问控制。

架构评估怎么评？

• 审查架构文档：查看架构设计文档，了解架构整体结构、模块划分、接口定义等。
• 场景分析：针对典型使用场景，模拟系统运行，评估架构表现。如模拟电商大促时的高并发场景。
• 专家评审：组织领域专家、架构师等对架构进行评审，提出意见和建议。
• 原型测试：搭建架构原型，进行实际测试，获取性能、功能等数据。
• 对比分析：与同类成功架构对比，分析优缺点。

软件质量属性

质量属性

性能

可用性

安全性

在系统性能指标的安全性范畴中，不可否认性指在网络环境里，信息交换的双方无法抵赖自己在交换过程中发送或接收信息的行为。

例如在电子合同签署场景中，甲方发送合同给乙方，基于不可否认性，甲方不能事后否认发送过合同这一行为；乙方收到合同后，也不能否认接收过合同。一般通过数字签名、可信时间戳等技术实现不可否认性。数字签名能确保信息来源可验证、内容未被篡改，发送方无法否认发送行为，接收方也难以抵赖接收事实；可信时间戳则为数据电文加上时间证明，确定信息在某一时间点的存在状态和内容，防止相关方事后否认。

可修改性

易用性和可测试性

敏感点权衡点风险点与非风险点

架构评估方法

几种评估方法

场景评估方法

基于场景的评估方法

SAAM

ATAM

质量效用树

评估架构质量的工具 将用户重视的东西 当作一个质量指标 直观的展现 一个系统中的各个指标

！！！！！！！
一般在案例分析中会吧里面 的 如 性能 可修改性给扣掉 后面具体的场景也给扣掉 作为一个案例分析的题目来做

4.6 软件产品线

基本概念

双生命周期

建立方式

组织结构

4.7 构件与中间件技术

软件复用

构件复用

中间件介绍

构件标准

其他知识

解释器架构

构件的组装方式包括：

1、顺序组装：按顺序调用己经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
2、层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。
3、叠加组装：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口。

复用的基本过程

主要包括3个阶段：
首先构造/获取可复用的软件资产，其次管理这些资产，最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。
复用的前提：获取可复用的软件资产首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。
管理可复用资产：该阶段最重要的是构件库（Component Library），由于对可复用构件进行存储和管理，它是支持软件复用的必要设施。构件库中必须有足量的可复用构件才有意义，构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。
在这个过程中，存在两个关键问题：一是构件分类，构件分类是指将数量众多的构件按照某种特定方式组织起来；二是构件检索，构件检索是指给定几个查询需求，能够快速准确地找到相关构件。使用可复用资产：在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产（修改、扩展、配置等），最后将它们组装与集成，形成最终系统。

ABSDM模型

ABSDM 是 Architecture - Based Software Development Method 的缩写。
ABSDM 模型将基于体系结构的软件过程分为体系结构需求、设计、文档化、复审、实现和演化6个过程：

• 体系结构需求：获取用户需求，标识系统构件。
• 体系结构设计：是迭代过程，若系统可从已有系统导出大部分，可沿用其设计过程。
• 体系结构文档化：输出体系结构规格说明和测试体系结构需求的质量设计说明书。
• 体系结构复审：与设计、文档化构成迭代过程，目的是发现设计缺陷和错误。
• 体系结构实现：用实体显示软件体系结构，按规定分割、交互构件，最后进行测试。
• 体系结构演化 因构件开发时用户需求可能变动，或软件开发完成并正常运行后移植到其他单位导致需求变化，这两种情况下都需修改软件体系结构以适应新需求，即使用系统演化步骤来修改应用以满足新需求。

DSSA

DSSA即特定领域软件体系结构（Domain Specific Software Architecture），是为特定应用领域的一组应用提供组织结构参考的标准软件体系结构。不同人对其定义不同，Hayes Roth认为它是专用于特定任务领域、能有效使用且限定标准组合结构的软件构件集合；Tracz认为它是特定问题领域中支持应用开发的基础。DSSA必备特征有：
有严格定义的问题域和问题解域；
具有普遍性可用于领域内特定应用开发；
对领域构件组织模型恰当抽象；
具备领域固定、典型且可重用元素。

软件架构复用的风格

• 机会复用：开发过程中发现可复用资产就复用。
• 系统复用：开发前进行规划以确定复用内容。

云计算的基础类型

• 软件即服务（SaaS）：基于互联网提供软件服务，供应商搭建企业所需设施并负责实施、维护，企业按需租赁使用。
• 平台即服务（PaaS）：将服务器平台或开发环境作为服务提供，是SaaS模式应用，可加快SaaS发展。
• 基础设施即服务（IaaS）：消费者通过互联网从完善的计算机基础设施获取服务，如《纽约时报》使用Amazon EC2处理数据。

构建的分类方法

• 关键字分类法：简单的构件库组织法，按领域分析结果将概念分解为树状或有向无回路图，用关键字表示概念，原子级关键字含相关构件。
• 刻面分类法：定义刻画构件特征的“面”，面含表述构件特征的概念，可描述功能、数据等特征。
• 超文本组织方法：基于全文检索技术，构件需有详尽说明文档，重要概念或构件网状链接，检索者可按思维跳转，系统通过关键字匹配实现浏览式检索。

ATAM

ATAM（Architecture Tradeoff Analysis Method，体系结构权衡分析方法）在SAAM基础上发展而来，用于系统开发前对性能、可用性、安全性和可修改性等质量属性进行评价和折中，具体内容如下：

• 活动领域：分为场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中四个阶段。
• 目标：在多质量属性相互影响情况下，提供理解软件体系结构能力的方法，确定质量属性间折中的必要性。
• 质量属性：分析可修改性、安全性、性能和可用性等相互竞争的质量属性。
• 风险承担者：场景和需求收集需所有系统相关人员参与。
• 体系结构描述：受历史遗留系统等约束，基于Kruchten的4 + 1视图派生的五个基本结构进行描述，用消息顺序图注解。
• 评估技术：可视为一种体系结构设计或检查的分析方法。

黑板架构风格

黑板架构风格是一种在复杂系统中处理信息的设计方法，通过共享的数据结构来促进各个部分之间的协作，特别适用于需要多个专家模块共同工作的问题领域。以下是其详细介绍：
组成部分 - 黑板：一个共享的数据存储区（全局数据库），包含解域的全部状态，存储原始数据、中间结果和最终结果等，所有知识源都能对其进行读取和写入操作，是知识源互相作用的唯一媒介。

• 知识源：处理特定任务的独立模块，包含若干独立计算的不同单元，提供解决问题的知识。它们会响应黑板上的变化，从黑板读取数据进行处理，然后将处理结果写回黑板。不同知识源可视为不同领域的“专家”。
• 控制组件：负责协调知识源的激活与执行，决定在什么情况下调用哪个知识源，监控黑板内容的变化，并据此触发相应知识源进行处理。 工作流程 系统启动时，黑板处于初始状态。知识源持续关注黑板内容，根据黑板状态的变化判断自身是否需要进行处理。若知识源被触发，便执行相应的处理逻辑，并将产生的结果写入黑板。控制组件实时监控黑板内容，依据黑板的状态激活合适的知识源，以推进问题的解决。
• 优点 - 高内聚、低耦合：知识源模块之间相互独立，便于管理和替换。- 可扩展性：能够轻松添加新的知识源，而不会对现有模块造成影响。
• • 动态适应性：可以根据当前黑板的数据状态，灵活选择合适的知识源，以适应不同的应用场景。
• 缺点
• • 性能问题：当知识源数量较多、处理逻辑复杂时，可能导致系统性能下降。
• • 调试困难：由于模块之间没有直接的调用关系，难以追踪数据流和处理逻辑。 应用场景 通常应用于对于解决问题没有确定性算法的系统中，例如：
• • 语音识别：处理不同语言、方言等复杂语音信息。
• • 车辆识别和跟踪：融合多种传感器数据，识别和跟踪车辆。
• • 蛋白质结构识别：通过分析大量数据确定蛋白质结构。
• • 声纳信号的解释：解析复杂的声纳信号数据 。

几种常用的adl建模语言

• UNICON：用于描述软件系统架构，虽认知度不高但符合ADL基本定义和用途。
• RAPIDE：基于事件驱动的ADL，使用事件描述软件体系结构，核心概念含事件、处理器和连接器等，可表达软件系统动态行为和组件交互。
• ACME：由卡内基梅隆大学开发，提供标准化方式描述软件系统架构，广泛应用于软件工程领域。
• AADL：由汽车工程师协会（SAE）标准化的ADL，主要用于嵌入式实时系统建模，通过描述构件和连接建立系统体系结构，有文本化、XML和图形化等多种描述方式。
• MDA：模型驱动架构，是应用系统开发的软件设计方法，强调通过模型驱动软件开发和部署，ADL是其模型重要组成部分，目标是提高软件可移植性、互通性和可重用性 。

软件系统质量属性分类

基于软件生命周期，软件系统质量属性分为开发期和运行期质量属性：

• 开发期质量属性：软件开发阶段关注的属性，包括易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。
• 运行期质量属性：软件运行阶段关注的属性，包括性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性。

敏感点和权衡点

该内容介绍了软件架构中的几个关键概念：

• 敏感点：是一个或多个构件（及构件间关系）的特性，有助于设计和分析人员明确实现质量目标时的注意事项。
• 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点，如改变加密级别对安全性和性能有重要影响，可能成为权衡点。
• 风险点与非风险点：非标准专业术语，风险点是可能引发风险的因素，某做法有隐患、可能导致问题即为风险点；可行、可接受的则为非风险点。

构件组装

• 概念：将构件库构件修改后相互连接，或与当前项目构件元素连接，构成新目标软件。
• • 技术分类：
• • 基于功能：依据软件系统功能需求组装构件。
• • 基于数据：先据核心数据结构设计框架，再依框架结点需求提取并修改构件。
• • 面向对象：利用封装、继承和多态特性，更适合支持软件复用。常规分类中无“基于实现的构件组装技术”，构件组装多从功能、数据或面向对象角度出发，而非具体实现细节。