软件测试面向系统建模的模型集成[1]

软件测试面向系统建模的模型集成[1] 软件测试工具

关键字：系统建模 模型集成

　　使用模型就像找专家咨询来帮助解决问题。当问题既不寻常又少见，有必要寻求多方意见而综合考虑，这是对系统建模中模型集成的一个很通俗的解释。规范一些， 系统 是一些对象或部件如人、资源、概念或者过程的集合，以完成某些功能或者达到某个目标。 模型 是有关一个系统、理论或现象的一个概要性的描述，它阐明已知或可推出的性征以用于深入的研究。 在分析问题时，常需要创建一个或多个模型，特别是对于复杂的问题。多个模型的组织是模型集成所考虑的问题。但模型集成不仅仅囿于单纯地建立模型间的连接，它与系统建模过程紧密联系。关于模型集成的研究因领域人员对模型的理解而有所不同，尤其体现在运筹 / 管理科学和信息系统领域人员对此问题的认识上，实际表现为对模型与知识的区别。 从知识工程来看，知识可定义为一种模式 (pattern) ，而模型是一种特殊形式的模式。知识表达可以是专家系统知识库中的逻辑形式，亦可以是各种分析形式的表达。从其他领域，特别是运筹与管理领域，则持相反的观点，认为模式是一种特殊形式的模型 [1] 。关于知识与模型的争论始终持续着，这也反映在决策支持系统的发展上。 DSS 最初是基于模型的，有优化模型、仿真模型、启发式模型、其它的描述型模型、预测模型等等。模型的增多，就有一个管理以提高效率的问题。 20 世纪 70 年代中期数据库技术发展开始成熟，人们借鉴数据管理上的方法实现模型管理。由于数学模型的结构不能显性表达，简单套用数据管理的方法实现模型管理有很大的局限，因为建模是复杂的、迭代的过程，于是发展了支持建模过程的模型管理。建模过程包括 识别问题、创建、实现、验证、求解、分析和维护模型等任务， 支持建模过程即提供相应的工具，这些工具有任务表达的语言并能执行完成任务的操作。而具体实现时“模型集成”被视为创建模型的一个目标。

　　关于模型管理的一些代表性的综述，较早的有 Elam 和 Lee 主编的 1986 年在 Decision Support Systems 第 2 卷第 1 期对过去 6 、 7 年研究的思考和今后研究的展望 [2] ，之后有 Shetty, Bhargava 和 Krishnan 等主编的 Annals of Operations Research1992 年的一期专集 [3] ， Blanning 主编的 1993 年 Decision Support Systems 的一期专集 [4] ，正是 6 、 7 年前展望的一些成果。最新的一篇综述由 Krishnan 和 Chari 所著， 2000 年在网络杂志 Interactive Transactions of ORMS 上发表 [5] 。 93-94 年间涌现了大批有关模型管理的文献，体现了该领域的丰富成果。而模型集成逐渐不再视为模型管理的一支，它已涵盖模型创建任务中的所有问题。但自那以后直到 2000 年的 6 、 7 年间很少有深刻或全面的文章，研究似乎处于低潮。实际上，深入的研究走向将理论研究成果应用于现实的复杂性，涌现了一批面向特定领域或问题的建模支持软件。另一方面，互联网技术自 90 年代以来的迅猛发展为模型集成与管理带来了新的机遇和挑战，如分布式技术。

　　本文集中讨论模型集成，它源于考虑这样的问题：面对新问题没有现成模型时，系统建模者如何利用已有资源(模型和经验)而构建一个关于问题的描述模型，以深入探索?

　　• 模型集成与集成式建模环境

　　• 模型表达

　　在过去的十几年间模型管理的主要成就体现在模型表达，有三个主要流派：结构建模、逻辑建模和图建模。结构建模 (structured modeling) 是一种基于图论的标准的描述型模板，它扩充了数据库技术中的语义数据模型以描述数学模型中的复杂性 [6] 。结构建模允许用户在不同的抽象层面上以图形、文本或代数形式察看模型。逻辑建模 (logic modeling) 是人工智能和数学规划的一种结合，主要是应用一阶逻辑表达模型知识 [7] 。图建模 (graph grammars) 将模型比喻为图，从而提供了一种形象化的模型表达方式 [8] 。这种描述和操纵模型的方式在使用可视化程序设计技术时特别有利于模型的实现。这三种模型表达方式相互借鉴，相互融合也是模型表达重要的研究领域 [9,10] 。

　　• 集成方式

　　模型集成有两类广泛的议题，即结构 (scheme) 集成和过程 (process ) 或求解器的集成 [11] 。这是从技术角度根据传统的程序设计语言考虑的。结构集成指合并两个模型的体系以创立一个新模型。过程集成指求解过程的连接;简单地可理解为一个模型的输入是另一个模型的输出，问题是求解过程的组织序列是否可以推理出来。这里值得研究的问题很多，如化解冲突、模型表达、求解控制等。这时模型不再被视为黑盒子，而是玻璃盒子。允许访问模型的全部结构的设计是极为复杂的。目前有关研究主要在化解冲突和模型表达上。给定模型结构变化的范围，人们怎样才能判定集成的模型是有效的?在这方面最著名的工作是 Geoffrion 的结构建模。文 [11] 则是过程集成方面的先驱性的工作，其中也讨论了从组织视角和实现视角等方面的考察。当一个组织有模型集成的动机时一般立足于战略性建模，因为有效的战略规划需要集成有关特定功能和操作的各种模型，如后勤管理系统中的复杂操作。而实现视角则关注于面向对象的集成式建模环境。不过目前大多数的理论研究集中于技术角度。

　　Geoffrion 从结构建模的角度对应于结构 / 过程集成对模型集成方式作了一种划分：纵深 (deep) 集成和功能 (functional) 集成 [12] 。纵深集成合成两个以上的模型以创建一个新的模型;新模型采用同样的表达方式。功能集成并不产生同样表达方式的新模型。通过叠加一个计算议程而协调模型的运算，议程规定了如何实现功能集成。典型的如指定某些已有模型的输出是另外一些模型的输入但需要明确模型运算的顺序。

　　区分这两种集成很重要，更重要的是辨明什么需要集成。 Geoffrion 解释了四种层次的模型抽象：模型实例 (instance), 模型类 (class), 模型或问题模板 (paradigm) 和模型领域 (tradition) [13] 。如一个传统的运输模型可视为 Hitchcock -Koopmans 运输模型类的一个实例，后者又是运筹 / 管理领域的网络流建模问题;其他一些相关的建模领域可能包括数据库管理和人工智能。以下为 10 种可能的集成类型(其中两个指两个或两个以上)：

　　• 两个建模领域的接合;

　　• 一个建模领域中两个问题的接合;

　　• 不同建模领域中两个问题的接合;

　　• 同一领域同一问题的两个模型类的接合;

　　• 同一领域不同问题的两个模型类的接合;

　　• 不同领域和问题的两个模型类的接合;

原文转自：http://www.ltesting.net