接口间的条件限定关系建模技术探讨

上一节中介绍了接口与接口的引发关系，但是事实上还存在以下三种情况：

（1）接口因为不同的输入参数，会有不同的输出结果，即使接口正常运行，也可能因为运行结果的不同而引发不同的接口。例如，在图6 的示例中，接口CheckMaterial用来检查厨房是否还有足够的食材，当其结果为true时，它引发的下一个接口才是接口PrepareOrder；当其结果为false时，它引发的接口将是用于取消订单，如图8（a）所示。

（2）多个接口的运行结果都满足条件才能引发下一组接口。同样以外卖订餐系统为例，在调用接口PrepareOrder准备菜品之前，不仅仅需要接口CheckMaterial的正常运行，还需要用户在确认订单后调用接口PayOrder完成订单支付，如图8（b）所示。

（3）多个接口中只要有一个接口运行结果满足条件就能引发下一组接口。例如，在接口CheckMaterial返回结果为false时，会引发用于取消订单的接口；但是当用于订单支付的接口PayOrder返回结果为false或者接口运行失败时，也会引发用于取消订单的接口；这两种情况只要有一种情况成立，就会引发同一个接口，如图8（c）所示。

这三种情况在接口引发关系上加上了条件限定，用上一节的引发关系不能完整描述。因此，本节将重点讨论对接口间存在的条件限定关系的形式化建模。

图8　接口与接口之间的条件限定关系

由图8 可以看出，条件限定关系是在引发关系的基础上，对接口与接口之间的关系作进一步约束，在上一节中用三元组来描述接口api_Name处于某种状态status时可能引发的下一组接口{apiSet}，加上条件限定关系后，就可以描述接口api_Name处于某种状态status并满足一定条件condition 时可能引发的下一组接口{apiSet}。

定义9 （条件限定关系Condition）Condition =（api_Name，satCon），其中：

（1）api_Name表示接口的名称，同时也是条件限定关系与因果关系建立起联系的键；

（2）satCon 为接口需要满足的限定条件，是由1 个或多个构造子组合而成，接下来将详细对其进行定义。

定义10 （限定条件satCon）

（1）若一个接口运行完成后，无条件引发下一组接口的调用。记satCon：： =τ，则有

（2）若一个接口运行完成后，需要满足一定条件才能引发下一组接口的调用。设ω为条件表达式，并记satCon：： =ω，则有

（3）若在n 个接口中，其中i个接口都运行完成后（ 1 ≤i≤n），无须满足条件便可引发下一组接口的调用。用符号⊕表示i个接口需都运行完成，并记其中1 ≤i ≤n，则有 {a1，a2，...，an} ｜

（4）若在n 个接口中，其中k 个接口都运行完成后（ 1 ≤k ≤n），其中i个接口无需满足条件，而另外的j个接口则需要满足一定条件才能引发下一组接口的调用，有i+j=k。用符号⊕表示k 个接口需都运行完成，并记satCon：： =⊕，其中1 ≤i≤k；1 ≤j≤k；i+j=k；1 ≤k≤n，则有{a1，a2，...，an} ｜

（5）若在n 个接口中，其中j个接口都运行完成后（ 1 ≤j≤n），这j个接口都需要满足一定条件才能引发下一组接口的调用。用符号⊕表示j个接口需都运行完成，并记，其中1 ≤j≤n，则有{a1，a2，...，an} ｜(www.xing528.com)

如前文所述，本体描述的是特定领域中的概念及其属性和相互关系，因此定义10 中的限定关系的表达式是无法用本体来直接描述的。接下来将定义9 与定义10 中的符号转换为本体中的元素。

对于概念concept，API、Condition…都是概念的例子。

对于实例instance，{a1，a2，...，an} 、 {b} 是接口API的实例； satCon 为条件Conditon 的实例。

对于关系relation 有：

（1）attribute-of关系

概念接口API与条件Condition 有属性关系，即条件Condition 是接口API的属性；条件Condition 的实例satCon 是接口API实例a1，a2，...，an 和b 等的属性；τ和ω为属性值。

（2）and_Causedby（）关系

定义10 中，用符号⊕来表示n 个接口需都运行完成才能引发下一组接口，这n 个接口之间是AND关系。在图9（a）中，and_Causedby（b，a）表示接口a由接口b 引发，但并不是由接口b 独立引发的，接口b 需要与其他接口一起引发接口a的运行。

图9　二元关系and_Causedby（）与or_Causedby（）

（3）or_Causedby（）关系

若n 个接口不需要都运行完成就能引发下一组接口，只需要其中i（1≤i＜n）个接口运行完便能引发下一个接口，那么这i个接口之间是AND关系，它们共同构成一个接口集合，接口集合与接口集合之间是OR的关系。在图9（b）中，接口a与接口b 的关系仍然用and_Causedby（b，a）来表示，这里用included In（a，api-Set1）来表示接口a包含于接口集合apiSet1中，用or_Causedby（b，apiSet1）来表示接口b 可以由接口集合apiSet1引发，这种引发关系是可能而不是必需的。由此可见，or_Causedby（）关系通常要与关系included In（），and_Causedby（）一起使用。

举例说明接口之间条件限定关系在接口定位中的应用，如在Windows API中，要调用函数VirtualUnlock 为从lpAddress起的dwSize字节大小的页面解除锁定（页对齐），需要满足两个条件，首先，需要解除锁定的页面必须是已经被锁定的；其次，由于只有提交的页面才能被锁定，因此要求这段页面处于提交状态。因此在调用函数VirtualUnlock 之前，需要调用完成函数VirtualAlloc和函数Virtual-Lock，其中函数VirtualAlloc用于在虚存中分配从lpAddress起的dwSize字节大小的页面（页对齐），并通过指定参数fAllocationType将页面的状态设置为提交状态；函数VirtualLock 用于将这段提交的页面锁定。因此它们之间存在条件限定关系，可以表示为：

includedIn （VirtualAlloc，apiSet）

includedIn （VirtualLock，apiSet）

and_Causedby（VirtualUnlock，apiSet）

当在一段代码中定位到函数VirtualAlloc和函数VirtualLock，那么在距离这两个函数不远处定位到函数VirtualUnlock 的概率就比较大。