[轉]架構藍圖--軟件架構 "4+1" 視圖模型

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

本文基於多個併發視圖的使用狀況來講明描述軟件密集型系統架構的模型。使用多重視圖容許獨立地處理各"風險承擔人"：最終用戶、開發人員、系統 工程師、項目經理等所關注的問題，而且可以獨立地處理功能性和非功能性需求。本文分別對五種視圖進行了描述，並同時給出了捕獲每種視圖的表示方法。這些視 圖使用以架構爲中心的、場景驅動以及迭代開發過程來進行設計。

1 評論

Philippe Kruchten, 高級技術專員

2005 年 1 月 01 日

• 內容

在 IBM Bluemix 雲平臺上開發並部署您的下一個應用。

開始您的試用

引言

咱們已經看到在許多文章和書籍中，做者欲使用單張視圖來捕捉全部的系統架構要點。經過仔細地觀察這 些圖例中的方框和箭頭，不難發現做者努力地在單一視圖中表達超過其表達限度的藍圖。方框是表明運行的程序嗎？或者是表明源代碼的程序塊嗎？或是物理計算機 嗎？或僅僅是邏輯功能的分組嗎？箭頭是表示編譯時的依賴關係嗎？或者是控制流嗎？或是數據流嗎？一般它表明了許多事物。是否架構只須要單個的架構樣式？有 時軟件架構的缺陷源於過早地劃分軟件或過度的強調軟件開發的單個方面：數據工程、運行效率、開發策略和團隊組織等。有時架構並不能解決全部"客戶"（或者 說"風險承擔人"，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。