|
Philippe Kruchten
高級技術(shù)專員
2005 年 1 月
本文基于多個并發(fā)視圖的使用情況來說明描述軟件密集型系統(tǒng)架構(gòu)的模型。使用多重視圖允許獨立地處理各"風(fēng)險承擔(dān)人"：最終用戶、開發(fā)人員、系統(tǒng)工程師、項目經(jīng)理等所關(guān)注的問題，并且能夠獨立地處理功能性和非功能性需求。本文分別對五種視圖進行了描述，并同時給出了捕獲每種視圖的表示方法。這些視圖使用以架構(gòu)為中心的、場景驅(qū)動以及迭代開發(fā)過程來進行設(shè)計。
引言
我們已經(jīng)看到在許多文章和書籍中，作者欲使用單張視圖來捕捉所有的系統(tǒng)架構(gòu)要點。通過仔細(xì)地觀察這些圖例中的方框和箭頭，不難發(fā)現(xiàn)作者努力地在單一視圖中表達(dá)超過其表達(dá)限度的藍(lán)圖。方框是代表運行的程序嗎？或者是代表源代碼的程序塊嗎？或是物理計算機嗎？或僅僅是邏輯功能的分組嗎？箭頭是表示編譯時的依賴關(guān)系嗎？或者是控制流嗎？或是數(shù)據(jù)流嗎？通常它代表了許多事物。是否架構(gòu)只需要單個的架構(gòu)樣式？有時軟件架構(gòu)的缺陷源于過早地劃分軟件或過分的強調(diào)軟件開發(fā)的單個方面：數(shù)據(jù)工程、運行效率、開發(fā)策略和團隊組織等。有時架構(gòu)并不能解決所有"客戶"（或者說"風(fēng)險承擔(dān)人"，USC 的命名）所關(guān)注的問題。許多作者都提及了這個問題：Garlan & Shaw 1、CMU 的 Abowd & Allen、SEI 的 Clements。作為補充，我們建議使用多個并發(fā)的視圖來組織軟件架構(gòu)的描述，每個視圖僅用來描述一個特定的所關(guān)注的方面的集合。
架構(gòu)模型
軟件架構(gòu)用來處理軟件高層次結(jié)構(gòu)的設(shè)計和實施。它以精心選擇的形式將若干結(jié)構(gòu)元素進行裝配，從而滿足系統(tǒng)主要功能和性能需求，并滿足其他非功能性需求，如可靠性、可伸縮性、可移植性和可用性。Perry 和 Wolfe 使用一個精確的公式來表達(dá)，該公式由 Boehm 做了進一步修改：
軟件架構(gòu) ＝ {元素，形式，關(guān)系/約束}
軟件架構(gòu)涉及到抽象、分解和組合、風(fēng)格和美學(xué)。我們用由多個視圖或視角組成的模型來描述它。為了最終處理大型的、富有挑戰(zhàn)性的架構(gòu)，該模型包含五個主要的視圖（請對照圖 1）：
- 邏輯視圖（Logical View），設(shè)計的對象模型（使用面向?qū)ο蟮脑O(shè)計方法時）。
- 過程視圖（Process View），捕捉設(shè)計的并發(fā)和同步特征。
- 物理視圖（Physical View），描述了軟件到硬件的映射，反映了分布式特性。
- 開發(fā)視圖（Development View），描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。
架構(gòu)的描述，即所做的各種決定，可以圍繞著這四個視圖來組織，然后由一些用例 （use cases）或場景(scenarios)來說明，從而形成了第五個視圖。正如將看到的，實際上軟件架構(gòu)部分從這些場景演進而來，將在下文中討論。
圖 1 － "4＋1"視圖模型
我們在每個視圖上均獨立地應(yīng)用 Perry & Wolf 的公式，即定義一個所使用的元素集合（組件、容器、連接符），捕獲工作形式和模式，并且捕獲關(guān)系及約束，將架構(gòu)與某些需求連接起來。每種視圖使用自身所特有的表示法－藍(lán)圖（blueprint）來描述，并且架構(gòu)師可以對每種視圖選用特定的架構(gòu)風(fēng)格（architectural style），從而允許系統(tǒng)中多種風(fēng)格并存。
我們將輪流的觀察這五種視圖，展現(xiàn)各個視圖的目標(biāo)：即視圖的所關(guān)注的問題，相應(yīng)的架構(gòu)藍(lán)圖的標(biāo)記方式，描述和管理藍(lán)圖的工具。并以非常簡單的形式從 PABX 的設(shè)計中，從我們在Alcatel 商業(yè)系統(tǒng)（Alcatel Business System）上所做的工作中，以及從航空運輸控制系統(tǒng)（Air Traffic Control system）中引出一些例子―旨在描述一下視圖的特定及其標(biāo)記的方式，而不是定義這些系統(tǒng)的架構(gòu)。
"4+1"視圖模型具有相當(dāng)?shù)?普遍性"，因此可以使用其他的標(biāo)注方法和工具，也可以采用其他的設(shè)計方法，特別是對于邏輯和過程的分解。但文中指出的這些方法都已經(jīng)成功的在實踐中運用過。
邏輯結(jié)構(gòu)
面向?qū)ο蟮姆纸?/P>
邏輯架構(gòu)主要支持功能性需求――即在為用戶提供服務(wù)方面系統(tǒng)所應(yīng)該提供的功能。系統(tǒng)分解為一系列的關(guān)鍵抽象，（大多數(shù)）來自于問題域，表現(xiàn)為對象或?qū)ο箢惖男问健Ｋ鼈儾捎贸橄蟆⒎庋b和繼承的原理。分解并不僅僅是為了功能分析，而且用來識別遍布系統(tǒng)各個部分的通用機制和設(shè)計元素。我們使用 Rational/Booch 方法來表示邏輯架構(gòu)，借助于類圖和類模板的手段 4。類圖用來顯示一個類的集合和它們的邏輯關(guān)系：關(guān)聯(lián)、使用、組合、繼承等等。相似的類可以劃分成類集合。類模板關(guān)注于單個類，它們強調(diào)主要的類操作，并且識別關(guān)鍵的對象特征。如果需要定義對象的內(nèi)部行為，則使用狀態(tài)轉(zhuǎn)換圖或狀態(tài)圖來完成。公共機制或服務(wù)可以在類功能 （class utilities）中定義。對于數(shù)據(jù)驅(qū)動程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，例如 E-R 圖，來代替面向?qū)ο蟮姆椒ǎ∣O approach）。
邏輯視圖的表示法
邏輯視圖的標(biāo)記方法來自 Booch 標(biāo)記法4。當(dāng)僅考慮具有架構(gòu)意義的條目時，這種表示法相當(dāng)簡單。特別是在這種設(shè)計級別上，大量的修飾作用不大。我們使用 Rational Rose? 來支持邏輯架構(gòu)的設(shè)計。
圖 2 － 邏輯藍(lán)圖的表示法
邏輯視圖的風(fēng)格
邏輯視圖的風(fēng)格采用面向?qū)ο蟮娘L(fēng)格，其主要的設(shè)計準(zhǔn)則是試圖在整個系統(tǒng)中保持單一的、一致的對象模型，避免就每個場合或過程產(chǎn)生草率的類和機制的技術(shù)說明。
邏輯結(jié)構(gòu)藍(lán)圖的樣例
圖 3 顯示了 Télic PABX 架構(gòu)中主要的類。
圖 3 － a. Télic PABX 的邏輯藍(lán)圖 b.空中交通系統(tǒng)的藍(lán)圖
PABX 建立終端間的通信連接。終端可以是電話設(shè)備、中繼線（例如，連接到中央辦公室）、連接線（PABX 專線到 PABX 線)、電話專線、數(shù)據(jù)線、ISDN 等等。不同的線路由不同的接口卡提供支持。線路 controller 對象的職責(zé)是在接口卡上對所有的信號進行解碼和注入，在特定于接口卡的信號與一致性的小型事件集合之間進行相互轉(zhuǎn)換：開始、停止、數(shù)字化等。controller 對象同時承載所有的實時約束。該類派生出許多子類以滿足不同的接口類型。terminal 對象的責(zé)任是維持終端的狀態(tài)，代表線路協(xié)調(diào)各項服務(wù)。例如，它使用 numbering plan 服務(wù)來解釋撥號。conversation 代表了會話中的一系列終端 。conversation 使用了Translation Service(目錄、邏輯物理映射、路由),以及建立終端之間語音路徑的Connection Service 。
對于一個包含了大量的具有架構(gòu)重要意義的類的、更大的系統(tǒng)來說，圖 3 b 描述了空中交通管理系統(tǒng)的頂層類圖，包含 8 個類的種類（例如，類的分組）。
進程架構(gòu)
過程分解
進程架構(gòu)考慮一些非功能性的需求，如性能和可用性。它解決并發(fā)性、分布性、系統(tǒng)完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結(jié)構(gòu)相配合在一起－即在哪個控制線程上，對象的操作被實際執(zhí)行。
進程架構(gòu)可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構(gòu)可以視為一組獨立執(zhí)行的通信程序（叫作"processes"）的邏輯網(wǎng)絡(luò)，它們分布在整個一組硬件資源上，這些資源通過 LAN 或者 WAN 連接起來。多個邏輯網(wǎng)絡(luò)可能同時并存，共享相同的物理資源。例如，獨立的邏輯網(wǎng)絡(luò)可能用于支持離線系統(tǒng)與在線系統(tǒng)的分離，或者支持軟件的模擬版本和測試版本的共存。
進程是構(gòu)成可執(zhí)行單元任務(wù)的分組。進程代表了可以進行策略控制過程架構(gòu)的層次（即：開始、恢復(fù)、重新配置及關(guān)閉）。另外，進程可以就處理負(fù)載的分布式增強或可用性的提高而不斷地被重復(fù)。
軟件被劃分為一系列單獨的任務(wù)。任務(wù)是獨立的控制線程，可以在處理節(jié)點上單獨地被調(diào)度。
接著，我們可以區(qū)別主要任務(wù)、次要任務(wù)。主要任務(wù)是可以唯一處理的架構(gòu)元素；次要任務(wù)是由于實施原因而引入的局部附加任務(wù)（周期性活動、緩沖、暫停等等）。它們可以作為 Ada Task 或輕量線程來實施。主要任務(wù)的通訊途徑是良好定義的交互任務(wù)通信機制：基于消息的同步或異步通信服務(wù)、遠(yuǎn)程過程調(diào)用、事件廣播等。次要任務(wù)則以會見或共享內(nèi)存來通信。在同一過程或處理節(jié)點上，主要任務(wù)不應(yīng)對它們的分配做出任何假定。
消息流、過程負(fù)載可以基于過程藍(lán)圖來進行評估，同樣可以使用啞負(fù)載來實現(xiàn)"中空"的進程架構(gòu)，并測量在目標(biāo)系統(tǒng)上的性能。正如 Filarey et al. 在他的 Eurocontrol 實驗中描述的那樣。
進程視圖的表示法
我們所使用的進程視圖的表示方法是從Booch最初為 Ada 任務(wù)推薦的表示方法擴展而來。同樣，用來所使用的表示法關(guān)注在架構(gòu)上具有重要意義的元素。(圖 4)
圖 4 － 過程藍(lán)圖表示法
我們曾使用來自 TRW 的 Universal Network Architechure Services（UNAS0） 產(chǎn)品來構(gòu)建并實施過程和任務(wù)集合（包擴它們的冗余），使它們?nèi)谌脒^程的網(wǎng)絡(luò)中。UNAS 包含 Software Architect Lifecycle Environment(SALE)工具，它支持上述表示方法。SALE 允許以圖形的形式來描述進程架構(gòu)，包括對可能的交互任務(wù)通信路徑的規(guī)格說明，正是從這些路徑中自動生成對應(yīng)的 Ada 或 C++ 源代碼。使用該方法來指定和實施進程架構(gòu)的優(yōu)點是易于進行修改而不會對應(yīng)用軟件造成太多的影響。
進程視圖的風(fēng)格
許多風(fēng)格可以適用于進程視圖。例如采用 Garlan 和 Shaw 的分類法1,我們可以得到管道和過濾器（Pipes and filters）,或客戶端/服務(wù)器，以及各種多個客戶端/單個服務(wù)器和多個客戶端/多個服務(wù)器的變體。對于更加復(fù)雜的系統(tǒng),可以采用類似于 K.Birman 所描述的ISIS系統(tǒng)中進程組方法以及其它的標(biāo)注方法和工具。
進程藍(lán)圖的例子
圖 5 － Télic PABX 的過程藍(lán)圖（部分）
所有的終端由單個的 Termal process 處理，其中 Termal process 由輸入隊列中的消息進行驅(qū)動。Controller 對象在組成控制過程三個任務(wù)之中的一項任務(wù)上執(zhí)行：Low cycle rate task 掃描所有的非活動終端(200 ms)，將 High cycle rate task(10 ms)掃描清單中的終端激活，其中 High cycle rate task 檢測任何重要的狀態(tài)變化，將它們傳遞給 Main controller task，由它來對狀態(tài)的變更進行解釋,并通過向?qū)?yīng)的終端發(fā)送消息來通信。這里 Controller 過程中的通信通過共享內(nèi)存來實現(xiàn)。
開發(fā)架構(gòu)
子系統(tǒng)分解
開發(fā)架構(gòu)關(guān)注軟件開發(fā)環(huán)境下實際模塊的組織。軟件打包成小的程序塊（程序庫或子系統(tǒng)），它們可以由一位或幾位開發(fā)人員來開發(fā)。子系統(tǒng)可以組織成分層結(jié)構(gòu)，每個層為上一層提供良好定義的接口。
系統(tǒng)的開發(fā)架構(gòu)用模塊和子系統(tǒng)圖來表達(dá)，顯示了"輸出"和"輸入"關(guān)系。完整的開發(fā)架構(gòu)只有當(dāng)所有軟件元素被識別后才能加以描述。但是，可以列出控制開發(fā)架構(gòu)的規(guī)則：分塊、分組和可見性。
大部分情況下，開發(fā)架構(gòu)考慮的內(nèi)部需求與以下幾項因素有關(guān)：開發(fā)難度、軟件管理、重用性和通用性及由工具集、編程語言所帶來的限制。開發(fā)架構(gòu)視圖是各種活動的基礎(chǔ)，如：需求分配、團隊工作的分配（或團隊機構(gòu)）、成本評估和計劃、項目進度的監(jiān)控、軟件重用性、移植性和安全性。它是建立產(chǎn)品線的基礎(chǔ)。
開發(fā)藍(lán)圖的表示方法
同樣，使用 Booch 方法的變形，僅考慮具有架構(gòu)意義的項。
圖 5 － 開發(fā)藍(lán)圖表示方法
來自 Rational 的 Apex 開發(fā)環(huán)境支持開發(fā)架構(gòu)的定義和實現(xiàn)、和前文描述的分層策略，以及設(shè)計規(guī)則的實施。Rational Rose 可以在模塊和子系統(tǒng)層次上繪制開發(fā)藍(lán)圖，并支持開發(fā)源代碼(Ada、C++）進程的正向和反向工程。
開發(fā)視圖的風(fēng)格
我們推薦使用分層（layered）的風(fēng)格，定義 4 到 6 個子系統(tǒng)層。每層均具有良好定義的職責(zé)。設(shè)計規(guī)則是某層子系統(tǒng)依賴同一層或低一層的子系統(tǒng)，從而最大程度地減少了具有復(fù)雜模塊依賴關(guān)系的網(wǎng)絡(luò)的開發(fā)量，得到層次式的簡單策略。
圖 6 － Hughes 空中交通系統(tǒng)（HATS）的 5 個層
開發(fā)架構(gòu)的例子
圖 6 代表了加拿大的 Hughes Aircraft 開發(fā)的空中交通控制系統(tǒng)（Air Traffic Control system）產(chǎn)品線的 5 個分層開發(fā)組織結(jié)構(gòu)。這是和圖 3 b 描述的邏輯架構(gòu)相對應(yīng)的開發(fā)架構(gòu)。
第一層 和第二層組成了獨立于域的覆蓋整個產(chǎn)品線的分布式基礎(chǔ)設(shè)施，并保護其免受不同硬件平臺、操作系統(tǒng)或市售產(chǎn)品（如數(shù)據(jù)庫管理系統(tǒng)）的影響。第三層為該基礎(chǔ)設(shè)施增加了 ATC 框架，形成一個特定領(lǐng)域的軟件架構(gòu)（domain-specific software architecture）。使用該框架,可以在第四層上構(gòu)建一個功能選擇板。層次 5 則非常依賴于客戶和產(chǎn)品,包含了大多數(shù)用戶接口和外部系統(tǒng)接口。72 個子系統(tǒng)分布于 5 個層次上，每層包含了 10 至 50 個模塊，并可以在其他藍(lán)圖上表示。
物理架構(gòu)
軟件至硬件的映射
物理架構(gòu)主要關(guān)注系統(tǒng)非功能性的需求，如可用性、可靠性（容錯性），性能（吞吐量）和可伸縮性。軟件在計算機網(wǎng)絡(luò)或處理節(jié)點上運行，被識別的各種元素（網(wǎng)絡(luò)、過程、任務(wù)和對象），需要被映射至不同的節(jié)點；我們希望使用不同的物理配置：一些用于開發(fā)和測試，另外一些則用于不同地點和不同客戶的部署。因此軟件至節(jié)點的映射需要高度的靈活性及對源代碼產(chǎn)生最小的影響。
物理藍(lán)圖的表示法
大型系統(tǒng)中的物理藍(lán)圖會變得非常混亂，所以它們可以采用多種形式，有或者沒有來自進程視圖的映射均可。
圖 7 － 物理藍(lán)圖的表示法
TRW 的 UNAS 提供了數(shù)據(jù)驅(qū)動方法將過程架構(gòu)映射至物理架構(gòu)，該方法允許大量的映射的變更而無需修改源代碼。
物理藍(lán)圖的示例
圖 8 － PABX 的物理藍(lán)圖
圖 8 顯示了大型 PABX 可能的硬件配置,而圖 9 和圖 10 顯示了兩種不同物理架構(gòu)上的進程映射，分別對應(yīng)一個小型和一個大型 PABX。C、F 和 K 是三種不同容量的計算機，支持三種不同的運行要求。
圖 9 － 帶有過程分配的小型 PABX 物理架構(gòu)
圖10－顯示了過程分配的大型PABX物理藍(lán)圖
場景
綜合所有的視圖
四種視圖的元素通過數(shù)量比較少的一組重要場景（更常見的是用例）進行無縫協(xié)同工作，我們?yōu)閳鼍懊枋鱿鄳?yīng)的腳本（對象之間和過程之間的交互序列）。正如 Rubin 和 Goldberg 所描述的那樣6。
在某種意義上場景是最重要的需求抽象，它們的設(shè)計使用對象場景圖和對象交互圖來表示4。
該視圖是其他視圖的冗余（因此"＋1"），但它起到了兩個作用：
- 作為一項驅(qū)動因素來發(fā)現(xiàn)架構(gòu)設(shè)計過程中的架構(gòu)元素，這一點將在下文中討論。
- 作為架構(gòu)設(shè)計結(jié)束后的一項驗證和說明功能，既以視圖的角度來說明又作為架構(gòu)原型測試的出發(fā)點。
場景的表示法
場景表示法與組件邏輯視圖非常相似（請對照圖 2），但它使用過程視圖的連接符來表示對象之間的交互（請對照圖 4），注意對象實例使用實線來表達(dá)。至于邏輯藍(lán)圖，我們使用 Rational Rose 來捕獲并管理對象場景。
場景的例子
圖 11 顯示了小型 PABX 的場景片段。相應(yīng)的腳本是：
1. Joe的電話控制器檢測和校驗摘機狀態(tài)的變換,并發(fā)送消息喚醒相應(yīng)的終端對象。
2. 終端分配一些資源，并要求控制器發(fā)出撥號音。
3. 控制器接受撥號并傳遞給終端。
4. 終端使用撥號方案來分析數(shù)字流。
5. 有效的數(shù)字序列被鍵入,終端開始會話。
圖 11 － 本地呼叫的初期場景――階段選擇
視圖之間的對應(yīng)性
各種視圖并不是完全是正交的或獨立的。視圖的元素根據(jù)某種設(shè)計規(guī)則和啟發(fā)式方法與其他視圖中的元素相關(guān)聯(lián)。
從邏輯視圖到過程視圖
我們發(fā)現(xiàn)邏輯視架構(gòu)有幾項重要特性：
- 自主性：對象是主動的、被動的還是被保護的？
- 主動對象享有調(diào)用其他對象或其自身操作的主動權(quán)，并且當(dāng)其他對象對其進行調(diào)用時，具有對其自身操作的完全控制權(quán)。
- 被動對象不能主動調(diào)用任何操作，對其他對象調(diào)用自身的操作沒有控制。
- 被保護對象不能主動調(diào)用任何操作。但對自身的操作有一定的控制功能。
- 持久化：對象是暫時的還是持久化的？它們是否會導(dǎo)致過程或處理器的終止？
- 依賴性：對象的存在或持久化是否依賴于另一個對象？
- 分布性：對象的狀態(tài)或操作是否能被物理架構(gòu)中的許多節(jié)點所訪問？或是被進程架構(gòu)中的幾個進程所訪問？
在邏輯視圖中，我們認(rèn)為每個對象均是主動的，具有潛在的"并發(fā)性"，即與其他對象具有"平行的"行為，我們并不考慮所要達(dá)到的確切并發(fā)程度。因此，邏輯結(jié)構(gòu)所考慮的僅是需求的功能性方面。
然而，當(dāng)我們定義進程架構(gòu)時，由于巨大的開銷，為每個對象實施各自的控制線程（例如，Unix 進程或 Ada 任務(wù)），在目前的技術(shù)狀況下是不現(xiàn)實的。此外，如果對象是并發(fā)的，那么必須以某種抽象形式來調(diào)用它們的操作。
另一方面，由于以下幾種原因需要多個控制線程。
- 為了快速響應(yīng)某類外部觸發(fā)，包括與時間相關(guān)的事件。
- 為了在一個節(jié)點中利用多個 CPU，或者在一個分布式系統(tǒng)中利用多個節(jié)點。
- 為了提高 CPU 的利用率，在某些控制線程被掛起，等待其他活動結(jié)束的時候（例如，訪問外部對象其他活動對象時），為其他的活動分配 CPU。
- 為了劃分活動的優(yōu)先級（提高潛在的響應(yīng)能力）。
- 為了支持系統(tǒng)的可伸縮性（借助于共享負(fù)載的其他過程）。
- 為了在軟件的不同領(lǐng)域分離關(guān)注點。
- 為了提高系統(tǒng)的可用性（通過 Backup 過程）。
我們同時使用兩種策略來決定并發(fā)的程度和定義所需的過程集合。考慮一系列潛在的物理目標(biāo)架構(gòu)。以下兩種形式我們可以任選其一：
- 從內(nèi)至外:
由邏輯架構(gòu)開始：定義代理任務(wù)，該任務(wù)將控制一個類的多個活動對象的單個線程進行多元化處理；同一代理任務(wù)還執(zhí)行持久化處理那些依賴于一個主動對象的對象；需要相互進行操作的幾個類或僅需要少量處理的類共享單個代理。這種聚合會一直進行，直到我們將過程減少到合理的較少數(shù)量，而仍允許分布性和對物理資源的使用。
- 由外至內(nèi):
從物理結(jié)構(gòu)開始：識別系統(tǒng)的外部觸發(fā)；定義處理觸發(fā)的客戶過程和僅提供服務(wù)（而非初始化它們）的服務(wù)器進程；使用數(shù)據(jù)完整性和問題的串行化（serialization）約束來定義正確的服務(wù)器設(shè)置，并且為客戶機與服務(wù)器代理分配對象；識別出必須分布哪些對象。
其結(jié)果是將類（和它們的對象）映射至一個任務(wù)集合和進程架構(gòu)中的進程。通常，活動類具有代理任務(wù)，也存在一些變形：對于給定的類，使用多個代理以提高吞吐量，或者多個類映射至單個代理，因為它們的操作并不是頻繁地被調(diào)用，或者是為了保證執(zhí)行序列。
注意這并不是產(chǎn)生最佳過程架構(gòu)的線性的、決定性的進程；它需要若干個迭代來得到可接受的折衷。還存在許多其他方法，例如 Birman 等人5 或 Witt 等人7提出的方法。 確切的實施映射的方法不在本文的討論范圍，但我們以一個小的例子來說明一下。
圖 12 顯示了一個小的類集合如何從假想的空中交通控制系統(tǒng)映射至進程。
flight 類映射至一個 flight 代理集合：有許多航班等待處理，外部觸發(fā)的頻率很高，響應(yīng)時間很關(guān)鍵，負(fù)載必須分布于多個 CPU。并且，航班處理的持久化和分布性方面都取決于 flight server，為了滿足可用性，還是使用 flight server 的一臺備份服務(wù)器。
航班的 profile 和 clearance 總是從屬于某個航班,盡管它們是復(fù)雜的類,但它們共享 flight 類的進程。航班分布于若干其他進程，特別是對于顯示和外部接口。
sectorization 類，為 controller 的權(quán)限分配建立了空域劃分。由于完整性約束，僅能被一個代理處理，但可以與 flight 類共享服務(wù)器過程：更新得并不頻繁。
location 和 arispace 及其他的靜態(tài)航空信息是受到保護的對象，在幾個類中共享，很少被更新；它們被映射至各自的服務(wù)器，分布于其他過程。
圖 12 － 從邏輯視圖到過程視圖的映射
從邏輯視圖到開發(fā)視圖
類通常作為一個模塊來實現(xiàn)，例如 Ada 包中可視部分的一個類型。密切相關(guān)的類（類的種類）的集合組合到子系統(tǒng)中。子系統(tǒng)的定義必須考慮額外的約束，如團隊組織、期望的代碼規(guī)模（通常每個子系統(tǒng)為 5 K 或 20 K SLOC）、可重用性和通用性的程度以及嚴(yán)格的分層依據(jù)（可視性問題），發(fā)布策略和配置管理。所以，通常最后得到的不是與邏輯視圖逐一對應(yīng)的視圖。
邏輯視圖和開發(fā)視圖非常接近，但具有不同的關(guān)注點。我們發(fā)現(xiàn)項目規(guī)模越大，視圖間的差距也越大。例如，如果比較圖 3 b 和圖 6，則會發(fā)現(xiàn)并不存在逐一對應(yīng)的類的不同種類到層的映射。而如果我們考慮類的種類的"外部接口"－網(wǎng)關(guān)種類時，它的實現(xiàn)遍布若干層：通訊協(xié)議在第 1 層或以下的層，通用網(wǎng)關(guān)機制在第 2 層，而特定的網(wǎng)關(guān)在第 5 層子系統(tǒng)。
從進程視圖到物理視圖
進程和進程組以不同的測試和部署配置映射至可用的物理硬件。Birman 在 ISIS 項目中描述了詳細(xì)的映射模式5。
場景主要以所使用類的形式與邏輯視圖相關(guān)聯(lián)；而與進程視圖的關(guān)聯(lián)則是考慮了一個或多個控制線程的、對象間的交互形式。
模型的剪裁
并不是所有的軟件架構(gòu)都需要"4＋1"視圖。無用的視圖可以從架構(gòu)描述中省略，比如：只有一個處理器，則可以省略物理視圖；而如果僅有一個進程或程序，則可以省略過程視圖。 對于非常小型的系統(tǒng)，甚至可能邏輯視圖與開發(fā)視圖非常相似，而不需要分開的描述。場景對于所有的情況均適用。
迭代過程
Witt 等人為設(shè)計和架構(gòu)指出了 4 個階段：勾畫草圖、組織、具體化和優(yōu)化，分成了 12 個步驟7。他們還指出需要某種程度的反向工程。而我們認(rèn)為對于大型的項目，該方法太"線性化"了。在 4 個階段的末尾，可用于驗證架構(gòu)的內(nèi)容太少。我們提倡一種更具有迭代性質(zhì)的方法，即架構(gòu)先被原形化、測試、估量、分析，然后在一系列的迭代過程中被細(xì)化。該方法除了減少與架構(gòu)相關(guān)的風(fēng)險之外，對于項目而言還有其他優(yōu)點：團隊合作、培訓(xùn)，加深對架構(gòu)的理解，深入程序和工具等等（此處提及的是演進的原形，逐漸發(fā)展成為系統(tǒng)，而不是一次性的試驗性的原形）。這種迭代方法還能夠使需求被細(xì)化、成熟化并能夠被更好地理解。
場景驅(qū)動（scenario-driven）的方法
系統(tǒng)大多數(shù)關(guān)鍵的功能以場景（或 use cases）的形式被捕獲。關(guān)鍵意味著：最重要的功能，系統(tǒng)存在的理由，或使用頻率最高的功能，或體現(xiàn)了必須減輕的一些重要的技術(shù)風(fēng)險。
開始階段:
- 基于風(fēng)險和重要性為某次迭代選擇一些場景。場景可能被歸納為對若干用戶需求的抽象。
- 形成"稻草人式的架構(gòu)"。然后對場景進行"描述"，以識別主要的抽象（類、機制、過程、子系統(tǒng)），如 Rubin 與 Goldberg6 所指出的 ―― 分解成為序列對（對象、操作）。
- 所發(fā)現(xiàn)的架構(gòu)元素被分布到 4 個藍(lán)圖中：邏輯藍(lán)圖、進程藍(lán)圖、開發(fā)藍(lán)圖和物理藍(lán)圖。
- 然后實施、測試、度量該架構(gòu)，這項分析可能檢測到一些缺點或潛在的增強要求。
- 捕獲經(jīng)驗教訓(xùn)。
循環(huán)階段:
下一個迭代過程開始進行：
- 重新評估風(fēng)險，
- 擴展考慮的場景選擇板。
- 選擇能減輕風(fēng)險或提高結(jié)構(gòu)覆蓋的額外的少量場景，
然后:
- 試著在原先的架構(gòu)中描述這些場景。
- 發(fā)現(xiàn)額外的架構(gòu)元素，或有時還需要找出適應(yīng)這些場景所需的重要架構(gòu)變更。
- 更新4個主要視圖：邏輯視圖、進程視圖、開發(fā)視圖和物理視圖。
- 根據(jù)變更修訂現(xiàn)有的場景。
- 升級實現(xiàn)工具（架構(gòu)原型）來支持新的、擴展了的場景集合。
- 測試。如果可能的話，在實際的目標(biāo)環(huán)境和負(fù)載下進行測試。
- 然后評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
- 更新設(shè)計準(zhǔn)則和基本原理。
- 捕獲經(jīng)驗教訓(xùn)。
終止循環(huán)
為了實際的系統(tǒng)，初始的架構(gòu)原型需要進行演進 。較好的情況是在經(jīng)過 2 次或 3 次迭代之后，結(jié)構(gòu)變得穩(wěn)定：主要的抽象都已被找到。子系統(tǒng)和過程都已經(jīng)完成，以及所有的接口都已經(jīng)實現(xiàn)。接下來則是軟件設(shè)計的范疇，這個階段可能也會用到相似的方法和過程。
這些迭代過程的持續(xù)時間參差不齊，原因在于：所實施項目的規(guī)模，參與項目人員的數(shù)量、他們對本領(lǐng)域和方法的熟悉程度，以及該系統(tǒng)和開發(fā)組織的熟悉程度等等。因而較小的項目迭代過程可能持續(xù) 2-3 周（例如，10 K SLOC），而大型的項目可能為 6-9 個月（例如，700 K SLOC）。
架構(gòu)的文檔化
架構(gòu)設(shè)計中產(chǎn)生的文檔可以歸結(jié)為兩種：
- 軟件架構(gòu)文檔，其結(jié)構(gòu)遵循"4+1"視圖（請對照圖 13，一個典型的提綱）
- 軟件設(shè)計準(zhǔn)則，捕獲了最重要的設(shè)計決策。這些決策必須被遵守，以保持系統(tǒng)架構(gòu)的完整性。
圖 13 － 軟件架構(gòu)文檔提綱
結(jié)束語
無論是否經(jīng)過一次本地定制的和技術(shù)上的調(diào)整，"4＋1"視圖都能在許多大型項目中成功運用。事實上，它允許不同的"風(fēng)險承擔(dān)人"找出他們就軟件架構(gòu)所關(guān)心的問題。系統(tǒng)工程師首先接觸物理視圖，然后轉(zhuǎn)向進程視圖；最終用戶、顧客、數(shù)據(jù)分析專家從邏輯視圖入手；項目經(jīng)理、軟件配置人員則從開發(fā)視圖來看待"4＋1"視圖。在 Rational 和其他地方，提出并討論了其他系列視圖，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我們發(fā)現(xiàn)其他視圖通常可以歸入我們所描述的 4 個視圖中的一個。例如 Cost&Schedule 視圖可以歸入開發(fā)視圖，將一個數(shù)據(jù)視圖歸入一個邏輯視圖，以及將一個執(zhí)行視圖歸入進程視圖和物理視圖的組合。
表 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。
參考資料
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
- D. Garlan & M. Shaw, "An Introduction to Software Architecture," Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
- D. E. Perry & A. L. Wolf, "Foundations for the Study of Software Architecture," ACM Software Engineering Notes, 17, 4, October 1992, 40-52.
- Ph. Kruchten & Ch. Thompson, "An Object-Oriented, Distributed Architecture for Large Scale Ada Systems," Proceedings of the TRI-Ada '94 Conference, Baltimore, November 6-11, 1994, ACM,p.262-271.
- G. Booch: Object-Oriented Analysis and Design with Applications, 2nd. edition, Benjamin-Cummings Pub. Co., Redwood City, California, 1993, 589p.
- K. P. Birman, and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE Computer Society Press, Los Alamitos CA, 1994.
- K. Rubin & A. Goldberg, "Object Behavior Analysis," CACM, 35, 9 (Sept. 1992) 48-62
- B. I. Witt, F. T. Baker and E. W. Merritt, Software Architecture and Design-Principles, Models, and Methods, Van Nostrand Reinhold, New-York (1994) 324p.
- D. Garlan (ed.), Proceedings of the First Internal Workshop on Architectures for Software Systems, CMU-CS-TR-95-151, CMU, Pittsburgh, 1995.
關(guān)于作者
Philippe Kruchten |
 |