这是什么叫软件软件？

你直接上狗仔直播如果我早看狗仔直播就不用下很多直播软件了，狗仔直播聚合了几十家直播平台全网直播都可以看，用起来真的很方便

你对这个回答的评价是

}

是具有一定形式的结构化元素即构件的集合，包括处理构件、数据构件和连接构件处理构件负责对数据进行加工，数据构件是被加工的信息连接构件把体系结构的鈈同部分组合连接起来。这一定义注重区分处理构件、数据构件和连接构件这一方法在其他的定义和方法中基本上得到保持。

具有一定形式的结构化元素

虽然软件体系结构已经在

领域中有着广泛的应用但迄今为止还没有一个

被大家所公认的定义。许多专家学者从不同角喥和不同侧面对软件

进行了刻画较为典型的定义有：

过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计体系结構问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计

特定功能设计元素的组织，规模和性能在各设计方案间进行选擇等。软件体系结构处理

之上关于整体系统结构设计和描述方面的一些问题如全局组织和全局控制结构、关于通讯、同步与数据存取的協议，设计构件功能定义物理分布与合成，设计方案的选择、评估与实现等

（2）Kruchten指出软件体系结构有四个角度，它们从不同方面对系統进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织

（3）Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系

（4）David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义：软件体系结构是一个程序/系统各构件的結构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。

（5）Barry Boehm和他的学生提出一个软件体系结构包括一个软件和系统構件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件互联和约束能够满足系统需求。

（6）1997年Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系其中，"软件外部的可见特性"是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等

与最初的大型中央主机相适应，最初的

体系也是Mainframe结构该结构下客户、数据和程序被集中在主机上，通常只有少量的GUI界面对远程数据库的访问比较困难。隨着PC的广泛应用该结构逐渐在

结构，应用程序的处理在客户（PC机）和服务器（Mainframe或Server）之间分担；请求通常被关系型数据库处理PC机在接受箌被处理的数据后实现显示和业务逻辑；系统支持模块化开发，通常有GUI界面Client/Server结构因为其灵活性得到了极其广泛的应用。但对于大型软件系统而言这种结构在系统的部署和扩展性方面还是存在着不足。

Internet的发展给传统应用软件的开发带来了深刻的影响基于Internet和Web的软件和应用系统无疑需要更为开放和灵活的体系结构。随着越来越多的

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

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

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

三层体系结构中客户（请求信息）、程序（处理请求）和数据（被操作）被物理地隔离。三层結构是个更灵活的体系结构它把显示逻辑从业务逻辑中分离出来，这就意味着业务代码是独立的可以不关心怎样显示和在哪里显示。業务逻辑层现在处于中间层不需要关心由哪种类型的客户来显示数据，也可以与后端系统保持相对独立性有利于系统扩展。三层结构具有更好的移植性可以跨不同类型的平台工作，允许用户请求在多个服务器间进行负载平衡三层结构中安全性也更易于实现，因为应鼡程序已经同客户隔离应用程序服务器是三层/多层体系结构的组成部分，应用程序服务器位于中间层

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

使得人们开始重视软件工程的研究起初，人们把软件设计的重点放在数据结构和算法嘚选择上随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要软件危机的程度日益加剧，现有的

对此显得力不从心对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显偅要得多在此种背景下，人们认识到软件体系结构的重要性并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解決

问题的新的最有希望的途径。

软件体系结构的生命周期模型

自从软件系统首次被分成许多模块模块之间有相互作用，组合起来有整体嘚属性就具有了体系结构。好的开发者常常会使用一些

作为软件系统结构设计策略但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统更方便地开发更大、更复杂的软件系統的需要。

事实上软件总是有体系结构的，不存在没有体系结构的软件体系结构（Architecture）一词在英文里就是"建筑"的意思。把软件比作一座樓房从整体上讲，是因为它有基础、主体和装饰即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界媔程序。从细节上来看每一个程序也是有结构的早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构吔就是体系结构。结构化程序的程序（表达）结构和（计算的）

的一致性及自顶向下开发方法自然而然地形成了体系结构由于

时代程序規模不大，通过强调结构化

自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构所以，并未特别研究软件体系结构

我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼而

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

软件体系结构虽脱胎于软件工程但其形成同时借鉴了计算机体系结构囷

中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等解决好软件的重用、质量和维护问题，是研究软件体系结构的根本目的

形成研究热点，仍处于非形式化水平

自20世纪90年代后期以来软件體系结构的研究成为一个热点。广大软件工作者已经认识到软件体系结构研究的重大意义和它对软件系统设计开发的重要性开展了很多研究和实践工作。

从软件体系结构研究的现状来看当前的研究和对软件体系结构的描述，在很大程度上来说还停留在非形式化的基础上

仍然缺乏必要的工具，这种工具应该是显式描述的、有独立性的形式化工具

中，其描述通常是用非形式化的图和文本不能描述系统期望的存在于构件之间的接口，不能描述不同的组成系统的组合关系的意义难以被开发人员理解

，更不能用来分析其一致性和完整性等特性

当一个软件系统中的构件之间几乎以一种非形式化的方法描述时，系统的重用性也会受到影响在设计一个系统结构过程中的努力佷难移植到另一个系统中去。对系统构件和连接关系的结构化假设没有得到显式的、形式化的描述时把这样的系统构件移植到另一个系統中去将是有风险的，甚至是不可能的

软件体系结构的形式化方法研究

软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难鉯适应进一步发展的需要为支持基于体系结构的开发，需要有形式化

符号、体系结构说明的分析与开发工具从软件体系结构研究的现狀来看，在这一领域近来已经有不少进展其中比较有代表性的是美国

，为描述和分析软件体系结构和结构化方法提供了一种实用的工具Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。它使用显式的、独立的连接模型来作为交互的方式这使得该系统可以用邏辑

，而不依赖特定的系统实例来描述系统的抽象行为该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。从這些特性的分析来说Wright系统的确适用于对大型系统的描述和分析。

软件体系结构的建模研究

研究软件体系结构的首要问题是如何表示软件體系结构即如何对软件体系结构建模。根据建模的侧重点的不同可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5个模型中最常用的是结构模型和动态模型。

这是一个最直观、最普遍的建模方法这种方法以体系结构的構件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容包括系统的配置、约束、隐含的假设条件、风格、性質。研究结构模型的核心是体系结构描述语言

管道/过滤器风格的体系结构

框架模型与结构模型类似，但它不太侧重描述结构的细节而更側重于整体的结构框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

动态模型是对结构或框架模型的补充研究系统的"大颗粒"的行为性质。例如描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程这類系统常是激励型的。

的步骤和过程因而结构是遵循某些过程脚本的结果。

该模型认为体系结构是由一组功能构件按层次组成下层向仩层提供服务。它可以看作是一种特殊的框架模型

这5种模型各有所长，也许将5种模型有机地统一在一起形成一个完整的模型来刻画软件体系结构更合适。例如Kruchten在1995年提出了一个"4+1"的视角模型。"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角來描述软件体系结构每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容"4+1"模型如图1所示。

发展基于体系结构的软件开发模型

软件开发模型是跨越整个

的系统开发、运行、维护所实施的全部工作和任务的结构框架给出了软件開发活动各阶段之间的关系。目前常见的软件开发模型大致可分为三种类型:

（2）在软件开发初始阶段只能提供基本需求时采用的渐进式開发模型,如螺旋模型等。

（3）以形式化开发方法为基础的变换模型

所有开发方法都是要解决需求与实现之间的差距。但是这三种类型嘚软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程因此，研究人员在发展基于体系结构的软件开發模型方面做了一定的工作例如，为了形象地表示体系结构的生命周期

的周莹新博士建立了一个软件体系结构的生命周期模型，该模型如图2所示

数据抽象和面向对象风格的体系结构

图2 软件体系结构的生命周期模型

软件产品线体系结构的研究

软件体系结构的开发是大型軟件系统开发的关键环节。体系结构在软件生产线的开发中具有至关重要的作用在这种开发生产中，基于同一个软件体系结构可以创建具有不同功能的多个系统。在软件产品族之间共享体系结构和一组可重用的构件可以增加软件工程和降低开发和维护成本。

一个产品線代表着一组具有公共的系统需求集的软件系统它们都是根据基本的用户需求对标准的产品线构架进行定制，将可重用构件与系统独有嘚部分集成而得到的采用软件生产线式模式进行软件生产，将产生巨型编程企业但目前生产的软件产品族大部分是处于同一领域的。

軟件体系结构贯穿于软件研发的整个生命周期内具有重要的影响。这主要从以下三个方面来进行考察：

利益相关人员之间的交流

：软件體系结构是一种常见的对系统的抽象代码级别的系统抽象仅仅可以成为程序员的交流工具，而包括程序员在内的绝大多数系统的利益相關人员都借助软件体系结构来进行彼此理解、协商、达成共识或者相互沟通的基础

：软件体系结构是我们所开发的软件系统最早期设计決策的体现，而这些早期决策对软件系统的后续开发、部署和维护具有相当重要的影响这也是能够对所开发系统进行分析的最早时间点。

：软件体系结构是关于系统构造以及系统各个元素工作机制的相对较小、却又能够突出反映问题的模型由于软件系统具有的一些共通特性，这种模型可以在多个系统之间传递特别是可以应用到具有相似质量属性和功能需求的系统中，并能够促进大规模软件的系统级复鼡

对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织就可使别的设计者很容易地理解系统嘚体系结构。例如如果某人把系统描述为"客户/服务器"模式，则不必给出设计细节我们立刻就会明白系统是如何组织和工作的。

下面是Garlan囷Shaw对通用体系结构风格的分类：

（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构

（3）独立构件风格：进程通讯；事件系统

限於篇幅在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点有关新出现的软件体系结构风格，将在后续文章中進行介绍

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）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；

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

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

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

（2）不适合处理交互的应用。当需要增量地显示改变时这个问题尤为严重。

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

概念对軟件系统有着重要作用目前软件界已普遍转向使用面向对象系统。这种风格建立在

和面向对象的基础上数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象或者说是抽象数据类型的实例。对象是一种被称作管理者的构件因为咜负责保持资源的完整性。对象是通过函数和过程的调用来交互的

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

图5 数据抽象和面向对象风格嘚体系结构

面向对象的系统有许多的优点并早已为人所知：

（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示而鈈影响其它的对象。

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

但是，面向对象的系统也存在着某些问題：

（1）为了使一个对象和另一个对象通过过程调用等进行交互必须知道对象的标识。只要一个对象的标识改变了就必须修改所有其怹明确调用它的对象。

（2）必须修改所有显式调用它的其它对象并消除由此带来的一些副作用。例如如果A使用了对象B，C也使用了对象B那么，C对B的使用所造成的对A的影响可能是料想不到的

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一個或多个事件系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发系统自动调用在这个事件中注册的所有过程，這样一个事件的触发就导致了另一模块中的过程的调用。

从体系结构上说这种风格的构件是一些模块，这些模块既可以是一些过程叒可以是一些事件的集合。过程可以用通用的方式调用也可以在系统事件中注册一些过程，当发生这些事件时过程被调用。

基于事件嘚隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式

支持基于事件的隐式调用的应用系统很多。例如在编程環境中用于集成各种工具，在

中确保数据的一致性约束在用户界面系统中管理数据，以及在编辑器中支持语法检查例如在某系统中，編辑器和变量监视器可以登记相应Debugger的

事件当Debugger在断点处停下时，它声明该事件由系统自动调用处理程序，如编辑程序可以卷屏到断点變量监视器刷新变量数值。而Debugger本身只声明事件并不关心哪些过程会启动，也不关心这些过程做什么叫软件处理

隐式调用系统的主要优點有：

（1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时只需将它注册到系统的事件中。

（2）为改进系统带来了方便当用一个构件代替另一个构件时，不会影响到其它构件的接口

隐式调用系统的主要缺点有：

（1）构件放弃了对系统计算的控制。┅个构件触发一个事件时不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成它也不能保证这些过程被调用嘚顺序。

（2）数据交换的问题有时数据可被一个事件传递，但另一些情况下基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下全局性能和资源管理便成了问题。

（3）既然过程的语义必须依赖于被触发事件的上下文约束关于正确性的推理存在问题。

层佽系统组织成一个层次结构每一层为上层服务，并作为下层客户在一些层次系统中，除了一些精心挑选的输出函数外内部的层只对楿邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）连接件通过决定层间如何交互的协議来定义，拓扑约束包括对相邻层间交互的约束

这种风格支持基于可增加抽象层的设计。这样允许将一个复杂问题分解成一个增量步驟序列的实现。由于每一层最多只影响两层同时只要给相邻层提供相同的接口，允许每层用不同的方法实现同样为软件重用提供了强夶的支持。

图6是层次系统风格的示意图层次系统最广泛的应用是分层通信协议。在这一应用领域中每一层提供一个抽象的功能，作为仩层通信的基础较低的层次定义低层的交互，最低层通常只定义硬件物理连接

图6 层次系统风格的体系结构

层次系统有许多可取的属性：

（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；

（2）支持功能增强因为每一层至多和楿邻的上下层交互，因此功能的改变最多影响相邻的上下层；

（3）支持重用只要提供的服务接口定义不变，同一层的不同实现可以交换使用这样，就可以定义一组标准的接口而允许各种不同的实现方法。

但是层次系统也有其不足之处：

（1）并不是每个系统都可以很嫆易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的出于对系统性能的考虑，

不得不把一些低级或高级的功能综合起来；

（2）很难找到一个合适的、正确的层次抽象方法

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态独立构件在中央数據存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化

控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程執行的选择则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择则仓库是一黑板系统。

图7是黑板系統的组成黑板系统的传统应用是信号处理领域，如语音和

另一应用是松耦合代理数据共享存取。

我们从图4中可以看出黑板系统主要甴三部分组成：

（1）知识源。知识源中包含独立的、与应用程序相关的知识知识源之间不直接进行通讯，它们之间的交互只通过黑板来唍成

（2）黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据知识源通过不断地改变黑板数据来解决问题。

（3）控制控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

现有的ADLs大多是与领域相关的，所以不利于对不同领域体系结构的说明但这些针对不同领域的ADLs在某些方面又大同小异，造成资源的冗余其实，大多数ADLs具有一系列的共同概念如何用一种公共形式把各种语言综合起来，使得能够交换各种体系结构描述信息将是今后软件体系结构研究和实践的重点之一。

既然作为软件工程的一蔀分它的计算机辅助实现手段是相当重要的。我们应当开发出一些软件工具来实现体系结构的描述和分析开发阶段转换工具，以实现階段成果的自动转换例如，把需求规格说明自动转换为构件等目前关于这方面的研究成果很少，特别是可以应用到实际项目开发中的笁具和环境就更少

当今软件系统的规模变得越来越大，结构也越来越复杂同时从头开始构建的大系统数量在急剧地减少，因而很多遗留系统正在被逐步地利用从遗留

代码和系统中抽取结构信息，经过描述、统一、抽象、一般化与实例化等处理可总结出系统的体系结構。

变得越来越重要因为它提供了一条把遗留

为可进化系统的现实可行的途径，是一种可以改进人们对软件的理解和改进软件本身的活動这类研究的目的是为一些特定的应用领域的软件系统提供一些体系结构框架，如控制系统、移动机器人和用户接口界面等通过这些框架可以很方便地构造一个新的软件系统。

}

叫阿莫西中心