软件体系结构层模式

软件体系结构的发展历史

与最初的大型中央主机相适应，最初的软件结构体系也是Mainframe结构，该结构下客户、数据和程序被集中在主机上，通常只有少量的GUI界面，对远程数据库的访问比较困难。

随着PC的广泛应用，该结构逐渐在应用中被淘汰。

在80年代中期出现了Client/Server分布式计算结构，应用程序的处理在客户（PC机）和服务器（Mainframe或Server）之间分担；请求通常被关系型数据库处理，PC机在接受到被处理的数据后实现显示和业务逻辑；系统支持模块化开发，通常有GUI界面。

Client/Server结构因为其灵活性得到了极其广泛的应用。

但对于大型软件系统而言，这种结构在系统的部署和扩展性方面还是存在着不足。

Internet的发展给传统应用软件的开发带来了深刻的影响。

基于Internet和Web的软件和应用系统无疑需要更为开放和灵活的体系结构。

随着越来越多的商业系统被搬上Internet，一种新的、更具生命力的体系结构被广泛采用，这就是为我们所知的“三层/多层计算”。

。

客户层（client tier）用户接口和用户请求的发出地，典型应用是网络浏览器和胖客户（如Java程序）。

服务器层（server tier）典型应用是Web服务器和运行业务代码的应用程序服务器。

数据层（data tier）典型应用是关系型数据库和其他后端（back-end）数据资源，如 Oracle和SAP、 R/3等三层体系结构中，客户（请求信息）、程序（处理请求）和数据（被操作）被物理地隔离。

三层结构是个更灵活的体系结构，它把显示逻辑从业务逻辑中分离出来，这就意味着业务代码是独立的，可以不关心怎样显示和在哪里显示。

业务逻辑层现在处于中间层，不需要关心由哪种类型的客户来显示数据，也可以与后端系统保持相对独立性，有利于系统扩展。

三层结构具有更好的移植性，可以跨不同类型的平台工作，允许用户请求在多个服务器间进行负载平衡。

三层结构中安全性也更易于实现，因为应用程序已经同客户隔离。

应用程序服务器是三层/多层体系结构的组成部分，应用程序服务器位于中间层。

如图所示，应用程序服务器运行于浏览器和数据资源之间，一个简单的实例是，顾客从浏览器中输入一个定单，web服务器将该请求发送给应用程序服务器，由应用程序服务器执行处理逻辑，并且获取或更新后端用户数据。

兴起六十年代的软件危机使得人们开始重视软件工程的研究。

起初，人们把软件设计的重点放在数据结构和算法的选择上，随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。

软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。

对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多。

在此种背景下，人们认识到软件体系结构的重要性，并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。

自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，就具有了体系结构。

好的开发者常常会使用一些体系结构模式作为软件系统结构设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。

软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件系统的需要。

事实上，软件总是有体系结构的，不存在没有体系结构的软件。

体系结构（Architecture）一词在英文里就是建筑的意思。

把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。

从细节上来看每一个程序也是有结构的。

早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。

结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。

由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究软件体系结构。

我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。

构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。

软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。

软件体系结构研...

软件体系结构常用的设计模式包括哪些

MVC是当前流行的Web应用设计框架的实施标准，是软件工程中的一种软件架构模式[ ]。

它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller），目的是实现一种动态和可持续的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的代码或功能重复利用成为可能。

在这种设计结构下，一个应用被分为三个部分：model、view和controller，每个部分负责不同的功能。

根据用户界面（view）的操作完成对程序数据（model）的更新。

将程序数据（model）改变及时反应到用户界面（view）上。

也就是完成两个方向的动作。

软件体系结构的体系风格

展开全部对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

体系结构风格的不变部分使不同的系统可以共享同一个实现代码。

只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。

例如，如果某人把系统描述为客户/服务器模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

下面是Garlan和Shaw对通用体系结构风格的分类：（1）数据流风格：批处理序列；管道/过滤器（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构（3）独立构件风格：进程通讯；事件系统（4）虚拟机风格：解释器；基于规则的系统（5）仓库风格：数据库系统；超文本系统；黑板系统限于篇幅，在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点。

有关新出现的软件体系结构风格，将在后续文章中进行介绍。

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：（1）系统中的构件和连接件都有一个顶部和一个底部；（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；（3）一个连接件可以和任意数目的其它构件和连接件连接；（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

图3是C2风格的示意图。

图中构件与连接件之间的连接体现了C2风格中构建系统的规则。

图3 C2风格的体系结构C2风格是最常用的一种软件体系结构风格。

从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；（2）所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；（3）构件相对独立，构件之间依赖性较少。

系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。

因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。

一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

图4是管道/过滤器风格的示意图。

一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。

Unix既提供一种符号，以连接各组成部分（Unix的进程），又提供某种进程运行时机制以实现管道。

另一个著名的例子是传统的编译器。

传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。

图4 管道/过滤器风格的体系结构管道/过滤器风格的软件体系结构具有许多很好的特点：（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；（3）支持软件重用。

重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；（4）系统维护和增强系统性能简单。

新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；（5）允许对一些如吞吐量、死锁等属性的分析；（6）支持并行执行。

每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

但是，这样的系统也存在着若干不利因素。

（1）通常导致进程成为批处理的结构。

这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

（2）不适合处理交互的应用。

当需要增量地显示改变时，这个问题尤为严重。

（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。

这种风格的构件是对象，或者说是抽象数据类型的实例。

对象是一种被称作管理者的构件，因为它负责保持资源的完整性。

对象是通过函数和过程的调用来交互的。

图5是数据抽象和面向对象风格的示意图。

图5 数据抽象和面向对象风格的体系结构面向对象的系统有许多的优点，并早已为人所知：（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。

（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

但是，面向对象的系统也存在着某些问题：（1）为了...

什么是B/S三层开发结构？

随着软件系统的规模和复杂性的增加，软件体系结构的选择成为比数据结构和算法的选择更为重要的因素，三层客户/服务器体系结构为企业资源规划的整合提供了良好的框架，是建立企业级管理信息系统的最佳选择。

随着体系结构的发展，软件框架结构方面也在不断发展，目前在多层应用结构方面出现Java技术和.net技术的实现的不同的解决方案，二者各有优缺点，分别适用于不同规模的系统的要求。

本文将结合电信计划建设管理信息系统的实现，说明三层模式的体系结构，介绍基于三层模式的应用系统的分布式组件技术，阐述应用J2EE框架结构来实现应用系统的实现方法。

一、系统结构的选择1、传统两层C/S结构的缺点传统的两层客户/服务器模式比较适合于小规模、用户较少、单一数据库且在安全、快速的网络环境下（例如局域网）运行。

但是，随着应用系统的规模不断扩大，复杂性越来越高在多用户、多数据库且非安全的网络环境下（例如：Internet），这种两层结构的应用模型将无法适应。

而且传统的两层结构还存在以下缺陷：(1)它是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或 Intranet;(2)受限于供应商，程序的升级维护必须由供应商重新开发扩展；(3)软、硬件的组合及集成能力有限；在软件上呈现出胖客户端，用户必须在客户端安装特定的客户端应用程序，而且企业的业务逻辑都写在客户端应用程序中，程序维护困难，程序升级需要每个客户端都要安装新的客户端应用程序，同时，对于程序开发商来说，程序模块的重用性差，各个模块相对独立；(4)C/S模式很难管理大量的客户机。

基于以上原因，传统的C/S模式已经不能适应发展的需要，随着网络技术的普及和用户需求的进一步提高，三层WEB模式应运而生。

2、三层WEB结构的优点三层客户/服务器模式（以下简称三层模式）在两层模式的基础上，增加了新的一级。

这种模式在逻辑上将应用功能分为三层：客户显示层、业务逻辑层、数据层。

客户显示层是为客户提供应用服务的图形界面，有助于用户理解和高效的定位应用服务。

业务逻辑层位于显示层和数据层之间，专门为实现企业的业务逻辑提供了一个明确的层次，在这个层次封装了与系统关联的应用模型，并把用户表示层和数据库代码分开。

这个层次提供客户应用程序和数据服务之间的联系，主要功能是执行应用策略和封装应用模式，并将封装的模式呈现给客户应用程序。

数据层是三层模式中最底层，他用来定义、维护、访问和更新数据并管理和满足应用服务对数据的请求。

三层模式的主要优点为：①良好的灵活性和可扩展性。

对于环境和应用条件经常变动的情况，只要对应用层实施相应的改变，就能够达到目的。

②可共享性。

单个应用服务器可以为处于不同平台的客户应用程序提供服务，在很大程度上节省了开发时间和资金投入；③较好的安全性。

在这种结构中，客户应用程序不能直接访问数据，应用服务器不仅可控制哪些数据被改变和被访问，而且还可控制数据的改变和访问方式。

④增强了企业对象的重复可用性。

“企业对象”是指封装了企业逻辑程序代码，能够执行特定功能的对象。

随着组件技术的发展，这种可重用的组件模式越来越为软件开发所接受。

⑤三层模式成为真正意义上的“瘦客户端”，从而具备了很高的稳定性、延展性和执行校率。

⑥三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的容错能力和负载平衡能力。

什么是网站的两层体系架构

展开全部C/S架构即Client/Server结构。

它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。

目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。

这也就是目前应用系统的发展方向。

CS架构的三层体系结构

相对于二层体系结构（Client/Server构架）是由逻辑上相互分离的表示层、业务层和数据层构成。

表示层向客户提供数据，业务层实施业务和数据规则，数据层定义数据访问标准。

三层体系结构中的核心是组件对象模型。

在网络连接模式中，除对等网外，还有另一种形式的网络，即服务器/客户机网，Client/Server。

在客户机/服务器网络中，服务器是网络的核心，而客户机是网络的基础，客户机依靠服务器获得所需要的网络资源，而服务器为客户机提供网络必须的资源。

它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。

大多数应用软件系统都是Client/Server形式的两层结构，由于软件应用系统正在向分布式的Web应用发展，Web和Client/Server应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。

这也就是应用系统的发展方向。

软件架构模式基本概念及三者区别

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

架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。

架构模式的好坏可以影响到总体布局和框架性结构。

设计模式是中等尺度的结构策略。

这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。

模式的好坏不会影响到系统的总体布局和总体框架。

设计模式定义出子系统或组件的微观结构。

代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。

代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。

架构模式（Architectural Pattern）一个架构模式描述软件系统里的基本的结构组织或纲要。

架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。

称之为系统模式。

?MVC模式，一个架构模式常常可以分解成很多个设计模式的联合使用。

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（微核）模式等。

设计模式（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）模式等。

代码模式（Coding Pattern）代码模式（或成例）是较低层次的模式，并与编程语言密切相关。

代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。

较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等

体系结构,软件构架和设计模式之间的区别和联系

展开全部结构：程序功能实现的逻辑框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法；另一方面也可以说框架是可被应用开发者定制的应用骨架。

框架亦可称为应用架构，在特定领域基于体系结构的可重用的设计。

也可以认为框架是体系结构在特定领域下的应用。

框架的例子如MVC。

设计模式在一定的环境中解决某一问题的方案构件通常是代码重用，而设计模式是设计重用，框架则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用. 构架是architecture：它是对软件系统的系统组织，是对构成系统的构件的接口，行为模式，协作关系等体系问题的决策总和。

它不仅涉及到结构与行为，而且还涉及到系统的使用，功能，性能，适应性，重用性，可理解性设计模式比框架更为抽象设计模式在碰到具体问题后，才能产生代码；框架已经可以用代码表示设计模式是比框架更小的体系结构元素：框架中可以包括多个设计模式简单点说：结构 < 设计模式 < 架构 <框架结构+算法=程序（功能代码块）程序与程序之间进行调整=设计模式多个设计模式相组合（组件）=架构（系统）...

层次软件体系结构的原理是什么？层次系统有哪些可取之处？有哪些不...

软件系统结构风格通常分为三种模式，即架构模式，设计模式，代码模式。

这三种不同的模式存在于它们各自的抽象层次和具体层次。

架构模式是一个系统的，多层次策略，涉及到大尺度的组件以及整体性质和力学。

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