可依賴軟件設計的關注點分離的研究

饒建農

摘要：對于具有關鍵和非關鍵功能的“混合臨界”系統(tǒng)，對可靠性的最大影響可能是在設計級別。通過設計使每個關鍵需求都有一個小的可信基，可以大大降低可靠性案例所需的分析成本。該種方法的一個含義是，傳統(tǒng)的面向對象設計可能是一種責任，因為它會導致“糾纏”，而基于分離服務的方法可能更可取。

關鍵詞：關注點分離;可信基;解耦;糾纏;混合臨界系統(tǒng)

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

文章編號：1009-3044（2021）04-0240-02

1 背景

“關注點分離（separation of concerns）”是軟件工程中的一個基本原則?！瓣P注點分離”原則要求軟件設計人員能夠以模塊化的方式實現各關注點[1]。 “關注點分離”是對只與“特定概念、目標”（關注點）相關聯的軟件組成部分進行“標識、封裝和操縱”的能力，即標識、封裝和操縱關注點的能力。是處理復雜性的一個原則[2]。由于關注點混雜在一起會導致復雜性大大增加，所以能夠把不同的關注點分離開來，分別處理就是處理復雜性的一個原則，一種方法。

“關注點分離”是面向對象的程序設計的核心概念。分離關注點使得解決特定領域問題的代碼從業(yè)務邏輯中獨立出來，業(yè)務邏輯的代碼中不再含有針對特定領域問題代碼的調用（將針對特定領域問題代碼抽象化成較少的程式碼，例如將代碼封裝成function或是class），業(yè)務邏輯同特定領域問題的關系通過側面來封裝、維護，這樣原本分散在整個應用程序中的變動就可以很好的管理起來。

2 過程和測試

當今的軟件開發(fā)人員依靠兩種技術來使他們的軟件更加可靠：過程和測試。

在任何大型軟件開發(fā)中，定義軟件過程都是必不可少的，沒有它，標準就很難執(zhí)行，問題就會陷入無解，組織就無法從過去的錯誤中吸取教訓。通常，一個過程可以包括版本控制、錯誤跟蹤和回歸測試的程序;還包括文件的標準結構和會議指南（用于需求收集、設計和代碼審查）;最重要的是必須包括詳細的統(tǒng)計數據和相應調整過程的明確機制。通過將問題領域和實現領域的關注點分離，以及各類軟件開發(fā)技術和技能的分離，實現了軟件開發(fā)工作責任的分離和人員的分工，為大規(guī)模軟件開發(fā)提供了合作基礎[3]。

測試用于兩個非常不同的目的。一方面，它被用來尋找BUG。結構測試利用軟件結構的知識來識別已知類別中的錯誤。例如，突變測試可能側重于選擇錯誤運算符進行表達式的可能性;回歸測試旨在檢測特定缺陷的再發(fā)生。另一方面，測試可以用來提供可靠性的證據。在這種情況下，側重于特定已知BUG類別的測試不太有用（因為故障可能來自尚未識別的類別）。 相反，測試是隨機地從“操作配置文件”的基礎上進行的抽樣測試。對于這種測試，一個成功的測試是一個成功的測試用例，因為一個失敗的測試用例可能不僅需要一個錯誤修復（它將測試工作設置為平方，因為測試的目標現在是一個新的程序，舊的結果不再獲得），而且提供了低質量的直接證據，從而改變了測試者的假設，提高了顯示可靠性的標準。

對于適度的可靠性，過程和測試被認為是有效的，并且被廣泛認為是任何發(fā)展的必要組成部分。關于過程和測試應該采取什么形式的爭論仍然存在：例如，過程應該遵循增量方法還是更傳統(tǒng)的瀑布方法，或者單元測試或子系統(tǒng)測試應該占主導地位。但很少有人會認為過程和測試是不好的想法。然而，對于關鍵應用程序所需要的高度可靠性，過程和測試，雖然是必要的，但似乎又是不夠的。盡管多年來在開發(fā)程序和進行廣泛測試的組織中積累了經驗，但幾乎沒有令人信服的證據表明這些努力確保了所需的可靠性水平。盡管采用嚴格的程序似乎會間接影響可靠性，但又缺乏直接聯系的證據。

統(tǒng)計測試的有效性是問題的核心，因為一個過程建立可靠性的最可能的方法是通過測試，就像工業(yè)制造中從裝配線上通過測量樣品來實現質量一樣。不幸的是，即使可以適當地對業(yè)務概況進行抽樣，并且所有其他統(tǒng)計假設都成立，但建立信心所需的測試數量很少是可行的。要檢測R執(zhí)行中的失敗率或要求99%的可信度需要執(zhí)行大約5R次測試[4];同樣，R小時內的一個失敗率需要測試5R小時。

3 正式驗證方法

近幾年來，借鑒系統(tǒng)安全領域的經驗，提出了一種不同的方法。這個想法是，開發(fā)人員不依賴于來自過程或測試的可靠性的間接證據，而是通過提出一個將軟件與可靠性索賠聯系起來的論點來提供直接證據。這一論點被稱為可靠性案例，它以軟件系統(tǒng)的代碼和與其交互的領域（如硬件外圍設備、物理環(huán)境和程序員）的假設為前提，并從這些前提中或多或少地建立一些特定的關鍵屬性。

可靠案例的可信度，就像任何論點的可信度一樣，將取決于各種社會和技術因素。有時，它可能包括統(tǒng)計參數，盡管邏輯參數可能發(fā)揮更大的作用。為了論證一個組件的故障率低于1/109 ，需要對組件進行詳盡的測試，但這種為獲得足夠的統(tǒng)計信心而進行的測試可能過于昂貴，因此正式驗證將是一個更可行的選擇。正式驗證方法在可靠情況下可能發(fā)揮關鍵作用，因為沒有其他方法可以以更合理的成本提供可比性。但是，嚴格的過程并不能保證可靠性，使用正式驗證方法也不能完全保證可靠性。正式驗證只有在它在可靠性參數中提供了關鍵鏈接的情況下才有用。堅持使用特定的方式，或消除特定的異常現象，不可能比強加任何其他過程實踐更具成本效益（如DO178B對MCDC的要求測試）。雖然知道程序不會出現算術溢出或超過數組的界限是很有用的，但這些知識并不能提供任何直接證據，證明軟件不會導致災難性的故障。事實上，構建一個可依賴系統(tǒng)軟件[5]表明，運行時錯誤的風險不是鏈中最薄弱的環(huán)節(jié)。

4 構建可信基

統(tǒng)計測試的一大吸引力在于它的成本不取決于被檢查的軟件的大小。通過對有可能被用作可靠性案例的元素分析，由于其依賴于檢查軟件的文本，測試成本至少隨著文本大小而線性增加。這突出了簡單設計的重要性。代碼越小，越簡單，為其正確性構建案例的成本就越低。但現實的目標不是縮小整個程序的大小，而是必須考慮子程序的大小，以證明一個關鍵屬性是成立的。 該子程序是關鍵屬性的可信基，它不僅必須包括直接實現相關功能的代碼，而且還必須包括可能破壞該屬性的任何其他代碼。

假設可靠性必須建立系統(tǒng)的k屬性，并且每個屬性都有一個大小為B的可信基。分析成本很可能是超線性的;一個合理的猜測是，它將是二次方的，以解釋組件之間的相互作用。在這種情況下，總成本為kB2?，F在，如果受信任的基覆蓋整個程序（但不重疊），則總碼基的大小為kB。對于相同的代碼庫，不考慮可信基，分析的成本將是k（kB）2。即使分析成本僅在可信基的大小上是線性的，但在大小為kB的碼基上分析k屬性的成本將是k2與分析k屬性的成本kB相比，每個屬性都超過了大小為B的可信基。這種分析沒有考慮到分析不同屬性所涉及的工作重疊的可能性。例如，如果多個屬性需要通信信道的可靠性，則可能只確定一次該信道是可靠的，以便對其代碼進行一次分析。在經典的驗證方法（尚未在大規(guī)模系統(tǒng)上完全實現）中，每個組件都根據其規(guī)范進行驗證;然后，高級別屬性只需要使用最大組件的規(guī)范在頂層進行分析。

對大多數系統(tǒng)來說，不同的屬性在不同程度上至關重要，因此需要不同程度的信心和不同程度的投資。此外，在可靠性的前提下，應用程序的許多功能根本不需要考慮。例如，對于在線書店，對于處理搜索、廣告和評論的功能，常規(guī)測試可能足以建立應用程序可開發(fā)的信心。而與此相反，信用卡號碼不被泄露，或者客戶按所顯示的金額計費的屬性可能更值得構建一個可靠的案例。

對于混合臨界系統(tǒng)，臨界屬性對于整體功能來說是尤其重要的部分，以至于很少有機會進行共享子程序分析;驗證規(guī)范中分析多個屬性的組件的成本通常是不合理的。此外，臨界屬性的高方差使系統(tǒng)被分割成多個可信基是值得的，理想情況下，構建與更關鍵的屬性相關聯的較小的可信基也是值得的。

5 脫鉤機制

由于兩個不同的原因，關鍵屬性的可信基可能大于可取的可信基。一種是，實現該屬性的代碼不像想象的那樣本地化。另一種是相關的代碼被適當地本地化，但需要對其他模塊進行分析，以確定它們的代碼不相關。大多數人可能認為可信基的概念可以在執(zhí)行中而不是在分析術語中定義。如果模塊的失敗可能會破壞關鍵屬性，則可以將其包含在可信基中。因此，可信的基本思想提供了一個分階段分析的思路。在第一階段，穩(wěn)健但廉價的解耦分析（最好在設計級別進行），確定哪些模塊處于可信基中，因此是相關的;在第二階段，對這些模塊進行分析，以確保屬性保持不變。

在最簡單的情況下，解耦分析可以依賴于物理隔離，但更常見的是需要對虛擬隔離的吸引力，這是通過解耦機制實現的。各級都有這種機制。計算機及其操作系統(tǒng)可以提供地址空間分離，支持不同進程獨立運行的推斷;中間件平臺可以提供通信通道，隱式保證不可能有其他交互;編程語言可以提供名稱空間訪問控制和強類型，從而可以封裝數據。在所有這些情況下，主張脫鉤，從而縮小可信基仍然需要履行一些假設的狀況。例如，在具有強類型的語言中，建立的兩個模塊之間缺乏交互將需要一個簡單的參數，即它們的名稱空間是不相交的（如果它們的類型重疊，也可能需要別名/轉義分析）。這種分析是有意義的，通常比隨后的分析成本要低得多，也就是分析相關模塊強制執(zhí)行所需的屬性，從而也證明了相分離和可信基的概念是合理的。相反，如果缺乏對解耦的支持，就不會有這種成本差異，而對較小的可信基的索賠將不會那么有用。例如，在用不安全語言（如C）編寫的程序中，任何一個模塊中的代碼原則上可以修改另一個模塊訪問的數據（例如，通過超出數組的界限和修改任意內存），無論它們的命名空間是否有重疊。

6 面向對象的糾纏

一個好的軟件設計（借助可用的解耦機制）為關鍵屬性提供了小的可信基。找到一個好的設計顯然需要洞察力、經驗和領域專長。然而，值得思考的是，傳統(tǒng)上使用的基本設計策略是一種幫助還是一種阻礙。

從可靠性和可信基的角度來看，面向對象實際上可能是一種責任。標準規(guī)范對共同屬性進行分組，將域實體轉換為單個程序對象不僅不能幫助解耦，而且可能通過創(chuàng)建不必要的特征糾纏而使情況變得更糟。例如，網上書店的設計。標準域模型可能包括諸如Customer、Book、Shopping Cart、Order、Credit Card等實體，當這些實體作為代碼中的類實現時，它們之間的關聯很可能被表示為字段（通常由關系數據庫的表支持）。更糟糕的是，這些關聯在語義上是雙向的，在代碼中通常會通過雙向引用來支持，以便于導航。獲取客戶購物車的字段將由購物車返回到客戶的字段匹配。因此，不能輕易地將與關鍵屬性無關的代碼考慮在內。如果財產是信用卡號碼，不是無意中顯示出來的，那么整個Customer類將是相關的，因為它的一個字段包含對客戶卡的引用;購物車也是相關的，因為它的背面引用了客戶。

與其解決面向對象的問題，不如從一開始就將系統(tǒng)構建為獨立服務的集合，然后以傳統(tǒng)的風格實現，并連接在狹窄的接口中。

在書店的例子中，搜索書籍、評論、廣告和計費都可以作為一種不同的服務來實現。要向客戶的信用卡收費，協(xié)調組件可以使用由服務內部映射到信用卡記錄的客戶標識符對賬單服務進行調用。在面向對象的整體實現中，此標識符將是客戶對象的地址，并且保持它允許客戶端訪問客戶的所有特性。與此相反，用于計費目的標識符的使用由計費服務的API控制。

在網絡書店等混合臨界系統(tǒng)中，與臨界屬性（如保護信用卡）相關的代碼比例可能很低，可能在5%或更低。因此，為一個小的可信基進行設計可能會使構建可依賴案例的成本降低，這可能會影響將來在語言設計、靜態(tài)分析或驗證方面取得的進展。

7 結束語

作為一個研究領域，軟件工程可以更少地強調語言和分析，更多地強調設計和方法?，F在很多研究都集中在事后分析和遺留代碼問題上。應該要改變這種研究方法，重新關注設計的根本問題。分析可以作為輔助，但可靠性不能作為事故出現。只有通過設計才能確定軟件的可靠性。

參考文獻：

[1] 梅宏，曹東剛.ABC-S2C：一種面向貫穿特性的構件化軟件關注點分離技術[J].計算機學報，2005，28（12）：2036-2044.

[2] Ober I，Ober I.On patterns of multi-domain interaction for scientific software development focused on separation of concerns[J].Procedia Computer Science，2017（108）：2298-2302.

[3] 何明昕.關注點分離在計算思維和軟件工程中的方法論意義[J].計算機科學，2009，36（4）：60-63.

[4] Littlewood B，Wright D.Some conservative stopping rules for the operational testing of safety-critical software[J].IEEE Transactions on Software Engineering，1997，23（11）：673-683.

[5] JACKSON D，THOMAS MILLETT L.Software For Dependable Systems：Sufficient Evidence[M].Washington DC：The National Acade mies Press，2007.

【通聯編輯：謝媛媛】