基于ＵＭＬ的多視圖軟件體系結構描述方法研究
2008-12-31 00:00:00劉寧鄭東霞
計算機應用研究 2008年11期
(1.大連海事大學信息科學與技術學院， 遼寧 大連 116026; 2.東北大學 東軟信息學院 計算機科學與技術系， 遼寧 大連 116023）
摘要：提出一種新的基于UML(unified modeling language)的多視圖模型，即“6＋1”視圖模型，從場景、概念視圖、框架視圖、過程視圖、數據視圖、構件視圖、物理視圖七個視角完整地描述一個系統的體系結構，并將該視圖模型應用到鋼材庫管理系統的體系結構描述中。實踐表明，它是面向對象軟件開發方法中高效而實用的軟件體系結構建模方法。
關鍵詞：軟件體系結構； 多視圖； 模型； 統一建模語言
中圖分類號：TP311文獻標志碼：A
文章編號：1001-3695(2008)11-3367-03
Research on describing method of multi-view softwarearchitecture based on UML
LIU Ning1， ZHENG Dong-xia2
(1.School of Information Science Technology， Dalian Maritime University， Dalian Liaoning 116026， China; 2.Dept. of Computer Science Technology， Neusoft Institute of Information Technology， Dalian Liaoning 116023， China)
Abstract:This paper proposed a new UML-based multi-view model， that is “6+1” view model. The model completely described a system architecture from seven perspectives，that is the scene，conceptual view，framework view，process view，data view，component view，physical view. And the view model was applied to describe the architecture of the steel base management system. The practice indicates that the new model is an effective and applied architecture modeling method in object-oriented software development.
Key words：software architecture; multi-view; model; UML
在處理體系結構時，通常只考慮系統功能方面的需求，而實際上系統的物理分布、過程通信和同步等問題也必須在體系結構中加以考慮。UML提供了可視化的圖形表示方法及語義化的元模型描述規范，提供了靜態和動態兩種建模機制。利用UML的半形式化特性及嵌入的擴充機制，可以從多個視圖描述軟件體系結構。Kruchten在1995年提出了一個基于UML的“4+1”視圖模型，從五個不同的視角來描述軟件體系結構，五個視角結合在一起反映軟件體系結構的全部內容。在“4+1”視圖模型的基礎上，對其進行擴充，分別從概念、框架、過程、數據、構件、物理、場景七個視角考慮體系結構的構造，提出“6＋1”視圖體系結構模型。該模型描述系統的核心概念是什么；系統是如何滿足應用需求的；系統需要哪些構件；系統的實現需要哪些物理環境給予支持以及如何構造這些視圖等。
1“6＋1”視圖的體系結構模型
對一個軟件體系結構的描述可以從不同的視角來描述。“4+1” 視圖模型中的五個體系結構視圖基本上反映了系統構造的主要方面，“6＋1”視圖體系結構模型能夠更全面系統地描述一個軟件系統的體系結構。
11“4＋1”視圖描述軟件體系結構
“4+1”模型從邏輯、開發、過程、物理和場景五個不同的視角來描述軟件體系結構的全部內容，如圖1所示。其中，邏輯角度描述系統的功能需求及它們之間的相互關系；開發角度負責軟件模塊的組織和管理；過程角度側重于系統的運行性；物理角度解決系統的拓撲結構、系統安裝及通信等問題；場景則對應于用戶需求和系統功能實例的抽象，設計者通過分析如何滿足每個場景所要求的約束來分析軟件的體系結構。對比軟件體系結構各個視角與軟件開發的各階段，邏輯視角、開發視角、過程視角和物理視角分別對應于軟件開發的需求分析、總體設計、詳細設計和實現階段。
“4+1” 視圖模型中的四個體系結構視圖基本上反映了系統構造的幾個主要方面，但在某些方面尚存在不足。經過分析認為具體表現在如下幾個方面：
a）“4+1”視圖不能體現體系結構構造的多層抽象特征，不能體現系統的體系結構風格；
b）數據作為系統開發的一個重要方面，在“4+1”視圖中沒有得到充分體現；
c）無法反映基于構件的軟件開發方法的一些特征，如構件、構件組織結構、開發者之間的關聯等；
d）對于體系結構模型的實現，如何構造這些視圖以及視圖之間的映射關系等方面缺乏更詳細的指導。
12“6＋1”視圖的體系結構模型
針對“4+1”視圖模型存在的不足，分別從概念、框架、過程、數據、構件、物理六個視圖以及場景的角度考慮體系結構的構造，提出“6＋1”視圖體系結構模型，如圖2所示。
1)概念視圖按照應用領域的概念描述體系結構。這些概念與實現它們的代碼有關系，但并不總有直接映射的關系。體系結構在該視圖中設計系統的功能特性。例如，概念視圖的一個普通目標是組織體系結構以便能夠方便地增加、刪除及修改系統功能。這對于系統演化非常重要，同時能支持體系結構的重用。
2）框架視圖該視圖從高層抽象的角度出發，體現體系結構的風格，制約并指導構件視圖、過程視圖、數據視圖的構造，是系統的大粒度構成結構，是詳細解決方案的抽象。
3）過程視圖從系統的行為出發，考察各個構件之間的協作/交互/通信關系，反映系統的行為結構。該視圖基于系統的需求場景，同時遵循框架視圖的制約，是系統核心結構之一。
4）數據視圖從數據生產和消費的角度出發，關注系統的結構問題，是構件視圖的一種特化，反映體系結構的靜態特性；是框架視圖在以數據構件為組成結構下的映射，同時數據視圖還貫穿于過程視圖中，是連接各個計算構件或連接件的中間媒介。它所關心的問題是:數據是從哪里產生的，是如何存儲的，在哪些組件之間傳輸。
5）構件視圖該視圖以構件為著眼點，是系統開發的核心結構之一，是框架視圖的設計模式，是對框架視圖的細化。
6）物理視圖描述系統的軟件與硬件之間的映射關系并反映其分布特性，展示軟件在生命周期的不同階段中所必需的物理環境或硬件配置以及分布狀況。
7）場景它是整個體系結構設計的依據，是以上六個視圖構造的著眼點。它對應于重要的用戶需求和系統功能實例的抽象，設計者通過分析如何滿足每個場景所要求的約束來設計軟件的體系結構。
綜上所述，概念視圖定義系統的目標；框架視圖、構件視圖、過程視圖和數據視圖則提供詳細的解決方法。其中框架視圖是大粒度的；后三者則從靜態組成、動態行為、數據側面對其進行細化；物理視圖解決系統的拓撲結構、系統安裝及通信等問題；場景反映完成上述任務的組織結構。框架視圖是高層體系結構；構件視圖、過程視圖和數據視圖構成體系結構的核心，是系統開發的關鍵結構，為低層體系結構；而概念視圖、物理視圖則為輔助體系結構。
2基于UML的鋼材庫管理系統體系結構“6＋1”視圖描述
21“6+1”視圖體系結構的構造
“6＋1”視圖體系結構模型的構造涉及多種角色，并且分別完成不同的任務：
a）用戶與系統分析師通過需求工程獲得待開發系統的功能和非功能需求，將其轉換為功能場景與質量場景，即“6＋1”視圖模型中的場景。
b）體系結構設計師完成如下任務：
(a)將功能場景轉換為概念視圖，并征求用戶的確認，得到待解決問題的定義；
(b)根據已有的體系結構知識，選擇和確定框架視圖；
(c)依據框架視圖得到構件視圖、過程視圖和數據視圖；
(d)在得到核心體系結構模型后，開發物理視圖。
c)構件工程師依據構件視圖、過程視圖、數據視圖開發相應的構件。
d）集成工程師依據構件視圖集成部署構件。
e）組織管理者按照場景分配開發任務。
對于體系結構的構造而言，只考慮體系結構設計師相應的工作，即如何得到上述六個視圖。下面具體討論各個視圖的構造與基于UML的描述方法。
22場景描述
場景可以采用UML中的用例圖來描述。用例圖包含的主要實體有用例、參與者和系統邊界。用例通過系統與一個或多個參與者之間的一系列消息來描述系統中的交互作用，用于表示系統的一項外部功能需求，即從用戶角度分析所得的需求；參與者用于描述與系統功能有關的外部實體，可以是用戶，也可以是外部系統；系統邊界用于界定系統功能范圍。
鋼材庫管理系統的軟件體系結構圖中，共涉及九個用例，分別對應九個基本的系統功能。外部角色有四個，即客戶、業務人員、供應商和系統管理員。在場景描述中，分別從四個外部角色的角度對系統提出功能需求。鋼材庫管理系統體系結構的場景描述如圖3所示。
23概念視圖描述
在概念視圖中，組件是角色和用例，連接件是角色與用例之間的關系以及多個用例之間的關系。在構造概念視圖時，著眼點是功能場景，考慮系統的功能分解，但不考慮其實現。具體來說，將需求工程得到的功能場景抽取為視圖中的一個功能組件，進而考慮這些功能組件之間的關系。 概念視圖可以采用UML用例圖來表示，從所有參與者的角度出發，通過用例來描述他們對系統概念的不同理解。每一個用例名相當于一個概念功能的名稱。
在鋼材庫管理系統體系結構的概念視圖中，給出了該體系結構的系統功能需求的抽象描述，即系統提供給最終用戶的服務。鋼材庫管理系統主要完成對供應商的開戶，對貨物的質檢、入庫、出庫等功能。鋼材庫管理系統體系結構中的概念視圖如圖4所示。
24框架視圖描述
框架視圖需要展現的是系統的類及對象，對系統進行靜態和動態行為的建模。可以由UML中的類圖、對象圖和包圖來描述，側重以質量場景為著眼點，尋求合適的體系結構風格/模式，進行系統大粒度的分解，分析系統的子系統組成，以及子系統之間關系等基本問題。每個子系統均由相應的構件或構件簇來實現時，需要保持子系統的組成關系。
鋼材庫管理系統體系結構中的部分框架視圖如圖5所示。
25過程視圖描述
過程視圖主要通過對過程動態模型建模來實現，用UML中的活動圖來描述。過程視圖幫助設計人員更細致地分析概念視圖和場景中的用例，分析視圖和場景中用例工作流之間的交互。大型軟件系統非常復雜，很多過程可能是并行的，活動圖支持并行的行為。
鋼材庫管理系統體系結構中的過程視圖如圖6所示，包括權限檢查、開戶、質檢、入庫、出庫、查詢、異常處理等組件。
26數據視圖描述
數據視圖給出數據元素之間的關系以及數據間的流動。軟件體系結構中的數據視圖不同于數據庫中的數據視圖。在體系結構中，組件不再是計算組件，而是數據組件，組件之間的交互，即數據視圖中的連接件體現為數據組件之間的轉換關系。數據組件可以用UML中的類圖或對象圖表示，連接件可以用類圖或對象圖之間的關系描述。
在鋼材庫管理系統體系結構的數據視圖中，包含業務人員類、貨位類、收貨類、入庫類、訂貨類、供應商類、客戶類、出庫類等數據組件，如圖7所示。
27構件視圖描述
構件視圖用于描述軟件開發中程序模塊的靜態組織結構，由程序庫或子系統組成，用UML中的構件圖來表示。它考慮軟件內部的特性，描述軟件開發以及軟件的組織，顯示系統結構的劃分。在構件視圖中，組件就是程序模塊，程序模塊之間的關系是連接件。
在鋼材庫管理系統中，完成質檢功能的質檢組件、對入庫貨物進行信息錄入與出單的入庫組件、負責出庫工作的出庫組件及它們所對應的數據庫組件。這些組件及其相互關系如圖8所示。
28物理視圖描述
物理視圖描述如何將軟件映射到硬件上，它通常考慮系統性能、規模和可擴展性等，主要通過UML中的配置圖加以實現。配置圖定義系統中軟硬件的邏輯或物理的拓撲結構，它可以顯示計算節點的拓撲結構和通信路徑、節點上運行的軟件組件、組件包含的邏輯單元等。
鋼材庫管理系統是一個采用C/S體系結構風格的系統。其體系結構中的物理視圖如圖9所示。客戶端和服務器端是節點，兩個節點之間通過TCP/IP協議進行連接。在客戶端，開戶單、入庫單和出庫單填寫界面作為相應的構件。
3結束語
針對基于UML的“4+1”視圖體系結構模型描述中存在的不足，本文提出了更加全面的“6+1”視圖模型，并分別闡述各視圖的定義及其基于UML的描述方法。最后將該模型應用到鋼材庫管理系統的體系結構描述中，證明了將該模型用于面向對象的軟件開發方法中描述軟件體系結構的可行性及易用性。
參考文獻：
［1］梅宏， 申峻嶸. 軟件體系結構研究進展[J].軟件學報，2006，17(6)：1257-1275.
[2]馬重明， 張學旺， 范時平. 基于UML的軟件體系結構開發方法[J]. 計算機工程與應用，2006(4):118-120，148.
[3]黃正寶， 張廣泉.一種新型的軟件體系結構描述方法研究[J].微電子學與計算機，2006，23(12):82-84，88.
[4]ALBIN S T.The art of software architecture: design methods and techniques[M]. [S.l.]:Wiley， 2003.
[5]BERNARDO M， CIANCARINI P， DONATIELLO L.On the formalization of architectural types with process algebras[C]//Proc of the 8th ACM Int Symp on the Foundations of Software Engineering.[S.l.]:ACM Press，2000:14-18.
