軟件架構的過程

領測軟件測試網 本文來自于 Rational Edge：軟件架構被公認為軟件開發領域的一門新興學科。作為軟件架構系列文章的第三篇，本文描述的是在軟件工程的生命周期里軟件架構師正在進行的各類活動。

在這個系列里，我的 第一篇文章描述的是什么是軟件架構， 第二篇文章 講述軟件架構師這個角色的特征。第三部分是建立在以前討論的基礎之上，而且所考慮的主題或者特征都是在軟件架構過程這個框架下。

軟件架構活動：定義及范圍

根據IEEE標準，軟件架構活動代表了

這樣一系列活動：定義、記錄、維持、改進一個軟件構架并確保其正確執行。 ¹

軟件架構的范圍相當寬泛。圖1展示的模型詳細地說明了軟件架構過程的各個方面。這個模型來自IEEE標準1471，架構師所關注的軟件架構各個方面都可以此模型作為參考。

圖1：軟件架構相關術語的模型

圖1中陰影框里的元素直接來自于IEEE標準1471，它們之間的相互關系闡明的是一個系統及其構架的諸多特征：

• 一個系統有一個構架。
• 一個系統完成一項任務。
• 一個系統存于一個環境中，并受這個環境的影響。
• 一個系統有一個或多個涉眾。
• 一個構架對應一條構架描述。
• 一條構架描述識別一個或多個涉眾。
• 一條構架描述識別一條或多條關聯。
• 一條構架描述提供理由。
• 一個涉眾有一條或多條關聯，一條關聯對一個或多個涉眾都很重要。

圖1中另外那些不是來自IEEE標準1471的元素和相互關系，顯示在非陰影框中，可描述如下：

• 一個團隊組負責一個開發項目。
• 一個開發項目遵循一個開發流程。
• 一個開發項目交付給一個系統。
• 開發流程包括軟件架構。
• 項目組里包含一個架構師。
• 架構師負責軟件架構。
• 架構師是涉眾中的一種。
• 架構最終得出一個軟件構架。
• 架構師創造出軟件構架。

軟件架構是一門科學

雖然軟件構架是一門新生事物，但它已被公認為一門學科。而隨之而來的是將重點放在使軟件架構過程日趨成熟的技術、方法和資源上。推進這一趨勢的方法之一就是利用現有的知識體系。概括地說，就是架構師們在開發一個新的構架時尋求已經通過檢驗的解決方案，而不是重蹈覆轍，將以往的軟件構架、構架設計模型以及其他一些可再度使用的元素中可以借鑒的經驗匯集成冊。

盡管如此，軟件架構過程要想在任何地方都和土木工程的架構過程一樣成熟，仍有一段路要走。這種成熟可以體現在很多層面上，包括標準的運用，對最佳實行方案、技術以及方法的理解上。因此，基于這一點，一個架構師的經驗對于一個項目的成功有很大的影響。

軟件架構是一門藝術

盡管軟件架構被認為是一門科學，但有些時候具備一定的創造力是十分必要的，在處理一些從未見過的奇特的系統時這一點就尤為重要。在這種情況下，可能沒有成形的經驗可以借鑒。就如同一個畫家在面對一張空白的畫板時需要靈感一樣，架構師們有時會視他們的工作為一門藝術而不是一門科學。當然在很大程度上，軟件架構的藝術層面是很小的。即使是面對一個極為新奇的系統，通常的做法也是借鑒別處的解決辦法，處理之后使其適應用這個系統。

隨著軟件架構過程日漸成為主流，它極有可能不再被認為是只有“被挑出的極少數人”可以理解的一系列神秘的實踐行為，而是一系列被廣泛接受的、建立在科學基礎之上的、定義明確并通過檢驗的實踐行為。

軟件架構跨越很多學科

在軟件開發過程中架構師需要涉及許多學科。架構師涉及最多的學科是軟件設計，盡管如此，架構師也很關注其他的一些學科。例如，在需求分析里，架構師要確保對于利害關系的需求條件尤為了解，同時也懂得區分這些需求的優先次序。架構師參與實現工作，他們詳細地說明用來組織源代碼以及可執行的工作產品的實現結構。架構師們還參與測試工作，確保架構結構具有可測性并能通過測試。架構師負責開發環境中的一些特定元素，特別是建立一些特定的指針。架構師們還幫助制定配置管理策略，因為配置管理結構（用來支持版本管理的）經常影響已經定義好的軟件架構。架構師與項目管理人緊密合作，正如這個文章系列中的第二部分所提到的，架構師已經成為項目計劃中的一員。

當談及軟件架構的范圍時，我需要提到架構和設計的關系。盡管架構師尤為重視設計學，但并非所有的設計都可以認為是軟件架構。因為一個架構只是關注那些十分重要的元素，而并不是所有的設計元素都對架構有重要意義。例如，用戶界面屏幕的詳細設計通常認為對架構沒有任何意義，最好是留給用戶界面設計者來完成。這種思路同樣應用于其他的系統元素，例如那些支持業務邏輯或數據邏輯的元素。架構師只在必要時加以限制，而許多設計方面的決策都是留給設計者們來完成的。

架構是時刻進行的行為

經驗表明，軟件架構并不是在項目初期一蹴而就的事情，而是貫穿整個項目的始終。在整個項目里，通過交付給可執行軟件的一系列迭代遞增的程序，軟件架構也日趨成熟。在每一次交付過程中，軟件構架都會變得更加穩定完善。這就很好地解釋了什么是架構師貫穿項目始終的重點。

成功的軟件架構行為是以結果為導向的。因此，架構師的重點會因預期結果隨時間變化而變化。這一點如圖2所示，圖2由Bran Selic繪制。 ²

圖2：隨時間變化的工程重點

圖2表明，在工程早期，架構師著眼于發現，重點是理解系統所涉及的范圍并識別其主要特征及所有相關的風險——所有的要素對軟件構架都有顯著的影響。然后重點轉向創造，主要是開發一個可以為整個實現過程提供牢固基礎的穩定的構架。最終，重點放在了實現上面，這個時候大部分的發現和創造開始起作用。

應該注意到，發現、創造和實現并不是嚴格按順序來的。例如，隨著架構模型的建立，在項目早期會有一些實現過程。而隨著過程的深入理解和實現架構中某些元素的不同策略的提出，在項目后期將會有一些發現。

請記住，直到系統交付架構過程才被完成，因此，架構師必須一直關注軟件構架直至項目結束。一旦一個項目的軟件構架穩定下來，人們總是希望架構師離開這個項目，將這一珍貴的資源用于其他的項目。然而，直到項目后期仍有一些架構方面的決策需要制定。實際上，還有介于兩者之間的情況，一旦影響軟件架構的重大決策制定出來，架構師就成為項目組中的一名兼職人員。不管怎樣，架構師不應該完全脫離這個項目。當然還有一種更加靈活的情況，那就是由一個團隊來履行架構師這個角色，這個團隊里的一些成員可能去參予其他的項目，而另外一些則留下來繼續確保這個系統架構的完整性。

軟件架構受涉眾所驅動

正如在早期的章節里所描述的，一個構架滿足許多涉眾的需求。因此架構的過程必須適應所有這些涉眾，以確保他們的關系——特別是那些極有可能對軟件構架產生影響的——能夠被了解，被闡明，能夠得到協調及有效的處理，也有必要將相關的涉眾融入到對這些關系處理的每一次復審之中。

在架構過程中不應低估適應所有涉眾所付出的努力。涉眾影響著架構過程的許多方面，包括集中需求條件的方式，構架的文檔記錄樣式以及構架的評估方法。

軟件架構經常需要做出折衷

假定給出影響軟件構架的諸多因素，很顯然軟件架構過程需要做出折衷。通常情況是在需求中做出權衡，同時也要考慮涉眾來幫助做出正確的折衷。一個折衷的例子就是性能價格比：添加更多的問題處理能力會增加性能，但是要以成本為代價。這可能代表一個需求的沖突，假設架構師已經努力地找到所有可解決方案，這就是一個要由有需求沖突的涉眾來解決的問題。

另一種折衷體現在解決方案上：例如，用一種技術代替另一種技術，或是用第三方的部分代替另一方，或者甚至用一組模式來取代另外的一組。作出折衷無法避免，也不應避免。構架師的一項工作就是考慮可選擇的方案并在它們之間作出折衷。

軟件架構受益于過去的經驗

架構師們很少“白手起家”。正如前面提到的，他們積極地尋找已經匯集成冊的經驗，包括架構模式、設計模式以及已經成形的部分等等。換句話說，架構師努力獲取那些可再度利用的資源。只有那些最無知的架構師才放棄考慮過去的經驗。

當問題重復發生時，可重復使用的資源就是解決方案；可重復使用的資源就是一種在重復使用時已經在腦海中得到提煉的資源。 ³

一個軟件構架中的元素可以在當前系統的前后關系里再度使用，與此同時，一個架構師可能也已經將其構架或者其中的一些元素作為可再度使用的資源，用于當前系統之外。

軟件架構既是自上而下也是自下而上的

許多軟件構架是按照自上而下方式來設計的：1）在定義構架之前掌握涉眾需求并加以研究；2）設計架構元素；3）實現這些元素。盡管如此，一個軟件構架很少完全按照這個自上而下的方式進行架構，普遍情況是采取相反的方式，從已經創造出來的實現軟件中汲取教訓，比如說概念論證。在某種程度上，軟件構架按照自下而上的方式是由于指定的設計或實現方案的約束，在這種情況下這些元素是給定的，軟件構架必須適應它們。例如，約束可能是設計將在現在系統上使用關系數據庫或者接口。

成功的架構師們承認，架構的方法是必要的，并且他們的軟件架構是按照自上而下和自下而上兩種方式創建的。這可以被認為是“中間的”架構解決方法。

結束語

這篇文章重點說明的是軟件構造過程的主要特征。下個月的文章是軟件架構系列文章的最后一篇，其重點放在將軟件構架作為IT基礎資源的益處上。

致謝

這篇文章的內容來源于一本即將出版的新書，暫時叫做“軟件架構建立過程”。最后，我衷心的感謝對內容提出寶貴意見的人們，他們是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。

注解

¹IEEE Computer Society，強軟件系統的架構描述的IEEE推薦實踐：IEEE 標準 1472000，2000。

² Bran告訴我，他為Philippe Kruchten將這張圖畫在了餐巾紙上。

³ 取自“Reusable Asset Specification”， 對象管理組織，文檔號 04-06-06，2004年六月。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/