软件架构概述

从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌的错误，即不会奔溃。
架构设计就是需求分配，将满足需求的职责分配到组件上。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构建的描述、构建的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。
软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。
软件结构解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
软件架构设计包括提出架构模型，产生架构设计和进行架构设计评审等活动，是一个迭代的过程，架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面的描述特定系统的架构。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性和内部交互关系。
软件架构师项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构是可传递和可用复用的模型，通过研究软件架构可能预测软件的质量。

构件与对象

构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。
构件由一组通常需要同时部署的原子构件组成，一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单元。原子构件通常成组滴部署，但是他也能够被单独的部署。
构件和原子构件之间的区别在于，大多数原子构件永远不会被单独部署，尽管他们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个模块是不带单独资源的原子构件。
一个单独的包被编译成多个单独的类文件——每个公共类只有一个
模块是一组类和可能的非面对象的结构体，比如过程或者函数。
构件的特征：
（1）独立部署单元
（2）作为第三方的组装单元
（3）没有（外部）可见的状态
对象的特征：
（1）一个实例单元，具有唯一的标志。
（2）可能具有状态，此状态外部可见。
（3）封装了自己的状态和行为。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，他强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。
面向构件的编程（COP）
关注于如何支持建立面向构件的解决方案。面向构件的变成需要下列基础的支持。
（1）多态性（可替代性）
（2）模块封装性（高层次星星的隐藏）
（3）后期的绑定和装载（部署独立性）
（4）安全性（类型和模块安全性）

软件架构建模

结构模型：以架构的构件、连接件和其他概念来刻画结构，并试图以结构模型来反应整个系统的配置、内在逻辑等。
框架模型：不太侧重描述结构的细节而更侧重于整体的结构；主要是针对具体的问题为目标，未来适应这个问题的模型。
动态模型：系统的大颗粒的行为性质；对结构模型和框架模型的补充，描述系统的演化。
过程模型：构建系统的步骤和过程。
功能模型：由一组功能构件按层次组成，下层向上层提供服务。

4+1视图

image.png

逻辑视图：只要支持系统的功能需求，即系统提供给最终用户的服务。用类图来描述
开发视图：也称为模块视图，在uml中被称为实现视图，它主要侧重于软件模块的组织和管理。通过系统I/O关系的模型图和子系统图来描述。
进程视图：侧重于系统的运行特性，主要关注一些非功能性需求，例如系统的性能和可用性等，强调并发性、分部性、系统集成性和容错能力。定义了逻辑视图中的各个类的操作具体是在哪个一个线程中被执行的。
物理视图：在UML中被称为部署图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。
场景：可以看作是哪些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象，对于UML中的用例视图。

软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的管用模式。架构风格定义了一个系统家族，即一个架构定义了一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统，对软件结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到软件级的架构复用。
架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

基本架构风格

数据流风格:面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。
调用/返回风格:构件之间存在互相调用的关系，一般是显式的调用，代表的风格有 主程序!了程序、面向对象、层次结构。
独立构件风格:构件之间是互相独立的，不存在显式的调用关系，而是，过某个事件触发，异步的方式来执行，代表的风格有 进程通信、事件驱动系统(隐式记用)。
虚拟机风格:自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。
仓储风格：以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。
数据流风格
批处理序列：构件为一系列固定顺序的计算单元，构件之间只能通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为一个构件的输入，前后数据流关联，过滤器就是构件，连接件就是管道。
早期的编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。
二者区别在于批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行。
调用/返回风格
主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合称为模块，过程调用作为交互机制，充当连接件的角色。调用关系具有层次性，其寓意逻辑表现为主程序的正确性取决于他调用的子程序的正确性。
面向对象：构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和他们的响应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即使对象间交互的方式，对象是通过函数和过程的调用交互的。
层次架构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）。
层次结构优点:
1、支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增上步骤序列的实现。
2、不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高;超推近顶层，抽象级别越低。
3、由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
缺点:
1、并不是每个系统都可以很容易的划分为分层的模式。
2、很难找到一个合适的、正确的层次抽象方法。
独立构件风格
进程通信:构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。
事件驱动系统(隐式调用):构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是登名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便;
缺点是构件放弃了对系统计算的控制。
虚拟机风格
解解器:通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
*仓库（数据共享）风格
数据库系统：构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态;另一类是多个独立处理单元，处理单元对数据元素进行操作。
黑板系统：包括知识源、黑板和控制三部分，知识源包括若干独立计算的不同单元，提供解决问题的知识，知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应式通过黑板状态的变化来控制的，黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
超文本系统:构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法，它以节点为基础单元，链作为节点之间的联想式关联。通常应用在互联网领域。
现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格）架构风格进行开发，其中心数据就是程序的语法树。
闭环控制（过程控制）
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。
C2架构风格
C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下:
(1)系统中的构件和连接件都有一个顶部和 个底部;
(2)构件的顶部应连接到某连接件的底部， 的件的底部则应连接到某连接件的项部，而构件与 构件之间的直接连接是不允许的;
(3)一个连接件可以和任意数目的其它构件和连接件连接;
(4)当两个连接件进行直接连接时，必须由其中一个的底部到另一个的项部。
架构风格汇总（重点重点重点）

层次架构风格

两层C/S架构
客户端和服务端都有处理功能，相比较于传统的集中式软件架构，还是有不少有点的，但是现在已经不常用，原因有：开发成本高、客户端程序设计复杂，信息内容和形式单一，用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。
三层C/S架构
将处理功能独立出来，表示层和数据层都变得简单。表宗层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。即将两层 C/S架构中的数据从服务器中独立出来了。其优点下面四点:
各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可护展性;
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性。
各层可以并行开发，各层也可以选择各自最适合的开发语言；
功能层有效的隔离表示层和数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。
三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。
三层B/S架构
是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的 WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点，主要是数据处理能力差
B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能;
安全性难以控制;
在数据查询等响应速度上，要远远低于C/S架构;
数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。
混合架构风格
内外有别模型:企业内部使用C/S，外部人员访问使用B/S。
查改有别模型:采用B/S查询，采用C/S修改。混合架构实现困难，且成本高。
富互联网应用RIA
弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下:
RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性;
RIA简化并改进了B/S架构的用户交互;
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序。

面向服务的架构风格SOA

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含了一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理。
实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用(服务请求能被及时响应)、粗粒度接口(粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)、服务分级、松散耦合(服务提供者和服务使用者分离)、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、 XML是核心)、支持各种消息模式、精确定义的服务接口。
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
基于服务的构件与传统构件的区别有四点：
服务构件粗粒度，传统构件细粒度居多;
服务构件的接口时标准的，主要是WSDL接口，而传统构件常以具体API形式出现；
服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言;
服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。
关键技术
SOA中应用的关键技术如下表。

发现服务
UDDI：用于Web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他业务来调用。
DISCO：发现公共服务的功能及交互协议。
描述服务
WSDL (WEB服务描达语言）协议：用于描达web服务的接口和操作功能，描达网络服务。
消息格式层
SOAP为建立Web服务和服务请求之间的通信提供支持。
REST (Representational State Transfer， 表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技木，可以降低开发的复杂性，提高系统的可伸缩性。
编码格式层
扩展标记语言 (Extensible Markup Language, XML)，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据，定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。
SOA实现方式
WEB Service
服务提供者、服务注册中心（中介，提供交易平台，可有可无）、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。
服务注册表
服务注册：应用开发者(服务提供者)在注册表中公布服务的功能。
服务位置：服务使用者(服务应用开发者)，帮助他们查询注册服务，寻找符合自身要求的服务。
服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。
本质与WEB Service类似，只是使用一个注册表来代替服务注册中心。
企业服务总线ESB
客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。本质也是通过网络，有下列六点功能:
1、提供位置透明性的消息路由和寻址服务；
2、提供服务注册和命名的管理功能;
3、支持多种的消息传递范型;
4、支持多种可以广泛使用的传输协议;
5、支持多种数据格式及其相互转换;
6、提供日志和监控功能。

架构描述语言ADL

ADL是一种形式化语言，在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。
ADL的基本构成要素
构件和构件接口：计算单元或数据存储单元，是计算与状态存储的场所。
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
架构配置：描述架构的构件与连接件的连接图。
主要的架构描述语言
Aesop:支持体系结构风格的应用。
MetaH:为设计者提供了关于实时电子控制软件系统的设计指导。
C2:支持基于消息传递风格的用户界面系统的描述。
Rapide:支持体系结构设计的模拟并提供了分析模拟结果的工具。
SADL:提供了关于体系结构加细的形式化基础。
Unicon:支持异构的构件和连接类型并提供了关于体系结构的高层编译器。
Wright:支持体系结构构件之间交互的说明和分析。

特定领域软件架构DSSA

基于架构的软件开发ASBSD

软件架构评估

软件产品线

中间件技术

Web架构设计