软件架构模式的种类

软件架构模式的种类

在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。

· 架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式 的好坏可以影响到总体布局和框架性结构。

· 设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。 模式的好坏不会影响到系统的总体布局和总体框架。 设计模式定义出子系统或组件的微观结构。

· 代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、 外部的结构或行为的底层细节， 但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。

1.1 架构模式(Architectural Pattern)

一个架构模式描述软件系统里的基本的结构组织或纲要。 架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。称之为系统模式。

· MVC（model-view-controller） 模式 一个架构模式常常可以分解成很多个设计模式的联合使用。 MVC 模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite） 模式、观察者（Observer）模式等。

· Layers（分层）模式 有时也称 Tiers 模式

· Blackboard（黑板）模式

· Broker（中介）模式

· Distributed Process（分散过程）模式

· Microkernel（微核）模式

架构模式常常划分成如下的几种：

 一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。 包括 Layers （分层）模式、 Blackboard （黑板）模式、 Pipes/Filters （管道/过滤器）模式等。

二、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包 括像 Broker（中介）模式等。

三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括 MVC（Model-View-Controller）模式、PAC （Presentation-Abstraction-Control）模式等。

四、 Adaptable Systems 型， 支持应用系统适应技术的变化、 软件功能需求的变化。 如 Reflection（反射）模式、Microkernel（微核）模式等。

1.2 设计模式(Design Pattern)

一个设计模式提供一种提炼子系统或软件系统中的组件的， 或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这 种结构解决在一定的背景中的具有一般性的设计问题。 设计模式常常划分成不同的种类，常见的种类有：

创建型设计模式，如（Factory Method） 模式、 抽象工厂 （Abstract Factory）、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等

结构型设计模式，如合成（Composite） 模式、（Decorator） 装饰模式、（Proxy） 代理模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等

行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子 （Iterator） 模式、 责任链 （Chain of Responsibility） 模式、 备忘录 （Memento） 模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。

 以上是三种经典类型， 实际上还有很多其他的类型， 比如 Fundamental 型、 Partition 型，Relation 型等等。设计模式在特定的编程语言中实现的时候，常常会用到代 码模式。比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。

1.3 代码模式(Coding Pattern)

代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。 较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等

参考自：http://www.cnblogs.com/duanxz/archive/2012/06/05/2536801.html

 

2   Architectural Patterns

架构模式是软件系统的结构组织概要。提供了一系列的预订义的子系统，指定他们的职责，包括规则和他们之间的组织关系。这张主要描述8个架构模式：Layers(分层), Pipes and Fllters（管道/过滤器）， Blackboard（黑板）， Broker（中介）， Model-View-Controller（MVC），

Presentation-Abstractlon-Control（PAC）， Microkernel（微核）以及 Reflection（反射）。

在设计新系统之前，我们从用户搜集数据并转换成具体的指标，这些通常比想象的复杂。

乐观点来说，我们假定对我们新系统的要求定义的比较好而且稳定。下一个任务就是定义系统架构，这意味着要为系统的每一个组成部分找到一个高级的子版本。我们要顾及到各个方面，将凌乱的问题组织为一个可工作的结构。

软　件　类　型	架　构　模　式	特　点　和　用　途
系统软件	分层（Layer）	从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中
	管道和过滤器（Pipes and Filters）	用数据流的观点来观察系统，整个系统由一些管道和过滤器组成，需要处理的数据通过管道传送给每一个过滤器，每个过滤器就是一个处理步骤。当数据通过了所有的过滤器后，就完成了所有的处理操作，得到最终的处理结果。ＵＮＩＸ操作系统的管道模型就建立在这样的架构之上；在ＵＮＩＸ下进行开发时，每个进程都是一个过滤器，我们可以通过管道把进程连接起来，让所有的过滤器在协作中完成整个任务。大多数程序设计语言的编译器也是基于这种架构模式实现的。
	黑板（Blackboard）	在这种架构中，在两种不同的构件;一种是表示当前的状态的中心数据结构；另一种是一组相互独立的构件，这些构件对中心数据进行操作。这种架构主要用于数据库和人工智能系统的开发。
分布式软件	经纪人(Broker)	在这种架构中，客户和服务器通过一个经纪人部件进行通信，经纪人负责协调客户和服务器之间的操作。并且为客户和服务器发送请求和结果信息。Broker就是经纪人模式的典型应用。
	客户/服务器(Client/Server)	系统分为客户和服务器，服务器一直处于侦听的状态，客户主主动连接服务器，每个服务器可以为多个客户服务。
	点对点（Peer to Peer）	系统中的结点都处于平等的地位，每个结点都可以连接其他结点。在这种架构中，一般需要由一个中心服务器完成发现和管理结点的操作。我们熟悉的ＩＣＱ程序以及WEB Service技术的大多数应用，都是典型的点对点结构。
交互软件	模型－视图－控制器(Model-View-Controller)	当应用程序的用户界面非常复杂，且关于用户界面的需求很容易变化时，我们可以把交互类型的软件抽象成抽模型，视图和控制器这三类组件单元，这种抽象可以很好地分离用户界面和业务逻辑，适应变化的需求。大多数现代交互软件都在一定程序上符合这一架构模型的特点。
	显示－抽象－控制器(Presentation-Abstraction-Control)	这是显示－抽象－控制器模式的另一种变形，这里就不再详细介绍了

 

参考自：http://www.cnblogs.com/shinings/archive/2009/07/31/1536180.html

 

　Layers架构模式
      Layer架构模式主要适合于架构能够被分解为子任务组的应用，每个任务组是一个特定的任务抽象层。从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中，网络协议是Layer模式最广为所指的应用。

 

 

Layer模式主要的特点是Layer J只能被Layer J+1使用，layer之间没有太多直接的联系。这种结构可以和一个stack，甚至是洋葱相比较。每一个单独的layer保护其下所有低层次的layers不能被更高层次的layer直接接触。

 

查询单独层次的更多详细信息时可能会显示他们是复杂的入口（包含不同的组件）。下图中，每个层都包含了三个组件。中间层中，两个组件相交互。在不同层的组件可以直接调用彼此---其它设计通过一个统一的接口保护每个层。这样的设计下，Component_2.1不在直接调用Component_1.1,而是通过调用Layer1的接口对象来调用。

 

 

以下场景是层次应用的动态行为原型。但这并不意味着你在每个架构里会遇到所有的场景。在简单的层次架构中，你只能看到第一种场景，但是大部分应用都会涉及场景1 和场景2.

场景1 ：

场景1 众所周知。客户端向Layer N提出一个请求，因为Layer N不能处理自己的请求，他将会调用Layer N-1, Layer N-1调用Layer N-2，... ...直到到达Layer 1，执行最底层的服务。如果必要的话，对于不同的请求的恢复会从Layer1传到Layer2，Layer2传到Layer3,...直到LayerN。这种自上而下的通信的一个特点就是， Layer J总是传递Layer J+1的一些请求到Layer J-1. 

 

场景2：

场景2是自下而上的通信，一系列从Layer1开始的动作。例如，每当设备检测到输入，设备将输入转换为内部消息格式报告给Layer 2，然后层层解释，直到数据到达最高层。对于自上而下的消息控制流经常描述为“请求”，而之下而上的消息控制流则可称为“notifications”(通知，告知)。

就像场景1所说的，top-down“请求”经常驱动请求到底层。相反的，bottom-up通知可能会将一个“通知”到更高层，或者仍旧是1:1的关系。

 

场景3：

场景三描述了一个这样的情况，“请求”只会在层的子集中传递。一个高层请求可能只能传递到下个低层N-1（如果此层能满足请求）。一个例子就是N-1层作为一个canche，从N层发出的请求不用传递到1层或者到远程服务器就能够满足。注意这种cache层保留状态信息，但是只能向前传递请求的层通常状态很少。状态少的层优点就是程序简单，尤其与重新进入相关的层。

场景4：

与场景3相似，

场景5：

 

 

　在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。

　　横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。

　　纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:

　　一、网页，也就是用户界面，负责显示数据、接受用户输入；

　　二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；

　　三、数据库，负责存储数据，按照查询要求提供所存储的数据。

　　四、操作系统层，比如Windows NT或者Solaris等

　　五、硬件层，比如SUN E450服务器等

　　有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。 

　　Layers架构模式的好处是：

　　第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。

　　第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术