在线刊号(2278-8875)印刷版(2320-3765)
Poovizhi Panpa P 印度金奈Easwari工程学院研究生 |
有关文章载于Pubmed,谷歌学者 |
更多相关文章请访问国际电气、电子和仪器工程高级研究杂志
软件系统的关键属性,如可靠性和性能,应该在开发早期进行检查,因为它们可以控制重要的架构设计决策。已经开发了几种基于体系结构的可靠性分析方法来支持这项任务。然而,这些方法要么监督单个影响可靠性的因素,要么将它们硬编码到正式的模型中,这极大地限制了它们在基于组件的开发过程中支持体系结构设计的适用性。我们的方法,基于Palladio组件模型(PCM)在高度参数化的类uml模型中考虑软件系统的相关体系结构因素,允许对体系结构设计选项进行透明的评估。它在整个体系结构中对系统使用概要文件和执行环境的传播进行建模,并自动派生组件使用概要文件,这在大多数现有方法中都得到了监督。在分析之前,模型自动转换为正式的分析模型。使用一个实际的示例,我们演示了使用概要分析的支持。
关键字 |
基于组件的软件工程,离散时间马尔可夫链,帕拉迪奥组件模型(PCM),参数依赖,服务效果规范(SEFF),使用概要 |
介绍 |
软件系统越来越多地用于不同的领域,并处理许多时间和任务关键的工作,以支持业务和工业流程。分析软件系统属性的形式化技术不仅对功能属性有用,而且对额外的功能属性也有用,例如可靠性、性能、安全性等。可靠性可以非正式地定义为系统正确运行的时间的百分比。更正式地说,它被定义为软件系统在指定环境[1]中在指定时间内无故障运行的概率。预测系统的可靠性可以帮助避免实现不能满足用户需求的基于组件的软件架构,从而极大地节省基于糟糕架构的实现的修正成本。基于体系结构的可靠性预测可以用来评估系统设计的质量,也可以用来识别体系结构中的可靠性关键要素。这支持了开发过程早期的基本设计决策。 |
对于基于体系结构的软件可靠性分析,需要各个软件组件的可靠性规范。这些值最好由组件供应商提供。然而,供应商很难提供软件组件的可靠性,因为其价值不仅取决于组件的实现,还取决于供应商控制之外的一些其他因素,例如其使用概要文件、外部服务的可靠性和执行环境的可靠性。 |
许多现有的方法(例如,[2],[3])没有显式地建模系统使用概要文件对整个体系结构中的控制和数据流的影响。他们根据马尔可夫模型中的转换概率将系统使用概要隐式地编码为正式模型。由于模型牢固地绑定到特定的使用概要文件,因此需要重复大量的建模工作来评估不同使用概要文件的可靠性。此外,许多方法没有考虑执行环境对系统可靠性的影响。即使软件是完全无故障的,由于不可用的硬件资源和组件之间的通信网络链路故障,也可能发生故障。忽略这些因素会导致可靠性预测过于乐观(如[2],[3])。相反,考虑执行环境的方法(例如[4])没有提供建模应用程序级软件故障的方法,这也导致了对软件系统可靠性的有限看法。 |
本文试图通过一种基于体系结构的软件可靠性建模和预测的创新技术来弥补以往方法的不足,该技术明确地检查和集成了上述可靠性相关因素。该技术通过解析参数依赖关系在基于组件的软件体系结构中传播使用概要文件,并通过评估不同硬件可用性状态下的服务执行来说明执行环境。通过扩展具有可靠性预测功能的PCM, Palladio组件模型(PCM)[8]被用作基于组件的软件架构的面向设计的建模语言。提供了将pcm自动转换为马尔可夫链和对这些链进行空间有效评估的工具支持。 |
PCM支持多个开发人员角色,因为他们可以独立地将自己的部分贡献给体系结构模型。这降低了整个任务的复杂性。整个方法通过基于eclipse的工具[7]实现,该工具不仅支持建模过程和可靠性分析,还支持可靠性仿真和灵敏度分析,进一步方便了体系结构设计。本文的其余部分组织如下:第2节讨论了相关工作。第3节简要介绍了PCM中最重要的概念。第4节详细介绍了PCM实例的可靠性预测。第五节总结了我们的工作。 |
相关工作 |
软件可靠性工程[1]领域的开创性工作侧重于将系统视为黑盒的系统测试和可靠性增长模型。最近,许多基于体系结构的可靠性分析方法被提出,将系统视为软件组件的组合。随后,这些方法关于他们的建模影响因素的部件可靠性进行了检查。 |
系统使用概要可以根据系统调用的预期序列(包括它们的概率)和用于这些调用的输入参数值来描述,这些调用可能会影响整个系统控制流。为了对使用概要文件对系统可靠性的影响进行建模,必须对从用户到组件以及从组件到其他组件(外部调用)的输入传播进行建模。Goseva等人[3]指出,大多数方法依赖于组件之间转换概率的估计。张[2]提到,可以通过组装和部署组件并针对它们执行预期的使用概要来获得转换概率。然而,这需要软件架构师在架构设计期间设置整个系统,这通常是不希望也不可能的。 |
Wang等人[9]和Sharma等人[10]的当代方法扩展了张的工作,以支持各种建筑风格,并结合性能和可靠性分析。然而,他们信赖测试数据或软件架构师的洞察力来计算转换概率。Reussner et al.[11]的工作假设组件之间的转换概率是固定的;因此,如果系统级的使用概要文件不同,它的模型就不能重用。张等人。[6]着重于单个组件的可靠性,不包括对其他组件的调用。 |
已经提出了许多将执行环境的属性纳入软件可靠性模型的方法。Sharma等人[4]提供了一个软件性能模型,其中包括硬件可用性和硬件资源的不同状态,但忽略了使用概要文件传播和组件依赖关系。此外,该方法只计算硬件故障时成功请求的吞吐量,而不计算系统可靠性。Trivedi et al.[13]和Vilkomir et al.[14]的方法也是如此,他们设计了执行环境的复杂可用性模型,然而,没有将其与软件级别相关联,以估计整个系统的可靠性。 |
Popic et al.[15]考虑了网络连接的故障概率,但没有考虑其他硬件资源的故障概率。Sato和Trivedi[16]将通信系统服务的系统模型集成到资源可用性模型中。然而,它们不包括纯软件故障(不是由执行环境激活的),假设服务之间的固定转换概率,并且不建模服务的使用概要依赖关系。Yacoub等人[17]在他们的方法中包括通信链路可靠性,但忽略了硬件可用性。 |
一般来说,需要一种集成的建模和评估方法,允许使用不同的使用概要和执行环境对基于组件的软件系统进行系统可靠性预测。这是本文研究的重点。在接下来的部分中,我们将详细描述建模和评估方法。 |
用PCM建模可靠性 |
为了向读者简要介绍PCM的建模功能,我们首先讨论一个简单的示例(a节),然后根据所涉及的开发角色(B节)对建模功能进行更详细的叙述,最后介绍关于可靠性建模的PCM扩展(C节)。 |
答:示例 |
图1显示了一个PCM实例的例子,它模拟了一个简单的web服务器系统。它允许在数据库中存储传递给它的号码和名称的提交操作。 |
PCM由四个不同的开发人员角色独立交付的四种模型组成。角色可以独立于其他角色贡献其部分,通过平等分布的建模贡献来支持基于分布式组件的开发过程。PCM实现的角色是组件开发人员、软件架构师、系统部署人员和领域专家。 |
组件开发人员提供组件服务的抽象行为规范,从而形成组件服务行为模型。它们可以用失败概率注释服务的内部计算。此外,它们可以用参数依赖关系注释外部调用以及控制流构造。后者允许针对不同的系统级使用概要文件调整模型。软件架构师从存储库检索组件规范,并通过组件连接规范将它们组合到架构模型中。它们不处理组件内部,而是完全依赖组件开发人员提供的seff。系统部署人员定义一个标注了故障属性的资源环境,并将体系结构模型中的组件分配给资源,从而构建系统的部署模型。最后,领域专家根据随机调用序列和输入参数值指定系统级使用模型,然后可以在整个模型中自动传播。一旦指定了整个模型,就可以将其转换为马尔可夫模型进行可靠性预测 |
B. PCM架构建模能力 |
本节对各个pcm提供更详细的解释。有关包括元模型在内的完整摘要,请参阅[8]。 |
1)组件服务行为模型:PCM的这一部分包括组件提供的服务的行为规范,以及它们的输入参数和相关的组件参数。图1中的示例由两个SEFF模型组成,每个模型都对体系结构模型中使用的组件的单个提供服务进行建模。提交服务是Web组件提供的服务。提交SEFF指定高级控制和数据流如下:执行开始后,内部动作(stereotype << internal >>)表示提交操作,使用CPU资源类型。还有另一个原型<< call >>,可以用来表示对另一个组件的另一个服务的外部调用操作。另一个SEFF存储是数据库组件提供的服务。它也只包含一个内部操作,但是,服务迭代执行更复杂的搜索(使用CPU和HD资源类型),迭代次数受name参数的长度(或字节大小)的影响。 |
2)体系结构模型:通过各自的组件服务行为模型指定的组件由软件架构师连接到系统的体系结构模型中。此外,软件架构师定义系统边界,并确定应向系统用户或其他系统公开的所提供的接口。在图1中,体系结构模型通过所需和提供的存储服务连接Web和数据库组件,提交服务公开给外部系统用户。 |
3)部署模型(Deployment Model):部署模型对资源环境进行建模,即通过网络链路连接起来的一组资源容器(即计算节点)。每个资源容器可以包括许多建模的硬件资源(例如,CPU、硬盘、内存等)。资源具有属性,例如故障率或调度策略。系统部署人员指定具体的资源,而组件seff只引用抽象的资源类型。在为资源容器指定组件分配时,可以将资源需求定向到具体的资源。这种方法允许轻松地交换模型中的资源环境,而不需要调整组件规范。图1的资源环境由一个资源容器Server组成。资源容器提供CPU和HDD(硬盘驱动器)资源,这些资源可以被提交和存储组件使用,对应于指定的组件分配。 |
4)使用模型:使用模型由领域专家提供,它捕获系统的使用概要文件。它由一组表示不同用户类或系统用例的使用场景组成。每个场景都包含系统服务调用序列,包括用于表示每个用例或用户类中的现有变量的概率控制流构造。如果服务签名包含输入参数,领域专家可以描述它们的值和其他属性。他们可以使用随机表达式语言对具有任意概率分布的参数属性进行建模。图1包含一个简单的使用模型,由单个使用场景组成。每个系统用户到达系统,输入一系列提交服务的三次调用,然后离开系统。对于输入参数名的长度,即len(name),每次调用submit都有相同的概率分布:10、20或30。 |
我们的方法可用于支持单独评估单个使用场景,也可用于支持多个并行使用场景。在第二种情况下,必须说明刺激所有个别使用场景的可能性。然后,可靠性分析确定了由使用场景概率加权的整个系统可靠性。 |
C.建模可靠性的PCM扩展 |
在本节中,我们将描述纳入最初为性能建模和预测而设计的PCM元模型中的与可靠性相关的新概念。 |
在业务执行过程中,由于实现过程中出现故障,导致软件出现故障。SEFF中的PCM内部操作抽象了组件内部处理,并且可以用描述内部操作在执行期间失败概率的失败概率进行注释。任何内部操作的失败都被认为是系统故障的原因。组件开发人员可以在组件上使用统计测试、软件可靠性增长模型或代码覆盖率度量来估计各自的故障概率。 |
通信链路故障包括消息在传输过程中丢失或损坏,导致业务失败。尽管像TCP这样的传输协议提供了容错机制,但由于过载、链路物理损坏或其他原因,仍然可能发生故障。由于从系统部署人员的角度来看,这些故障在很大程度上是不可预测的,因此它们被视为软件故障,并且通信链路在PCM模型中用故障概率进行了注释。这些故障概率可以从类似系统的经验中定义,也可以通过在目标网络上运行测试来定义。 |
硬件不可用,将导致业务执行失败。硬件资源崩溃主要是由于磨损造成的。最终,出现故障的资源通常会被功能类似的新资源修复或替换。在PCM中,硬件资源用系统部署人员指定的平均故障时间(Mean Time To Failure, MTTF)和平均修复时间(Mean Time To Repair, MTTR)进行注释。硬件供应商经常在规范文档中提供MTTF值。系统部署人员可以根据经验改进这些值。 |
用PCM预测可靠性 |
预测过程如图2所示,以及前面的建模和后续的设计评估步骤。 |
A.解决参数依赖关系 |
组件开发人员通过服务效果规范指定其组件的高级行为。这些seff可以包含参数依赖项,以表示输入参数值对控制和数据流的影响。要解析整个PCM实例中的所有参数依赖关系,可以重用现有的PCM依赖求解器。从给定的使用场景开始,Dependency Solver递归遍历指定的seff,并按其方式解析所有参数依赖项。每个解析步骤都包括解析和解析具有任意概率分布的随机表达式、对具有不同数据类型的输入参数的引用以及不同类型的操作符。 |
B.确定物理系统状态的概率 |
物理系统状态由系统硬件资源的所有单独状态组成,这些状态在PCM资源环境中定义,并分配给资源容器。设R = {r1, r2,…, rn}是系统中资源的集合。每个资源ri由其MTTFi和MTTRi表征,有两种可能的状态OK和NA(不可用)。在我们的方法中,我们不直接使用指定的MTTFi和MTTRi值进行可靠性预测。相反,我们计算资源ri的稳态可用性Av: |
C.生成和评估马尔可夫模型 |
基于已解决的参数依赖关系和已知的物理系统状态的PCM,我们的方法以递归的方式生成和评估吸收离散时间马尔可夫链(dtmc),以预测系统可靠性。该算法有两个主要部分:首先,每个物理系统状态产生一个单独的DTMC并进行评估。其次,将所有单独的结果聚合以获得最终结果。 |
首先,每个行为规范B(使用场景)表示为操作{A1,A2,……,An}的线性序列,包括内部操作、调用操作、分支、循环和分支,具有嵌套的语义。在这个语义中,属于分支、循环或分支的整个行为块用一个具有嵌套行为的单个动作表示。 |
在向序列添加START和STOP动作之后,该规范被转换为DTMC,这样行为的每个动作都成为DTMC的一个状态。START动作变成初始DTMC状态;STOP动作为成功状态。此外,还引入了FAILURE状态来表示任何动作Ai都可能以fp(Ai)的概率失败。所得到的DTMC具有吸收性和无环性,如图3.7所示。整体行为的失效概率fp(B)是由初始状态达到failure状态的概率: |
由于算法的递归性质,可靠性评估是空间有效的。给定资源数量n,时间复杂度为O(2n),因为有2n个物理系统状态。 |
结论 |
本文提出了一种基于构件的软件体系结构的可靠性建模和预测方法。通过集成甚至很少包含的架构方面,如使用概要文件和执行环境,预测的准确性也得到了提高。该方法是作为Eclipse SDK中Palladio组件模型的扩展来实现的。PCM支持分布式的、基于组件的系统。通过软件仿真验证了预测结果。 |
该方法的主要缺点是可伸缩性。由于指数级的复杂性,该算法最多只能对大约20个资源有效。我们未来的工作之一就是解决这个可伸缩性问题。此外,离散时间马尔可夫链(dtmc)也不准确,因为它们假设每个状态之间有恒定的故障概率,这是不正确的。我们将使用连续时间马尔可夫链(CTMCs)来解决这个问题。另一个导致结果不准确的假设是,组件的软件故障概率被假定为彼此独立,而在实践中,软件组件的故障与其他组件相关。 |
参考文献 |
|