1 软件架构概述

1.1 基本概念

软件架构设计主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

软件架构设计是指通过一系列的设计活动，获得满足系统功能性需求，符合一定非功能性需求与质量属性有相似含义的软件系统框架模型。在软件体系结构设计过程中，主要考虑系统的非功能性需求。软件体系结构设计经验的总结与重用是软件工程的重要目标之一，所采用的手段主要包括体系结构风格、DSSA（特定领域的架构）等技术。

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

1.2 架构设计与生命周期

1.2.1 需求分析阶段

需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。
保持两者的可追踪性和转换，是软件工程领域追求的目标。从软件需求模型向软件架构模型转换主要关注：

  1. 如何根据需求模型构建软件架构模型
  2. 如何保证模型转换的可追踪性

1.2.2 设计阶段

是关注最早和最多的阶段，这一阶段主要研究：软件架构模型的描述、软件架构模型的设计与分析方法，以及对软件架构设计经验的总结与复用等。有关软件架构模型描述的研究分为三个层次：

  1. SA的基本概念：SA模型由哪些元素组成，元素之间按照何种原则组织。（构件和连接子）
  2. 体系结构描述语言（ADL）：支持构件、连接子及其配置的描述语言
  3. 软件架构模型的多视图表示：从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的软件架构模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。典型的包括 4+1 视图

1.2.3 实现阶段

主要研究以下几个方面：

  1. 研究基于软件架构的开发过程支持，如项目组织结构、配置管理等
  2. 寻求从软件架构向实现过渡的途径，如：将程序设计语言元素引入软件架构阶段、模型映射、构件组装、复用中间件平台等。
  3. 研究基于软件架构的测试技术

1.2.4 构件组装阶段

主要内容包括：

  1. 如何支持复用构件的互联
  2. 组装过程中，如何检测并消除体系结构适配问题，这些问题包括：
    1. 由构件引起的失配
    2. 由连接子引起的失配
    3. 由于系统成分对全局体系结构的假设存在冲突引起的失配

1.2.5 部署阶段

  1. 提供高层的体系结构视图描述部署阶段的软硬件模型
  2. 基于软件架构模型可以分析部署方案的质量属性，从而选择合理的部署方案

1.2.6 后开发阶段

这一阶段主要围绕维护、演化、复用等方面来进行，典型的研究方向包括：

  1. 动态软件体系结构：现实中的软件具有动态性，体系结构会在运行时发生改变；运行时改变包括：软件内部所导致的体系结构改变；软件系统外部的请求对软件进行的重配置。包括两部分的研究：体系结构设计阶段的支持、运行时刻基础设施的支持。
  2. 体系结构恢复与重建等。

2 基于架构的软件开发方法

2.1 概述

基于体系结构的软件设计方法（ABSD），是体系结构驱动，强调由业务、质量和功能需求的组合驱动架构设计，采用视角和视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。
ABSD 是自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生构件和类。
ABSD方法有三个基础：

  1. 基础功能的分解：在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术
  2. 通过选择体系结构风格来实现质量和商业需求
  3. 软件模板的使用，利用了一些软件系统的结构

2.2 基于体系结构的开发模型 ABSDM

ABSDM 模型把整个基于体系结构的软件过程划分为：体系结构需求、设计、文档化、复审、实现和演化。

  1. 架构需求：需求指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。重在掌握标识构件的三步：生成类图、对类进行分组、把类打包成构件
  2. 架构需求评审：组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对体系结构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的需求，类的分组是否合理，构件合并是否合理，必要时，可以在“需求获取–标识构件–需求评审”之间进行迭代。
  3. 体系结构文档化过程输出：体系结构规格说明 和 测试体系结构需求的质量设计说明书
  4. 体系结构复审是一个迭代过程：目的是标识出潜在的风险尽早发现体系结构设计中的缺陷和错误。在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。


3 软件架构风格

3.1 概述

软件体系结构风格是描述 某一特定应用领域 中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义 一个词汇表 和 一组约束。
词汇表：包含一些构件和连接件类型
约束：指出系统如何将这些构件和连接件组合起来的

体系结构风格 反映了 领域中众多系统所共有的结构 和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

3.2 经典架构风格

3.2.1 数据流风格

批处理风格：上一个的输出是下一个的输入，应用场景：日志分析、计费应用程序、数据仓库

管道过滤器风格：每个构件都有一组输入和输出，构件读输入，经过内部处理，然后产生输出数据流；应用场景：Web容器的Filter过滤机制、传统编译器

3.2.2 调用/返回风格

  • 主程序/子程序：采用单线程控制，把问题划分为若干处理步骤，主程序正确性取决于他调用的子程序的正确性；如开发语言
  • 面向对象：数据的表示和他们的相应操作被封装起来，一个对象的改变不会影响其他对象。
  • 层次：每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。修改某一层，最多影响其相邻的上下两层。

3.2.3 独立构件风格

  • 进程间通信：进程间消息传递的方式可以是点对点、异步或同步方式，以及远程过程调用等
  • 事件驱动：当某个事件被触发，系统自动调用在这个事件中注册的所有过程；如：断点调试、新闻、公众号等的订阅消息。

独立构件风格主要特点是：每个构件都是独立的个体，可代表一切体现封装的”对象“，例如：小到代码级的函数、类，大到一个服务端进程、集群、完整的系统。

3.2.4 虚拟机风格

解释器：包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区；缺点是执行效率低；如JVM
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存。一般用在人工智能领域和DSS中。

3.2.5 仓库风格（数据共享风格）

数据库系统：构件分为中央共享数据源、独立处理单元。构件控制中央共享数据。如 IDE集成开发环境。
黑板：包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板。黑板是一个全局数据库，包含问题域解空间的全部状态。如：语音识别、信号处理
超文本系统：静态网页。

3.2.6 闭环（过程）控制

是将过程输出的指定属性维护在一个特定的参考值（设定值），将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。如：空调的温度自动调节器、巡航系统（设定值是速度）

3.2.7 C2 风格

C2风格的系统组织规则：

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

3.2.8 C/S结构 与 B/S结构

二层C/S结构：客户端、服务器
三层C/S结构：表示层、功能层、数据层
B/S架构：浏览器/服务器

4 面向服务的架构（SOA）

4.1 概述

服务与对象的不同：

  1. 对象主要面向系统的，而服务是面向业务的
  2. 对象的粒度级别主要集中在类级别，而服务是粗粒度的
  3. 类是以函数调用为基础来交互的，而服务是以网络请求为基础来交互的

为了实现面向服务的架构，我们需要解决服务之间的交互、交互的方式、数据格式定义等，还要决定把那些业务”封装“成服务，达到封装性、可重用性、易维护性、易扩展性（服务注册表模式）；或者把那些业务”整合“成服务，达到对外统一、通用的目的（企业服务总线模式）

SOA紧密相关的技术主要有 UDDI、WSDL、SOAP 等，这些技术都是以XML为基础发展起来的。

4.2 实现方式

4.2.1 服务注册表模式

4.2.2 企业服务总线模式（ESB）

企业服务总线架构模式在于整合，可能是公司内部团队的服务，也可能是公司之间的不同服务。业务总线兼具”代理“的功能。业务方只需要知道业务总线的地址，无需耦合所有服务。

4.3 微服务

微服务的优势：

  1. 分解巨大单体应用为多个服务方法解决了复杂性问题
  2. 让每个服务能够独立开发，开发者能够自由选择可行的技术，提供API服务
  3. 每个微服务独立部署，开发者不再需要协调其他服务部署对本服务的影响。
  4. 微服务使得每个服务独立扩展

微服务架构带来的挑战：

  1. 并非所有的系统都能转成微服务
  2. 部署较以往架构更加复杂
  3. 性能问题
  4. 数据一致性问题

5 其他架构模式

5.1 MVC

5.2 MVP

5.3 MVVM

MVVM由MVP进化而来，MVVM模式基本上与MVP相同，MVVM中的数据可以实现双向绑定，当Model变化时，View-Model会自动更新，View也会自动变化。
MVVM框架比较适合逻辑复杂的前端项目，比如一些管理系统等。

6 特定领域软件体系结构DSSA

6.1 领域分类

垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构
水平域：在多个不同的特定领域之间的相同部分的小工具

6.2 基本活动

6.3 建立DSSA的过程

定义领域范围：领域中的应用要满足用户一系列的需求
定义领域特定的元素：建立领域字典，归纳领域中的术语，识别出领域中相同和不相同的元素
定义领域特定的设计和实现需求的约束：识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构：产生一般的架构，并描述其构件说明
产生、搜集可复用产品单元：为DSSA增加复用构件，使可用于新的系统。

以上过程是并发的、递归的、反复的、螺旋型的。

6.4 系统模型

7 质量属性与架构评估

7.1 质量属性

7.1.1 质量属性

  • 提升可用性的策略

  • 提升性能的策略

  • 提升可修改性的策略

  • 提升安全性的策略

7.1.2 质量场景

质量属性场景是一种面向特定的质量属性的需求。
质量场景的6个组成部分：

  1. 刺激源：谁造成的刺激
  2. 刺激：一个响应系统的情况
  3. 制品：系统被刺激的部分
  4. 环境：刺激发生时，系统所处的状态
  5. 响应：刺激所产生的结果
  6. 响应度量指标

7.2 质量特性

7.3 架构评估方法

基于调查问卷或检查表的方式：该方式的关键是设计好问卷或检查表。它充分利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观判断。

基于场景的方式：架构权衡分析法（ATAM）和 软件架构分析法（SAAM）、成本效益分析法（CBAM）。通过分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。

基于度量的方式：制定一些定量值来度量架构，如 代码行数等。

7.3.1 软件架构分析法（SAAM）

SAAM的主要输入是问题描述、需求说明和架构描述，其分析过程主要包括 场景开发、架构描述、单个场景评估、场景交互和总体评估。

7.3.2 架构权衡分析法（ATAM）

主要在系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要活动阶段：描述和介绍阶段、调查和分析阶段、测试阶段、报告阶段。

  1. 描述ATAM方法：评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。
  2. 描述业务动机：项目决策者从业务角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人，以及架构的驱动因素等。
  3. 描述架构：包括技术约束、将与本系统进行交互的其他系统、用以满足质量属性要求的架构方法等
  4. 确定架构方法：通过理解架构方法分析架构，在这一步，由架构设计师确定架构方法
  5. 生成质量属性效用树：评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。
  6. 分析架构方法：主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
  7. 讨论场景和对场景分级：项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成。
  8. 分析架构方法：在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第6步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。
  9. 描述评估结果：最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合

7.3.3 CBAM方法

CBAM用来对架构设计决策的成本和收益进行建模，它的基本思想是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益，CBAM协助项目干系人根据其投资收益率选择架构策略。CBAM可以看作是ATAM的补充，在ATAM评估结果的基础上对架构的经济性进行评估。