天天看點

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

作者:蘇荨墨
随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

文|蘇荨墨

編輯|蘇荨墨

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

前言

在當今數字化和快速發展的世界中,企業軟體的一個重要問題是能夠快速适應新的或不斷變化的功能或跨功能需求。

這個問題由軟體品質屬性演化性(有時也稱為可修改性或可變性)解決:可以修改軟體系統以适應或擴充它的有效性和效率的程度。

随着面向服務的計算 (SOC) 的興起,實作了與此品質屬性相關的幾個好處,比如松散耦合,隔離業務相關接口背後的服務實作,或者友善的重用群組合。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

雖然面向服務的架構 (SOA) 仍然是一種重要的架構風格,但微服務作為一種靈活、輕量級和分散的面向服務的變體越來越受歡迎。

一種常用的增強可修改性的工具是設計模式的應用。

将這些既定的解決方案藍圖用于反複出現的問題在面向對象的系統中尤為常見。

然而,還有大量專門為基于服務甚至基于的系統設計的模式。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?
随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

設計理念在系統中的實作

設計模式的思想起源于Alexander的建築和城市建設語言,他們将解決方案藍圖網絡概念化。

該概念适用于包括計算機科學在内的其他幾個領域,并且在軟體工程和軟體體系結構中非常流行。

是以,模式是針對重複出現的設計問題的經過驗證和确定的解決方案,它以與技術無關的形式記錄,并且可以以許多相似但不完全相同的方式實施。

文檔在模式語言中通常是系統化和标準化的,并且包括例如上下文、問題、力量、解決方案或相關模式等屬性。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

使用模式的一個主要驅動因素是它們對可用性、性能或可修改性等 QA 的影響。已經進行了幾項研究來分析這種複雜且有争議的關系。

在面向對象設計的背景下,必須分析和修改四個 UML 類圖,一組使用标準和直接的設計模型,而另一組使用語義等效的版本,其中包含設計規則(例如,“類之間的依賴關系必須用抽象實作。”)和模式(例如狀态或組合)。

測量了可了解性(通過問題)和可修改性(通過擴充任務),結果表明,帶有規則和模式的後一版本更難了解(非模式版本的時間減少了 58%,正确答案增加了 15%)。對于可修改性,無法确定效率的統計顯著差異。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

使用基于 ISO/IEC 9126 的機率品質模型來分析 Java GUI 架構 JHotDraw 的 300 多個修訂版的可維護性,該架構采用衆所周知的面向對象模式。

JHotDraw 中設計模式的每一次使用都記錄在 JavaDoc 中,并且有很多僅引入模式的修訂。

分析中得出結論,額外模式的引入提高了系統的整體可維護性,測量了模式線密度和可維護性之間的強相關性。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

對于 17 項實證研究的比較文獻分析表明,僅檢查了四個 QA 和模式的一小部分,此外,還沒有就影響(正面、中性或負面)達成普遍共識。

有趣的是,對于可維護性、演化和變更傾向,有關所分析模式的影響的總體趨勢是負面的。

通過架構政策的代理來确定模式對 QA 的量化影響,從這些結果中,得出結論,例如,模型視圖控制器最适合性能而最不适合安全性,而層模式最适合安全性。

進行了一項系統的映射研究,目的是描述以人類為對象的關于軟體模式應用的實證研究的研究設計。

30 項研究中有 16 項涉及維護是最常見的情況,将近一半的研究與面向對象的設計模式有關。

效率和正确性是評估模式應用的最常見名額,報告說,實驗設計的差異使得比較結果變得困難,而且一些研究沒有提到局限性以及它們如何最大限度地減少偏差的威脅。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

在面向服務的背景下,通過力解析圖(從 -2 到 +2 的影響)對 80 個基于服務的設計模式與 S-Cube 品質參考模型的 QA 進行了理論定性映射。

報告還說,來自非常詳細的 S-Cube 模型的 53 個 QA 沒有被模式解決。

大多數映射的 QA 都是性能和可擴充性,由于 S-Cube 不包括一些重要的 QA,還使用了 ISO/IEC 9126,為了可維護性,總共确定了 12 種模式。

最後,通過收集FraSCAti 系統的曆史軟體開發中繼資料分析了基于服務的模式和反模式對維護和演化的影響。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

觀察到模式中涉及的服務需要較少的維護工作,然而,這種影響在統計學上并不顯着。

另一方面,發現具有反模式的服務需要更多的維護工作,尤其是對于God Component或Service Chain的執行個體。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

最終對實驗對象的目的

所呈現的相關工作概述了模式和 QA 之間的複雜關系以及有争議的證據,一般而言,針對基于服務的模式及其可修改性的實證定量研究并不多,這就是為什麼目标是通過第一個受控實驗的結果以及基于度量的分析,對這種關系帶來更多的定量見解。

實驗的研究目标是根據在給定時間内完成修改(有效性)和每次修改所需的時間(效率)來分析所選的基于服務的模式是否對系統的可演化性産生重大影響。

實驗對象是一個簡單的基于服務的網上商店系統,專門為本實驗建構,它由幾個 RESTful Java 服務組成,例如客戶、訂單、産品和通知,以及一個基于 Web 的前端。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

資料持久化和不必要的建立讀取更新删除 (CRUD) 操作尚未完全實作。

是以,該系統相當接近真實世界的網上商店,但對于實驗來說仍然具有可控的複雜性。

選擇線上商店域是因為大多數人根據個人經驗對它有所熟悉,此外,以面向服務的方式實作此類系統非常普遍。

還為這個網上商店建立了兩個功能相同的版本,一個版本是以“普通”方式建構的(請參閱圖1和圖2)。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

圖1

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

圖2

而另一個版本是用幾個基于服務的模式設計的,這些模式被認為有利于可修改性,例如流程抽象和服務外觀(請參圖3和圖4)。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

圖3

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

圖4

一般而言,系統的模式版本表現出更高的基礎複雜性(例如,更多服務、特殊模式),但已認證使用的模式有意為任務修改的性質做好準備。

之是以選擇這些模式,是因為它們在可進化性方面的理論優勢已得到充分證明。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

實驗的目标人群

雖然熟悉基于服務的系統和模式的專業軟體開發人員可能是合适的實驗對象,但是仍然選擇了更多沒有經驗的開發人員,即學生。

首先,很難說服大量軟體專業人員免費花費兩個小時的寶貴時間進行看似毫無意義的編碼。

其次,如果這些模式的優勢即使對于那些對模式知之甚少或根本不了解的經驗不足的開發人員來說也是如此,那麼它們對可演化性的影響一定是巨大的。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

然而,雖然在軟體工程實驗中使用學生是很常見的,但在将結果推廣到所有開發人員時必須更加小心,從好的方面來說,學生通常是相當同質的參與者。

是以,實驗對象是大學生,他們需要作為“軟體工程概論”講座的一部分參加實驗。

學生可以根據簡短描述選擇兩個實驗之一,資料收集是匿名的,實驗表現對學生的成績沒有影響。

在沒有收集資料的情況下參與實驗也有可能通過課程,在實驗執行期間,學生通過在 PC 撞球室中選擇一個座位,将自己随機且不知不覺地配置設定到兩組中的一組:非模式版本 #1,即控制組,或模式版本 #2 ,即是治療組。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

作為實驗材料,在大學 PC 機房為學生提供了一個完全配置的虛拟機。

他們有數字和印刷形式的文檔和任務描述,如果出現問題,他們可以使用網際網路搜尋。

還提供了一個帶有自動測試的 Web 界面,用于驗證三個任務中每一個任務的完成情況,建議學生使用自己選擇的秒表測量每項任務的時間。

參與者必須解決總共三個互相依賴的任務(見表2)。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

表2

在第一個任務中,應調整網上商店系統的訂購流程(例如,客戶信用評級檢查)并擴充一個額外的流程步驟(通過 發送電子郵件)。

版本 #2 已準備好流程抽象模式,是以所有更改都必須在版本中實作,訂單程序服務而不是像版本 #1 中那樣在三個不同的服務中實作。

在第二項任務中,必須将大型訂單程序服務分解為三個較小的服務:aProductSrv僅管理産品域實體,aCategorySrv管理産品類别,aWarehouseSrv管理産品可用性。

版本 #2 結合了分解能力模式以簡化分解和服務門面使前者免受ProductSrv消費者侵害的模式。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

在最後的任務中,應實施一個新流程以響應将新産品添加到資料庫(發送電子郵件并将新産品添加到營銷資料庫)。

版本 #2 通過代理提供了基于消息的通信,該代理允許釋出一個,它實作了事件驅動消息傳遞和通信反轉NewProductEvent模式。

作為實驗的響應變量,分析了有效性和效率(每項任務的持續時間)。

參與者的有效性衡量為他/她在 90 分鐘内成功完成的三項任務的百分比,即 0%、33%、67% 或 100%。

效率以秒為機關記錄,如果任務未完成,則效率不可用,每組的中位有效性僅針對所有三項任務的總和進行計算和測試。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

為了平均效率,還分析和比較了每個單獨的任務,以得出每個模式的效果。

雖然這兩個響應變量也取決于參與者的技能,但如果兩組足夠大且技能大緻相等,則它們可以表征系統的可進化性。

預測變量是組或系統版本(即對照組或治療組),它要麼是非模式版本的#1,要麼是模式版本的#2。

為了形式化我們的研究目标,其中i表示研究目标辨別符,如果每個目标有多個假設,則j表示計數器(參見表3)。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

對于有效性(i = 1),我們有一個假設(j = 1),而對于效率(i = 2),,即每個任務一個,一個用于一次完成一組任務。

由于有五個假設,這也意味着需要對假設檢驗的顯着性水準進行,以解釋 I 類錯誤機率的增加。

是以,必要的顯着性水準 α 是通過将所需的顯着性水準除以假設數來計算的,即 α = 0.05/5 = 0.01。

對于分析,每個參與者記錄的任務持續時間測量首先與通過參與者 ID 導出的調查結果相結合。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

結語

然後,将生成的資料集分為兩組(版本#1 和版本#2),并使用描述性統計對其進行分析。

最初,希望確定兩個版本具有可比的特性和體驗,這在大多數領域都是如此(見表 4)。

随着軟體品質的演化性,面向服務模式對資料有着怎樣的發展?

表4

平均而言,第 1 組有 36 名參與者,第 2 組有 33 名參與者,他們的學習計劃分布和學期大緻相同 (2.5)。

是以經實驗确定,在這類實驗中出現的問題,都會是成為問題解決的根本,也是需要操作空間的,這也表示提供單個操作平均所需的 LOC 數,較大的LOC/WSIC值意味着服務具有較大且可能很複雜的操作。

繼續閱讀