架構藍圖--軟體架構 “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。

部落格位址：https://blog.csdn.net/xiang__liu，https://www.cnblogs.com/xiang--liu/