PL/SQL代码分析工具之创建高水平的设计

　　在这一 Codecheck 系列的早期文章中，我仔细分析了希望我的质量保证工具解决的问题：自动识别程序包中潜在的歧义超载。我还确定了可用来实施解决方案的技术 （DBMS_DESCRIBE 和 ALL_ARGUMENTS），并提出了一个测试计划的概要。现在，我可以相当简明扼要地说明 Codecheck 应当做什么：对于一个指定的程序包，或者也许是一个程序包内某个特定程序的名称，从 DBMS_DESCRIBE 和 ALL_ARGUMENTS 中获取关于这些程序的所有信息。然后读取所有的参数信息，并确定是否存在歧义超载。最后，通过 DBMS_OUTPUT 将结果发送至屏幕，同时也发送给 cc_ambig_ovld_results 表，以便可以使用 utPLSQL 来测试 Codecheck.

　　似乎够清楚了。这是否意味着下一步就可以开始编写代码了？不！在深入 IFs 和 LOOPs 之前，我需要收集足够多的信息来创建一个设计，以指导编程。本文中，我探索了如何开发这种设计，并演示了我如何小心地避免在开始时过多地纠缠于细节。

　　输入和输出

　　为我的实用工具创建设计从“输入什么，输出什么？”这一问题开始。这是程序的一个基本问题，因为输入（范围包括参数到底层表格）驱动程序的行为，而要检测一个程序的效果，没有其它方法比检查它的输出（从广义上定义的输出）更好。

　　Codecheck 的所有输入包括：

　　Codecheck 将检查的程序包或 package.program 的名称。在涉及到超载的地方，分析独立的过程或函数没有任何意义。

　　ALL_ARGUMENTS 和 DBMS_DESCRIBE 所提供的与程序相关的参数。

　　Codecheck 的所有输出包括：

　　将分析结果显示到屏幕的输出。是否存在歧义超载？如果存在，它们违反了什么规则？

　　写至 cc_ambig_ovld_results 的行，这些行包含相同的信息。

　　关于 Codecheck 体系结构与流程的最初的想法

　　给定这些输入和输出，我可以很快地提出 Codecheck 体系结构的概念（参见图 1）。该流程包含四个主要的阶段：