l

2017年1月18日 星期三

軟體架構的 4 + 1 View

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

屏幕截图 2017-01-16 20.30.50

▲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中物件的重要行為需要被定義在介面上,如果要表達物件的重要內部行為,可以用狀態圖來表達。

 

屏幕截图 2017-01-16 17.00.36

▲Logic View所使用的符號

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


屏幕截图 2017-01-16 16.45.14

▲論文中舉了兩個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)。

 

屏幕截图 2017-01-16 17.29.08

▲Process View所使用的符號

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

 

屏幕截图 2017-01-16 17.32.14

▲論文中的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)關係。

 

屏幕截图 2017-01-16 17.53.06

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

 

屏幕截图 2017-01-16 17.55.06

▲論文中的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針對開發環境、測試環境、生產環境會有不同的配置(看到這裡是否想到持續整合與持續佈署?)

 

屏幕截图 2017-01-16 18.15.18

▲Physical View所使用的符號

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

 

屏幕截图 2017-01-16 18.22.59

▲論文中的Physical View例子

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

 

屏幕截图 2017-01-16 18.28.22

▲論文中另一個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之類的圖。

屏幕截图 2017-01-16 21.04.44

▲論文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)。

屏幕截图 2017-01-16 22.15.36

***

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

沒有留言:

張貼留言