系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA
软件架构概念软件架构（） =软件体系结构指系统的一个或者多个结构，结构包括：（1）结构 - 软件的构件（可能是程序的模块、类、或者中间件）（2）属性 - 构件的外部可见属性（3）交互作用 - 构件之间的相互关系软件架构的本质软件架构为软件系统提供了一个结构、行为和属性的高级抽象。软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。软件架构的作用软件架构是项目干系人进行交流的手段。软
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
系统架构设计 · 基础（一）【系统架构设计师】
一、软件架构的概念★★★
1.1 软件架构的定义
软件架构概念
软件架构（Software Architecture） = 软件体系结构
指系统的一个或者多个结构，结构包括：
（1）结构 - 软件的构件（可能是程序的模块、类、或者中间件）
（2）属性 - 构件的外部可见属性
（3）交互作用 - 构件之间的相互关系
软件架构的本质
软件架构为软件系统提供了一个 结构、行为和属性的高级抽象。
软件架构风格是特定应用领域的 惯用模式，架构定义 一个词汇表和一组约束。
软件架构的作用
软件架构是 项目干系人进行交流的手段。
软件架构是 可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
软件架构使推理和控制的更改更加简单， 有助于循序渐进的原型设计，可以作为培训的基础。
需求分析 → 架构（弥补需求到设计的鸿沟）→ 软件设计
架构设计就是需求分配，既 将满足的需求的职责分配到组件上。
软件架构设计通过多种视图全面描述 - 4 + 1 视图。
1.2 软件架构设计4 + 1视图
视角与视图：
从不同的视角来检查，所以会有不同的视图。
Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。
逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统，且描述对象模型和对象之间的关系。
开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
进程视图：也称为过程视图。侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
1.3 软件架构设计与生命周期
软件架构是贯穿整个生命周期的，不同阶段的作用和意义不同，各阶段架构工作表现表：
| 阶段 | 作用和意义 |
|---|---|
| 需求分析阶段 | 有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。 软件需求模型向软件架构模型转换关注两个问题： 1）如何根据需求模型构建软件架构模型 2）如何保证模型转换的可追踪性 |
| 设计阶段 | 关注最早和最多的阶段。 这一阶段的研究主要包括： 1）软件架构模型的描述 2）软件架构模型的设计与分析方法 3）软件架构设计经验的总结与复用 架构模型的描述研究包括： ①组成SA（软件架构）模型 - 构件和连接的建模 ②架构描述语言（Architecture Describe Language，ADL） ③多视图 - 4 + 1视图 ADL三个基本元素： 1）构件：计算或数据存储单元，包括构件和相应的构件接口 2）连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则 3）架构配置：描述体系结构的构件和连接件的连接图 ADL是建模用的，是一些伪代码 |
| 实现阶段 | 有效实现从软件架构设计向实现的转换。 这一阶段架构研究包括： 1）基于架构开发过程的支持 2）寻求从架构向实现过渡的途径 3）研究基于架构的测试技术 |
| 构件组装阶段 | 可复用构件组装的设计能够提高系统实现的效率。 这一阶段的研究内容包括： 1）如何支持可复用构件的互联，即对架构设计模型中规约的连接子的实现提供支持 2）组装过程中，如何检测并消除架构失配问题 适配问题主要包括： ①构件本身适配 ②连接子（互联机制）的失配 ③部分和整体的失配 |
| 部署阶段 | 组织和展示部署阶段的软硬件架构、评估分析部署方案。 部署阶段的软件架构对软件部署的作用： 1）提供高层的体系结构视图描述部署阶段的软硬件模型 2）基于软件架构模型可以分析部署方案的质量属性从而选择合理的部署方案 |
| 后开发阶段 | 主要围绕维护、演化、复用进行。 部署安装后（后开发阶段）的系统架构研究方向包括： 1）动态软件体系结构 2）体系结构恢复与重建 |
1.4 软件架构的重要性
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
二、软件架构的风格★★★★★
- 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
- 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。
- 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
2.1 软件架构经典五大风格
| 五大架构风格 | 子风格 |
|---|---|
| 数据流风格 | 批处理、管道-过滤器 |
| 调用/返回风格 | 程序/子程序、面向对象、层次结构 |
| 以数据为中心风格 | 数据库系统、黑板系统、超文本系统 |
| 虚拟机风格 | 解释器、规则系统 |
| 独立构件风格 | 进程通信、事件驱动系统（隐式调用） |
2.1.1 数据流体系结构风格
| 优点 | 缺点 | 典型实例 |
|---|---|---|
| 1、松耦合【高内聚-低耦合】 2、良好的重用性/可维护性 3、可扩展性【标准接口适配】 4、良好的隐蔽性 5、支持并行 | 1、交互性较差 2、复杂性高 3、性能较差（每个过滤器都需要解析与合成数据） | 传统编译器 网络报文处理 |
2.1.1.1 批处理风格
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。数据必须是完整的，以整体的方式传递。
2.1.1.2 管道/过滤器风格
在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
2.1.2 调用/返回系结构风格
2.1.2.1 主程序/子程序风格
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。
2.1.2.2 面向对象风格
这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
2.1.2.3 层次结构风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见
2.1.3 以数据为中心系结构风格
2.1.3.1 仓库结构风格
数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
2.1.3.2 黑板结构风格
黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。语音识别、知识推理。
2.1.3.3 超文本系统风格
超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
2.1.4 虚拟机体系结构风格
2.1.4.1 解释器风格
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
2.1.4.2 规则系统风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
2.1.5 独立构件体系结构风格
2.1.5.1 进程间通信风格
构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
2.1.5.2 事件驱动系统风格（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
2.2 C2风格
C2风格通过连接件连接构件或某个构件组，构件与构件之间无连接。
软件体系结构设计的一个核心问题就是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。
C2 = EBI（基于事件的集成）+ LCS（分层客户端服务器）
C2是一种基于构件和消息的架构风格，可用于创建灵活的，可伸缩的软件系统。可以将架构看作是按照一定规则由连接件如消息路由设备连接的许多构件组成的层次网络系统中的构件和连接件都有一个“顶部”和“底部”;一个构件的“顶部”或“底部”可以连接到一个连接件的“底部”或“顶部”;对于一个连接件，和其相连的构件或连接件的数量没有限制，但是构件和构件之间不能直接相连。
C2架构的基本规则：
- 构件和连接件都有一个顶部和一个底部。
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
2.3 闭环风格
- 适用于嵌入式系统，用于解决简单闭环控制问题。
- 经典应用：空调温控，定速巡航。
三、基于架构的软件开发方法（ABSD）★★★★
3.1 体系机构设计的方法概述
基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。
ABSD强调由业务、质量和功能需求的组合驱动架构设计 ，强调采用 视角和视图 来 描述软件架构 ，采用 用例（功能需求）和质量场景（质量需求） 来 描述需求 。
ABSD方法有三个基础：
- 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 第二个基础是通过选择架构风格来实现质量和业务需求。
- 第三个基础是软件模板的使用。
3.2 基于架构的开发模型（ABSD）
传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。
四、特定领域的软件架构（DSSA）★★★
DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。
4.1 特定领域的软件架构 - 基本活动
（1）建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
（2）具有普遍性，使其可以用于领域中某个特定应用的开发。
（3）对整个领域的合适程序的抽象。
（4）具备该领域固定的、典型的在开发过程中的。可复用元素。
4.2 特定领域的软件架构 - 领域分析机制
4.3 特定领域的软件架构 - 建立过程
五、软件架构的复用★★★
-
软件架构复用的定义及分类
软件架构复用是系统化的软件开发过程：开发一组基本的软件构件模块，以覆盖不同的需求/体系结构之间的相似性，提高系统开发的效率、质量和性能。 -
软件架构复用的原因
减少开发工作、减少开发时间、降低开发成本、提高生产力、提高产品质量，更好的互操作性。 -
软件架构复用的对象及形式
可复用的资产包括：需求、架构设计、元素、建模分析、测试、项目规划、过程+方法+工具、人员、样本系统、缺陷消除。
一般形式的复用包括：函数的复用、库的复用、面向对象开发中的类、接口和包的复用。 -
软件架构复用的基本过程
（1） 首先构建/获取可复用的软件资产（复用前提）；
（2） 管理可复用资产；
（3） 使用可复用资产。
开源、云原生的融合云平台
更多推荐
20
0- 0
已为社区贡献11条内容
所有评论(0)