软件架构综述论文
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件架构综述
一、软件架构的定义
1、软件架构的概念
软件架构(software architecture)是一个系统的草图,是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”一书中,David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”
2、与软件体系结构概念的细微区别
目前,没有文献表明软件体系结构与软件架构的差别。如果你强调方法论,应使用软件体系结构。强调软件开发实践,应使用软件架构。构架不仅是结构,IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
软件系统的架构是一个软件系统从整体到部分的最高层次的划分。其有两个要素:元件划分和设计决定。详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(TASk-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
3、研究的背景
在经历60年代的软件危机之后,使人们开始重视软件工程的研究。来自不同应用领域的软件专家总结了大量的有价值的知识. 当初,人们把软件设计的重点放在数据结构和算法的选择上,如Knuth提出了数据结构+算法=程序. 但是随着软件系统规模越来越大、越来越复杂,使软件系统的架构越来越重要。软件危机的程度日益加剧,现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说,软件体系架构比起对程序的算法和数据结构的选择已经变得明显重要得多。在此种背景下,人们认识到软件体系架构的重要性,并认为对软件体系架构系统、深入的研究将会成为提高软件生产效率和解决软件危机的最有希望的途径
二、架构的目标
正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:
〃可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。
〃安全行(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
〃可扩展性(SCAlable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。
〃可定制化(CuSTomizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
〃可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展
〃可维护性(MAIntainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
〃客户体验(Customer Experience)。软件系统必须易于使用。
〃市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
三、架构的种类
根据我们关注的角度不同,可以将架构分成三种:
〃逻辑架构:软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。
〃物理架构:软件元件是怎样放到硬件上的。
〃系统架构:系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。
四、架构的风格
软件体系结构风格(有时候也叫架构模式)是描述某一特定应用领域中系统组织方式的惯用模式,是为一个系统提供的一系列抽象框架。它反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。架构风格通过为经常发生的问题提供解决方案,来提高设计重用和改善程序结构。按这种方式理解,软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
通用软件体系结构风格总结为以下几类:
1.数据流风格:批处理序列;管道过滤器。
2.调用返回风格:主程序子程序;面向对象风格;层次结构。
3.独立构件风格:进程通讯;事件系统。
4.虚拟机风格:解释器;基于规则的系统。
5.仓库风格:数据库系统;超文本系统;黑板系统。
几种主要的和经典的体系结构风格:
1.C2风格。C2风格是最常用的一种软件体系结构风格,该体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。
2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统,抽象数据类
型概念对软件系统有着重要作用。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程
的调用来交互的。
3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个
过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中
注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件
的触发就导致了另一模块中的过程的调用。
4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中,每个构件都有一组输入
和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过
对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,