一、软件架构设计
 
软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
 
软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件系统的组织结构和拓扑结构。
 
软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。
 
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人（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. 分布式架构
 
客户机/服务器系统开发时可以采用不同的分布式计算架构：
 
分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上（类似三层CS架构的两层应用）；
分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机（类似两层CS架构）；
分布式数据和应用架构数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机（类似三层CS架构）。
 
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。
 
9. 扩展知识
 
一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例，其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。早期的编译器采用管道-过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助。

软件架构（software architecture）
 
学习笔记，内容来自网络，橙色为自己总结，如有错误还请指正。
 
目录
 
软件架构（software architecture）
 
一、架构的定义
 
二、软件架构定义
 
三、架构的种类
 
逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口、商业逻辑元件等
 
物理架构：软件元件是怎样放到硬件上的
 
系统架构：系统的非功能性特征，如可扩展性、强壮性、灵活性、可靠性、性能等
 
四、架构的表现形式----4+1视图
 
逻辑视图(Logic View)
 
处理视图（Process view）
 
物理视图（PhysicalView）
 
开发视图（DevelopmentView）
 
场景视图（用例视图）
 
五、软件架构设计的目标
 
六、软件架构的作用
 
七、五种常见软件架构
 
1.分层架构
 
2.事件驱动架构
 
 3.微核架构
 
4.微服务架构
 
 5.云架构
 

一、架构的定义
 
参考资料：https://www.cnblogs.com/ivaneye/p/9752478.html
 
软件架构的定义大体分为“决策”论和“组成”论。
 
比较著名的“决策”论的定义是Booch,Rumbaugh和Jacobson于1999年提出的：架构就是一系列重要的决策，这些决策涉及软件系统的组织、组成系统的结构化元素及其接口的选择、元素之间协作时特定的行为、结构化元素和行为元素形成更大子系统的组合方式以及引导这一组织（也就是这些元素及其接口）、他们之间的协作以及组合（架构风格）。
 
“组成”论中最受推崇的是SEI(Software Engineering Institute)的Len Bass等人提出的定义：程序或计算系统的软件架构是系统的一个或多个结构，它包括软件元素、这些元素的外部可见属性以及它们之间的关系。
 
架构是规划、设计、构建的过程及最终成果。
 

参考资料里对架构下的定义为：架构是特定约束下决策的结果，并且这是一个循环递进的过程。
 
特定约束
任何行为、言语、结论都有一个context(上下文)为前提，某一个架构换一个场景可能并不适用。这个context就称为约束。但是必须是特定约束，不能是泛约束(约束必须具体，不能宽泛)。
 
决策
决策是一个过程，实际上就是选择。选择技术、结构、通信方式等内容，去符合特定约束。
 
结果
是决策的最终产物，可能是运行良好、满足需求的系统。也可能是一堆文档。如果这个结果是五视图(架构表现形式)、组件、接口、子系统、及其之间的关系，那么这个架构就是软件架构。
 
完善的需求（功能性、非功能性），实际就是架构的「特定约束」。而对上面这些问题的选择，就是「决策」。这些决策确定后，需要相关的设计图，这些图纸就是你决策的部分结果。最终交付给客户的才是你架构的最终成果。
 

架构和设计的关系：架构是顶层设计！
 
从操作层面做决策：用户从哪里进入、页面应该跳转到哪里、应该输入哪些信息.....这就是流程设计！
 
从代码层面决策，代码该怎么写：模块如何组织、包如何组织、类如何组织、方法如何组织......这就是代码设计！
 
从系统整体层面决策：子系统如何组织、组件如何组织、接口如何设计......这就是架构设计！
 

二、软件架构定义
 
参考资料：百度百科
 
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现
 
软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。
 
David GArlan和 Mary Shaw认为软件构架“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”
 
但构架不仅是结构
 
IEEEWorking Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
 
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
 
一般而言，软件系统的架构（ArchitECture）有两个要素：
 
1.它是一个软件系统从整体到部分的最高层次的划分。
 
2.一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
 
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
 
总结：软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计，包括架构元件(构成系统的各种组件)、联结器(组件之间通信的路径和机制)、任务流(系统如何使用元件和联结器完成需求)。不仅注重对系统内部(功能因素)的考虑，同时注重对系统外部(非功能因素)的考虑
 
三、架构的种类
 
根据关注的角度不同，可以将架构分成三种
 
 
逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口、商业逻辑元件等
 
 
从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件
 
 
物理架构：软件元件是怎样放到硬件上的
 
比如下面这张物理架构图，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等
 
 
 
系统架构：系统的非功能性特征，如可扩展性、强壮性、灵活性、可靠性、性能等
 
首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
 
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。
 
四、架构的表现形式----4+1视图
 
来源：https://blog.csdn.net/taoge512/article/details/81224430
 
https://blog.csdn.net/maritimesun/article/details/7099652?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase
 
以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
也就是说，架构要涵盖的内容和决策太多了，超过了人脑"一蹴而就"的能力范围，因此采用"分而治之"的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。
 
 
 
 
逻辑视图(Logic View)
 
 逻辑视图用来描述系统的功能需求，即在为用户提供服务方面系统所应该提供的功能。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition)。在面向对象技术中，表现为对象或对象类的形式，采用抽象、封装和继承的原理。用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。借助于类图和类模板的手段 ，类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等。相似的类可以划分成类集合。类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。
 
逻辑视图的表示法：
 　　构件(Components)：类、类服务、参数化类、类层次 
 　　连接件(Connectors)：关联、包含聚集、使用、继承、实例化 
 　　 
 
逻辑视图的风格采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免就每个场合或过程产生草率的类和机制的技术说明。
 
 
处理视图（Process view）
 
      又称“进程视图”，又称“处理视图”。
 
过程架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起，即定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。过程视图侧重系统的运行特性。服务于系统集成人员，方便后续性能测试
 
Ø 构件：进程、简化进程、循环进程
 
Ø 连接件：消息、远程过程调用（RPC）、双向消息、事件广播 。
 
过程视图：关注进程、线程、对象等运行时概念，以及相关的并发、同步和通信等问题。
 
进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作"processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
 
接着，我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。
 
 
物理视图（PhysicalView）
 
主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。
 
软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。
 
物理视图的表示法
 
Ø  构件：处理器、计算机、其它设备
 
Ø  连接件：通信协议等
 
物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；
 
 
开发视图（DevelopmentView）
 
描述了在开发环境中软件的静态组织结构，即关注软件开发环境下实际模块的组织，服务于软件编程人员。将软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
 
系统的开发架构用模块和子系统图来表达，显示了"输出"和"输入"关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分组和可见性。
 
开发视图的风格通常是层次结构，每个层为上一层提供良好定义的接口，层次越低，通用性越好。
 
开发视图的表示方法：
 
Ø  构件：模块、子系统、层
 
Ø  连接件：参照相关性、模块/过程调用
 
大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。
 
 
 
 
场景视图（用例视图）
 
它综合所有的视图。用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。
 
四种视图的元素通过一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。
 
场景视图是其他视图的冗余（因此"＋1"），但它起到了两个作用：
 
作为一项驱动因素来发现架构设计过程中的架构元素。
作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。
五、软件架构设计的目标
 
1.可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
 
2.安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
 
3.可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
 
4.可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
 
5.可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。
 
6.可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护系统可以有效地降低技术支持的花费。
 
7.客户体验（Customer Experience）。软件系统必须易于使用。
 
8.市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
 
六、软件架构的作用
 
1、开发新产品过程中软件架构所具备的作用分析
 
所谓的软件架构则是属于在现实的世界与计算机领域所搭建起来的一座沟通的桥梁
 
第一点就是进行业务目标的上乘。从本质上来看，软件架构往往存在着出于将业务目标完成而必须开展相应的大局规划的责任
 
第二点所指的就是进行技术决策的下接。凭借着把面向业务的相关需求往面向技术方向转向的软件架构设计方案，这可以将行之有效的限制与指导提供给后续的技术开发工作
 
第三点就是有效的将新产品的质量提升；第四点所指的就是进相应的新产品开发过程的组织；第五点所指的就是借助于相应的迭代实施相应新产品开展与增量的交付；第六点则是说控制所具备的复杂性，立足于相应的分而治之的思想，
 
2、 开发软件产品过程中系统架构所具备的作用分析
 
第一就是将所具备的相应的核心知识予以固话；第二就是可以提供相应的可重用资产；第三就是将产品推出的周期进行有效的缩短；第四就是使得产品开发与维护的总成本得以最大限度的降低；第五就是将产品的质量有效的提升；第六就是为批量控制提供有效的支持。
 
3、 软件产品线架构所具备的特点分析
 
第一个作用就是应该将一系列的明确许可的变化进行考虑；第二个作用所指的就是必须做到文档化；第三个作用就是说应该可以存在着相应的产品创建者指南，将实例化架构的整个过程进行描述。
 
4、维护软件过程中软件架构的作用分析
 
从本质上来看，相应的软件维护工作主要的来源是Bug与需求变更。往往修复一个Bug与增加一个新的功能，那么通常都会涉及到架构环节的一条模块协作链，针对这样的情况，软件架构比有利于维护工作的开展；反之，如果对于架构并不能了解，相应的进行程序的盲目修改，这也就会存在着可能性对架构设计的思路造成未必，从而导致整个系统所存在的架构逐步显得比较混乱，这也就会存在着可能性导致出现不可思议的Bug与问题。
 
5、软件升级过程中软件架构的作用分析
 
相应的软件架构则是通过对软件系统实施持续性的修改，还应该必须做好重构，往往对其实施重构主要是两种状况：第一种状况就是特别混乱的架构，从而导致实施一个比较小的改动就会出现牵动全身；第二种状况所指的就是即将实施的升级软件存在着比较大的力度，之前的软件架构与新的需求根本就不能适应。相应的软件架构予以重构则是属于再工程的一种情况，往往必须实施的步骤为逆向工程、重新规划、正向工程这样的三个步骤
 
七、五种常见软件架构
 
来源：https://www.cnblogs.com/doit8791/p/9343826.html
 
1.分层架构（layered architecture）
 
分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。
 
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。
 
虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见
 
 
 
 
表现层（presentation）：用户界面，负责视觉和用户互动
业务层（business）：实现业务逻辑
持久层（persistence）：提供数据，SQL 语句就放在这一层
数据库（database） ：保存数据
 
有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。
 
用户的请求将依次通过这四层的处理，不能跳过其中任何一层。
 
 
优点
 
 
 
结构简单，容易理解和开发
不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构
每一层都可以独立测试，其他层的接口通过模拟解决
 
缺点
 
 
 
一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
软件升级时，可能需要整个服务暂停
扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难 
 
2.事件驱动架构（event-driven architecture）
 
事件（event）是状态发生变化时，软件发出的通知。
 
事件驱动架构就是通过事件进行通信的软件架构。它分成四个部分。
 
 
 
 
 
 
事件队列（event queue）：接收事件的入口
分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
事件通道（event channel）：分发器与处理器之间的联系渠道
事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
 
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
 
 
优点
 
 
 
分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
适用性广，各种类型的项目都可以用
性能较好，因为事件的异步本质，软件不易产生堵塞
事件处理器可以独立地加载和卸载，容易部署
 
缺点
 
 
 
涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
分布式和异步特性导致这个架构较难测试
 
 3.微核架构（microkernel architecture）
 
微核架构又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
 
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
 
 
优点
 
 
 
良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，
可定制性高，适应不同的开发需要
可以渐进式地开发，逐步增加功能
 
缺点
 
 
 
扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制
 
4.微服务架构（microservices architecture）
 
微服务架构是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
 
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
 
 
微服务架构分成三种实现模式。
 
 
 
RESTful API 模式：服务通过 API 提供，云服务就属于这一类
RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群
 
优点
 
 
 
扩展性好，各个服务之间低耦合
容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
易于测试，可以单独测试每一个服务
 
缺点
 
 
 
由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。
一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。
分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。
 
 5.云架构（cloud architecture）
 
云结构主要解决扩展性和并发的问题，是最容易扩展的架构。
 
它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。
 
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
 
处理单元：实现业务逻辑
虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
 
 
 
虚拟中间件又包含四个组件。
 
 
 
消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
 
优点
 
 
 
高负载，高扩展性
动态部署
 
缺点
 
 
 
实现复杂，成本较高
主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
较难测试
 
 
 
 
 
 
 
 
 
 
 
 
 
 

一、软件架构评估
 
软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。
 
二、软件架构评估的方法
 
业界已开发出多种软件架构评估的方法，按基于的技术手段来看，可以分为三类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。以属性作为架构评估的核心概念。
 
基于调查问卷或检查表的方式：该方式的关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。
基于场景的方式：基于场景的方式由 SEI 首先提出并应用在架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。它是通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于度量的方式：它是建立在软件架构度量的基础上的，涉及三个基本活动，首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；然后从软件架构文档中获取度量信息；最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高
 的要求。ATAM 中也使用了度量的思想（度量效用）。
 
三、软件架构评估的质量属性
 
性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。（优先级队列、资源调度）
可用性是系统能够正常运行的时间比例。(通过用两次故障之间的时间长度或出现故障时系统能够恢复的速度来表示)（冗余、心跳线（ping/echo））
可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。（冗余、心跳线）
健壮性是指在处理或环境中，系统能够承受压力或变更的能力。
安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。（追踪审计）
可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。（包含四个方面：可维护性（maintainability）、可扩展性（extendibility），结构重组（reassemble）、可移植性（portability））
可变性是指体系结构经扩充或变更成为新体系结构的能力。
易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。（信息隐蔽）
功能性是系统所能完成所期望工作的能力。
互操作性是指系统与外界或系统与系统之间的相互作用能力。
 
四、关键步骤
 
敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。系统权衡点会影响一个或多个属性，并对于多个属性来说都是敏感点。
 
 
风险点: 架构设计中潜在的、存在问题的架构决策所带来的隐患。（业务逻辑不明确的地方）
 
 
非风险点：非隐患
 
 
敏感点: 为了实现某种特定的质量属性，一个或多个构件所具有的特征；（修改影响结果）
 
 
权衡点: 影响多个质量属性的特征，是多个质量属性的敏感点（如对两个质量属性特征产生相反的影响，一个好一个坏）（安全与性能）
 
 
通常采用效用树对质量属性的描述进行刻画与排序。在评估过程中，权衡点是一个会影响多个质量属性的架构设计决策。
 
五、软件架构评估-基于场景的评估 SAAM
 
最初用于分析架构可修改性，后扩展到其他质量属性。
 
场景：问题描述/需求说明/架构描述。
 
 分析过程：场景开发/架构描述/单个场景评估/场景交互/总体评估。
 
 先评估单个, 再评估多个相互作用。
 
六、架构权衡分析法ATAM
 
在SAAM的基础上发展起来的，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和这种。ATAM 方法不但能够揭示架构如何满足特定的质量需求（例如，性能和可修改性），而且还提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。该框架主要关注系统的需求说明。
 
场景包括：场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型折中。整个评估过程强调以属性作为架构评估的核心概念。
 
 评估过程：
 
 
七、产品线及系统演化
 
 
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。
 包含的技术: 软件架构/领域工程/DSSA
 
 
特定领域软件架构(DSSA)
 
 
过程模型
 
  
 
双生命周期模型：
 
 
 
SEI模型
 
 
 
三生命周期模型
 
 
 
 
组织结构
 
 
 
建立方式
 
 
八、架构复用
 
软件构件是软件系统中具有一定意义的、相对独立的可重用单元。与对象相比，构件可以基于对象实现，也可以不作为对象实现。构件需要在容器中管理并获取容器提供的服务；客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。
 
面向构件的编程需要下列基本的支持：多态性（可替代性）、模块封装性（高层次信息的隐藏）、后期的绑定和装载（部署独立性）、安全性（类型和模块安全性）。
 
构件组装成软件系统的过程可以分为3个层次: 定制/集成/拓展
 
1. 商用构件标准规范 CORBA
 
三个层次：
 
 
对象请求代理(ORB): 最底层, 规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的“软总线”.
 
 
公共对象服务: 提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务.
 
 
公共设施: 最上层, 定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则.
 
 
四种构件
 
实体（Entity） 构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
加工（Process） 构件同样需要容器管理其持久化，但没有客户端可访问的主键。
会话（Session） 构件不需要容器管理其持久化，其状态信息必须由构件自己管理。负责完成服务端和客户端的交互。
服务（Service） 构件是无状态的。
 
构件模型
 
 
伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
 
 
对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
 
 
对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
 
 
2. EJB/J2EE
 支持的5种构件模型：Applet、Servlet、JSP、EJB、Application Client。
 其中,EJB中的BEAN分三种:
 
session bean会话bean: 负责维护一个短暂的会话；
entity bean 实体bean:负责维护一行稳固持久的数据；
message-driven bean 消息驱动bean:异步接受消息。
 
无状态的bean没有成员变量，用单例模式 ；有状态的bean有成员变量，非线程安全，适合用prototype原型模式。
 
3. 微软的 COM/DCOM/COM+
 
4. 软件重用
 
软件重用分垂直式重用与水平式重用，垂直式重用是指局限于某一垂直领域的重用，如只在电力系统中用到的构件；而水平式重用是指通用领域的重用，如标准函数库，任何软件都能用，所以是水平式重用。

架构的定义
 
     软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较为权威的定义。
 
 
软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
 
 
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式的约束组成。
 
 
软件架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471-2000）
 

 从技术角度看，软件架构的重要性：
 
  
 
项目关系人之间交流的平台
 
 
早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。
 表现为： （1）架构明确了对系统实现的约束条件；（2）架构影响着系统的质量属性；（3）架构可以用来预测系统的质量；（4）架构为维护的决策提供依据；（5）架构有助于原型开发。
 
 
在较高层面上实现软件复用
 
 
架构对开发的指导与规范意义不容忽略
 
 
 
     基于架构的软件开发模型则明确地把整个软件过程划分为：架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。
 
架构的模型
 
最常用的是结构模型和动态模型。
 
结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反应系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。
框架模型。框架模型于结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的机构。
动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置和演化。动态可能指系统总体结构的配置、建立或查出通信通道或计算的过程。
过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看做是一种特殊的框架模型。
 
“4+1”视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图、场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反应系统的软件架构的全部内容。如下图所示：
 
 
视图名称
功能
关注点
关注人员
逻辑视图
主要支撑系统的功能需求
描述系统功能
用户
开发视图（模块视图、实现视图）
主要侧重于软件模块的组织和管理
描述系统配置、装配
编程人员
进程视图
侧重于系统的运行特性，一些非功能性的需求
描述系统性能、吞吐
系统集成人员
物理视图
主要考虑如何把软件映射到硬件上
描述系统安装、拓扑结构、通信等
系统工程师
场景视图（用例视图）
使四个视图有机得联系起来
描述人机互动的系统行为
分析人员和测试人员
 
软件质量属性
 

 案例分析常考 
属性
子属性
作用及要点
应对策略
性能
效率指标：处理任务所需时间或单位时间内的处理量
增加计算资源、减少计算开销、引入并发机制、资源调度
可靠性
容错
出现错误后仍能保证系统正常运行，且自行修正错误
主动冗余
健壮性
错误不对系统产生影响，按既定程序忽略错误
可用性
正常运行时间比例
心跳、Ping/Echo、主动冗余、被动冗余、选举
安全性
系统向合法用户提供服务并组织非法用户的能力
侵入检测、用户认证、用户授权、追踪审计、限制访问
可修改性
可维护性
局部修复故障对架构的负面影响最小化
软件模块泛化、限制模块之间通信、使用中介和延迟绑定、运行时注册、接口实现分离、信息隐蔽
可拓展性
因松散耦合更易实现新特性/功能，不影响架构
结构重组
不影响主体进行的灵活配置
可移植性
适用于多样的环境（硬件平台、语言、操作系统）
功能性
需求的满足程度
构建协作
可变性
总体架构可变
预先定义规则，作为相关产品基础
互操作性
通过可视化或接口方式提供更好的交互操作体验
交互作用
可测试性
软件发现故障并隔离，定位其故障的能力特性
记录回放
 
软件架构风格
 
这部分内容比较多，我又总结了另一篇文章
 软考-系统架构设计师（软件架构风格）
 
层次系统架构风格
 
二层C/S架构
 
提出的原因：C/S架构是基于资源不对等，且为实现共享而提出来的
 
结构：C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与客户的交互任务。
 
优点：C/S软件架构具有强大的数据操作和事物处理能力，模型思想简单，易与人们理解和接受。
 
局限： （1）二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；
             （2）软、硬件的组合及集成能力有限；
             （3）服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；
             （4）数据安全性不好。
 
三层C/S架构
 
结构：将应用功能分成表示层、功能层和数据层三个部分
 
表示层：是应用的用户接口部分，它负担着用户与应用间的对话功能。它用于检查用户 从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需修改显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
功能层：相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交互要尽可能简洁。
数据层：就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。
 
 
解决方案：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况下是只将表示层配置在客户机中，如果将功能层也放在客户机中，与二层 C/S 结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变差。如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。
 
B/S 架构风格
 
使用技术：B/S 结构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原本需要复杂的专用软件才能实现的强大功能，并节约了开发成本。
 
 
优点：基于 B/S 架构的软件，系统安装、修改和维护全在服务器端解决（零客户端），很容易在运行时自动升级。也可以更加充分利用网络上的各种资源，同时应用程序维护的工作量也大大减少。
 
不足：（1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
            （2）采用 B/S 架构的应用架构，在数据查询等响应速度上，要远远地低于 C/S 架构；
            （3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不抢，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP ）应用。
 
MVC架构风格
 
定义：全名是 Model ViewController，是模型（model）- 视图（view）- 控制器（controller）的缩写，分层架构的一种。
 
分工协作：
 
Model 是对应用状态和业务功能的封装。Model 接受 Controller 的请求并完成响应的业务处理，在状态改变的时候向 View 发出相应的通知。
View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。View 捕获到用户交互操作后直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。
 
 
MVP架构风格
 
定义：全称为 Model-View-Presenter。MVP 是从MVC 演变而来。
 
与MVC的相同点：基本思想有相通的地方：Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。
 
与MVC的不同点：MVC模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在MVP 中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC中的Controller）来进行的，所有的交互都发生在Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。
 
缺点：由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。还有一点需要明白，如果 Presenter 过多的渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。
 
优点：（1）模型与视图完全分离，我们可以修改视图而不影响模型；
            （2）可以更高效的使用模型，因为所有的交互都发生在一个地方——Presenter 内部。
            （3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
            （4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
 
面向服务的架构（SOA）
 
典型的定义：（1）W3C 的定义：SOA 是一种应用程度架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
                       （2）Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
                       （3）Gartner 的定义： SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 于大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。
 
**概述：**SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。由于 SOA 考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
 

 服务的基本结构：
 
 
SOA 设计原则：
 
明确定义的接口
自包含和模块化
粗粒度
松耦合
互操作性、兼容和策略声明
 
SCA 服务构件于传统构件的区别：服务构件往往是粗粒度的，而传统构件以细粒度居多；服务架构的接口是标准的，主要是服务描述语言接口，而传统构件常以具体 API 形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供 QoS 的服务，而传统构件完全由程序代码直接控制。
 
SOA 的关键技术：这些技术都是以 XML 为基础而发展起来的。
 
UDDI
统一描述、发现和集成
数据模型；API；注册服务
WSDL
Web 服务描述语言
服务实现定义包含：服务、端口；服务接口定义包含：绑定、端口类型、消息、类型
SOAP
简单对象访问协议
定义了服务请求和服务提供者之间的消息传输规范。SOAP包含：封装、编码规则、RPC表示、绑定。SOAP消息包含：封装（信封）、SOAP 头、SOAP体。
REST
表述性状态转移
是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。
 
SOA 的实现方法：
 
Web Service
 
 
服务注册表
 
（1）服务注册
 （2）服务位置
 （3）服务绑定
 
企业服务总线（ESB）
 
内容：ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者和服务提供者进一步解耦。EJB 是由中间件技术实现并支持 SOA 的一组基础架构 ，是传统中间件技术于 XML、Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。
 
功能：（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性；（2）通过使用 ESB ，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准；（3）充当缓冲的 ESB 与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码；（4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能；（5）头攻可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
 
优势：（1）扩展的、基于标准的连接；（2）灵活的、服务导向的应用组合；（3）提高复用率，降低成本；（4）减少市场反应时间，提高生产率。
 
微服务
 
优势：（1）技术异构性；（2）弹性；（3）扩展；（4）简化部署；（5）与组织结构相匹配；（6）可组合型；（7）对可替代性的优化
 
挑战：（1）分布式系统的复杂度；（2）运维成本；（3）部署自动化；（4）DevOps 与组织结构；（5）服务间依赖测试；（6）服务间依赖管理
 
微服务与 SOA ：
 
 
架构设计
 
 
软件架构文档化
 
内容： 一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成功，供项目关系人使用。
 
架构文档的使用者：架构的项目关系人。编写技术文档最基本的原则之一是要从读者的角度来编写。
 
编档规则：
 
从读者的角度编写文档
避免出现不必要的重复
避免歧义
使用标准结构
记录基本原理
使文档保持更新，但更新频率不要过高
针对目标的适应性对文档进行评审
 
视图编档：
 
 
软件架构评估
 
方法：
 
基于调查问卷或检查表的方式（依赖于评估人员的主观推断）
基于场景的方式：应用在架构权衡分析法（ATAM）和软件架构分析方法（SAAM）中。它是通过分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于度量的方式：建立在软件架构度量的基础上
 
架构权衡分析法（ATAM）
 
步骤：
 
ATAM 方法的表述：评估负责人向参加会议的项目代表介绍 ATAM
商业动机的表述
架构的表述
对架构方法进行分类
生成质量属性效用树
分析架构方法
集体讨论并确定场景的优先级
分析架构方法
结果的表述
 
分析得到的信息：
 
已编写了文档的架构方法
经过讨论得到的场景集合及其优先级
效用树
所发现的有风险决策
已编成文档的无风险决策
所发现的敏感点和权衡点