http://www.uml.org.cn/zjjs/200906045.asp

在不同的架構設計方法中出現的軟體架構檢視種類很多，本文介紹最常用的兩種架構檢視——邏輯架構檢視和物理架構檢視，並通過具體案例的分析說明如何運用它們進行架構設計。

當觀察和描述事物大局的時候，邏輯架構和物理架構是最常用的角度。比如，以我們辦公室裡的區域網為例：從物理角度看，所有計算機“毫無區別”地連線到路由器上；而從邏輯角度看呢，就發現這些計算機是有區別的——一臺計算機充當檔案伺服器，而其它計算機是可以訪問伺服器的客戶機。如圖1所示。

圖1  區分物理視角與邏輯視角

同樣，在軟體架構設計過程中，也可以通過區分軟體的邏輯架構和物理架構，分別從不同的角度設計和描述軟體架構。

所謂軟體架構檢視，是指設計和看待整個軟體系統的特定視角。每個軟體架構檢視關注系統架構的不同方面，針對不同的目標和用途。也就是說，架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力範圍，因此採用“分而治之”的辦法從不同視角分別設計；同時，也為軟體架構的理解、交流和歸檔提供了方便。

邏輯架構

軟體的邏輯架構規定了軟體系統由哪些邏輯元素組成、以及這些邏輯元素之間的關係。

軟體的邏輯元素一般指某種級別的功能模組，大到我們熟悉的邏輯層（Layer），以及子系統、模組，小到一個個的類。至於具體要分解到何種大小的功能模組才可結束軟體架構設計，並不存在一個“一刀切”的標準——只要足夠明確簡單，能夠分頭開發就可以了。於是，在實踐中我們往往將關鍵機制相關的架構設計部分明確到類，而一般功能則到模組甚至子系統的介面定義即可。

值得說明的是，功能模組有時容易識別，有時卻比較隱含。而比較全面地識別功能塊、規劃功能塊的介面、明確功能塊之間的使用關係和使用機制，正是軟體邏輯架構設計的核心任務所在。對此，Ivar Jacobson曾有過極為形象的說法，“軟體系統的架構涵蓋了整個系統，儘管架構的有些部分可能只有‘一寸深’”。

圖2展示了一個網路裝置管理系統邏輯架構設計的一部分，我們藉此來舉例說明軟體邏輯架構設計的3大核心任務：

識別功能塊

規劃功能塊的介面

明確功能塊之間的使用關係和使用機制

軟體的邏輯架構是架構設計思維的重要方法。在用例技術已經成為捕獲功能需求的事實標準的今天，邏輯架構的設計往往是從用例分析開始的。基於用例的分析方法使邏輯架構的設計變得比較有序——通過對每個關鍵用例的分析，從邏輯上將用例實現為一組功能塊的特定組合，最後綜合這些用例分析成果，將一個個獨立的協作歸納合併成整個軟體系統的邏輯架構。而在用例分析方法產生之前，功能模組的確定多多少少帶有些“硬”想出來的味道，特別是並不直接承載業務功能的模組有時比較容易遺漏，直到大規模程式設計實現階段才發現。

物理架構

軟體的物理架構規定了組成軟體系統的物理元素、這些物理元素之間的關係、以及它們部署到硬體上的策略。

物理架構可以反映出軟體系統動態執行時的組織情況。此時，上述物理架構定義中所提及的“物理元素”就是程序、執行緒、以及作為類的執行時例項的物件等，而程序排程、執行緒同步、程序或執行緒通訊等則進一步反映物理架構的動態行為。

隨著分散式系統的流行，“物理層（Tier）”的概念大家早已耳熟能詳。物理層和分佈有關，通過將一個整體的軟體系統劃分為不同的物理層，可以把它部署到分佈在不同位置的多臺計算機上，從而為遠端訪問和負載均衡等問題提供了手段。當然，物理層是大粒度的物理單元，它最終是由粒度更小的元件、模組、程序等單元組成的。

物理架構的應用很廣泛。例如，架構設計中可能需要專門說明資料是如何產生、儲存、共享和複製的，這時可以利於物理架構，展示軟體系統在執行期間資料是由哪些執行時單元如何產生的，資料又如何被使用、如何被儲存，哪些資料需要跨網路複製和共享等方面的設計決策。

由於人們對組成軟體系統的“物理元素”存在不同看法（如圖3所示），所以在實踐中物理架構的用法比較寬泛，不同的人認為的物理架構也可能不盡相同。因此，我們在交流和實踐的過程中，應注意區分物理架構所指為何。（也正是因為這個原因，實踐中所採用的基於多檢視的架構設計方法往往包含更多的檢視，從而使每個架構檢視的職責更加明確。）

圖3    對“物理元素”的不同看法

從邏輯架構和物理架構到設計實現

邏輯架構和物理架構是軟體架構設計的重要方面。邏輯架構致力於將軟體系統分解成不同的邏輯單元，並規定這些邏輯單元之間的互動介面和互動機制。物理架構則更重視軟體系統執行時的動態結構，以及組成軟體系統的目標程式如何部署到硬體上。

在後續的詳細設計和程式設計實現中，將貫徹和利用邏輯架構和物理架構設計中制定的架構決策，如圖4所示。

　　圖4    邏輯架構和物理架構對後續開發的作用

邏輯架構中關於職責劃分的決策，體現為層、子系統、模組等的劃分決定，從靜態視角為詳細設計和程式設計實現提供切實的指導；有了分解就必然產生協作，邏輯架構還規定了不同邏輯單元之間的互動介面和互動機制，而程式設計工作必須實現這些介面和機制。 所謂互動機制，是指不同軟體單元之間互動的手段。互動機制的例子有：方法呼叫、基於RMI的遠端方法呼叫、傳送訊息等。

至於物理架構，它關注的是軟體系統在計算機中執行期間的情況。物理架構設計方案中規定了軟體系統如何使用程序和執行緒完成期望的併發處理、程序執行緒這些主動物件（Active Object）會呼叫哪些被動物件（Passive Object）參與處理、互動機制（如訊息）為何等等問題，從而為詳細設計和程式設計實現提供了工作目標的動態檢視。

裝置除錯系統案例簡介

下面通過一個實際案例的分析，來幫助領會邏輯架構和物理架構這兩種架構檢視對架構設計的指導作用。

該案例是某型號裝置除錯系統。裝置除錯員通過使用該系統，可以察看裝置狀態（裝置的狀態資訊由專用的資料採集器實時採集）、傳送除錯命令。該系統的用例圖如圖5所示。

　　 圖5    裝置除錯系統的用例圖

邏輯架構設計

首先根據功能需求進行初步設計，進行大粒度的職責劃分。如圖6所示。

圖6    裝置除錯系統的邏輯架構

之後，還有很多與邏輯架構設計相關的工作要做。例如，圖7所示的CRC卡描述了上面的三層架構每一層的職責與協作者：

應用層負責裝置狀態的顯示，並提供模擬控制檯供使用者傳送除錯命令。

應用層使用通訊層和裝置控制層進行互動，但應用層不知道通訊的細節。

通訊層負責在RS232協議之上實現一套專用的“應用協議”。

當應用層傳送來包含除錯指令的協議包，由通訊層負責按RS232協議將之傳遞給裝置控制層。

當裝置控制層傳送來原始資料，由通訊層將之解釋成應用協議包傳送給應用層。

裝置控制層負責對除錯裝置的具體控制，以及高頻度地從資料採集器讀取裝置狀態資料。

裝置控制指令的物理規格被封裝在裝置控制層內部，讀取數採器的具體細節也被封裝在裝置控制層內部。

圖7    用CRC卡描述每層的職責和協作者

物理架構設計

軟體最終要駐留、安裝或部署到硬體才能執行。軟體的物理架構關注“目標程式及其依賴的執行庫和系統軟體”最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性等要求。

多個邏輯層（Layer）可以對映到一個物理層（Tier），這是很多從事分散式開發的讀者都瞭解的。在進行裝置除錯系統的物理架構設計之時，也體現了這一點。如圖8所示，裝置除錯系統共包含2個物理層：桌面部分和嵌入部分。作為邏輯層的應用層和通訊層最終將成為桌面部分，而裝置控制層最終成為嵌入部分。

圖8    邏輯層（Layer）到物理層（Tier）的對映

物理層作為組成軟體系統的物理單元，最終又要對映到具體的硬體，這也是物理架構設計要考慮的，對於分散式軟體系統的設計而言尤其不可或缺。圖9展示了這一點。可以看出，裝置控制部分駐留在除錯機中（除錯機是專用單板機），而桌面部分以常見的“Windows可執行程式”的形式運用於PC機之上。

圖9    裝置除錯系統架構的物理架構

我們還可能根據具體情況的需要，通過物理架構檢視更明確地表達具體目標模組及其通訊結構，如圖10所示。

圖10 裝置除錯系統的物理架構

總結

從簡單系統到複雜系統的變化，對架構設計的衝擊決不僅僅是量變的問題。通過引入了軟體架構檢視的概念，有助於軟體架構師控制架構設計的複雜性。

軟體架構檢視的概念和軟體架構基本概念是完全相容的，後者針對軟體系統的整體目標，而前者針對特定目標子集，這樣一來，重點突出了，問題明確了，軟體架構師的經驗也就活躍了起來。

邏輯架構和物理架構相分離的設計方法在軟體實踐中比較常用。邏輯架構和物理架構是軟體架構設計的重要方面。邏輯架構致力於將軟體系統分解成不同的邏輯單元，並規定這些邏輯單元之間的互動介面和互動機制。物理架構則更重視軟體系統執行時的動態結構，以及組成軟體系統的目標程式如何部署到硬體上。