4.2.3　以架構為中心的過程

Rational統一過程主要的一部分可以說是圍繞建模進行的。模型是現實的簡化，能夠幫助我們理解并確定問題及其解決方法。對于那些整體把握不太容易的大型系統，模型應當盡量能夠完整而一致地描述將要開發的系統，盡量和現實情況保持一致。當描述一個系統的一系列任務時，需要用一定的系統框架來進行描述。也就是和很多人認為的那樣，所謂架構（即體系結構）就是當我們在去掉其中的任何部分時，就無法讓人理解整個系統和解釋它是如何工作的系統描述。

一個良好的架構能夠清晰表達其目的，它應該具有關于架構的形成過程的具體描述，并且能夠以一種被普遍接受的方式表達出來。對于一個以架構為中心的開發組織，需要對架構的以下3個方面進行關注。

• 架構的目的：開發組織應當理解架構的目的，明確它為什么如此重要，從中能夠得到什么樣的好處以及如何開發自己的架構。
• 架構的表示：開發組織應當確定一個統一的架構表示形式，這樣能夠使架構具體化，從而使開發組織可以系統地在同一架構下進行交流、評審和改進工作。
• 架構的過程：項目組織應當關注架構的具體形成過程，從而確定如何建立并驗證一個能夠滿足項目需求的架構，并決定由誰來做這件事。

不同的參與者會關注架構的不同方面，因此在描述一個完整的架構時，應當是多維的，而不是平面的，這就是架構視圖（Architecture View）。一個架構視圖是從某一視角或某一點上看到的系統，并依此所做的概述（簡要描述），描述中涵蓋了系統的某一特定方面，省略了與此無關的實體。

在Rational統一過程中建議采用五種視圖來描述架構，這5種視圖分別是：

• 邏輯視圖（Logical View）。在使用面向對象的方法時，邏輯視圖是用來設計對象的模型。
• 過程視圖（Process View）。過程視圖是用來捕捉設計的并發和同步特性。
• 物理視圖（Physical View）。物理視圖是用來描述軟件到硬件的映射，反映分布式的特性。
• 開發視圖（Development View）。開發視圖是用來描述在開發環境中軟件的靜態組織結構。
• 用例視圖（Use Case View）。有時也被認為是場景（Scenarios），用來闡述其他視圖是如何工作的。

我們可以輪流使用這5種視圖觀察系統的架構，并且展現出各個視圖的目標，即視圖所關注的問題、相應的架構設計的標記方式、描述和管理架構設計的工具。下面分別詳細說明這5種視圖。

1．邏輯視圖（Logical View）

邏輯視圖主要支持系統的功能性需求，即在為用戶提供服務方面，系統應該提供的功能。邏輯視圖是設計模型的抽象形式，將系統分解為一系列的關鍵抽象，這些關鍵抽象大多數來自于問題域，并采用抽象、封裝和繼承的方式，對外表現為對象或對象類的形式。我們可以使用Rational統一過程中的相關方法來表示邏輯架構，借助于類圖和類模板的形式。類圖用來顯示一個類的集合和它們的邏輯關系：關聯、使用、組合、繼承等。相似的類可以劃分成類集合的形式。類模板關注于單個類，它們強調主要的類操作，并且識別關鍵的對象特征。如果需要定義對象的內部行為，則需要使用狀態圖等形式來完成。公共的機制或服務可以在工具類（Class Utilities）中定義。

邏輯視圖的風格是采用面向對象的風格，其主要的設計準則是試圖在整個系統中保持單一的、一致的對象模型，避免對各個場合或過程產生多余的類和機制的技術說明。邏輯視圖的結果是用來確定重要的設計包、子系統和類。

2．過程視圖（Process View）

過程視圖考慮的是一些非功能性的需求，主要表現為系統運行時的一些特性，它解決系統運行時的并發性、分布性、系統完整性、系統容錯性，以及邏輯視圖的主要抽象如何與系統進程架構結合在一起。

進程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視為一組獨立執行的通信程序的邏輯網絡，它們分布在一組硬件資源上，這些資源通過LAN或者WAN連接起來。多個邏輯網絡可能同時并存，共享相同的物理資源。例如，獨立的邏輯網絡可能用于支持離線系統與在線系統的分離，或者支持軟件的模擬版本和測試版本的共存。

進程是構成可執行單元任務的分組。進程代表了可以進行策略控制過程架構的層次（即：開始、恢復、重新配置及關閉）。另外，進程可以根據處理負載分布式的增強或可用性的提高而不斷地被重復。

軟件被劃分為一系列單獨的任務，而任務是獨立的控制線程，可以在處理節點上單獨調用。任務可以區分為主要任務和次要任務，主要任務是可以唯一處理的架構元素，次要任務則是由于具體實施主要任務而引入的局部附加任務（如周期性活動、緩沖、暫存等等）。主要任務采用良好的交互任務的通信機制：基于消息的同步或異步通信服務、遠程過程調用、事件廣播等；次要任務則以會話或共享內存來進行通信。在同一過程或處理節點上，不應對主要任務的分配做出任何假定，這是由線程的執行特點決定的。

在進程視圖的設計中，應當關注那些在架構上具有重要意義的元素。使用Rational統一過程中提供的相關方法描述進程架構時，要詳細描述可能的交互通信路徑中的規格說明。

3．物理視圖（Physical View）

物理視圖主要關注的也是系統的非功能性需求，這些需求包括系統的可用性、可靠性、性能和可伸縮性。物理視圖描述的是軟件到硬件的映射，即展示不同的可執行程序和其他運行時構件是如何映射到底層平臺或處理節點上的。軟件在各種平臺（包括計算機網絡等）或處理節點上運行，各種元素（網絡、過程、任務和對象）需要被映射至不同的節點。

在物理視圖的設計中，需要考慮很多關于軟件工程和系統工程的問題，因此在使用Rational統一過程提供的方法進行描述時，表達形式也多種多樣，盡可能不要混用物理視圖，以免產生混亂。

4．開發視圖（Development View）

開發視圖描繪的是系統的開發架構，它關注的是軟件開發環境中實際模塊的組織情況，即系統的子系統是如何被分解的。軟件被打包分成為一個個小的程序模塊（類庫或子系統），一個程序模塊可以由一位或幾位開發人員來進行開發。在大型系統的開發中，有時需要將系統進行組織分層，每一層的子系統模塊都為上層模塊提供良好定義的接口。

系統的開發架構主要使用模塊和子系統圖來表達，顯示了“輸入”和“輸出”的關系。完整的開發架構只有當所有軟件元素被標識后才能加以描述。

在開發視圖的設計中，在大多數情況下，需要考慮的問題與以下幾項因素有關：開發難度、軟件管理、重用性和通用性以及由工具集和編程語言所帶來的限制。開發視圖是各種活動的基礎，這些活動包括：需求分配、團隊工作的分配、成本評估和計劃、項目進度的監控、軟件重用性、可移植性和安全性等。這些活動都是建立產品線的基礎。

5．用例視圖（Use Case View）

用例視圖有時也被認為是場景視圖，扮演著一個很特殊的角色，它綜合了所有上面的這四種視圖。四種視圖的元素通過數量比較少的一組重要場景或者用例進行無縫協同工作。

在某種意義上，這些場景或用例是最重要的需求抽象，它們的設計在Rational統一過程中可以使用用例圖或交互圖來表示。在系統的軟件架構文檔中，需要對這幾個為數不多的場景進行詳細的說明。用例視圖通常被認為是其他4種視圖的冗余視圖，但是它卻起著兩個重要的作用：

• 作為一項設計的驅動元素來發現架構設計過程中的架構元素。
• 作為架構設計結束后的一項驗證和說明功能，既以視圖的角度來說明，又作為架構原型測試的出發點。

使用這5種視圖來描述架構可以解決架構的表述問題，那么Rational統一過程是如何以架構為中心實施設計過程呢？

Rational統一過程定義了兩個關于架構的主要產物，它們分別是：

• 軟件架構描述（SAD），用于描述與項目有關的架構視圖。
• 架構原型，用于驗證架構并充當開發系統其余部分的基礎。

除此之外，還包括其他3種產物，上面兩種產物是這3種產物的基礎。這3種產物分別是：

• 設計指南，為架構設計提供指導，提供了一些模式和習慣用語的使用。
• 在開發環境中基于開發視圖的產品結構。
• 基于開發視圖結構的開發群組結構。

在Rational統一過程中還定義了一個參與者：架構師，負責架構的設計工作。但是，架構師不是唯一關系架構的人，大多數開發人員都參與了架構的定義和實現，尤其是在系統的細化階段。

在Rational統一過程中，通過分析和設計工作流描述了大部分關于架構設計的活動，同時，這些活動貫穿了系統的需求、實現以及管理等方面。所以說，Rational統一過程是一個以架構為中心的過程。