通過上一節的介紹，相信你對架構設計已經有了初步的瞭解。這一節我們主要講解架構的方法與基本原理，儘管這很俗，但是我們還不得不對它做一下大致的介紹，以免我們在進行架構設計時走入誤區。     我們知道一個軟體開發專案是由不同角色的人為完成不同的任務而產生的工作產品。我們要開發軟體，制定架構就需要研究角色、任務和工作產品，接下來我們詳述這三個部分。    角色     角色定義了軟體開發組織內作為團隊一起工作的一組人或單個人的職責。角色不是單個人，單個人可能扮演多個角色，多個人可能會扮演同一個角色。下面我們介紹一下不同角色的架構師的定義及其職責：    首席架構師全面負責定義系統架構的主要技術決策。這個角色也負責為這些決策提供理論基礎；平衡各種利益相關者的關注點；管理技術風險和問題；還確保決策被有效地溝通、驗證和執行。
   應用架構師關注那些使業務流程自動化和滿足業務需要的元素。這個角色主要關注業務需要的功能，但是他也關心應用相關的元素如何滿足系統的非功能性需求（質量和約束）。
   基礎設施架構師關注那些不依賴業務功能的系統元素，如持久機制、硬體和中介軟體。這樣的元素支援應用相關元素的執行。這個角色關注那些對系統質量有明顯影響的元素，因此，他也會處理一些延伸的非功能性需求。
   資料架構師關注系統的資料元素，尤其是那些用適當的機制（如資料庫、檔案系統、內容管理系統或其他儲存機制）保持持久的資料。這個角色定義適當的與資料相關的屬性，比如結構、來源、位置、完整性、可用性、效能和使用年限。
任務     任務是在專案的上下文中提供有意義結果的一個工作單元。它有明確的目的，通常涉及建立或更新工作產品。所有的任務都由適當的角色執行。     任務可能會被重複執行很多次，尤其是當採用迭代開發方式時。下圖列出了不同角色的架構師的相關任務。
   工作產品
    工作產品是在流程執行過程中生成和使用的一些資訊或物理實體。工作產品包括模型、計劃、程式碼、可執行程式碼、文件、資料庫等。雖然可能有多個角色協作來生成一個工作產品，但是它是單個角色的職責。
    SPEM（軟體系統流程工程元模型規範）定義了三種類型的工作產品：工件、可交付物及成果。工件是一個實在的工作產品，如文件、模型原始碼、可執行物或專案計劃。可交付物是切實的打包交付的工作產品。成果表示一個結果或任務執行結果的狀態。下圖是不同角色架構師的一些文件產品。
         我們知道軟體行業中使用的各種方法間的差異主要與遵循的流程有關，而不在於角色、工作產品和任務，所以我們現在討論一下當前使用最多的三種流程型別：瀑布、迭代和敏捷。
   瀑布模型在早期軟體開發模型的典範，但是在開發綠色領域專案（架構師從頭開始）或那些被大範圍修改的專案上，瀑布模型就因專案進度不能精確地度量，直到專案的後期才能獲得使用者的反饋等原因而被逐漸放棄。在此，不再對瀑布模型做過多的介紹，僅以下面一幅圖說明瀑布模型的開發過程。
   迭代是一個專案的短的週期劃分。迭代時一個明確的、固定時間的活動序列，它們會產生一個可執行產品的版本。OpenUP定義了軟體開發的四個階段：起始、細化、構造和移交，在每個階段都會進行N次迭代最終形成產品。
    迭代開發與瀑布開發流程相比，迭代開發是以結果驅動的，而不是以工作產品驅動，這有助於對專案進度進行更精確的測量。迭代的方式通過系統增量版本的執行儘早獲得使用者反饋，而這些反饋促進實際需求的收斂。
   敏捷開發是近年來最受歡迎的開發方式，代表性的方法有極限程式設計、Scrum、精益和特徵驅動開發。雖然每個特定的敏捷方法以及所倡導的方法存在一些差異，但是它們都基於相同的基礎準則--敏捷宣言：
    注重個人及其互動，勝於過程與工具。
    注重可用的軟體，勝於詳盡的文件。
    注重客戶協作，勝於契約談判。
    注重響應變化，勝於恪守計劃。
    敏捷流程不倡導預先設計，架構直接來自於程式碼。然而，“注重可用的軟體，勝於詳盡的文件”這個原則並不意味著沒有文件，這僅僅意味著只有滿足當前迭代目標的文件。     本篇我們介紹了軟體架構的一些方法和基本原理，同時也用生動的圖形說明了不同角色的工程師的職責和工作產品。通過這些介紹，我們接下來就可以詳細介紹專案生命週期中使用的方法，以及如何去設計架構。歡迎您保持關注。。。