一种自适应的软件体系结构方法

一种自适应的软件体系结构方法

在网络环境下，恶意软件面临着快速和可变电态的用户需求和操作环境，这要求恶意软件能够感知外部操作环境的变化，并根据功能指标和性能指标进行静态和动态发展，这意味着恶意软件具有一定的适应性。所谓自适应性,是指软件系统能够在运行过程中,实时收集系统的各种变化信息,并根据预先设定好的策略,在必要的时候对自身进行调整,以更好地为用户提供服务。近些年来,人们逐渐认识到软件体系结构是处理软件质量属性的一个适当的层次。软件体系结构(softwarearchitecture,SA)是一个程序或计算系统的结构,它包括该系统的软件元素、这些元素的外部可见属性、以及元素之间的关系。作为设计阶段的第一个重要制品,软件体系结构不仅是系统的蓝图,更是系统质量属性的载体。软件体系结构对于质量属性的影响是如此巨大,以至于在很多情况下,体系结构的一个设计决策会影响到多个质量属性,需要在这些质量属性之间做出权衡以确定体系结构的设计。但是,这种权衡往往是以牺牲一个或多个质量属性要求来完成的,在多个同等重要质量属性的权衡中其效果往往差强人意。另一方面,很多研究人员开始关注软件体系结构层次的动态性,即通过在软件体系结构层次对系统进行调整,以达到增加功能或提高性能指标等目的。文献指出,对于运行时刻变化的关注渗透于系统设计。作为描述、理解和分析系统行为的一个工具,软件体系结构成为在体系结构层次管理系统动态性的一个重要工具,充分利用这一层次系统设计的知识,对于管理运行时刻系统变化也提供了良好的支持。自20世纪90年代中期以来,涌现了很多对于软件体系结构动态性的研究,这些研究可以统称为动态软件体系结构研究(dynamicsoftwarearchitecture,DSA)。总结说来,动态软件体系结构支持构件和连接子的增加、删除和替换,拓扑结构的变化和体系结构约束的变化。动态软件体系结构是对软件自适应在软件体系结构层次的重要尝试。作为下一代中间件研究和实践的热点,反射式中间件被认为是实现适应式中间件的根本途径。反射式中间件使得整个系统(包括中间件平台和应用程序)的内部状态和行为在运行时刻可以被观测和操作。现有的反射式中间件研究强调运行时的调整能力,提供的可观测信息大多反映平台内部的配置以及运行过程中产生的信息片段,帮助理解整个系统的作用有限。针对现存的反射式中间件反射能力不足、易用性不佳的情况,文献提出了一种基于软件体系结构的中间件反射方法,并且实现了一个基于软件体系结构的反射式中间件PKUAS。该方法的核心思想在于将软件体系结构作为完整、准确、翔实、易于理解的中间件自述——运行时刻软件体系结构(runtimesoft-warearchitecture,RSA)。RSA是系统软件体系结构在运行时刻的视图,它不仅描述了中间件平台的内部结构与行为,还从上层应用的角度描述了整个应用系统的结构与行为。上述3方面的研究,都对软件系统的自适应提供了直接的支持,软件体系结构成为实现软件自适应的核心:质量属性在软件体系结构层次的显式描述为软件自适应提供了目标;动态软件体系结构为软件自适应提供了模型描述和实现指导;反射式中间件及运行时刻软件体系结构为软件自适应提供了运行时刻的实施支持。这3方面的研究虽然各自取得了比较大的突破,但是也各具有一些不足之处。大部分的软件体系结构设计和评估方法都主要关注设计阶段,没有考虑软件生命周期的其他阶段,如运行时刻软件体系结构的作用。设计阶段包含在软件体系结构中的信息对于软件生命周期中的其他阶段具有重要的指导作用,而这些信息往往并没有被包含在软件体系结构描述中。另外,大部分软件体系结构设计和评估方法对质量属性只能通过模拟、分析等进行静态的评估和静态的调整,针对一些与运行时刻紧密相关的质量属性,如性能、可靠性等,其评估结果的正确性无法保证,其调整策略可能不是最佳的,甚至是错误的。动态软件体系结构相关研究在软件体系结构描述语言中加入变化性的描述机制,用以规约设计人员可以预测的变化。在运行阶段则试图通过软件体系结构来指导系统的维护与演化。但是,目前动态软件体系结构的研究多集中在系统演化,也就是说,其研究的重点是系统功能的增删和更改,忽略了质量属性方面的研究和实践,其动态调整需要维护人员的参与,与自适应的目标有一定距离。运行时刻软件体系结构的相关研究基于软件体系结构的反射为实现软件的自适应提供了良好的支撑机制。但是,基于RSA的反射式中间件只是提供了自适应的机制,也就是说解决了“如何做”问题,但因为缺乏足够的应用系统信息而无法决定“为何做”、“何时做”和“做什么”等问题。为实现软件系统的自适应,本文综合上述软件体系结构相关领域的研究成果,提出了一种基于软件体系结构的方法,即自适应软件体系结构方法(self-adaptivesoftwarearchitecture,SASA)。该方法利用基于质量属性场景的软件体系结构分析方法来获得适应性变化的原因和时机,利用质量属性驱动的软件体系结构设计方法决定适应性变化的内容,利用支持变化性描述的软件体系结构描述语言记录上述信息,利用基于运行时刻软件体系结构的中间件在运行时刻实施指定的适应性变化,以达到面向质量属性的软件自适应目标。其基本思路可表达为:SASA=SA+DSA+RSA,即,适应性软件体系结构利用传统软件体系结构来提供对于质量属性的支持,通过动态软件体系结构来分析和描述软件系统在运行时刻可以进行的体系结构层次的调整,通过运行时刻软件体系结构实施对于软件体系结构的修改,并最终保证系统的质量属性指标。1通过atam方法来提取质量属性场景来获得所获得的信息本文的目标是面向质量属性的软件自适应,也就是说,本文考察的是如何通过软件自身的适应性来保证软件预期的质量属性需求。第一,所谓的自适应,是指在系统运行时刻没有人工参与,完全由软件来监控和调整自身;第二,保证软件的质量需求是指,在系统运行过程中的大部分时间内,使系统对外呈现出预期的质量,并且在系统某个质量属性不能被满足的(外界环境变化引起的)情况下,系统能马上做出反应并进行调整,在一段可以接受的调整时间之后,使系统能够恢复其预期的质量。从逻辑角度上讲,通过软件自适应来保证系统的质量属性需求需要解决下面3个方面的问题:何时做(when),即确定在什么情况下需要对系统进行调整,针对质量而言,就是确定系统处于哪种状态时其质量属性不能被满足;做什么(what),即确定当系统的质量属性不能满足时应该对系统进行哪些调整,针对体系结构而言,就是要定位需要调整的系统成分;如何做(how),即调整方案如何通过运行实体的具体动作实现,针对自适应的支撑机制而言,就是如何保证分析得到的调整方案正确、完整地在运行系统中实施。针对“何时做”的问题,究其本质,需要确定系统所需质量属性的临界值。也就是说,需要选择一种形式化或者半形式化的方法来对质量属性进行描述。SASA方法选择质量属性场景作为对于系统质量进行描述的方法,也就是通过质量属性场景来获得“何时做”的信息。一个质量属性场景代表了某个特定的质量属性需求,它由激励源、激励、环境、制品、响应和响应度量6个部分组成。其中,激励源和激励描述了质量属性度量的外部条件或事件;制品描述了该场景涉及的系统组成部分;响应和响应度量描述了临界值。ATAM是基于质量属性场景的软件体系结构分析方法,该方法不仅揭示了体系结构满足特定质量属性的情况,而且强调了如何在不同的质量目标之间(一个体系结构设计决策可能影响多个质量目标的实现)进行权衡。在ATAM方法中,通过场景的集合来捕获质量需求,通过效用树将场景按照其对应的质量属性及优先级别进行组织,通过关键点和权衡点(即属性之间的依赖关系)来对多个质量属性目标进行权衡。SASA借鉴ATAM的研究成果来对体系结构的质量属性进行分析,对ATAM的结果和过程进行了剪裁,以得到对于自适应分析有用的信息。剪裁后的ATAM结果包括两个部分,即效用树、敏感点和权衡点的集合。效用树是质量属性和场景的树形组织;敏感点和权衡点是对一个或者多个质量属性具有显著影响的体系结构决策的集合。剪裁后的ATAM的步骤包括两个活动,一是产生质量属性的效用树,即列举构成系统“效用”的质量属性(性能、可用性、安全、可修改性、易用性等等),将这些属性逐步具体化到场景级别(用场景表示的质量属性),构成效用树,并给出效用树中场景的优先级别。二是分析体系结构方法,即基于效用树中高优先级的场景,定位并分析实现该场景所采用的体系结构方法,并对该类场景进行遍历以发现系统中所有场景的敏感点和权衡点。SASA利用剪裁后的ATAM结果来分析每个引发自适应调整的场景,找到相关的体系结构层次的关键元素以确定调整的具体方案。针对“做什么”的问题,需要选择一种形式化或半形式化的方法来刻画适应性调整的策略,即在质量属性指标不满足的情况下,对系统中相关的部分进行什么样的调整,使得质量属性能够恢复到可接受的范围。这种调整可以是模块层次的,也可以是类层次的,SASA方法选择在体系结构层次进行调整,即在体系结构层次上对体系结构模型中的元素进行调整,并将这种调整在运行时刻进行实施,来达到保证质量属性指标的目的。ABC/ADL是支持基于体系结构的构件组装方法(architecturebasedcomponentcomposition,简称ABC)的体系结构描述语言(architecturedescriptionlanguage),不仅能够描述系统的结构,而且能够帮助软件系统的精化和构建,并且支持自动的组装和验证。本文对ABC/ADL进行了适当的扩展以使其能够支持适应性软件体系结构的描述,即针对每个自适应策略的对象(场景的敏感点和权衡点),加入相应的策略描述。指定自适应策略在体系结构中的绑定元素,即通过场景分析得到的敏感点和权衡点在体系结构模型中可以进行对应的体系结构建模元素。这些绑定元素包括构件及其属性、连接子及其属性、拓扑结构、系统行为等,这些元素都将作为自适应策略中可操作的对象,在自适应过程中进行调整。自适应的策略通过一个新的建模元素Action来表示,图1是Action的构成图示。一个自适应调整策略应当能够描述该调整进行的时机、该调整的具体内容以及调整后可预见的对系统产生的影响,因此,建模元素相应地包括以下几个部分:1)Trigger用来描述调整的时机,该时机可能是系统无法满足某个质量目标,或者是其他自适应策略的级联反应。Objective利用场景描述中的Response和Measure两个成分来刻画一个质量目标。Objective与被绑定的元素共同形成系统在运行时刻需要的监控信息,即自适应支撑机制需要对绑定元素的响应进行监控,看其是否在响应度量的范围之内。CausalAction描述引发当前自适应策略实施的其他自适应策略。2)ActionType,ActionContent和Duration用来刻画调整的内容。ActionType描述可操作于绑定元素之上的调整类型,包括添加(addition)、删除(removal)、调整(adaptation)。对于调整来讲,必须给出调整的内容ActionContent,ActionContent的描述方式与被绑定的元素的描述方式相同。每个自适应策略都有一个持续时间来表明该策略的实施是暂时的还是永久的。3)DependantAction,TargetNFR和SideEffect描述了自适应策略的影响。对策略影响的记录是对设计者在不同属性之间进行权衡并进行决策的一个记录,这对于系统后期的理解和维护都具有很大的意义。DependantAction描述一个自适应策略可能引发的其他策略,应与CausalAction结合考虑。SideEffect描述该策略可能对系统哪些质量属性产生负面影响。TargetNFR描述自适应策略的目标质量属性,即该自适应变化所期望达到的质量属性目标,通过TargetNFR模型元素来对变更结果进行约束,在运行时刻通过中间件提供的监测机制来获得变更后的系统运行状态,在变更持续的时间内与约束条件进行对照,以保证变更结果的有效性和正确性。针对“如何做”的问题,需要选择一个合适的运行时刻支撑机制,来具体实施适应性软件体系结构模型中所要求的调整策略。从技术角度讲,这个支撑机制必须能够支持对系统的监控和灵活调整。在反射式中间件中,元层实体(中间件)可通过监控基层实体(中间件平台及其上层应用)的结构及其行为两种方式来实现不同效果的反射,元层实体的变化也会立即导致基层实体发生相应变化。根据结构及行为的反射,元层实体同样可以对基层实体的交互/依赖关系和交互行为进行调整。文献中提出了一种基于软件体系结构的中间件反射方法,并且实现了一个反射式的中间件平台PKUAS。鉴于本文中对于自适应调整方案表现为软件体系结构元素的调整,而PKUAS正是利用软件体系结构作为中间件自述,因而采用PKUAS作为本文方法的支撑机制可以确保自适应调整方案能够完整、准确地通过运行时刻的调整实现。PKUAS可支持如表1所示的体系结构层次的调整。图2给出了传统方法和本文方法的一个概览。其中,图2(a)中给出了不考虑自适应的传统软件设计方法:首先,设计人员根据需求规约进行体系结构的设计得到应用程序的软件体系结构;然后,针对需求中的质量属性对体系结构进行分析和调整;最后,将最终实现的系统进行部署,由维护人员对运行的系统进行监控并分析监控得到的结果,在需要的时候对系统进行调整。从质量属性和自适应两个方面考察,可以发现传统方法存在两个不足。第一,对于质量属性的考虑可以包含在体系结构设计和分析的过程之中,但是,正如前文所说,传统方法中对于质量的评估和针对质量的调整都是静态的,这样往往会形成不佳的或者不必要的设计决策。第二,传统方法中没有对自适应的支持,对于运行系统中存在的不能被满足的质量属性,必须通过人工的参与来识别并且解决。可以预见的是,如果系统的维护人员能够获得详细的体系结构信息,将有助于对系统做出有效、正确的调整。针对上面的不足,图2(b)给出了本文提出的方法,该方法的过程如下:1)根据需求规约按照传统的方法进行体系结构设计,得到应用程序的软件体系结构。2)分析需求规约中的质量属性场景,选择与自适应相关的质量场景。3)针对2)中选择的场景,按照某种体系结构分析方法(本文采用ATAM)选择适当的调整方案,并将该方案及其对应的质量属性场景作为备选配置记录在适应性软件体系结构中。4)对于3)中得到的每个不同的配置,对其进行体系结构分析,以保证系统质量属性得到满足。5)将按照适应性软件体系结构实现的系统部署到运行支撑平台(本文采用PKUAS)上,该平台根据适应性软件体系结构中描述的自适应解决方案对系统进行监控和调整。与传统方法相比,SASA方法将静态评估得到的调整方案作为备选的配置记录在适应性软件体系结构描述中,其实施被推迟到运行时刻。这样做,一方面使得调整能够更加精确,另一方面也可以得到调整策略是否有效的反馈,维护人员可以根据这些反馈来对设计阶段形成的效用较低的调整策略进行修改。另一方面,SASA在运行时刻的调整依据设计时刻形成的调整策略,整个运行过程不需要人的参与,系统自动完成监控、解释、解决和调整,达到了一定程度的“自适应”。2案例研究2.1基于opc的流程Java宠物商店(JPS)是Sun公司提供的J2EE示例应用,本文将利用JPS对SASA的建模过程进行示例。整个JPS由4个主要部分组成——宠物商店网站(WebSite)、订单处理中心(OrderProcessCenter,以下简称OPC)、管理界面(AdminGUI)和供货商(Supplier)。其中WebSite作为整个系统的外部接口与用户直接进行交互,将订单发送给OPC,OPC首先对订单进行一定的处理,然后将生成的购物请求发送给Admin。管理员通过Admin界面来批准(在用户信用卡中扣除相应的款额)或者拒绝订单(用户信用卡中余额不足),并将结果再发送回OPC。对于批准的订单,OPC将购物请求发送给Supplier,Supplier从库存中找到相应的宠物,并且运送给客户,同时将发票发送回OPC;对于拒绝的订单,OPC向客户发送邮件通知请求被拒绝。鉴于篇幅限制,本文中将只利用OPC部分进行实例研究,并针对该部分的场景进行自适应的分析。图3是复合构件OPC的配置图。PurchaseOrder-Receiver负责接收从WebSite发送的订单;Admin可以通过OPCAdminFacade来对到达OPC的订单进行直接的访问;OrderApprovalReceiver用来接收从Admin发送的被批准的订单;OrderApprovalSender用来将已经批准的订单发送给Supplier;InvoiceSender等待接收从Supplier发来的发票;CustomerRelation负责将发票信息或者拒绝信息发送给客户;ProcessManager负责管理整个订单的处理流程。2.2基于可移植性的场景分析表2给出了JPS部分场景列表。根据这些场景,可以得到如图4所示的效用树。JPS的效用树表示,系统中需要考虑性能、可追踪性、可移植性和安全性4个质量属性。性能可以细分为响应时间和吞吐量两个子属性,其中响应时间通过场景1,2,4和5来表示,吞吐量通过场景3来表示;可追踪性主要是对订单处理调用的记录,通过场景6来表示;安全性主要是要求在WebSite和OPC之间传送数据的机密性,通过场景7来表示;可移植性主要是指应用程序在不同的数据库之间的移植,通过场景8来表示。通过对不同的场景的分析,可以看出性能所对应的场景具有最高的优先级,安全性和可移植性具有较高的优先级,而可追踪性的优先级较低。从实现难度上讲,可移植性的难度最高,性能次之,安全和可追踪性比较容易实现。根据JPS的效用树,可以对场景进行分析。按照前文所述的启发式原则,可以得到如下判断,即除了场景8以外,其他的场景都涉及运行时刻的系统质量属性,而且都有一定的响应临界值。所以,场景1—7都作为自适应相关的场景,需要对其进行自适应相关的分析。重点考察构件OPC的性能属性。场景3,4和5描述的是构件OPC在性能方面的一些要求。因为构件OPC的实现方式主要采用工作流的模式,所以对于流程的控制将成为场景3,4和5的敏感点。图5是OPC的处理流程。首先从PurchaseOrderSender(WebSite)接收客户的订单,然后把订单发送给Administration进行处理,一旦从OrderApprovalSender(Admin)接收到批准的订单的消息,则通过SupplyApprove向Supplier发送送货请求,然后等待InvoiceSender(Supplier)将发货的发票返回。经过分析可以得出,OPC的性能取决于流程中每个活动的性能,因此流程及其内部各个活动的设计是场景3,4和5的敏感点。2.3dministraft响应面设计经过上一节的分析,场景3,4和5的敏感点是整个OPC的流程。OPC对于用户的响应时间取决于流程处理中的所有活动中性能最低的活动。图6左侧是OPC当前的处理流程。从图中可以看出,Administration是系统的主要性能瓶颈(影响OPC的吞吐量和响应时间),可以考虑对OPC中的流程做出如图6右侧所示的修改,即Administration只处理总金额大于500的订单。这样,在不影响系统业务目标的情况下,可以缩短一个订单的平均处理时间,提高系统的吞吐量,可以作为场景3和4的自适应策略。在自适应方案确定以后,需要对调整后的体系结构配置进行一定的分析。对图6中的调整,通过分析可以知道调整后的系统不能满足场景6。对于基于中间件的系统来讲,可以很容易的解决这一问题,可以对系统启动日志服务,对每个订单处理调用进行记录即可满足。针对场景5描述的情况,如果在负载的情况下(比如OPC同时处理10个订单),如果按照图6右侧的流程仍然不能满足响应时间的约束,那么还可以对消息传送的方式进行改变。根据场景7的要求,系统对于WebSite和OPC之间进行的消息进行了加密处理,考察图3中的效用树可以发现,场景7的优先级低于场景5,所以可以在负载情况下,暂时取消消息加密,当系统恢复正常运行时,再恢复原来的设置。对于上面三个自适应策略——流程调整、增加日志和取消加密,后两个策略可以看做是由第一个策略的实施而引起的。以下程序是OPC流程改变的自适应策略的XML描述。2.4系统负载、opc流程已经改进的测试本节将考察构件OPC在压力测试的情况下进行自适应调整的情况。对于场景4和5,按照如下方法生成测试用例:生成一个Servlet文档将其同WebSite一同部署,该文档生成m个线程,每个线程睡眠n秒内的随机时间后随机产生一个订单(主要是生成唯一ID的订单),然后将该订单通过JMS发送给OPC(m,n可以进行设置)。设定Admin每隔半分钟查询所有未处理订单,并尽快批准或拒绝订单。图7分为5个部分,显示了对OPC正常调用和4次压力测试的结果,结果分析如下:1)图7的第1部分展示了系统轻载情况下OPC的两次响应时间,从图中可以看出,如果每次(1分钟内)只有一个请求的话,那么OPC的响应时间为2分钟左右,满足场景4的要求。2)图7的第2部分测试1是对OPC进行压力测试后的情况。其中,测试用例中设定m=10,n=5,也就是说在(0,50)秒的范围内,OPC收到了10个调用请求(系统此时可以看做负载),而显然admin成为了整个流程的瓶颈。可以看到,处理第3个订单的调用已经超过了5分钟(300秒)。此时,中间件将会监测到不满足质量属性要求的情况发生,并根据自适应策略对系统进行调整。3)图7的第3部分测试2是OPC的流程按照自适应策略调整以后,用测试1中同样的测试用例进行测试的结果。为了观察流程改进以后的效果,测试2中的测试用例中每个线程睡眠的时间与测试1中完全相同(即,不再通过随机数产生睡眠时间)。因为流程改进的策略对总额500以下的订单直接处理,所以在测试2的10个测试中,明确标明了总额大于500的订单。可以看见,对于总额小于500的订单来讲,OPC可以直接对其进行处理,响应时间在2～5秒的范围内。当连续的两个总额大于500的订单,OPC的响应时间在2～3分钟之间,仍然满足场景5的要求。这说明该自适应调整策略是有效果的,经过调整以后的系统摆脱了无法满足质量属性要求的情况。4)图7的第4部分测试3仍然是OPC流程改进以后的测试,同样采用测试1的间隔时间。与测试2不同的是,这次的用例中有4次连续的总额大于500的调用。可以看见,在第4次总额超过500的调用时OPC的响应时间已经超过了5分钟(300秒)。因此,可以得到如下的结论:如果有连续4个总额大于500的调用,那么流程改进以后仍然不能满足场景5的要求(也就是说,admin在5分钟内只能连续处理4个订单)。同样也可以预见,只要10次调用中总额大于500的调用不连续出现4个,那么改进后的OPC流程就可以满足场景4。这说明该自适应调整策略具有局限性,该局限性无法在设计阶段设计自适应调整策略时发现,只能通过在运行时刻对系统进行实际调整并监测调整结果的时候才能发现。该局限性会反馈给设计人员,以供他们对自适应调整策略进行修改和完善。5)图7的第5部分测试4是针对策略4所做的测试,也就是在系统负载、OPC流程已经改进的情况下,利用HTTP来代替HTTPS。采用了与测试3中完全相同的用例,如图7所示,这一策略并没有达到预期的效果——第4