软件体系结构风格论文.docx
- 文档编号:10503019
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:8
- 大小:54.60KB
软件体系结构风格论文.docx
《软件体系结构风格论文.docx》由会员分享,可在线阅读,更多相关《软件体系结构风格论文.docx(8页珍藏版)》请在冰点文库上搜索。
软件体系结构风格论文
软件体系结构课程设计
学院:
班级:
学号:
姓名:
指导教师:
1.软件体系结构的定义:
软件体系结构是具有一定形式的结构化元素,即构件的集合,包括处理构件、数据构件和连接构件。
处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把体系结构的不同部分组组合连接起来。
这一定义注重区分处理构件、数据构件和连接构件,这一方法在其他的定义和方法中基本上得到保持。
2.软件体系结构的分类:
一个小型的软件可能具有一种软件体系结构,而大型的软件一般由多种软件体系结构组成,软件体系结构没有定性的说只有几种风格,但是经过长期的大型软件设计与分析,人们总结出了一些最为常用的软件体系结构风格,分别是:
(1).数据流风格:
批处理风格;管道过滤器。
(2).调用返回风格:
主程序子程序;面向对象风格;分层风格。
(3).独立构件风格:
进程通讯;事件系统。
(4).虚拟机风格:
解释器;基于规则的系统。
(5).仓库风格:
数据库系统;超文本系统;黑板系统。
1.数据流风格:
数据流风格的体系结构中,我们可以在系统中找到非常明显的数据流,处理过程通常在数据流的路线上“自顶向下、逐步求精”,并且,处理过程依赖于执行过程,而不是数据到来的顺序。
1.1批处理风格:
批处理风格。
批处理序列的每一步处理都是独立的,并且每一步是顺序执行的,只有当前一步处理完后,后一步处理才能开始,数据传送在步与步之间作为一个整体。
批处理的典型应用是经典数据处理和程序开发。
批处理风格与管道过滤器风格的共同点是把任务分解成一系列固定顺序的计算单元(组件),组件间只通过数据传递交互。
区别表现在以下几个方面:
批处理是全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性,管道过、滤器是递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互。
1.2管道过滤器:
在管道/过滤器风格的软件体系结构中,每个组件都有一组输入和输出,组件读输入的数据流,经过内部处理,然后产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。
因此,这里的组件被称为过滤器,这种风格的连接器就象是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
此风格特别重要的过滤器必须是独立的实体,它不能与其它的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。
一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
编译器系统就具备典型的管道系统风格的体系结构。
在该系统中,一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。
管道/过滤器风格的软件体系结构具有许多很好的特点:
(1)使得软组件具有良好的隐蔽性和高内聚、低耦合的特点;
(2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;
(3)支持软件复用。
(4)系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来;旧的可以被改进的过滤器替换掉;
(5)允许对一些如吞吐量、死锁等属性的分析;
(6)支持并行执行。
每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。
这比下面将要阐述的一种“主-子程序风格”的单线程操作要灵活得多。
这种系统结构的弱点是:
(1)通常导致进程成为批处理的结构。
这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
(2)不适合处理交互的应用。
当需要增量地显示改变时,这个问题尤为严重。
(3)因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
2.调用返回风格:
调用/返回风格的体系结构在过去的30年之间占有重要的地位,是大型软件开发中的主流风格的体系结构。
这类系统中呈现出比较明显的调用/返回的关系。
2.1主程序子程序
主-子程序风格的体系结构是一种经典的编程范型,主要应用在结构化程序设计当中。
这种风格的主要目的是将程序划分为若干个小片段,从而使程序的可更改性大大提高。
主-子程序体系结构风格有一定的层次性,主程序位于一层,下面可以再划分一级子程序,二级子程序甚至更多。
需要特别注意的是主-子程序体系结构风格是单线程控制的。
同一时刻只有一个孩子结点的子程序可以得到父亲结点的控制。
其特点如下:
(1)由于单线程控制,计算的顺序得以保障。
(2)并且有用的计算结果在同一时刻只会产生一个。
(3)单线程的控制可以直接由程序设计语言来支持
(4)分层推理机制:
子程序的正确性与它调用的子程序的正确性有关。
2.2面向对象风格:
目前软件界已普遍转向使用面向对象系统,抽象数据类型概念对软件系统有着重要作用。
这种风格的构件是对象,或者说是抽象数据类型的实例。
对象是一种被称作管理者的构件,因为它负责保持资源的完整性。
对象是通过函数和过程的调用来交互的。
对象风格的体系结构具有以下的特点:
(1)对象抽象使得组件和组件之间的操作以黑箱的方式进行。
(2)封装性使得细节内容对外部环境得以良好的隐藏。
对象之间的访问是通过方法调用来实现的。
(3)考虑操作和属性的关联性,封装完成了相关功能和属性的包装,并由对象来对它们进行管理。
(4)使用某个对象提供的服务并不需要知道服务内部是如何实现的。
面向对象体系结构存在的问题:
(1)对象之间的耦合度比较紧:
为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。
只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。
(2)必须修改所有显式调用它的其它对象,并消除由此带来的一些副作用。
例如A使用了对象B,C也使用了对象B,那么,C对B的使用所造成的对A的影响可能是不可预测的。
分层风格的体系结构是将系统组织成一个层次结构,每一层为上层提供服务,并作为下层的客户端。
在分层风格的体系结构中,一般内部的层只对相邻的层可见。
层之间的连接器(conector)通过决定层间如何交互的协议来定义。
2.3分层风格
分层风格的体系结构:
(1)支持基于抽象程度递增的系统设计:
使设计者可以把一个复杂系统按递增的步骤进行分解;
(2)支持功能增强:
因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;
(3)支持复用:
只要提供的服务接口定义不变,同一层的不同实现可以交换使用。
这样,就可以定义一组标准的接口,而允许各种不同的实现方法。
但是,分层风格的体系结构也有其不足之处:
(1)并不是每个系统都可以很容易地划分为分层风格的体系结构,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
(2)很难找到一个合适的、正确的层次抽象方法。
总结一下调用/返回风格的软件体系结构:
这类架构中的组件就是各种不同的操作单元(例如,子程序、对象、层次),而连接器则是这些对象之间的调用关系(例如,主-子程序调用,或者对象的方法以及层次体系结构中的协议)。
调用-返回结构的优点在于,容易将大的架构分解为一种层次模型,在较高的层次,隐藏那些比较具体的细节,而在较低的层次,又能够表现出实现细节。
在这类体系结构中,调用者和被调用者之间的关系往往比较紧密。
在这样的情况下,架构的扩充通常需要被调用者和所有调用者都进行适当的修改。
3.独立构件风格:
3.1进程通讯:
进程间通信就是在不同进程之间通过共享内存或其他外设传播或交换信息。
3.2事件系统:
事件系统风格是独立组件风格的一个子风格。
其中的每一个独立组件在它们的相关环境中声明它们希望共享的数据,这个环境便是未指定的参与项。
事件系统会充分利用消息管理器(messagemanager)在消息传递到消息管理器的时候来管理组件之间的交互,和调用组件。
组件会注册它们希望提供或者希望收到的信息的类型。
随后它们会发送这个注册的类型给消息管理器,这个消息管理器可能是一个对象引用。
通信处理风格也是独立组件风格的一个子风格。
这是一个多处理系统。
4.虚拟机风格:
虚拟机风格的体系结构设计的初衷主要是考虑体系结构的可移植性。
这种体系结构力图模拟它运行于其上的软件或者硬件的功能。
4.1解释器:
解释器是能够执行用其他计算机语言编写的程序的系统软件,它是一种翻译程序。
它的执行方式是一边翻译一边执行,因此其执行效率一般偏低,但是解释器的实现较为简单。
4.2基于规则的系统:
基于规则的系统或者成为专家系统、生产式系统,是一种重要的应用系统,他广泛用于医疗诊断、航空航天、实时监控和辅助决策等领域中。
5.仓库风格:
在仓库风格中,有两种不同的组件:
中央数据结构(用于说明当前状态),和独立组件(在中央数据存贮上执行),仓库与外组件间的相互作用在系统中会有大的变化。
仓库风格的体系结构控制原则的选取产生两个主要的子类。
若输入流中某类时间触发进程执行的选择,则仓库是一个传统型数据库;系统中的组件通常包括数据存储区,以及与这些存储区进行交流的进程或处理单元,而连接器则是对于存储区的访问。
这类系统中,数据处理进程往往并不直接发生联系,它们之间的联系主要是通过共享的数据存储区来完成的。
这种现象非常类似于在独立组件架构中的情况。
另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
3.案例分析:
这里以本学期的作业图书管理系统来说:
我们的小组设计的图书管理系统是把C/S和B/S模式综合运用的体系结构。
其中以C/S模式为主,辅助以B/S模式。
C/S(Client/Server)结构,即客户机和服务器结构。
它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现,降低了系统的通讯开销。
B/S(Browser/Server)结构,即浏览器和服务器结构。
它是随着Internet技术的兴起,对C/S结构的一种变化或者改进的结构。
在这种结构下,用户工作界面是通过WWW浏览器(Browser)来实现,而主要事务逻辑放在服务器端(Server)去实现,形成所谓三层结构(客户层,应用服务层,数据层)。
这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本。
学校图书馆使用B/S体系结构,完成图书借阅人员远程对借阅信息查询。
借书者通过浏览器访问图书管理系统,使用借书证号进入系统,里面能查询到读者基本资料,未还图书列表,查看我的借阅历史等等。
由于在网上就能查询,方便借阅者对自己所借图书情况进行了解。
使用C/S体系结构,如图:
通过C/S结构,完成图书的入库,借阅,归还,图书信息查询等功能。
用户通过客户端进入图书管理系统,在此段完成“借书”、“还书”、“查询借阅信息”等操作,发出相应操作请求,即用户界面层;连接组件将该操作请求发送到服务器端,服务器端通过业务逻辑组件进行相应的业务处理,即业务处理层;业务处理完毕后,将处理更新后的信息保存到数据库,完成数据的存取过程,即数据访问层;数据存储完毕后,系统返回操作结果,直到用户界面。
完成用户通过客户端发送业务处理请求然后服务器端进行相应处理并最终把处理结果返回到客户端的一次业务处理过程。
图书馆采用以C/S模式为主,B/S模式为辅的体系结构,其主要优点有下:
1.应用服务器运行负荷轻。
由于采用了C/S模式为主的体系结构,在客户端较少(只有图书管理员安装)的情况下,客户端完成接受数据输入,校验数据有效性,向后台数据库发请求,接受返回结果,处理应用逻辑等的操作,把应用逻辑主要放在客户端,减少服务器的应用逻辑操作,降低了服务器的运行负荷。
使系统运行速度在低成本下也能大大提高。
2.成本低。
一般的以C/S模式为主的系统其成本都相对高,这是由于胖客户端瘦服务器的缘故,由于客户端安装使用成本较高,当客户端多时,往往会造成成本的增加,而图书管理系统却不同,由于客户端较少,用户面相对固定,使得因为客户端的过多而造成的成本高昂不复存在,相应的反而由于相对B/S模式的瘦服务器,减少了服务器购置的成本投入,反而比B/S模式成本更低。
3.相对于只用C/S模式方便性大大提高。
由于C/S模式使得借阅图书必须每次都要到图书馆去,在固定的地方有固定的客户端环境下才能进行图书借阅,方便性大大降低,但是如今在C/S模式下嵌套运用了B/S模式,使得图书借阅者能通过远程进入图书管理系统,能在不用去图书馆的情况下就能查询到相应的图书借阅信息,方便了用户的信息查询。
但是如此结构不可避免的也带来了缺点,由于是C/S为主,每次系统的维护升级都要对应一次客户端的更新,相对于B/S模式维护更新不方便;同时由于B/S模式使用少,不能使借书者远程上网运用浏览器访问的方式借书,使得借书方便性不强,这也是该模式的一大缺点。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 体系结构 风格 论文
![提示](https://static.bingdoc.com/images/bang_tan.gif)