体系结构风格有9大类：
1. 数据流系统，包括顺序批处理、管道和过滤器；
6. 特殊领域风格；例如过程控制、模拟器；
8. 不同风格合成建立的异构结构；
在传统的程序设计领域中，人们使用流程图来表达系统的基本功能和实现的具体逻辑，但是，流程图实际上仅仅是源程序的图形化表示，无法给系统的分析和开发者提供更多的信息，所以没有在实际的系统开发过程中得到广泛的应用。
随着软件系统的规模和复杂性的增加，对软件系统的整体结构（数据和控制的逻辑）进行分析和描述成为大型系统开发的一个不可缺少的重要部分，显然，使用流程图是无法达到这个目标的，我们必须使用新的方法和概念来对系统的整体结构进行把握。
系统分析实际上包括两个阶段的工作，首先是需求的分析，也就是说，划分出系统和环境之间的界面，将所研究（或者是将要开发）的系统和周围的环境分离，这就是从使用者的观点，将整个系统作为一个整体来考察。其次是系统的设计，根据系统的整体功能和数据，参考实际的物理系统或者类似的系统，设计实际运行的软件系统，这一步骤实际上就是体系结构的分析和确定。
从系统工程的观点看来，任何复杂的系统都是由相对简单的，在当前所分析的系统层次是原始的基本元素（虽然在更进一步的分析中，这些元素可能具有非常复杂的内部结构）组成的，这些基本元素之间存在复杂的相互作用。所以，软件系统的分析和设计的基本任务是：确立系统中的基本元素（完成系统的功能所必不可少的成分）；确定这些元素之间相互作用的方式（这就是系统的体系结构） [2]。
过滤器A
过滤器B
过滤器C
管道
特点：
- 过滤器之间是相互独立的（不能共享状态），其中一个过滤器的操作和行为不能影响另外过滤器的操作和行为，流的传送没有副作用。
- 过滤器对所输入流的来源和输出流的去向不关心，不需要知道流的来源和流的去向，来源和去向对于过滤器的数据处理没有任何影响。
- 过滤和流的传送可以是并发的，可以同时有多个流的传送存在于系统之中。
实例：
一个最著名的实例是unix的shell编程，多个对数据进行处理的程序（组件）通过管道联结起来，产生总和的效果；还有传统的编译器，源代码经过词法分析、语法分析、中间代码生成、目标代码生成等步骤生成输出的目标代码。
优点：
- 整个系统的功能是多个过滤器作用的总和，这样可以简化系统的分析和设计，可以经过需求的分析之后将整个系统作为一个过滤器处理，然后再逐步的细化成为多个相互连接的过滤器。
- 易于维护和增强，过滤器可以被替换，可以增加新的过滤器到系统中而不改变原有的过滤器，不改变原来系统的基本功能。
- 本质上的并发性支持，这种体系结构由于本质上是与各个独立的过滤器的状态无关的，与并行的流的通过次序也是无关的，所以并发是一个基本的体系结构自然具有的特性。
缺点：
- 由于过滤器之间本质上是独立的，所以设计者必须独立考虑每一个过滤器的输入、处理和输出的过程，对于过滤器逻辑上的共同点和相互关系无法在设计中加以体现。
- 由于这种体系的批处理特性，所以不适合开发和用户交互的应用程序。
- 系统的多个处理流之间的共同特性无法提取、多个过滤器之间的共同特性也无法提取，所以增加了设计的复杂性。
对象D
对象B
对象A
对象E
对象C
对象调用
对象调用
对象调用
类A
类B
类C
类G
对象A
对象E
类F
复合
继承
特点：
优点：
由于封装，实现了灵活性和扩充性，隐藏了实现的细节，提高代码的质量；
缺点：
最主要的缺点是，由于对象之间的交互是通过明确的对象函数调用进行的，所以当一个对象需要实现一个特定功能的时候，必须知道哪一个对象提供这种服务，这就降低了系统的灵活性。管道和过滤器模型不需要明确指明数据的来源和去向 [3]。
对象E
对象E
对象E
事件分发的总线
事件的创建
事件接收者的注册的创建
对象E
这是面向对象和数据抽象体系的一种变形，系统同样是由大量的对象组成的，但是对象之间的交互不是通过明确指明对象的函数或者过程调用进行的，相反，系统提供事件的创建和发布的机制，对象产生事件，一个或者多个对象通过向系统注册关注这个事件并由此触发出相应的行为或者产生新的事件。
实例：
一个最著名的例子是GUI的模型，鼠标、键盘或者其他输入设备产生各种事件，窗口、程序或者其他对象有这些事件所触发，产生新的事件、进行数据处理或者其他操作。
优点：
用于函数和过程的调用调用不需要指明特定的对象，所以系统具有非常好的灵活性和扩展性，新的组件只需要向系统的事件处理部分注册就可以立刻加入系统中，同样，老的组件也可以方便的从系统中删除。对于动态性要求特别高的系统，特别是如果需要在运行时对系统进行扩充，应该采用该结构。
缺点：
由于函数调用是通过事件发送进行的，所以，发出事件的对象不能确认是否有对象处理了这个事件、是否是期望的对象处理了这个事件、是否获得期望的结果，同样也无法控制事件发生的次序，系统的逻辑和时序的正确性必须通过复杂的时序逻辑和前后条件的断言加以保证。
用户界面层
事务逻辑层
核心层
实例：
优点：
- 系统的开发和设计可以逐步的分层次的进行，从底层的简单的功能逐步建立高层的复杂和抽象的功能。
- 灵活性和扩展性，由于相邻层次之间通过清晰的接口交互，所以特定的层次可以被替换和增强，甚至可以增加新的层次。
缺点：
- 不是所有的系统都可以分解成为清楚的层次
- 划分清晰、逻辑上一致的层次是非常困难的（OSI的失败和TCP/IP的成功说明了这一点）
- 严格的层次调用结构会降低系统的性能。
使用一个中心数据结构表示系统的当前状态，一组相互独立的组件在中心数据库上进行操作。如果组件负责对中心数据进行选择、处理，这种体系就是传统的数据库模型；如果中心数据结构自主的引发一系列的行为，则这种体系可以看成一个黑板模型。
中心数据库（知识库）
客户组件A
客户组件B
客户组件C
实例：
优点：
以数据为中心的体系结构，可以自然的表示大量的数据和事务处理的逻辑，适合表达以数据为重新的应用程序。
缺点：
只有很少一部分简单的数据库存储应用可以完全采用这种体系结构表示，在大量实际的商业应用中，完成师傅处理和其他逻辑的应用程序必须采用其他的体系结构表达
用户
如果应用程序的逻辑非常复杂，例如，AutoCAD的各种绘图指令，而且，用户可能以非常复杂的方式使用这个系统，一个较好的体系就是提供面向领域的一组指令（语言），系统解释这种语言，产生相应的行为，用户使用这种指令（语言）完成复杂的操作。
虚拟机解释器
完成实际操作任务的基本指令
实际的问题领域
实例：
大量的开发工具、二次开发工具体现了这一思想：微软在其产品中大量使用的Visual Basic for Application，以及在AutoDesk产品中大量使用的AutoLisp语言，实际上就是给用户提供了一种面向领域的语言，然后核心解释执行这一语言的指令和指令序列。从而扩充产品的功能，方便用户按照自己的需要定制系统。
优点：
非常好的扩展性，用户可以实现对软件系统的二次开发。
缺点：
软件开发复杂，特别是这种指令集的设计非常困难。
是否可以采用一种成熟的语言作为二次开发的基础（例如，基于Java）
在实际开发过程中，简单的判断某一个具体的应用应该采取何种体系结构是非常困难的，简单的管道、过滤器体系已经非常少见，面向对象的思想已经融合在几乎所有的体系结构之中，而层次化的思想同样也被广泛使用，所以，一个基本的系统分析方法应该是功能和复杂性的分解，也就是说，从横向分解（分模块、子系统），纵向分解中得到系统的基本组件（分类、分层次的功能和对象）。然后根据问题领域的特性选择系统的行为模式（具体的体系结构）。
（系统可以清楚的分解成为不同的功能层次，例如基本的图形库，提供不同层次的绘图接口） 这种体系结构适合于系统的功能相对简单，并且可以按照复杂的程度、抽象的程度、和硬件平台的关系等方面的特性加以分层的软件中。
对互操作性、特别是异构环境下的互操作性要求非常高的情况下，可以采用这种体系，当整个系统中存在大量的并发的，相互之间没有逻辑联系的组件的时候（例如操作系统或者图形用户界面）可以使用这种体系结构。现代软件技术中微软的COM和ISO的CORBA实际上都是这种体系结构的例子。
如果应用系统和用户的交互非常复杂，采用这种体系结构是最适合的方案，只有将系统的基本操作以指令的形式提供给用户，同时，提供一种简单明了的语法和基本的数据操作、处理的功能，才能得到功能最强大、最灵活、具有最佳扩充新的应用系统；一个非常合适的例子是浏览器，一开始，浏览器只是简单的下载和显示HTML的页面，随着用户对界面交互要求的发展，开发出javascript，提供一种语言和基本的界面元素操纵的指令来得到扩充性和强大的功能。
绝大多数实际运行的系统都是上面几种体系结构的复合：在系统的某些部分采用一种体系结构而在其他的部分采用另外的体系，我们可以将复合几种基本体系结构的系统称作复合体系结构。在实际的系统分析和设计中，可能首先将整个系统作为一个功能体进行分析和权衡，得到适宜的、最上层的体系结构，如果该体系结构中的元素较为复杂，可以继续进行分解，得到某一部分的，局部的体系。
分析的层次应该在可以清晰的使用简单的功能和界面描述表达结束，这样，可以将我们在分析和设计的这一阶段将焦点集中在系统的总体结构上，而避免引入和所使用的语言、实现所具体需要的技术等实现的细节上。
体系结构(architecture)规定了处理器的功能性行为，是处理器设计的规范。
微体系结构（microarchitecture）是体系结构的具体设计，即处理器实现。
某种体系结构在其生命周期内可以有多种逻辑实现。比如，Intel的IA-32架构，也称为“x86”架构，是一种设计规范。基于该规范下的产品包括包括Intel 8086、80186、80286、80386以及80486等。
