的定义软件体系结构还在发展中，没有形成统一的公认的定义，这里只列举一些比较权威的定义。
或计算机系统的软件体系结构是系统的一种或多种结构，结构由软件元素、元素的外部可见属性及其关系组成。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象由构成系统的要素的记述、这些要素的相互作用、指导要素合并的模型的制约组成。
软件体系结构是系统的基础知识，具体体现在系统的组件、组件之间、组件与环境之间的关系以及指导其设计和演化的原则上。 (IEEE1471-2000 )
从技术角度看，软件架构的重要性
项目相关人员之间的交流平台
早期的设计决定。 从软件的生命周期来看，软件体系结构是所开发系统最早设计决策的体现。
表现为： (1)体系结构明确了系统实现的制约条件； )2)体系结构影响系统的质量属性)3)体系结构可以用来预测系统的质量(4)框架为维护决策提供依据)5)体系结构有助于原型开发。
实现高水平的软件复用
框架对发展指导和规范的意义不容忽视
基于体系结构的软件开发模型将整个软件过程明确划分为体系结构需求、设计、文档化、审核(评估)、实现、进化六个子过程。
的模型最常用结构模型和动态模型。
结构模型这是最直观、最常用的建模方法。 该方法通过结构的构成要素、连接件和其他概念刻画结构，试图通过结构反应系统的重要语义内容，包括系统的配置、约束、隐含假设条件、风格和性质。 http://www.Sina.com/研究结构模型的核心是架构描述语言框架模型类似于结构模型，但较少侧重于详细描述结构，http://www.Sina.com /框架框架模型动态模型是对结构和框架模型的补充，用于研究系统“大粒子”行为的性质。 例如，介绍系统的重新配置和进化。 动态可以指整个系统的配置、通信信道的建立或检测或计算的过程。更侧重于整体的结构流程模型研究建立系统的步骤和流程。 因此，结构是遵循了几个流程脚本的结果。动态模型该模型认为体系结构由一系列功能组件分层组成，底层为上层服务。 这可以看作是特殊的框架模型。过程模型模型从五个不同的视角描述软件体系结构：逻辑视图、处理视图、物理视图、开发视图和场景视图。 每个视图只关注系统的一个方面，只有五个视图结合起来才能反应系统软件架构的全部内容。 如下图所示。
视图名称功能关注点人员逻辑视图主要支持系统的功能需求描述系统功能用户开发视图(模块视图、实现视图)主要侧重软件模块的组织和管理，描述系统结构，编程人员的流程视图是系统的运行部分非功能需求描述系统性能、吞吐量系统集成人员物理视图主要考虑将软件映射到硬件来描述系统安装、拓扑、通信等的系统工程师场景视图)用例视图)，4个视图
软件质量属性
案例研究考察属性的子属性的作用和重要的应对措施的性能效率指标。 处理任务所需的时间或单位时间的处理量增加了计算资源，降低了计算开销，引入了并发机制，保证了系统在资源调度可靠性容错出现错误后仍能正常运行，并主动纠正错误实现了冗余遵循既定流程忽略错误可用性正常运行时间成比例的心率、Ping/Echo、主动冗余、被动冗余、选举安全系统为合法用户提供服务、组织非法用户的能力入侵检测、用户认证、用户授权、跟踪访问限制可修正性可维护性最小化局部修复故障对体系结构的负面影响软件模块泛化、模块间通信限制、使用中介和延迟绑定、运行时注册、接口隔离、信息隐藏可扩展性通过松散耦合实现新特性/功能不影响结构重组，不影响主体的灵活配置、可移植性，多种环境(硬件平台、语言、OS ) ) ) ) ) ) ) ) )的功能)
软测试-系统体系结构设计师(软件体系结构样式) ) )。
分层系统体系结构样式功能模型
“4+1”视图:C/S架构是基于资源不平衡等，为了实现共享而提出的
二层C/S架构:C/S结构将应用分成两部分，服务器(后台)负责数据管理，客户端)完成与客户的交互任务。
提出的原因:C/S软件体系结构具有较强的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
33558www.Sina.com/:(1)由于第2层C/S结构是单一的服务器，以LAN为中心，所以很难扩展到大企业的广域网或因特网
t；（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 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
典型的定义：（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；注册服务WSDLWeb 服务描述语言服务实现定义包含：服务、端口；服务接口定义包含：绑定、端口类型、消息、类型SOAP简单对象访问协议定义了服务请求和服务提供者之间的消息传输规范。SOAP包含：封装、编码规则、RPC表示、绑定。SOAP消息包含：封装（信封）、SOAP 头、SOAP体。REST表述性状态转移是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。SOA 的实现方法：
Web Service 服务注册表（1）服务注册
（2）服务位置
（3）服务绑定
内容：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商业动机的表述架构的表述对架构方法进行分类生成质量属性效用树分析架构方法集体讨论并确定场景的优先级分析架构方法结果的表述分析得到的信息：
已编写了文档的架构方法经过讨论得到的场景集合及其优先级效用树所发现的有风险决策已编成文档的无风险决策所发现的敏感点和权衡点