以體系結構為中心的分布式系統的程序變換

摘要:隨著需求和技術發展的日新月異，軟件開發已成為不可阻擋的趨勢。軟件質量及其生產率在軟件開發中起著至關重要的作用。以體系結構為中心的軟件開發有助于提升程序的質量，然而，它卻無法直接顯示軟件開發所需要耗費的時間。該文提出了一種關乎軟件質量和生產率且以架構為中心的程序變換策略，其著重于對架構的不同備選方案的相似性和差異性進行分析，從而有助于軟件架構開發工具或評估工具的發展。

關鍵詞:軟件質量;生產率;軟件構造工具

中圖分類號:TP311.52文獻標識碼:A 文章編號:1009-3044(2009)25-7154-03

Architecture in the Distributed System as the Center of the Program Change

WANG Tian-yu

(School of Information Engineering Shangdong University At Weihai，Weihai 264209，China)

Abstract: With the demand and rapid technological development， software development has become an irresistible trend. Software quality and productivity in software development plays a crucial role. Architecture-centric software development process and will also enhance the quality， however， it can not be directly displayed by the software development takes time. This paper presents a software quality and productivity related to the structure and process-centric transformation strategy， which focused on the structure of the different options of similarities and differences in analysis of software architecture in order to contribute to the development of assessment tools or development tools.

Key words: software quality; productivity; software construction tool

分布式軟件系統和應用程序在目前的互聯網時代早已屢見不鮮，并伴隨著新的需求和特性的出現而變得越來越復雜，因此，現有的分布式軟件系統的開發也變得十分復雜、費時，而且容易出錯。另外，軟件系統的開發通常停留在代碼層面，一般而言，其不如在架構層面有效，這是因為，軟件架構展示著主結構及其相互關系，以及系統的設計原理。一個軟件系統的大部分性能，如質量特性，是在其架構層中得到最佳展示及處理效果的。因此，架構層的軟件開發或者以架構為中心的軟件開發將更好地促進新需求的同步:不論是來自用戶抑或科學技術的需求、設計和實施。

然而，軟件開發企業也面臨著另外的挑戰——產品上市時間。軟件質量屬性——如性能、安全性、可靠性、適用性和可修改性是進行以程序架構為中心的設計的源動力。但是，其往往對軟件的上市時間產生的是不直接或明確的影響。事實上，對軟件生產商而言，在設計初期或開發階段的實際中，軟件的上市時間可能比其質量屬性作用更重要，尤其是在軟件開發這一競爭白熱化的領域。從軟件開發的角度來看，設計師可為軟件的非功能性需求采納新的軟件架構，比如上面提到的那些質量屬性。因此，通過一種不同的架構和/或新技術，對試圖將當前系統轉換為一個新系統的軟件開發人員而言，是極為重要的，因為這樣可以減少對時間的耗費并提高其他的質量屬性。

如上所述，分布式系統在當今社會已經司空見慣。然而，許多分布式系統的設計并未充分利用其領域一些新型科技的優勢。例如，使用單線程(ST)對在電信和無線應用中的系統進行研究。多線程設計的替代品，如Half-Sync/Half-Async (HS/HA)和Leader/Followers(LFs)這兩種設計模式[Schmidt00]，尤其可以提高軟件的性能。事實上，其中一個系統的研究是由ST轉化為HS/HA，另外一個系統是由ST轉化為LFs。分布式系統應用中的許多設計模式已被捕獲并記錄下來。一些較為低級模式的代碼有待設計細化;另一方面，展示出分布式的高級結構或架構。這兩種模式的實例在隨后被分為HA/HA和LFs。

即便上述的模式已被良好記錄下來，使用新技術將舊系統手動轉換為一個新系統也可能需要大量的時間或專業知識。Lung雜志系列刊登了一篇有關為了更高性能和服務質量需求對ST到HS/HA進行轉換的實證研究，這些需要淵博的知識和大量的努力。因此，本文旨在使用有良好記錄的設計模式進行工具的開發，以便于分布式系統程序之間的轉換。本文將重點探討兩個被普遍采用的并行模式:HS/ HA和LFs。

程序轉換工具的開發基于對現有系統的分析，包括使用相關設計模式進行總體框架和可重復利用組件的設計。工具使用Python語言編寫，用于將現有的使用Java的單線程技術設計的系統自動轉換為另外使用HS/HA和LFs高級并行設計模式之一的Java程序。設計模式的選擇由用戶決定。相對于手動轉換而言，用戶可以使用我們提供的軟件工具對現有系統進行更為便利的轉換，從而可大大節省轉換所需的時間，同時，由于工具已經進行了良好的測試和確認，軟件的質量也有保證。另外，一個單線程系統可通過使用工具轉換為HS/HA和LFs，以便對軟件架構進行調試或者進行高精度分析。

本文的其他章節劃分如下:第1章對一些相關工作進行介紹，第2章討論了程序轉換方法。第3章對程序轉換工具進行闡述，并通過實例說明工具的使用。最后的第4章對全文進行總結。

1 相關研究

由于在理論和實踐方面的重要性，設計模式在軟件工程學中已被廣泛認同。由于眾多不同的系統或特定的系統，設計模式也不盡相同。

Schmidt等人描繪了網絡和并行系統中的多種設計模式，它們包括程序服務的引入和類型配置、事件處理模式、同步模式和并行模式。程序服務的引入和類型配置主要用于處理有效的應用程序接口(APIs)，以在獨立式或聯網系統引入和配置服務和組件。

事件處理模式用于描述如何在聯網系統中對事件進行初始化、接收、多路信號分離、發送和處理。可分為四種類型:接收器、接收器的連接器、預處理器和異步處理標志。本文將對前三種模式進行研究。可利用組件的開發基于上面提到的用于程序轉換的三種模式。

并行模式展示了典型通訊軟件的多種架構。基于并行管理視角，本文選取了三種基本的架構，它們是:傳統的使用接收模式的單線程(ST)技術、HS/HA和LFs。選用ST的最初原因是其簡易性，更為重要的是，它是在現有系統研究中被采用的原始類型。許多系統也是通過使用ST技術進行開發的，其余兩種模式也由于在行業中的采用而被列于其中，HS/HA和LFs可潛在提升系統性能。

Lung介紹了通訊軟件中基于多種架構的基本變化分析。ST技術中的線程將通過select()功能對事件和到達的信息進行處理。但是，該技術經常導致數量方面的問題。解決途徑是，通過使用HS/HA和LFs模式之一作為總體架構。

LFs模式提供了與ST實例和那些同步線程相似的多線程的功能，但是，一次只允許對一個線程進行處理——引導器等候網絡事件的發生。其他的線程和事件就需要排隊等待，一旦引導器監測出事件，就會讓排隊的事件之一進入處理。換言之，變為進行服務處理的線程。另一方面，HS/HA將系統分為3層，異步層從網絡讀取信息并將它們儲存于隊列中，多線程從隊列讀取信息并將它們進行處理。

2 以架構為中心的程序轉換

如前章所述，那些不同的架構有著相似之處，但也有不同。每種架構各有其優劣，盡管一般而言，HS/HA和LFs可能會有更好的性能。雖然如此，軟件架構可能包括復雜的操作或行為。在實際的案例研究中，我們為了性能提升之需將網絡系統從ST轉換為LFs。但是，基于LFs模式的系統并不像預料中那樣比ST模式的系統性能更好。使用工具便利以架構為中心的軟件開發不僅可以節約時間，而且可在實際程序轉換前對正在運行的系統的架構評估進行提升。

以下所述的技術采用基于對以架構為中心的程序轉換的支持。技術的開發請見我們前面有關以架構為中心的多產框架的研究。框架的開發包括以下步驟:

1)在架構層對范圍進行限定并采取多樣化分析;

2)對現有機器軟件系統進行設計方面的恢復;

3)使用模型對現有系統進行再改造;

4)對多種架構進行評估;

5)添加可利用組件和框架。

第一章已經高亮顯示了第一個步驟，第二步強調的是，與其開發一個新系統，不如再利用現有系統的重要性。我們研究了多種多樣的系統，包括業界開發的網絡原型系統。設計的恢復過程提供的寶貴訊息對接下來的再設計幫助很大。我們使用以下設計模式對ST系統進行了人工干預:接收器、接收器的連接器，HS/HA和LFs。

接下來進行的是完整的ST、HS/HA和LFs軟件架構評估(突出強調其性能)。該過程有助于我們更好理解不同架構下的軟件質量屬性。最近的開發中采用的是包含以下可再用組件的框架——發送器、連接接收器、連接器、服務處理器、HS/HA和LFs，該框架允許用戶通過一種特別的方法(如ST、HS/HA或LFs)對系統作出選擇并使其運行。

本文通過工具開發層面對先前論點進行擴展，以支持基于用戶選擇的自動程序轉換。技術包含以下主要任務:

1)基于所選設計模式和現有系統，對架構/設計層之間的多種類型的相同點與不同點展開分析;

2)在組件層進行相似性分析;

3)在代碼層進行相似性分析;

4)進行從ST到HS/HA的人工轉換，并對結果進行核實;

5)對方案進行開發，為ST到HS/HA或LFs的轉換建造工具。

3 程序轉換工具

本章將介紹用于工具開發的技術。工具的最初版本在分析階段被調整用于整體的框架結構，工具主要用于ST到HS/HA和LFs之一的轉換。3.1講述了所需的步驟，3.2將對更細化的算法進行介紹。

3.1 轉換步驟

轉換工具的開發過程包括三個步驟:提取、輸入和再構造。提取主要針對類和方法。在我們的研究中，提取指的是類的提取，輸入步驟用于在不同的分析階段添加特定的主程序行或方法，最終的再構造步驟對方法和類進行再建。這三種步驟將在本章作出詳盡的論述。

軟件工具也有自己的數據庫，包括用于執行特定設計模式的所有支持文件。基于用戶選定的設計模式，適當的支持文件與總框架的接口類進行連接。接口類用于顯示特定的設計選項。

數據庫內的支持文件用于LFs模式或HS/HA模式的基礎結構的創建，以下為用于程序變換的數據庫內支持文件列表:

·工作池

·工作對象

·排列層

·同步層

·服務處理線程

其中，前兩個文件用于LFs類型，后面三個文件用于HS/HA類型。

在數據提取過程，首先是從單線程的接口類中讀取數據并提取方法。需要注意的是，因為已對所有數據的不同之處作出分析，故無需讀取所有數據。

數據錄入階段主要是新方法的添加。添加至ST的有兩種方法:startLeaderFollower()和stopLeaderFollower()。另外，需添加新連接:位于LeaderFollower接口和工作池之間，還有工作池與工作類之間的連接。

從ST到HS/HA，需添加一種額外的方法:startServiceHandlers()。介于HSyncHaSync接口和ServiceHandler線程的新線程，以及介于HSyncHaSync接口和Asynchronous層的連接也需要進行創建。

再構造過程負責對代碼進行重建。其間，帶有新附加方法和再利用組件的現有系統進行了重建。在本過程結束后，生成包含所產生程序的新輸出文件。

3.2 詳細算法

本章描述了工具所用的算法。每種工具對ST技術中的每個方法及介于ST和HS/HA或LFs之間的不同處進行跟蹤。

以下為更為具體的算法:

在程序轉換過程中，ST代碼的每種方法被當成一個整體進行處理。在每種方法下，工具將逐行搜尋用于程序轉換的原始ST代碼。另外，工具將每種方法出現的變化進行記錄(在第二章的分析階段已事先進行了討論)，包括標題文件和附加變量等。

算法:

main():

{按照需要添加額外的標題文件

按照需要輸入額外的變量

讀取輸入文件

讀取行

重復搜尋需要進行轉換的方法(自起點始)并執行

{ 讀取行，直至找到基于關鍵詞或關鍵行變化的正確行

執行updateMethod()

}}

updateMethod()

{// 每種方法對所需變化的數目進行跟蹤，用于下列程序循環

重復所有列明的變化

{搜尋用于轉換的關鍵行

// 例如:ST代碼中的this.serviceHandler

將相對應的新代碼行和/或一個新代碼段替換為“原始行”

// 有關HS/HA的實例:此處的變化是從this.dataAcceptor 到this.serviceHandler，另外在HS/HA設計中添加另外的兩行以啟動HS/HA。

} }

Python中的圖形用戶接口(GUI)開發為了使用上的便利，在實際中有其重要性。一般而言，Python程序開發所需時間少，被譽為“膠著”程序語言，便于進行配置管理。用戶對目標系統具有真實的選擇權。普通的引導行及數據接收和阻隔被良好記錄下來。但是，通過可執行系統對數量選取的更抽象的數據進行比較將更為有用。

4 結束語

質量屬性或非功能性需求是進行軟件開發的重要環節，包括可維護性和生產效率。始于架構層的軟件開發在展示質量方面起著更好的杠桿調節作用。在具體實踐中，所需的生產效率和開發時間對軟件公司起著至關重要的作用。本文展示了以架構為中心的程序轉換，旨在描述有關傳統的軟件質量和生產效率的問題。應用的目標領域在分布式和并發式系統。

我們的初始化工具開發基于對現有系統的研究，盡管我們是在一個大的范圍中進行分析的。然而，普通Java程序工具可以進行提示。本理念也可用于其他領域，如當多任務類型為潛在的架構方法，尤其是當工具可以被多次使用時。

參考文獻:

[1] Alhussaini A..Software Restructuring and Performance Evaluation[R].Ottawa， Canada:Project Report 2004，Dept of Systems Computer Eng，Carleton Univ.

[2] Barbacci M.Quality Attribute Workshops (QAW)[R].3rd ed.Technical Report CMU/SEI-2003-TR-016，2006.

[3] Balasubramaniam B，Elankeswaran P，Gopalasundaram U.et al.Transformation and Building Reusable Components with Design Patterns[R].Ottawa，Canada:Project Report 2005， Dept Of Systems Computer Eng，Carleton Univ.

[4] Gamma E，Helm R，Johnson R，et al.Design Patterns: Elements of Reusable Object-Oriented Software[M].Addison Wesley，1995.

[5] Kazman R，Klein M，Barbacci M，et al.The Architecture Tradeoff Analysis Method[C].Proc of the 4th Int'l Conf on Engineering of Complex Computer Systems，1998:68-78.