嘘_告诉你个秘密_安倍是条狗
软件体系结构的发展历史
与最初的大型中央主机相适应，最初的软件结构体系也是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）一词在英文里就是建筑的意思。
把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。
从细节上来看每一个程序也是有结构的。
早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。
结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。
由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究软件体系结构。
我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。
构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。
软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。
软件体系结构研...
软件体系结构的应用现状
形成研究热点，仍处于非形式化水平自20世纪90年代后期以来，软件体系结构的研究成为一个热点。
广大软件工作者已经认识到软件体系结构研究的重大意义和它对软件系统设计开发的重要性，开展了很多研究和实践工作。
从软件体系结构研究的现状来看，当前的研究和对软件体系结构的描述，在很大程度上来说还停留在非形式化的基础上。
软件构架师仍然缺乏必要的工具，这种工具应该是显式描述的、有独立性的形式化工具。
在目前通用的软件开发方法中，其描述通常是用非形式化的图和文本，不能描述系统期望的存在于构件之间的接口，不能描述不同的组成系统的组合关系的意义。
难以被开发人员理解，更不能用来分析其一致性和完整性等特性。
当一个软件系统中的构件之间几乎以一种非形式化的方法描述时，系统的重用性也会受到影响，在设计一个系统结构过程中的努力很难移植到另一个系统中去。
对系统构件和连接关系的结构化假设没有得到显式的、形式化的描述时，把这样的系统构件移植到另一个系统中去将是有风险的，甚至是不可能的。
软件体系结构的形式化方法研究软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。
为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学（Carnegie Mellon University）的Robert J.A11en于l997年提出的Wright系统。
Wright是-种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式，这使得该系统可以用逻辑谓词符号系统，而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的建模研究研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。
根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。
在这5个模型中，最常用的是结构模型和动态模型。
（1）结构模型这是一个最直观、最普遍的建模方法。
这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。
研究结构模型的核心是体系结构描述语言。
（2）框架模型框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型动态模型是对结构或框架模型的补充，研究系统的大颗粒的行为性质。
例如，描述系统的重新配置或演化。
动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。
这类系统常是激励型的。
（4）过程模型过程模型研究构造系统的步骤和过程。
因而结构是遵循某些过程脚本的结果。
（5）功能模型该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
它可以看作是一种特殊的框架模型。
这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。
例如，Kruchten在1995年提出了一个4+1的视角模型。
4+1模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。
每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
4+1模型如图1所示。
图1 4+1模型发展基于体系结构的软件开发模型软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。
目前，常见的软件开发模型大致可分为三种类型：（1）以软件需求完全确定为前提的瀑布模型。
（2）在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。
（3）以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。
但是，这三种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。
因此，研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。
例如，为了形象地表示体系结构的生命周期，北京邮电大学的周莹新博士建立了一个软件体系结构的生命周期模型，该模型如图2所示。
图2 软件体系结构的生命周期模型软件产品线体系结构的研究软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发和维护成本。
一个产品线代表...
软件体系结构的设计是什么呢？
整个软件开发过程中关键的一步。
对于当今世界上庞大而复杂的系统来说，没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。
不同类型的系统需要不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。
体系结构的选择往往会成为一个系统设计成败的关键。
典型的软件体系结构风格有很多。
例如，设计图形用户界面（GUI）常用的事件驱动风格、设计操作系统常用的层次化设计风格、设计编译程序常用的管道与过滤器风格、设计分布式应用程序常用的客户机/服务器风格等。
一个实用的软件系统通常是几种典型体系结构风格的组合[1]。
近年来，我们致力于软件体系结构理论和实践应用研究，取得了一些初步成绩。
在第2节中，我们将给出
软件体系结构常用的设计模式包括哪些
MVC是当前流行的Web应用设计框架的实施标准，是软件工程中的一种软件架构模式[ ]。
它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller），目的是实现一种动态和可持续的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的代码或功能重复利用成为可能。
在这种设计结构下，一个应用被分为三个部分：model、view和controller，每个部分负责不同的功能。
根据用户界面（view）的操作完成对程序数据（model）的更新。
将程序数据（model）改变及时反应到用户界面（view）上。
也就是完成两个方向的动作。
软件体系结构的建模是怎样的？
一、软件体系结构和框架的定义软件体系结构的英文单词是“architecture”.Architecture的基本词义是建筑、建筑学、建筑风格。
软件体系结构虽然根植于软件工程，但还处于一个研究发展的阶段，迄今为止还没有一个为大家所公认的定义。
《设计模式》中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。
软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。
框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。
框架不是现成可用的应用系统。
是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。
框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。
框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。
而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。
二、框架与架构之间的关系框架不是构架（即软件体系机构）。
体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。
框架比架构更具体。
更偏重于技术涉嫌。
确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。
三、框架与设计模式之间的关系设计模式和框架在软件设计中是两个不同的研究领域。
设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。
框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。
1）从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。
2）从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。
3）以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。
总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。
Feedback#re：软件体系结构（构架）、架构、设计模式之间的关系回复更多评论2005-11-1813:08by非鱼FRAMEWORK和ARCHITECTURE属于不同的设计层次。
DP和FRAMEWORK、ARCHITECTURE分属不同的领域，DP只能和ARCHITECTURALPATTERN相提并论。
#re：软件体系结构（构架）、架构、设计模式之间的关系回复更多评论2005-11-1817:59bypublisherluoARCHITECTURE是描述系统整体的一种结构（C/S架构，B/S架构，三层架构等），使用框架开发的web系统也是一种体系结构，而架构是系统中的一部分具体实现。
框架的设计也使用了很多设计模式。
设计模式只是一个问题解决域，而框架可以利用设计模式来解决客观存在的问题。
几种常见的软件体系结构及特点分析
展开全部 20世纪60年代的软件危机使得人们开始重视软件工程的研究。
起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。
随着软件危机程度的加剧，软件体系结构（software architecture）这一概念应运而生。
软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。
与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。
面向方面软件开发（AOSD）认为系统是由核心关注点（corn concern）和横切关注点（cross-cutting concern）有机地交织在一起而形成的。
核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。
AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremadura大学的Navasa等人[1]在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中，称之为面向方面软件体系结构（aspect oriented software architecture,AO-SA），这样能够结合两者的优点，但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识，但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件（aspect component）这一新的构成单元，通过方面构件来封装系统的横切关注点。
目前国内外对于面向方面软件体系模型的研究还相对较少，对它的构成单元模型的研究更少，通常只关注方面构件这一构成单元。
方面构件最早是由Lieberherr等人[2]提出的，它是在自适应可插拔构件（adaptive plug and play component,APPC）基础之上通过引入面向方面编程（AOP）思想扩展一个可更改的接口而形成的，但它关于请求接口和服务接口的定义很模糊，未能给出一个清晰的方面构件模型。
Pawlak等人[3]提出了一个面向方面的框架，该框架主要包含了一个方面构件模型———Java方面构件（Java aspect component,JAC），但该方面构件模型仅包含了切点（pointcut），并把AOP中装备（advice）集成到了切点的表达式中，它主要从实现的角度进行了阐述，并没有给出详细的方面构件模型。
本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型，还详细分析了它的另外两个构成单元，即构件和连接件，因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念 面向方面软件体系结构涉及诸多概念，以下将分别介绍。
软件体系结构在软件工程领域有着广泛的影响，但当前仍未形成一个统一的、标准的定义。
目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束[4]。
其中约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。
这样就可以把软件体系结构写成 软件体系结构（software architecture）=构件（components）+ 连接件（connectors）+约束（constraints） 构件是软件体系结构的基本元素之一。
一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备语义完整、语法正确、有可重用价值的特点，然而目前对于构件的具体结构及构成并没有一个统一的标准[5]，而且一些主要的构件技术也没有使用相同的构件类型。
另外，当前被广泛接受的构件定义并不包含具体的软件构件模型（software component model）。
例如，Szyperski等人[6]给出了软件构件一个很有名的定义：软件构件是一个仅带特定契约接口和显式语境依赖的结构单位，它可以独立部署，易于第三方整合。
但是关于软件构件模型有一个被普遍接受的观点是：软件构件是一个具有服务提供和服务请求功能的软件单元[7]。
连接件是软件体系结构另一个基本的构成元素，是用来建立构件间交互以及支配这些交互规则的构造模块。
连接件最先是由Shaw[8]提出来的，她建议把连接件作为软件体系结构中第一类实体，用来表示普通构件之间的交互关系。
目前对于连接件尚未形成统一的认识，尽管在软件体系结构中强调了连接件存在的必要性，但是关于连接件模型的研究还很少，连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。
通常认为，方面构件是封装了系统横切关注点的一类特殊的构件。
目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型 由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。
其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。
以下对这...
软件体系结构与软件架构有哪些区别？
软件体系结构与软件架构的中文翻译都是英文Software Architecture。
两者都使用一样的定义，如IEEE的“一个系统的基础组织，包含各个构件、构件互相之间与环境的关系，还有指导其设计和演化的原则。
”[IEEE-2000]为了找到两者的区别，得先从应用的环境入手。
我们利用网站搜索引擎对这个领域的常用关键词进行了检索，搜索区域分为开发者网站、所有网站、学术网站，结果如下（检索日期2007-04-08）： ① http://www-128.ibm.com/developerworks/cn ② http://www.miscrosoft.com/china ③ google.com 采用精确匹配。
“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 ④ baidu.com 采用精确匹配。
“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 ⑤ http://www.cnki.net/index.htm采用精确匹配。
中国期刊全文数据库（2000-2007） 结果表明，在软件开发者和软件应用者来说，倾向于使用“软件架构”，在一定程度上接受“软件体系结构”。
大家对软件架构的设计人员，“架构师”得到广泛的认同。
对于学术界，普遍使用“软件体系结构”，对架构师几乎没有关注。
Software Architecture是一个实践性非常强的领域，统计表明理论和实践的鸿沟还是存在的。
其次，我们从词源探讨“体系”“结构”“架构”的解释[字典-2001]。
体系：若干事物互相联系而构成的一个整体。
例思想~ | 工业~ 结构：①建筑物承受重量和外力的部分及其制造。
按材料分有钢结构、木结构、砖石结构、框架结构、砖混结构等。
按形式分有悬索结构、拱结构等。
②构成整体的各个部分及其结合方式。
例经济~│文章~。
③文艺作品的内部构造。
即作品的各部分（包括内容和形式）之间有机的组织联系。
架构：①建造；构筑。
②框架；支架。
③比喻事物的组织、结构、格局。
例市场~│故事~庞大 通过以上分析，我们不难看出学术界为什么用“软件体系结构”。
首先，体系结构的中文定义完全符合IEEE等的定义。
强调整体与部分，部分与部分的关系；研究系统构成的方法学；提倡多角度研究系统。
其次，从学科地位讲，作为一门独立软件子学科，和硬件学科（计算机组织与体系结构）直接对应。
从工程实践需要看，软件架构更能体现系统构成与相关技术。
RUP过程或软件生产线关注的软件架构并不注重原理及表示，而是由结构和技术相结合的形成框架。
软件架构在中文中很容易与软件框架（Software Framework）混淆，对于一个应用的软件框架通常称为应用程序框架（Application Framework）。
框架是为了构建完整的应用而必须详细阐述的一种程序结构[Johnson-88]。
框架在RUP和软件产品线开发过程中是一个非常重要的过程。
RUP中框架是细化阶段的一个制品，软件产品生产线中是一组应用共享的程序框架。
目前，没有文献表明软件体系结构与软件架构的差别。
如果你强调方法论，应使用软件体系结构。
强调软件开发实践，应使用软件架构。
