WEB开发网      婵犵數濮烽弫鍛婄箾閳ь剚绻涙担鍐叉搐绾剧懓鈹戦悩瀹犲闁汇倗鍋撻妵鍕箛閸洘顎嶉梺绋款儑閸犳劙濡甸崟顖氬唨闁靛ě浣插亾閹烘鈷掗柛鏇ㄥ亜椤忣參鏌″畝瀣暠閾伙絽銆掑鐓庣仭缁楁垿姊绘担绛嬪殭婵﹫绠撻、姘愁樄婵犫偓娴g硶鏀介柣妯款嚋瀹搞儱螖閻樺弶鍟炵紒鍌氱Ч瀹曟粏顦寸痪鎯с偢瀵爼宕煎☉妯侯瀳缂備焦顨嗗畝鎼佸蓟閻旈鏆嬮柣妤€鐗嗗▓妤呮⒑鐠団€虫灀闁哄懐濮撮悾鐤亹閹烘繃鏅濋梺闈涚墕濡瑩顢欒箛鏃傜瘈闁汇垽娼ф禒锕傛煕閵娿儳鍩f鐐村姍楠炴﹢顢欓懖鈺嬬幢闂備浇顫夊畷妯肩矓椤旇¥浜归柟鐑樻尭娴滃綊姊虹紒妯虹仸闁挎洍鏅涜灋闁告洦鍨遍埛鎴︽煙閼测晛浠滃┑鈥炽偢閹鈽夐幒鎾寸彇缂備緡鍠栭鍛搭敇閸忕厧绶炴俊顖滅帛濞呭洭姊绘担鐟邦嚋缂佽鍊垮缁樼節閸ャ劍娅囬梺绋挎湰缁嬫捇宕㈤悽鍛婄厽閹兼番鍨婚埊鏇㈡煥濮樿埖鐓熼煫鍥ュ劤缁嬭崵绱掔紒妯肩畺缂佺粯绻堝畷姗€濡歌缁辨繈姊绘担绛嬪殐闁搞劋鍗冲畷顖炲级閹寸姵娈鹃梺缁樻⒒閳峰牓寮崒鐐寸厱闁抽敮鍋撻柡鍛懅濡叉劕螣鐞涒剝鏂€闂佺粯鍔曞Ο濠囧吹閻斿皝鏀芥い鏃囨閸斻倝鎽堕悙鐑樼厱闁哄洢鍔屾晶顖炴煕濞嗗繒绠婚柡灞界Ч瀹曨偊宕熼鈧▍锝囩磽娴f彃浜炬繝銏f硾椤戝洨绮绘ィ鍐╃厵閻庢稒岣跨粻姗€鏌ㄥ☉妯夹fい銊e劦閹瑩顢旈崟顓濈礄闂備浇顕栭崰鏍礊婵犲倻鏆﹂柟顖炲亰濡茶鈹戦埄鍐ㄧ祷妞ゎ厾鍏樺璇测槈閵忕姈鈺呮煏婢跺牆鍔撮柛鏂款槺缁辨挻鎷呯粙搴撳亾閸濄儳鐭撶憸鐗堝笒閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓 ---闂傚倸鍊搁崐鐑芥倿閿旈敮鍋撶粭娑樺幘濞差亜鐓涢柛娑卞幘椤斿棝姊虹捄銊ユ珢闁瑰嚖鎷�
开发学院WEB开发Jsp JML起步--使用JML 改进你的Java程序(3) 阅读

JML起步--使用JML 改进你的Java程序(3)

 2008-01-05 09:25:51 来源:WEB开发网 闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷闂傚倸鍊搁崐椋庣矆娓氣偓楠炲鏁撻悩鎻掔€梺姹囧灩閻忔艾鐣烽弻銉︾厵闁规鍠栭。濂告煕鎼达紕校闁靛洤瀚伴獮鎺楀箣濠靛啫浜鹃柣銏⑶圭壕濠氭煙閻愵剚鐏辨俊鎻掔墛缁绘盯宕卞Δ鍐冣剝绻涘畝濠佺敖缂佽鲸鎹囧畷鎺戭潩閹典焦鐎搁梻浣烘嚀閸ゆ牠骞忛敓锟�婵犵數濮烽弫鍛婃叏椤撱垹绠柛鎰靛枛瀹告繃銇勯幘瀵哥畼闁硅娲熷缁樼瑹閳ь剙岣胯鐓ら柕鍫濇偪濞差亜惟闁宠桨鑳堕崝锕€顪冮妶鍡楃瑐闁煎啿鐖奸崺濠囧即閵忥紕鍘梺鎼炲劗閺呮稒绂掕缁辨帗娼忛埡浣锋闂佽桨鐒﹂幑鍥极閹剧粯鏅搁柨鐕傛嫹闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷  闂傚倸鍊搁崐鐑芥嚄閼哥數浠氱紓鍌欒兌缁垶銆冮崨鏉戠厺鐎广儱顦崡鎶芥煏韫囨洖校闁诲寒鍓熷铏圭磼濡搫顫岄梺璇茬箲濮樸劑鍩€椤掍礁鍤柛鎾跺枎椤繐煤椤忓嫬鐎銈嗘礀閹冲酣宕滄导瀛樷拺闂侇偆鍋涢懟顖涙櫠椤斿墽纾煎璺猴功缁夎櫣鈧鍠栭…閿嬩繆濮濆矈妲烽梺绋款儐閹瑰洤螞閸愩劉妲堟繛鍡楃箲濞堟﹢姊绘担椋庝覆缂傚秮鍋撴繛瀛樼矤閸撶喖宕洪埀顒併亜閹烘垵鈧綊寮抽鍕厱閻庯綆浜烽煬顒傗偓瑙勬磻閸楀啿顕i崐鐕佹Ь闂佸搫妫寸粻鎾诲蓟閵娾晜鍋嗛柛灞剧☉椤忥拷
核心提示:来自:http://www-106.ibm.com/ 作者:Joe Verzulli 副作用请大家回忆一下代码段2中pop()方法的后处理代码:ensureselementsInQueue.equals(((JMLObjectBag) old(elementsInQueue))

  来自:http://www-106.ibm.com/ 作者:Joe Verzulli


副作用


请大家回忆一下代码段2中pop()方法的后处理代码:





ensures

elementsInQueue.equals(((JMLObjectBag)

old(elementsInQueue))

.remove(esult)) &&

esult.equals(old(peek()));




这里我们说有一个副作用,那就是在从elementsInQueue删除一个元素的时候会有副作用。事实上,这里还可能有其他的副作用。比方说,一个pop()方法的具体实现中假如修改了m_isMinHeap的值,那么就把排序方法从一个小顶堆变成了大顶堆。只要这种修改能够返回正确结果,就不会引起运行期间的断言检查异常,可是这个却事实上削弱了JML行为规范的作用。我们可以加强后置条件,不答应除了修改elementsInQueue以外的任何改变,请看下面的代码:



代码断7 加强的后置条件





ensures

elementsInQueue.equals(((JMLObjectBag)

old(elementsInQueue))

.remove(esult)) &&

esult.equals(old(peek())) &&

isMinimumHeap == old(isMinimumHeap) &&

comparator == old(comparator);




从中我们可以看出,通过加入形如x == old(x)的语句,我们可以消除变量x发生改变的副作用。可是有一个问题,假如用这种办法,每一个方法在它的后置条件都要为每一个变量加上这么一句,这样就会导致行为规范的混乱。而且假如我们给一个类增加一个成员的变量的话,那么我们就得在这个类的所有方法的后处理规范中增加一句,这将让维护变得异常困难。 JML通过引入assignable语句提供了一种更好地解决方案。



assignable 语句


使用assignable语句,我们可以这样完成pop()方法的后置条件:



代码段8 在方法的行为规范中使用assignable语句



/*@

@ public normal_behavior

@ requires ! isEmpty();

@ assignable elementsInQueue;

@ ensures

@ elementsInQueue.equals(((JMLObjectBag)

@ old(elementsInQueue))

@ .remove(esult)) &&

@ esult.equals(old(peek()));

@*/

Object pop() throws NoSUChElementException;





只有在assignable语句中列出的变量才能在一个方法的实现中修改。上面pop()方法的assignable语句的意思是在pop()方法的实现中可以修改elementsInQueue的值,除此之外的其他变量,比如isMinimumHeap、comparator等等都不可以修改。假如你在pop()方法的实现中修改了m_isMinHeap的值,那么编译的时候就会产生一个错误。(不过当前的JML编译器尚没有支持这个,也就是没有检查在方法的实现中,是否只修改在assignable语句中指定的变量。)



修改规则


我们前面说只有在assignable语句中列出的变量才能在一个方法的实现中修改,这其实是有点简化的说法。事实上,假如以下任意一个条件是 true,该规则就答应方法修改一个变量(loc):

assignable语句中显式列出loc 。
assignable语句中列出的变量依靠于loc。(比如说假如我们声明“assignable isMinimumHeap;” ,因为模型域isMinimumHeap依靠于具体域m_isMinHeap,所以该 assignable语句意味着方法不仅可以修改显式声明的isMinimumHeap,而且还能修改m_isMinHeap。)
方法开始执行时loc尚没有分配。
loc 是方法的局部变量或者是方法的形式参数。
最后一种情况答应一个方法修改它的参数,即使这个参数没有显式地出现在assignable语句中。粗略一看,这个似乎答应一个方法通过参数传递答应它的调用者修改变量的值。比方说,有一个方法foo(Bar obj),它里面有一个语句obj = anotherBar。不过虽然这个语句修改了obj的值,却不会影响到foo()的调用者,因为虽然这两个obj都是指向一个Bar对象,而且具有一样的名字,foo()方法中的此obj实际上与foo()的调用者中的彼obj是不同的(译者注:关于这一点,请参考java中索引与对象的概念)。



现在我们考虑假如方法foo(Bar obj)里面有一个语句obj.x = 17会怎么样?这个将显式地改变调用者中的变量。这是有问题的。assignable 语句的规则答应一个方法不需要在assignable 语句中声明就可以修改传入参数的值,不过它并不答应修改参数的成员变量,具体在这里来说,就是不答应修改obj.x的值。假如你希望在foo()方法中修改obj.x的值,你就必须在assignable 语句中声明,你可以写assignable obj.x; 。



assignable 语句中可以使用两个JML要害字, othing和everything。 我们可以通过assignable othing 语句来表明一个方法没有任何副作用;同样,我们可以通过assignable everything语句来表明我们的方法可以修改一切变量的值。早先我们使用了一个JML要害字pure,它就等同于使用assignable othing; 。

Tags:JML 起步 使用

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接