软件体系结构的应用现状
形成研究热点,仍处于非形式化水平自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 软件体系结构的生命周期模型软件产品线体系结构的研究软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用,在这种开发生产中,基于同一个软件体系结构,可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件,可以增加软件工程和降低开发和维护成本。
一个产品线代表...
什么是软件体系结构
软件体系结构研究如果仅仅停留在非形式化的框图阶段,已经难以适应进一步发展的需要。
为支持基于体系结构的开发,需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看,在这一领域近来已经有不少进展,其中比较有代表性的是美国卡耐基梅隆大学(Carnegie Mellon University)的Robert J.A11en于l997年提出的Wright系统。
Wright是-种结构描述语言,该语言基于一种形式化的、抽象的系统模型,为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式,这使得该系统可以用逻辑谓词符号系统,而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说,Wright系统的确适用于对大型系统的描述和分析。
软件体系结构设计的目录
第一篇基础篇:软件体系结构的理论 第1章绪论1.1软件体系结构的概念演化1.1.1软件体系结构的定义1.1.2软件体系结构的理论基础1.2软件体系结构形式化方法概述1.2.1基于CHAM的体系结构形式规约1.2.2基于Z语言的体系结构形式规约1.2.3基于一阶逻辑的体系结构形式规约1.2.4基于图论的体系结构形式规约1.2.5目前形式化方法存在的问题1.3软件体系结构描述语言概述1.4软件质量与质量模型 思考题 第2章软件建模的基础2.1一个简单例子2.2面向对象特性2.2.1封装性2.2.2继承性2.2.3多态性2.3接口2.4设计原则2.4.1SRP单一职责原则2.4.2OCP开闭原则2.4.3LSP里氏替换原则2.4.4ISP接口分离原则2.4.5DIP依赖倒置原则2.5UML2的各种图2.6需求建模:用例2.6.1一个用例图例子2.6.2用例与参与者2.6.3用例图2.6.4用例间关系2.6.5用例对需求建模2.7基本结构建模2.7.1一个类图例子2.7.2性质2.7.3对象图2.7.4操作2.7.5接口2.7.6关系2.7.7关系建模2.7.8类图2.8高级结构建模2.8.1公共扩展机制2.8.2包和包图2.8.3复合结构2.8.4模板2.9Kruchten4+1模型描述软件体系结构2.9.1逻辑视图:面向对象的分解2.9.2过程视图:过程分解2.9.3开发视图:子系统分解2.9.4物理视图:从软件到硬件的映射2.9.5场景视图:汇总2.9.6视图间的交流2.9.7模型的迭代过程和软件文档 思考题 第3章软件体系结构的形式化3.1软件的生命周期3.2基于抽象代数的形式化方法3.2.1构件3.2.2连接件3.2.3软件体系结构3.2.4软件体系结构关系3.2.5软件体系结构范式3.3基于粒度计算的形式化方法3.3.1软件体系结构演化3.3.2属性合成和跟踪3.3.3软件体系结构多视图表达及集成3.3.4软件体系结构风格和软件体系结构风格发现3.4*基于π演算的形式化方法3.4.1π演算基本语法3.4.2π演算约简关系3.4.3π演算迁移关系3.5*动态软件体系结构的形式化描述:化学抽象机3.5.1化学抽象机模型3.5.2软件体系结构描述 思考题 第4章软件体系结构的风格4.1管道和过滤器风格4.2仓库风格和黑板风格4.3事件驱动风格4.4客户机?分配器?服务器风格4.5分层系统风格4.6解释器4.7面向服务的体系结构4.7.1面向服务体系结构中的组成元素4.7.2面向服务体系结构的设计原则4.8过程控制环路模式 思考题 第5章体系结构描述语言5.1典型ADL5.1.1C2概述5.1.2Darwin与Wright概述5.1.3ACME概述5.1.4UniCon概述5.1.5Aesop概述5.1.6Rapide概述5.1.7MetaH5.1.8SADL概述5.2πADL的概述5.2.1πADL体系结构描述框架5.2.2πADL体系结构风格描述方法5.3πADL体系结构行为规约 思考题 第6章软件质量建模方法6.1软件质量建模与分析6.1.1风险分析的基本概念6.1.2风险分析的基本方法6.1.3图形化建模语言6.2实证分析:软件体系结构的质量6.2.1地面智能机器人的软件系统6.2.2解决方案1:过程控制环路模式6.2.3解决方案2:分层架构模式6.2.4解决方案3:基于事件驱动的隐式调用模式6.2.5解决方案4:黑板体系模式6.2.6解决方案比较 思考题 第7章设计模式7.1设计模式概述7.2设计模式的分类7.3创建型的设计模式7.3.1Factory7.3.2Prototype7.3.3Builder7.3.4Singleton7.3.5Adapter 思考题 第8章战场环境中自适应服务的软件组合框架8.1服务的描述与特征8.1.1服务模型8.1.2服务事务处理8.2TSCF服务组合框架8.2.1TSCF框架8.2.2服务代理设计8.2.3服务组合协调8.3服务调度流程控制的应用实现8.4小结 思考题 第二篇软件复用与构件库的设计 第9章构件库研究现状 第10章软件复用概述 第11章构件技术 第12章Web构件库实现 第三篇软件规模的度量 第13章软件规模度量研究现状 第14章FPA方法 第15章FPA方法的实际应用及其不足 第16章FPA方法的改进 第17章改进后FPA方法的应用及实例试验 第四篇软件的性能抗衰 第18章软件的性能问题与抗衰技术18.1软件性能衰退 第19章新型软件抗衰策略 第20章细粒度软件抗衰策略研究 第21章细粒度重启技术研究 第22章细粒度软件抗衰策略模型研究 附录A缩略词及中英文词汇对照附录B软件体系结构支持工具参考文献 ……
什么是软件系统架构设计
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石:无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
软件体系结构的发展历史
与最初的大型中央主机相适应,最初的软件结构体系也是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)一词在英文里就是建筑的意思。
把软件比作一座楼房,从整体上讲,是因为它有基础、主体和装饰,即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。
从细节上来看每一个程序也是有结构的。
早期的结构化程序就是以语句组成模块,模块的聚集和嵌套形成层层调用的程序结构,也就是体系结构。
结构化程序的程序(表达)结构和(计算的)逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。
由于结构化程序设计时代程序规模不大,通过强调结构化程序设计方法学,自顶向下、逐步求精,并注意模块的耦合性就可以得到相对良好的结构,所以,并未特别研究软件体系结构。
我们可以作个简单的比喻,结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼,而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。
构件怎样搭配才合理?体系结构怎样构造容易?重要构件有了更改后,如何保证整栋高楼不倒?每种应用领域需要什么构件(医院、工厂、旅馆)?有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑(即体系结构)更能满足用户的需求?如同土木工程进入到现代建筑学一样,软件也从传统的软件工程进入到现代面向对象的软件工程,研究整个软件系统的体系结构,寻求建构最快、成本最低、质量最好的构造过程。
软件体系结构虽脱胎于软件工程,但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法,最近几年软件体系结构研究已完全独立于软件工程的研究,成为计算机科学的一个最新的研究方向和独立学科分支。
软件体系结构研...
软件体系结构描述语言与程序设计语言有什么区别
从软件体系结构研究和应用的现状来看,当前对软件体系结构的描述,在很大程度上来说还停留在非形式化的基础上,很大程度上依赖于软件设计师个人的经验和技巧。
在目前通用的软件开发方法中,其对软件体系结构的描述通常是采用非形式化的图和文本,不能描述系统期望的存在于构件之间的接口,更不能描述不同的组成系统的组合关系的意义。
这种描述方法难以被开发人员理解,难以适于进行形式化分析和模拟,缺乏相应的支持工具帮助设计师完成设计工作,更不能用来分析其一致性和完整性等特性。
因此,形式化的、规范化的体系结构描述对于体系结构的设计和理解都是非常重要的。
然而,要实现体系结构设计、描述等的形式化并不是一蹴而就的,我们必须先经历一个非形式化的过程,在非形式化的发展过程中逐步提取一些形式化的标记和符号,然后将它们标准化,从而完成体系结构设计、描述等的形式化。
本文首先简单地介绍传统的软件体系结构描述方法,然后再比较详细地讨论软件体系结构描述语言。
一、传统软件体系结构描述方法1、图形表达工具对于软件体系结构的描述和表达,一种简洁易懂且使用广泛的方法是采用由矩形框和有向线段组合而成的图形表达工具。
在这种方法中,矩形框代表抽象构件,框内标注的文字为抽象构件的名称,有向线段代表辅助各构件进行通讯、控制或关联的连接件。
例如:图1表示某软件辅助理解和测试工具的部分体系结构描述。
目前,这种图形表达工具在软件设计中占据着主导地位。
尽管由于在术语和表达语义上存在着一些不规范和不精确,而使得以矩形框与线段为基础的传统图形表达方法在不同系统和不同文档之间有着许多不一致甚至矛盾,但该方法仍然以其简洁易用的特点在实际的设计和开发工作中被广泛使用,并为工作人员传递了大量重要的体系结构思想。
为了克服传统图形表达方法中所缺乏的语义特征,有关研究人员试图通过增加含有语义的图元素的方式来开发图文法理论。
2、模块内连接语言软件体系结构的第二种描述和表达方法是采用将一种或几种传统程序设计语言的模块连接起来的模块内连接语言MIL(Module Interconnection Language)。
由于程序设计语言和模块内连接语言具有严格的语义基础,因此他们能支持对较大的软件单元进行描述,诸如定义/使用和扇入/扇出等操作。
MIL方式对模块化的程序设计和分段编译等程序设计与开发技术确实发挥了很大的作用。
但是由于这些语言处理和描述的软件设计开发层次过于依赖程序设计语言,因此限制了他们处理和描述比程序设计语言元素更为抽象的高层次软件体系结构元素的能力