軟體架構的 4 + 1 View

Jan. 16 15:48~18:33; 20:30~22:10

▲4+1 View，節錄自〈The 4+1 View Model of Architecture〉（以下圖片除最後一張照片其餘皆節錄自該論文）

 

前言

昨天〈什麼是軟體架構？〉介紹了2012年出版的《Software Architecture in Practice, 3rd》對於軟體架構的定義，今天把時間往回推，介紹一篇1995年發表於IEEE Software的文章〈The 4+1 View Model of Architecture〉，並比較兩者之間的異同，讓鄉民們可以減少對於相同意義不同用語的名詞之間的誤解。

這篇文章雖然已經問世超過21年，但對於軟體架構領域來講依舊是非常經典的文章，值得一讀。文章標題開宗明義告訴大家它用5個觀點或視角（View或Perspective）來表達軟體架構，這5個觀點分別是：

• Logic View
• Process View
• Development View
• Physical View
• Scenario View

以下逐一介紹。

***

Logic View

邏輯觀點代表功能需求（系統應提供哪些服務給使用者）被拆解之後的結果。在一般軟體專案中若採用物件導向的方式開發，則Logic View以物件（object）或類別（class）和物件之間的關係（association、aggregation、usage、inheritance、instantiation）來呈現。若採用資料驅動的方式來設計，則可以用E-R Diagram來表達Logic View。

在Logic View中物件的重要行為需要被定義在介面上，如果要表達物件的重要內部行為，可以用狀態圖來表達。

 

▲Logic View所使用的符號

在那個年代UML還沒有出生，論文中使用Booch notation來畫圖。

▲論文中舉了兩個Logic View的例子

由圖3a和3b的例子可以很明顯看出來，3a的粒度大小類似OOAD的domain model，圖中的主角是類別（class）。3b的粒度大小類似module，圖中的主角是類別種類（class category）。以下是Teddy個人的解讀，Logic View屬於《Software Architecture in Practice, 3rd》提到的Module Structure 的一部分，代表系統靜態關係。

***

Process View

行程觀點考慮效能或可用性這類的非功能需求，主要關注並行處理、分散式、資料與狀態完整性、容錯處理，以及如何將Logic View的靜態結構對應到Process View的動態視角。有好幾種不同的層次可以用來表達Process View，從最高層次來看，Process View包含一組獨立執行於網路節點的通訊程式（稱為行程，process）。一個行程包含很多個工作，組成一個可執行單位。這些行程可以被啟動、復原、重新組態、關閉、複製、搬移。

一個行程可以包含擁有獨立執行緒且可被單獨排程的task（可以把行程、task想成作業系統中的process與thread）。

 

▲Process View所使用的符號

這些Process View的符號原本是Booch用來描述Ada語言task機制的圖示。Ada語言是當年美國國防部制定用來開發軍用系統的語言，語言本身具備分散式與並行處理的能力，在那個年代是很先進的程式語言。

 

▲論文中的Process View例子

由圖5的例子可以看出來，Process View的「Process」不是「軟體開發流程」的那個「Process」，而是（分散式）作業系統中的那個「Process」，代表（通常）執行於不同網路節點的程式。以現在的角度來看，Process View非常重要，因為現在分散式系統實在是太普遍了，Logic View要如何對應到Process View必須要被清楚描述。有研究SOA（服務導向架構）或Microservice architecture（微服務架構）的鄉民們應該也看出來，在這種架構中Process View顯得更加重要。

以下是Teddy個人的解讀，Process View類似《Software Architecture in Practice, 3rd》提到的Component-and-Connector（C&C）Structure，代表系統動態關係。

***

Development View

開發觀點將系統分解成子系統，軟體被打包成可以被個人或開發團隊所實作的程式庫、類別庫或子系統。子系統被組成階層式架構，每一層都有清楚定義的介面與上層子系統溝通。

開發觀點以模組和子系統圖來表達，並註明引入（import）和輸出（export）關係。

 

▲Development View所使用的符號，同樣採用Booch notation

 

▲論文中的Development View例子

論文建議採用一個包含4~6個階層的layered style來表達Development View，請參考圖6的例子。以下是Teddy個人的解讀，《Software Architecture in Practice, 3rd》的Module Structure包含Development View。

***

Physical View

實體觀點將軟體對應到硬體，關注可用性、可靠性、效能、可擴展性等非功能需求。軟體系統執行於網路節點，network、process、task、object這些元素要被對應到實體的網路節點。通常Physical View針對開發環境、測試環境、生產環境會有不同的配置（看到這裡是否想到持續整合與持續佈署？）

 

▲Physical View所使用的符號

大型系統的Physical View可能非常繁瑣混亂，其表達方式也可以有很多種。論文中並沒有提到Physical View採用哪種notation，直接給了圖7的圖表。看到這裡鄉民們先想一下Physical View和Process View是不是有些類似？都涵蓋了效能或可用性。主要的差別在於Process View是從軟體的角度來看待程式（並行）執行的問題，而Physical View是從硬體的角度。所以由圖1可知，在畫Physical View的時候可能需要參考Process View與Development View。

 

▲論文中的Physical View例子

從圖8可以看出來最上面C primary和C backup是兩個實體的網路節點，作為備援以提高系統的可用性與可靠性。理論上這些網路節點上應該執行若干的行程（Process），但圖8並沒有畫出來。

 

▲論文中另一個Physical View例子

圖10與圖8類似，但在圖10中的網路節點同時顯示了Process。

Teddy認為Physical View和《Software Architecture in Practice, 3rd》的Allocation Structure相近。

***

Scenario View

劇情（腳本）觀點將其他四個觀點全部串連起來。Scenario可以想成Use Case的某個路徑，Scenario View將此路徑中物件與行程的互動關係用object scenario diagram與object interaction diagram畫出來，應該是相當於UML sequence diagram與collaboration diagram之類的圖。

▲論文Scenario View的例子，類似UML collaboration diagram

在《Software Architecture in Practice, 3rd》書中提到的三種Structure似乎並沒有包含Scenario View。

***

結論

看到這裡希望不要愈看越模糊，最後做一下重點整理：

• 雖然〈The 4+1 View Model of Architecture〉標題主要在談Architecture，但論文中有提到這些View適合使用在architecture-centered、scenario-driven、iterative development process。耶，這三點不正是RUP的特點嗎（use case driven、architecture-centric、iterative and incremental development）？文章標題之所要用「4+1 View」，是為了特別凸顯增加Scenario View用來串起傳統一般軟體架構會涵蓋的那四個View。
• 在《Software Architecture in Practice, 3rd》提到的那三個結構：Module Structure、C&C Structure、Allocation Structure，大約可以對應到這篇文論所提到的那4個View。因為Scenario View比較像是考慮了開發流程所增加的一個View，也許因為如此《Software Architecture in Practice, 3rd》沒有把它放進來（有待確認）。也就是說，雖然他們對於架構應該涵蓋那些「結構」或「觀點」分類方式以及所用的名稱不同，但其內容的本質其實是大同小異。

最後再討論一個問題：「為什麼軟體架構需要這麼多結構或是觀點來表達？」就好像蓋房子一樣，有建築結構圖、平面隔間配置圖、水電瓦斯配置圖、管線圖，每一種圖代表一種關注點。如果把不同的圖全部畫再一起，那麼最後的「架構圖」將變得無法閱讀。所以針對每一種關注點畫一張圖，依據需要再把圖「疊起來」一起閱讀，這樣就不會亂了套（怎麼跟Aspect-Oriented Programming的精神那麼像XD）。

***

友藏內心獨白：架構就是靜態、動態、軟體、硬體，以及它們之間彼此的關係。