为PLSQL构建代码分析实用工具.doc

《为PLSQL构建代码分析实用工具.doc》由会员分享，可在线阅读，更多相关《为PLSQL构建代码分析实用工具.doc（16页珍藏版）》请在金锄头文库上搜索。

1、为PL/SQL构建代码分析实用工具（一）作者：Steven Feuerstein 来源：OTN在这共有 8 个部分组成的系列中， Steven Feuerstein PL/SQL 语言方面的世界顶尖专家（自 2001 年始就是 OTN 成员），解释了他如何创建 Codecheck 一个 PL/SQL 实用工具，依靠数据字典中的信息来分析歧义超载包。Steven Feuerstein 是 Oracle PL/SQL 语言方面的世界顶尖的专家。他编著或者合著了九本关于 PL/SQL 的书，包括 Oracle PL/SQL 编程，第三版 ，和 Oracle PL/SQL 最佳应用 （ OReilly

2、 & Associates 出版社， http:/ ）。他是 Quest Software 的高级技术顾问，从 1980 年就开始开发软件， 1987 至 1992 年间为 Oracle 公司工作。他也是 Crossroads 基金的前董事会主席，这一基金为芝加哥地区争取社会、种族和经济平等的社区组织 ( www.CrossroadsFund.org ) 提供资助。下载 codecheck.zip第 1 部分：构建一个代码分析实用工具，并在第一次就正确执行 在这个最初的步骤中， Steven 讨论了在创建一个实用工具时要涉及到的内容，如何执行所需的分析，以及如何将分析的结果转换成有用的形式。

3、第 2 部分：开始启动，从测试开始 Steven 说明了如何通过在开始编写代码之前建立测试计划来节省时间。 第 3 部分：创建高水平的设计 准备开始编程了吗？别着急：您需要先进行设计。 第 4 部分：实施 Codecheck ： 构建阶段 该逐步说明您的代码程序包了。 第 5 部分：使参数信息更加灵活 Steven 详细说明了如何消除多层次和以字符串为索引的集合的复杂性。 第 6 部分：构造服务提供程序：具有专门功能的程序包 Codecheck 软件层次结构的低端（相对小型、专门化的单元）一览。 第 7 部分：构造服务提供程序：创建一个通用的报告程序包 了解在您创建 Codecheck 的报告

4、程序包时，如何利用动态 WHERE 子句来优化代码，以及如何为难于操作但却有用的过程添加一个用户友好的包装。 2004 年 1 月在 OTN 上查找最后的 第 8 部分 。为 PL/SQL 构建代码分析实用工具（二）作者：Steven Feuerstein 来源：OTN第一部分：构建一个代码分析实用程序以确保代码首次运行时的流畅和正确 构建实用程序验证代码质量的内部详情许多开发人员和开发经理所面对的一个突出问题就是找到改进代码质量的方法。于是我决定以一种独特的方式来解决这一难题。在随后的几个月中，我将在 OTN 上发布一系列文章说明我是如何构建 Codecheck 的。 Codecheck 是

5、依赖数据字典中的信息，执行重要任务（即分析程序包以检测这些程序包是否包含重载多义性）的一个 PL/SQL 程序包。由于我采用的是自顶而下的设计方法并运用了许多我在 Oracle PL/SQL 最佳实战技巧 中推荐的最佳实战技巧，因此不想只是简单地呈现结果，而更愿意邀请您和我一同演练这一过程。 深入了解这一实用程序要花费一些时间，因为我想借这个机会实际经历一下开发生命周期中的几个阶段。在以后的几个月中，我将进行以下工作： 确定我希望 Codecheck 解决的问题并明确需求。 给出验证实用程序正确运行的测试案例。 研究有助于解决问题的相关技术。 给出实用程序的整体设计（结果发现测试要求会对我的设

6、计产生影响）。 逐步细化以采用易于编写、理解和部署的代码块来构建解决方案。 利用 utPLSQL 单元测试框架自动对实用程序进行复杂的回归测试。 通过对 Codecheck 及其相关概念的学习，您将了解到 Oracle PL/SQL 最新、最好的一些特性，如多层集合。此外，我还将提供一套平台，您可以在该平台上构建和添加自己的 QA 检查，例如检查参数是否太多或太少、查找所有程序包都要用到的程序，并确保代码符合命名规则。也许亲身演练的最大好处在于有机会看到实际运用的一些最佳实战技巧，这可能是学习如何使用这些技巧最简单的方法。 我需要声明一点：我已经完成了 Codecheck 的一个运行版本。我计

7、划一边写下该实用程序的构造经过，一边对其进行改进。因此，该系列每一篇文章的下载都将包含一个 Codecheck (codecheck.zip) 。请随意下载并立即使用。如果您在调试的过程中遇到什么问题，或是有一些改进意见，请发送至 。 确定问题：程序包中的重载多义性 为了写出高质量的程序而顾及到方方面面会令人发疯。因此，我打算集中到几个典型的问题，以免屡屡受挫而不得不放弃创建 Codecheck 的初衷。编写和成功编译包含不可调用程序的 PL/SQL 程序包是极有可能的，而这并没有多大的意义，不是吗？让我们来看看这一奇怪的情形是怎样出现的。 Oracle PL/SQL 支持负载，也就是所谓的

8、 静态多态性 。这就意味着，您能在任何声明段或程序包中用相同的名称定义两个或多个程序，只要这些程序区别显著（通常是参数列表不同），编译器能够辨别您想要使用哪个程序。重载对于提高代码的可用性来说是一项有用的技术。然而，它也会带来一些问题，特别是如果参数列表很长，其中的参数有些有缺省值，有些没有，则尤其如此。 为了向您证实开发人员的确会面临这一问题，我挑选了几个可能会出错的例子，这些例子是以下面所示的程序包说明开头的： CREATE OR REPLACE PACKAGE salespkg IS PROCEDURE calc_total (zone_in IN VARCHAR2); PROCEDUR

9、E calc_total (reg_in IN VARCHAR2); END salespkg; / 这一部分在编译时不会有任何问题，正如其程序体一样。其中有两段重载程序，都命名为 calc_total 。其中之一接收一个地段，例如 ZONE 15 ，然后计算该地段的总销售额。而第二个程序则接收一个区域，例如 SOUTHWEST ，然后计算该区域的总销售额。但当我试图调用其中某个程序，却出现一个错误。 SQL exec salespkg.calc_total (ZONE 15) BEGIN salespkg.calc_total (ZONE 15); END; * ERROR at line

10、1: ORA-06550:line 1, column 7: PLS-00307:too many declarations of CALC_TOTAL match this call 该错误消息明确地指出了这一问题： Too many declarations of CALC_TOTAL match this call. （有多个 CALC_TOTAL 的声明与该调用相匹配）。您可以看到，计算机并不是十分的聪明。您我都可以看出 ZONE 15 是一个地段；难道 PL/SQL 编译器就不能识别出这是 地段 的 calc_total 吗（即带有 zone_in 参数的重载）？不幸的是，编译器并不

11、是这样工作的。 ZONE 15 是字符串的字面意义，编译器无法分析。编译器无法知道应该使用哪段程序，然后就甩手不管了。 我们该如何解决这一问题呢？在这种特定情况下，我可以通过使用指定的参数值来消除多义性： BEGIN salespkg.calc_total (zone_in = ZONE 15); END; 在这个实例，我想要告诉编译器使用特定的参数 ( zone_in ) 。因为这两个重载程序中，只有一个程序的参数名与之相符，这样编译器就知道该调用这两个中的哪一个了。尽管如此， 不得不 使用参数名引用来调用一个过程或一个函数还是令人难以接受。这明显是一个糟糕的设计 而且会越来越糟。考虑下面的

12、程序包说明： CREATE OR REPLACE PACKAGE salespkg IS PROCEDURE calc_total (zone_in IN VARCHAR2); PROCEDURE calc_total (zone_in IN CHAR); END salespkg; / 同样，这个程序包在编译时也不会有任何问题。但现在又面临另一种情况：无法调用这些过程中的任意一个。他们共享程序名和参数名。唯一的区别就是数据类型。 VARCHAR2 当然不同于 CHAR ，因此编译器会让您轻松过关。但不幸地是，这两种数据类型的差异性还不够大，这将导致在真正试图使用代码的时侯出现难题。考虑下面的

13、一段代码： BEGIN salespkg.calc_total (ZONE15); END; ZONE 15 是固定长还是可变长？ PL/SQL 文档中说道 All string literals except the null string () have datatype CHAR , （所有非空串的字符串文字都是 CHAR 型）但是编译器并没有意识到这个问题。非常奇怪，即使向程序传送了一个显式声明为固定长度的字符串，仍然会出现问题。 SQL DECLARE 2 l _zone CHAR(6) := ZONE15; 3 BEGIN 4 salespkg.calc_total (l_zone

14、); 5 END; 6 / salespkg.calc_total (l_zone); * ERROR at line 4: PLS-00307:too many declarations of CALC_TOTAL match this call 如您所见，确实可以定义这样一个程序包重载，即它可以顺利通过编译，但要么不可用，要么只能通过 非自然行为 使用，例如强制使用参数名引用。 我将采用什么样的解决方案呢？ 为了识别这些重载问题，我产生如下的想法：也许我可以构建一个实用程序 自动 扫描程序包，检查所有可能的有效程序调用置换，并提醒我注意那些多义重载。我能够作到这一点吗？看起来我应该要能够将

15、程序包定义解析为各段程序，同时解析出每个程序的参数列表。我应该能够取出这些参数的数据类型和缺省值。我如何才能获得这些信息呢？遗憾的是，我对 PL/SQL 解析器没有 API 级的访问权限，特别是不能从 PL/SQL 自身内部来进行访问。而且我压根不想 考虑 自己编写一个解析器。那么一个积极的（深受困扰的）实用程序构造者会如何去做呢？他会查找可以替代的方法。 还有没有其他的方法可以从程序中提取这一信息呢？我想起每当我编译一个 PL/SQL 程序， Oracle 数据库就会对源代码进行解析并将其装载到数据字典中。然后就可以提供各种数据字典视图给出对所存储代码的不同描述。 ALL_SOURCE 揭示了源代码。 ALL_DEPENDENCIES 显示各个对象之间的依赖性。 ALL_OBJECTS 告诉我哪个程序是 INVALID 。也许有某个数据字典视图有助于解决这一问题。我该如何找到它呢？数据字典中有很多视图，而且这些视图都非常晦涩。 为了能对此有所帮助，我构建了一个名为 dd_view_scan 的实用程序，该程序可以找到符合需要的那些视图。使用 d