4+1視圖與UML對應關系


  • 4+1視圖模型概況     Kruchten 提出了一個"4+1"視圖模型,從5個不同的視角包括包括邏輯試圖、進程視圖、物理視圖、開發視圖、場景視圖來描述軟件體系結構。每一個視圖只關心系統的一個側面,5個試圖結合在一起才能反映系統的軟件體系結構的全部內容。如下圖:  

     

  •  邏輯試圖主要是用來描述系統的功能需求,即系統提供給最終用戶的服務. 在邏輯視圖中,系統分解成一系列的功能抽象、功能分解與功能分析,這些主要來自問題領域(Problem Definition)。 在面向對象技術中,通過抽象、封裝、繼承,可以用對象模型來代表邏輯視圖,可以用類圖(Class Diagram)來描述邏輯視圖。如下圖: 構件(Components):類、類服務、參數化類、類層次 連接件(Connectors):關聯、包含聚集、使用、繼承、實例化 

  • 開發視圖(Development/Module View)     開發視圖主要用來描述軟件模塊的組織與管理(通過程序庫或子系統)。服務於軟件編程人員, 方便后續的設計與實現。它通過系統輸入輸出關系的模型圖和子系統圖來描述。要考慮軟件的內部需求:開發的難易程度、重用的可能性,通用性,局限性等等。開發視圖的風格通常是層次結構,層次越低,通用性越好(底層庫:Java SDK,圖像處理軟件包)。如下圖: 構件:模塊、子系統、層 連接件:參照相關性、模塊/過程調用 

  • 進程視圖   進程試圖側重系統的運行特性,關注非功能性的需求(性能,可用性)。服務於系統集成人員,方便后續性能測試。強調並發性、分布性、集成性、魯棒性(容錯)、可擴充性、吞吐量等。定義邏輯視圖中的各個類的具體操作是在哪一個線程(Thread)中被執行。 如下圖: 構件:進程、簡化進程、循環進程 連接件:未指定,消息、遠程過程調用(RPC)、雙向消息、事件廣播 

  • 物理視圖       物理試圖主要描述硬件配置。服務於系統工程人員,解決系統的拓撲結構、系統安裝、通信等問題。主要考慮如何把軟件映射到硬件上,也要考慮系統性能、規模、可靠性等。可以與進程視圖一起映射。如下圖: 構件:處理器、計算機、其它設備 連接件:通信協議等  

  • 場景(Scenarios)       場景用於刻畫構件之間的相互關系將四個視圖有機地聯系起來。可以描述一個特定的視圖內的構件關系,也可以描述不同視圖間的構件關系。文本、圖形表示皆可。 

  • 小結     邏輯視圖、開發視圖,都主要是用來描述系統的靜態結構。 進程視圖、物理視圖,主要是用來描述系統的動態結構。 並非每個系統都必須把5個視圖都畫出來,而是各有側重。例如MIS系統側重於邏輯視圖、開發視圖,而實時控制系統則側重於進程視圖、物理視圖 

 Betty:UML中有動態和靜態視圖,靜態圖是不是就是結構圖?用案圖是不是就是用例圖?

             那么,下面兩個圖有點矛盾,用例圖到底是動態還是靜態

主要的域 視圖 主要概念
結構

靜態視圖

類圖

類、關聯、泛化、依賴關系、實現、接口

用例視圖

用例圖

用例、參與者、關聯、擴展、包括、用例泛化

實現視圖

構件圖

構件、接口、依賴關系、實現

部署視圖

部署圖

節點、構件、依賴關系、位置

動態

狀態機視圖

狀態機圖

狀態、事件、轉換、動作、

 

活動視圖

活動圖

狀態、活動、完成轉換、分叉、結合

 

交互視圖

順序圖

交互、對象、消息、激活

 

 

協作圖

協作、交互、協作角色、消息

模型管理

模型管理視圖

類圖

報、子系統、模型

可擴展性

所有

所有

約束、構造型、標記值

通常我們選擇UML來表現各種視圖,以下列出了UML和各視圖的對應關系

4+1視圖                                   UML

場景視圖                            use case

邏輯視圖                            類圖

開發視圖                            類圖,組件圖

進程視圖                            無完全對應

部署視圖                            部署圖

在架構設計穩定中通常不會給出較多的用例描述,這些是在需求穩定中定義。但是往往架構文檔會選擇一些用例,列入文檔中,這些用例和一些非功能性需求一起用以證明架構的有效和正確性。在邏輯視圖中用例的實現是必不可少的一節,盡管架構設計更關注非功能性需求。

融入MDA的思想

對於邏輯視圖和開發視圖所應包含的內容常常會覺得很難區分兩者間的明顯界限。邏輯視圖包含更多的分析模型與實現技術本身相關性應該較少,如業務對象模型及其擴展。而開發視圖則會與實現技術緊密相關。

隨着MDA思想的推廣,在架構設計文檔的撰寫方面也產生了影響,我們不難把MDA的PIM和邏輯視圖聯系起來,而把MDA中的PSM和開發視圖聯系起來。

在編寫邏輯視圖是我們應該描述與技術平台無關的模型,而開發視圖則描述與實現技術平台相關的模型。

如在邏輯視圖中表現的某些實體類,我們會在開發視圖中轉換為EJB組件(實體Bean)。

這種做法不僅有利於我們編寫架構設計文檔,同時更是一種好的架構設計思考流程。 

 原文鏈接: https://m.oschina.net/blog/327255


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM