基于NX CheckMate检测项结构探析.docVIP

基于NX CheckMate检测项结构探析 　　摘 要:检测项是NX Validation application的重要元素,负责具体实现基于需求的模型检查功能。但现有的检测项采用过程式架构,无法灵活应对变化。本文从Check-Mate用户的角度分析了检测项现有架构的不足之处,试图提出一种面向对象的检测项设计思想。并通过一个简单的实例,验证重构检测项的可行性。 　　关键词:检测项 需求 过程式架构 OOAD 　　中图分类号:TP391.72 文献标识码:A 文章编号:1007-9416(2010)11-0106-02 　　 　　1 前言 　　Check-Mate是集成于Siemens PLM Software NX中的产品模型验证机制。该工具包含的通用检查规则可以帮助企业有效提高产品模型数据质量,降低产品设计成本,提高设计效率。 　　检测项是Check-Mate 模块中的检测项,承担具体的检测任务。检测项的外在表现形式是开发人员根据国家标准,行业规范,企业准则等需求,采用面向对象的KF (Knowledge Fusion)语言编写的类。该类继承了ug_base_checker基类,实现了do_check,do_doc等功能。该类被存储在DFA 文件中。当该检测项被加载到NX后,可以由Check-Mate 驱动,针对具体的数据文件进行检测。 　　Check-Mate检测项具有极好的扩展性。这些检测项加载到NX后,可在Check-Mate中由客户定制规则参数。此外,检测项采用KF语言编写,结构简单,代码开源。只要具备一定KF语言基础,也可以以已有的检测项作为模板,编写更加符合公司需求的检测项。 　　 　　2 检测项当前的结构 　　2.1 类图 　　当前检测项的典型结构图如图1所示。 　　根据类示意图,我们了解到下列事实:(1)每一个具体的检测项,都继承了ug_base_checker这个基础类。(2)视需要继承某些methods_mixin class,调用其中的公用方法。(3)检测项覆盖某些属性。添加一些参数,这些参数可在运行时赋值。(4)检测项根据需要调用函数库中的API,实现每一条规则的检测方法。(5)检测项覆盖ug_base_checker中的do_check。在这个属性中编写检测逻辑,调用每个检测规则的方法。并将检测结果记录到part中。 　　2.2 当前结构解析 　　我们可以看到,每个检测项能完成一个或几个相关联的规则组成的需求的检测。其优点是结构简单,一个检测项就对应一条需求,检测过程清楚,因为有参数,对用户而言,具有一定的灵活性。 　　但是,因为检测结构被绑定在检测项中,缺乏更深层次的灵活性。当需求发生较大变动时,用户极有可能无法通过参数的简单配置就能满足新的需求。除了动手修改源文件外,别无他法。这对不熟悉KF语言的用户而言,是一个挑战。此外,各个检测项彼此独立,相似的逻辑无法复用。 　　用面向对象的分析与设计(OOAD)的观点来看,当前的检测项违背了如下原则: 　　2.2.1 单一职责 　　为了满足当前的某一需求,设计者将需求解析为多条规则(rule)。但把这些rule的检测放在一个检测项中,这导致检测功能过于庞杂,功能间的耦合度过高,维护麻烦,复用不可能,也缺乏灵活性。 　　2.2.2 开放封闭原则 　　因为检测项是结构化的,当需求有任何变更时,都需要进入源代码层,对检测项做相应修改,甚至要把整个程序推倒重来。这不但耗时费力,修改不当还会导致两个后果,一是原有的功能可能会衰退,所有的用例(use case)都要重新设计并测试。二是无法判断这里的改动会否导致其他检测项功能异常。 　　面向对象的编程思想要求结构对于扩展是开放的,对于更改是封闭的。也就是说,具有良好设计的检测项,面对需求变化,只需要增加新的代码,而无需改动原有代码,既能保持整体结构的稳定又可满足新的需求。使变化中的检测项具有一定的适应性和灵活性。 　　2.2.3 依赖倒置原则 　　当前的检测项过于依赖细节,和底层的Function纠结在一起,耦合过度。就像一台由电阻,三极管,电路板等元件焊接在一起的收音机,出现任何故障都可能涉及其他部件,各个部件相互依赖,难以维护。现代的面向对象的设计要求针对接口编程,高层不应该依赖底层,两者都应该依赖抽象；抽象不应该依赖细节,细节应该依赖抽象。根据这种原则设计的检测项,像一台功能复杂的电视机,具有标准的插槽和配件。CPU或内存坏了,换一个能插入接口中的新配件即可,而无需检查整个线路。 　　综上所述,现有的检测项还是面向过程的结构,直观高效,但是对需求变动的适应性不强,耦合过于紧密,没能发挥面向对象的KF语言的优势。而Check-Mate的检测项是直接面对需求的,需