◆ 软件架构设计
软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件系统的组织结构和拓扑结构。
软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人（stakeholders）达成一致的目标；能够支持项目计划和项目管理等活动；能够有效地管理复杂性；等等。然而系统架构的给出必须建立在需求明确的基础上。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。
◆ 架构的模型 4 1视图
逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。（用户关注）
开发视图：也称为模块(实现)视图，主要侧重于软件模块的组织和管理。（程序员）
进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。（并发，集成人员）
物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。（软件到硬件，系统工程人员）
场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。（用例图）
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
◆ 软件架构风格
软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式；惯用模式则反映众多系统共有的结构和语义特性。强调对软件设计的重用。
架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工作的。
1. 数据流风格
批处理序列
强调数据作为一个整体（数据必须是完整的，以整体的方式传递）
管道和过滤器
每个构件都有一组输入和输出,构件读输入的数据流，经过内部处理，然后产生输出数据流. (构件–>过滤器;连接件–>管道) （数据流的形式）
2. 调用/返回风格
主程序/子程序
计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用。
面向对象风格
面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。
层次结构风格
分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度。允许每层用不同的方法实现，为软件重用提供了强大的支持。（二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用）
3. 独立构件风格
进程通讯
进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作。
事件系统子风格（隐式调用 ）
事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐式调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。
4. 虚拟机风格
解释器
具有运行时系统行为 (自)定义与改变能力 。如专家系统。
基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。（一般用在人工智能领域和DSS中）
5. 仓库风格
在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。
数据库系统
构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态,另一个是多个独立处理元素,处理元素对数据元素进行操作。中央数据库管理系统通过自身机制如数据排它锁，共享锁等，实现数据高速访问，数据一致性，数据完整性。同时各独立数据处理单元之间互相不受约束。(如编译器，传统编译器采用批处理架构，现代编译器采用数据共享架构风格。分析树是共享数据。)
超文本系统
主要应用于静态网页。
黑板风格
由一个作为全局共享数据的黑板，一个控制单元和多个知识源组成，主要应用与专家问题解决系统。通过专家知识和反馈逐步得到正确结果. (如语音识别)
6. 闭环控制架构
过程控制
工业中的过程控制是指以温度、压力、流量、液位和成分等工艺参数作为被控变量的自动控制。过程控制也称实时控制，是计算机及时的采集检测数据，按最佳值迅速地对控制对象进行自动控制和自动调节，如数控机床和生产流水线的控制等。（比如空调制冷，温度大于设定温度制冷，小于等于时停止，一旦大于继续运作）
C2
通过连接件绑定在一起按照一组规则运作的并行构件。
- 构建和连接件都有一个顶部和一个底部
- 构建的顶部都要连接连接件的底部，构建的底部都要连接连接件的顶部，构建 之间不允许直连。
- 一个连接进行直接连接时，必须有其中一个的底部到另一个的顶部。
◆ 分层C/S架构风格演化
1. 二层 C/S
- 二层 C/S 结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；(使用范围)
- 软、硬件的组合及集成能力有限；(扩展性)
- 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；(性能)
- 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。(安全)
2. 三层C/S架构
- 表现层（Web层） 负责接收客户端请求，向客户端响应结果，通常客户端使用http协议请求 web，web层需要接收 http请求，完成http响应。 表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。 表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。 表现层的设计一般都使用 MVC 模型。MVC 是表现层的设计模型，和其他层没有关系。
- 业务层 （Service层） 它负责业务逻辑处理，和我们开发项目的需求息息相关。web层依赖业务层，但是业务层不依赖Web层。 业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。(事务应该放到业务层来控制）
- 持久层 （dao 层） 负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进行持久化的载体，数据访问层是业务层和持久层交互的接口；业务层需要通过数据访问层将数据持久化到数据库中。 持久层就是和数据库交互，对数据库表进行增删改査的。
优点:
（1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。(逻辑独立清晰, 可维护性/可扩展性)
（2）允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。(可升级性/开放性)
（3）三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。(开发维护成本/速度/技术门槛)
（4）允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。(安全)
3. 三层B/S架构
用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。(客户端)
基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。(服务端)
B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。(开放性)
缺点:
- B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
- B/S架构的系统扩展能力差，安全性难以控制。
- 采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。(性能)
- B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用.
◆ MVC的架构风格
MVC 全名是 Model ViewController，是模型(model)－视图(view)－控制器(controller)的缩写，它是分层架构风格的一种。主要解决 将与 UI 相关的逻辑都定义在针对视图的相关元素的事件上 的问题。
MVC 中各个部分的分工与协作：
- Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知。
- View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
- View 捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。在完成 UI 处理后，Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。
◆ MVP 的架构风格
MVP 是从经典的模式 MVC 演变而来，它们的基本思想有相通的地方：Controller/Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。
当然 MVP 与 MVC 也有一些显著的区别，MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在 MVP 模式中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC 中的 Controller）来进行的，所有的交互都发生在 Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller，从而避免了 View 和 Model 之间的耦合。
◆ 扩展：
1. MVVM架构
2. 富互联网应用（RIA）
3. 分布式架构
客户机/服务器系统开发时可以采用不同的分布式计算架构：
- 分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；
- 分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；
- 分布式数据和应用架构数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机。
4. ANSI
在ANSI/IEEE 1471-2000标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。架构描述（Architecture Description）本质上是多视图的。每一个视图（View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角（Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。
5. 需求和架构
需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。
6. 架构风格和设计模式的区别
架构风格往往是从全局的角度来考虑问题，他是一种独立于实际问题的通用组织结构。例如，常用的B/S架构，在很多不同的系统中，都有应用。
而设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。例如，在很多的软件系统中，创建对象时，希望有统一的机制对这些对象的创建进行管理，所以出现了工厂模式，创建者模式等设计模式。比如java内存垃圾的回收机制也做成了一种设计模式。
7. 软件架构需求
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
8. 面向构件的编程（COP）
面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP 定义如下（Szyperski，1995）：“面向构件的编程需要下列基本的支持：
- 多态性（可替代性）；
- 模块封装性（高层次信息的隐藏）；
- 后期的绑定和装载（部署独立性）；
- 安全性（类型和模块安全性）。”
系统构件组装分为三个不同的层次：定制（ Customization）、集成（Integration）、扩展（Extension）。这三个层次对应于构件组装过程中的不同任务。
9. OMG接口定义语言IDL
IDL 是一种接口定义语言，具体的定义会涉及到接口以及相关部分。文件包含的主要元素有：接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。
由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包 (Package)或C 的namespaces。
10. 扩展知识
一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例，其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。早期的编译器采用管道-过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助。
来源：
https://blog.csdn.net/qq_43692950/article/details/117848595
