Page 201 - 《软件学报》2026年第5期
P. 201

2080                                                       软件学报  2026  年第  37  卷第  5  期


                 GEN  值, 并对类按照   GEN  值进行降序排列; (3) 获取测试用例; (4) 执行测试用例以获取执行轨迹; (5) 分析执行轨
                 迹以获取方法调用关系及类集, 进而对类集进行扩充, 并对结果进行优化.
                    从表  5  可知, 在  8  个实验系统上, CDAG  均可以在    35.5 min  内完成关键类识别任务. CDAG      在  jEdit 系统上耗
                 时最多, 约  35.46 min; 在  wro4j 系统上耗时最少, 仅用了约    3.53 min. 此外, 因为我们生成的测试用例数量比较大,
                 执行一个测试用例的耗时平均在            22.98 s. 为了提高实验的效率, 测试用例的执行是由实验室的               10  位硕士生在同
                 一时间段内共同完成的. 换言之, 表          5  中  (4) 这个部分的耗时是这    10  个硕士生中耗时最多的那个学生的用时. 在
                 表  5  中, PDFBox  和  wro4j 第  (3) 部分的耗时为  0, 这主要是因为它们是非   GUI 软件, 我们使用了源码仓库中自带
                 的测试脚本, 这些脚本的执行无需          10  名硕士生的参与. 此外, 构建网络时我们用的是            DWM  这种赋权方式.
                    在实验过程中我们发现, 相对于软件的静态分析而言, 软件的动态分析是很耗时间的, 为了识别                             jEdit (仅包含
                 1 091  个类) 中的关键类, CDAG  就已经耗时约      35.46 min. 若系统规模更大, 功能更复杂, CDAG      识别其中的关键类
                 将耗时更多. 但是相对于某个软件的整个维护阶段而言, 这点时间消耗还是可以接受的. 此外, 我们还可以在系统
                 上线前将获取执行轨迹的脚本嵌入其中, 这样便可在系统运行时收集执行轨迹, 从而跳过“获取测试用例”和“执行
                 测试用例”这两个最为耗时的环节, 大幅节省方法运行的时间.

                                           表 5 CDAG   在各实验系统上的时间消耗 (s)

                   耗时部分       argoUML     jEdit   jHotDraw   jMeter    Mars    Maze    PDFBox     wro4j
                     (1)        37.3      43.4      17.3      12.4     40.2     1.1      28.5     13.2
                     (2)        22.8     112.4      21.8      2.9      72.7     0.3     183.8     24.3
                     (3)       1 028.7   1 623.1   819.1     1 664.8   945.3   648.6      0        0
                     (4)        282       324       210       225      528      108     299.5     169.3
                     (5)        67.2      24.8      9.1       9.4      387.7    24.5    1 440.3   4.99
                    总耗时        1 438.0   2 127.7   1 077.3   1 914.5  1 973.9  782.5    1 952.1   211.79

                    根据对   CDAG  在实验系统上的时间消耗的分析, 我们可以得出结论: CDAG                 在运行效率方面是可以接受的.

                  2.5   有效性分析
                    本节从构造有效性、内部有效性和外部有效性                 3  个方面讨论实验所得结果的有效性.
                    (1) 构造有效性
                    构造有效性主要关注实验中使用的指标是否准确度量了想要度量的概念. 本文使用                            GEN  评价类的重要性, 并
                 使用  Recall 评价方法的性能. 其中, GEN    从软件结构角度评价类的重要性; Recall 是同类工作中普遍采用的评价指
                 标, 主要用于度量软件中被成功识别的关键类的比例. 为了保障                   GEN  和  Recall 值计算的准确性, 减少构造有效性
                 威胁, 我们对所编写的代码进行了充分的测试.
                    (2) 内部有效性
                    内部有效性主要关注实验过程中一些处理方式对结果的影响. 在第                       1.3  节中, 对于一些类节点由于具有相同
                 的重要性而无法准确排序的问题, 我们采用了“求均值位置”的方式, 这实际上求的是一个概率意义上的期望位置.
                 当然此处也可以采用随机确定位置的方式, 即: 在具有相同重要性的几个类节点中, 随机选一个作为它们中的第
                 1  个, 再在剩余的中随机选一个作为它们中的第             2  个, 以此类推. 但是这会引入一定的随机性, 导致求得的              Recall
                 值在两次独立的运行中结果值不同. 即使运行               1 000  次求均值, 也无法绝对避免两个独立的         1 000  次的均值具有不
                 同结果的情况. 为了消除这种随机性, 我们采用了“求均值位置”的方式.
                    (3) 外部有效性
                    外部有效性主要关注结果的可扩展性. 本文仅使用了                  8  个  Java 开发的开源项目作为实验对象. 因此, 本文实
                 验得出的结论可能无法直接推广到其他非               Java 系统或闭源系统. 但是这      8  个系统广泛应用在关键类识别研究中,
                 它们来自不同的领域、规模各异, 具有一定的多样性和代表性, 在一定程度上可以减少这种有效性威胁. 实际上,
                 这种有效性威胁普遍存在于实证研究中. 在未来工作中, 我们计划将本研究扩展到闭源的                          Java 系统以及非   Java 系统.
   196   197   198   199   200   201   202   203   204   205   206