梁朋舉　劉建賓　鄭麗偉

(北京信息科技大學(xué)計(jì)算機(jī)學(xué)院　北京 100101)

?

程序藍(lán)圖模型重構(gòu)操作實(shí)例研究

梁朋舉劉建賓鄭麗偉

(北京信息科技大學(xué)計(jì)算機(jī)學(xué)院北京 100101)

重構(gòu)可以改善軟件系統(tǒng)的內(nèi)部結(jié)構(gòu)，提高軟件可理解性、可維護(hù)性，而又不改變軟件的外部行為。傳統(tǒng)的源碼層次的重構(gòu)雖有很多重構(gòu)工具的支持，但是對(duì)于復(fù)雜軟件的重構(gòu)難度大，容易出錯(cuò)。針對(duì)這種情況，提出基于程序藍(lán)圖模型層次的重構(gòu)?？紤]到UML模型直觀性的特點(diǎn)，給出UML類圖模型在系統(tǒng)體系結(jié)構(gòu)上的重構(gòu)操作和實(shí)例，為重構(gòu)在軟件框架結(jié)構(gòu)上的實(shí)施提供有力的支持。深入研究過程藍(lán)圖模型使用樹形結(jié)構(gòu)來描述程序的方法，定義過程藍(lán)圖相關(guān)重構(gòu)操作并給出具體操作實(shí)例及過程，最后從過程藍(lán)圖模型生成新的源碼。實(shí)驗(yàn)結(jié)果表明，UML模型和過程藍(lán)圖模型層次上的重構(gòu)，提高了重構(gòu)的抽象級(jí)別和效率。該方法能有效支持復(fù)雜軟件的重構(gòu)，并減少出錯(cuò)率。

重構(gòu)UML模型過程藍(lán)圖模型程序模型

0　引　言

當(dāng)軟件所處的環(huán)境發(fā)生變化或者需求改變時(shí)，軟件需要不斷地增強(qiáng)、修改以適應(yīng)新的變化，在這個(gè)發(fā)展的過程中，程序代碼會(huì)變得越來越復(fù)雜，并且可能會(huì)偏離最初的設(shè)計(jì)意圖，因而導(dǎo)致軟件的質(zhì)量持續(xù)降低。正是由于這個(gè)原因，軟件開發(fā)的大量成本都花費(fèi)在軟件的維護(hù)上。隨著軟件系統(tǒng)的演變，系統(tǒng)的結(jié)構(gòu)越來越復(fù)雜，性能越來越差，為解決這一問題，重構(gòu)技術(shù)開始產(chǎn)生并得到發(fā)展?！爸貥?gòu)”一詞最早是由Opdyke[1]提出，他把重構(gòu)定義為“面向?qū)ο箢I(lǐng)域的行為保持的重建的變體”。重構(gòu)沒有統(tǒng)一的定義，一個(gè)被廣泛認(rèn)可的定義是Martin Fowler[2]給出的定義，他把重構(gòu)定義為動(dòng)詞和名詞兩種形式?！爸貥?gòu)(名詞):對(duì)軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。重構(gòu)(動(dòng)詞)：使用一系列重構(gòu)的手法，在不改變軟件可觀察行為的前提下，調(diào)整其結(jié)構(gòu)?！?/p>

目前的重構(gòu)技術(shù)的對(duì)象主要集中在程序源碼上，屬于代碼級(jí)別重構(gòu)，重構(gòu)之前需要先對(duì)源碼分析，進(jìn)行重構(gòu)定位，然后才能執(zhí)行重構(gòu)。UML模型的出現(xiàn)將重構(gòu)提升到模型級(jí)別，UML模型重構(gòu)的研究國(guó)內(nèi)外已有較好進(jìn)展，并且有一些工具能夠支持UML模型的重構(gòu)，在文獻(xiàn)[3]的關(guān)于UML模型在模型驅(qū)動(dòng)軟件開發(fā)中的調(diào)查中，我們可以看到近期關(guān)于UML模型重構(gòu)的部分研究成果。Sunye等[4]使用UML類圖和狀態(tài)圖向我們展示了最初的模型重構(gòu)，在元模型級(jí)別上定義為OCL約束，使用前置條件和后置條件來保證重構(gòu)前后的行為保持，以此來提高模型的質(zhì)量。Dobrzanski等[5]為可執(zhí)行的UML類圖模型中的壞味道提供了一系列重構(gòu)，并在Telelogic TAU CASE工具中給出了實(shí)現(xiàn)。Tom Mens等[6，7]把重構(gòu)提升到一個(gè)更高的抽象層次——基于模型驅(qū)動(dòng)的軟件重構(gòu)，包括UML類圖模型層次的重構(gòu)等。文獻(xiàn)[6]中使用UML協(xié)議的狀態(tài)機(jī)和順序圖向我們提出了一種模型重構(gòu)的形式化方法。文獻(xiàn)[7]中Mens采用最先進(jìn)的模型驅(qū)動(dòng)軟件開發(fā)工具AndroMDA進(jìn)行案例開發(fā)的形式來解決模型驅(qū)動(dòng)軟件重構(gòu)的一系列問題(如：如何定義、檢測(cè)、保證模型質(zhì)量，如何進(jìn)行行為保持)。Wüst[8]開發(fā)的用于UML的軟件質(zhì)量評(píng)估工具，可以用來分析UML模型的結(jié)構(gòu)，運(yùn)用設(shè)計(jì)規(guī)則檢測(cè)設(shè)計(jì)的不一致性和不完整性。El-Sharqwi[9]等人提出了一種基于使用XML語義定義的設(shè)計(jì)模式的UML模型重構(gòu)。Reimann[10]等人提出了一種由角色模型和通用轉(zhuǎn)換規(guī)則組成通用的UML模型重構(gòu)框架。張雨薇[11]結(jié)合Opdyke和Fowler的研究和UML類圖特點(diǎn)，將基本重構(gòu)劃分了三個(gè)層次，并給出UML自動(dòng)重構(gòu)的實(shí)現(xiàn)框架。國(guó)內(nèi)外研究在UML模型重構(gòu)上雖提出了相應(yīng)的理論化方法、重構(gòu)框架和重構(gòu)工具支持，但是由于UML模型本身在程序過程描述方面沒有較好的支持，所以我們使用過程藍(lán)圖模型彌補(bǔ)了UML模型在實(shí)現(xiàn)層過程描述的不足使得模型重構(gòu)能夠在方法級(jí)別上執(zhí)行，從而把重構(gòu)的級(jí)別提升到模型級(jí)與過程級(jí)。

2005年劉建賓[12]提出過程藍(lán)圖的概念并進(jìn)行完備的形式化定義。2006年楊林邦[13]在基于源碼重構(gòu)的基礎(chǔ)上提出了過程藍(lán)圖上的重構(gòu)形式化定義，定義了37個(gè)過程藍(lán)圖模型重構(gòu)的分析函數(shù)，在Opdyke[1]提出的7個(gè)不變量的基礎(chǔ)上針對(duì)過程藍(lán)圖的特點(diǎn)增加了3個(gè)不變量，定義15個(gè)基本樹變換操作，給出27個(gè)過程藍(lán)圖重構(gòu)規(guī)格說明，并進(jìn)行了一些簡(jiǎn)單的重構(gòu)變換實(shí)踐。2007年易長(zhǎng)安[14]在文獻(xiàn)[13]基礎(chǔ)上進(jìn)行了完善，新增15個(gè)過程藍(lán)圖模型重構(gòu)的分析函數(shù)，提出3個(gè)新的不變量，增加5個(gè)基本樹變換操作，又給出了9種重構(gòu)規(guī)格說明并給出每種重構(gòu)規(guī)格對(duì)應(yīng)的源碼重構(gòu)實(shí)例。2011年梅新云[15]提出了一種程序模型重構(gòu)的實(shí)現(xiàn)框架，使用JAVACC解析源碼，從而實(shí)現(xiàn)源碼到過程藍(lán)圖的逆向變換，重新定義了21種過程藍(lán)圖基本樹變換函數(shù)，在文獻(xiàn)[13]的基礎(chǔ)上重新定義了3種重構(gòu)規(guī)格說明，新增了15種重構(gòu)分析函數(shù)，并添加了15種重構(gòu)輔助函數(shù)，給出了增加和刪除變量重構(gòu)操作的實(shí)現(xiàn)算法和一個(gè)完整的變量重命名操作實(shí)現(xiàn)算法。2012年王俊飛[16]在C#過程藍(lán)圖上使用了基于數(shù)據(jù)流方程的切片算法，在文獻(xiàn)[13-15]的基礎(chǔ)上定義了9個(gè)新的分析函數(shù)，針對(duì)過程藍(lán)圖增加了3個(gè)新的重構(gòu)操作。2013年胡偉奇[17]提出了一種Java藍(lán)圖模式的形式化定義框架，并引入了動(dòng)作模式和過程模式，提出了一種新的Java藍(lán)圖模式匹配，包括結(jié)構(gòu)匹配、語義匹配和參數(shù)匹配，并在這個(gè)的基礎(chǔ)上說明了模式間的映射關(guān)系和重構(gòu)變換規(guī)則。以上研究在過程藍(lán)圖模型重構(gòu)研究方面做出了一定的理論成果，為進(jìn)一步的研究提供了理論支持，但在過程藍(lán)圖上重構(gòu)的方面尚未有深入涉及。

本文給出了一種新的程序藍(lán)圖框架，使用UML模型來表示系統(tǒng)的體系結(jié)構(gòu)，定義UML類圖重構(gòu)操作，并給出操作實(shí)例，執(zhí)行系統(tǒng)框架級(jí)的模型重構(gòu)，為過程藍(lán)圖上的重構(gòu)指明了方向。使用過程藍(lán)圖模型描述方法的實(shí)現(xiàn)，定義過程藍(lán)圖重構(gòu)的一系列形式化操作，并給出部分操作實(shí)現(xiàn)，執(zhí)行類的方法層次的重構(gòu)，從而將重構(gòu)提升到模型和過程級(jí)別。

1　程序藍(lán)圖模型基本概念

我們把程序藍(lán)圖定義為UML類圖模型、過程藍(lán)圖模型以及兩者之間的關(guān)系。使用UML類圖模型描述軟件的體系結(jié)構(gòu)框架，直觀地呈現(xiàn)程序結(jié)構(gòu)；使用過程藍(lán)圖模型描述程序方法的實(shí)現(xiàn)過程，直觀地表示方法細(xì)節(jié)。故程序藍(lán)圖模型包括UML類圖模型和過程藍(lán)圖模型兩部分。

UML類圖模型

Sunye等[4]第一次使用UML語言將重構(gòu)思想應(yīng)用到模型之上。UML模型，特別是UML的類圖模型廣泛得到研究者的論證，其優(yōu)勢(shì)是和面向?qū)ο蟪绦虻慕Y(jié)構(gòu)非常接近，因此，很多來自于面向?qū)ο蟪绦?Fowler[2])的重構(gòu)方法也可以轉(zhuǎn)換成UML類圖模型。使用UML模型重構(gòu)的一個(gè)缺點(diǎn)是只能在程序框架上執(zhí)行重構(gòu)，在表示完整程序方面有所欠缺。

過程藍(lán)圖模型

過程藍(lán)圖是一種跨越分析、設(shè)計(jì)和構(gòu)造階段的統(tǒng)一過程表示方法，是描述軟件行為過程的一種工程藍(lán)圖[12]。過程藍(lán)圖分為概念層、邏輯層和實(shí)現(xiàn)層三個(gè)層次，分別用于描述抽象概念結(jié)構(gòu)(ACSD)、抽象邏輯結(jié)構(gòu)(ALSD)和抽象實(shí)現(xiàn)結(jié)構(gòu)(AISD)。過程藍(lán)圖提供了從概念層到邏輯層的控制流映射和從邏輯層到實(shí)現(xiàn)層的數(shù)據(jù)流映射，這種兩級(jí)映射功能提供了一定程度的程序獨(dú)立性(控制流獨(dú)立性和數(shù)據(jù)流獨(dú)立性)。過程藍(lán)圖的三層結(jié)構(gòu)層層細(xì)化，逐步求精，是一種圖形化的程序過程表示方法，是對(duì)源碼進(jìn)行描述的模型。其本質(zhì)是抽象語法樹，是一種內(nèi)部外部統(tǒng)一表示的樹形結(jié)構(gòu)模型，富含豐富的語義，具備抽象語法樹對(duì)重構(gòu)的支持能力，將重構(gòu)的抽象層次提高到模型級(jí)別。由于過程藍(lán)圖模型本身具備有效性、一致性、完備性、正確性，所以使用重構(gòu)操作的執(zhí)行更加容易，而且出錯(cuò)率較低，在一定程度上優(yōu)于基于源碼的重構(gòu)和基于UML模型的重構(gòu)。

UML類圖模型和過程藍(lán)圖模型的關(guān)系

UML類圖模型是程序框架級(jí)別的抽象，能夠直觀地呈現(xiàn)程序的體系結(jié)構(gòu)。過程藍(lán)圖是類的方法級(jí)別的抽象，使用三層結(jié)構(gòu)兩級(jí)映射來描述方法實(shí)現(xiàn)過程。二者各有自己的優(yōu)點(diǎn)和不足，一個(gè)完整的程序模型重構(gòu)過程既需要框架層次的重構(gòu)，又需要方法層次的重構(gòu)，二者相輔相成缺一不可。

2　UML類圖模型重構(gòu)擴(kuò)展

2.1UML類圖三層重構(gòu)操作擴(kuò)展

UML類圖上的重構(gòu)分為基本重構(gòu)和組合重構(gòu)?；局貥?gòu)是進(jìn)行UML類圖變換的一系列基本的操作，組合重構(gòu)是將基本重構(gòu)按照循序、選擇和循環(huán)三種方式組合的一起完成實(shí)現(xiàn)一個(gè)重構(gòu)的功能。文獻(xiàn)[11，14]中給出將基本重構(gòu)劃分為三個(gè)層次：變量和對(duì)象級(jí)別的重構(gòu)、構(gòu)造函數(shù)和方法級(jí)別的重構(gòu)、類和接口級(jí)別的重構(gòu)，并給出每個(gè)層次下的重構(gòu)操作的定義。

我們?cè)谠撗芯康幕A(chǔ)上進(jìn)行擴(kuò)充和完善，提出以下新的UML類圖模型的重構(gòu)操作，并給出部分UML類圖的基本重構(gòu)和組合重構(gòu)的實(shí)現(xiàn)實(shí)例。

(1) 新增變量和對(duì)象級(jí)別的重構(gòu)操作

針對(duì)UML類圖中的字段、臨時(shí)變量以及對(duì)象進(jìn)行的重構(gòu)操作，新增以下重構(gòu)操作：

Void EncapsulateField(Class c, Field varName ) 封裝類的字段

Void SplitTempVariable(Class c, Field varName)針對(duì)每次不同賦值，創(chuàng)造一個(gè)獨(dú)立、對(duì)應(yīng)的臨時(shí)變量

(2) 新增構(gòu)造函數(shù)和方法級(jí)別的重構(gòu)操作

針對(duì)UML類圖中的字段、臨時(shí)變量以及對(duì)象進(jìn)行的重構(gòu)操作，新增以下重構(gòu)操作：

Void EncapsulateCollection(Class c, Set method1, Set method2)封裝集合副本做返回值，增加新增和移除集合元素的函數(shù)

Void HideMethod(Class c,Method m)隱藏函數(shù)，將函數(shù)的類型改為private

Void AddParameter(Class c, Method m)為函數(shù)添加新的參數(shù)

Void RemoveParameter(Class c, Method m)移除函數(shù)的部分參數(shù)

(3) 新增類和接口級(jí)別的重構(gòu)操作

針對(duì)UML類圖中的字段、臨時(shí)變量以及對(duì)象進(jìn)行的重構(gòu)操作，新增以下重構(gòu)操作：

Void ReplaceValuewithObject(Class c1, Class c2, Object obj)新增類將數(shù)據(jù)項(xiàng)變?yōu)閷?duì)象

Void Replace Constructor with Factory Method(Class c, Class c1, Class c2,FactoryMethod fm)為每個(gè)子類建立工廠函數(shù)

Void ExtractInterface(Interface,Class)將相同的子集提煉到一個(gè)獨(dú)立的接口中

2.2UML類圖重構(gòu)操作實(shí)例

對(duì)類圖的重構(gòu)有五種基本類型操作：增加、刪除、移動(dòng)、泛化和特化。其中，泛化和特化分別是在類和接口的層次上進(jìn)行上移和下移的重構(gòu)操作。

實(shí)例源于文獻(xiàn)[2]中的影片出租程序，并在其基礎(chǔ)上進(jìn)行適當(dāng)擴(kuò)展。顧客可以通過該系統(tǒng)租用不同的影片，系統(tǒng)可根據(jù)影片租用時(shí)間和影片類型計(jì)算費(fèi)用并打印詳單，亦可為?？陀?jì)算積分。

實(shí)例1Void EncapsulateField(Class c, Field varName )

功能：將類c(Movie)的字段varName(price)進(jìn)行封裝。

重構(gòu)類型：基本重構(gòu)。

重構(gòu)過程：Movie類中的字段price為public類型，不符合面向?qū)ο蠓庋b原則。首先為price字段添加get和set方法，然后更新price字段的所有引用，最后更改price的類型為private。如圖1所示。

圖1　EncapsulateField重構(gòu)執(zhí)行前后類圖對(duì)比

實(shí)例2Void Extract_Class(Class c, Class c1)

重構(gòu)類型：組合重構(gòu)。

重構(gòu)過程：重構(gòu)之前Customer類有3個(gè)字段一個(gè)方法，經(jīng)過分析之后，可以把其中的兩個(gè)字段和一個(gè)方法使用Move_Field和Move_Method進(jìn)行搬移到新類的重構(gòu)，做法是首先新建一個(gè)TelephoneNumber類，然后運(yùn)用Move_Field把a(bǔ)reaCode和number字段搬移到TelephoneNumber類，然后使用Move_Method將getTelephoneNumber方法搬移到TelephoneNumber類，最后在調(diào)整可見性，重構(gòu)執(zhí)行前后的類圖如圖2所示。

圖2　Extract_Class重構(gòu)執(zhí)行前后類圖對(duì)比

實(shí)例3void ReplaceSubclasswithFields(Class c, Class c1, Class c2, Field varName)

功能：在超類c(Customer)中添加字段varName(_code)取代子類c1(VIP),c2(NVIP)，并銷毀子類。

重構(gòu)類型：組合重構(gòu)。

重構(gòu)過程：Customer類是抽象類，有兩個(gè)子類VIP和NVIP，兩個(gè)子類唯一區(qū)別就是以不同方式實(shí)現(xiàn)了Customer類所聲明的getCode()方法，返回不同的常量，我們首先使用Replace Constructor with Factory Method重構(gòu)，在Customer類中為每個(gè)子類建立對(duì)應(yīng)的工廠函數(shù)，并將所有調(diào)用處的構(gòu)造函數(shù)改為工廠函數(shù)，接著使用Add_Instance_Variable重構(gòu)，在Customer類中添加兩個(gè)字段。在使用Add_Method重構(gòu)在Customer類添加構(gòu)造函數(shù)，最后使用Remove_Method，Remove_Class刪除VIP類和NVIP類。重構(gòu)執(zhí)行前后的類圖如圖3所示。

圖3　ReplaceSubclasswithFields重構(gòu)執(zhí)行前后類圖對(duì)比

以上三個(gè)UML重構(gòu)實(shí)例分別是字段、方法和類三個(gè)層次的代表性實(shí)例，主要說明了重構(gòu)操作實(shí)現(xiàn)的相關(guān)細(xì)節(jié)。UML類圖模型重構(gòu)對(duì)程序的框架結(jié)構(gòu)執(zhí)行了較好優(yōu)化，雖沒有涉及到具體的方法層次的重構(gòu)，但還是為過程藍(lán)圖模型重構(gòu)提供了良好的框架基礎(chǔ)。

流行音樂已介入社會(huì)生活的各個(gè)領(lǐng)域，成為年輕人喜愛并熱情參與的文化娛樂形式，它深刻影響著青少年人生觀、價(jià)值觀的形成。因此，隨著國(guó)家新一輪課程改革的進(jìn)一步深入、學(xué)校和教師擁有越來越多的課程自主權(quán)，教師可以在中學(xué)生音樂教育中根據(jù)學(xué)生的實(shí)際情況，適當(dāng)引入一些藝術(shù)價(jià)值相對(duì)較高的流行音樂，教會(huì)學(xué)生鑒賞音樂的辦法，提高他們的鑒賞能力、欣賞品味和審美能力，并以此為契機(jī)激發(fā)他們學(xué)習(xí)音樂的興趣，擴(kuò)大他們的音樂視野。

3　過程藍(lán)圖模型重構(gòu)

3.1過程藍(lán)圖的樹形重構(gòu)

? 過程藍(lán)圖的樹形結(jié)構(gòu)模型

一個(gè)標(biāo)準(zhǔn)的Java系統(tǒng)源碼通常包含以下元素：包名(Package)、類名(Class)、方法名(Method)、屬性名(Attribute)，這些元素的命名應(yīng)符合Java命名規(guī)范，過程藍(lán)圖的樹形結(jié)構(gòu)表示和軟件系統(tǒng)源碼是一一對(duì)應(yīng)的，也包含以上四種元素。一個(gè)系統(tǒng)的過程藍(lán)圖樹形結(jié)構(gòu)的基本元素之間的關(guān)系圖如圖4所示。

圖4　過程藍(lán)圖基本元素之間的關(guān)系圖

ACSD是抽象概念結(jié)構(gòu)圖，ALSD是抽象邏輯結(jié)構(gòu)圖，AISD是抽象實(shí)現(xiàn)結(jié)構(gòu)圖，它們一起組成了過程藍(lán)圖中一個(gè)操作的過程藍(lán)圖三層結(jié)構(gòu)模型。過程藍(lán)圖三層結(jié)構(gòu)的思想和MDA的思想是吻合的，ACSD對(duì)應(yīng)于MDA的平臺(tái)無關(guān)模型PIM，是對(duì)程序的高度抽象描述，表達(dá)了程序的思想，與具體的實(shí)現(xiàn)技術(shù)和平臺(tái)無關(guān)；ALSD也對(duì)應(yīng)與MDA的PIM模型，是對(duì)ACSD的細(xì)化，使語義的表達(dá)更加明確，與具體的實(shí)現(xiàn)技術(shù)和平臺(tái)無關(guān)；AISD對(duì)應(yīng)于MDA的平臺(tái)相關(guān)模型(PSM)，是基于特定的變換格式對(duì)ALSD的轉(zhuǎn)換，格式的要求較為嚴(yán)格，同特定的平臺(tái)和實(shí)現(xiàn)技術(shù)密切相關(guān)。ALSD模型是代碼生成的依據(jù)，代碼質(zhì)量好壞取決于ALSD的格式正確性。

過程藍(lán)圖模型動(dòng)作語義[12]包括終結(jié)動(dòng)作和復(fù)合動(dòng)作，ACSD的構(gòu)造類型集合表示為Tacsd={+，*，o，？，！，：，>，e,&,#},ALSD和AISD的構(gòu)造類型相同，集合表示為：Talsd={SEQ，SYN，F(xiàn)OR，WHL，DOW，SWH，IFE，IFT，CAS，DFT，BLK，DCL，OPE，LAB，TRY，CAH，F(xiàn)NY，BRK，CON，CHR，RET，UND}=Taisd，我們對(duì)Java語言的過程藍(lán)圖動(dòng)作語義的定義匯總?cè)绫?所示。

表1　過程藍(lán)圖三層動(dòng)作語義表

過程藍(lán)圖的三層模型都是一個(gè)合法的樹結(jié)構(gòu)，每一層都必須滿足同時(shí)滿足以下三個(gè)條件，令T表示過程藍(lán)圖樹，A表示T的節(jié)點(diǎn)集合，a表示T的一個(gè)結(jié)點(diǎn)，root表示根節(jié)點(diǎn)。

條件1T中有且只有一個(gè)根節(jié)點(diǎn)root，并且root沒有父節(jié)點(diǎn)。

C1: root∈A(parent(T,root) = ∧ unique(T,root))

條件2T中除去根節(jié)點(diǎn)以外，其他的結(jié)點(diǎn)有且只有一個(gè)父節(jié)點(diǎn)。

C2: a∈A—{root}(|parent(T,a)| = 1)

條件3T中的任何結(jié)點(diǎn)都不能是自己的祖先。

C3: a∈A(a?ancestor(T,a))

三個(gè)條件保證過程藍(lán)圖的三層結(jié)構(gòu)圖在任何時(shí)刻具有樹形層次結(jié)構(gòu)的強(qiáng)制性要求。

? 過程藍(lán)圖重構(gòu)形式化

過程藍(lán)圖是程序模型的一種過程級(jí)描述，需要用到的程序及模型實(shí)體有：包(Package)、類(Class)、操作(Method)、屬性(Attribute)、過程藍(lán)圖樹(T)、抽象概念結(jié)構(gòu)圖(Tc)、抽象邏輯結(jié)構(gòu)圖(Tl)、抽象實(shí)現(xiàn)結(jié)構(gòu)圖(Ti)、結(jié)點(diǎn)(Node)、結(jié)點(diǎn)類型(NType)、語句塊(Statement)、表達(dá)式(Expression)、變量(Variable)、常量(Constant)和參數(shù)(Parameter)。

分析函數(shù)是用來對(duì)程序進(jìn)行分析的函數(shù)，任何重構(gòu)操作必須在分析函數(shù)的基礎(chǔ)上才能正確進(jìn)行。Opdyke[1]將分析函數(shù)分為原始分析函數(shù)和導(dǎo)出分析函數(shù)。原始分析函數(shù)是粒度最小、不可分割、且能實(shí)現(xiàn)最基本功能的分析函數(shù)；導(dǎo)出分析函數(shù)是原始分析函數(shù)的疊加調(diào)用和組合，結(jié)構(gòu)復(fù)雜且功能更加強(qiáng)大的分析函數(shù)。分析函數(shù)的主要功能是保證執(zhí)行重構(gòu)操作的前置條件和重構(gòu)后的程序滿足的后置條件。

文獻(xiàn)[13-16]在Opdyke和Roberts[18]的基礎(chǔ)上針對(duì)過程藍(lán)圖一共提出了76個(gè)分析函數(shù)，因所采用的語言和實(shí)現(xiàn)方法不同而有所差異，由于過程藍(lán)圖重構(gòu)操作實(shí)例實(shí)現(xiàn)的需要，我們?cè)谒麄児ぷ鞯幕A(chǔ)上提出部分新的分析函數(shù)。如表2所示。

表2　新增分析函數(shù)列表

不變量是重構(gòu)變換過程中應(yīng)該保持不變的量，Opdyke在面向?qū)ο蟪绦蛑貥?gòu)中，使用前置條件來保護(hù)不變量，以確保重構(gòu)前后程序的行為保持，Roberts又增加了后置條件來保障重構(gòu)的行為保持。文獻(xiàn)[13，14，16]在Opdyke提出的7個(gè)不變量的基礎(chǔ)上，針對(duì)過程藍(lán)圖的特點(diǎn)一共新增了9個(gè)不變量，我們根據(jù)過程藍(lán)圖上重構(gòu)實(shí)現(xiàn)需要，增加新的不變量，來保證我們的重構(gòu)結(jié)果的正確性。表3給出了新增不變量的列表。

表3　新增不變量列表

續(xù)表3

在過程藍(lán)圖中，所有的重構(gòu)操作都是基于過程藍(lán)圖樹結(jié)構(gòu)的變換操作,因此，基本樹變換操作是實(shí)現(xiàn)過程藍(lán)圖重構(gòu)的基礎(chǔ)。文獻(xiàn)[13，14]給出了20個(gè)基本的樹變換操作，我們?cè)谒麄兊幕A(chǔ)上進(jìn)行了擴(kuò)充，新增了10個(gè)基本樹變換操作。新增的基本樹變換操作如表4所示。

表4　新增基本樹變換操作列表

表4中S表示結(jié)構(gòu)操作，N表示結(jié)點(diǎn)操作。

文獻(xiàn)[13，14，16]在Martin Fowler提出70多種基于源碼的重構(gòu)操作的基礎(chǔ)上，先后一共定義了39種過程藍(lán)圖上的重構(gòu)規(guī)格說明，在他們的基礎(chǔ)上，基于過程藍(lán)圖重構(gòu)實(shí)現(xiàn)的需要，我們新增了10個(gè)重構(gòu)操作，如表5所示。

表5　新增重構(gòu)操作規(guī)格說明及分類

續(xù)表5

表5中RP為原子重構(gòu)，R1為組合重構(gòu)，R2為復(fù)雜重構(gòu);SR為結(jié)構(gòu)重構(gòu)，NR為結(jié)點(diǎn)重構(gòu)。ACR為抽象概念層重構(gòu)，ALR為抽象邏輯層重構(gòu)，AIR為抽象實(shí)現(xiàn)層重構(gòu)。

過程藍(lán)圖的樹形結(jié)構(gòu)模型的定義以及重構(gòu)形式化工作的擴(kuò)展，都是為過程藍(lán)圖上重構(gòu)操作的具體實(shí)現(xiàn)做理論準(zhǔn)備，下面我們將基于幾種特定的應(yīng)用場(chǎng)景，給出對(duì)應(yīng)的重構(gòu)操作在過程藍(lán)圖上的實(shí)現(xiàn)。

3.2過程藍(lán)圖重構(gòu)操作實(shí)例

過程藍(lán)圖模型的構(gòu)建使用了我們的藍(lán)圖工具，中文化藍(lán)圖模型的建立需要定義中英文映射表mapping.zhb和tokens.sys英文變量符號(hào)表，使用過程這里不再詳述，可參見文獻(xiàn)[12]，在執(zhí)行重構(gòu)之前須確保中文化的過程藍(lán)圖模型能正確生成重構(gòu)前的源代碼。以下實(shí)例同樣采用2.2節(jié)案例中提到的影片出租程序,展示了擴(kuò)展后的重構(gòu)形式化定義在過程藍(lán)圖模型重構(gòu)操作中的具體應(yīng)用，并給出詳細(xì)的操作過程。

實(shí)例1：

重構(gòu)操作：提煉方法ExtractMethod(Class c, Method m, Tl t, Statement s, Method m1)

功能：針對(duì)類c的方法m(printInfo)的過程藍(lán)圖t，將t的語句塊s提煉為新的方法m1(printDetail)。

場(chǎng)景：Martin Fowler提出的22種代碼壞味道中，重復(fù)代碼、過長(zhǎng)函數(shù)、過大的類、依戀情結(jié)、Switch語句等都是考慮執(zhí)行Extract Method的外在表現(xiàn)，場(chǎng)景重前的源碼和構(gòu)造的過程藍(lán)圖模型如圖5所示。

圖5　重構(gòu)前ExtractMethod類的方法源碼和過程藍(lán)圖模型

執(zhí)行步驟：

(1) 運(yùn)用已定義的導(dǎo)出分析函數(shù)LongMethodWithoutTempVar及其他原始分析函數(shù)，分析重構(gòu)的前置條件和不變量是否滿足。

(2) 對(duì)“打印信息”過程藍(lán)圖模型進(jìn)行基本樹變換操作。選定“打印橫幅”，執(zhí)行InsertElderBrother插入兄長(zhǎng)“打印詳細(xì)信息”，并建立三層模型。跳轉(zhuǎn)步驟5。

(3) 在類上執(zhí)行CreateMethod添加新的方法“打印詳細(xì)信息”,接著執(zhí)行EditPBTree建立該方法的過程藍(lán)圖模型。然后連續(xù)使用CreateNode將“打印信息”藍(lán)圖模型中需要提煉的語句塊依次添加到“打印詳細(xì)信息”三層模型中。跳轉(zhuǎn)步驟5。

(4) 打開“打印信息”過程藍(lán)圖模型，執(zhí)行DeleteNode刪除已提煉到“打印詳細(xì)信息”藍(lán)圖模型中的所有節(jié)點(diǎn)。跳轉(zhuǎn)到步驟5。

(5) 執(zhí)行GenerateEnglishCode生成重構(gòu)后英文源碼，源碼有錯(cuò)誤，返回步驟2-步驟4。直到最終源碼正確，重構(gòu)結(jié)束。

重構(gòu)結(jié)果：

重構(gòu)執(zhí)行后，從“打印信息”的語句塊中提煉出了一個(gè)新方法“打印詳細(xì)信息”，重構(gòu)后的兩個(gè)方法的過程藍(lán)圖模型和源碼如圖6所示。

圖6　重構(gòu)后Extract Method的的方法源碼和過程藍(lán)圖模型

實(shí)例2：

重構(gòu)操作：搬移函數(shù)MoveMethod(Class c1, Method m1, Class c2, Method m2)

功能：將類c1(Customer)中的方法m1(overRentCharge)搬移到類c2(CustomerType)中成為新的方法m2(overRentCharge)

場(chǎng)景：一個(gè)類中的方法有太多的行為與另外一個(gè)類相關(guān)而形成了高度耦合，就要考慮使用搬移函數(shù)MoveMethod，場(chǎng)景重構(gòu)前的類框架和方法rentCharge,overRentCharge的過程藍(lán)圖模型如圖7所示。

圖7　Move Method重構(gòu)之前的類框架和方法過程藍(lán)圖模型

執(zhí)行步驟：

(1) 運(yùn)用已定義的導(dǎo)出分析函數(shù)MethodAppear及其他原始分析函數(shù)，分析重構(gòu)的前置條件和不變量是否滿足。

(2) 在方法rentCharge和方法上overRentCharge上執(zhí)行一系列樹變換操作。先執(zhí)行CreateTree分別建立過程藍(lán)圖樹，然后執(zhí)行InsertChild、InsertElderBrother，每次建立一個(gè)結(jié)點(diǎn)，執(zhí)行UpdateNode進(jìn)行更新保存。當(dāng)所有的模型建立完畢之后執(zhí)行savePBModel保存當(dāng)前的過程藍(lán)圖模型。跳轉(zhuǎn)到步驟5。

(3) 在類Customer中的方法overRentCharge上執(zhí)行copyMethod操作，然后在CustomerType類中執(zhí)行pasteMethod操作，這樣兩個(gè)類中都有方法overRentCharge。接著執(zhí)行MethodAppear查找overRentCharge出現(xiàn)的類，如果只有在Customer中調(diào)用了，可以直接對(duì)Customer中的overRentCharge執(zhí)行deleteMethod，刪除該方法，并更新rentCharge的過程藍(lán)圖模型為方法調(diào)用。如果還有其他類調(diào)用Customer中的overRentCharge方法，可以在過程藍(lán)圖中使用deleteAllChildren刪除overRentCharge的方法體，并執(zhí)行InsertChild添加新子節(jié)點(diǎn)，加入對(duì)_type. overRentCharge()的調(diào)用。跳轉(zhuǎn)到步驟5。

(4) 在類CustomerType的方法overRentCharge上執(zhí)行EditPBTree，編輯過程藍(lán)圖模型，修改結(jié)點(diǎn)的調(diào)用語句，并執(zhí)行UpdateNode更新結(jié)點(diǎn)和savePBModel保存模型，跳轉(zhuǎn)到步驟5。

(5) 執(zhí)行GenerateEnglishCode生成重構(gòu)后英文源碼，源碼有錯(cuò)誤，返回步驟2-步驟4。直到最終源碼正確，重構(gòu)結(jié)束。

重構(gòu)結(jié)果：

重構(gòu)完成后,刪除了Customer類的overdraftCharge方法，在CustomerType類中添加了新的overdraftCharge方法，并進(jìn)行了簡(jiǎn)單的修改，重構(gòu)后的兩個(gè)類的兩個(gè)方法的過程藍(lán)圖模型和類框架如圖8所示。

圖8　Move Method重構(gòu)之后的類框架和方法過程藍(lán)圖模型

實(shí)例1和實(shí)例2的結(jié)果分別說明重構(gòu)形式化定義在簡(jiǎn)單和復(fù)雜的過程藍(lán)圖模型重構(gòu)中是可以正確操作的，為以后重構(gòu)系統(tǒng)的實(shí)現(xiàn)奠定了形式化基礎(chǔ)。

4　程序模型重構(gòu)流程

程序模型重構(gòu)的實(shí)現(xiàn)，需要建立UML模型、過程藍(lán)圖模型和程序源碼的一致性映射，程序源碼是基于文本的表示方法，UML模型和過程藍(lán)圖模型都是基于可視化圖形的表示方法，比起文本表示更直觀。源碼到UML模型的逆向映射可以借助于許多開源工具(如ArgoUML)自動(dòng)變換，也可以手工添加；程序源碼到過程藍(lán)圖模型的轉(zhuǎn)換需要使用過程藍(lán)圖模型轉(zhuǎn)換工具自動(dòng)轉(zhuǎn)換，然后加以修改。重構(gòu)完畢后UML模型可以正向生成框架代碼，過程藍(lán)圖模型可以直接生成完整的可執(zhí)行代碼。下面給出程序模型重構(gòu)實(shí)現(xiàn)的工作流程圖，如圖9所示。

圖9　程序模型重構(gòu)實(shí)現(xiàn)的工作流程圖

上述框架的實(shí)現(xiàn)主要包括以下幾步：

(1) 程序源碼到程序模型的逆向變換

程序模型包括UML模型和過程藍(lán)圖模型，源碼到模型的變換需要遵循特定的映射規(guī)則，首先，借助于開源的UML建模工具和過程藍(lán)圖變換系統(tǒng)，實(shí)現(xiàn)半自動(dòng)化的變換，生成初步的UML類圖模型和每個(gè)方法對(duì)應(yīng)的過程藍(lán)圖模型，然后人工在模型上進(jìn)行修改，以保證變換后模型的正確性。

(2) UML類圖模型的重構(gòu)

UML類圖模型的重構(gòu)在類、方法、屬性三個(gè)層次上執(zhí)行。首先對(duì)UML類圖運(yùn)用分析函數(shù)確保前置條件滿足，然后執(zhí)行類圖重構(gòu)操作，最后通過分析函數(shù)驗(yàn)證后置條件和不變量是否滿足，是則結(jié)束，否則撤銷。

(3) 過程藍(lán)圖模型的重構(gòu)

過程藍(lán)圖的重構(gòu)執(zhí)行之前使用分析函數(shù)進(jìn)行模型的分析，在滿足前置條件的前提下執(zhí)行重構(gòu)操作，使用不變量來進(jìn)行行為保持驗(yàn)證，運(yùn)用樹變換操作來修改過程藍(lán)圖的三層模型，最后使用重構(gòu)變換系統(tǒng)執(zhí)行模型重構(gòu)變換，重構(gòu)變換系統(tǒng)需要分析函數(shù)、基本樹變換，重構(gòu)規(guī)格說明的支撐。使用重構(gòu)變換系統(tǒng)改變后的過程藍(lán)圖模型只有滿足后置條件和不變量才算是正確的重構(gòu)。

(4) 程序模型到程序源碼的正向變換

UML模型和過程藍(lán)圖模型執(zhí)行重構(gòu)操作之后，借助于UML建模工具和過程藍(lán)圖變換系統(tǒng)，都可以正向生成程序源碼，從UML模型生成的是程序的框架代碼，有利于對(duì)程序的基本結(jié)構(gòu)進(jìn)行把握。從過程藍(lán)圖模型生成可執(zhí)行的源碼，可以直接在開發(fā)平臺(tái)中進(jìn)行調(diào)試驗(yàn)證。

5　驗(yàn)證與比較

為了驗(yàn)證程序模型重構(gòu)實(shí)現(xiàn)框架的可行性，UML類圖重構(gòu)操作的正確性，過程藍(lán)圖重構(gòu)形式化定義的正確性，過程藍(lán)圖模型重構(gòu)的優(yōu)越性，我們同樣采用2.2節(jié)案例中提到的影片出租程序進(jìn)行實(shí)現(xiàn)。

5.1程序源碼重構(gòu)執(zhí)行過程

分解并重組Customer類的過長(zhǎng)方法statement()

(1) 運(yùn)用ExtractMethod()重構(gòu)將statement()中的switch代碼塊抽取成amountFor()方法，并在statement方法添加引用，thisAmount = amountFor(each)。

(2) amountFor()方法的某些變量名稱無意義，使用Rename()重構(gòu)將這些變量重命名，分析amountFor()方法時(shí)發(fā)現(xiàn)，使用了來自Rental類的信息，沒有使用Customer類的信息，故需要運(yùn)用MoveMethod()重構(gòu)將amountFor()方法搬移到Rental類中，再運(yùn)用Rename()重構(gòu)將amountFor()重命名為getCharge()，最后更新statement()方法中對(duì)舊函數(shù)的所有引用，修改為：thisAmount = each.getCharge()。

(3) 這時(shí)我們發(fā)現(xiàn)臨時(shí)變量thisAmount多余了，運(yùn)用ReplaceTempwithQuery()重構(gòu)將thisAmount去除，只需將thisAmount的引用全部替換成getCharge()。

(4) 使用類似(1)(2)(3)的方法，使用ExtractMethod重構(gòu)將“常客積分計(jì)算”代碼抽取為方法getFrequentRenterPoints()，然后替換引用為frequentRenterPoints += each.getFrequentRenterPoints()。

(5) 連續(xù)兩次交替使用ReplaceTempwithQuery和ExtractMethod和重構(gòu)，在類Customer中提取出兩個(gè)方法getTotalCharge()和getTotalFrequentRenterPoints()，替換掉臨時(shí)變量totalAmount和frequentRenterPoints的引用，去除臨時(shí)變量。

5.2UML類圖模型重構(gòu)執(zhí)行過程

這里只給出重要屬性的UML類圖，并借此來說明UML類圖重構(gòu)實(shí)現(xiàn)的過程。

(1) 分析源程序，構(gòu)造UML類圖模型，重構(gòu)操作執(zhí)行之前UML類圖模型如圖10所示。

圖10　初始程序的UML類圖

(2) 重構(gòu)分解并重組Customer類的過長(zhǎng)方法statement()，順序執(zhí)行UML類圖基本重構(gòu)操作ExtractMethod()，MoveMethod()和Rename()，得到如圖11所示的UML類圖。

圖11　抽取并移動(dòng)getChange()方法后UML類圖

(3) 再次順序執(zhí)行和(2)中相同的3種UML類圖基本重構(gòu)操作，得到如圖12所示UML類圖。

圖12　抽取并移動(dòng)getFrequentRenterPoints()方法后UML類圖

(4) 最后連續(xù)兩次順序交替使用UML類圖的基本重構(gòu)操作ExtractMethod()和ReplaceTempwithQuery()，最終得到如圖13所示的UML類圖。

圖13　重構(gòu)完成后的UML類圖

5.3過程藍(lán)圖模型重構(gòu)執(zhí)行過程

UML類圖模型重構(gòu)的直觀性框架為過程藍(lán)圖模型重構(gòu)在方法具體實(shí)現(xiàn)上提供了很好的指導(dǎo)。下面我們將以類圖模型重構(gòu)過程為基礎(chǔ)，展示過程藍(lán)圖模型重構(gòu)在方法級(jí)別的實(shí)現(xiàn)過程。

(1) 使用過程藍(lán)圖工具自動(dòng)化生成過程藍(lán)圖模型，并構(gòu)造中英文映射表和tokens，重構(gòu)之前的statement()方法的過程藍(lán)圖模型M的三層結(jié)構(gòu)分別如圖14-圖16所示。

圖14　重構(gòu)前statement()方法的抽象概念結(jié)構(gòu)圖-ACSD

圖15　重構(gòu)前statement()方法的抽象邏輯結(jié)構(gòu)圖-ALSD

圖16　重構(gòu)前statement()方法的抽象實(shí)現(xiàn)結(jié)構(gòu)圖-AISD

(2) 首先，在statemment()方法的過程藍(lán)圖模型M中對(duì)switch代碼段對(duì)應(yīng)的三層藍(lán)圖模型執(zhí)行ExtractMethod()重構(gòu)，提取新的方法amountFor()的過程藍(lán)圖模型M1，接著使用MoveMethod()重構(gòu)將M1搬移到Rental類中，成為新的過程藍(lán)圖模型M2，然后使用Rename()重構(gòu)將M2描述的方法amountFor()重命名為getCharge()，更新M中的引用。其次，使用相同方法對(duì)M中“?？头e分計(jì)算”對(duì)應(yīng)的三層藍(lán)圖模型執(zhí)行重構(gòu)，最終在Rental類建立getFrequentRenterPoints()對(duì)應(yīng)的過程藍(lán)圖模型M3，并在M中更新對(duì)M3的引用。最后，在上面的基礎(chǔ)上，連續(xù)兩次順序交替使用過程藍(lán)圖重構(gòu)操作ReplaceTempwithQuery()和ExtractMethod()，在Customer類中建立兩個(gè)新的過程藍(lán)圖模型M4和M5，M4描述方法getTotalCharge()，M5描述方法getTotalFrequentRenterPoints()。重構(gòu)完成之后各個(gè)方法所對(duì)應(yīng)的過程藍(lán)圖模型分別如圖17-圖21所示。

圖17　重構(gòu)后Renter類的方法getFrequentRenterPoints()的過程藍(lán)圖模型

圖18　重構(gòu)后Customer類的方法statement()的過程藍(lán)圖模型

圖19　重構(gòu)后Customer類方法getTotalFrequentRenterPoints()過程藍(lán)圖模型

圖20　重構(gòu)后Customer類的方法getTotalCharge()的過程藍(lán)圖模型

圖21　重構(gòu)后Renter類的方法getCharge()的過程藍(lán)圖模型

通過比較可以看出源碼重構(gòu)的可讀性差，難以找到需要重構(gòu)的地方，而且容易出錯(cuò)；UML類圖重構(gòu)直觀性好，效率高，但只能進(jìn)行類模型框架重構(gòu)；而過程藍(lán)圖重構(gòu)彌補(bǔ)了UML模型不能執(zhí)行過程級(jí)別重構(gòu)的缺點(diǎn)，并且藍(lán)圖模型與源碼一一對(duì)應(yīng)使得程序更易于理解，提高了重構(gòu)的效率和程序的可讀性。

6　結(jié)　語

本文研究了重構(gòu)操作在程序模型級(jí)別上的執(zhí)行實(shí)例，使用UML類圖執(zhí)行程序框架級(jí)別的重構(gòu)變換，運(yùn)用過程藍(lán)圖模型描述類的方法實(shí)現(xiàn)，執(zhí)行方法級(jí)別的重構(gòu)變換。

本文的貢獻(xiàn)主要包括：

? 在屬性、方法、類三個(gè)層次上定義了新的類圖基本重構(gòu)操作。

? 給出三種代表性類圖模型基本和組合重構(gòu)操作實(shí)例。

? 完善過程藍(lán)圖模型重構(gòu)的形式化定義，新增分析函數(shù)、不變量、基本樹變換操作、重構(gòu)規(guī)格說明定義。

? 給出兩種代表性的簡(jiǎn)單和復(fù)雜過程藍(lán)圖模型重構(gòu)操作實(shí)例。

? 給出一種程序藍(lán)圖模型重構(gòu)的實(shí)現(xiàn)框架。

? 進(jìn)行了源碼重構(gòu)、UML類圖重構(gòu)，過程藍(lán)圖模型重構(gòu)實(shí)驗(yàn)驗(yàn)證與比較。

程序藍(lán)圖重構(gòu)實(shí)現(xiàn)框架有待于進(jìn)一步在大型的軟件系統(tǒng)中進(jìn)行驗(yàn)證，今后的工作中我們將進(jìn)一步完善過程藍(lán)圖工具對(duì)模型重構(gòu)變換的支持，最終給出一套具有較高價(jià)值的模型重構(gòu)方法和工具。

[1] Opdyke W F. Refactoring: A program restructuring aid in designing object-oriented application frameworks[D]. PhD thesis, University of Illinois at Urbana-Champaign, 1992.

[2] Fowler M. Refactoring: improving the design of existing code[M]. Pearson Education India, 1999.

[3] Khalil A, Dingel J. Supporting the evolution of UML models in model driven software developmeny: A Survey[R]. Technical Report, School of Computing, Queen’s University, Canada, 2013.

[4] Sunyé G, Pollet D, Le Traon Y, et al. Refactoring UML models[M].in UML 2001—The Unified Modeling Language. Modeling Languages, Concepts, and Tools. Springer Berlin Heidelberg, 2001:134-148.

[6] Van Der Straeten R, Jonckers V, Mens T. A formal approach to model refactoring and model refinement[J]. Software & Systems Modeling, 2007, 6(2): 139-162.

[7] Mens T, Taentzer G, Müller D. Model-driven Software Refactoring[C]//WRT. 2007: 25-27.

[8] Wüst.SDMetrics V2.31[EB/OL]. http://www.sdmetrics.com/, latest released: July 3,2013.

[9] El Sharqwi M, Mahdi H, El Madah I. Pattern-based model refactoring[C]//Proceedings of Computer Engineering and Systems (ICCES), 2010 International Conference on. IEEE, 2010:301-306.

[10] Reimann J, Seifert M, Aβmann U. On the reuse and recommendation of model refactoring specifications[J]. Software & Systems Modeling, 2013, 12(3): 579-596.

[11] 張雨薇, 候少杰. 基于 UML 自動(dòng)化重構(gòu)工具的研究[J]. 計(jì)算機(jī)與信息技術(shù),2005(5):32-37.

[12] 劉建賓.過程藍(lán)圖設(shè)計(jì)方法學(xué)[M].北京:科學(xué)出版社,2005.

[13] 楊林邦. 基于過程藍(lán)圖的重構(gòu)研究[D]. 汕頭大學(xué),2006.

[14] 易長(zhǎng)安. 基于類圖和過程藍(lán)圖的模型重構(gòu)操作的研究[D]. 汕頭大學(xué),2007.

[15] 梅新云. 程序模型重構(gòu)實(shí)現(xiàn)方法與工具[D]. 北京信息科技大學(xué),2011.

[16] 王俊飛. 程序模型再工程方法及其支撐工具研究[D]. 北京信息科技大學(xué)，2012.

[17] 胡偉奇. JAVA藍(lán)圖模式及其重構(gòu)方法研究[D]. 北京信息科技大學(xué)，2013.

[18] Roberts D B, Johnson R. Practical analysis for refactoring[M].University of Illinois at Urbana-Champaign,1999.

RESEARCH ON REFACTORING OPERATION EXAMPLES OF PROGRAM BLUEPRINT MODEL

Liang PengjuLiu JianbinZheng Liwei

(SchoolofComputerScience,BeijingInformationScienceandTechnologyUniversity,Beijing100101,China)

Refactoring is a technique to improve the comprehensibility and maintainability of software systems by changing their internal structure without altering their external behavioural properties. Although traditional source-level refactoring has been supported by a lot of refactoring tools, the refactoring of complex software is very difficult and is prone to error. In view of this situation, we put forward a program blueprint model hierarchy-based refactoring. Taking into account the intuitive feature of a UML model, we proposed the refactoring operations and implementation examples of UML class diagram model on system architecture. These operations provide a strong support for the refactoring implemented on software framework architecture. We have researched deeply the method of procedure blueprint model using a tree structure to describe the program, and defined in this paper the refactoring operations correlated to procedure blueprint as well as showed some specific examples and procedures of these refactoring operations. Finally, from the procedure blueprint model the new source codes can be generated. Experimental results showed that the refactoring on UML model and procedure blueprint model hierarchy improves the abstraction level and efficiency of refactoring. This method can effectively support the refactoring of complex software and reduce the error rate.

RefactoringUML modelProcedure blueprint modelProgram model

2014-07-15。

北京市教委人才培養(yǎng)模式創(chuàng)新實(shí)驗(yàn)區(qū)項(xiàng)目(京教函[2009]630號(hào));北京市教委科技計(jì)劃面上項(xiàng)目(KM201311232013)。

梁朋舉，碩士生，主研領(lǐng)域：模型驅(qū)動(dòng)架構(gòu)，過程藍(lán)圖。劉建賓，教授。鄭麗偉，講師。

TP311

A

10.3969/j.issn.1000-386x.2016.03.005