软件或计算机188系统的软件架构是该系统的8146一个（或多个）结构，而结构由软1931件元素、元素的外部属性及它们之间的关系组成。

　　软件系统架构是关于软件系统的 结构、行为和属性 的抽象。指定了软件系统的组织结构和拓扑结构。

　　软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。

　　软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人（stakeholders）达成一致的目标；能够支持项目计划和项目管理等活动；能够有效地管理复杂性；等等。然而系统架构的给出必须建立在需求明确的基础上。

　　软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。

　　 架构的模型 4+1视图

　　 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。（用户关注）

　　 开发视图：也称为模块(实现)视图，主要侧重于软件模块的组织和管理。（程序员）

　　 进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。（并发，集成人员）

　　 物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。（从软件到硬件，系统工程人员）

　　 场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。（用例图）

　　逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

　　 软件架构风格

　　软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式；惯用模式则反映众多系统共有的结构和语义特性。强调对软件设计的重用。

　　架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工作的。

　　 1. 数据流风格

　　 批处理序列

　　强调数据作为一个整体（数据必须是完整的，以整体的方式传递）

　　 管道和过滤器

　　每个构件都有一组输入和输出,构件读输入的数据流，经过内部处理，然后产生输出数据流. (构件–>过滤器;连接件–>管道) （数据流的形式）

　　 2. 调用/返回风格

　　 主程序/子程序

　　计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用。

　　 面向对象风格

　　面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。

　　 层次结构风格

　　分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度。允许每层用不同的方法实现，为软件重用提供了强大的支持。（二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用）

　　 3. 独立构件风格

　　 进程通讯

　　进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作。

　　 事件系统子风格（隐式调用 ）

　　事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐式调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。