Peter Eeles, Senior IT Architect, IBM
2006 年 6 月 15 日
本文來自於 Rational Edge：軟件架構被公認爲軟件開發領域的一門新興學科。作爲軟件架構系列文章的第三篇，本文描述的是在軟件工程的生命週期裏軟件架構師正在進行的各類活動。
在這個系列裏，我的 第一篇文章描述的是什麼是軟件架構， 第二篇文章 講述軟件架構師這個角色的特徵。第三部分是建立在以前討論的基礎之上，而且所考慮的主題或者特徵都是在軟件架構過程這個框架下。
根據IEEE標準，軟件架構活動代表了
這樣一系列活動：定義、記錄、維持、改進一個軟件構架並確保其正確執行。 1
軟件架構的範圍相當寬泛。圖1展示的模型詳細地說明了軟件架構過程的各個方面。這個模型來自IEEE標準1471，架構師所關注的軟件架構各個方面都可以此模型作爲參考。
圖1：軟件架構相關術語的模型
圖1中陰影框裏的元素直接來自於IEEE標準1471，它們之間的相互關係闡明的是一個系統及其構架的諸多特徵：
- 一個系統有一個構架。
- 一個系統完成一項任務。
- 一個系統存於一個環境中，並受這個環境的影響。
- 一個系統有一個或多個涉衆。
- 一個構架對應一條構架描述。
- 一條構架描述識別一個或多個涉衆。
- 一條構架描述識別一條或多條關聯。
- 一條構架描述提供理由。
- 一個涉衆有一條或多條關聯，一條關聯對一個或多個涉衆都很重要。
圖1中另外那些不是來自IEEE標準1471的元素和相互關係，顯示在非陰影框中，可描述如下：
- 一個團隊組負責一個開發項目。
- 一個開發項目遵循一個開發流程。
- 一個開發項目交付給一個系統。
- 開發流程包括軟件架構。
- 項目組裏包含一個架構師。
- 架構師負責軟件架構。
- 架構師是涉衆中的一種。
- 架構最終得出一個軟件構架。
- 架構師創造出軟件構架。
雖然軟件構架是一門新生事物，但它已被公認爲一門學科。而隨之而來的是將重點放在使軟件架構過程日趨成熟的技術、方法和資源上。推進這一趨勢的方法之一就是利用現有的知識體系。概括地說，就是架構師們在開發一個新的構架時尋求已經通過檢驗的解決方案，而不是重蹈覆轍，將以往的軟件構架、構架設計模型以及其他一些可再度使用的元素中可以借鑑的經驗彙集成冊。
儘管如此，軟件架構過程要想在任何地方都和土木工程的架構過程一樣成熟，仍有一段路要走。這種成熟可以體現在很多層面上，包括標準的運用，對最佳實行方案、技術以及方法的理解上。因此，基於這一點，一個架構師的經驗對於一個項目的成功有很大的影響。
儘管軟件架構被認爲是一門科學，但有些時候具備一定的創造力是十分必要的，在處理一些從未見過的奇特的系統時這一點就尤爲重要。在這種情況下，可能沒有成形的經驗可以借鑑。就如同一個畫家在面對一張空白的畫板時需要靈感一樣，架構師們有時會視他們的工作爲一門藝術而不是一門科學。當然在很大程度上，軟件架構的藝術層面是很小的。即使是面對一個極爲新奇的系統，通常的做法也是借鑑別處的解決辦法，處理之後使其適應用這個系統。
隨着軟件架構過程日漸成爲主流，它極有可能不再被認爲是隻有“被挑出的極少數人”可以理解的一系列神祕的實踐行爲，而是一系列被廣泛接受的、建立在科學基礎之上的、定義明確並通過檢驗的實踐行爲。
在軟件開發過程中架構師需要涉及許多學科。架構師涉及最多的學科是軟件設計，儘管如此，架構師也很關注其他的一些學科。例如，在需求分析裏，架構師要確保對於利害關係的需求條件尤爲了解，同時也懂得區分這些需求的優先次序。架構師參與實現工作，他們詳細地說明用來組織源代碼以及可執行的工作產品的實現結構。架構師們還參與測試工作，確保架構結構具有可測性並能通過測試。架構師負責開發環境中的一些特定元素，特別是建立一些特定的指針。架構師們還幫助制定配置管理策略，因爲配置管理結構（用來支持版本管理的）經常影響已經定義好的軟件架構。架構師與項目管理人緊密合作，正如這個文章系列中的第二部分所提到的，架構師已經成爲項目計劃中的一員。
當談及軟件架構的範圍時，我需要提到架構和設計的關係。儘管架構師尤爲重視設計學，但並非所有的設計都可以認爲是軟件架構。因爲一個架構只是關注那些十分重要的元素，而並不是所有的設計元素都對架構有重要意義。例如，用戶界面屏幕的詳細設計通常認爲對架構沒有任何意義，最好是留給用戶界面設計者來完成。這種思路同樣應用於其他的系統元素，例如那些支持業務邏輯或數據邏輯的元素。架構師只在必要時加以限制，而許多設計方面的決策都是留給設計者們來完成的。
經驗表明，軟件架構並不是在項目初期一蹴而就的事情，而是貫穿整個項目的始終。在整個項目裏，通過交付給可執行軟件的一系列迭代遞增的程序，軟件架構也日趨成熟。在每一次交付過程中，軟件構架都會變得更加穩定完善。這就很好地解釋了什麼是架構師貫穿項目始終的重點。
成功的軟件架構行爲是以結果爲導向的。因此，架構師的重點會因預期結果隨時間變化而變化。這一點如圖2所示，圖2由Bran Selic繪製。 2
圖2：隨時間變化的工程重點
圖2表明，在工程早期，架構師着眼於發現，重點是理解系統所涉及的範圍並識別其主要特徵及所有相關的風險——所有的要素對軟件構架都有顯著的影響。然後重點轉向創造，主要是開發一個可以爲整個實現過程提供牢固基礎的穩定的構架。最終，重點放在了實現上面，這個時候大部分的發現和創造開始起作用。
應該注意到，發現、創造和實現並不是嚴格按順序來的。例如，隨着架構模型的建立，在項目早期會有一些實現過程。而隨着過程的深入理解和實現架構中某些元素的不同策略的提出，在項目後期將會有一些發現。
請記住，直到系統交付架構過程才被完成，因此，架構師必須一直關注軟件構架直至項目結束。一旦一個項目的軟件構架穩定下來，人們總是希望架構師離開這個項目，將這一珍貴的資源用於其他的項目。然而，直到項目後期仍有一些架構方面的決策需要制定。實際上，還有介於兩者之間的情況，一旦影響軟件架構的重大決策制定出來，架構師就成爲項目組中的一名兼職人員。不管怎樣，架構師不應該完全脫離這個項目。當然還有一種更加靈活的情況，那就是由一個團隊來履行架構師這個角色，這個團隊裏的一些成員可能去參予其他的項目，而另外一些則留下來繼續確保這個系統架構的完整性。
正如在早期的章節裏所描述的，一個構架滿足許多涉衆的需求。因此架構的過程必須適應所有這些涉衆，以確保他們的關係——特別是那些極有可能對軟件構架產生影響的——能夠被瞭解，被闡明，能夠得到協調及有效的處理，也有必要將相關的涉衆融入到對這些關係處理的每一次複審之中。
在架構過程中不應低估適應所有涉衆所付出的努力。涉衆影響着架構過程的許多方面，包括集中需求條件的方式，構架的文檔記錄樣式以及構架的評估方法。
假定給出影響軟件構架的諸多因素，很顯然軟件架構過程需要做出折衷。通常情況是在需求中做出權衡，同時也要考慮涉衆來幫助做出正確的折衷。一個折衷的例子就是性能價格比：添加更多的問題處理能力會增加性能，但是要以成本爲代價。這可能代表一個需求的衝突，假設架構師已經努力地找到所有可解決方案，這就是一個要由有需求衝突的涉衆來解決的問題。
另一種折衷體現在解決方案上：例如，用一種技術代替另一種技術，或是用第三方的部分代替另一方，或者甚至用一組模式來取代另外的一組。作出折衷無法避免，也不應避免。構架師的一項工作就是考慮可選擇的方案並在它們之間作出折衷。
架構師們很少“白手起家”。正如前面提到的，他們積極地尋找已經彙集成冊的經驗，包括架構模式、設計模式以及已經成形的部分等等。換句話說，架構師努力獲取那些可再度利用的資源。只有那些最無知的架構師才放棄考慮過去的經驗。
當問題重複發生時，可重複使用的資源就是解決方案；可重複使用的資源就是一種在重複使用時已經在腦海中得到提煉的資源。 3
一個軟件構架中的元素可以在當前系統的前後關係裏再度使用，與此同時，一個架構師可能也已經將其構架或者其中的一些元素作爲可再度使用的資源，用於當前系統之外。
許多軟件構架是按照自上而下方式來設計的：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。
1IEEE Computer Society，強軟件系統的架構描述的IEEE推薦實踐：IEEE 標準 1472000，2000。
2 Bran告訴我，他爲Philippe Kruchten將這張圖畫在了餐巾紙上。
3 取自“Reusable Asset Specification”， 對象管理組織，文檔號 04-06-06，2004年六月。
註解