软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部属性及它们之间的关系组成。
软件系统架构是关于软件系统的结构、行为和属性的高级抽象。指定了软件系统的组织结构和拓扑结构。
软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。
架构的模型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层）
表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。
表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。
表现层的设计一般都使用MVC模型。MVC是表现层的设计模型，和其他层没有关系。
业务层（Service层）
业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。(事务应该放到业务层来控制）
持久层（dao层）
负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进行持久化的载体，数据访问层是业务层和持久层交互的接口；业务层需要通过数据访问层将数据持久化到数据库中。
持久层就是和数据库交互，对数据库表进行增删改査的。
优点:
（1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。(逻辑独立清晰,可维护性/可扩展性)
（2）允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。(可升级性/开放性)
（3）三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。(开发维护成本/速度/技术门槛)
3.三层B/S架构
用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。(客户端)
基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。(服务端)
B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。(开放性)
缺点:
B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
B/S架构的系统扩展能力差，安全性难以控制。
采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。(性能)
B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用.
MVC的架构风格
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
5.需求和架构
需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。
6.架构风格和设计模式的区别
架构风格往往是从全局的角度来考虑问题，它是一种独立于实际问题的通用组织结构。例如，常用的B/S架构，在很多不同的系统中，都有应用。
而设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。例如，在很多的软件系统中，创建对象时，希望有统一的机制对这些对象的创建进行管理，所以出现了工厂模式，创建者模式等设计模式。比如java内存垃圾的回收机制也做成了一种设计模式。
7.软件架构需求
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
8.面向构件的编程（COP）
多态性（可替代性）；
模块封装性（高层次信息的隐藏）；
后期的绑定和装载部署（独立性）；
安全性（类型和模块安全性）。”
系统构件组装分为三个不同的层次：定制（Customization）、集成（Integration）、扩展（Extension）。这三个层次对应于构件组装过程中的不同任务。
9.OMG接口定义语言IDL
由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java语言中的包(Package)或C++的namespaces。
10.扩展知识
一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例，其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。早期的编译器采用管道-过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助。