软件体系结构中的性能模型分析及验证

理论计算机科学电子笔记97（2004）219-239www.elsevier.com/locate/entcs工作中的三种性能模型：软件设计师的观点1Vittorio Cortellessa2Dipartimento diInformaticaUniversit`adiLAntinisca Di Marco3Dipartimento diInformaticaUniversit`adiLPaola Inverardi4Dipartimento diInformaticaUniversit`adiL摘要从生命周期的早期阶段开始，软件性能的验证是一个关键问题 复杂的软件系统设计。在目前的软件开发实践中，分配给该任务的时间和任务的百分比仍然太小，以避免性能错误，这些错误是后期的难以发现，也难以修复。这是由于上市时间短以及需要（开发团队通常缺乏）有效地完成早期性能验证的特殊技能。软件体系结构是一种系统抽象，可以支持系统性能的验证和预测分析。不同的符号/语言可用于表示性能观点下的软件架构。在本文中，我们专注于软件体系结构的性能问题，我们从软件设计师的角度分析了不同的性能模型符号。本文的目标是通过一个简单的案例研究，推测三个广泛使用的性能模型符号的描述能力及其在架构设计层面获得反馈的适用性。关键词：自动性能验证，软件体系结构，Petri网，广义随机Petri网，随机进程代数。1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2004.04.038220V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-2391介绍随着现代分布式软件系统的复杂性和规模的不断增长，对支持设计决策的工具的需求正在成为一个关键问题。独立于软件过程，早期设计阶段可能会严重影响软件开发和最终软件产品的质量。因此，早期阶段的不准确决策可能意味着昂贵的返工，可能涉及整个软件系统。软件开发团队常常不得不仅依靠自己的技能和经验在不同的功能等效的设计方案中做出决定。这种选择是由非功能因素驱动的，例如性能、可靠性和拓扑/经济约束。即使在非功能需求没有明确表达的软件系统中，这些属性的关键性也很高事实上，在基于组件的分布式软件系统中，诸如性能、可靠性、可维护性等属性决定了产品的质量和软件开发的成功。一方面，评估单个组件的质量的问题是一个活跃的研究领域，另一方面，即使它可以假设“良好的质量”的组件的组装软件系统的质量并不总是得到保证。因此，必须进一步调查，特别是在早期开发阶段，组件如何相互作用以及与环境的相互作用。将性能方法和工具应用于软件开发的兴趣非常高。为软件系统的性能评估建立精确模型所需的信息，例如硬件平台的详细信息，可能在软件生命周期的后期才可用。另一方面，现代软件系统日益增加的复杂性将性能焦点移到了生命周期的早期。软件体系结构（SA）是这种分析的自然候选者，最近出现了许多旨在对软件体系结构进行定量分析的工作[19，20，21，5，11，3，4]。从更广泛的角度来看，最近在[16]中强调了在架构级别集成非功能和功能需求分析在软件实践中，人们普遍认为，缺乏个性化的需求验证主要是由于软件工程师/架构师和质量保证专家之间的知识差距，而不是1本工作由MIUR公司的“SA HA RA”和“P rog e to S o ciet ` a dell'Infor m a zi one S P 4“提供支持。2 电子邮件地址：cortelle@di.univaq.it3 电子邮件地址：adimarco@di.univaq.it4电子邮件：inverard@di.univaq.itV. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219221基础问题。此外，短时间的上市要求使这种情况更加严重。在这种情况下，软件建模符号和工具可能在填补这一空白以及缩短性能验证时间方面发挥关键作用。目前，在软件系统的性能分析中，可以使用几种模型符号。这些模型符号分为两个主要类别：最初提出的表示实际系统（通常是硬件或制造系统）性能特征的符号（如嵌入式网络）[14];最初在软件规范领域提出的符号（如（随机）Petri网或过程代数），然后在整个性能域中导出[1，9，7]。在生命周期的早期，性能模型符号的选择仍然是开放的。从软件设计师的角度来看，上述选择之间可能存在相关差异。例如，虽然嵌入式网络显然离软件开发人员的知识很远，但过程代数（或Petri网）似乎更接近开发人员的观点。 然而，可以观察到，在过去的几年中，嵌入式网络构成了性能评估的最佳目标[4]，即使在软件模型仍然基于抽象交互组件的早期生命周期阶段。此外，“网络建模是一个自上而下的过程。其基本理念是首先确定系统的主要组成部分及其相互作用的方式，然后提供任何证明是必要的细节这表明了一个非常直观和自然的映射网络与早期的软件生命周期工件，如软件架构描述。另一方面，PA和PN具有在其建模中几乎免费导入性能分析的优点，从而以牺牲行为模型构造为代价使基于这些观察，本文所描述的研究源于我们的兴趣，调查的影响，性能模型符号可能对软件开发。最近在[17]中概述了缺乏这方面的研究。在这个程度上，我们认为在工作中的三个主要符号在一个简单的案例研究，即随机Petri网（QN），广义随机Petri网（GSPN），随机过程代数（SPA）。我们想回答的问题是：哪种符号可能更容易被软件设计师接受？在设计师技能和软件开发环境的哪些假设下，这是正确的？为了解决这些问题，我们讨论这些模型符号，通过建模和分析一个简单的案例研究，沿着两个维度：222V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-2391. 嵌入和管理绩效相关方面的充分性（例如，工作量）在设计架构层面;2. 易于建模、调整和修改架构方面（例如，组件的数量和类型），同时考虑到通过性能验证获得的可能反馈我们成立的团队实验比较所考虑的符号是由六个人组成的，他们对任何符号都没有深入的了解，但对软件工程原理相当熟悉。他们使用这三种工具来模拟案例研究，并报告了我们感兴趣的维度。本文的目标远不是性能模型的正式分类，而是基于案例研究建模和分析，从软件设计师的角度强调这种符号的适用性。即使从一个简单的案例研究的分析，相关的差异，可以设计性能模型之间沿草图尺寸。本文的组织如下：第2节介绍了实验框架，其中包括我们提出的架构设计过程和我们使用的案例研究，在第3节中，我们通过SPA，GSPN和QN建模案例研究，在第4节中，我们将架构设计过程应用于三个模型，并对所获得的结果进行评论，在第5节中，我们比较了三种符号，而最后的评论在第6节中给出。2实验框架在本节中，我们将介绍我们的实验框架的元素，即：（i）我们建议考虑性能问题的架构设计过程，以及（ii）我们应用该过程的案例研究2.1架构设计流程在图1中，我们展示了我们考虑的软件架构的设计过程，通过性能验证的反馈来丰富。在这个级别上，性能是在对将执行软件系统的硬件平台知之甚少的情况下估计的。因此，预期的性能反馈包括识别需要修改设计的主要步骤包括从软件系统的抽象描述中构建嵌入性能方面的软件体系结构模型。软件体系结构V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219223摘要描述软件架构（SPA、GSPN、QN）性能指数建筑反馈建模（（11，，2））绩效考核软件体系结构求精（（11，，22））指数分析检查点架构反馈性能指标软件架构（SPA、GSPN、QN）抽象描述包括一组感兴趣的索引（例如，组件吞吐量、平均队列长度）。从产出分析来看，可能会出现一些问题出口Fig. 1. 架构设计流程为了应对这些性能问题，可以提出一系列替代解决方案，这些解决方案构成了图1的体系结构反馈1.一、在体系结构级别，产生替代方案的技术可能会影响组件或组件之间的通信。我们感兴趣的技术是那些密切关注组件及其工作负载的技术，这些技术基本上可以分为三类：拆分、合并和复制。• 将一个重载组件拆分为两个或多个组件意味着将该组件提供的服务集分布到一组新引入的组件上。拆分该组成部分的方式取决于多个标准，包括运营概况。例如，我们假设组件提供三个服务，即s1，s2和s3，它们的操作概要5由元组（f1，f2，f3）表示，其中f1=f2+f3。在他的科学中，一个自然的替代方案可能会导致组件，一个只提供s1服务，另一个提供s2和s3服务。• 合并意味着将一个加载不足的组件提供的服务集分布到一组现有组件上。例如，让我们假设每个组件6的利用率在性能评估步骤中分析的指数中，并且让我们假设一个组件利用率低于某个阈值（例如，40%）。在这种情况下[5]对于这种特定情况，我们所说的操作概要是指服务调用频率的分布。6利用率是指组件繁忙的时间百分比。224V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239一种自然的替代方案可以是将该组件的服务分布在其利用率允许这种开销的其他组件• 复制一个组件通常意味着创建一个或多个相同组件的新实例。这种类型的技术可以在每次组件不能被拆分时使用，例如，因为它是最小组件（即，它只提供一种基本服务）或由于某些设计约束而强制软件结构。在图1中的检查点，考虑所有软件产品/过程需求，在备选方案中进行选择。在实践中，开发人员必须进行权衡分析，以便根据性能反馈决定是否以及如何改进架构图1的边缘上的数字标记指的是上面介绍的尺寸（即，适当性和容易性），并指出我们集中观察和比较三种模型符号的步骤剩下的步骤也可以从这些维度来考虑，但是对于本文的范围，我们更感兴趣的是设计者的观点，而不是性能评估者的观点。2.2案例研究：XML翻译器在本节中，我们将介绍我们的实验所基于的简单系统。我们考虑的软件系统被称为XML翻译器（XT）。它根据给定的XML模式从文本文档自动构建XML文档[24]。文本文档具有固定的结构，允许自动识别其特定部分，然后通过使用给定XML Schema中定义的XML标记来强调这些部分系统读取一个文本文档，并创建一个新的XML文件，该文件包含文本文档的信息内容，并根据所考虑的XML语法[23]和XML模式进行适当格式化。该系统通过迭代步骤构建新文件，其中识别有用信息并对其进行标记。多个用户可以同时连接到系统并请求其服务。从该系统的第一个描述中，我们可以识别两个不同的软件组件：• 一个StructureBuilder，它预处理文本文件，以创建符合XML语法规则的XML相关内容（即XML特殊字符）。 这一步的输出是一个新的文本文件，在语义上与前者等同，但在语法上不同。它还根据已建立的XML Schema创建一个空XML文件，即该文件仅包含V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219225加价申请标记改进 *返回标记StructureBuilder用户用户标记结构编码程序图二. XT系统图三. XT系统文件的结构• 一个标记器，通过使用启发式方法，将文本文档中的有用信息该组件对文档的XML版本迭代地工作未知的次数，直到它不可接受（即，它在某些启发式条件下确实强调了大部分有用信息）。XT系统的静态描述如图2所示，而其外部方面则通过图3中的UML序列图[22]进行定义，该图显示所有交互都是异步的。3XT系统建模在本节中，我们将介绍2.2节中介绍的案例研究（XT）的SPA、GSPN和QN模型。在每个模型描述的最后，我们报告了关于所使用的工具的具体考虑以及关于符号的一般想法。SPA和GSPN分别是进程代数（PA [15]）和Petri网（PN [18]）的扩展，它们引入了对软件系统的时序和概率方面进行PA和PN是用于对不同类型的系统的行为进行建模的众所周知的符号在下文中，我们假设读者熟悉PA，PN和QN基础知识[15，18，14]。在这三种模型中，我们使用了一组通用参数，这些参数被引入来表征性能方面。特别是• λ表示用户平均思考时间的倒数，即系统响应与后续用户之间的平均时间间隔226V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239规范系统行为哪里（用户|||用户|||User）|[enq1，到达]|（0，3）|[deq1]|StructureBuilder| [enq3]| 100%（0，3）|[deq2，enq2]|标记）process User：=（work，lambda）; enq1; arrival; Userendproc process processes_1（n，k）：= [n>0] ->（deq1;processes_1（n-1，k））[][n k] ->（enq1; node1（n+1，k））endproc进程队列2（n，k）：= [n>0] ->（deq 2;队列2（n-1，k））[][n k] ->（enq3; node2（n+1，k））[][n k] ->（enq2; node2（n+1，k））endprocprocess StructureBuilder：= deq1;（processing，mu1）; enq3;StructureBuilderendproc process Marker：= deq2;（markup，mu2）;（refinement，p）; enq2; Marker）[]（（backtousers，100000-p）; arrival; Marker））endprocendspec见图4。 XT系统的随机进程代数模型。请求;• mu1、mu 2分别是StructureBuilder和Marker组件的服务率• p对文档细化的概率进行建模（即第2.2节中的启发式条件）。请注意，mu1和mu2是软件系统的内在参数（即它们取决于软件组件的内部设计），而lambda则对用户类型进行建模，而p则是要处理的文档类型它们都具有相同的含义，与系统建模所因此，它们将被用作参考值，在第4节中配置我们的实验。3.1随机过程代数随机过程代数（SPA [12，2，10]）允许用速率标记过程动作，该速率可以表示时间值（即，动作执行的估计时间）或概率（即，动作执行的频率我们通过使用TIPP随机过程代数[9]对案例研究进行建模，TIPP随机过程代数 [ 9] 符 合 我 们 的 建 模 要 求 ， 并 得 到 稳 定 的 设 计 和 评 估 工 具 （ 即TIPPTool[13]）的支持。TIPPTool是一个免费下载的软件，允许编辑模型并进行定性和定量分析。这些任务由用户友好的GUI支持。V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219227XML转换器系统的TIPP规范如图所示四 、 它 包 括 两 个 过 程 ， 一 个 用 于 第 2.2 节 中 确 定 的 每 个 软 件 组 件 ， 即StructureBuilder过程和Marker过程。为了正确地对整个系统进行建模，我们引入了两个额外的过程，分别表示存储异步服务请求的缓冲器，它们分别指向StructureBuilder和Marker。外部用户由一个特殊的进程User建模，它为系统生成文本排版请求。每个进程的内部行为都使用标准的进程代数语义进行建模。流程操作由[]运算符非确定性地组成，并且每个操作可以用布尔表达式（例如，[n>0]）;动作排序由Wavelon运算符表示。我们有简单的动作（例如，ENQ 1）和额定动作，其速率可以用作它们的执 行 时 间 （ 例 如 ， （ 标 记 ， μ 2 ） ） 或 它 们 的 相 对 执 行 频 率 （ 例 如 ，（refinement，p））。执行时间直接从速率值的反相获得（例如，加价执行时间由1/mu 2给出）。同样的速率也可以用来将动作中的非确定性选择转换为随机性选择。例如，在图4中，细化和backtouser是评级动作，但由于它们被放置为两个非确定性选项的头部，它们的比率也给出了（除了标准的时间含义）每个选项的相对频率。换句话说，将使用p/ （ p+ （ 100000−p ） ） 频 率 （ 而 其 执 行 时 间 将 为 1/p ） ， 并 且 将 以（ 100000−p ） / （ p+ （ 100000−p ） ） 频 率 （ 而 其 执 行 时 间 将 为 1/100000−p）选择背景干扰器备选方案最后，整个系统的行为在图4的最上面的部分被指定，其中基本的系统进程是通过使用并行操作符组成的|||并且同步动作（例如，[enq1，到达]）。为了我们在图4中显示了一个有3个用户的系统配置TIPP工具特定注意事项选择p和100000−p的特殊情况是因为需要在两个备选方案上引入相对频率，几乎不会对它们的执行时间引入进一步的延迟。事实上，通过将p值的区间从10000到90000乘以10000，我们能够对具有可忽略延迟的不同随机分布进行建模。这篇文章与TIPP进程代数的语义密切相关。它可以通过使用不同的代数/工具来克服。例如，EMPAgrProcessAlgebra [7]允许将优先级和执行频率与即时操作（对应于TIPP代数的简单操作）相关联。228V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-2391P21P2i1P2 n... ......这t 1工作1 1 1Lambda。。。我不Lambda工作我 1 1。。。tnLambda工作;工作112221 1 1。。2。。2Q0P1用户1P2i-1。。用户iP2n-1用户n结构生成器1年q1标记SB1 。11 。M1M311预处理MU12deq1第二节21标记MU21 1Refinement返回112SB221M2p1-pQ21图五. XML翻译系统进程代数一般思想PA允许过程和架构组件之间的自然映射。这有助于软件设计人员描述软件架构。然而，为了量化组件的行为，PA规范需要更多关于组件内部行为的细节（就每个过程执行的操作而言），这些细节通常在开发过程的早期阶段是不可用的。关于组件交互，PA允许人们轻松地指定同步交互。为了在通信中引入非对称性，一些额外的结构（例如，进程），一个示例是对等待队列和队列上的调度策略进行建模的进程。从积极的方面来看，SPA允许使用与用于软件规范的符号相差不远的符号来规范性能模型，从而获得软件设计人员易于使用的特性3.2广义随机Petri网广义随机Petri网（GSPN [1]）扩展了PN模型的表示法，引入了几个特征，其中包括不确定行为的时间转移和随机分布。我们使用GSPN对XT系统进行建模，并使用HiQPN工具进行性能分析[6]。HiQPN是一个免费下载的软件，V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219229(likeTIPPTool用于SPA）允许模型定义和某些类型的分析，也由用户友好的GUI支持我们的XT系统的GSPN模型如图5所示。较低的阴影区域突出显示了对StructureBuilder和Marker组件进行建模的子网。较高的阴影区域表示向系统提供文本格式化请求的系统用户通用的第i个用户由两个位置组成：P2i-1表示繁忙用户（制定请求），P2i表示空闲用户（等待回复）。当用户忙碌时，两个令牌出现在P2i-1中;当工作i转换时触发时，一个令牌进入P2i以将用户移动到等待状态，并且一个令牌排队到Q1。Q1对StructureBuilder组件的等待队列进行建模.同样的逻辑也适用于StructureBuilder（Marker）组件，因为进入SB1（M1）的标记表示组件的空闲状态，而进入SB2（M2）的一对标记模拟其繁忙状态。StructureBuilder处理的服务请求排队到Q2，Q2对Marker组件的等待队列进行建模。由Marker处理的服务请求可以从相同的组件中细化（在Q2中排队），也可以作为已完成服务的回复（在Q0中排队）发送回用户。我们为每个对组件的服务执行进行建模的转换分配了一个时间属性。模型的 定 时 转 换 是 ： worki ， 第 i 个 用 户 正 在 格 式 化 文 本 ;preproc ，StructureBuilder组件处理请求;标记，标记组件处理重新标记。探索所有剩余的过渡都是即时的。一个概率选择规则被应用到输出M3的转换，以模拟参考和返回选项的相对频率。HiQPN工具特定注意事项由于我们的目的是考虑基本的建模符号，图5的模型已经使用最小的Petri网符号建立，该符号允许对与性能相关的特征进行建模，这些特征是不确定性行为上的定时转换和随机分布。然而，HiQPN工具允许以扩展的Petri网符号构建模型，例如有色GSPN和分层Petri网[6]。通过使用扩展符号，我们的模型的复杂性会降低，但这也意味着软件设计者需要更高的PN技能，而我们希望保持最低限度。然而，选择采用这种强大的PN工具（即，HiQPN）为将来考虑更复杂和要求更高的模型提供了可能性230V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239-向上Lambda用户见图6。 XT网络模型Petri网一般思想用基本的Petri网（PN），系统从功能的角度建模，使其难以识别模型中的组件。事实上，PN设施（地点，转换和to-kens）和软件组件之间没有直接映射，而是软件组件可以对应于Petri子网。PN表示法最初是为了对并发系统建模而创建的，因此它特别适合于对具有多个松散耦合组件的系统在高度交互的组件中，同步交互显然是建模的，而异步交互可能需要（对于进程代数）额外的结构。例如，一个简单的基于优先级的排队调度需要使用扩展的PN符号，如有色Petri网。至于PA，除了上述限制，PN的扩展（如GSPN）允许指定一个性能模型，其符号与用于软件规范的符号相差不远3.3排队网络嵌入式网络是一种众所周知的系统性能建模符号[14]。为了求解XT系统的QN模型，我们使用了平均值算法（MVA [14]），因为该模型是乘积形式的。我们的MVA实现将包含计算所需的所有参数（如用户数量、服务速率和QN拓扑）的文本文件作为输入，并将四个文本文件作为输出，每个文本文件分别包含性能指标的值：利用率、吞吐量、平均队列长度和响应时间。在图6中，我们展示了XT系统的嵌入式网络模型它非常接近图2中的描述。每个组件都被建模为一个排队的服务中心，而用户组被建模为一个无限服务器中心。定时属性以直接的方式分配给服务中心。概率选择规则被应用于从Marker服务中心输出的路径，以模拟参考结构编码程序pMU1MU2标记1-pV. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219231和"回到用户“的替代方案。MVA具体考虑因素我们只是想指出，通过MVA算法评估QN模型的可能性是由于我们的案例研究的简单性质，这导致了产品形式模型。网络一般思想物联网嵌入了组件和服务中心之间的直观映射。对于体系结构级别的软件建模，它们还提供了一种连接组件的直接方法，即通过服务中心之间的连接。当然，基于与服务中心相关联的队列，服务中心之间的通信都是异步的。由于队列是显式建模的，因此很容易引入不同的调度策略。当必须对同步交互进行建模时，QN会出现限制。在这些情况下，QN建模必须添加非典型特征，例如空长队列，并且它们的评估可能变得更加复杂。此外，QN不适合描述组件内部行为的细节，每个组件执行的动作。因此，在生命周期后期，当软件建模需要更多细节时，QN可能不足以支持软件设计，从而导致远离常见的软件符号。4工作中的模型：结果和评论在本节中，我们将架构设计过程（如图1所示）应用于XT系统，在第2.2节中进行了描述，并在第3节中进行了建模。这个实验的目的是比较三个考虑的符号嵌入来自性能验证的反馈的能力我们使用了两种不同的模型参数配置，在本节中，我们分别将其标识为7：• Fast StructureBuilder：lambda = 1. 5，μ 1 = 1。0，μ 2 = 0。5;• 快速标记：lambda = 0。5，μ 1 = 1。0，μ 2 = 1。五、对于这两种配置，我们假设其他软件系统代表XT系统的用户，这种假设允许如此低的值，7所有参数值均以文件/毫秒表示。232V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239的λ每种配置都已通过假设以下值的文档细化概率进行了评估：p∈ {0. 1、0.五，零。9}。比较了组成XT系统的各软件组件的平均队列长度（即等待处理的平均文档数）和吞吐量（即单位时间内处理的平均文档数）两个性能指标。我们研究指数趋势，同时增加XT用户的数量。我们要指出的是，模型评估过程的复杂性可能会明显地彼此不同，并且它们也可能在指数值中引入一些近似误差。在这个维度上比较模型符号超出了本文的范围，因为许多其他因素会进入画面（例如，产品形式、解决方案工具功能）。由于XT系统的低复杂性，已经经历了完全收敛的性能指标值所考虑的符号。结果值显示在以下部分中。观察结果的完全收敛验证了XT系统的三个模型，并评估了它们的语义等效性。快速结构生成器图7显示了Fast StructureBuilder配置的性能指标。这种情况下的结果分析直接考虑到标记组件的工作量过高。事实上，对于所有文档类型（用p建模），Marker吞吐量在用户数从2到5时饱和。请注意，在第2.1节中介绍的意义上，标记组件是最小的。因此，唯一合适的反馈替代方案包括复制组件本身。在架构设计过程的检查点（参见图1），我们假设开发人员选择通过复制Marker组件来细化架构。细化实现显然取决于模型符号（即SPA，GSPN，QN）。复制标记组件所需的修改如下所示，所有这些修改都需要复制标记等待队列。SPA -没有引入新的过程定义。唯一的修改涉及图4所示规范的行为部分，其中复制了由标记2和标记过程组成的这个子系统的新实例与现有实例并行运行，它还通过enq3操作与XT系统的其余部分并行运行。发送到子系统的服务请求现在以概率0路由到每个实例。5.V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219233Fast StructureBuilder（lambda=1.5 mu1=1.0 mu2=0.5）0.5 0.450.40.350.30.250.20.150.10.0500.9 0.80.70.60.50.40.30.20.101234567用户数量1 2 3 4 5 6 7用户数量0.550.50.450.40.350.30.250.20.150.10.0501234567用户数量876543210123456 7用户数量见图7。快速StructureBuilder性能指标。GSPN -为了模拟新的XT体系结构，必须复制由Q2位置和标记子网（即图5为了将这些子系统与系统的其余部分连接起来，必须在GSPN模型中引入一个新的位置（即P）和两个新的变迁（即T1和T2预处理转换现在进入新的位置P而不是Q2位置。T1和T2离开了地点P，每个都进入了地点Q2的一个实例.T1和T2是即时转换，我们将0的情况。5相对频率，以便为每个子系统实例建模相同的工作负载。QN -标记服务中心及其等待队列必须复制。离开StructureBuilder服务中心的路径输入0。每个标记实例的概率为5通过评估新模型获得了新结果（如图8所示）。通过快速分析，我们观察到任何Marker实例的吞吐量都有所下降，整个系统的性能有所提高，因为在考虑用户数量的值范围内没有出现明显的瓶颈。StructureBuilder组件显示出相当高的吞吐量，但仍远未饱和。我们判断这些结果令软件设计者满意，从而在检查点退出该过程。p=0.1p=0.5p=0.9使用StructureBuilderStructureBuilder的平均队列长度标记的放置标记的平均队列长度234V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239p=0.1p=0.5p=0.9Fast StructureBuilder-细化（lambda=1.5 mu 1 =1.0 mu 2 =0.5）0.80.750.70.650.60.550.50.450.40.350.30.250.20.150.10.050123456721.81.61.41.210.80.60.40.201 2 3 4 5 6 7用户数量43.532.521.510.501234567用户数量见图8。 Fast StructureBuilder细化的性能指标。快速标记图9显示了Fast Marker配置的性能指标即使在这里，StructureBuilder和Marker组件也会经历p极值的一些饱和现象（即，p = 0。对于前一个组分，p= 1，p = 0。第九个是后者）。在这种情况下，设计者可以认为XT行为是可接受的，因为对于所有中间p值，系统似乎表现得非常好，因此他/她退出架构设计过程。5总结：三种符号一瞥在本节中，我们将讨论从实验中吸取的教训在表1中，我们显示了从第3节中所考虑的符号的一般思想和实验报告中得出的结果当然，对结果的解释也考虑到了我们所使用的案例研究的局限性。事实上，案例研究提出了一些特殊的方面，如所有异步通信，小架构尺寸（即，组件数量有限），以及缺乏外部请求源/接收器（即，它是一个封闭的系统），这可能会促进一个符号与其他符号。在第1节中，我们将每个建模符号的功能设计为0.50.450.40.350.30.250.20.150.10.050用户数量1234567用户数量使用StructureBuilder标记的放置StructureBuilder的平均队列标记的平均队列长度V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）21923510.90.80.70.60.50.40.30.20.10快速标记器（λ =0.5 μ 1 =1.0 μ 2 =1.5）4 3.532.521.510.5012345671234567用户数量1.61.41.210.80.60.40.201234567用户数量765432101234567用户数量见图9。 快速标记器性能指标。符号容易性充足建模以调整大小SPA介质高介质GSPN介质低介质QN介质高高表1所考虑的符号描述和细化典型体系结构方面的能力以及嵌入和管理性能相关方面的充分性。在表1中，这两个宏观维度被确定为容易性和充分性。易用性分为建模的易用性和调整大小的易用性，前者考虑了提供初始模型及其细化版本（根据其拓扑结构）的困难，后者考虑了更改系统配置的困难。即改变组件实例的数量。 可扩展性是指模型嵌入和管理性能方面的能力，例如快递服务时间我们对这些尺寸使用粗粒度数值标度，只有三个有序值：低，中，高。易于建模，对于QN来说是中等的，因为尽管它们相当用户数量p=0.1p=0.5p=0.9使用StructureBuilder标记的放置StructureBuilder的平均队列标记的平均队列长度236V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219-239远离常用的设计符号，在软件生命周期的早期阶段，与架构概念有一种自然的对应关系。8建模的容易性对于SPA和GSPN也是中等的，即使它们可能被认为是软件设计者熟悉的符号。它们的缺点是，一旦系统架构变得更加复杂，模型的复杂性就会明显增加。广义随机Petri网的结果难以调整大小。例如，让我们考虑用户的问题。为了修改所考虑的用户的数量随机进程代数和随机网络很容易调整大小。在SPA中，并行组合新的用户（进程）实例是足够的，而在QN中，只需要改变一个输入参数。QN的性能指标，输入参数和路由概率被明确考虑和管理的复杂性是高的GSPN和SPA则不那么直接地提供性能信息。例如，在这两种情况下，为了表示路由概率，需要采用符号技巧：在PA中引入了两个额外的动作，而在GSPN中引入了一个额外的位置和两个立即转换总之，QN似乎在所有考虑的维度上表现得更好，尽管他们的性能分析能力。正如本节开头所描述的，这并不奇怪，因为我们在架构级别使用QN符号，在架构级别可以隐藏行为细节。QN的局限性在于它们与非线性模型的潜在距离。软件模型需要的行为细节（可能是组件内部的）越多，QN表示法支持的表达性就越缺乏。5.1考虑的维度与细化技术从性能分析中获得的反馈包括几个架构改进建议。在第2.1节中，我们设计了三种类型的建筑修饰，即：拆分、合并和复制。从实际的观点来看，所采用的符号的特性（即，易用性和充分性），并考虑到从性能结果中建议的架构改进让我们分别考虑这三种细化技术。每个组件拆分都会更改架构拓扑，因此使用8由于QN的异步性质，为了减轻我们的案例研究对QN建模的特殊适用性，该值没有设置得太高。V. Cortellessa等/ Electronic Notes in Theoretical Computer Science 97（2004）219237高值的建模容易性将适合于该目标。对于合并操作也可以进行类似的考虑，而很明显，具有高的易于调整大小的值的符号更好地支持组件复制。此外，任何细化技术的应用都会导致性能方面的变化，例如组件之间的工作负载分布和路由概率。因此，在任何情况下，符号的适当性最好是高的当然，这些考虑不能妨碍我们对所考虑的符号的分类事实上，在开始架构设计过程之前（图1），几乎无法预测将从性能结果中建议哪些类型的改进，因此建模符号的选择不能从这些考虑中排除。6结论本文中提出的实验的动机来自我们在过去几年中进行的软件性能和软件架构领域我们提出的三种性能模型符号（及其变体）已经被广泛使用。通常情况下，选择其中之一作为性能验证方法的基础，是由于几个因素不考虑用户/软件设计师的角度。我们的实验的目的是看看这些模型符号，以评估其适用性，以支持软件设计师。根据报告的结果，由于案例研究和实验设置的限制，我们不打算对该领域进行一般性评估相反，我们的目标是为这一方向的重大实验活动建立一个从软件设计者的角度来看，QN提供了最抽象/黑盒符号，从而允许更容易的反馈和模型理解，特别是在基于组件的软件开发框架中对于QN，问题仍然是从行为描述中轻松获得模型，特别是当需要一定程度的行为细节时。一旦设计者对行为描述使用相同的符号，这在其他两个模型中就不是问题了。因此，在需要性能和行为分析的情况下，PA和PN符号显然具有优势。如果我们假设一个标准的开发过程，使用标准的软件构件，如基于UML的构件，那么从行为描述中产生性能模型的代价对于所有三种符号都是可比的。在这种情况下，算法和工具的存在变得相关，这些算法和工具允许从标准软件工件创建性能模型，238V. Cortelle