架構藍圖--軟體架構 "4+1" 視圖模型

標籤：

引言

我們已經看到在許多文章和書籍中，作者欲使用單張視圖來捕捉所有的系統架構要點。通過仔細地觀察這 些圖例中的方框和箭頭，不難發現作者努力地在單一視圖中表達超過其表達限度的藍圖。方框是代表啟動並執行程式嗎？或者是代表原始碼的程式塊嗎？或是實體電腦 嗎？或僅僅是邏輯功能的分組嗎？箭頭是表示編譯時間的依賴關係嗎？或者是控制流程嗎？或是資料流嗎？通常它代表了許多事物。是否架構只需要單個的架構樣式？有 時軟體架構的缺陷源於過早地劃分軟體或過分的強調軟體開發的單個方面：資料工程、運行效率、開發策略和團隊組織等。有時架構並不能解決所有"客戶"（或者 說"風險承擔人"，USC 的命名）所關注的問題。許多作者都提及了這個問題：Garlan & Shaw 1、CMU 的 Abowd & Allen、SEI 的 Clements。作為補充，我們建議使用多個並發的視圖來組織軟體架構的描述，每個視圖僅用來描述一個特定的所關注的方面的集合。

回頁首

架構模型

軟 件架構用來處理軟體高階層的設計和實施。它以精心選擇的形式將若干結構元素進行裝配，從而滿足系統主要功能和效能需求，並滿足其他非功能性需求，如可 靠性、延展性、可移植性和可用性。Perry 和 Wolfe 使用一個精確的公式來表達，該公式由 Boehm 做了進一步修改：

軟體架構 ＝ {元素，形式，關係/約束}

軟體架構涉及到抽象、分解和組合、風格和美學。我們用由多個視圖或視角組成的模型來描述它。為了最終處理大型的、富有挑戰性的架構，該模型包含五個主要的視圖（請對照圖 1）：

• 邏輯視圖（Logical View），設計的物件模型（使用物件導向的設計方法時）。
• 過程視圖（Process View），捕捉設計的並發和同步特徵。
• 物理視圖（Physical View），描述了軟體到硬體的映射，反映了分布式特性。
• 開發視圖（Development View），描述了在開發環境中軟體的靜態組織圖。

架構的描述，即所做的各種決定，可以圍繞著這四個視圖來組織，然後由一些用例 （use cases）或情境(scenarios)來說明，從而形成了第五個視圖。正如將看到的，實際上軟體架構部分從這些情境演化而來，將在下文中討論。

圖 1 － "4＋1"視圖模型

我 們在每個視圖上均獨立地應用 Perry & Wolf 的公式，即定義一個所使用的元素集合（組件、容器、串連符），捕獲工作形式和模式，並且捕獲關係及約束，將架構與某些需求串連起來。每種視圖使用自身所特 有的標記法－藍圖（blueprint）來描述，並且架構師可以對每種視圖選用特定的架構風格（architectural style），從而允許系統中多種風格並存。

我們將輪流的觀察這五種視圖，展現各個視圖的目標：即視圖的所關注的問題，相應的架構藍圖的標 記方式，描述和管理藍圖的工具。並以非常簡單的形式從 PABX 的設計中，從我們在Alcatel 商業系統（Alcatel Business System）上所做的工作中，以及從航空運輸控制系統（Air Traffic Control system）中引出一些例子―旨在描述一下視圖的特定及其標記的方式，而不是定義這些系統的架構。

"4+1"視圖模型具有相當的"普遍性"，因此可以使用其他的標註方法和工具，也可以採用其他的設計方法，特別是對於邏輯和過程的分解。但文中指出的這些方法都已經成功的在實踐中運用過。

邏輯結構

物件導向的分解

邏 輯架構主要支援功能性需求――即在為使用者提供服務方面系統所應該提供的功能。系統分解為一系列的關鍵抽象，（大多數）來自於問題域，表現為對象或對象類的 形式。它們採用抽象、封裝和繼承的原理。分解並不僅僅是為了功能分析，而且用來識別遍布系統各個部分的通用機制和設計項目。我們使用 Rational/Booch 方法來表示邏輯架構，藉助於類圖和類模板的手段 4。 類圖用來顯示一個類的集合和它們的邏輯關係：關聯、使用、組合、繼承等等。相似的類可以劃分成類集合。類模板關注於單個類，它們強調主要的類操作，並且識 別關鍵的對象特徵。如果需要定義對象的內部行為，則使用狀態轉換圖或狀態圖來完成。公用機制或服務可以在類功能 （class utilities）中定義。對於資料驅動程度高的應用程式，可以使用其他形式的邏輯視圖，例如 E-R 圖，來代替物件導向的方法（OO approach）。

邏輯視圖的標記法

邏輯視圖的標記方法來自 Booch 標記法4。當僅考慮具有架構意義的條目時，這種標記法相當簡單。特別是在這種設計層級上，大量的修飾作用不大。我們使用 Rational Rose? 來支援邏輯架構的設計。

圖 2 － 邏輯藍圖的標記法

邏輯視圖的風格

邏輯視圖的風格採用物件導向的風格，其主要的設計準則是試圖在整個系統中保持單一的、一致的物件模型，避免就每個場合或過程產生草率的類和機制的技術說明。

邏輯結構藍圖的範例

圖 3 顯示了 Télic PABX 架構中主要的類。

圖 3 － a. Télic PABX 的邏輯藍圖 b.空中交通系統的藍圖

PABX 建立終端間的通訊串連。終端可以是電話裝置、中繼線（例如，串連到中央辦公室）、連接線（PABX 專線到 PABX 線)、電話專線、資料線、ISDN 等等。不同的線路由不同的介面卡提供支援。線路 controller 對象的職責是在介面卡上對所有的訊號進行解碼和注入，在特定於介面卡的訊號與一致性的小型事件集合之間進行相互轉換：開始、停止、數字化等。 controller 對象同時承載所有的即時約束。該類派生出許多子類以滿足不同的介面類型。terminal 對象的責任是維持終端的狀態，代表線路協調各項服務。例如，它使用 numbering plan 服務來解釋撥號。conversation 代表了會話中的一系列終端 。conversation 使用了Translation Service(目錄、邏輯物理映射、路由),以及建立終端之間語音路徑的Connection Service 。

對於一個包含了大量的具有架構重要意義的類的、更大的系統來說，圖 3 b 描述了空中交通管理系統的頂層類圖，包含 8 個類的種類（例如，類的分組）。

進程架構

過程分解

進程架構考慮一些非功能性的需求，如效能和可用性。它解決並發性、分布性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一起－即在哪個控制線程上，對象的操作被實際執行。

進 程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視為一組獨立執行的通訊程式（叫 作"processes"）的邏輯網路，它們分布在整個一組硬體資源上，這些資源通過 LAN 或者 WAN 串連起來。多個邏輯網路可能同時並存，共用相同的實體資源。例如，獨立的邏輯網路可能用於支援離線系統與線上系統的分離，或者支援軟體的類比版本和測試版 本的共存。

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

軟體被劃分為一系列單獨的任務。任務是獨立的控制線程，可以在處理節點上單獨地被調度。

接著，我們可以區別主要任務、次要任務。主要任務是可以唯一處理的架構元素；次要任務是由於實施原因而引入的局部附加任務（周期性活動、緩衝、暫停等等）。它們可以作為 Ada Task 或輕量線程來實施。 主要任務的通訊途徑是良好定義的互動任務通訊機制：基於訊息的同步或非同步通訊服務、遠端程序呼叫、事件廣播等。次要任務則以會見或共用記憶體來通訊。在同一過程或處理節點上，主要任務不應對它們的分配做出任何假定。

訊息流程、過程負載可以基於過程藍圖來進行評估，同樣可以使用啞負載來實現"中空"的進程架構，並測量在目標系統上的效能。正如 Filarey et al. 在他的 Eurocontrol 實驗中描述的那樣。

進程視圖的標記法

我們所使用的進程視圖的表示方法是從Booch最初為 Ada 任務推薦的表示方法擴充而來。同樣，用來所使用的標記法關注在架構上具有重要意義的元素。(圖 4)

圖 4 － 過程藍圖標記法

我們曾使用來自 TRW 的 Universal Network Architechure Services（UNAS0） 產品來構建並實施過程和任務集合（包擴它們的冗餘），使它們融入過程的網路中。UNAS 包含 Software Architect Lifecycle Environment(SALE)工具，它支援上述表示方法。SALE 允許以圖形的形式來描述進程架構，包括對可能的互動任務通訊路徑的規格說明，正是從這些路徑中自動產生對應的 Ada 或 C++ 原始碼。使用該方法來指定和實施進程架構的優點是易於進行修改而不會對應用軟體造成太多的影響。

進程視圖的風格

許多風格可 以適用於進程視圖。例如採用 Garlan 和 Shaw 的分類法1,我們可以得到管道和過濾器（Pipes and filters）,或用戶端/伺服器，以及各種多個用戶端/單個伺服器和多個用戶端/多個伺服器的變體。對於更加複雜的系統,可以採用類似於 K.Birman 所描述的ISIS系統中進程組方法以及其它的標註方法和工具。

進程藍圖的例子

圖 5 － Télic PABX 的過程藍圖（部分）

所 有的終端由單個的 Termal process 處理，其中 Termal process 由輸入隊列中的訊息進行驅動。Controller 對象在組成控制過程三個任務之中的一項任務上執行：Low cycle rate task 掃描所有的非活動終端(200 ms)，將 High cycle rate task(10 ms)掃描清單中的終端啟用，其中 High cycle rate task 檢測任何重要的狀態變化，將它們傳遞給 Main controller task，由它來對狀態的變更進行解釋,並通過向對應的終端發送訊息來通訊。這裡 Controller 過程中的通訊通過共用記憶體來實現。

開發架構

子系統分解

開發架構關注軟體開發環境下實際模組的組織。軟體打包成小的程式塊（程式庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層為上一層提供良好定義的介面。

系統的開發架構用模組和子系統圖來表達，顯示了"輸出"和"輸入"關係。完整的開發架構只有當所有軟體元素被識別後才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見度。

大 部分情況下，開發架構考慮的內部需求與以下幾項因素有關：開發難度、軟體管理、重用性和通用性及由工具集、程式設計語言所帶來的限制。開發架構視圖是各種活動 的基礎，如：需求分配、團隊工作的分配（或團隊機構）、成本評估和計劃、項目進度的監控、軟體重用性、移植性和安全性。它是建立產品線的基礎。

開發藍圖的表示方法

同樣，使用 Booch 方法的變形，僅考慮具有架構意義的項。

圖 5 － 開發藍圖表示方法

來自 Rational 的 Apex 開發環境支援開發架構的定義和實現、和前文描述的分層策略，以及設計規則的實施。Rational Rose 可以在模組和子系統層次上繪製開發藍圖，並支援開發原始碼(Ada、C++）進程的正向和反向工程。

開發視圖的風格

我們推薦使用分層（layered）的風格，定義 4 到 6 個子系統層。每層均具有良好定義的職責。設計規則是某層子系統依賴同一層或低一層的子系統，從而最大程度地減少了具有複雜模組依賴關係的網路的開發量，得到層次式的簡單策略。

圖 6 － Hughes 空中交通系統（HATS）的 5 個層

開發架構的例子

圖 6 代表了加拿大的 Hughes Aircraft 開發的空中交通控制系統（Air Traffic Control system）產品線的 5 個分層開發組織圖。這是和圖 3 b 描述的邏輯架構相對應的開發架構。

第 一層 和第二層組成了獨立於域的覆蓋整個產品線的分布式基礎設施，並保護其免受不同硬體平台、作業系統或市售產品（如資料庫管理系統）的影響。第三層為該基礎設 施增加了 ATC 架構，形成一個特定領域的軟體架構（domain-specific software architecture）。使用該架構,可以在第四層上構建一個功能選擇板。層次 5 則非常依賴於客戶和產品,包含了大多數使用者介面和外部系統介面。72 個子系統分佈於 5 個層次上，每層包含了 10 至 50 個模組，並可以在其他藍圖上表示。

物理架構

軟體至硬體的映射

物理架構主要關注系 統非功能性的需求，如可用性、可靠性（容錯性），效能（輸送量）和延展性。軟體在電腦網路或處理節點上運行，被識別的各種元素（網路、過程、任務和對 象），需要被映射至不同的節點；我們希望使用不同的物理配置：一些用於開發與測試，另外一些則用於不同地點和不同客戶的部署。因此軟體至節點的映射需要高 度的靈活性及對原始碼產生最小的影響。

物理藍圖的標記法

大型系統中的物理藍圖會變得非常混亂，所以它們可以採用多種形式，有或者沒有來自進程視圖的映射均可。

圖 7 － 物理藍圖的標記法

TRW 的 UNAS 提供了資料驅動方法將過程架構映射至物理架構，該方法允許大量的映射 的變更而無需修改原始碼。

物理藍圖的樣本

圖 8 － PABX 的物理藍圖

圖 8 顯示了大型 PABX 可能的硬體設定,而圖 9 和圖 10 顯示了兩種不同物理架構上的進程映射，分別對應一個小型和一個大型 PABX。C、F 和 K 是三種不同容量的電腦，支援三種不同的運行要求。

圖 9 － 帶有過程分配的小型 PABX 物理架構

圖10－顯示了過程分配的大型PABX物理藍圖

情境

綜合所有的視圖

四種視圖的元素通過數量比較少的一組重要情境（更常見的是用例）進行無縫協同工作，我們為情境描述相應的指令碼（對象之間和過程之間的互動序列）。正如 Rubin 和 Goldberg 所描述的那樣6。

在某種意義上情境是最重要的需求抽象，它們的設計使用對象情境圖和對象互動圖來表示4。

該視圖是其他視圖的冗餘（因此"＋1"），但它起到了兩個作用：

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

情境的標記法

情境標記法與組件邏輯視圖非常相似（請對照圖 2），但它使用過程視圖的串連符來表示對象之間的互動（請對照圖 4），注意對象執行個體使用實線來表達。至於邏輯藍圖，我們使用 Rational Rose 來捕獲並管理對象情境。

情境的例子

圖 11 顯示了小型 PABX 的情境片段。相應的指令碼是：

1. Joe的電話控制器檢測和校正摘機狀態的變換,並發送訊息喚醒相應的終端對象。

2. 終端分配一些資源，並要求控制器發出撥號音。

3. 控制器接受撥號並傳遞給終端。

4. 終端使用撥號方案來分析數字流。

5. 有效數字序列被鍵入,終端開始會話。

圖 11 － 本地呼叫的初期情境――階段選擇

視圖之間的對應性

各種視圖並不是完全是正交的或獨立的。視圖的元素根據某種設計規則和啟發學習法方法與其他視圖中的元素相關聯。

從邏輯視圖到過程視圖

我們發現邏輯視架構有幾項重要特性：

• 自主性：對象是主動的、被動的還是被保護的？
  • 主動對象享有調用其他對象或其自身操作的主動權，並且當其他對象對其進行調用時，具有對其自身操作的完全控制權。
  • 被動對象不能主動調用任何操作，對其他對象調用自身的操作沒有控制。
  • 被保護對象不能主動調用任何操作。但對自身的操作有一定的控制功能。
• 持久化：對象是暫時的還是持久化的？它們是否會導致過程或處理器的終止？
• 依賴性：對象的存在或持久化是否依賴於另一個對象？
• 分布性：對象的狀態或操作是否能被物理架構中的許多節點所訪問？或是被進程架構中的幾個進程所訪問？

在邏輯視圖中，我們認為每個對象均是主動的，具有潛在的"並發性"，即與其他對象具有"平行的"行為，我們並不考慮所要達到的確切並發程度。因此，邏輯結構所考慮的僅是需求的功能性方面。

然而，當我們定義進程架構時，由於巨大的開銷，為每個對象實施各自的控制線程（例如，Unix 進程或 Ada 任務），在目前的技術狀況下是不現實的。此外，如果對象是並發的，那麼必須以某種抽象形式來調用它們的操作。

另一方面，由於以下幾種原因需要多個控制線程。

• 為了快速響應某類外部觸發，包括與時間相關的事件。
• 為了在一個節點中利用多個 CPU，或者在一個分布式系統中利用多個節點。
• 為了提高 CPU 的利用率，在某些控制線程被掛起，等待其他活動結束的時候（例如，訪問外部對象其他使用中的物件時），為其他的活動分配 CPU。
• 為了劃分活動的優先順序（提高潛在的響應能力）。
• 為了支援系統的延展性（藉助於共用負載的其他過程）。
• 為了在軟體的不同領域分離關注點。
• 為了提高系統的可用性（通過 Backup 過程）。

我們同時使用兩種策略來決定並發的程度和定義所需的過程集合。考慮一系列潛在的物理目標架構。以下兩種形式我們可以任選其一：

• 從內至外:
  
  由邏輯架構開始：定義代理任務，該任務將控制一個類的多個使用中的物件的單個線程進行多元化處理；同一代理任務還執行持久化處理那些依賴於一個主動對象的對象；需要相互進行操作的幾個類或僅需要少量處理的類共用單個代理。這種彙總會一直進行，直到我們將過程減少到合理的較少數量，而仍允許分布性和對實體資源的使用。
• 由外至內:
  
  從物理結構開始：識別系統的外部觸發；定義處理觸發的客戶過程和僅提供服務（而非初始化它們）的伺服器處理序；使用資料完整性和問題的序列化（serialization）約束來定義正確的伺服器設定，並且為客戶機與伺服器代理指派至；識別出必須分布哪些對象。

其結果是將類（和它們的對象）映射至一個任務集合和進程架構中的進程。通常，活動類具有代理任務，也存在一些變形：對於給定的類，使用多個代理以提高輸送量，或者多個類映射至單個代理，因為它們的操作並不是頻繁地被調用，或者是為了保證執行序列。

注意這並不是產生最佳過程架構的線性、決定性的進程；它需要若干個迭代來得到可接受的折衷。還存在許多其他方法，例如 Birman 等人5 或 Witt 等人7提出的方法。 確切的實施映射的方法不在本文的討論範圍，但我們以一個小的例子來說明一下。

圖 12 顯示了一個小的類集合如何從假想的空中交通控制系統映射至進程。

flight 類映射至一個 flight 代理集合：有許多航班等待處理，外部觸發的頻率很高，回應時間很關鍵，負載必須分佈於多個 CPU。並且，航班處理的持久化和分布性方面都取決於 flight server，為了滿足可用性，還是使用 flight server 的一台備份伺服器。

航班的 profile 和 clearance 總是從屬於某個航班,儘管它們是複雜的類,但它們共用 flight 類的進程。航班分佈於若干其他進程，特別是對於顯示和外部介面。

sectorization 類，為 controller 的許可權分配建立了空域劃分。由於完整性條件約束，僅能被一個代理處理，但可以與 flight 類共用伺服器過程：更新得並不頻繁。

location 和 arispace 及其他的靜態航空資訊是受到保護的對象，在幾個類中共用，很少被更新；它們被映射至各自的伺服器，分佈於其他過程。

圖 12 － 從邏輯視圖到過程視圖的映射

從邏輯視圖到開發視圖

類通常作為一個模組來實現，例如 Ada 包中可視部分的一個類型。密切相關的類（類的種類）的集合組合到子系統中。子系統的定義必須考慮額外的約束，如團隊組織、期望的代碼規模（通常每個子系統為 5 K 或 20 K SLOC）、可重用性和通用性的程度以及嚴格的分層依據（可視性問題），發布策略和組態管理。所以，通常最後得到的不是與邏輯視圖逐一對應的視圖。

邏輯視圖和開發視圖非常接近，但具有不同的關注點。我們發現項目規模越大，視圖間的差距也越大。例如，如果比較圖 3 b 和圖 6，則會發現並不存在逐一對應的類的不同種類到層的映射。而如果我們考慮類的種類的"外部介面"－網關種類時，它的實現遍布若干層：通訊協議在第 1 層或以下的層，通用網關機制在第 2 層，而特定的網關在第 5 層子系統。

從進程視圖到物理視圖

進程和進程組以不同的測試和部署配置映射至可用的物理硬體。Birman 在 ISIS 項目中描述了詳細的映射模式5。

情境主要以所使用類的形式與邏輯視圖相關聯；而與進程視圖的關聯則是考慮了一個或多個控制線程的、對象間的互動形式。

模型的剪裁

並不是所有的軟體架構都需要"4＋1"視圖。無用的視圖可以從架構描述中省略，比如：只有一個處理器，則可以省略物理視圖；而如果僅有一個進程或程式，則可以省略過程視圖。 對於非常小型的系統，甚至可能邏輯視圖與開發視圖非常相似，而不需要分開的描述。情境對於所有的情況均適用。

迭代過程

Witt 等人為設計和架構指出了 4 個階段：勾畫草圖、組織、具體化和最佳化，分成了 12 個步驟7。他們還指出需要某種程度的反向工程。而我們認為對於大型的項目，該方法太"線性化"了。在 4 個階段的末尾，可用於驗證架構的內容太少。我們提倡一種更具有迭代性質的方法，即架構先被原形化、測試、估量、分析，然後在一系列的迭代過程中被細化。該方法除了減少與架構相關的風險之外，對於項目而言還有其他優點：團隊合作、培訓，加深對架構的理解，深入程式和工具等等（此處提及的是演化的原形，逐漸發展成為系統，而不是一次性的實驗性的原形）。這種迭代方法還能夠使需求被細化、成熟化並能夠被更好地理解。

情境驅動（scenario-driven）的方法

系統大多數關鍵的功能以情境（或 use cases）的形式被捕獲。關鍵意味著：最重要的功能，系統存在的理由，或使用頻率最高的功能，或體現了必須減輕的一些重要的技術風險。

開始階段:

• 基於風險和重要性為某次迭代選擇一些情境。情境可能被歸納為對若干使用者需求的抽象。
• 形成"稻草人式的架構"。然後對情境進行"描述"，以識別主要的抽象（類、機制、過程、子系統），如 Rubin 與 Goldberg6 所指出的 ―― 分解成為序列對（對象、操作）。
• 所發現的架構元素被分布到 4 個藍圖中：邏輯藍圖、進程藍圖、開發藍圖和物理藍圖。
• 然後實施、測試、度量該架構，這項分析可能檢測到一些缺點或潛在的增強要求。
• 捕獲經驗教訓。

迴圈階段:

下一個迭代過程開始進行：

• 重新評估風險，
• 擴充考慮的情境選擇板。
• 選擇能減輕風險或提高結構覆蓋的額外的少量情境，

然後:

• 試著在原先的架構中描述這些情境。
• 發現額外的架構元素，或有時還需要找出適應這些情境所需的重要架構變更。
• 更新4個主要視圖：邏輯視圖、進程視圖、開發視圖和物理視圖。
• 根據變更修訂現有的情境。
• 升級實現工具（架構原型）來支援新的、擴充了的情境集合。
• 測試。如果可能的話，在實際的目標環境和負載下進行測試。
• 然後評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
• 更新設計準則和基本原理。
• 捕獲經驗教訓。

終止迴圈

為了實際的系統，初始的架構原型需要進行演化 。較好的情況是在經過 2 次或 3 次迭代之後，結構變得穩定：主要的抽象都已被找到。子系統和過程都已經完成，以及所有的介面都已經實現。接下來則是軟體設計的範疇，這個階段可能也會用到相似的方法和過程。

這些迭代過程的期間參差不齊，原因在於：所實施項目的規模，參與項目人員的數量、他們對本領域和方法的熟悉程度，以及該系統和開發組織的熟悉程度等等。因而較小的項目迭代過程可能持續 2-3 周（例如，10 K SLOC），而大型的項目可能為 6-9 個月（例如，700 K SLOC）。

架構的文檔化

架構設計中產生的文檔可以歸結為兩種：

• 軟體架構文檔，其結構遵循"4+1"視圖（請對照圖 13，一個典型的提綱）
• 軟體設計準則，捕獲了最重要的設計決策。這些決策必須被遵守，以保持系統架構的完整性。圖 13 － 軟體架構文檔提綱

回頁首

結束語

無論是否經過一次本地定製的和技術上的調整，"4＋1"視圖都能在許多大型項目中成功運用。事實上，它允許不同的"風險承擔人"找出他們就軟體架構所關心的問題。系統工程師首先接觸物理視圖，然後轉向進程視圖；終端使用者、顧客、資料分析專家從邏輯視圖入手；專案經理、軟體配置人員則從開發視圖來看待"4＋1"視圖。在 Rational 和其他地方，提出並討論了其他系列視圖，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我們發現其他視圖通常可以歸入我們所描述的 4 個視圖中的一個。例如 Cost&Schedule 視圖可以歸入開發視圖，將一個資料檢視歸入一個邏輯視圖，以及將一個執行視圖歸入進程視圖和物理視圖的組合。

表 1 － "4＋1"視圖模型一覽表

回頁首

致謝

"4+1" 視圖的誕生要歸功於在Rational、加拿大的 Hughes Aircraft、Alcatel 以及其他地方工作的同事。筆者特別感謝下面這些人的貢獻： Ch. Thompson、A. Bell、M.Devlin、G. Booch、W. Royce、J. Marasco、R. Reitman、V. Ohnjec、E. Schonberg。

架構藍圖--軟體架構 "4+1" 視圖模型