基于UML的軟件體系結構描述方法研究

摘要:對基于UML(Unified Modeling Language)的“4+1”視圖模型進行描述，從場景、概念視圖、過程視圖、構件視圖、物理視圖5個視角完整的描述一個系統的體系結構，并將該視圖模型應用到鋼材庫管理系統的體系結構描述中。實踐表明:它是面向對象軟件開發方法中高效而實用的軟件體系結構建模方法。

關鍵詞:軟件體系結構;多視圖;模型;UML

1 引言

在描述軟件體系結構時，不僅要考慮系統功能方面，實際上系統的物理分布、過程通訊等問題也要加以考慮。UML提供了可視化的圖形表示方法及語義化的元模型描述規范，提供了靜態和動態兩種建模機制。利用UML的半形式化特性及嵌入的擴充機制，可以從多個視圖描述軟件體系結構。本文利用UML的“4+1”視圖模型，分別從概念、過程、構件、物理、場景等五個不同的視角來描述鋼材庫管理系統的軟件體系結構，5個視角結合在一起反映鋼材庫系統的體系結構的全部內容。

2 “4+1”視圖的體系結構模型

對一個軟件體系結構的描述可以從不同的視角來描述。“4+1”視圖模型中的5個體系結構視角反映了系統構造的主要方面，能夠全面系統地描述一個軟件系統的體系結構。

“4+1”模型從邏輯、開發、過程、物理和場景5個不同的視角來描述軟件體系結構的全部內容，如圖1所示。對比軟件體系結構各個視角與軟件開發的各階段，邏輯視角、開發視角、過程視角和物理視角分別對應于軟件開發的需求分析、總體設計、詳細設計和實現階段。

“4+1”視圖模型反映了系統構造的幾個方面，體現體系結構構造的抽象特征，體現系統的體系結構風格;反映了基于構件的軟件開發方法的一些特征;對于“體系結構模型的實現”，“如何構造這些視圖以及視圖之間的映射關系”給予指導。

邏輯視角:描述系統的功能需求及它們之間的相互關系;按照應用領域的概念描述體系結構。這些概念與實現它們的代碼有關系，但并不總有直接映射的關系。體系結構在該視圖中設計系統的功能特性。例如，概念視圖的一個普通目標是組織體系結構以便能夠方便的增加、刪除及修改系統的功能。這對于系統演化非常重要，同時能支持體系結構的重用。

過程視角:過程角度側重于系統的運行性;從系統的行為出發，考察各個構件之間的協作/交互/通訊關系，反映系統的行為結構。該視圖基于系統的需求場景，同時遵循框架視圖的制約，是系統核心結構之一。

開發視角:開發角度負責軟件模塊的組織和管理;該視圖以構件為著眼點，是系統開發的核心結構之一，是框架視圖的設計模式，是對框架視圖的細化。

物理視角:物理角度解決系統的拓撲結構、系統安裝及通信等問題;描述系統的軟件與硬件之間的映射關系并反映其分布特性，展示軟件在生命周期的不同階段中所必須的物理環境或硬件配置以及分布狀況。

場景:場景則對應于用戶需求和系統功能實例的抽象，設計者通過分析如何滿足每個場景所要求的約束來分析軟件的體系結構。場景是整個體系結構設計的依據，是以上六個視圖構造的著眼點。它對應于重要的用戶需求和系統功能實例的抽象，設計者通過分析“如何滿足每個場景所要求的約束”來設計軟件的體系結構。

綜上所述，概念視圖定義系統的目標;構件視圖、過程視圖提供詳細的解決方法;物理視圖解決系統的拓撲結構、系統安裝及通信等問題;場景反映完成上述任務的組織結構。概念視圖是高層體系結構;構件視圖、過程視圖構成體系結構的核心，是系統開發的關鍵結構，為低層體系結構;物理視圖則為輔助體系結構。

3 基于UML的鋼材庫管理系統體系結構“4+1”

視圖描述

3.1 “4+1”視圖體系結構的構造

“4+1”視圖體系結構模型的構造涉及多種角色，并且分別完成不同的任務:

(1)用戶與系統分析師通過需求工程獲得待開發系統的功能和非功能需求，將其轉化為功能場景與質量場景，即“4+1”視圖模型中的場景。

(2)體系結構設計師完成如下任務:

①將功能場景轉化為概念視圖，并征求用戶的確認，得到待解決問題的定義;

②根據已有的體系結構知識，選擇和確定構件視圖、過程視圖;

③在得到核心體系結構模型后，開發物理視圖;

(3)構件工程師依據構件視圖、過程視圖、數據視圖開發相應的構件;

(4)集成工程師依據構件視圖集成部署構件;

(5)組織管理者按照場景分配開發任務。

對于體系結構的構造而言，只考慮體系結構設計師相應的工作，即如何得到上述四個視圖。下面具體討論各個視圖的構造與基于UML的描述方法。

3.2 場景描述

場景可以采用UML中的用例圖來描述。用例圖包含的主要實體有:用例、參與者和系統邊界。用例通過系統與一個或多個參與者之間的一系列消息來描述系統中的交互作用，用于表示系統的一項外部功能需求，即從用戶角度分析所得的需求;參與者用于描述與系統功能有關的外部實體，可以是用戶，也可以是外部系統;系統邊界用于界定系統功能范圍。

鋼材庫管理系統的軟件體系結構圖中，共涉及九個用例，分別對應九個基本的系統功能。外部角色有四個，分別是:客戶、業務人員、供應商、系統管理員。在場景描述中，分別從四個外部角色的角度對系統提出功能需求。鋼材庫管理系統體系結構的場景描述如圖2所示。

3.3 概念視圖描述

在概念視圖中，組件是角色和用例，連接件是角色和用例之間的關系以及多個用例之間的關系。在構造概念視圖時，著眼點是功能場景，考慮系統的功能分解，但不考慮其實現。具體來說，將需求工程得到的功能場景抽取為視圖中的一個功能組件;進而考慮這些功能組件之間的關系。 概念視圖可以采用UML用例圖來表示，從所有參與者的角度出發，通過用例來描述他們對系統概念的不同理解，每一個用例名相當于一個概念功能的名稱。

在鋼材庫管理系統體系結構的概念視圖中，給出了該體系結構的系統功能需求的抽象描述，即系統提供給最終用戶的服務。鋼材庫管理系統主要完成對供應商的開戶，對貨物的質檢、入庫、出庫等功能。鋼材庫管理系統體系結構中的概念視圖如圖3所示。

3.4 過程視圖描述

過程視圖主要通過對過程動態模型建模來實現，用UML中的活動圖來描述。過程視圖幫助設計人員更細致的分析概念視圖和場景中的用例，分析

視圖和場景中用例工作流之間的交互。大型軟件系統非常復雜，很多過程可能是并行的，活動圖支持并行的行為。

鋼材庫管理系統體系結構中的過程視圖如圖4所示，包括權限檢查、開戶、質檢、入庫、出庫、查詢、異常處理等組件。

3.5 構件視圖描述

構件視圖用于描述軟件開發中程序模塊的靜態組織結構，由程序庫或子系統組成，用UML中的構件圖來表示。它考慮軟件內部的特性，描述軟件開發以及軟件的組織，顯示系統結構的劃分。在構件視圖中，組件就是程序模塊，程序模塊之間的關系是連接件。

在鋼材庫管理系統中，包含這樣一些組件:完成質檢功能的質檢組件、對入庫貨物進行信息錄入與出單的入庫組件、負責出庫工作的出庫組件及它們所對應的數據庫組件。這些組件及其相互關系如圖5所示。

3.6 物理視圖描述

物理視圖描述如何把軟件映射到硬件上，它通常考慮系統性能、規模和可擴展性等，主要通過UML中的配置圖加以實現。配置圖定義系統中軟硬件的邏輯或物理的拓撲結構，它可以顯示計算節點的拓撲結構和通信路徑、節點上運行的軟件組件、組件包含的邏輯單元等。

鋼材庫管理系統是一個采用C/S體系結構風格的系統，其體系結構中的物理視圖如圖6所示。客戶端和服務器端是節點，兩個節點之間通過TCP/IP協議進行連接。在客戶端，開戶單、入庫單和出庫單填寫界面作為相應的構件。

4 結論

針對基于UML的“4+1”視圖體系結構模型描述的特點，分別闡述各視圖的定義及其基于UML的描述方法，最后將該模型應用到鋼材庫管理系統的體系結構描述中，證明了將該模型用于面向對象的軟件開發方法中描述軟件體系結構的可行性及易用性。

參考文獻

[1]J.Wiley. The Art of Software Architecture:Design[J]. Methods and Techniques.2003.

[2]M.Bernardo， P.Ciancarini， L.Donatiello. On the formalization of architectural types with Process algebras.In D.S.Rosenblum， editor，Proc.of the 8th ACM Int.Symp.on the Foundations of software Engineering (FSE-8):14~148.ACM press， November 2000.

[3]馬重明，張學旺，范時平.基于UML的軟件體系結構開發方法[J].計算機工程與應用.2006(4).

[4]黃正寶，張廣泉.一種新型的軟件體系結構描述方法研究[J].微電子學與計算機.2006，23(12).