軟件設計中的模塊依賴研究

饒建農(nóng)

摘要：針對軟件開發(fā)中的模塊依賴提出了一種新的模塊間依賴模型。新模型的關(guān)鍵思想是依賴是由規(guī)范調(diào)節(jié)的，這樣不僅記錄了依賴的存在，而且記錄了依賴的質(zhì)量。單個模塊不一定只提供單個規(guī)范，每個依賴模塊可以通過不同的規(guī)范使用它。這種依賴的概念比傳統(tǒng)的概念更容易解釋一些常見的編程習慣用法，并為分析和設計提供了新的評價體系。

關(guān)鍵詞：模塊依賴;規(guī)范;依賴關(guān)系圖;耦合

中圖分類號：TP311? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）09-0078-03

開放科學（資源服務）標識碼（OSID）

1 背景

軟件設計者早就認識到模塊之間的依賴關(guān)系在評估設計中的意義。當模塊之間存在許多相互依賴關(guān)系時，系統(tǒng)更難理解，編碼分工的靈活性降低，局部變化將產(chǎn)生廣泛影響。盡管依賴性起著開創(chuàng)性的作用，但是大多數(shù)設計人員對依賴性是什么，以及如何表達依賴性只有模糊的認識。

盡管各種代碼依賴因其在分離編譯和程序分析中的作用而受到重視，但對設計依賴的重視卻很少。因此，依賴關(guān)系圖在程序設計中的作用要小得多，不能用作分析的基礎(chǔ)。

本文提出了一種新的依賴模型。該模型的工作還處于初步階段，但它確實解決了標準模型的一些問題，特別是更好地解釋了面向?qū)ο笤O計中的一些常見的習慣用法。

2 標準模型及其缺陷

模塊依賴的標準概念首先由Parnas[1]闡述，大多數(shù)開發(fā)人員都很熟悉。該系統(tǒng)被描述為一個圖，節(jié)點表示模塊，邊表示語法依賴關(guān)系。每種模塊關(guān)系可以賦予不同權(quán)重，邊上的權(quán)值是模塊間存在多種關(guān)系的權(quán)值和[2]。模塊A對模塊B的依賴，如從A指向B，表明A在向依賴它的模塊提供服務時，使用了B。

在進行軟件工程開發(fā)時，盡管使用了“模塊依賴圖”來解釋軟件設計的思路，但是只有這些圖是不充分的，因為它們通常不能捕捉到促進設計的洞察力，在相關(guān)概念上存在一定的缺陷。

1） 傳遞性。根據(jù)定義，依賴關(guān)系是可傳遞的，而直觀上它不應該是。如果A使用B和B使用C，那么，在沒有附加信息的情況下，必須假設對C的任何變化都會影響B(tài)，從而間接地影響A，從而A使用C。但是，也許B是在A和C之間插入的，以保護A不受到C的變化的影響，而對C的大多數(shù)變化都不會影響A。

2） 多態(tài)性?，F(xiàn)代語言的關(guān)鍵元素，如多態(tài)性和接口，沒有得到適應?？紤]一個典型的Java程序，其中客戶端類C使用哈希表類H和鍵類K，H依賴于K嗎？一方面，H的代碼沒有引用K的代碼;另一方面，H很可能屬于K之前編寫的庫，對K的更改肯定會導致H失敗。例如，如果K的Equals和Hashcode方法不兼容，就會違反Hashtable的一個關(guān)鍵表示（相同的鍵保留在相同的Bucket 鏈中），并且使用給定鍵進行查找可能不會返回最后插入到該鍵下面的值。

3）先決條件。給模塊提供一個錯誤的過程參數(shù)會導致它失敗。如果模塊的規(guī)范規(guī)定了一個前提條件，那么設計人員的意圖是將錯誤輸入的責任歸咎于調(diào)用模塊。但是一個模塊不能簡單地被稱為“使用”調(diào)用它的模塊。

4）替換。由于A對B的依賴并不表示A實際使用了B的哪些屬性，因此無法判斷B的哪些屬性應該保存在替換它的模塊中。因此，依賴關(guān)系圖不能用來解釋組件的兼容性。

3 新模型

提出的新模型是基于兩個簡單的想法。首先，依賴表示一個假設：如果A的設計者或?qū)崿F(xiàn)者對插入A的環(huán)境做出一個假設，那么模塊A依賴于模塊B，這個假設通過B的存在在構(gòu)造的系統(tǒng)中被證明是正確的，原因可能是因為假設A以一定的頻率執(zhí)行;或者傳遞給它的值滿足某些條件;或者通過過程調(diào)用返回給它的值，與它以某種方式傳遞給它們的值有關(guān)。其次，依賴關(guān)系是由規(guī)范協(xié)調(diào)的：一個模塊不直接依賴于另一個模塊，而是依賴于另一個模塊必須滿足的特殊要求。模塊A對模塊B的依賴關(guān)系是由專門指令S所規(guī)范的，這意味著模塊A假設S保證的條件，系統(tǒng)通過B配置來提供這些條件。

新模型解決了標準模型的一些缺陷但并非全部缺陷。

1） 由于插值規(guī)范，不存在傳遞性問題。如果A通過規(guī)范S依賴于B，而B通過規(guī)范T依賴于C，那么很明顯，保留T所要求的行為的C的變化不會影響B(tài);而影響B(tài)的變 化，只有那些導致B不再滿足S的變化才會影響A。

2） 闡明了多態(tài)模塊的使用。哈希表H通過規(guī)范對象依賴于它的鍵類K，在Java中被稱為“對象契約”。H對K的依賴是配置的一項工作：在這種情況下，由于一些客戶端類C將K類型的對象傳遞給哈希表類H。H的設計者不期望預測K的使用，但可以假設任何對象被用作鍵的類都會滿足對象。

3） 前置條件表示為相反方向的依賴關(guān)系，前置條件和后置條件可以看作是與不同方向的數(shù)據(jù)相關(guān)的不同規(guī)格。

4） 關(guān)于替換的推理很容易成為使用規(guī)范的副產(chǎn)品。一個模塊的依賴，使規(guī)范S中描述的假設將被適當?shù)乇Ａ簦绻蕾嚨哪K被一個也滿足S的模塊所取代。如果將某個模塊視為未解釋的名稱（這通常很方便），則可以使用一個明確的排序來證明不涉及精確匹配的替換是正確的。

規(guī)范在傳統(tǒng)模型中出現(xiàn)，至少是隱含的，但它們扮演了不同的角色。在Parnas的公式中，相關(guān)的是使用模塊的規(guī)范，而不是使用模塊。此外，在我們的模型中，規(guī)范是與依賴相關(guān)而不是與模塊相關(guān)。一個單獨的模塊可能有多個規(guī)范，每個規(guī)范表示一個模塊的視圖，并提供給依賴于它的另一個模塊。在哈希表示例中，鍵類K出現(xiàn)在規(guī)范對象下的哈希表類H中，但在提供特定域?qū)傩缘母鼜娨?guī)范下，它可能出現(xiàn)在客戶端類C中。

4 案例研究

許多“四人組”的設計模式[3]都是出于依賴性的考慮。下面舉例說明觀察者模式的依賴模型。

圖1中顯示了與觀察者重構(gòu)的程序片段的依賴關(guān)系圖。左邊的原始程序有一個主題類Subj和一個具體的觀察者類Cobs。通過對特定的Cobs的過程的調(diào)用，從客戶端類客戶端向Subj的更新傳播到Cobs。已經(jīng)用規(guī)范Cobs標記了這種依賴性：使用規(guī)范的模塊名稱是為了建議規(guī)范承諾模塊設計提供的所有屬性。

右邊的重構(gòu)程序主要不同于中介依賴關(guān)系的規(guī)范。關(guān)鍵的區(qū)別在于Subj不再通過專門化Cobs與Monterey.cobs相互作用，而是通過一個更弱的規(guī)范Cobs，一個可用于其他觀察類的通用觀察專門化Cobs。這就是觀察者的核心動機：它允許添加新的觀察者類，而不需要更改Subj的代碼。通過規(guī)范Get表示Cobs現(xiàn)在必須向Subj調(diào)用以獲得狀態(tài)更新，從Cobs到Subj存在一個回依賴關(guān)系。

對客戶端類Client和主題Subj之間的關(guān)系進行了細化，以顯示兩種不同的交互。規(guī)范更新中介的依賴表示服務Subj在響應客戶端的請求更新其內(nèi)部狀態(tài)時提供的依賴。標簽Reg代表Subj提供的注冊服務，其中一個對象被添加到其內(nèi)部觀察員記錄中。有兩個與Reg相關(guān)的依賴關(guān)系，顯示為雙向箭頭，對應于注冊操作的前置和后置條件。前置條件顯示為從Subj到Client的箭頭，表示Client有義務避免注冊可能創(chuàng)建觀察周期的觀察者。

最后，Client對Cobs有一個新的依賴關(guān)系，因為客戶端類現(xiàn)在需要在注冊觀 察者對象時處理它。假設Client創(chuàng)建觀察者對象，可以用規(guī)范ConsObs來標記依賴關(guān)系，以表示構(gòu)造函數(shù)的使用，但可能沒有其他操作。

典型的設計模型是代碼在某些方面變得更加復雜。應用模型后有更多的依賴，但它們更系統(tǒng)地組織起來。最重要的是，行為的某些方面被考慮到由通用規(guī)范（Reg和 Obs）引導的依賴，這些規(guī)范是模型的標志。

5 結(jié)束語

5.1 規(guī)范調(diào)節(jié)依賴

程序的依賴結(jié)構(gòu)不能簡單地從其代碼中提取。一方面，確定一個系統(tǒng)中哪個模塊履行另一個模塊的假設所產(chǎn)生的責任可能并不容易。在哈希示例中，要找到哈希模塊H對關(guān)鍵模塊K的依賴關(guān)系，至少需要進行基于類型的分析，以確定哪些類型的對象被插入到表中。此外，依賴關(guān)系代表了設計者對如何在模塊之間劃分責任的主觀看法。在觀察者的例子中，采取了傳統(tǒng)的抽象數(shù)據(jù)類型觀點，主題類和觀察者類間接地為客戶端提供服務。但是一個同樣成立的觀點是，觀察者類依賴于其他類的服務：它的規(guī)范要求它顯示某些狀態(tài)更改，因此它需要通知這些更改何時發(fā)生。在這個觀點中，從Subj到Cobs的通知依賴被逆轉(zhuǎn)。類似地，在哈希示例中，對密鑰的關(guān)注可能被表示為從哈希類H到客戶端類C的先決條件依賴關(guān)系，該類將錯誤密鑰傳遞給H的責任分配給C。

依賴關(guān)系圖不應與類圖或?qū)ο竽Ｐ突煜?。類圖只是面向?qū)ο蟪绦虻木浞ńY(jié)構(gòu)的圖形表示，顯示繼承層次結(jié)構(gòu)以及實例變量的源類和目標類。對象模型是堆不變[4]的圖形表示：因此，在語義上，模塊依賴圖是句法的。

由于一個模塊不僅可以被視為需要多個服務，而且還可以提供多個服務，因此跟蹤兩者之間的關(guān)系可能是有用的。豐富的依賴關(guān)系圖可能包括每個模塊的傳入和傳出規(guī)范之間的關(guān)系，然后可以執(zhí)行一種“模塊切片”，遵循模塊之間和模塊內(nèi)部的依賴關(guān)系。模塊間接依賴的一組模塊可能比僅僅通過跟蹤模塊之間的依賴邊緣而獲得的一組模塊小，特別是對于面向?qū)ο蟮某绦颍渲蓄愃缪莸摹敖巧蓖ǔＴ诤艽蟪潭壬鲜仟毩⒌?。在觀察者示例中，這樣的分析將表明Reg對Subj的依賴沒有進一步傳播，相反，更新依賴被傳播到Obs和Get依賴。

在提出的新模型或標準模型中沒有捕捉到一些重要的耦合形式，最顯著的是那些由于共享而產(chǎn)生的耦合。假設模塊M使用模塊W編寫一個文件，模塊R讀取它，W寫文件的格式必須與R讀文件的格式相同。因此，對W的更改可能會破壞R，但兩者都不能為對方提供服務，因此依賴的標準概念在它們之間找不到耦合。

5.2 未來的工作

提出的新模型為軟件設計及其原理提供了一些新的見解，但它還遠未完成。未來需要完成的工作包括：

1）整理依賴關(guān)系和代碼之間的關(guān)系，并開發(fā)提取至少近似依賴關(guān)系的分析算法。在Java中，應該可以使用基本的類型推斷來查找依賴關(guān)系，并從顯式使用接口或使用類方法的子集來合成規(guī)范標簽，調(diào)查在推理系統(tǒng)的哪些部分損害關(guān)鍵模塊時使用依賴關(guān)系。前置條件依賴為代表傳統(tǒng)模型所忽略的耦合提供了一些希望。

2）找到一種方法來表示由于共享而產(chǎn)生的耦合，可能是使用ML編程語言的共享約束[5]或單元[6]的參數(shù)綁定約束。

3）更好地理解依賴關(guān)系在軟件工程中的作用，也許可以按照Epinger在設計結(jié)構(gòu)矩陣及其應用方面的常規(guī)工程工作的思路。

參考文獻：

[1] Parnas D L.Designing software for ease of extension and contraction[C].IEEE Transactions on Software Engineering，1979，5（2）.

[2] 杜欣，趙康，倪友聰，等.一種基于邏輯的Java模塊依賴圖構(gòu)建工具[J].計算機應用與軟件，2016，33（4）：6-10.

[3] Erich Gamma，Richard Helm，Ralph Johnson，et al.Design Patterns： Elements of Reusable Object-Oriented Software[M].Addison Wesley，1994.

[4] Daniel Jackson.Object Models as Heap Invariants[M]//Carroll Morgan，Annabelle McIver. A chapter in： Programming Methodology.Springer Verlag，2002.

[5] Robin Milner，Mads Tofte，Robert Harper，et al.The Definition of Standard ML （Revised）[M].MIT Press，1997.

[6] Flatt M，F(xiàn)elleisen M.Units： Cool modules for HOT languages[C].Proc. Sigplan 1998 Conference on Programming Language Design and Implementation，1998：236-248.

【通聯(lián)編輯：謝媛媛】