图4-42政务模型库抽象层次

位置及相关信息。前者在模型库保存模型本体及相关信息，避免了维护模型文件位置正确的额外工作以及因位置信息错误而导致的模型调用问题；然而，这种策略指导下构建的模型库结构复杂、信息量大，不利于模型库的扩展，模型的任何扩展与修正都会导致模型库的改变。后一种方案将模型本体独立存储，避免了模型库对整个模型的数据存储；但需要建立严密的方案维护模型文件位置信息的正确性，以防止外部文件移动导致文件位置信息错误引起的模型调用失败。

总体而言，第二种模型存储方案具有较高的灵活性、易维护性和可扩展性，故将其作为政务模型库存储策略。此时，政务模型库以索引表和模型字典（嶋丄来存放模型位置及相关信息（模型元数据其中，前者保存模型的索引信息，可以方便对模型分类、査询和修改以及对模型的选择与组合，其表项作如下定义：

索引表表项:：:I模型10，模型名，模型类别，目标程序名，存取路径，

前驱模型10，调用权限丨后者存储关于模型的详细描述信息，其表项作如下定义：

模型字典表项:： 丨模型10，源程序名，功能说明，适用条件，实现语言，编译系统，模型输入，模型输出，开发者！

索引表中的前驱模型10体现了模型库的组织方式，便于模型间相互调用与组合，如图4-43所示。它既可以是单个模型10，也可以是多个模型10的析取或合取式。‘在并行环境下，前驱模型10可起到模型调度约束作用。例如，当模型船的前驱模型10值为“财2奶13”时，表明只有当从2和财3均被执行并得到输出后方能调用姑1；当模型时1的前驱模型丨0值为“\12丨1肥”时，表明只要当从2和站3至少有一个被执行并得到输出后，就能调用财1。显然，会有模型的前驱模型10值为空（见；!! ）。政务模型库索引表与模型字典均以关系型数据库的二维表存储，每个元组对应一个模型文件。